쿠버네티스(Kubernetes) Pod 생성과 관리

■ 쿠버네티스 오브젝트(Object)의 이해 

• 오브젝트는 하나의 "의도를 담은 레코드" 이며, 쿠버네티스 시스템 내에서 상태정보가 변경되지 않는 영속성을 가지고, 영속성 보장을 위해 쿠버네티스 시스템이 지속적으로 작동함
• 쿠버네티스는 클러스터의 상태를 나타내기 위해 오브젝트를 활용 한다
  • 컨테이너화된 애플리케이션의 동작 여부와 동작하는 노드 정보 
  • 컨테이너화된 애플리케이션이 사용할 수 있는 리소스 
  • 재구동 정책, 업데이트 및 내고장성과 같은 정책 정의
• 오브젝트는 " spec "과 " status " 2개의 필드로 구성되어 있으며, spec을 사용하여 오브젝트 생성 시 쿠버네티스 시스템에 의도를 전달하고 쿠버네티스 시스템은 컨트롤-플레인을 통해 오브젝트의 상태(status) 감시하여 spec과 status를 비교하고 보정하는 능동적 행위를 수행 함. 
• 생성, 수정 및 삭제와 같은 쿠버네티스 오브젝트를 동작시키려면,  쿠버네티스 API를 이용해야 하며, kubectl와 같은 CLI을 사용하는 경우 CLI가 필요한 쿠버네티스 API를 호출해서 사용하게 되고, 외 에도 클라이언트 라이브러리를 이용하여 API를 직접 호출하여 사용할 수 있음. 
• 쿠버네티스에서 사용가능한 오브젝트 확인 명령어
  • kubectl api-resources  (사용 가능한 전체 오브젝트에 대한 목록 출력)
  • kubectl explain pods (특정 오브젝트에 대한 yaml 코드 작성 시 필요한 정보에 대한 설명)
  • kubectl explain pods.spec (spec에 대한 정보 조회. key:value 방식으로 . 를 이용하여 하위 목록 조회 가능)
  • kubectl explain pods.spec --recursive (--recursive 옵션을 통해 계층 정보 확인)
• 쿠버네티스 오브젝트 개념도

 

■ 쿠버네티스 Pod 관리 

• 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이자, 애플리케이션을 실행하는데 필요한 기본 단위 이다. 
• 파드가 물리적인 머신 또는 가상 머신 처럼 파드 내부에서 다수의 애플리케이션을 실행하는 논리적인 단위로써 논리적인 호스트 라고 한다
• 쿠버네티스는 컨테이너를 개별적으로 배포하는 것이 아닌 파드 단위로 배포 한다. 즉, 파드는 하나 이상의 컨테이너의 그룹이다.
• 파드 내부의 컨테이너들이 서로 독립적인 시스템 리소를 소유하도록 보장하는 것이 "네임스페이스"와 "네트워크 네임스페이스"이며, 이를 통해 리소스 자원을 분리하고 관리한다. 또한 "CGROUP"을 통해 리소스 사용량을 제한하고 격리하는 역할을 수행 한다.
  • 네임스페이스
    
    • 설명
      - 쿠버네티스 클러스터 내에서 리소스를 논리적으로 분리하고 관리하기 위한 단위 이다. 네임스페이스에 리소스 쿼터를 설정하여 리소스를 관리할 수 있으며, 리소스 쿼터가 설정된 네임스페이스의 경우 자원의 상한을 지정해야 하고, 해당 네임스페이스에 배포된 파드의 리소스 총합은 네임스페이스 설정된 리소스 상한을 초과할 수 없다.
    • 리소스 격리
      - 파드, 서비스, 디플로이먼트 등 다양한 쿠버네티스 리소스를 그룹화하고, 접근 제어 및 리소스 할당을 관리하는 데 사용됩니다.
  • 네트워크 네임스페이스
    • 설명
      - 파드가 실행 되기전 Pause 컨테이너가 먼저 실행되고,  Pause 컨테이너의 리눅스 네임스페이스를 파드 내부의 모든 컨테이너들이 공유해서 사용하기 때문에 동일한 IP주소와 인터페이스를 사용할 수 있다.
    • 네트워크 설정 유지
      - Pod 내의 다른 컨테이너가 종료되거나 재시작되더라도, 네트워크 설정은 그대로 유지되어 네트워크 연결 일관성을 보장 함
      
    • 리소스 격리
      - 네트워크 네임스페이스는 파드 실행 시 Pause 컨테이너에 의해 생성되기 때문에 파드간의 격리된 네트워크 환경을 제공 합니다. 
  • CGROUP
    • 리소스 격리 및 제한
      - cgroup(Control Group)은 리눅스 커널 기능으로 프로세스 그룹에 대해 CPU, 메모리, 디스크 I/O 등의 시스템 리소스를 제한하고 격리하는데 사용 된다. 각각의 파드와 컨테이너에 대해 CPU 와 메모리 사용량을 제한하고 격리 합니다. 
    • 리소스 관리 계층
      - 네임스페이스는 클러스터 단위에서 리소스를 관리하고 cgroup은 개별 컨테이너 수준에서 리소스를 물리적으로 제한하고 격리 합니다. 
    • QoS 관리
      - 파드 생성 시  리소스 요청, 상한 및 네임스페이스의 리소스 쿼터를 바탕으로 QoS Class를 부여 합니다. 
