쿠버네티스 서비스(Kubernetes Service)의 이론과 실천

“In theory, there is no difference between theory and practice. In practice, there is.”
– Jan L. A. van de Snepscheut

서론

현대의 분산 시스템에서 마이크로서비스 아키텍처(MSA)는 서비스 간의 유기적인 연결을 전제로 한다. 그러나 컨테이너 기반의 인프라에서 컨테이너는 생성과 소멸이 자유로운 반면, 그들 간의 네트워크 주소는 영속적이지 않다. 이때 등장하는 개념이 바로 쿠버네티스 서비스(Kubernetes Service)이다.

쿠버네티스 서비스는 동적으로 변하는 파드(Pod) 들에 대해 안정적인 네트워크 접근점을 제공한다. 본 칼럼에서는 쿠버네티스 서비스의 개념적 정의부터 동작 원리, 유형별 특성, 그리고 실무에서의 응용까지 총체적으로 조망하고자 한다.

---

1. 정의

쿠버네티스에서 “서비스(Service)“는 논리적 파드 집합에 대한 추상화된 네트워크 엔드포인트를 의미한다. 일반적으로 라벨 셀렉터(Label Selector)를 통해 특정 조건의 파드 집합을 선택하고, 해당 파드로의 트래픽을 라운드로빈 방식으로 분산한다.

즉, 서비스는 다음 두 가지 기능을 수행한다.

1. Service Discovery: 고정된 DNS 이름으로 파드 집합에 접근할 수 있게 한다.
2. Load Balancing: 요청을 여러 파드에 분산하여 고가용성과 성능을 확보한다.

서비스는 단순한 네트워크 라우팅 역할을 넘어, 시스템 아키텍처 안정성의 핵심 축이다. 애플리케이션 설계 초기 단계부터 어떤 서비스 유형이 필요한지 구상하는 습관이 중요.

---

2. 유형별 비교 분석

쿠버네티스는 다양한 사용 사례에 맞춰 총 4가지 주요 서비스 유형을 제공한다.

2.1 ClusterIP (기본값)

• 정의: 클러스터 내부에서만 접근 가능한 IP를 부여받음.
• 용도: 내부 서비스 간 통신 (예: 백엔드 ↔ DB)
• 예시

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

DNS: backend.default.svc.cluster.local

ClusterIP는 반드시 클러스터 내부 통신에만 사용된다. 만약 개발자가 외부 브라우저에서 접속하려고 한다면 동작하지 않는 것이 정상이다. 이를 혼동하지 않도록 주의.

2.2 NodePort

• 정의: 각 노드의 고정 포트(30000~32767)를 통해 외부에서 접근 가능
• 용도: 간단한 외부 노출, 테스트용
• 한계: 로드 밸런싱 기능 없음, 보안 및 확장성 문제 존재

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

접속 주소: http://<NodeIP>:30080

NodePort는 설정이 간단하지만 보안성과 유지보수성이 떨어지는 구조이다. 클러스터가 확장될수록 관리 포트가 충돌하거나 노드 간 트래픽 분산이 어려워질 수 있다.

2.3 LoadBalancer

• 정의: 클라우드 제공자의 L4 Load Balancer를 생성하여 외부 노출
• 용도: 프로덕션 레벨의 트래픽 대응
• 장점: Public IP 할당, 외부 접근 가능
• 단점: 퍼블릭 클라우드 의존, 비용 발생

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

AWS에서는 ELB가 생성됨 (보통 Classic 또는 NLB)

퍼블릭 클라우드(AWS, GCP, Azure 등)에서는 LoadBalancer 서비스가 외부 로드 밸런서를 자동으로 생성해주지만, 온프레미스 환경에서는 MetalLB 같은 솔루션이 필요하다.

2.4 ExternalName

• 정의: 외부 도메인명을 내부 DNS로 연결
• 용도: 외부 서비스를 쿠버네티스 네트워크에 통합
• 예시

spec:
  type: ExternalName
  externalName: database.example.com

사용자는 db-service.default.svc.cluster.local 으로 접근 → 외부 DNS로 리디렉션됨

ExternalName은 단순히 DNS alias 역할을 한다. 따라서 실제 외부 주소에 대한 가용성이나 인증 문제는 별도로 고려해야 한다.

---

