GitHub

지난 2편에서 쿠버네티스의 뼈대(아키텍처)를 살펴봤다. 마스터 노드가 명령을 내리고 워커 노드가 일을 한다는 구조는 이해했다.

이제 내 홈서버(k3s)에 실제로 애플리케이션을 띄워볼 차례다. 그런데 막상 도커에서 쓰던 것처럼 “컨테이너를 띄운다”라고 하지 않고, 쿠버네티스에서는 자꾸 “파드(Pod)를 띄운다”고 한다.

도대체 파드는 뭐고, 왜 컨테이너를 한 번 더 감싸서 쓰는 걸까? 그리고 튜토리얼들을 보면 왜 파드를 직접 만들지 말고 Deployment를 쓰라고 하는 걸까? 오늘은 이 근본적인 질문들을 정리해 본다.

1. 컨테이너가 아니라 Pod(파드)다

쿠버네티스에서 배포의 최소 단위는 컨테이너가 아니라 Pod다.
이 개념을 잡는 것이 가장 중요하다.

콩껍질(Peapod)과 완두콩

Pod라는 단어는 고래 떼(Pod of Whales)라는 뜻도 있지만, 구조적으로는 콩껍질(Peapod)에서 유래했다고 이해하는 것이 직관적이다.

Pod (콩껍질): 쿠버네티스가 관리하는 최소 단위.
Container (완두콩): 실제 애플리케이션.

보통은 콩껍질 하나에 완두콩 하나(1 Pod = 1 Container)가 들어간다. 하지만 필요하다면 하나의 콩껍질 안에 여러 개의 완두콩(Multi-container)을 넣을 수도 있다.

왜 굳이 감싸놨을까?

Pod 내부에 있는 컨테이너들은 “운명 공동체”다. 이들은 다음과 같은 리소스를 공유한다.

IP 공유: Pod 안의 컨테이너들은 서로 localhost로 통신할 수 있다. 포트만 겹치지 않으면 된다.
스토리지 공유: 같은 볼륨을 마운트해서 파일을 공유할 수 있다.

예를 들어, 웹 서버 컨테이너가 로그를 파일로 쌓으면, 같은 파드 내의 ‘로그 수집 컨테이너(Sidecar)’가 그 파일을 읽어 외부로 전송하는 식이다. 이런 밀접한 결합을 위해 Pod라는 논리적인 테두리가 필요하다.

2. 명령어가 아니라 YAML로 관리한다

도커를 쓸 땐 docker run 처럼 명령어를 사용했지만, 쿠버네티스의 세계에서는 “원하는 상태(Desired State)”를 문서로 정의해서 제출한다. 이때 사용하는 형식이 YAML이다.

이것을 선언형(Declarative) API라고 한다. “이거 해!”(명령)가 아니라, “난 이런 상태를 원해”(선언)라고 말하는 방식이다.

Pod를 정의하는 기본 YAML 구조

처음 보면 복잡해 보이지만, 핵심 필드는 4가지다.

apiVersion: v1
kind: Pod # 1. 리소스 종류 (Pod? Deployment?)
metadata:
  name: nginx-pod # 2. 이름표
spec: # 3. 상세 명세 (가장 중요)
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

이 파일을 작성하고 kubectl apply -f pod.yaml을 입력하면 파드가 생성된다. 하지만 실무나 운영 환경에서는 이렇게 Pod를 직접(Kind: Pod) 생성하는 일은 거의 없다.

3. Pod를 직접 만들지 않는 이유

Pod는 ‘유한한 생명(Ephemeral)’을 가졌다.

실행 중인 노드가 장애로 죽으면? -> 그 안의 Pod도 같이 사라진다.
실수로 삭제하면? -> 그냥 지워진다. 자동으로 복구되지 않는다.

우리가 쿠버네티스를 쓰는 주된 이유는 “장애 발생 시 알아서 복구하고(Auto-healing)”, “트래픽에 따라 알아서 늘리는(Auto-scaling)” 기능을 쓰기 위함이다. Pod 단독으로는 이 기능을 수행할 수 없다.

그래서 Pod를 관리해 줄 상위 개념이 필요하다. 그것이 바로 Deployment(디플로이먼트)다.

4. 배포의 정석, Deployment

Deployment는 Pod의 상태를 관리하는 컨트롤러다. “나는 Nginx 파드 3개를 유지하고 싶어”라고 Deployment 명세에 적어두면, 이 친구가 알아서 파드를 만들고, 감시하고, 죽으면 살려낸다.

Deployment의 구조

내부적으로는 다음과 같은 계층 구조를 가진다.

Deployment: 배포 전략(업데이트, 롤백 등)을 관리.
ReplicaSet: “파드의 개수(Replicas)”를 보장하는 중간 관리자.
Pod: 실제 실행되는 컨테이너 집합.

Deployment YAML 예시 (이게 진짜다)

홈서버에 실제로 띄울 땐 아래와 같은 형식을 사용한다.

apiVersion: apps/v1
kind: Deployment        # 종류는 디플로이먼트
metadata:
  name: nginx-deployment
spec:
  replicas: 3           # "파드 3개를 항상 유지해줘!" (핵심)
  selector:
    matchLabels:
      app: nginx
  template:             # 여기서부터는 Pod의 설정과 동일하다
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

이 파일을 deployment.yaml로 저장하고 실행해 보자.

# 배포 적용
kubectl apply -f deployment.yaml

# 상태 확인
kubectl get deployments
kubectl get pods

파드 하나를 강제로 삭제해 보면(kubectl delete pod [파드이름]), Deployment가 즉시 새로운 파드를 생성해서 3개를 맞추는 것을 확인할 수 있다. 이것이 쿠버네티스가 제공하는 안정성이다.

5. Deployment를 쓰면 좋은 점 3가지

자동 복구 (Self-healing): 앞서 말했듯, 노드가 죽거나 파드가 삭제되어도 설정된 개수(replicas)를 맞추기 위해 자동으로 복구한다.
쉬운 스케일링 (Scaling): replicas: 3을 replicas: 10으로 수정하고 apply만 하면, 순식간에 파드가 10개로 늘어난다.
롤링 업데이트 (Rolling Update): 이미지를 nginx:1.14.2에서 nginx:latest로 바꾸면, 기존 파드를 하나씩 종료하고 새 파드를 하나씩 생성하며 무중단 배포를 수행한다.

6. 정리

오늘 내용을 요약하면 다음과 같다.

Pod: 쿠버네티스의 최소 실행 단위 (콩껍질). 컨테이너들의 모임이며 IP를 공유한다.
YAML: 쿠버네티스에게 “원하는 상태”를 선언하는 주문서.
Deployment: Pod를 관리하는 매니저. 안정적인 운영을 위해 Pod를 직접 만들지 말고, Deployment를 사용해야 한다.

자, 이제 내 홈서버에 Nginx 서버 3대를 띄우는 것까진 성공했다. 그런데 문제는 이 웹 서버에 접속할 방법이 없다. 파드는 클러스터 내부 IP만 가지고 있어서 외부 브라우저에서 접근이 불가능하다.

다음 편에서는 굳게 닫힌 파드에 문을 달아주는 Service(서비스)와 Ingress(인그레스)에 대해 정리해 본다. 드디어 도메인을 치고 내 서버에 접속할 수 있게 된다.

📂 [시리즈] 쿠버네티스(k8s) 기초 완전 정복

이 글은 개인 학습을 위해 정리한 내용이며, 오류가 있다면 피드백 부탁드립니다.

[k8s 기초 3편] 가장 작은 실행 단위 Pod, 그리고 배포의 정석 Deployment