Pod 라이프사이클
Kubernetes를 통해 애플리케이션을 배포하면 Pod가 생성된다.
Pod는 Kubernetes에서 정의된 라이프사이클을 따르며, 생성시 Pending 단계에서 시작하여 Running 단계를 통과하고 Success 또는 Failed 단계로 이동한다.
Pod가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시 시작할 수 있으며, Pod 내에서Kubernetes는 다야안 컨테이너 상태를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를 결정한다.
모든 Pod들은 각각 고유한 UID를 가지며, 동일한 UID를 가진 Pod들은 단 한번만 스케줄된다.
Pod의 수명 단계
위의 Pod의 라이프사이클을 도식화하면 아래의 그림과 같다.
각 단계는 다음과같은 상태를 의미한다.
| 라이프사이클 | 설명 |
|---|---|
| Pending | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지의 다운로드 시간도 포함된다. |
| Running | 파드가 노드에 바인딩 되었고, 모든 컨테이너가 생성 되었다. 적어도 하나의 컨테이너가 아직 실행중이거나, 시작 중 또는 재시작 중에 있다. |
| Succeeded | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작 되지 않을 것이다. |
| Failed | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. |
| Unknown | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. |
추가적으로 노드가 죽거나 클러스터와의 연결이 끊길 경우, 쿠버네티스는 손실된 노드의 모든 Pod의 phase를 Failed로 변경한다.
Pod 생성 실습
Pod의 생명주기를 CLI 화면을 통해서 확인하기 위해서는 아래의 명령어를 활용해볼 수 있다.
$ kubectl get pod -o wide --watch
$ kubectl run nginx --image nginx
위의 그림은 nginx pod를 배포하고 그 pod가 어떻게 생성되는지를 관찰한 터미널 화면이다.
일련의 순서를 보면 다음과 같다.
- Pod를 조회할 수 있고 Pending 상태가 된다.
- Pod가 어느 Node에 스케줄링 될지 결정된다
- ContainerCreating 상태로 변경된다.
- Running 상태로 변경된다.
위의 Pod는 Job 또는 Cronjob이 아니기 때문에 제거되기 전까지 Running 상태를 유지하게 될 것이다.
Pod 컨디션
Pod는 하나의 PodStatus를 가지며, PodStatus는 파드가 통과했거나, 통과하지 못한 Pod 컨디션 배열을 가진다.
이 Pod컨디션들은 kubelet이 관리하며 종류는 아래와 같다.
| 라이프사이클 | 설명 |
|---|---|
| PodScheduled | 파드가 노드에 스케줄되었다 |
| PodHasNetwork | (알파 기능; 반드시 명시적으로 활성화해야 함) 샌드박스가 성공적으로 생성되고 네트워킹이 구성되었다. |
| ContainersReady | 파드의 모든 컨테이너가 준비되었다. |
| Initialized | 모든 초기화 컨테이너가 성공적으로 완료(completed)되었다. |
| Ready | 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드 밸런싱 풀에 추가되어야 한다. |
이제 아래 명령어를 통해 nginx pod의 상태를 확인해보자.
$ kubectl get pod -o yaml nginx
위 명령어를 수행하면 위와 같은 화면을 확인할 수 있다.
이를 통해 해당 Pod가 생성되는 과정에서 언제 어떤 작업이 완료되었는지(status=true) 완료되지 않았다면(status=false) 왜 완료되지 않았는지(reason)를 확인할 수 있다.
