Deployment와 ReplicaSet이란 무엇이며, rolling update와 rollback은 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

**Deployment**는 stateless 앱을 실행하는 표준 controller다. 그것은 **ReplicaSet**을 관리하고, ReplicaSet은 지정된 수의 동일한 Pod를 계속 실행되게 유지한다. 당신은 Deployment를 편집하고; 그것이 당신을 위해 **rolling update**와 **rollback**을 조율한다.

## 계층 구조

```text
Deployment  → 원하는 상태 + 업데이트 전략을 선언 (당신이 관리하는 것)
   └── ReplicaSet  → N개의 동일한 Pod가 존재하도록 보장 (앱 버전마다 하나)
          └── Pod  → Pod → Pod ...  (실제 실행 중인 복제본들)

새 버전마다 Deployment는 새로운 ReplicaSet을 만들고 Pod를 그쪽으로 옮긴다.
```

## Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # 업데이트 중 최대 1개의 Pod만 중단
      maxSurge: 1            # 원하는 개수보다 최대 1개의 추가 Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: 무중단 버전 변경

```bash
kubectl set image deployment/web web=myapp:2.0   # rolling update 트리거
kubectl rollout status deployment/web            # 진행 상황 관찰
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (시작: 4개의 옛 Pod)
      █████       새 Pod 1개(v2) 기동, 이제 총 5개 (surge)
      ███ █       옛 Pod가 3개로 감소, 새 Pod는 Ready
      ...점진적으로 전환...
  v2: ████        (끝: 4개의 새 Pod, 옛 ReplicaSet은 0으로 축소)
트래픽은 readiness probe를 통과한 Pod로만 간다 → 무중단.
```

## 릴리스가 잘못되었을 때 rollback

```bash
kubectl rollout history deployment/web       # revision 목록
kubectl rollout undo deployment/web          # 이전 revision으로 롤백
kubectl rollout undo deployment/web --to-revision=3
```

옛 ReplicaSet이 (0으로 축소된 채) 유지되기 때문에 rollback은 빠르다: Kubernetes는 그냥 이전 ReplicaSet을 다시 확장하고 새것을 축소한다.

## 스케일링(Scaling)

```bash
kubectl scale deployment/web --replicas=10   # 원하는 개수 변경
```

## 왜 중요한가

Deployment는 Kubernetes에서 stateless 애플리케이션을 실행하는 주력이므로, 그것과 ReplicaSet의 관계를 이해하는 것은 매일 쓰는 필수 지식이다. 계층화가 핵심 통찰이다: 당신은 **Deployment**를 관리하고, 그것이 **ReplicaSet**(버전마다 하나)을 소유하며, 각 ReplicaSet은 지정된 수의 동일한 Pod가 실행되도록 보장한다 — 함께 자가 치유와 안정적인 replica 수를 제공하는 조정 루프의 연쇄다. 진짜 힘은 Deployment가 변경을 처리하는 방식에 있다: **rolling update**는 새 ReplicaSet을 만들고 `maxSurge`와 `maxUnavailable`의 통제 하에 Pod를 옛것에서 새것으로 점진적으로 옮기므로, 용량이 보존되고 — 어떤 Pod가 트래픽을 받을지 결정하는 readiness probe와 결합되어 — 릴리스가 **무중단**으로 일어난다. 이전 ReplicaSet이 (삭제되지 않고 0으로 축소되어) 유지되기 때문에 **rollback**은 빠르고 안전하다: `kubectl rollout undo`는 단순히 옛 버전을 다시 확장하고 문제의 버전을 축소하는데, 이것이 바로 릴리스가 잘못 동작할 때 손을 뻗는 수단이다. 이 메커니즘을 이해하는 것 — 스케일링(`kubectl scale`) 및 진행 확인(`kubectl rollout status/history`) 방법과 함께 — 은 Kubernetes에서 소프트웨어를 안전하게 배포하는 기초이며, 이 플랫폼이 프로덕션에서 작동하는 방식을 정의하는 선언적, controller 주도 모델을 반영한다.

계층 구조

Deployment manifest

Rolling update: 무중단 버전 변경

릴리스가 잘못되었을 때 rollback

스케일링(Scaling)

왜 중요한가

관련 질문