[IT-방법] 레플리카셋 실전 예제 따라하기 – 배포부터 동작 검증까지 단계별 실습

왜 지금 레플리카셋을 제대로 알아야 할까요

새벽 3시, 갑작스러운 알람 소리에 잠에서 깨어난 적이 있으신가요? 모니터링 대시보드에는 서비스의 핵심 파드가 다운되었다는 붉은색 경고가 떠 있고, 사용자의 접속은 끊기고 있어요. 플랫폼 팀을 이끄는 테크리드라면 이런 상황이 얼마나 끔찍한지 잘 아실 거예요. 사람이 일일이 개입해서 파드를 다시 띄우는 동안 서비스의 가용성은 바닥을 치게 되거든요.

쿠버네티스를 사용하면서 단순히 파드를 하나씩 띄우는 데 그치고 있다면, 아직 진정한 자기 치유(Self-healing)의 이점을 누리지 못하고 있는 거예요. 레플리카셋(ReplicaSet)은 우리가 설정한 파드의 개수를 항상 일정하게 유지하도록 감시하고, 문제가 생기면 즉시 새로운 파드를 생성해내는 아주 똑똑한 관리자랍니다.

많은 분이 배포(Deployment) 객체를 사용하기 때문에 레플리카셋을 직접 다룰 일이 별로 없다고 생각하기도 해요. 하지만 배포 객체의 바로 아래 단계에서 실제로 어떤 메커니즘으로 파드가 복제되고 관리되는지 이해하는 것은 운영의 깊이를 완전히 다르게 만들어요. 장애가 발생했을 때 어떤 로직으로 복구가 일어나는지 모른다면, 복잡한 트러블슈팅 상황에서 길을 잃기 쉽거든요.

이 글에서는 이론적인 설명은 잠시 접어두고, 실제 실무에서 바로 써먹을 수 있는 레플리카셋 실전 예제를 통해 동작 원리를 몸소 체험해 보려고 해요. 매니페스트를 작성하는 아주 기초적인 단계부터, 파드를 의도적으로 죽여서 복구되는 과정을 확인하는 고난도 검증까지 차근차근 진행할 거예요.

이번 실습을 통해 여러분은 다음과 같은 것들을 확실히 얻어갈 수 있어요.

• 레플리카셋의 핵심 설정 값인 셀렉터(Selector)와 템플릿(Template)의 관계 이해
• YAML 매니페스트를 통해 파드의 복제본 개수를 제어하는 방법
• 장애 상황을 시뮬레이션하여 쿠버네티스의 자기 치유 능력 검증하기
• 실제 운영 환경에서 발생할 수 있는 설정 오류와 해결책 파악

실습 전 반드시 챙겨야 할 준비물과 기본 개념

본격적으로 실습에 들어가기 전에, 여러분의 환경이 준비되어 있는지 먼저 확인해야 해요. 준비가 되지 않은 상태에서 명령어를 입력하면 에러 메시지만 마주하게 되어 흐름이 끊길 수 있거든요. 테크리드로서 팀원들에게 가이드를 줄 때도 이 체크리스트는 매우 중요해요.

실습 환경 체크리스트

먼저 쿠버네티스 클러스터가 활성화되어 있어야 해요. 로컬 환경이라면 Minikube나 Kind를 사용하는 것을 추천드려요. 클라우드 환경이라면 EKS나 GKE를 사용해도 무방해요. 또한, 클러스터를 조작할 수 있는 kubectl 도구가 설치되어 있고, 현재 컨텍스트가 올바른 클러스터를 가리키고 있는지 확인해 주세요.

레플리카셋과 배포의 결정적 차이

실무에서 가장 많이 헷갈려 하는 부분이 바로 레플리카셋과 배포의 차이점이에요. 사실 우리가 실무에서 사용하는 대부분의 관리 객체는 배포(Deployment)이지만, 그 배포가 내부적으로 레플리카셋을 생성하고 관리하는 구조라는 점을 이해하는 것이 핵심이에요. 아래 표를 통해 두 객체의 특징을 비교해 드릴게요.

