[Kubernetes] 파드 라이프 사이클과 Probe(liveness, readiness, startup)

파드(pod)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.

파드는 하나 이상의 컨테이너로 구성되어 있다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

 

일반적으로 파드는 직접 생성하지 않고, 워크로드 리소스(디플로이먼트, 레플리카셋 등)를 사용하여 생성한다.

실제로 운영 환경에서는 애플리케이션을 단일 파드로 운영하는 경우가 거의 없기 때문이다.

 

파드는 기본적으로 파드에 속한 컨테이너에 네트워킹과 스토리지라는 두 가지 종류의 공유 리소스를 제공한다.

워크로드 리소스를 통하여 여러 파드를 만들고 관리 가능한데, 리소스에 대한 컨트롤러는 파드 장애 시 복제 및 롤아웃과 자동 복구를 처리한다.

EX) 노드 실패 → 컨트롤러는 해당 파드에 문제가 생겼음을 인식하고 대체 파드 생성 → 스케줄러는 대체 파드를 정상 노드에 배치

 

파드는 정의된 라이프 사이클이 존재하며 이를 따른다.

우선 파드는 수명 중 한 번만 스케줄링된다. 즉, 한번 노드에 할당되면 중지되거나 종료될 때까지 해당 노드에서 실행된다. 그래서 만약 노드가 실패하면 파드는 삭제된다. 또한 리소스 부족이나 노드 유지로 인한 evict이 된다.

 

파드의 단계

파드의 phase는 파드가 라이브 사이클 중 어느 단계에 해당하는지 표현한다.

• Pending
  • 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다.
    여기에는 파드가 스케줄 되기 이전까지의 시간뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다.
• Running
  • 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다.
• Succeeded
  • 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다.
• Failed
  • 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
• Unknown
  • 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 보통 노드와의 통신 오류인 경우 해당한다.

 

파드의 컨디션

파드는 하나의 PodStatus를 가진다. kubelet은 다음 PodConditions를 관리한다.

• PodScheduled: 파드가 노드에 스케줄 되었다.
• PodHasNetwork: (알파 기능; 반드시 명시적으로 활성화해야 함) 샌드박스가 성공적으로 생성되고 네트워킹이 구성되었다.
• ContainersReady: 파드의 모든 컨테이너가 준비되었다.
• Initialized: 모든 초기화 컨테이너가 성공적으로 완료(completed)되었다.
• Ready: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드 밸런싱 풀에 추가되어야 한다.

 

파드의 종료

파드는 클러스터 노드에서 실행되는 프로세스로 정상적으로 종료되는 것이 중요하다.

kubectl을 이용하여 파드 삭제 시에, 일반적으로 30초 이내에 삭제가 정상적으로 이루어진다. (default 유예 기간)

이 기본 값은 --grace-period=<seconds> 옵션으로 수정 가능하다.

kubectl delete pod <pod-name> --grace-period=<seconds>

만약 강제 삭제를 수행해야 한다면, 다음과 같이 작성해야 한다. (kubelet의 확인 없이 api에서 즉시 삭제)

kubectl delete pod <pod-name> --grace-period=0 --forece

 

컨테이너

파드 안에는 1개 이상의 컨테이너가 존재하는데, 쿠버네티스는 파드의 상태뿐만 아니라 컨테이너의 상태도 추적한다.

아래 명령어로 통하면 파드 내의 컨테이너 상태를 확인할 수 있다.

kubectl describe pod <name-of-pod>

 

컨테이너 상태

• Waiting
  • Running과 Terminated 상태가 아닌 상태
  • 컨테이너 이미지를 가져오거나 시크릿 데이터 적용과 같은 시작에 필요한 작업을 실행하는 상태
  • kubectl을 사용하여 파드 쿼리 시에 해당 상태에 있는 이유를 요약하는 Reason 필드도 표시
• Running
  • 컨테이너가 문제없이 실행되고 있음을 나타내는 상태
  • kubectl을 사용하여 파드 쿼리시에 Running 상태에 진입한 시기에 대한 정보 확인 가능