• 파드가 포함하는 컨테이너의 종류 (설계패턴)는 3가지가 있다.
• 실제 애플리케이션을 수행 → runtime container (기본)
• 기동 시점에서 처리하고 종료 → init container
• 보조 역할로써 배포 → sideCar container

■ 쿠버네티스 Pod 특징

• 파드 실행 방식
  • 단일 컨테이너 실행 파드
    - 파드 당 하나의 컨테이너 모델은 가장 일반적인 경우 이며, 쿠버네티스 는 컨테이너 대신 이런 파드를 관리한다.
  • 다중 컨테이너 실행 파드
    - 파드는 리소스를 공유하는 다중 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있다. 캡슐화된 것은 하나의 서비스 단위를 형성한다.
• 파드의 확장
  • 수평적 확장
    - 애플리케이션 성능을 높이기 위해 애플리케이션의 인스턴스를 여러 개 파드에서 실행하는 것. 쿠버네티스에서는 일반적으로 레플리케이션 이라 한다.
  • 수직적 확장
    - 하나의 인스턴스가 사용하는 리소스를 증가시키는 방법으로  인스턴스 자체의 성능을 높이는 것
• 파드 관리 워크로드
  • 워크로드 리소스를 이용하여 파드를 만들고 관리할 수 있고 장애 발생 시 복제 및 롤아웃과 자동 복구를 처리 한다. 파드를 관리하기 위해 사용되는 워크로드 리소스는 대표적으로 "디플로이먼트", "스테이트풀셋", "데몬셋" 이 있다.

반응형

■ 쿠버네티스 Pod 라이프사이클 

상태	설명
Pending	파드가 k8s 클러스터의 api 서버에 의해 승인되었지만 하나 이상의 컨테이너가 설정되지 않았거나 실행할 준비가 되지 않은 상태이다.
Running	파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되어 적어도 하나 이상의 컨테이너가 실행 중인 상태
Succeeded	파드에 있는 모든 컨테이너가 성공적으로 종료된 상태
Failed	파드 내의 하나 이상의 컨테이너가 실패로 종료된 상태. 컨테이너가  0이 아닌 상태로 종료되거나 시스템에 의해서 종료된 상태
Unknown	파드의 상태를 알 수 없는 경우이며, 주로 API 서버가 파드의 상태를 알 수 없을 때 발생. 일반적인 경우 통신 오류

 

■ 쿠버네티스 Pod 조건 (Condition)

• Pod는 하나의 PodStatus를 가지며 이는 Pod의 상태와 이유를 나타내며, Pod LifeCycle과 달리 동시에 여러 조건을 가질 수 있습니다. 

조건	설명
PodScheduled	파드가 노드에 스케줄된 상태
PodHasNetworking	샌드박스가 성공적으로 생성되고 네트워킹이 구성된 상태
ContainersReady	파드의 모든 컨테이너가 준비된 상태
Initialized	모든 초기화 컨테이너가 성공적으로 완료된 상태
Ready	파드가 요청을 처리할 수 있고, 서비스 제공이 가능한 상태

 

■ 쿠버네티스 컨테이너 상태 

• Kubernetes는 Pod 전체의 단계뿐만 아니라 Pod 내부의 각 컨테이너 상태도 추적합니다. 컨테이너 수명 주기 후크를 사용하면 컨테이너 수명 주기의 특정 지점에서 실행되는 이벤트를 트리거할 수 있습니다.

