서버 한 대에서 컨테이너 5개를 돌릴 때는 Docker만으로도 충분합니다. 그런데 서비스가 커지면 어떤 일이 벌어질까요? 컨테이너가 죽어도 아무도 모릅니다. 트래픽이 몰려도 자동으로 늘어나지 않습니다. 새 버전 배포 중에 서비스가 잠깐 끊깁니다. 서버가 10대가 되면 어느 서버에 어느 컨테이너를 띄울지 일일이 결정해야 합니다.

확대

문제 1: 자동 복구 없음

# 컨테이너가 죽었다 — 아무일도 일어나지 않는다
docker run -d --name my-api my-api:latest
# 5분 후, 메모리 부족으로 컨테이너 종료됨

docker ps
# CONTAINER ID   IMAGE   COMMAND   ...
# (아무것도 없음 — 죽은 채로 있음)

# 알림을 받은 누군가가 수동으로 재시작
docker start my-api

--restart=always 옵션으로 단순 재시작은 가능하지만, 헬스체크 실패나 의존 서비스 장애, 노드 다운 시에는 속수무책입니다.

문제 2: 수동 스케일링

# 트래픽이 5배 폭증 — 수동으로 컨테이너를 추가해야 함
docker run -d --name my-api-2 my-api:latest
docker run -d --name my-api-3 my-api:latest
docker run -d --name my-api-4 my-api:latest

# 그리고 로드밸런서 설정도 수동으로 변경해야 한다
# nginx.conf 수정 → nginx -s reload

트래픽이 줄어들면 다시 수동으로 줄여야 합니다. 새벽에 폭증하면? 아무도 없습니다.

문제 3: 무중단 배포 어려움

# 새 버전 배포 — 이 사이에 다운타임 발생
docker stop my-api
docker rm my-api
docker run -d --name my-api my-api:v2

# 또는 Blue-Green 배포를 수작업으로 구현해야 함
# → 로드밸런서 전환, 이전 컨테이너 관리, 롤백 스크립트...

문제 4: 멀티 호스트 관리 복잡성

서버가 10대라면? 어느 서버의 CPU가 여유로운지, 어느 서버에 컨테이너를 배치할지, 서버 간 네트워크는 어떻게 구성할지 — 모두 수작업입니다.

서버1: docker run ...  # SSH 접속 후 실행
서버2: docker run ...  # SSH 접속 후 실행
서버3: docker run ...  # SSH 접속 후 실행
# 10대면 10번 반복

Docker 환경에서 컨테이너 수십 개를 명령어로 직접 관리하다 보면, 어느 서버에 어떤 버전이 떠 있는지 파악하기 어려워지고 배포할 때마다 수작업 실수가 생깁니다. 특히 장애가 났을 때 "무엇을 실행해야 하는지"를 사람이 일일이 판단해야 하는 구조에서는 복구 속도가 개인 역량에 달리게 됩니다. Kubernetes의 선언적 관리는 이 문제를 "원하는 상태를 기록하면 시스템이 알아서 맞춘다"는 방식으로 해결합니다. 운영자가 "3개를 실행하라"고 선언해두면 컨테이너가 죽든, 노드가 바뀌든 Kubernetes가 현재 상태를 원하는 상태로 계속 맞춰주는 것이 Reconciliation Loop입니다.

확대

선언적 배포 예시

# deployment.yaml — "이런 상태이길 원한다"고 선언
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 3          # 항상 3개 실행
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
      - name: my-api
        image: my-api:v2   # 이 버전으로
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"

kubectl apply -f deployment.yaml
# deployment.apps/my-api created
# → K8s가 알아서 3개의 Pod를 적절한 노드에 배치
# → 하나가 죽으면 자동으로 새로 생성
# → 버전 변경 시 롤링 업데이트 자동 진행

K8s가 자동으로 처리하는 것들

Reconciliation Loop — K8s의 작동 원리

확대

이 루프는 K8s가 실행되는 동안 끊임없이 반복됩니다. 운영자가 잠든 새벽에도, 휴일에도.

이 모듈에서 K8s가 죽은 파드를 자동으로 되살린다는 것을 배웠습니다. 그런데 자동 복구를 믿고 배포했더니 파드가 Running도 아니고 CrashLoopBackOff에 갇혀 영영 안 뜨는 상황을 실무 첫날 만나게 됩니다. 자가 치유가 무엇을 고치고 무엇을 못 고치는지 선을 그어야 합니다.

• 자가 치유의 범위: reconcile 루프와 ReplicaSet은 파드 개수를 원하는 수로 되돌립니다. 노드가 죽거나 파드가 사라지면 새로 띄우는, 곧 인프라 수준의 소실을 복구하는 일입니다.
• 못 고치는 것: 파드가 떠도 앱이 시작 즉시 크래시하면(잘못된 설정, 없는 환경변수, 못 붙는 DB, 마이그레이션 실패) K8s는 그 원인을 모릅니다. 재시작만 반복하고, 반복이 잦아지면 지수 백오프로 재시작 간격을 늘립니다(10s → 20s → 40s … 최대 5분). 이 상태가 CrashLoopBackOff입니다.
• 왜 이렇게 설계됐나: 무한 즉시 재시작은 노드 CPU를 태우고 로그를 폭주시킵니다. 백오프는 고장난 걸 계속 못 고치니 간격을 늘려 피해를 줄이자는 방어이자, 되살아나길 기다리지 말고 사람이 로그를 보라는 신호입니다.

정리하면 자가 치유는 인프라 장애를 자동 복구하지만 애플리케이션 버그는 못 고칩니다. Docker의 --restart=always가 무한 즉시 재시작으로 CPU를 태우던 문제를 K8s는 백오프로 다스릴 뿐입니다. CrashLoopBackOff를 보면 알아서 하겠지가 아니라 kubectl logs --previous로 크래시 원인을 읽는 게 첫 수순입니다.