4편 · 약 9분
네트워킹과 Service
쿠버네티스 네트워킹의 4가지 전제
쿠버네티스 네트워크 모델은 단순한 규칙 위에 서 있다.
- 모든 Pod는 고유 IP를 가진다.
- 같은 클러스터의 Pod끼리는 NAT 없이 서로 IP로 직접 통신한다.
- 노드도 모든 Pod와 통신할 수 있다.
- Pod가 보는 자기 IP와 남이 보는 그 Pod의 IP가 같다.
이 "평평한(flat) 네트워크"를 실제로 구현하는 건 CNI 플러그인(Calico, Cilium 등)이다.
Pod IP는 못 믿는다 → Service
Pod는 죽고 다시 뜨면서 IP가 바뀐다. 그래서 Pod IP로 직접 호출하면 안 된다. Service는 라벨 셀렉터로 한 묶음의 Pod를 가리키는 안정적인 가상 주소를 제공한다. 트래픽은 Service로 보내고, 뒤의 Pod 집합으로 분산된다.
클라이언트다른 Pod
→
Service (ClusterIP, 고정)app=web 셀렉터
→
엔드포인트 (바뀌는 Pod들)web-1web-2web-3
부하분산은 노드의 kube-proxy가 iptables/IPVS 규칙으로 처리한다.
Service 타입
| 타입 | 노출 범위 | 쓰임 |
|---|---|---|
| ClusterIP (기본) | 클러스터 내부 전용 | 내부 서비스 간 호출 |
| NodePort | 각 노드의 고정 포트로 외부 노출 | 간단한 외부 접근/테스트 |
| LoadBalancer | 클라우드 LB를 붙여 외부 노출 | 운영 외부 진입점 |
| ExternalName | 외부 DNS 이름으로 매핑 | 클러스터 밖 서비스 가리키기 |
서비스 디스커버리: DNS
클러스터 DNS(CoreDNS)가 Service마다 이름을 부여한다. 같은 네임스페이스면 web 만으로, 다르면 web.<namespace>.svc.cluster.local 로 부른다. IP를 몰라도 이름으로 호출하면 된다.
L7 라우팅: Ingress
Service는 L4(주소/포트) 수준이다. "호스트/경로별로 다른 서비스로 보내기"(예: /api → api, / → web), TLS 종료 같은 HTTP 레벨 라우팅은 Ingress + Ingress Controller(nginx 등)가 담당한다. 외부 도메인 하나로 여러 서비스를 묶는 표준 진입점이다.
References
- https://kubernetes.io/docs/concepts/services-networking/service/
- https://kubernetes.io/docs/concepts/services-networking/ingress/
- https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/