ReplicationController vs Deployment — 진화의 역사

지난 글에서 ReplicaSet의 컨트롤 루프와 자가 치유 동작을 살펴봤습니다. 이번에는 Kubernetes 역사를 거슬러 올라가 최초의 Pod 복제 오브젝트인 ReplicationController(RC)와, 현재의 표준인 Deployment를 비교합니다. 레거시 클러스터를 유지보수하거나 RC로 작성된 YAML을 마이그레이션해야 할 때 이 차이를 아는 것이 중요합니다.

ReplicationController의 등장

ReplicationController는 Kubernetes 1.0부터 존재한 오리지널 복제 오브젝트입니다. 지정한 수의 Pod를 유지하는 역할을 하지만 현재 기준으로 여러 한계가 있습니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: web-rc
spec:
  replicas: 3
  selector:
    app: web          # equality-based만 지원, matchLabels 없음
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.25

RC의 selector는 key: value 형태의 equality-based 방식만 지원합니다. matchExpressions를 사용할 수 없습니다.

핵심 차이점

기능	RC	Deployment
Selector	equality-based만	matchLabels + matchExpressions
롤링 업데이트	클라이언트 측 (kubectl rolling-update)	서버 측 자동
롤백	미지원	kubectl rollout undo
업데이트 일시 정지	미지원	pause/resume
히스토리 관리	없음	revision 히스토리
내부 구조	RC → Pod 직접	Deployment → ReplicaSet → Pod

RC 롤링 업데이트의 문제

RC로 롤링 업데이트를 하려면 kubectl rolling-update 명령을 사용해야 했습니다. 이 명령은 클라이언트 측에서 실행되므로 명령이 중단되면(네트워크 단절, 클라이언트 종료) 업데이트가 불완전한 상태로 멈춥니다. 서버 상태와 클라이언트 기대 상태가 불일치하는 위험이 있습니다.

# RC rolling-update (더 이상 권장하지 않음)
kubectl rolling-update web-rc --image=nginx:1.26
# 클라이언트 연결이 끊기면 반쯤 업데이트된 상태로 멈춤

Deployment는 이 문제를 서버 측에서 처리합니다. 롤아웃 상태를 Deployment 오브젝트에 기록하므로 클라이언트가 끊겨도 컨트롤러가 계속 업데이트를 진행합니다.

RC → Deployment 마이그레이션

무중단으로 RC를 Deployment로 전환하는 방법입니다.

# 1. 기존 RC 확인
kubectl get rc web-rc

# 2. Deployment YAML 작성 (selector 형식 변경 주의)
# spec.selector.app=web → spec.selector.matchLabels.app=web

# 3. Deployment 적용
kubectl apply -f web-deployment.yaml

# 4. RC는 Pod 유지하면서 삭제 (--cascade=orphan)
kubectl delete rc web-rc --cascade=orphan
# Pod가 남아 있고, Deployment의 selector가 일치하므로 Pod를 인수(adopt)

# 5. Deployment 상태 확인
kubectl rollout status deployment/web
kubectl get pods -l app=web

--cascade=orphan으로 RC만 삭제하면 기존 Pod가 살아있고, Deployment의 selector가 동일한 labels를 가진 Pod를 인수합니다. Pod 재시작 없이 마이그레이션할 수 있습니다.

Deployment의 내부 구조

Deployment는 RC와 달리 Pod를 직접 관리하지 않습니다. Deployment → ReplicaSet → Pod 체계입니다.

# Deployment가 생성한 ReplicaSet 확인
kubectl get replicaset -l app=web

# 롤링 업데이트 시 두 ReplicaSet이 공존
kubectl get rs
# NAME              DESIRED  CURRENT  READY
# web-7d9f8c        3        3        3   (새 버전)
# web-4c2b1a        0        0        0   (이전 버전, rollback용 유지)

이전 ReplicaSet이 남아 있기 때문에 kubectl rollout undo로 즉시 롤백이 가능합니다.

현재 권장 사항

ReplicationController는 deprecated 권고 상태입니다. 새로운 클러스터에서는 항상 Deployment(또는 StatefulSet, DaemonSet 등 목적에 맞는 워크로드)를 사용하세요. ReplicationController는 읽기 전용으로 기존 환경을 이해하는 용도로만 참고합니다.

# 클러스터에 남아 있는 RC 확인
kubectl get replicationcontrollers --all-namespaces

# RC가 있다면 마이그레이션 대상

---

지난 글: 쿠버네티스 ReplicaSet 완전 이해

다음 글: 쿠버네티스 Rolling Update와 Rollback

읽어주셔서 감사합니다. 😊