결론적으로, 우리는 오늘 레플리카셋을 직접 다루면서 쿠버네티스의 가장 밑바닥에서 돌아가는 복제 메커니즘을 배우는 거예요. 이 원리를 이해하고 나면, 나중에 배포 객체를 사용할 때 발생하는 복잡한 이슈들도 훨씬 쉽게 해결할 수 있게 될 거예요.

레플리카셋 실전 예제: 배포부터 장애 복구까지 5단계

이제 본격적으로 손을 움직여 볼 시간이에요. 이번 실습에서는 간단한 Nginx 웹 서버를 3개의 복제본으로 유지하는 레플리카셋을 만들어 볼 거예요. 단계별로 차근차근 따라와 주세요.

STEP 1. 레플리카셋 매니페스트 작성하기

가장 먼저 해야 할 일은 레플리카셋이 어떻게 동작해야 하는지 정의하는 설계도, 즉 YAML 매니페스트 파일을 만드는 것이에요. 텍스트 에디터를 열고 nginx-rs.yaml이라는 이름으로 파일을 생성해 주세요. 아래 코드를 그대로 복사해서 붙여넣으시면 돼요.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

코드가 조금 길어 보일 수 있지만, 구조는 매우 명확해요. 주의할 점은 selector의 matchLabels와 template의 labels가 반드시 일치해야 한다는 점이에요. 만약 이 둘이 서로 다르면 레플리카셋은 자신이 관리해야 할 파드를 찾지 못해서 무한 루프에 빠지거나 에러를 뱉게 돼요.

replicas: 3 부분은 우리가 항상 유지하고 싶은 파드의 개수를 의미해요. 쿠버네티스는 이 숫자를 보고 클러스터 상태를 끊임없이 체크할 거예요.

STEP 2. 클러스터에 레플리카셋 배포하기

설계도를 완성했다면 이제 실제 클러스터에 이 명령을 전달해야 해요. 터미널을 열고 매니페스트 파일이 있는 디렉토리로 이동한 뒤, 다음 명령어를 입력해 주세요.

kubectl apply -f nginx-rs.yaml

명령어를 실행하면 replicaset.apps/nginx-replicaset created라는 메시지가 출력될 거예요. 이 메시지는 클러스터의 API 서버가 여러분의 요청을 잘 받았고, 이제 레플리카셋을 생성하기 시작했다는 뜻이에요. 하지만 아직 파드가 모두 생성된 것은 아니니 조금만 기다려 주세요.

STEP 3. 동작 상태 및 파드 생성 확인하기

배포가 성공적으로 이루어졌는지 확인하는 과정은 매우 중요해요. 단순히 생성되었다는 메시지만 믿지 말고, 실제 리소스의 상태를 눈으로 직접 확인해야 하거든요. 다음 두 명령어를 차례로 실행해 보세요.

먼저 레플리카셋 자체의 상태를 확인합니다.
kubectl get rs

결과 화면에서 DESIRED는 3, CURRENT는 3, READY도 3으로 표시된다면 아주 완벽한 상태예요. 만약 READY 숫자가 3보다 작다면 파드가 아직 생성 중이거나 이미지를 불러오는 데 문제가 있는 상태일 수 있어요.

그다음, 실제로 생성된 파드들의 목록을 확인합니다.
kubectl get pods -l app=nginx-app

여기서 -l 옵션은 라벨 셀렉터를 사용하는 건데, 우리가 설정한 app: nginx-app 라벨을 가진 파드들만 골라서 보여줘요. 3개의 파드가 각각 Running 상태인지 꼭 확인해 보세요.

STEP 4. 파드 강제 삭제를 통한 자기 치유 검증

자, 이제 이 실습의 하이라이트인 장애 복구 테스트를 진행할 차례예요. 레플리카셋이 정말로 파드를 지켜주는지 확인하기 위해, 우리가 직접 파드 하나를 죽여볼 거예요. 마치 실제 서버에 하드웨어 장애가 발생한 것과 같은 상황을 만드는 거죠.

먼저 실행 중인 파드 중 하나의 이름을 확인합니다.
kubectl get pods

