🫛 쿠버네티스의 최소 단위 – Pod를 직접 만지고 부숴봤다

쿠버네티스를 처음 배울 때 제일 헷갈리는 개념이 바로 Pod(파드)입니다. Docker 컨테이너랑 뭐가 다른 거지? 라고 생각하기 쉬운데, 쿠버네티스는 컨테이너를 직접 관리하지 않습니다. 컨테이너를 파드라는 껍질로 감싸서 다루죠. 이번 실습은 파드를 두 가지 방식으로 만들고, 내부를 직접 들여다보고, 생명주기를 관찰한 기록입니다.

---

🎯 이번 실습에서 다룬 것들

• 명령형(Imperative) vs 선언형(Declarative) 방식 비교
• Resource Quota 설정 (requests / limits)
• kubectl describe로 파드 상태 추적
• kubectl exec로 컨테이너 내부 접속
• 파드의 상태 변화 관찰 (ContainerCreating → Running)

---

📌 방법 1: 명령형 (Imperative) — 빠른 테스트용

일회성 테스트엔 이 방법이 빠릅니다. CLI 명령어 한 줄로 바로 띄웁니다.

# 파드 생성
kubectl run nginx-pod --image=nginx:1.21

# 상태 확인
kubectl get pods

# 상세 정보 (Events 항목이 핵심)
kubectl describe pod nginx-pod

# 로그 확인
kubectl logs nginx-pod

# 컨테이너 내부 접속 (SSH 같은 느낌)
kubectl exec -it nginx-pod -- /bin/bash

# 삭제
kubectl delete pod nginx-pod

kubectl describe의 Events 항목을 보면 파드가 어떤 노드에 스케줄링됐는지, 이미지를 언제 다운로드했는지 전부 추적할 수 있습니다. 파드가 이상하면 가장 먼저 이걸 봐야 합니다.

---

📌 방법 2: 선언형 (Declarative) — 실무 표준 ⭐

실무에서는 YAML 파일을 작성해서 “이 상태를 유지해줘”라고 쿠버네티스에 전달합니다. 형상 관리도 되고, 팀원과 공유도 쉽습니다.

# nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
    resources:           # 자원 관리 (중요!)
      requests:          # "최소 이만큼은 있어야 일합니다"
        memory: "64Mi"
        cpu: "100m"      # 1 CPU의 10%
      limits:            # "이 이상은 절대 안 됩니다"
        memory: "128Mi"
        cpu: "200m"

Resource 설정이 왜 중요한가? requests가 없으면 스케줄러가 어느 노드에 배치할지 판단을 못 합니다. limits가 없으면 하나의 파드가 노드 자원을 독식하다가 다른 파드들을 죽일 수 있습니다. 처음부터 습관처럼 넣어두는 게 맞습니다.

# 파드 생성
kubectl apply -f nginx-pod.yaml

# 노드 할당 확인 (-o wide 옵션이 핵심)
kubectl get pods -o wide

-o wide 옵션을 쓰면 파드의 IP주소와 어느 노드에 배치됐는지가 보입니다. 스케줄러가 자원 여유를 계산해서 자동으로 배정한 결과입니다.

---

🔍 파드 생명주기 관찰

ContainerCreating → Running

파드를 처음 생성하면 곧바로 Running이 되지 않습니다.

1. ContainerCreating — 워커 노드가 이미지를 레지스트리에서 다운로드 중
2. Running — 이미지 다운로드 완료, 프로세스 시작

이미지가 노드에 이미 캐시돼 있으면 몇 초, 처음 받으면 네트워크 속도에 따라 10~30초 걸립니다. kubectl describe의 Events에서 Pulling image "nginx:1.21" 메시지로 확인할 수 있습니다.

---

🚨 삽질 포인트

⚠️ ContainerCreating 상태가 계속 유지된다면?

처음에 잠깐 당황했는데, 이건 사실 정상입니다. 이미지를 다운로드하는 데 시간이 걸리는 것뿐입니다. kubectl describe pod nginx-pod로 Events를 확인해보면 현재 무슨 단계인지 알 수 있습니다.

진짜 문제 상황이라면 ImagePullBackOff나 ErrImagePull 같은 에러가 표시됩니다.

---

💡 명령형 vs 선언형, 언제 뭘 쓰나?

상황	방법
빠른 테스트, 디버깅	명령형 (kubectl run)
실제 서비스 배포, 팀 협업	선언형 (kubectl apply -f)
CI/CD 파이프라인	선언형 (YAML 파일을 Git으로 관리)

선언형이 좋은 이유는 “현재 원하는 상태를 코드로 정의”할 수 있기 때문입니다. 파드가 죽어도 다시 kubectl apply하면 원상복구됩니다.

---

✅ 정리

파드 하나를 직접 다뤄보니, 쿠버네티스가 “컨테이너를 어디에 얼마나 어떻게 배치할지”를 전부 알아서 해준다는 걸 실감했습니다. 그런데 파드는 혼자선 자가 치유가 안 됩니다. 파드가 죽으면 그냥 끝입니다.

다음 글에서는 파드를 “군단” 단위로 관리하고, 죽으면 자동으로 살아나는 Deployment를 다룹니다.