Kubernetes Pod Lifecycle / container, pod, 수명주기, 관리

Kubernetes Pod Lifecycle

---

Cloud native한 container app은 스스로 lifecycle을 제어하기보단 Kubernetes와 같은 ochestration tool에 의해 lifecycle이 관리됨

관리플랫폼에 의해 이벤트를 받고, 응답하며 조절

Liveness probe, Readiness probe 와 연계되어 container의 상태를 Kubernetes가 알 수 있고, 정책이나 외부요인에 따라 시작이나 중지가 될 수 있음

어떻게 처리가 되는지는 각 container에 따라 미리 정의해둔 명세에 의해 동작을 함

추가로 probe 상태에 관계없이 따로 동작할 수도 있음

 

대표적으로 Kubernetes에서 제공하는 관리기능은 대표적으로 PreStop Hook, PostStart Hook, SIGTERM, SIGKILL 가 있음

이렇게 Kubernetes에서 제공하는 이벤트를 사용할 수도 있고, 아니면 다른 이벤트를 통해 관리할 수도 있음

Kubernetes Container Lifecycle

제공되는 기능은 이벤트이름과 동일하다고 보면 됨

  - PostStart Hook

말 그대로 컨테이너가 생성된 후 실행 됨

Container Process와 비동기적으로 실행

PostStart Hook이 완료되기 전까지는 Container는 Waiting, Pod는 Pending상태로 유지됨

PostStart Hook에 문제가 생긴다면, Container가 죽음

재시도가 되지 않고, 병렬로 실행되는 것에 유의할 필요가 있음

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - image: ~~
    name: ~~
    lifecycle:
      postStart:
        exec:
          command:
            - ls
            - sleep 30 && echo "test" > /tmp/test

PostStart hook 예시, 이외에도 httpGet등의 기능을 사용 가능

  - PreStop Hook

Container가 종료되기 전 실행

정상적으로 app을 종료시키기 위해 사용

앞서 그린 Container lifecycle에서 보인 것 처럼 SIGTERM이 Container 삭제를 호출하여 시작하기 전 완료되어야 함

PreStop에서 실패가 되더라도 Container가 삭제되는 것을 막을 순 없고, App의 정상종료 관리를 위한 기능

앞서 PostStart에서 lifecycle부분만 변경하면 사용 가능

...
    lifecycle:
      preStop:
        httpGet:
          port: 8080
          path: /pre-stop-test

  - SIGTERM

Kubernetes에서만 쓰지 않고 범용적으로 사용되는 SIG중 하나라서 익숙

Container를 멈추기 위해 사용되는 신호

SIGKILL전에 정상적으로 종료를 준비할 수 있도록 신호를 보내주는 것

일부 app은 이미 들어온 요청에 대한 처리가 필요할 수 있기 때문에 진행중인 요청을 처리하고 종료하기 위해 사용

외에도 임시파일을 지우거나 연결을 해제

대표적으로 nignx에서의 keep-alive설정이 되어있을 때 연결 해제가 필요한 것과 같은 상황

  - SIGKILL

SIGTERM 신호 수신 후 일정 유예시간을 가진 뒤 강제로 종료해주는 신호

Default설정으로는 SIGTERM이후 30초의 대기시간을 가짐

.spec.terminationGracePeriodSeconds 필드로 Pod마다 설정시간 변경 가능

 

왜 PreStart Hook은 존재하지 않는거지? 라는 생각을 하고 있다면 Init Container가 그 기능을 제공한다고 보면 됨

https://dev-chicken.tistory.com/29

Init Container / Kubernetes Pattern, 초기화 컨테이너, 이닛 컨테이너, 패턴

Init Container에서 해당 기능을 제공하고 있어서 따로 Hook으로 관리되지 않음

Init Container는 Pod level에서 관리기능을 제공하고 있기 때문에 차이를 알고 적절하게 사용할 필요가 있음

보통 Init Container에서 더 다양하고 많은 기능을 제공하고, 순차적 작업 보장, 컨테이너 재사용등의 특징이 있음

 

Kubenetes Pod Phase

---

Lifecycle에서 중간중간 Pod의 Phase를 파악할 필요가 있음

status를 통해 상태를 확인하고 어느 Phase에 있는지 확인 가능

Status	뜻
Pending	Kubernetes에서 Pod를 확인였지만, Container가 모두 준비되지 않은 상태 스케줄링 시간, Image pull되는 시간등이 포함 taint나 affinity와 같은것들을 통해 schedule될 node가 없을 때도 Pending상태로 남음
Running	Pod가 Node에 binding되었고 container가 모두 생성된 상태(시작, 재시작 포함)
Succeeded	Pod의 모든 Container가 성공적으로 종료된 상태
Failed	모든 Container가 종료되었지만, 하나 이상의 Cotainer가 실패로 종료된 상태 exited, terminated와 같은 상태의 Container가 존재
Unknown	Pod의 상태를 얻을 수 없을 때, 보통 network 문제로 발생함

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

 

보통

kubectl get pod -o wide(IP, NODE, READINESS GATES등의 추가정보 확인 가능 옵션) 
kubectl describe pod {{pod-name}}

명령어를 사용하여 상태와 event들을 확인

$ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
chicken-dev-test                    1/1     Running   0          24m

$ kubectl describe pod chicken-dev-test
Name:         chicken-dev-test
Namespace:    chicken-dev-test
Priority:     0
Node: ...
...
Events: #하단의 event 확인
  Type     Reason               Age              From               Message
  ----     ------               ----             ----               -------
  Normal   Scheduled            7s               default-scheduler  Successfully assigned ...
...