전체 비유: 아파트 한 세대#

Pod를 아파트 한 세대에 비유하면 이해하기 쉽습니다:

이처럼 Pod는 “한 세대에 여러 사람이 함께 살면서 주방과 거실을 공유"하는 것과 같습니다.

대상 독자: Kubernetes Pod 개념을 이해하고 싶은 백엔드 개발자 선수 지식: Docker 컨테이너 기본 개념 소요 시간: 약 25-30분 이 문서를 읽으면: Pod가 무엇인지, 왜 컨테이너 대신 Pod를 사용하는지 이해할 수 있습니다

TL;DR

• Pod는 Kubernetes의 최소 배포 단위입니다
• Pod는 하나 이상의 컨테이너를 포함하며, 컨테이너들은 네트워크와 스토리지를 공유합니다
• 대부분의 경우 Pod에 컨테이너 1개만 포함합니다

Pod란?#

Pod는 Kubernetes에서 생성하고 관리할 수 있는 가장 작은 배포 단위입니다. Docker에서는 컨테이너가 최소 단위지만, Kubernetes에서는 Pod가 최소 단위입니다.

flowchart TB
    subgraph Pod
        direction TB
        C1[Container 1]
        C2[Container 2]
        V[Shared Volume]
        C1 --- V
        C2 --- V
    end
    NET[공유 네트워크<br>localhost 통신]
    Pod --- NET

Pod 내의 컨테이너들이 공유하는 것은 다음과 같습니다.

반면 컨테이너별로 격리되는 것도 있습니다.

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

Docker의 컨테이너와 Kubernetes의 Pod는 어떻게 다를까요?

Pod를 사용하는 이유는 밀접하게 연관된 컨테이너들을 하나의 단위로 관리하기 위해서입니다.

예시: 웹 애플리케이션과 로그 수집#

flowchart LR
    subgraph Pod
        App[Web App<br>:8080]
        Log[Log Collector]
        V[(로그 볼륨)]
        App -->|로그 기록| V
        V -->|로그 읽기| Log
    end
    Log -->|전송| ES[(Elasticsearch)]

이 경우 Web App과 Log Collector는 다음과 같은 이유로 같은 Pod에 있어야 합니다.

• 같은 노드에서 실행되어야 함 (로그 파일 공유)
• 함께 시작하고 함께 종료되어야 함
• 스케일 아웃 시 함께 복제되어야 함

Pod YAML 구조#

기본적인 Pod 정의를 살펴봅니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
    version: v1
spec:
  containers:
  - name: app
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "200m"

각 필드의 의미는 다음과 같습니다.

Pod 생명주기#

Pod는 생성부터 종료까지 여러 단계를 거칩니다.

stateDiagram-v2
    [*] --> Pending: Pod 생성
    Pending --> Running: 컨테이너 시작
    Running --> Succeeded: 정상 종료
    Running --> Failed: 비정상 종료
    Running --> Unknown: 노드 통신 불가
    Succeeded --> [*]
    Failed --> [*]

각 단계를 설명하면 다음과 같습니다.

컨테이너 상태#

Pod 내 각 컨테이너도 상태를 가집니다.

# 컨테이너 상태 확인
kubectl describe pod my-app

멀티 컨테이너 패턴#

Pod에 여러 컨테이너를 포함하는 대표적인 패턴들입니다.

Sidecar 패턴#

메인 컨테이너를 보조하는 컨테이너를 함께 실행합니다.

apiVersion: v1
kind: Pod
metadata:
  name: web-with-logging
spec:
  containers:
  - name: web
    image: nginx:1.25
    volumeMounts:
    - name: logs
      mountPath: /var/log/nginx
  - name: log-forwarder
    image: fluent/fluentd:v1.16
    volumeMounts:
    - name: logs
      mountPath: /var/log/nginx
      readOnly: true
  volumes:
  - name: logs
    emptyDir: {}

Sidecar 패턴의 활용 사례는 다음과 같습니다.

• 로그 수집 (Fluentd, Filebeat)
• 프록시 (Envoy, Istio)
• 설정 동기화 (Git-sync)

Init Container 패턴#

메인 컨테이너 실행 전에 초기화 작업을 수행합니다.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  - name: init-db-check
    image: busybox:1.36
    command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
  - name: app
    image: my-app:1.0

Init Container의 특징은 다음과 같습니다.

활용 사례는 다음과 같습니다.

• 의존 서비스 대기 (DB, 캐시 등)
• 설정 파일 생성
• 데이터 다운로드

Pod 네트워킹#

Pod 네트워킹의 핵심 개념을 이해합니다.

Pod IP#

각 Pod는 클러스터 내에서 고유한 IP를 할당받습니다.

flowchart LR
    subgraph Node1
        P1[Pod A<br>10.244.1.5]
        P2[Pod B<br>10.244.1.6]
    end
    subgraph Node2
        P3[Pod C<br>10.244.2.3]
    end
    P1 <-->|직접 통신| P3
    P1 <-->|localhost 불가| P2

네트워킹 규칙은 다음과 같습니다.

포트 충돌#

같은 Pod 내 컨테이너는 동일한 포트를 사용할 수 없습니다.

# 잘못된 예시 - 포트 충돌
spec:
  containers:
  - name: app1
    ports:
    - containerPort: 8080  # 충돌!
  - name: app2
    ports:
    - containerPort: 8080  # 충돌!

# 올바른 예시
spec:
  containers:
  - name: app1
    ports:
    - containerPort: 8080
  - name: app2
    ports:
    - containerPort: 8081  # 다른 포트 사용

실습: Pod 생성과 관리#

Pod 생성#

# YAML 파일로 생성
kubectl apply -f pod.yaml

# 명령형으로 빠르게 생성 (테스트용)
kubectl run nginx --image=nginx:1.25

Pod 상태 확인#

# Pod 목록
kubectl get pods

# 상세 정보
kubectl describe pod nginx

# 로그 확인
kubectl logs nginx

# 멀티 컨테이너 Pod의 특정 컨테이너 로그
kubectl logs nginx -c sidecar

Pod 접속#

# 컨테이너 셸 접속
kubectl exec -it nginx -- /bin/bash

# 특정 컨테이너 접속
kubectl exec -it nginx -c sidecar -- /bin/sh

# 명령 실행
kubectl exec nginx -- cat /etc/nginx/nginx.conf

Pod 삭제#

# 단일 Pod 삭제
kubectl delete pod nginx

# YAML 파일로 삭제
kubectl delete -f pod.yaml

# 강제 삭제 (주의 필요)
kubectl delete pod nginx --force --grace-period=0

Pod를 직접 사용하지 않는 이유#

실제 운영에서는 Pod를 직접 생성하지 않습니다.

따라서 실제로는 Deployment, StatefulSet, DaemonSet 등의 워크로드 리소스를 통해 Pod를 관리합니다.

언제 Pod를 직접 사용하나요?

• 디버깅용 임시 Pod
• 일회성 작업 (kubectl run으로 빠른 테스트)
• 학습 목적

프로덕션에서는 항상 Deployment 등을 사용하세요.

다음 단계#

Pod를 이해했다면 다음 단계로 진행하세요: