Service 4가지 타입 — ClusterIP 위에 쌓아 올린 계층 구조
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 Kubernetes 공식문서 Service
이 모듈을 다 읽으면
- ClusterIP/NodePort/LoadBalancer가 서로 독립적이지 않고 하위 타입을 그대로 포함하며 확장되는 계층 구조임을 설명할 수 있다
- ExternalName이 나머지 세 타입과 근본적으로 다른 방식(DNS 매핑)으로 동작한다는 것을 설명할 수 있다
k8s-learn-03의 헤드리스 서비스가 '특수 케이스'였다면, 이 모듈은 일반적으로 쓰는 네 가지 Service 타입이 서로 어떤 계층 관계를 이루는지 정리한다.
ClusterIP → NodePort → LoadBalancer — 각자가 이전 단계를 포함한다
ClusterIP는 기본값으로, 클러스터 내부에서만 접근 가능한 가상 IP 하나를 만든다. NodePort는 이 ClusterIP 기능 위에 '클러스터의 모든 노드 IP에서 고정 포트로도 접근 가능하게' 하는 기능을 추가한다 — 즉 NodePort Service는 ClusterIP도 여전히 가지고 있다. LoadBalancer는 다시 NodePort 위에 클라우드 제공자의 외부 로드밸런서를 프로비저닝하는 기능을 얹은 것이다 — 그래서 LoadBalancer Service는 ClusterIP와 NodePort를 전부 가진 채로, 외부 로드밸런서가 그 NodePort로 트래픽을 전달하는 구조다.
핵심 포인트
- ClusterIP(기본, 클러스터 내부 전용 가상 IP) → NodePort(모든 노드의 고정 포트로도 접근, ClusterIP도 여전히 유지) → LoadBalancer(NodePort 위에 클라우드 외부 로드밸런서 프로비저닝)
- 상위 타입은 하위 타입 기능을 전부 포함한 채 확장하는 구조 — 서로 독립적인 대안이 아님
ExternalName — 트래픽 라우팅이 아니라 DNS 매핑
ExternalName은 나머지 세 타입과 완전히 다른 메커니즘이다 — 가상 IP나 프록시를 두는 대신, 클러스터 내부 DNS 이름을 외부 DNS 이름으로 CNAME 매핑만 해준다. 즉 클러스터 안의 Pod가 이 Service 이름으로 조회하면 kube-proxy의 트래픽 라우팅을 거치지 않고 곧바로 외부 DNS 이름으로 리졸브된다 — 클러스터 밖 관리형 데이터베이스처럼, Kubernetes가 실제로 트래픽을 다루지 않고 이름만 대신 알려주면 되는 경우에 쓴다.
핵심 포인트
- ExternalName은 가상 IP·프록시 없이 클러스터 내부 DNS를 외부 DNS 이름으로 CNAME 매핑만 함 — kube-proxy 트래픽 라우팅을 거치지 않음
- 클러스터 밖 외부 시스템(관리형 DB 등)을 클러스터 내부 이름으로 참조하고 싶을 때 사용