쿠버네티스 따라하기- k8s 기본 명령어와 pod구조

쿠버네티스란?

k8s, Kubernetes, 큐브, kube 등으로 불리며, 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

쿠버네티스 클러스터는 온프레미스, public, private, Hybrid Cloud 등으로 호스트를 확장 할 수 있다. 

도커와 컨테이너, 쿠버네티스에 대한 기본적인 내용은 아래 포스팅을 참고하자.

 

https://ysuekkom8915.tistory.com/55

클라우드, 도커, 컨테이너, 쿠버네티스 ?

---

쿠버네티스 이해하기

쿠버네티스는 서로 다른 워크로드를 충족하기 위해 '느슨한 결합'으로 확장 가능하다. 쿠버네티스에서 실행되는 내부 구성 요소와 확장 및 컨테이너는 k8s API에 의존한다. k8s의 구성 요소는 개별 노드와 그것을 관리하는 Control Plane로 나뉜다.

https://en.wikipedia.org/wiki/Kubernetes

 

k8s 디자인의 가장 기본 원리는 1. MSA, 2. Desired State, 3. 선언적 이다.

MSA는 위에서 언급한 느슨한 결합을 의미하고, Desdired State란 '현재 상태'가 아닌 '되고자 하는 상태'로, 현재 상태와 Desried State를 끊임없이 비교, 모니터링, 동기화하려는 것을 Control Loop라고 하며, Master Node에서 수행된다. 

 

 

>>파드는 클러스터의 Desired State와 일치하도록 생성되고, 삭제되는 매커니즘을 갖고 있다.

 .Deployment를 통해 배포할 경우, ReplicaSet이 Desired State로 항상 맞추기 때문에,  특정 파드가 삭제된다고 해도 Deployment를 통해 다시 생성되므로 문제 없음.

 

 

---

기본 구성 요소

마스터 노드와 워커노드로 구성된다. 마스터 노드는 k8s Control Plane을 처리하여 워커노드를 관리하고 시스템 전체 통신을 지시한다. 

  **노드: k8s에서 최소 단위의 하드웨어 유닛으로, Proxy와 Kubelet 두 가지 컴포넌트를 가진다. 

 

-Pod(파드)

쿠버네티스가 관리하는 컨테이너의 논리적 집합으로 보면 된다. 컨테이너를 묶어두는 단위로, 하나의 job을 수행하기 위해 묶인 집합이다. 하나의 파드는 1개~n개의 컨테이너를 실행할 수 있다.

 .애플리케이션을 배포하는 단위

 .일반적으로 하나의 pod에는 하나의 애플리케이션을 구동시킴

 .파드는 컨테이너를 감싼 것으로, k8s는 컨테이너를 둘러싼 파드를 관리하는 것임 

 

 

-동작: 파드를 실행하면, 파드 내 컨테이너 간 동일한 리소스와 NW를 공유하게 되고, k8s는 이를 복제하여 클러스터에 배포하는 방식으로 Replication 동작한다. 즉 하나의 파드에 배치된 컨테이너는 결합된 서비스 단위를 형성한다. 

uuu.jini Vlog

기존 docker라는 엔진 위에 각 컨테이너를 올려 각각 통신하게 되는 것이고, k8s의 컨테이너는 파드로 묶여 상위  1개의 IP(파드 생성 시 마다 부여)로 통신하게 되는 차이점이 있다. 

  **클러스터: 여러 노드를 묶은 그룹으로, 효율적인 리소스 공유와 균형 배분을 위함

  **pause: 일종의 pod 내부 컨테이너들의 부모 컨테이너(namespace를 공유하여 같은 리소스와 NW를 공유)

                 Pod에 반드시 1개 생성

#kube get pod	//pod정보 가져오기
#kubectl get pod -o wide

 

 

파드는 컨테이너를 실행하기 위한 환경으로, 파드가 컨테이너 자체가 아님을 주의!

 

-파드의 생성

 파드를 생성하기 위한 명세  "PodTemplate" : 파드를 생성하기 위한 spec 코드로, 앱을 실행하는 데 사용되는 워크로드 리소스를 명시해놓은 것. 

 

https://ysuekkom8915.tistory.com/59

[k8s] Pod 생성 시 플로우와 쿠버네티스 특성 이해하기

 

 

-특징

 .파드 템플릿을 수정해도, 수정하기 전 생성했던 파드에는 영향을 미치지 않음

 .구동중인 상태를 만들기 위한 일회성 자원으로, 특정 파드에 문제 발생 시 그룹 내 다른 파드를 사용하기 위한 Service 컴포넌트를 사용)

 

 

