Deployment와 ReplicaSet — 선언적으로 Pod를 관리한다
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 Kubernetes 공식문서 Workloads — Deployments
이 모듈을 다 읽으면
- Deployment/ReplicaSet/Pod의 계층 관계와 각각의 책임 범위를 설명할 수 있다
- 롤링 업데이트가 새 ReplicaSet을 만드는 방식으로 동작한다는 것을 설명할 수 있다
k8s-learn-01의 컨트롤러 개념을 전제로, 가장 흔히 쓰는 워크로드 리소스인 Deployment가 ReplicaSet과 Pod를 어떻게 계층적으로 관리하며 무중단 배포를 구현하는지 정리한다.
세 계층 — Deployment가 ReplicaSet을, ReplicaSet이 Pod를 관리한다
Pod는 가장 작은 배포 단위(하나 이상의 컨테이너 묶음)이고, ReplicaSet은 지정된 개수의 동일한 Pod가 항상 떠 있도록 보장하는 컨트롤러다. Deployment는 이 ReplicaSet을 한 단계 더 감싸 선언적 업데이트(롤링 업데이트, 롤백)를 제공한다 — 사용자는 보통 ReplicaSet을 직접 다루지 않고 Deployment만 다루며, Deployment가 필요에 따라 ReplicaSet을 만들고 교체한다.
핵심 포인트
- Pod(최소 배포 단위) ← ReplicaSet(지정 개수 유지) ← Deployment(선언적 업데이트·롤백 제공)
- 사용자는 보통 Deployment만 다루고, Deployment가 내부적으로 ReplicaSet 생성·교체를 담당
롤링 업데이트 — 새 ReplicaSet을 만들고 점진적으로 전환한다
Deployment의 이미지·설정을 바꾸면, 기존 ReplicaSet을 그대로 수정하는 게 아니라 새 ReplicaSet을 새로 만들고, 그 새 ReplicaSet의 Pod 수를 점진적으로 늘리는 동시에 기존 ReplicaSet의 Pod 수를 줄여나간다(maxSurge/maxUnavailable로 그 속도·여유분을 조절). 이 과정에서 옛 ReplicaSet은 즉시 삭제되지 않고 이력(history)으로 남아 롤백 시 재사용된다 — `kubectl rollout undo`가 실제로는 이 과거 ReplicaSet의 스펙으로 되돌리는 것이다.
핵심 포인트
- 설정 변경 시 새 ReplicaSet 생성 + maxSurge/maxUnavailable로 조절하며 신규 확대·구버전 축소를 점진적으로 진행
- 옛 ReplicaSet은 즉시 삭제 안 되고 이력으로 남아 롤백(rollout undo) 시 재사용됨