[Kubernetes] Pod - LifeCycle

Kubernetes

 

오랜만에 K8s 공부를 다시 시작했다. 인프런의 일프로님의 강의를 보며 학습을 이어간다.

 

거두절미하고 Pod의 라이프사이클에 관해 정리한 내용을 포스팅하려 한다.

 

Pod - LifeCycle

Pod에는 라이프사이클이 존재하고 어떤 Pod든 생성되고 사라지기까지 일정한 단계를 거치게 된다.

 

그리고 Pod 라이프사이클의 특징은 각 단계에 따라 행해지는 행동이 다르기에 라이프사이클에 대해 잘 알아야 한다.

 

Pod 라이프사이클 핵심 간단 정리

• Pending
  • ReadinessProbe
  • Policy
• Running
  • LivenessProbe
  • Qos
• Succeeded
  • Policy
• Failed
• Unknown

 

아래 사진은 Pod의 라이프사이클과 관련 요약이라고 생각하면 편할 것이다.

일프로님의 강의 PDF

 

 

Pending -> Running -> Succeeded & Failed

일프로님의 강의 PDF

 

Pending

Pod의 최초 상태는 Pending이고 이 상태 일 때 Pod 안에서는 어떤 일들이 일어날까?

1. Pod가 어드 노드 위에 올라갈지를 판단한다.
   • 직접 노드를 지정했을 때는 지정한 노드로 올라감
   • Kubernetes가 알아서 자원의 상황을 판단해서 노드를 결정
   • 위의 작업이 완료되면 PodScheduled 는 True 가 된다.
2. 다음에는 본 컨테이너가 기동되기 전에 초기화 시켜야 하는 내용들을 초기화 해주는 initContainer가 기동된다.
   • 볼륨이나 보안 세팅을 위해 사전 설정을 해야 되는 일이 있을 경우
   • Pod 생성 내용안에 initContainer라는 항목으로 초기화 스크립트를 넣을 수가 있다.
   • 이때, 해당 스크립트가 본 컨테이너보다 먼저 실행이 돼서 초기화 작업이 성공적으로 끝났거나
     또는, 아예 설정을 하지 않았을 경우 True 그리고 실패를 하게 되면 False 가 된다.
3. 컨테이너의 이미지를 다운로드 한다.
   • PodScheduled와 이미지 다운로드 동작 동안에 컨테이너의 상태는 Waiting 이며, reaseon 은 ContainerCreating 이다.
4. 그 후, 본격적으로 컨테이너가 기동되면서 Pod와 컨테이너의 상태는 Running이 된다.

 

Running

본격적으로 Pod와 컨테이너가 기동이 된 상태를 Running 상태라고 한다.

 

근데 정상적으로 기동이 될 수도 있지만, 하나 또는 모든 컨테이너가 기동 중에 문제가 발생되어 재시작될 수도 있다.

 

그럼 이때, 컨테이너의 상태는 Waiting이 되고 reason은 CrashLoopBackOff가 된다.

(해당 메시지는 아마 쿠버네티스를 하면 종종 보게 된다고 하니 알아두면 좋을 것 같다.)

 

Pod는 컨테이너의 이러한 상태들에 관해 Running이라고 간주를 한다.

• 하지만, 내부 Conditions의 ContainerReady 와 Ready 의 상태값을 False 값을 갖게 된다.
• 이후, 결국 모든 컨테이너들이 정상적으로 기동이 되어 원할하게 돌아간다면 Conditions들은 모두 True로 변경이 된다.

그래서, 일반적으로 계속 서비스가 운영이 돼야 하는 경우에 ContainerReady와 Ready의 값은 True 라는 Status를 계속 유지해야 한다.

 

중요한 점

 

그렇기에 Pod의 상태가 Running 이더라도 내부 컨테이너들의 상태가 Running이 아닐 수도 있기에

Pod뿐만 아니라 컨테이너의 상태도 모니터링 해줘야 한다.

 

 

Succeeded & Failed

Job이나 CronJob으로 생성된 Pod의 경우 자신의 일을 수행했을 때는 Running 중이지만,

일을 마치게 되면 Pod는 더 이상 일을 하지 않는 상태가 된다.

 

여기서 Pod의 상태는 Failed 나 Succeeded 이렇게 두 가지로 갈릴 수 있다.

 

• 만약, 작업을 하고 있는 컨테이너 중에 하나라도 문제가 생겨서 에러가 발생하면 Pod의 상태는 Failed가 된다.
• 만약, 컨테이너들이 모두 Completed로 해당 일들을 잘 맞췄을 때 Succeeded 가 된다.

 

이때, 또 Pod의 Conditions 값이 변하게 되는데 성공이건 실패건 간에
ContainerReady 값과 Ready의 값이 False 로 바뀌게 된다.

 

추가적인 케이스로 Pending 중에 바로 Failed로 빠지는 경우도 있고,

 

Pending이나 Running 중에 통신 장애가 발생하면 Pod 가 Unknown 상태로 바뀌는데

 

통신 장애가 빨리 해결이 되면 다시 기준 상태로 변경이 되지만, 계속 지속되면 Failed로 가기도 한다.

 

 

아래는 Job을 사용하는 경우와 CronJob을 사용하는 경우를 나름 분리해본 것이다.

Job을 사용하는 경우

• 한 번 실행하고 끝나는 작업이 필요할 때 사용

Job 사용 예시

1. 배치 작업
   • 한 번 실행한 후 종료되는 데이터 처리 작업
   • 예: 특정 시간에 생성된 데이터를 분석 후 저장
2. 데이터베이스 마이그레이션
   • 새로운 버전으로 업데이트할 때 데이터 스키마 변경
3. 파일 처리
   • 특정 파일을 다운로드하고, 압축을 해제한 후 저장
4. 일회성 백그라운드 작업
   • 사용자가 특정 요청을 했을 때 실행되는 비동기 작업
   • 예: 사용자가 요청한 리포트를 생성 후 이메일로 전송

CronJob을 사용하는 경우

• 일정 주기마다 반복 실행이 필요한 작업에 사용

CronJob 사용 예시

1. 정기적인 데이터 백업
   • 매일 새벽 3시에 DB를 백업하는 작업
2. 로그 정리 및 아카이빙
   • 특정 기간이 지난 로그 파일을 정리
3. 주기적인 API 요청
   • 5분마다 특정 API를 호출하여 데이터를 동기화
4. 정기 리포트 생성
   • 매주 금요일에 자동으로 리포트 생성 후 이메일 전송

 

요약

Job은 단발성 작업, CronJob은 정기적인 반복 작업