🧊 Kubernetes Pod 동작 원리 정리

1. Pod란?

Pod는 쿠버네티스가 생성하고 관리하는 가장 작은 배포 단위이다. 하나의 Pod 안에 있는 컨테이너들은 다음을 공유한다.

• 네트워크 네임스페이스: 같은 IP를 갖고 `localhost`로 서로 통신한다. 같은 포트를 두 컨테이너가 동시에 점유할 수는 없다.
• 스토리지 볼륨: Pod에 정의된 볼륨을 모든 컨테이너가 마운트할 수 있다.
• 생명 주기와 스케줄링 단위: 항상 같은 노드에 함께 스케줄링되고, 시작과 종료 또한 함께 이뤄진다.

Pod에는 컨테이너가 하나만 있을 수도, 여러 개가 있을 수도 있다. 보통은 1 Pod = 1 컨테이너가 기본이고, 여러 컨테이너를 하나의 Pod에 두는 것은 sidecar, init container 같은 특정 패턴에서만 사용한다.

2. Pod YAML 구조

쿠버네티스의 모든 리소스는 YAML(또는 JSON) 매니페스트로 선언한다. Pod도 다음 네 개의 최상위 필드로 이루어진다.

• apiVersion: 리소스가 속한 API 그룹과 버전으로, Pod는 코어 API 그룹에 속해 `v1`을 지정한다.
• kind: 리소스의 종류로 Pod의 경우 `Pod`를 지정한다.
• metadata: 리소스를 식별하기 위한 정보로, 같은 namespace 안에서 `name`은 유일해야 한다.
• spec: 이 Pod가 어떻게 동작해야 하는지에 대한 선언적 명세를 기술한다.

.yaml 예시

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

주요 필드의 의미는 다음과 같다.

• metadata.name: namespace 내에서 Pod를 식별하는 이름으로, DNS-1123 subdomain 규칙을 따라야 한다. (소문자 / 숫자 / `-`, 시작과 끝은 영숫자)
• metadata.labels: 임의의 key-value 쌍으로, 다른 리소스가 이 Pod를 찾을 때 매칭 키로 사용된다.
• spec.containers: Pod를 구성하는 컨테이너 목록으로, 컨테이너가 하나여도 -로 시작한다.
• spec.containers[].image: 사용할 컨테이너 이미지로, 운영 환경에서는 명시적 태그를 권장한다.
• spec.containers[].ports: 컨테이너가 listen 중인 포트를 선언한다. 이 필드 자체가 외부에 포트를 여는 것은 아니며, 나중에 Service 리소스를 통해 외부에 노출할 수 있다.

3. Pod 기본 명령어 (kubectl)

작성한 매니페스트를 클러스터에 반영하고 상태를 확인해보자.

kubectl apply -f - 매니페스트 적용

kubectl apply -f pod.yaml

• apply는 선언적 명령어다. 매니페스트의 정의된 상태와 클러스터의 현재 상태를 비교해 차이점만 반영한다.
• 멱등하다. 즉, 같은 파일을 여러 번 apply 해도 결과는 같다. 이미 존재하는 리소스라면 변경된 부분만 갱신된다.
• 비슷한 명령어로 kubectl create -f가 있지만, create는 리소스가 이미 존재하면 에러를 반환한다.

kubectl get pods - 리소스 조회

kubectl get pods                   # 현재 namespace의 모든 Pod
kubectl get pods nginx-pod         # 특정 Pod 하나
kubectl get pods -o wide           # IP, 노드 정보까지 포함
kubectl get pods -A                # 모든 namespace 조회
kubectl get pods nginx-pod -o yaml # spec과 status 전체

기본 출력은 다음과 같다.

NAME         READY   STATUS    RESTARTS   AGE
nginx-pod    1/1     Running   0          3m

• READY: (Ready 상태인 컨테이너 수) / (전체 컨테이너 수). readiness probe가 성공한 컨테이너만 Ready 상태가 된다.
• STATUS: Pod의 상태를 나타내는 값으로, Pending, Running, Succeeded, Failed, Unknown 중 하나의 값을 가진다.
• RESTARTS: kubelet이 컨테이너를 재시작한 횟수로, 컨테이너가 비정상 종료될 때마다 증가한다.

Pod IP 확인

Pod에는 클러스터 내부에서 라우팅 가능한 고유한 IP가 할당된다. (구체적인 IP 대역은 CNI 플러그인 설정에 따라 결정된다.)

kubectl get pods nginx-pod -o wide 
# NAME         READY  STATUS   ... IP          NODE   
# nginx-pod    1/1    Running  ... 10.244.1.5  worker-1

이 IP는 휘발성으로, Pod가 재시작되거나 다른 노드로 옮겨가면 바뀌게 된다. 따라서 Pod IP를 다른 곳에서 직접 참조해선 안 되며, 안정된 엔드포인트가 필요하다면 Service 같은 추상화된 리소스를 사용해야 한다.

kubectl delete - 리소스 삭제

kubectl delete pod nginx-pod # 이름으로 삭제
kubectl delete -f pod.yaml   # 매니페스트로 삭제

apply로 생성한 리소스는 같은 매니페스트로 delete -f 명령을 실행하는 것이 안전하다. 매니페스트에 정의된 모든 리소스가 한 번에 정리되기 때문이다.

삭제 시 즉시 종료가 아닌, graceful termination 절차를 거친다.

