[Kubernetes] Kubernetes ReplicaSet과 Replicas 완벽 이해하기

안녕하세요! 오늘은 쿠버네티스(Kubernetes) 운영의 핵심이자, 서비스의 안정성을 책임지는 **ReplicaSet(레플리카셋)**과 Replicas(레플리카) 설정에 대해 깊이 있게 알아보겠습니다. 특히 이론뿐만 아니라 실제 Pod가 삭제되었을 때 어떻게 복구되는지 테스트 결과까지 함께 정리해 보겠습니다.

 

이전 시간에 학습한 [Kubernetes] 어플리케이션의 생명주기와 관리: 프로브(Probes)와 레이블(Labels) 바로가기

 

---

1. ReplicaSet이란 무엇인가?

ReplicaSet은 쿠버네티스의 컨트롤러 객체 중 하나로, 실행 중인 Pod의 개수를 일정하게 유지하는 역할을 합니다.

쉽게 비유하자면, ReplicaSet은 "편의점 점주"와 같습니다. 점주는 매대에 항상 삼각김밥이 3개(Replicas) 진열되어 있도록 확인합니다. 누군가 삼각김밥을 사 가면(Pod 종료), 즉시 새 제품을 채워 넣어 항상 3개를 유지하죠.

ReplicaSet의 핵심 목적

• 고가용성(High Availability): 하나 이상의 Pod가 다운되더라도 서비스가 중단되지 않도록 합니다.
• 스케일링(Scaling): 트래픽 증가 시 Pod의 개수를 늘려 부하를 분산합니다.

---

2. ReplicaSet 구성 예시 (YAML)

실제 환경에서 사용할 수 있는 ReplicaSet 정의 파일 예시입니다. nginx 이미지를 기반으로 3개의 복제본을 유지하는 설정입니다.

YAML

 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-web-rs
spec:
  # 1. 원하는 Pod의 개수 (Replicas)
  replicas: 3
  # 2. 어떤 라벨의 Pod를 관리할지 선택 (Selector)
  selector:
    matchLabels:
      tier: frontend
  # 3. 신규 Pod 생성 시 참고할 템플릿 (Template)
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx:stable-alpine

---

3. [실습] 자가 치유(Self-Healing) 테스트 및 결과

ReplicaSet이 정말로 Pod의 개수를 유지하는지 직접 테스트해 본 결과입니다.

① ReplicaSet 생성

먼저 위 YAML 파일을 적용합니다.

Bash

 

$ kubectl apply -f my-web-rs.yaml
replicaset.apps/my-web-rs created

② 생성 확인 (Initial State)

3개의 Pod가 정상적으로 실행 중임을 확인할 수 있습니다.

Bash

 

$ kubectl get pods
NAME              READY   STATUS    RESTARTS   AGE
my-web-rs-abc12   1/1     Running   0          10s
my-web-rs-def34   1/1     Running   0          10s
my-web-rs-ghi56   1/1     Running   0          10s

③ 임의로 Pod 삭제 (Test)

장애 상황을 가정하여 Pod 하나를 강제로 삭제해 보겠습니다.

Bash

 

$ kubectl delete pod my-web-rs-abc12
pod "my-web-rs-abc12" deleted

④ 테스트 결과 확인 (Recovery)

삭제 직후 다시 Pod 목록을 조회하면, 기존 Pod는 사라졌지만 즉시 새로운 Pod(my-web-rs-xyz78)가 생성된 것을 볼 수 있습니다.

Bash

 

$ kubectl get pods
NAME              READY   STATUS    RESTARTS   AGE
my-web-rs-def34   1/1     Running   0          45s
my-web-rs-ghi56   1/1     Running   0          45s
my-web-rs-xyz78   1/1     Running   0          2s  # 새롭게 생성됨!

결과 분석: ReplicaSet은 replicas: 3 설정을 만족시키기 위해 삭제된 Pod를 감지하자마자 새로운 Pod를 스케줄링했습니다. 이것이 쿠버네티스의 '선언적 명령' 기반의 자가 치유 능력입니다.

---

4. ReplicaSet vs Deployment

공부를 하다 보면 Deployment와 혼동될 수 있습니다. 결론부터 말씀드리면, 실무에서는 ReplicaSet을 직접 정의하기보다 Deployment를 사용합니다.

• ReplicaSet: Pod의 개수 유지에만 집중합니다.
• Deployment: ReplicaSet을 관리하며, **롤링 업데이트(Rolling Update)**나 롤백(Rollback) 같은 배포 전략을 지원합니다.

Deployment를 생성하면 내부적으로 자동으로 ReplicaSet이 생성되므로, 운영 시에는 상위 객체인 Deployment를 다루는 것이 표준입니다.

---

5. 스케일링(Scaling) 결과 확인

트래픽이 몰려 복제본을 5개로 늘려야 하는 상황이라면 다음 명령어를 사용합니다.

Bash

 

$ kubectl scale rs my-web-rs --replicas=5
replicaset.apps/my-web-rs scaled

$ kubectl get rs my-web-rs
NAME        DESIRED   CURRENT   READY   AGE
my-web-rs   5         5         5       2m

DESIRED(원하는 상태)와 CURRENT(현재 상태)가 모두 5로 일치하게 변하는 과정을 확인할 수 있습니다.

---

마치며

ReplicaSet은 쿠버네티스의 "안정성"을 지탱하는 가장 기초적인 컨트롤러입니다. 비록 실무에서는 Deployment에 가려져 직접 작성할 일이 적을 수 있지만, 그 내부 동작 원리를 아는 것은 트러블슈팅에 매우 큰 도움이 됩니다.

다음 포스팅에서는 이 ReplicaSet을 효율적으로 업데이트하는 Deployment 전략에 대해 심도 있게 다뤄보겠습니다!

---

도움이 되셨다면 공감과 댓글 부탁드립니다!

궁금한 점은 언제든 남겨주세요. :)