[개발자 관점] 주요 Kubernetes 컨트롤러 종류 – 2. ReplicaSet

25 sec read

지난 시간에는 쿠버네티스 배포의 표준인 Deployment에 대해 알아보았습니다. Deployment가 Pod를 선언적으로 관리하고, 무중단 업데이트와 롤백까지 책임지는 만능 컨트롤러라는 것을 확인했죠.

그런데 Deployment가 “Pod 3개를 유지해줘!”라는 명령을 내렸을 때, 실제로 현장에서 Pod의 개수를 세고, 죽은 Pod를 살려내는 등 궂은일을 하는 존재는 따로 있습니다. 바로 오늘 알아볼 ReplicaSet입니다.

✅ ReplicaSet의 핵심 개념

ReplicaSet은 아주 단순하고 명확한 한 가지 임무를 수행하는 컨트롤러입니다.

“지정된 수의 Pod 복제본(Replica)이 항상 실행되도록 보장한다.”

즉, ReplicaSet은 특정 레이블(Label)을 가진 Pod가 정확히 몇 개 존재해야 하는지 정의하고, 현재 상태를 감시하며 그 수를 자동으로 맞춰주는 역할을 합니다. Pod가 장애로 꺼지면 새로 생성하고, 설정보다 많이 떠 있으면 초과분을 삭제하는 충실한 감시자입니다.

🔁 언제 생성되나요?

여기서 중요한 점이 있습니다. 대부분의 경우, 개발자가 kubectl create -f my-replicaset.yaml과 같이 직접 ReplicaSet을 생성하는 일은 거의 없습니다.

그렇다면 ReplicaSet은 언제 등장할까요? 바로 Deployment를 생성할 때 내부적으로 자동 생성됩니다. 전체적인 흐름은 다음과 같습니다.

Deployment (배포 전략과 버전을 관리하는 사령관)
    (자동으로 생성 및 관리)
ReplicaSet (단순히 Pod 수를 맞추는 현장 매니저)
    (실행 및 개수 유지)
Pod (실제 애플리케이션)

Deployment는 배포 전략을 실행하기 위해 ReplicaSet을 도구로 사용하는 셈입니다.

🧪 기본 예시: ReplicaSet YAML

물론 원한다면 다음과 같이 ReplicaSet을 독립적으로 생성할 수도 있습니다. 구조를 살펴보면 Deployment와 매우 유사하다는 것을 알 수 있습니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: web
          image: nginx

📌 위 YAML 스펙은 쿠버네티스에게 app=my-app 레이블을 가진 Pod가 항상 2개 유지되도록 자동 조정하라는 의미입니다.

🧠 작동 방식

ReplicaSet의 작동 원리는 간단합니다.

  1. Selector (matchLabels)를 통해 자신이 관리해야 할 Pod 그룹을 식별합니다.
  2. 현재 실행 중인 Pod의 수가 replicas에 정의된 수보다 부족하면template 명세를 이용해 새로운 Pod를 생성합니다.
  3. Pod의 수가 replicas에 정의된 수보다 많으면 → 초과된 Pod 중 하나를 삭제합니다.
  4. 관리하던 Pod가 예상치 못하게 죽으면 → 부족해진 수를 채우기 위해 즉시 새로운 Pod를 생성합니다.

이 과정을 끊임없이 반복하며 원하는 상태를 유지합니다.

🔍 Deployment vs ReplicaSet

그렇다면 Deployment와 ReplicaSet의 결정적인 차이는 무엇일까요?

🟡 ReplicaSet

  • 역할: 단순히 복제 수(Pod 수)를 유지하는 데 집중합니다.
  • 한계: 버전 관리나 롤링 업데이트와 같은 정교한 배포 전략을 수행할 수 없습니다.
  • 용도: 실무에서 직접 사용하는 경우는 매우 드뭅니다.

🟢 Deployment

  • 역할: 내부적으로 ReplicaSet을 생성하고 교체하며 버전 관리, 롤링 업데이트, 롤백까지 모두 처리합니다.
  • 용도: 실전 운영 환경에서는 항상 Deployment를 사용하는 것이 표준입니다. 새 버전을 배포할 때, Deployment는 새 버전의 ReplicaSet을 만들고 기존 ReplicaSet을 점진적으로 축소하는 방식으로 무중단 업데이트를 구현합니다.

✅ 개발자 관점 요약

ReplicaSet은 Pod 수를 유지하는 역할을 하는 하위 컨트롤러입니다.
Selector를 기반으로 Pod 그룹을 식별하고, 지정된 복제 수를 자동으로 관리합니다.
Deployment가 ReplicaSet을 자동 생성하고 관리하므로, 개발자가 직접 다룰 일은 거의 없습니다.
하지만 ReplicaSet의 동작 원리를 이해하면, Deployment 배포 시 Pod가 생성되고 교체되는 흐름을 더 명확하게 파악할 수 있습니다.

kubectl get replicaset (또는 rs) 명령을 통해 현재 어떤 ReplicaSet이 활성화되어 있는지 확인해보세요. Deployment를 업데이트하면 새로운 ReplicaSet이 생기고 이전 ReplicaSet의 Pod 수가 0으로 줄어드는 것을 직접 관찰할 수 있습니다. 이는 쿠버네티스의 동작을 이해하는 데 큰 도움이 됩니다.


쿠버네티스 시크릿 관리, 어떤 방법이 최선일까? 4가지 방식 장단점…

쿠버네티스에서 애플리케이션을 운영할 때, DB 접속 정보나 API 키 같은 민감한 정보, 즉 ‘시크릿(Secret)’을 어떻게 관리해야 할지는 모두의 공통된 고민입니다. 관리 방식은 보안, 운영...
eve
13 sec read

[MSA] Spring Cloud Gateway VS Apache APISIX : 단계별…

마이크로서비스 아키텍처(MSA)에서 API 게이트웨이는 시스템의 관문 역할을 하는 핵심 컴포넌트입니다. 수많은 Java 개발팀이 Spring 생태계와의 완벽한 통합성을 자랑하는 Spring Cloud Gateway를 선택해왔습니다. 그러나 시스템이...
eve
1 min read

[Kafka] 카프카의 심장: 토픽, 파티션, 프로듀서, 컨슈머 완벽 해부

Apache Kafka가 어떻게 대용량 데이터를 실시간으로, 그리고 안정적으로 처리할 수 있는지 궁금하신가요? 그 비밀은 Kafka를 구성하는 핵심 요소들의 유기적인 협력에 있습니다. Kafka는 마치 잘...
eve
1 min read