5.Pod

1) 전제(가정)

• 애플리케이션은 이미 도커 이미지로 빌드되어 있고 **Docker Hub(또는 사설 레지스트리)**에 올라가 있음 → Kubernetes가 pull 가능
• Kubernetes 클러스터는 이미 구성/동작 중(단일 노드든 다중 노드든 상관 없음)
• 목표: 워커 노드들에 컨테이너 형태로 애플리케이션 배포

---

2) Kubernetes는 컨테이너를 직접 배포하지 않고 “Pod”로 감싼다

• 컨테이너는 Pod라는 Kubernetes 오브젝트로 캡슐화됨
• Pod = 애플리케이션의 단일 인스턴스
• Pod는 Kubernetes에서 만들 수 있는 가장 작은 배포 단위
• 가장 단순한 예시:
  • 단일 노드 클러스터
  • 애플리케이션 1개 인스턴스
  • Pod 안에 컨테이너 1개가 실행

---

3) 스케일링(확장/축소) 원리

사용자 증가 → 어떻게 확장?

• 부하 분산을 위해 웹 애플리케이션 인스턴스를 추가해야 함
• “같은 Pod에 컨테이너를 하나 더 띄우는가?” → 아님
• 같은 앱의 새 인스턴스를 위해 “새 Pod”를 만든다
  • 결과: 동일 노드(또는 클러스터 내)에 Pod 2개로 앱 인스턴스 2개 실행

노드 용량 부족하면?

• 클러스터에 새 노드를 추가(물리/가상 리소스 확장)
• 새 노드에 추가 Pod를 스케줄링할 수 있음

핵심 정리

• 일반적으로 컨테이너 : Pod = 1 : 1
• 스케일업 = Pod 추가 생성
• 스케일다운 = 기존 Pod 삭제
• 기존 Pod에 컨테이너를 “추가”해서 확장하는 방식은 보통 사용하지 않음
  (로드밸런싱/서비스 구성 등은 이후 강의에서 다룰 예정)

---

4) “Pod 하나에 컨테이너 여러 개”도 가능하지만 목적이 다름

• Pod는 여러 컨테이너 포함 가능
• 단, “같은 앱 컨테이너를 여러 개 넣어 확장” 목적이 아니라
  • 앱을 보조하는 헬퍼/사이드카(Helper/Sidecar) 컨테이너를 함께 두는 패턴에 가깝다
  • 예: 업로드 파일 처리, 입력 데이터 처리, 로깅/프록시/동기화 등

멀티 컨테이너 Pod의 특징(같은 운명)

• 같이 생성되고 같이 종료됨(라이프사이클 공유)
• 네트워크 네임스페이스 공유
  • 서로를 localhost로 통신 가능
• 스토리지 공유도 쉽게 구성 가능

---

5) Docker로 직접 운영할 때 생기는 번거로움 vs Kubernetes(Pod)의 장점

Docker만으로 구성하면(앱 + 헬퍼 1:1 관계) 생기는 일

• 어떤 앱 컨테이너 ↔ 어떤 헬퍼 컨테이너인지 매핑 관리 필요
• 컨테이너 간 네트워크 연결(링크/커스텀 네트워크) 수동 설정
• 공유 볼륨도 만들고 연결 관계를 관리해야 함
• 앱 컨테이너 죽으면 헬퍼도 같이 정리해야 하는데 → 모니터링/수동 종료 필요
• 새 앱 인스턴스 뜰 때마다 헬퍼도 같이 배포해야 함

Kubernetes의 Pod는 이런 걸 자동으로 정리해줌

• “Pod 안에 어떤 컨테이너들로 구성되는지”만 정의하면
  • 네트워크/스토리지 공유,
  • 함께 생성/종료(운명 공유)
  • 운영 복잡도가 크게 감소

---

6) 파드 배포 & 조회(kubectl)

• kubectl run ... (강의에서는 이 명령이 “파드를 만들어 컨테이너 배포”한다고 설명)
• 이미지가 어디서 오나?
  • --image로 이미지 이름 지정
  • 기본적으로 Docker Hub 같은 레지스트리에서 pull
  • 필요하면 사설 레지스트리도 사용 가능(구성 가능)
• 파드 목록 확인:
  • kubectl get pods
  • 생성 중(ContainerCreating) → 실행(Running) 상태로 바뀌는 흐름 확인 가능
  • -o wide 옵션으로 ip, node 확인 가능
• 파드 리소스 세부 정보 확인:
  • kubectl describe pod {{podName}}
• 아직 외부 접근(서비스/네트워킹)은 다루지 않음
  • 현재는 노드 내부에서만 접근 가능한 상태
  • 이후 강의에서 Service/Networking으로 “외부 사용자 접근”을 설명 예정

7) Pods with YAML

• Kubernetes는 Pod/ReplicaSet/Deployment/Service 같은 오브젝트를 만들 때 YAML 정의 파일을 입력으로 쓴다.
• Kubernetes YAML은 공통적으로 4개의 최상위 필드가 필수:
  1. apiVersion : 사용할 Kubernetes API 버전 (Pod는 보통 v1)
  2. kind : 만들 오브젝트 종류 (예: Pod, Deployment, Service)
  3. metadata : 이름/레이블 같은 식별 정보
     • name: 오브젝트 이름
     • labels: 원하는 키-값을 자유롭게 추가 가능(나중에 필터링/그룹화에 유용)
     • 단, metadata 아래에는 Kubernetes가 허용하는 필드만 써야 함(아무거나 추가 X)
  4. spec : “실제로 무엇을 어떻게 실행할지” 상세 스펙 (오브젝트마다 형태가 다름)
• Pod 예시에서는 spec.containers를 정의:
  • containers는 리스트(Pod가 여러 컨테이너를 가질 수 있어서)
  • 각 컨테이너 항목은 name, image 등을 가진 딕셔너리
• 생성/확인 명령:
  • 생성: kubectl create -f <file>.yaml (또는 kubectl apply -f ...)
  • 목록: kubectl get pods
  • 상세: kubectl describe pod <pod-name>
• YAML에서 들여쓰기(인덴트)가 매우 중요: 형제/자식 관계가 인덴트로 결정됨.

Pod YAML 예시 (nginx 1개 컨테이너)

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
    - name: nginx-container
      image: nginx:latest
      ports:
        - containerPort: 80

이 파일로 생성하기

kubectl create-f pod.yaml
# 또는 (권장)
kubectl apply-f pod.yaml

kubectl create vs kubectl apply 차이

kubectl create

• “없을 때만 생성” 하는 명령
• 동일한 이름의 리소스가 이미 있으면 보통 에러(AlreadyExists) 로 실패
• 주 용도: “처음 한 번 만들기”, 또는 “명령형(imperative)으로 빠르게 생성”

kubectl apply

• “있으면 업데이트, 없으면 생성” (선언적 방식, desired state 반영)
• YAML을 바꾸고 apply를 다시 하면 변경분이 반영됨
• 실무에서 매니페스트(YAML) 기반 운영은 대부분 apply 사용
• 특징
  • 같은 파일을 여러 번 적용해도 안전(멱등성에 가까움)
  • GitOps/형상관리와 궁합이 좋음

YAML로 계속 관리/수정/재적용할 거면 apply 권장

확인하기

kubectl get pods
kubectl describe pod myapp-pod

레이블이 중요한 이유

나중에 “프론트엔드 Pod만 보고 싶다” 같은 요구가 생기면:

kubectl get pods -l tier=frontend
kubectl get pods -l app=myapp

이렇게 레이블로 필터링할 수 있음