상태	설명
Waiting	Running 또는 Terminated 상태가 아니면, Waiting 상태이고, Waiting 상태의 컨테이너는 시작을 완료하는 데 필요한 작업을 계속 실행하고 있는 중이다. kubectl 을 사용하면  Waiting 단계에 머물고 있는 이유를 Reason 필드를 통해 알 수 있음.    - ImagePullBackOff - 컨테이너 이미지를 가져오는 데 실패하여 다시 시도하기 전까지 대기 중   - ErrImagePull - 이미지 풀링 중 오류가 발생   - CrashLoopBackOff - 컨테이너가 반복적으로 크래시가 발생하여 재시작 대기 중   - ContainerCreating - 컨테이너가 생성 중이며, 주로 초기화 작업이 진행되고 있는 상태
Running	컨테이너가 정상적으로 실행 중인 상태이며, postStart 훅이 구성되어 있다면 이미 실행되고 완료되었다
Terminated	Terminating 상태의 컨테이너는 실행을 시작한 후 실행이 완료되거나 어떤 이유로 실패한 상태 입니다. 컨테이너에 preStop 후크가 구성되어 있는 경우 이 후크는 컨테이너가 종료됨 상태로 전환되기 전에 실행됩니다.

■ 쿠버네티스 컨테이너 재시작 정책

• Pod의 spec에는 restartPolicy 필드가 있으며 이는 파드의 모든 컨테이너에게 적용된다. 재시작 정책은 Always, OnFailure 및 Never 3가지가 있다.
  1. Always : 컨테이너의 프로세스가 종료되는 종료 코드에 관계없이 컨테이너가 다시 시작 (기본값)
  2. OnFailure : 프로세스가 0이 아닌 종료 코드로 종료되는 경우에만 컨테이너가 다시 시작
  3. Never : 컨테이너는 다시 시작되지 않음.
• 컨테이너 재시작이 반복되면 컨테이너가 종료된 후 컨테이너를 다시 시작하는데 시간이 오래 걸리게 되며 이때 Pod의 상태는 CrashLoopBackOff 또는 NotReady 상태로 표기 됩니다. 컨테이너 실패 마다 10초, 20초, 40초 ... 160초 까지 증가하며 160초 이후에도 실패하게 될 경우 대기 시간은 5분으로 고정 됩니다. 이처럼 대기 시간이 2배로 늘어나는 것을 BackOff 라고 합니다. 

 

■ 쿠버네티스 Pod 생성 / 수정 / 삭제 방법

• 명령적 방법
  
  • kubectl 이라는 CLI를 통해서 파드 생성 / 수정 / 삭제 수행 가능 (CLI가 API를 호출하는 방식)
    
• 선언적 방법
  • yaml 파일을 사용하여 파드 생성 / 수정 / 삭제 수행 가능 
  • 파드 생성: kubectl { create | apply } -f  { yaml 파일 경로 }
    1. apply : 이미 존재하는 리소스를 업데이트하거나 변경할 때 사용하며 변경 된 부분만 적용 됨, 존재하지 않을 경우 생성
    2. create : 명령 즉시 새로운 리소스를 생성하며 이미 존재하는 리소스를 덮어쓰지 않고 새로운 리소스를 만듬
  • 파드 삭제: kubectl delete pod -f { yaml 파일 경로 } 또는 kubectl delete { pod pod-name | pod/pod-name }
• Pod 생성 방법 예제
  • 명령적 방법: kubectl run nginx --image=nginx:1.14.2 --port=80
  • kubectl run nginx --image=nginx:1.14.2 --port=80 --dry-run=client -o yaml > web_nginx.yaml  해당 옵션을 통해 yaml 코드 생성 
  • 선언적 방법: kubectl apply -f nginx.yaml

# 파일명: nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

 

• Pod 삭제 방법 
  • 파드 삭제 요청을 API 서버가 수신하면 etcd 상태 수정 후 kubelet과 endpoint controller에게 전달 
  • kubelet은 파드에 SIGTERM 신호를 내려 새로운 요청을 수신하지 않게 하고, 30초 (terminationGracePeriodSeconds, 기본값) 이후 파드 종료. 30초 이후에도 종료되지 않는다면 SIGKILL 신호를 보내 파드 강제 종료
  • kube-proxy는 외부 서비스를 중단, endpoint controller는 IP 회수 

https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/

---

출처: https://medium.com/@Stardust1201/pod-lifecycle-%ED%8C%8C%EB%93%9C-%EC%83%9D%EB%AA%85%EC%A3%BC%EA%B8%B0-part-1-4a55e3e25395