---

1. 마스터노드

 .api server를 통해 쿠버네티스를 관리(Control Plane)하고, 모든 컴포넌트들은 api를 통해 통신

 .워커 노드에 pod(파드)를 할당하고 컨테이너를 띄우는 역할 수행

 .쿠버네티스의 상태 관리 및 Pod 스케줄링 관리

 .각 구성 요소들은 static pods로 불리며 yaml 파일 형태로 /etc/kubernetes/manifest/에 존재함

 

● api-server: 클러스터 통신 수행의 중추 역할로 상태조회/변경 등의 요청을 관리한다.

- 마스터노드와 워커노드의 통신 통로

- 리소스를 생성하거나 클러스터를 관리할 때, 쿠버네티스 CLI가 통신하는 끝점으로 동작.

 

 

● etcd(엣지디):  status value 저장(Key-Value 데이터 저장소)

- k8s의 모든 데이터가 etcd에 저장, 높은 신뢰성이 요구됨(Replicated state machine**방식으로 데이터 복구)

- 특정 시점에서의 클러스터 상태와 구성 데이터를 저장하여 etcd의 데이터로 장애 상황 시, 백업 클러스터 복구 가능

 

RSM(Replicated State Machine)**

같은 데이터를 여러 서버에 복제하여 보관하는 방식으로, 데이터를 여러 서버에 안전하게 복제하기 위한 전제 조건을 만족해야 한다. 

  -Safety: 항상 올바른 결과를 리턴 할 것

  -Available:  서버 일부가 다운되더라도 항상 응답 값을 리턴해야 함

  -Independent from timing: NW Delay가 발생해도 일관성을 유지할 것

  -Reactivity: 조건 만족 시, 요청에 빠르게 응답 할 것

 

>>분산 환경에서 내결함성을 높이기 위해 상태를 공유하는 알고리즘을 Consensus Algorithm이라고 하며, k8s의 etcd는 Raft Algorithm을 사용함.

 **Raft Algorithm: 다수 노드로 이루어진 시스템에서 노드의 최신화, 동기화, 내결함성을 동시에 구현하기 위한 합의 알고리즘의 일종. 

 

 

● Scheduler: 각 노드의 상태를 체크, 리소스 생성 위치 결정

- 즉 리소스 요구사항과 파드 별 부하/상태를 보고 컨테이너를 띄울 Pod를 결정

 

 

● Controller-manager: 실제로 클러스터를 실행하는 컨트롤러의 집합

 -컨트롤러 매니저는 리소스를 배포할 때 실제 작업을 관리하는 컴포넌트 

 -Desired State를 만족시키기 위해 api-server를 지속 모니터링(=Cotnrol Loop)

-동작: 마스터노드의 controller manager 실행 > Control Loop 실행 > 표준/오퍼레이터 컨트롤러 모두 실행(Reconcile()호출)

   .Control Loop: "모니터링 > 상태차이 감지 > 액션"을 통해 Desired State와 일치시킴

                         : Control Loop는 마스터노드와 워커노드 각각에서 수행됨

  >마스터노드 내 위치: 표준 컨트롤러로 워커노드의 오퍼레이터 컨트롤러 호스팅(리스트 보유)

  >워커노드 내 위치: 오퍼레이터 컨트롤러로, 실제 Desired State를 맞추는 작업을 수행함

                                    >커스텀 컨트롤러 가능(원리는 같으나, 애플리케이션 운영을 위한 커스텀 적용)

 

**표준컨트롤러:  Replicaset, Deployment, DaemonSet, StatefulSets, Job ...,

  다양한 컨트롤러를 제공하기 때문에 애플리케이션 특성에 맞는 컨트롤러 선택하여 사용

 

 

2. 워커노드

마스터 노드와 통신하여 할당 받은 Pod 내에 컨테이너를 유지 및 관리하는 역할 수행

 .마스터 노드로부터 받은 명령 수행

 .실질적인 프로그램 운영, 컨테이너화된 애플리케이션을 실행

● kubelet: 컨테이너 및 pod의 정상 동작을 모니터링 및 상태 관리.

- Pod 구성을 api-server로 수신, CRI(Container Runtime Interface)로 전달하여 

-Master Node의 api server와 통신하여 실행중인 노드에서 리소스 관리를 담당.(==워커노드의 관리자)

 

