8.2 서비스 (Service): 파드 집합에 대한 안정적인 엔드포인트 제공
앞서 8.1장에서 우리는 쿠버네티스 네트워킹의 기본 원칙, 특히 “모든 파드는 고유한 IP를 가진다”는 중요한 개념을 배웠습니다. 하지만 이 파드 IP 주소는 파드가 재시작되거나 다른 노드로 옮겨갈 때마다 변경될 수 있는 비영속적인(ephemeral) 특성을 가지고 있습니다. 만약 우리가 특정 기능을 제공하는 애플리케이션 파드 그룹에 지속적으로 접근해야 한다면, 이렇게 수시로 변하는 파드 IP를 직접 추적하고 관리하는 것은 거의 불가능에 가깝습니다. 마치 단골 식당의 전화번호가 매일 바뀐다면 우리가 그 식당에 예약 전화를 걸기 매우 어려운 것과 마찬가지입니다.
바로 이러한 파드 IP의 비영속성 문제를 해결하고, 논리적으로 동일한 기능을 수행하는 파드 집합에 대해 안정적이고 고정된 접근 지점(엔드포인트)을 제공하기 위해 쿠버네티스가 제공하는 핵심적인 추상화 계층이 바로 **서비스(Service)**입니다. 서비스는 클라이언트(다른 파드 또는 외부 사용자)가 실제 백엔드 파드들의 IP 주소나 개수 변화에 대해 신경 쓸 필요 없이, 마치 단일하고 변하지 않는 대상과 통신하는 것처럼 느끼게 해줍니다. 또한, 서비스는 여러 개의 백엔드 파드들에게 들어오는 요청을 분산시키는 기본적인 로드 밸런싱 기능도 함께 제공합니다.
이번 8.2장에서는 쿠버네티스 애플리케이션 간의 통신과 외부 노출의 핵심이라고 할 수 있는 서비스에 대해 깊이 있게 탐구할 것입니다.
- 먼저 8.2.1 서비스의 필요성 (파드 IP의 비영속성 문제 해결)에서는 왜 우리가 파드 IP를 직접 사용하는 대신 서비스를 사용해야 하는지, 파드의 동적인 생명주기가 애플리케이션 간 통신에 어떤 어려움을 주는지 구체적인 예를 통해 살펴볼 것입니다. 이를 통해 서비스라는 추상화 계층이 등장하게 된 근본적인 이유와 그 가치를 명확히 이해하게 될 것입니다.
- 다음으로 8.2.2 서비스 타입 (Type)에서는 서비스가 클러스터 내부 및 외부로 노출되는 방식에 따라 어떤 종류들이 있는지 알아볼 것입니다. 클러스터 내부에서만 사용되는 기본적인 ClusterIP 타입, 각 노드의 특정 포트를 통해 서비스를 노출하는 NodePort 타입, 클라우드 제공업체의 외부 로드밸런서를 자동으로 프로비저닝하여 서비스를 외부 인터넷에 노출하는 LoadBalancer 타입, 그리고 외부의 다른 서비스를 현재 클러스터 내의 DNS 이름으로 참조할 수 있게 해주는 ExternalName 타입까지, 각 서비스 타입의 특징과 사용 사례를 자세히 비교 분석합니다.
- 이어서 8.2.3 서비스와 셀렉터 (Selector)에서는 서비스가 어떻게 자신과 연결될 파드들을 찾아내고 관리하는지 그 핵심 메커니즘인 레이블과 셀렉터에 대해 다시 한번 강조하며 살펴볼 것입니다. 서비스 명세에 정의된 셀렉터가 파드의 레이블과 어떻게 매칭되어 엔드포인트 목록을 동적으로 유지하는지, 그리고 셀렉터 없이 수동으로 엔드포인트를 지정하는 방법(주로 외부 서비스를 통합할 때 사용)에 대해서도 간략히 언급할 것입니다.
- 마지막으로 8.2.4 [실습] 다양한 서비스 타입 생성 및 테스트에서는 직접 YAML 파일을 작성하여 앞서 배운 다양한 서비스 타입(ClusterIP, NodePort, LoadBalancer – 클라우드 환경이거나 Minikube 등에서 지원 시)을 생성하고, 실제로 이 서비스들을 통해 백엔드 파드에 접근하여 각 타입의 동작 방식을 눈으로 확인하고 체감하는 시간을 가질 것입니다. 이 실습을 통해 서비스의 강력함과 편리함을 직접 경험하고, 실제 애플리케이션 배포 시 어떤 서비스 타입을 선택해야 할지에 대한 감을 잡으실 수 있을 겁니다.
서비스는 쿠버네티스에서 마이크로서비스 아키텍처를 구현하고, 애플리케이션 간의 느슨한 결합(loose coupling)을 가능하게 하는 핵심적인 구성 요소입니다. 이 장을 통해 서비스의 개념과 활용법을 확실히 익히신다면, 쿠버네티스 위에서 더욱 안정적이고 확장 가능한 애플리케이션을 구축하고 운영하는 데 큰 자신감을 얻게 될 것입니다.