그다음, 확인된 이름 중 하나를 골라 삭제 명령을 내립니다.
kubectl delete pod [파드_이름]

파드가 삭제되는 즉시 터미널에 삭제 메시지가 뜰 거예요. 하지만 여기서 끝내면 안 돼요. 곧바로 다시 kubectl get pods 명령어를 입력해 보세요. 신기하게도 방금 삭제했던 파드 대신, 새로운 이름(예: nginx-replicaset-xxxxx)을 가진 파드가 생성되고 있는 것을 볼 수 있을 거예요. 이것이 바로 쿠버네티스가 보장하는 고가용성의 핵심 원리예요. 레플리카셋은 파드가 줄어든 것을 감지하자마자 즉시 새로운 파드를 생성해 3개의 숫자를 맞추려고 노력한 것이랍니다.

STEP 5. 복제본 개수 조절(Scaling) 실습

마지막으로 서비스의 부하가 늘어났다고 가정하고, 파드의 개수를 늘리는 방법도 익혀두어야 해요. 매니페스트 파일을 직접 수정할 수도 있지만, 실무에서는 명령어로 빠르게 대응하는 경우가 많아요. 파드의 개수를 5개로 늘려볼까요?

kubectl scale rs nginx-replicaset --replicas=5

명령어를 실행한 뒤 다시 kubectl get rs를 입력해 보세요. DESIRED와 CURRENT 값이 5로 변경된 것을 확인할 수 있어요. 반대로 부하가 줄어들었다면 숫자를 줄여서 리소스를 절약할 수도 있겠죠? 이렇게 레플리카셋은 상황에 따라 유연하게 리소스를 관리할 수 있는 아주 강력한 도구예요.

자주 하는 실수와 해결법 및 FAQ

실습을 진행하다 보면 예상치 못한 에러 메시지를 마주할 때가 많아요. 특히 초보자뿐만 아니라 숙련된 엔지니어들도 자주 실수하는 패턴들이 있거든요. 이를 미리 알고 있으면 트러블슈팅 시간을 획기적으로 줄일 수 있어요.

자주 하는 실수와 해결법

• ❌ 실수: 매니페스트의 selector 라벨과 template의 labels가 서로 다름
  → 왜 발생하는가: 복사 붙여넣기 과정에서 오타가 나거나, 라벨 이름을 임의로 변경했기 때문이에요.
  → ✅ 해결법: 두 곳의 라벨이 100% 일치하는지 반드시 확인하세요. 셀렉터는 파드를 찾는 ‘검색 조건’이고 템플레이트는 파드의 ‘생성 조건’이기 때문이에요.
• ❌ 실수: kubectl apply를 했는데 파드가 계속 0개로 유지됨
  → 왜 발생하는가: spec.selector.matchLabels 설정이 잘못되어 레플리카셋이 파드를 제대로 식별하지 못하는 상태예요.
  → ✅ 해결법: kubectl describe rs nginx-replicaset 명령어를 입력하여 이벤트 로그를 확인하세요. 셀렉터 불일치 관련 경고 메시지가 떠 있을 거예요.
• ❌ 실수: YAML 파일의 들여쓰기(Indentation) 오류
  → 왜 발생하는가: YAML은 공백(Space)에 매우 민감한 언어예요. 탭(Tab)을 사용하거나 공백 개수가 틀리면 문법 에러가 발생해요.
  → ✅ 해결법: 가급적 VS Code와 같은 에디터의 YAML 확장 프로그램을 사용하고, 모든 들여쓰기는 2칸 공백으로 통일하세요.
• ❌ 실수: 이미지 이름을 잘못 입력함
  → 왜 발생하는가: nginx:latest 대신 오타가 섞인 이미지를 적으면 파드가 생성되지 않아요.
  → ✅ 해결법: kubectl get pods에서 파드 상태가 ImagePullBackOff라면 이미지 이름을 다시 확인하세요.
