쿠버네티스 Pod 완전 정복: 컨테이너

쿠버네티스를 공부하거나 사용하다 보면 가장 자주 접하게 되는 개념이 바로 Pod입니다. 이 글에서는 Pod란 무엇인가? 왜 필요한가? 어떻게 구성되고 동작하는가?를 예시와 함께 상세히 다뤄보겠습니다.

---

🧱 1. Pod란 무엇인가?

Pod는 쿠버네티스에서 가장 작은 배포 단위입니다.

하나 이상의 컨테이너가 함께 배포되고 실행되는 논리적인 호스팅 단위입니다. 보통은 하나의 컨테이너만 실행되지만, 특수한 경우 두 개 이상의 컨테이너가 함께 실행되기도 합니다. 이 때의 컨테이너는 하나의 프로세스를 협력적으로 수행하기 위해 같은 네트워크, 스토리지를 공유합니다.

✅ 핵심 특징

• 공유 네트워크 네임스페이스: 동일한 localhost, 동일한 포트를 공유합니다.
• 공유 스토리지 볼륨: Pod 내 컨테이너들이 같은 볼륨을 마운트할 수 있습니다.
• 동일한 스케줄링 단위: 컨테이너들은 항상 함께 스케줄되어 같은 노드에 배치됩니다.

---

📦 2. Pod의 구성 요소

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
spec:
  containers:
    - name: nginx-container
      image: nginx:latest
      ports:
        - containerPort: 80

구성 설명

항목	설명
apiVersion	사용되는 Kubernetes API 버전
kind	리소스 종류 (Pod)
metadata	Pod 이름, 라벨 등 메타데이터
spec	Pod의 사양 (실행할 컨테이너 정의 등)
containers	실제 실행할 컨테이너 목록

---

🔄 3. 왜 Pod가 필요한가?

Kubernetes는 컨테이너 오케스트레이션 툴입니다. Docker만으로는 컨테이너 실행/종료는 가능해도 배포, 확장, 복구, 네트워크, 스토리지를 일관되게 관리할 수 없습니다.

이러한 이유로 Kubernetes는 컨테이너를 직접 다루기보다는 Pod라는 래퍼 객체로 컨테이너를 감싸 추상화된 단위로 관리합니다.

예시: 사이드카 패턴

containers:
  - name: app
    image: my-app
  - name: log-collector
    image: fluentd

위처럼 app과 log-collector를 한 Pod에 함께 배포하면, fluentd는 app 컨테이너의 로그를 같은 디렉토리에서 실시간으로 수집할 수 있습니다.

---

🕸️ 4. Pod의 네트워크와 IP

• 각 Pod는 고유의 IP 주소를 가짐
• Pod 내부 컨테이너들은 localhost로 통신
• Pod 간 통신은 Kubernetes CNI 플러그인 (예: Calico, Flannel 등)을 통해 이루어짐

즉, Pod는 작은 가상의 서버라고 볼 수 있으며, 컨테이너는 그 서버 위의 프로세스입니다.

---

🧬 5. Pod의 생명주기 (Pod Lifecycle)

Pod는 다음과 같은 생명주기를 가집니다.

Pending → Running → Succeeded / Failed → (Evicted or Terminated)

단계별 설명

상태	설명
Pending	노드에 스케줄링되기 전 또는 이미지 Pull 중
Running	모든 컨테이너가 실행 중
Succeeded	모든 컨테이너 정상 종료
Failed	하나 이상의 컨테이너가 비정상 종료
Evicted	자원 부족 등으로 강제 종료됨 (특히 노드 OOM)

---

📊 6. Pod 모니터링 및 상태 확인

상태 확인

kubectl get pod
kubectl describe pod my-nginx
kubectl logs my-nginx

상태 컬럼 해석

상태	의미
Running	정상 작동 중
CrashLoopBackOff	반복적으로 크래시
ImagePullBackOff	이미지 Pull 실패
Terminating	삭제 중 (혹은 네트워크 연결 중단 등으로 지연)

---

🧩 7. Pod는 직접 쓰지 않는다?

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

왜냐하면 Pod는 재시작 정책이 약하고, 오토스케일링 대상이 아니기 때문입니다. 대신, 아래와 같은 고수준 리소스를 사용합니다.

• Deployment: ReplicaSet을 관리해 Pod 자동 생성/복구
• StatefulSet: 상태를 가진 Pod 관리 (예: DB)
• DaemonSet: 노드당 1개의 Pod 배포 (예: 로그 수집기)
• Job / CronJob: 일회성/주기적 실행

✅ 실무 팁: Pod는 테스트나 디버깅 목적에만 직접 생성하고, 실제 서비스용으로는 Deployment 이상 레벨의 리소스를 사용하세요.

---

🛠️ 8. Pod 디버깅 팁

# Pod 상태 확인
kubectl describe pod <pod-name>

# 로그 확인
kubectl logs <pod-name> [-c container-name]

# 인터랙티브 쉘 접속
kubectl exec -it <pod-name> -- /bin/sh

특히 kubectl describe에서 Events 섹션은 Pod 스케줄링이나 이미지 문제, 오토스케일링 오류를 추적하는 데 매우 유용합니다.

---

📌 마무리

Pod는 Kubernetes에서 가장 기본이 되는 개념이지만, 그만큼 중요하고 많이 사용됩니다. 아래는 다시 정리한 핵심 요약입니다.

개념	설명
Pod	쿠버네티스에서 가장 작은 배포 단위
컨테이너 간 관계	네트워크, 볼륨을 공유하며 같은 노드에 배치됨
일반 사용법	직접 사용보다는 Deployment 등 상위 리소스를 통해 생성
네트워크	Pod는 고유 IP를 가지며 다른 Pod와 통신 가능
실무에서의 위치	앱 단위가 아닌 프로세스 단위의 묶음으로 사용됨

이제 kubectl로 Pod를 다뤄볼 때마다, 그 내부의 구조와 동작을 명확하게 이해하고 작업할 수 있게 될 것입니다. 궁금한 점이나 추가 주제 요청은 댓글로 남겨주세요! 😊