● kube-porxy:  pod의 통신 관리

-NW 접근 관리 및 제어

-로드밸런싱

-서비스 추상화 지원

-내/외부 통신 설정 및 관리

 

● container runtime: 컨테이너 구동 역할

 

 

 

 

---

이어질  Pod 생성 Flow에서 사용된 컨트롤러/오브젝트 살펴보기

 -오브젝트: Pod, Service, Volume ...

 -컨트롤러: Desired State와 현재 상태를 일치시키기 위해 오브젝트들을 생성/삭제

 

 

-ReplicaSet

지정된 수(Deployment에 명시된 Desired State)의 동일한 pod를 생성 및 유지, 가용성을 보장

-지정한 숫자만큼 pod가 생성 됨(default= 1)

-쿠버네티스가 주어진 pod에 대해 인스턴스 수를 유지할 수 있게 해주는 그룹화 메커니즘으로 볼 수 있다.

-이력 관리가 안됨

#kubectl scale deployment deploy-nginx --replica=3	//deploy-nginx이름으로 pod 3개 생성하기
#kubectl get pods   //결과 확인하기

  .deployment: 여러개의 pod 집합으로 특정 pod 장애 발생 시, 다른 Pod가 서비스를 이어갈 수 있도록 구현한다.

#kubectl create deployment deploy-nginx --image=nginx      //kubectl create deployment [name] --image=nginx //nginx로 배포
deployment.apps/deploy-nginx created
#kubectl get pods    //결과 확인하기
#kubectl get pods -o wide

 

 

 

-Deployment

선언적 형태로 Pod와 ReplicaSet을 감시하는 역할을 수행함

 -ReplicaSet의 상위 개념으로 관리 역할(Desired State를 선언)

 -수정이 필요할 경우, ReplicaSet 자체 수정이 아닌 Deployment 내 spec.replicas 수정 권고

 - 이점: 이력 관리/배포(롤링, 블루/그린, 카나리) 관리 가능

//Ningx Pod(3개) 불러오는 ReplicaSet 선언한 Deployment 설정

apiVersion: apps/v1
kind: Deployment		//Deployment
metadata:
  name: nginx-deployment		//Deployment 이름
  labels:
    app: nginx		
spec:
  replicas: 3			//spec.replicas: 3개의 Replica Pod 생성
  selector:				//생성된 ReplicaSet이 관리하는 Pod
    matchLabels:
      app: nginx      //spec.selector.matchLabels에 정의된 레이블을 통해 pod 생성
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:		//1.14.2버전의 nginx 컨테이너 실행하여 nginx 이름을 붙임
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

 

kubectl apply -f test-replicaset.yaml

 

https://dobby-isfree.tistory.com/156

 

 

 

 

-Service

외부에서 노드에 접속할 수 있는 포인트를 제공(단일 네트워크 진입점)

 .즉 파드를 통해 실행되고 있는 애플리케이션을 외부와 통신할 수 있도록 해주는 가상 컴포넌트

 .Service가 각 클러스터 내 워커노드의 NodePort로 보내고, 각 NodePort가 통신하여 적절한 Pod를 찾아가는 구조

 

[root@m-k8s ~]# kubectl expose pod nginx --type=NodePort --port=80 	//오픈하려는 NodePort, 실제로 pod가 내부 컨테이너와 통신하기 위한 포트: 80
service/nginx exposed			//pod 노출
[root@m-k8s ~]# kubectl get services		//서비스 컴포넌트 확인
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)        AGE
kubernetes     ClusterIP      10.96.0.1        <none>         443/TCP        41d
nginx          NodePort       10.100.58.88     <none>         80:30105/TCP   10s

//NodePort라는 Type으로 nginx 노출된 것 확인, 
//외부로 노출된 포트번호:30105
//노드 정보 확인은 kubectl get nodes -o wide 로 확인 가능

 

 

 

 

 

 

 

 

참고

https://myit.tistory.com/30

https://www.startkubernetes.com/blog/k8s_master_and_worker_nodes

https://en.wikipedia.org/wiki/Kubernetes

https://velog.io/@squarebird/Kubernetes-etcd

https://seongjin.me/raft-consensus-algorithm/

https://tech.kakao.com/2021/12/20/kubernetes-etcd/

https://kubernetes.io/docs/concepts/workloads/pods/

https://kubernetes.io/ko/docs/concepts/services-networking/service/

https://jh-labs.tistory.com/503