• ❌ 실수: 네임스페이스(Namespace) 혼동
  → 왜 발생하는가: 레플리카셋을 default가 아닌 다른 네임스페이스에 만들고, 확인은 default에서 하는 경우예요.
  → ✅ 해결법: kubectl get rs -A 명령어를 사용해 모든 네임스페이스를 검색하거나, 명령 뒤에 -n [네임스페이스명]을 꼭 붙여주세요.

자주 묻는 질문

Q. 레플리카셋 대신 배포(Deployment)만 사용하면 안 되나요?

물론이에요! 실제 운영 환경에서는 배포 객체를 사용하는 것이 표준이에요. 배포 객체는 레플리카셋을 내부적으로 생성하여 관리하면서, 추가로 앱 업데이트와 롤백 기능을 제공하거든요. 하지만 레플리카셋의 동작 방식을 아는 것은 배포 객체가 내부적으로 어떻게 작동하는지 이해하는 데 필수적이에요.

Q. 파드가 삭제되었는데 왜 즉시 다시 생기지 않나요?

보통은 몇 초 내에 생성되지만, 클러스터의 부하가 너무 높거나 노드에 리소스가 부족하면 지연될 수 있어요. 또한, 컨트롤 플레인이 스케줄링을 결정하는 과정에서 약간의 시간이 필요할 수도 있으니 잠시 기다려 보세요.

Q. 레플리카셋의 개수를 줄이면 기존 파드는 어떻게 되나요?

만약 레플리카셋의 개수를 3개에서 1개로 줄이면, 쿠버네티스는 현재 실행 중인 3개의 파드 중 어떤 것을 남길지 결정한 후 나머지 2개를 안전하게 종료(Terminating)시켜요.

Q. 라벨(Label)은 왜 그렇게 중요한가요?

쿠버네티스에서 라벨은 객체들을 서로 연결하는 ‘끈’과 같아요. 레플리카셋은 라벨을 통해 ‘아, 이 파드들이 내가 관리해야 할 파드들이구나!’라고 인식하기 때문에, 라벨 설정이 틀리면 관리 체계가 완전히 무너져 버립니다.

Q. 레플리카셋을 수동으로 삭제하면 어떻게 되나요?

레플리카셋 객체를 삭제하면, 그 레플리카셋이 관리하던 모든 파드도 함께 삭제되어요. 만약 파드만 삭제하고 싶다면 kubectl delete pod을 사용해야 합니다.

완벽한 운영을 위한 마지막 체크리스트

오늘 우리는 레플리카셋을 통해 쿠버네티스의 가장 강력한 기능 중 하나인 자기 치유와 자동 확장 메커니즘을 직접 경험해 보았어요. 이 실습은 단순한 연습을 넘어, 실제 서비스의 가용성을 책임지는 테크리드로서 갖춰야 할 기본 소양을 다지는 과정이었답니다.

성장을 위한 다음 단계

레플리카셋을 마스터했다면, 이제는 다음 단계로 나아갈 차례예요. 오늘 배운 내용을 바탕으로 아래 주제들을 하나씩 정복해 보세요.

• 이번 주 할 일: 레플리카셋을 관리하는 상위 객체인 배포(Deployment)를 공부하고, 롤링 업데이트를 직접 실습해 보세요.
• 오늘 할 일: 작성한 매니페스트 파일을 깃허브(GitHub)에 올려 자신만의 인프라 코드(IaC) 저장소를 만들어 보세요.
• 실행 직전 할 일: 파드가 여러 개일 때, 특정 파드에만 접근하기 위한 서비스(Service) 객체와의 연결을 준비하세요.

실습 중에 설정이 꼬이거나 예상치 못한 에러 메시지가 나와서 당황스러우시다면, 주저하지 말고 아래 댓글로 질문을 남겨 주세요. 함께 고민하고 해결책을 찾아가는 과정이 여러분의 실력을 가장 빠르게 키워줄 거예요. 여러분의 안정적인 클러스터 운영을 응원합니다!

관련하여 더 깊이 있는 내용이 궁금하시다면, 쿠버네티스 레플리카셋 기본 개념 글이나 클러스터 구축 입문 글을 함께 읽어보시는 것을 추천드려요.