들어가며

최근 약 10개월간 재직했던 금융 SI 기업을 떠나, 오는 9월부터 V사에서 데이터 엔지니어로 새로운 커리어를 시작하게 되었다. 새로운 직무를 준비하며 Airflow와 Kubernetes를 깊이 있게 학습하고 있으며, CKA 자격증 취득을 목표로 삼았다.

Udemy의 Kubernetes Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 수강하던 중, ReplicaSet과 Service의 개념이 혼동되어 이번 기회에 블로그에 명확히 정리하고자 한다.

이해를 돕는 비유: 음식점 이야기

ReplicaSet과 Service는 쿠버네티스에서 완전히 다른 역할을 수행한다. 쉽게 이해하기 위해 음식점에 비유해 볼 수 있다.

• **레플리카셋 (ReplicaSet)**은 주방에서 일하는 요리사들 👨‍🍳과 같다.

  • 사장님은 “우리 가게엔 항상 3명의 요리사가 있어야 해!”라는 규칙을 정한다.
  • 한 명의 요리사가 아파서 결원(파드 장애)이 생기면, 매니저(레플리카셋)는 즉시 새로운 요리사를 채용(새로운 파드 생성)하여 항상 3명의 정원을 유지한다.
  • 즉, 레플리카셋은 ‘요리사의 수’를 보장하고 관리하는 역할이다.

• **서비스 (Service)**는 손님을 맞는 ‘주문 창구’ 또는 ‘웨이터’ 🛎️와 같다.

  • 손님은 여러 요리사 중 누가 주문을 받을 수 있는지 일일이 알 필요 없이, 그저 ‘주문 창구’에 가서 주문하면 된다.
  • ‘주문 창구’(서비스)는 현재 일하고 있는 요리사들(파드) 중 가장 적절한 한 명에게 주문을 알아서 전달해 준다.
  • 주방의 요리사가 바뀌더라도 손님은 언제나 동일한 ‘주문 창구’를 이용할 수 있다.
  • 즉, 서비스는 ‘외부와의 안정적인 연결점’을 제공하고 요청을 분배하는 역할이다.

핵심 요약: 역할의 차이

• 레플리카셋 (ReplicaSet): 파드(Pod)의 복제본 수를 관리하고 항상 일정하게 유지한다. 파드에 장애가 발생하면 새로운 파드를 생성하여 고가용성을 보장한다.
• 서비스 (Service): 여러 파드에 대한 **안정적인 단일 네트워크 연결점(고정 IP 주소와 DNS 이름)**을 제공하고, 들어온 요청을 파드들에게 분산(로드 밸런싱)한다.

레플리카셋 (ReplicaSet): ‘개수’를 보장하는 관리자 👮

레플리카셋의 주된 목적은 지정된 수의 동일한 파드가 항상 실행되도록 보장하는 것이다.

주요 기능

• 파드 복제 및 개수 유지: YAML 파일에 정의된 replicas 수만큼 파드를 생성하고 유지한다.
• 장애 복구 (Self-healing): 노드 장애나 파드 에러 등으로 파드가 중단되면, 즉시 새로운 파드를 생성하여 지정된 개수를 맞춘다.
• 확장성 (Scaling): replicas 필드의 값을 변경하여 애플리케이션의 규모를 쉽게 확장하거나 축소할 수 있다.

한계점

레플리카셋이 관리하는 파드들은 생성되거나 교체될 때마다 내부 IP 주소가 계속 변경된다. 따라서 클라이언트가 이 파드들의 IP 주소로 직접 접근하는 방식은 매우 불안정하다.

서비스 (Service): ‘접근’을 담당하는 안내원 🚪

서비스는 레플리카셋(또는 다른 파드 그룹)이 가진 유동적인 네트워크 문제를 해결하기 위해 설계되었다.

주요 기능

• 고정된 단일 진입점 (Single Entrypoint): 서비스는 고유하고 안정적인 가상 IP 주소(ClusterIP)와 DNS 이름을 가진다. 개별 파드의 IP가 계속 바뀌더라도 서비스의 주소는 변하지 않는다.
• 로드 밸런싱 (Load Balancing): 서비스는 자신에게 들어온 네트워크 트래픽을 레이블 셀렉터(Label Selector)를 통해 연결된 여러 파드에게 자동으로 분배한다.
• 서비스 디스커버리 (Service Discovery): 클라이언트(다른 파드 또는 외부 사용자)는 개별 파드의 주소를 알 필요 없이, 서비스의 고정된 주소만으로 애플리케이션에 안정적으로 접근할 수 있다.

한눈에 보는 비교 표

⭐ 핵심 포인트: 실제 사용법

실제 쿠버네티스 환경에서 레플리카셋을 직접 생성하는 경우는 거의 없다. 대신, 롤링 업데이트나 롤백 등 더 정교한 배포 전략을 제공하는 **디플로이먼트(Deployment)**를 사용하는 것이 일반적이다.

디플로이먼트는 내부적으로 레플리카셋을 생성하고 관리하므로, 사용자는 디플로이먼트를 통해 애플리케이션의 상태를 선언적으로 관리한다.

따라서 일반적인 사용 흐름은 다음과 같다.

Deployment (배포 및 업데이트 관리) → ReplicaSet (파드 개수 관리) → Pods (애플리케이션 실행)

그리고 이 파드 그룹을 외부에 안정적으로 노출시키기 위해 Service를 사용한다.