[CKAD] Kubernetes Pod Lifecycle and Status

Kubernetes Pod Lifecycle, Status & Conditions

Pod Status

Pending (대기)

• Pod가 실행되기 위한 스케줄링이 아직 완료되지 않은 상태입니다. 스케줄러는 사용할 노드를 할당하고 Pod를 실행하기 위한 준비를 합니다.

ContainerCreating (컨테이너 생성 중)

• 해당 Pod에 필요한 컨테이너 이미지가 다운로드되거나 컨테이너가 시작되는 과정입니다. 이미지 pull이 완료되면 컨테이너가 시작됩니다.

Running (실행 중)

• 모든 컨테이너가 성공적으로 실행되고 있으며, 애플리케이션도 실행되고 있는 상태입니다.

Succeeded/Failed (성공/실패)

• Succeeded: 모든 컨테이너가 정상적으로 종료된 상태입니다.
• Failed: 실행 중에 오류가 발생하거나 비정상적인 종료가 발생한 상태입니다.

Pod Conditions

PodScheduled

• 스케줄러가 Pod를 노드에 할당한 상태입니다. 이 상태는 노드가 할당되었음을 나타냅니다.

Initialized

• Pod의 initContainers가 모두 실행 완료되었을 때 표시됩니다. initContainers는 주요 애플리케이션 컨테이너가 실행되기 전에 필요한 작업들을 처리합니다.

ContainersReady

• 모든 주요 컨테이너가 준비가 완료된 상태입니다. 이 상태는 트래픽을 받을 준비가 되었다는 것을 의미합니다.

Ready

• 포드가 트래픽을 처리할 준비가 되었다는 표시입니다. 모든 조건이 만족되면 트래픽을 받을 수 있게 됩니다.

kubectl 명령어

kubectl describe pod 또는 kubectl get pods 명령어를 사용하여 Pod의 상태(Status) 및 조건(Conditions)을 실시간으로 확인할 수 있습니다.

Note: 컨테이너 프로세스 실행이 완료되었다고 해서 애플리케이션이 완전히 준비되었다는 것은 아닙니다. 예를 들어 DB가 켜져 있어도 연결 준비가 완료되기까지 몇 초가 소요될 수 있습니다.

---

Kubernetes Probes

Readiness Probe: 트래픽 받을 준비 여부 확인

애플리케이션이 트래픽을 받을 준비가 되었는지를 판단하기 위한 프로브입니다. 이 프로브가 없으면, 앱이 아직 초기화 중인 상태에서 트래픽이 유입되어 장애가 발생할 수 있습니다.

• 동작: 이 프로브가 실패할 경우, 포드는 Not Ready 상태로 표시되며, 서비스 엔드포인트에서 제외됩니다.
• 검사 방법:
  • HTTP GET: 특정 헬스체크 URL(예: /healthz)에 HTTP GET 요청을 보내 응답을 확인합니다.
  • TCP Socket: 특정 포트가 리스닝 중인지 확인합니다.
  • Exec: 컨테이너 내부에서 커맨드를 실행하여 성공 또는 실패를 확인합니다.
• 주요 옵션:
  • initialDelaySeconds: 애플리케이션이 준비되기까지의 대기 시간
  • periodSeconds: 프로브를 주기적으로 실행하는 시간
  • failureThreshold: 실패할 경우 Not Ready 상태로 전환되기까지의 실패 횟수
  • successThreshold: 성공해야 Ready로 간주되는 최소 성공 횟수

예시:

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

Liveness Probe: 애플리케이션이 살아있는지(정상 동작 중인지) 확인

애플리케이션이 응답이 없거나 Hang 상태인 경우 자동으로 복구하기 위해 사용됩니다.

• 동작: 프로브가 실패하면, 컨테이너가 재시작되어 애플리케이션을 복구합니다.
• 검사 방법: Readiness Probe와 동일한 방법을 사용하여 애플리케이션의 상태를 확인합니다.
• 주요 옵션:
  • initialDelaySeconds: 검사 시작 전의 지연 시간
  • periodSeconds: 프로브 주기
  • failureThreshold: 실패 횟수 기준

livenessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 10
  periodSeconds: 20

Startup Probe: 초기 구동 시간이 긴 애플리케이션 보호

구동 시간이 오래 걸리는 애플리케이션에서 Liveness Probe가 너무 일찍 실행되어 잘못된 실패를 방지할 수 있도록 보호합니다.

• 동작: Startup Probe가 성공할 때까지 Liveness Probe는 실행되지 않으며, 초기 구동 시간이 긴 애플리케이션이 안정적으로 시작될 수 있게 합니다.
• 검사 방법: Readiness/Liveness와 동일한 방식으로 사용됩니다.
• 주요 옵션:
  • initialDelaySeconds: 시작 전 지연 시간
  • periodSeconds: 검사 주기
  • failureThreshold: 실패 횟수 기준

startupProbe:
  exec:
    command: ["cat", "/tmp/ready"]
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 30

Probe 비교

• Readiness Probe: 서비스 트래픽 유입 여부 제어
• Liveness Probe: 애플리케이션이 죽었을 때 자동 복구
• Startup Probe: 구동 시간이 오래 걸리는 애플리케이션 보호

---

Logging in Kubernetes

Docker에서의 로깅

• 로그 확인:
  • docker logs <container_id>: 컨테이너 로그 출력
  • docker logs -f <container_id>: 실시간 스트리밍

Kubernetes에서의 로깅

• 로그 확인:
  • kubectl logs <pod_name>: Pod 로그 출력
  • kubectl logs -f <pod_name>: 실시간 스트리밍
• 다중 컨테이너 Pod:
  • kubectl logs <pod_name> -c <container_name>로 특정 컨테이너 지정 필요

기본 로깅 vs 중앙집중식 로깅

기본 로깅은 간단하고 빠르지만 로그가 손실될 수 있습니다. 중앙집중식 로깅 솔루션(ELK, Loki 등)은 대규모 환경에서 장기적인 분석을 제공하지만, 구축과 운영이 복잡합니다.

---

Monitoring Kubernetes

모니터링 항목

노드 레벨 지표

• 클러스터 내 노드 수와 정상 노드 개수
• CPU, 메모리, 네트워크, 디스크 활용도

포드 레벨 지표

• 현재 클러스터 내 포드 개수
• 각 포드의 CPU 및 메모리 사용량

Kubernetes 내장 모니터링 한계

Kubernetes는 자체적인 모니터링 솔루션을 제공하지 않으며, 오픈소스 또는 상용 솔루션을 추가로 사용해야 합니다.

---

주요 모니터링 솔루션

• Metrics Server: 설치가 간단하며 kubectl top 명령어로 리소스를 확인할 수 있습니다. 장기 데이터 저장은 불가합니다.
• Prometheus: 시계열 데이터를 관리하며, 강력한 쿼리 언어 PromQL을 지원합니다. Grafana와의 연동이 가능합니다.
• Elastic Stack (ELK): Elasticsearch, Logstash, Kibana를 사용하여 로그 및 메트릭을 통합 분석할 수 있습니다.
• Datadog: 빠른 구축과 다양한 통합을 지원하는 클라우드 기반 APM 및 모니터링 서비스입니다.
• Dynatrace: 엔터프라이즈급 자동 계측 및 AI 기반 분석을 제공합니다.