콘텐츠로 이동

파드 (Pod)

개요

쿠버네티스에서 반드시 알아야 할 배포의 최소 단위가 파드(Pod)예요. 컨테이너를 "그냥 하나 띄우면 되지 않나?" 싶지만, 쿠버네티스는 컨테이너 하나가 아니라 파드 하나를 배포 단위로 삼아요. 파드 안에는 컨테이너가 하나 이상 들어갈 수 있고, 그 컨테이너들은 같은 네트워크와 저장소를 공유해요.

상위 문서: Kubernetes · 디플로이먼트 · ConfigMap

핵심 개념

파드가 컨테이너를 감싸는 이유. 파드 안 컨테이너들은 같은 IP와 포트 공간을 공유하고, localhost로 서로를 찾을 수 있어요. 또 같은 볼륨을 함께 마운트할 수 있어서, 주 컨테이너와 옆에서 로그를 수집·전달하는 사이드카 컨테이너를 같이 묶는 용도로 써요.

파드의 수명. 파드는 "언제든 죽고 다시 태어나는" 임시 존재로 설계돼요. 죽은 파드를 사람이 다시 키우지 않아요. 디플로이먼트나 StatefulSet 같은 워크로드 컨트롤러가 파드를 만들고, 죽으면 새 파드로 대체해요. 그래서 파드 IP는 고정되지 않아요.

라이프사이클 단계. 파드는 Pending(스케줄링·이미지 준비) → Running(실행 중) → Succeeded/Failed(정상/비정상 종료)로 넘어가요. 자세한 상태는 kubectl get pod -o wide나 kubectl describe pod로 확인해요.

프로브(Probe). 파드가 "떠 있지만 제대로 일하는지"를 컨트롤러가 확인하게 하는 장치예요. livenessProbe는 죽었는지, readinessProbe는 트래픽을 받을 준비가 됐는지를 검사해요. readiness가 실패하면 서비스의 로드 밸런싱 대상에서 제외되죠.

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
    - name: app
      image: myapp:1.0.0
      ports:
        - containerPort: 8080

파드를 직접 만드는 경우. 학습·테스트 등 단발 실행에는 직접 만들어도 돼요. 하지만 운영 배포는 디플로이먼트 같은 컨트롤러를 통해서만 해요. 직접 만든 파드는 죽어도 자동 복구가 안 되거든요.

실제 적용(데이터스케쳐스)

우리 서비스(마케팅 Astro, 위키 MkDocs, 백엔드 API)는 모두 디플로이먼트가 관리하는 파드로 떠요. 각 파드는 컨테이너 하나를 실행하고, readiness 프로브가 준비 상태를 확인해서 트래픽을 받아요. 파드 자체를 직접 만들 일은 거의 없고, "파드가 어떤 단위인지"와 "언제 죽을 수 있는지"를 아는 게 운영에서 가장 중요해요. 죽어도 새 파드가 뜨는 구조니까요.

더 알아보기