• Terminated
  • 완료될 때까지 정상적으로 실행되었거나 실패한 상태
  • kubectl을 사용하여 파드 쿼리시에 이유와 종료 코드 그리고 시간 정보를 확인 가능

 

컨테이너 재시작 정책

파드의 spec에는 restartPolicy 필드가 있으며, 사용 가능 값은 다음과 같다.

apiVersion: v1
kind: Pod
metadata:
  name: on-failure-example
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: nginx:1.14.2

• Always (기본 값)
  • 파드의 컨테이너가 종료되면 항상 다시 시작
• OnFailure
  • 파드의 컨테이너가 실패한 경우에만 다시 시작
• Never
  • 컨테이너가 종료되더라도 다시 시작하지 않음

restartPolicy는 해당 파드에 속한 모든 컨테이너에 적용된다.

 

컨테이너 프로브(probe)

컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단으로, kubelet이 컨테이너 안에서 코드를 실행하거나 네트워크 요청을 전송한다.

 

kubelet은 상태 진단을 위해 핸들러를 호출하는데 ExecAction(컨테이너 지정 명렁), TCPAction(TCP 소켓 연결), HttpGetAction(http 요청)의 총 3가지의 핸들러가 존재한다.

 

프로브 종류는 다음과 같다.

• livenessProbe
  • 컨테이너가 동작 중인지 여부를 나타낸다.
  • Pod는 정상적으로 Running이지만, 애플리케이션에 문제가 생겨서(ex: OOM) 정상 동작하지 않는 경우 감지한다.
  • 실패 시에 컨테이너를 죽이고, 재 시작 정책(restartPolicy)에 따라 처리된다.
• readinessProbe
  • 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
  • 초기 로딩 시간으로 인한 애플리케이션 요청 처리가 불가 할 수 있는 경우
  • 실패 시에 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP 주소를 제거한다.
    livenessProbe는 fail시에 재시작 정책에 따라 재시작 되지만, readiness probe는 서비스로 부터 pod를 제외 시킨다.
• startupProbe
  • 컨테이너 내의 애플리케이션이 시작되었는지 나타낸다.
  • 해당 프로브가 주어진 경우 성공 시까지 나머지 프로브를 활성시키지 않는다.
  • 실패 시에 컨테이너를 죽이고, 재 시작 정책에 따라 처리된다.

각 프로브의 결과는 다음 세 가지 결과 중 하나를 가진다.

• Success
  • 컨테이너가 진단 통과
• Failure
  • 컨테이너가 진단에 실패
• Unknown
  • 진단 자체가 실패

Probe는 어느 경우에 사용될까?🤔

• livenessProbe
  •  컨테이너의 상태가 unhealty한 경우
  • restartPolicy에 따라 kubelet이 정상적으로 처리(재시작)를 할 수  있기 때문에 필수적은 아니다.
• readinessProbe
  • 웹 서버와 같이 요청을 받을 수 있는 상태에 트래픽 전송이 되어야 하는 경우
• startupProbe
  • 애플리케이션 기동에 시간이 오래 걸리는 경우

한 가지 예로, pod 내부적으로 컨테이너 기동에 시간이 소요되는 경우가 있다고 가정하자.

이 경우에 Rolling Update 시에 파드 내에 컨테이너가 기동 되는 시간만큼 다운 타임이 발생할 수 있다.

이런 경우에는 probe 설정을 하면 새로 뜬 Pod의 readinessProbe 설정 만족 시까지 기존 Pod를 Terminated 시키지 않기 때문에 다운 타임을 방지할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-example
  template:
    metadata:
      labels:
        app: probe-example
		spec:
		  containers:
		  - name: web-server # 컨테이너 구동에 시간이 소요되는 서버
		    .. 생략 ... 
			readinessProbe:
				httpGet:
			      path: /
			      port: 8080
			    initialDelaySeconds: 30
			    periodSeconds: 10

 

[참고 자료]

- 쿠버네티스 공식 문서

https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

파드 라이프사이클

 

- kubernetes Pod의 진단을 담당하는 서비스 : probe