3. 서비스 디스커버리와 DNS

쿠버네티스 클러스터에는 기본적으로 CoreDNS가 설치되어 있으며, 각 서비스에 대해 다음과 같은 DNS 레코드를 자동 생성한다.

• [서비스명].[네임스페이스].svc.cluster.local
• 예: frontend.default.svc.cluster.local

서비스와 파드는 모두 IP 변경 가능성이 있기 때문에, 서비스는 일종의 추상화된 가상 IP (VIP) 역할을 수행한다.

 

DNS Resolution 과정은 다음과 같다.

1. 애플리케이션이 서비스 이름으로 접근
2. CoreDNS가 클러스터 DNS를 참조
3. 해당 서비스에 연결된 엔드포인트(Pod) 목록 중 하나로 트래픽 전달

DNS 기반 서비스 탐색은 CoreDNS의 안정성에 크게 의존한다. dnsPolicy: Default 설정으로 CoreDNS가 아닌 OS 레벨의 DNS를 사용하는 경우도 있으니, 네트워크 이슈 발생 시 해당 설정도 확인해야 한다.

---

4. 내부 동작: kube-proxy와 iptables/ipvs

서비스의 트래픽 분산은 kube-proxy에 의해 처리된다. 두 가지 동작 방식이 존재한다:

• iptables 모드: 커널 레벨에서 네트워크 패킷을 포워딩
• ipvs 모드: 성능이 더 높은 커널 모듈 기반의 로드밸런서

kube-proxy는 Service → Endpoints → Pod로 연결되는 라우팅 테이블을 주기적으로 갱신하며, 실질적인 트래픽 분산은 커널이 수행한다.

고성능이 요구되는 대규모 클러스터에서는 kube-proxy를 ipvs 모드로 설정하는 것이 좋다. --proxy-mode=ipvs 플래그를 설정하면 보다 효율적인 트래픽 분산이 가능하다.

---

5. 실전 적용 사례와 설계 시 고려사항

5.1 설계 시 주요 고려사항

고려 항목	설명
내부 or 외부 노출	ClusterIP vs LoadBalancer
클라우드 환경	퍼블릭 클라우드라면 LoadBalancer 활용 가능
서비스 디스커버리 방식	DNS 기반 접근이 기본이지만, 서비스 Mesh와 연계 가능
보안 정책	NetworkPolicy와 함께 적용 필요
Auto Scaling 대응	Pod 개수에 따라 kube-proxy 테이블이 갱신됨

5.2 실제 사례

• 웹 프론트엔드: LoadBalancer로 외부 노출
• 백엔드 서비스: ClusterIP로 내부 통신
• RDS 연동 등 외부 서비스 접근: ExternalName

서비스 설계 시 “지금은 필요 없지만 미래에는 외부 노출이 필요할 수도 있다”는 가능성을 고려해, type을 쉽게 변경할 수 있도록 Helm Chart나 Kustomize로 유연하게 관리하는 것이 좋다.

---

6. 진화: 서비스 메시와 인그레스의 통합

쿠버네티스 네트워크 모델은 현재 서비스 메시(Service Mesh, 예: Istio, Linkerd) 와의 통합을 통해 더욱 정교해지고 있다. 이들은 트래픽 제어, 인증, 관찰성 등을 서비스 레벨에서 제공하며, 단순한 L4 포워딩을 넘어서 L7 기반의 제어를 가능케 한다.

 

또한, 서비스와 별개로 인그레스(Ingress) 자원을 통해 HTTP 기반 트래픽에 대한 라우팅 정책도 설정할 수 있어, 쿠버네티스의 서비스 모델은 점점 더 고급화된 네트워크 컴포넌트로 확장되고 있다.

Istio, Linkerd 같은 서비스 메시 도입 시 기존 서비스 리소스와의 역할 충돌을 피하려면, sidecar injection, virtualService 등의 정책을 명확히 구분하고 관리해야 한다.

---

마무리

쿠버네티스 서비스는 단순한 파드 연결 도구를 넘어서, 마이크로서비스 생태계의 근간을 이루는 핵심 구성요소이다. 서비스는 동적 인프라 환경에서 안정성과 가용성을 확보하는 핵심 메커니즘이며, 올바른 설계 없이는 시스템 전체의 신뢰성이 무너질 수 있다.