🧊 Kubernetes Pod 동작 원리 정리

1. Pod의 네트워크 및 자원 공유 원리

Pod는 단순히 컨테이너 묶음이 아닌 공유된 Linux Namespace + Volume 위에서 실행되는 컨테이너의 집합이다.

- Pause Container (Infra Container)

Pod 생성 시 가장 먼저 실행되는 컨테이너로 Pod의 Network Namespace를 생성하고 유지하는 역할을 한다.

생성 과정은 다음과 같다.

1. Container Runtime이 Network Namespace 생성
2. Pause 컨테이너가 해당 Namespace에 attach (anchor 역할)
3. 이후 모든 앱 컨테이너가 해당 Namespace에 join

모든 컨테이너가 동일한 Network Namespace를 사용하기 때문에 동일한 IP를 공유하며 localhost로 컨테이너 간 통신이 가능하다.

이는 앱 컨테이너가 재시작 되는 경우에도 Pause 컨테이너가 Network Namespace를 유지하기 때문에 Pod IP는 유지된다.

- Pod 내부 Namespace 공유

k8s는 Linux Namespace를 활용해 Pod 내부 컨테이너를 격리한다. 하지만 동일 Pod 내부에서는 일부 namespace를 공유한다.

• Network (공유)
  동일 IP
• UTS (공유)
  hostname 공유
• IPC (공유)
  프로세스 간 통신
• PID (기본 비공유)
  옵션으로 공유 가능
• Mount (비공유)
  파일 시스템 분리

PID namespace는 기본적으로 공유되지 않지만 다음 설정을 통해 공유할 수 있다.

shareProcessNamespace: true

이 설정을 사용하면 컨테이너 간 프로세스를 확인할 수 있다.

또한 컨테이너 간 파일 시스템은 기본적으로 격리되며 데이터 공유는 반드시 Volume을 사용해야한다.

2. Init Container 실행규칙

Init Container는 주 앱 컨테이너가 실행되기 전, 필요한 환경을 논리적으로 분리하여 초기화하는 컨테이너이다. 주요 용도는 데이터 다운로드, DB 마이그레이션, 설정 파일 생성, 외부 서비스의 가용성 확인 등이 있다.

Init Container는 순차적으로 실행된다. 중간에 하나라도 실패하면 Pod는 시작되지 않으며 모든 Init Container가 성공해야 앱 컨테이너가 실행된다.

YAML에 정의된 순서대로 하나씩 실행되며 이전 Init 컨테이너가 성공(Exit Code 0)해야만 다음 Init 컨테이너가 실행된다. 하나라도 실패할 경우 Pod의 restartPolicy에 따라 전체 Pod가 재시작되거나 실행이 중단된다. 즉 모든 Init 컨테이너가 성공해야만 앱 컨테이너가 시작된다.

일반적인 Init 컨테이너는 종료를 전제로 하므로 Liveness, Readiness Probe를 지원하지 않는다. 오직 종료 코드로만 성공 여부를 판단한다.

단 k8s 1.29 이후에는 restartPolicy: Always가 설정된 Init 컨테이너의 경우 앱 컨테이너와 함께 계속 실행되는 사이드카 역할을 수행하므로 이 경우에 한해 Readiness Probe를 사용할 수 있으며, 해당 프로브가 성공해야 다음 단계로 진행된다.

Pod 스케줄링 시 리소스 계산은 다음과 같은 식을 따른다.

Effective Request = max(
  max(init containers),
  sum(app containers)
)

3. Pod Lifecycle & Probes

Pod의 상태는 내부 컨테이너 상태와 Probe 결과에 따라 결정된다. 컨테이너는 다음 세 가지 상태 중 하나를 가진다.

1. Wating
컨테이너가 실행 준비 중인 상태를 의미한다. 이미지 다운로드, 시크릿 로딩 등이 있다.

2. Running
컨테이너 프로세스가 정상 실행 중인 상태를 의미한다.

3. Terminated
프로세스가 종료된 상태를 의미한다. 정상 종료, 실패 종료

- Probes (상태 확인 메커니즘)

k8s는 애플리케이션 상태를 확인하기 위해 Probe를 사용한다.

• Startup Probe
  초기 기동 확인을 위해 사용하며 실패 시 컨테이너를 재시작한다. 성공 전까지 Liveness/Readiness 비활성화한다.
• Liveness Probe
  애플리케이션 상태 확인을 위해 사용하며 실패 시 컨테이너를 재시작한다.
• Readiness Probe
  트래픽 수신 가능 여부 확인을 위해 사용하며 실패 시 서비스 엔드포인트를 제외한다.

흔히 오해하기로 Pod Phase가 Running이면 서비스 가능 상태라고 생각하지만 실제 트래픽 유입 여부는 Readiness Probe 통과 여부에 달려 있다.

즉, Readiness Probe가 실패하면 Pod는 실행 중이어도 Service Endpoint에서 제외된다.

4. Pod Termination (종료 과정)

Pod 삭제 시 k8s는 트래픽 차단과 graceful shutdown을 동시에 진행한다.

1) Terminating 상태 변경 및 엔드포인트 제거

API Server가 Pod를 Terminating으로 변경한다. 이와 동시에 엔드포인트 컨트롤러는 서비스 목록에서 해당 Pod IP를 제거하여 새로운 트래픽 유입을 차단한다. (이 과정은 비동기적으로 전파된다.)

2) preStop Hook 실행

Kubelet은 컨테이너에 정의된 preStop 명령을 내린다. 주로 진행 중인 요청의 처리를 마무리하거나 DB 연결을 안전하게 닫는 데 사용된다.

3) SIGTERM 신호 전송

preStop 작업이 끝나면 Kubelet이 메인 프로세스(PID 1)에 SIGTERM을 보내 애플리케이션의 정상 종료를 유도한다.

4) Grace Period 대기

설정된 시간(기본 30초) 동안 프로세스가 종료되기를 기다린다.

terminationGracePeriodSeconds: 30

5) SIGKILL 강제 종료

대기 시간이 지나도 프로세스가 살아있으면 SIGKILL을 보내 강제로 종료하고, 최종적으로 API Server가 Pod 정보를 삭제한다.