DevOps/Kubernetes

[K8S] k8s 정리 - (7) Kubernetes Pod (Lifecycle, Probe, Handler)

yubi5050 2022. 9. 9. 04:50

이전 글에서는  Kuberenetes Controller의 종류와 역할에 대해 알아보았다.

https://yubi5050.tistory.com/178

 

[K8S] k8s 정리 - (6) Kubernetes Controller 종류와 역할

이전 글들에서는 Kubernetes 기본적인 Object 들 에 대해 알아보았다. https://yubi5050.tistory.com/177 [K8S] k8s 정리 - (5) Kubernetes Object (Pod, Service, Volume, Namespace) 이전 글들에서는 Kubernete..

yubi5050.tistory.com

 

이번 글에서는 Kubernetes 가장 작은 기본 단위인 Pod의 Lifecycle과 Probe와 Handler의 역할에 대해 자세히 알아보려고 합니다.

 

Pod란?

Pod는 쿠버네티스의 가장 기본적인 배포 단위이다. 그럼 왜 쿠버네틱스에서 단위를 파드로 사용할까? 

 

Pod 구성. 이미지 출처 : https://blog.wonizz.tk/2019/08/19/

 

 

이유는 컨테이너 묶음에 대해 추상화하여 사용하기 위함 

 

예로 한 서비스의 비즈니스 로직을 수행하는 컨테이너 외에 부가적으로 정의된 컨테이너를 사이드카 (Sidecar) 컨테이너들(특정 컨테이너의 설정 파일의 변경사항을 갱신해주는 설정 리로더(reloader) 프로세스 컨테이너 / 로그 수집 컨테이너 등)을 포함한 하나의 구성을 파드라고 추상화 한 것. 물론 Pod는 생성 후, 외부에서 접근할 수 있도록 노출된 상태는 아니며, Service 란 Object가 필요하다.

 

Pod에 대한 생명 주기나, 여러 특징에 대해서는 다른 글에서 다루려고 한다.

 

👉 파드(Pod) 주요 특징

  • 파드라는 단위로 컨테이너를 묶어서 관리
    ex) 외부에서 파드에 접근시 192.168.x.x라는 IP로 접근, 내부 컨테이너의 포트로 접근
  • 파드 내의 컨테이너 끼리는 localhost 통신이 가능
  • Pod 내에 배포된 컨테이너간 디스크 볼륨(emptydir) 공유 가능 
    동일 Pod내 컨테이너들끼리는 볼륨을 공유할 수 있어 애플리케이션의 로그 수집기 적용 가능
  • Docker Container와 Pod Container의 차이는 Docker의 경우 컨테이너별로 IP를 직접적으로 받는 반면, Pod는 한번 wrapping이 되어 상위 (Pod) 에 IP 가 할당이 됨
  • Pod 삭제 후 재생성시 IP가 변동된다 (IP가 가변적인걸 보완하기 위해 Service 를 이용)

 

이미지 출처:https://blog.wonizz.tk/2019/08/19

 

Pod의 생명주기

  • Pending : 쿠버네티스 시스템에 파드를 생성되는 중 (ex. 이미지 다운 받는 중 / 파드 생성 중일 때).
  • Running : 파드 안 모든 컨테이너가 실행중인 상태
  • Succeeded : 파드 안 모든 컨테이너가 정상 실행 된 상태
  • Failed : 파드 안 컨테이너 중 정상적으로 실행 종료되지 않은 컨테이너
  • Unknown : 파드의 상태를 확인 할 수 없는 상태 (ex. 해당 노드와 통신 불가능)

 

Pod의 Self-healing (Kubelet 컨테이너 진단)

Pod가 실행 된 후 kubelet은 Pod 내 컨테이너를 주기적으로 진단하며 상태 (정상 실행 여부, 실패시 자동 컨테이너 종료 후, 재시작)를 확인하는 역할을 한다. 이러한 kubelet의 역할 때문에 Pod가 재시작되도 IP는 변동되지 않으며, Pod가 계속 실행(복구) 할 수 있음을 보장한다.

 

응답 결과로는 Success(성공) , Failure(진단 실패), UnKnown(진단 실패 + 아무런 핸들러 호출 X) 가 있다.

 

Probe란?

컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단으로 livenessProbe, readnessProbe, startupProbe 3개 Probe가 존재하며, kubelet이 컨테이너에 의해 구현된 핸들러를 호출하여 응답 결과를 주기적으로 진단함.

 

👉 1. 활성프로브(livenessProbe)

  • 컨테이너가 동작 중인지 여부 체크
  • 실패시 컨테이너 죽이고 재시작
  • ex) 컨테이너가 이슈나 프로세스 문제로 중단될 경우, 컨테이너가 종료되거나 재시작 되기를 원할 때

 

👉 2. 준비성프로브(readinessProbe)

  • 컨테이너가 서비스 요청에 응답을 할 수 있는 상태인지 체크
  • 상태확인 실패시, 해당 Pod가 연결된 모든 서비스의 엔드포인트 정보 제거
  • ex) 해당 Pod에 제대로 트래픽 전송을 하려는 경우 (대량의 데이터, 설정 파일등)

 

👉 3. startupProbe

  • 컨테이너 내의 애플리케이션이 시작되었는지 체크

 

 

Probe의 Handler

👉 1. httpGet

  • 지정한 IP주소, port, path에 HTTP Get 요청을 보내 확인
  • 해당 Container의 응답 확인 반환코드가 200이 아닌 값이 나오면 컨테이너 재시작
  • 필드 : httpGet: / path: / port:

 

👉 2. tcpSocket

  • 지정된 포트에 TCP 연결을 시도
  • 연결되지 않으면 컨테이너 다시 시작
  • 필드 : tcpSocket: / port:

 

👉 3. exec

  • exec 명령을 전달 (exec : command -ls )
  • 명령의 종료코드가 0이 아니면 컨테이너 재시작

 

👉 기타 필드 (부가 조건 옵션)

  • initialDelaySeconds : 최초 검사 실행 전 대기
  • periodSeconds : x초 interval로 검사
  • timeoutseconds
  • successThreshold : 성공 횟수 기준
  • failureThreshold : 실패 횟수 기준

 

Pod 생성 Probe와 Handler 설정

 

마무리 

이번 글에서는 Kubernetes 가장 작은 기본 단위인 Pod의 Lifecycle과 Probe와 Handler의 역할에 대해 알아보았습니다. 다음 글에서는 Pod의 컨테이너 구성과 리소스 할당, 환경 변수 설정에 대해 알아보도록 하겠습니다.