1. kubelet이 컨테이너의 PID 1 프로세스에 SIGTERM을 보낸다.
2. terminationGracePeriodSeconds (기본값 30초) 동안 기다린다. 이 시간 안에 프로세스가 정상 종료돼야 한다.
3. 시간이 지나도 종료되지 않으면 SIGKILL로 강제 종료한다.

이 메커니즘 덕분에 애플리케이션은 진행 중인 요청을 마무리하고 리소스를 정리할 시간을 확보할 수 있다.

--grace-period=0 --force 옵션으로 즉시 종료 할 수도 있지만, 데이터 유실 위험이 있어 운영 환경에서는 권장되지 않는다.

4. Pod 관리

실행 중인 Pod의 상태와 이벤트, 로그를 확인하거나 내부에 직접 들어가야 할 때 사용하는 명령어는 다음과 같다.

kubectl describe pod - 상세 정보와 이벤트

kubectl describe pod nginx-pod

get -o yaml이 매니페스트를 그대로 보여준다면, describe는 사람이 읽기 쉬운 형태로 정리하고 마지막에 Events 섹션을 붙인다. 이미지 풀 실패, 스케줄링 실패 등의 로그가 Events에 기록되어 디버깅에 유용하다.

kubectl logs - 컨테이너 로그 확인

kubectl logs nginx-pod

logs는 컨테이너의 stdout과 stderr를 보여준다. 따라서 애플리케이션이 파일에 직접 로그를 쓰면 kubectl logs로는 확인할 수 없다.

k8s 환경에서는 stdout/stderr로 출력하는 것이 표준이며, 그 출력을 컨테이너 런타임이 노드의 파일로 수집한다.

추가로 -p(previous) 옵션을 붙이면 직전에 종료된 인스턴스의 로그를 볼 수 있다.

kubectl exec - 컨테이너 내부 진입

kubectl exec -it nginx-pod -- /bin/bash

docker exec와 비슷하게 동작한다. -i는 stdin 연결, -t는 TTY 할당으로, 인터랙티브 셸로 들어가려면 보통 -it 옵션을 함께 쓴다.

주의할 점은 컨테이너에 셸 바이너리가 설치되어 있어야 하며, 운영 환경에서 exec로 상태를 직접 건드리는 것은 권장하지 않는다.

5. Pod의 동작 원리

지금까지 Pod를 생성하고 다루는 방법을 살펴봤다. 마지막으로, 쿠버네티스가 왜 컨테이너 위에 Pod라는 한 단계의 추상화를 두는지, 그리고 그 추상화가 어떻게 실제로 구현되는지를 정리해보자.

왜 컨테이너가 아닌 Pod인가?

도커 같은 컨테이너 런타임이 다루는 단위는 개별 컨테이너이다. 반면 쿠버네티스는 한 단계 위의 단위인 Pod를 둔다.

이유는 함께 동작해야 하는 컨테이너들을 같은 리눅스 네임스페이스로 묶어, 하나의 단위로 스케줄링하기 위해서이다.

같은 Pod에 속한 컨테이너들은 다음 네임스페이스를 공유한다.

• Network: 같은 IP, 같은 IP 포트 공간을 공유하며, `localhost`로 서로 통신한다.
• IPC: 프로세스 간 통신 자원을 공유한다.
• UTS: 같은 호스트 이름을 가진다.

반면 Mount 네임스페이스(파일시스템)는 공유하지 않는다. 컨테이너 간 파일 공유는 별도의 볼륨을 통해 이루어지며, PID 네임스페이스도 기본값은 비공유이다.

필요 시 spec.shareProcessNamespace: true로 명시해야 한다.

이 공유 모델 위에서 sidecar 패턴이 가능해진다. 메인 애플리케이션 컨테이너 옆에 로깅, 프록시, 서비스 메시 같은 보조 컨테이너를 함께 두고, 같은 IP와 같은 볼륨을 공유한 채 협업하게 만드는 방식이다. 이렇게 한 Pod는 결국 하나의 완결된 애플리케이션 단위가 된다.

또한 같은 Pod의 모든 컨테이너는 같은 워커 노드에서 함께 실행되는 것이 보장된다. 이는 단순한 추상화가 아니라 강한 제약 조건이다. (네임스페이스 공유는 단일 노드 위에서만 성립하기 때문)

Pause 컨테이너 - 네임스페이스 공유의 실체

그렇다면 이 네임스페이스 공유는 실제로 어떻게 구현될까? 답은 Pause 컨테이너에 있다.

Pause 컨테이너는 각 Pod마다 자동으로 함께 생성되는 인프라 컨테이너다. 사용자가 작성한 매니페스트에는 등장하지 않지만, kubelet이 Pod을 띄울 때 가장 먼저 생성한다. 역할은 다음과 같다.

1. 네임스페이스를 만든다.
   Network·IPC·UTS 같은 공유 대상 네임스페이스를 점유한 채 idle 상태로 머문다.
2. 다른 컨테이너들이 합류한다.
   Pod 내부의 일반 컨테이너들은 자기 자신의 네임스페이스를 새로 만드는 대신 Pause 컨테이너의 네임스페이스에 join 한다.
3. 메인 컨테이너가 죽어도 네임스페이스는 살아남는다.
   컨테이너가 재시작돼도 Pod IP가 그대로 유지되는 이유가 여기에 있다. 네임스페이스의 실제 소유자는 Pause 컨테이너이지 메인 컨테이너가 아니다.

워커 노드를 통해 직접 확인이 가능하다.

ps aux | grep pause