Kubernetes 파드 간 통신의 모든 것 - Service, CoreDNS, kube-proxy, EndpointSlice까지

🤖 AI Assisted Content
이 글은 AI(Claude, Anthropic)의 도움을 받아 작성되었습니다.
작성자가 내용을 검토하고 편집했으나, AI가 초안 작성 및 구성에 참여했음을 밝힙니다.

왜 파드끼리 직접 통신하면 안 될까

Kubernetes를 처음 배우면 자연스럽게 이런 생각을 하게 됩니다. "파드마다 IP가 있으니까, 그냥 IP로 통신하면 되지 않을까?"

안 됩니다. 정확히 말하면 할 수는 있지만 하면 안 됩니다. 두 가지 문제가 있기 때문입니다.

첫째, 파드는 언제든 교체될 수 있고, 교체되면 IP가 바뀝니다. Deployment가 파드를 새로 만들면 이전 파드의 IP는 사라지고 완전히 새로운 IP가 할당됩니다. 클라이언트가 이전 IP로 계속 요청을 보내면 연결이 끊깁니다.

둘째, 교체된 파드의 새 IP를 알아내기가 어렵습니다. 새 IP는 Kubernetes API를 직접 조회해야만 알 수 있습니다. 모든 애플리케이션에 Kubernetes API 클라이언트를 내장하는 건 현실적이지 않습니다.

사실 이 문제는 새로운 게 아닙니다. 인터넷에서도 서버의 IP 주소가 바뀔 수 있기 때문에, 기억하기 쉬운 도메인 네임과 이를 IP로 변환해주는 DNS를 도입해서 해결했습니다. Kubernetes도 같은 전략을 씁니다.

Service — 변하지 않는 가상의 진입점

Kubernetes의 Service는 복수의 파드가 공유할 수 있는 고정된 가상 IP 주소(ClusterIP)입니다. Service는 Deployment처럼 레이블 셀렉터를 사용해서 대상 파드를 느슨하게 연결합니다. 파드가 교체되어도 레이블만 같으면 Service는 자동으로 새 파드를 대상에 포함시킵니다.

apiVersion: v1
kind: Service
metadata:
  name: my-backend
spec:
  selector:
    app: backend    # 이 레이블을 가진 파드들이 대상
  ports:
  - port: 80
    targetPort: 8080

이 Service를 만들면 my-backend라는 이름과 10.96.x.x 형태의 ClusterIP가 할당되고, 이 정보가 클러스터 내부 DNS에 등록됩니다. 다른 파드는 IP 대신 my-backend라는 이름으로 통신할 수 있게 됩니다.

CoreDNS — 클러스터 전용 DNS 서버

"클러스터 내부 DNS"가 바로 CoreDNS입니다. kube-system 네임스페이스에서 Deployment로 실행되는 파드이며, 보통 2개의 레플리카로 고가용성을 확보합니다.

CoreDNS가 하는 일

파드가 my-backend라는 이름으로 요청을 보내면, 파드 내부의 /etc/resolv.conf에 설정된 네임서버(CoreDNS의 Service IP)로 DNS 조회가 이루어집니다.

# 파드 내부의 /etc/resolv.conf (kubelet이 자동 설정)
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

search 리스트 덕분에 my-backend만 입력해도 my-backend.default.svc.cluster.local까지 자동으로 확장됩니다. CoreDNS는 이 FQDN에 매칭되는 Service의 ClusterIP를 반환합니다.

DNS 레코드 형식

Service의 DNS A 레코드 형식은 <service-name>.<namespace>.svc.<cluster-domain>입니다. 같은 네임스페이스 안에서는 서비스명만으로 충분하고, 다른 네임스페이스의 서비스에 접근할 때는 my-backend.other-ns 형태로 네임스페이스를 명시합니다.

CoreDNS의 구조

CoreDNS는 Go로 작성된 단일 바이너리로, 플러그인 체인 방식으로 동작합니다. 설정은 kube-system 네임스페이스의 coredns ConfigMap에 있는 Corefile로 관리됩니다.

.:53 {
    errors
    health { lameduck 5s }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

kubernetes 플러그인이 Service/Pod DNS 레코드를 처리하고, forward가 클러스터 외부 도메인(예: google.com)을 노드의 upstream DNS로 전달합니다.

⚠️ 주의: CoreDNS Service의 이름은 호환성을 위해 kube-dns로 되어 있습니다. kubectl get svc -n kube-system으로 확인하면 kube-dns라는 이름이 보이지만, 실제로 실행되는 것은 CoreDNS 파드입니다.

kube-proxy — 가상 IP를 실제 파드로 연결하는 마법

여기서 한 가지 의문이 생깁니다. CoreDNS가 반환한 ClusterIP(예: 10.96.100.50)는 가상 IP입니다. 어떤 네트워크 인터페이스에도 바인딩되지 않고, 실제로 "존재"하지 않는 IP입니다. 그런데 파드가 이 가상 IP로 패킷을 보내면 어떻게 실제 백엔드 파드에 도착할까요?

이 마법을 수행하는 것이 kube-proxy입니다.

kube-proxy의 역할

kube-proxy는 클러스터의 모든 노드에서 실행되는 네트워크 프록시입니다. DaemonSet으로 배포되어 각 노드에 하나씩 존재합니다. kube-proxy는 Kubernetes API 서버를 watch하면서 Service와 EndpointSlice 오브젝트의 변경을 감시하고, 변경이 감지되면 커널 수준에서 패킷 포워딩 규칙을 업데이트합니다.

이 규칙이 하는 핵심 동작은 DNAT(Destination NAT) — 패킷의 목적지 주소를 ClusterIP에서 실제 백엔드 파드 IP로 바꿔치기하는 것입니다.

전체 통신 흐름

Pod A: "my-backend에 요청을 보내자"
  ↓
/etc/resolv.conf → nameserver 10.96.0.10 (CoreDNS)
  ↓
CoreDNS: "my-backend.default.svc.cluster.local → 10.96.100.50"
  ↓
Pod A가 10.96.100.50:80으로 TCP 연결
  ↓
노드의 netfilter (kube-proxy가 설치한 규칙)
  ↓
DNAT: 10.96.100.50 → 10.244.2.10 (백엔드 파드 중 하나)
  ↓
Pod B가 요청을 수신

프록시 모드

kube-proxy에는 3가지 주요 모드가 있으며, 커널에서 규칙을 관리하는 방식이 다릅니다.

iptables 모드 (현재 기본값)는 Linux 커널의 netfilter/iptables를 사용합니다. 서비스와 엔드포인트마다 iptables 규칙을 생성하며, 백엔드 파드 선택은 확률 기반 랜덤 방식입니다. 모든 처리가 커널 공간에서 이루어져 빠르지만, 서비스 수가 수만 개로 늘어나면 규칙이 O(n)으로 증가하여 성능이 저하됩니다.

실제 iptables 규칙을 보면 동작 원리가 명확해집니다:

# 1단계: ClusterIP로 들어오는 패킷을 서비스 체인으로 전달
-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp --dport 80 \
   -j KUBE-SVC-NWV5X2332I4OT4T3

# 2단계: 확률 기반으로 백엔드 파드 선택 (3개 파드 = 각 33%)
-A KUBE-SVC-... --probability 0.33333 -j KUBE-SEP-aaa
-A KUBE-SVC-... --probability 0.50000 -j KUBE-SEP-bbb
-A KUBE-SVC-...                       -j KUBE-SEP-ccc

# 3단계: DNAT — 목적지를 실제 파드 IP로 변환
-A KUBE-SEP-aaa -p tcp -j DNAT --to-destination 10.244.1.7:9376
-A KUBE-SEP-bbb -p tcp -j DNAT --to-destination 10.244.2.3:9376
-A KUBE-SEP-ccc -p tcp -j DNAT --to-destination 10.244.3.6:9376

💡 포인트: KUBE-SERVICES → KUBE-SVC-* → KUBE-SEP-* 3단계 체인 구조로, 서비스 매칭 → 로드밸런싱 → DNAT가 순서대로 이루어집니다.

IPVS 모드 (v1.11부터 안정)는 커널의 IP Virtual Server를 사용합니다. 해시 테이블 기반으로 동작하여 O(1) 성능을 제공하며, 라운드로빈(rr), 최소 연결(lc), 목적지 해싱(dh) 등 다양한 로드밸런싱 알고리즘을 지원합니다. 대규모 클러스터에서 iptables의 성능 한계가 문제가 될 때 대안으로 사용됩니다.

nftables 모드 (v1.31부터 베타)는 가장 최신 모드로, 변경된 서비스/엔드포인트만 증분 업데이트하여 iptables와 IPVS 모두를 대체하도록 설계되었습니다.

EndpointSlice — 서비스와 파드를 연결하는 목록

Service가 "레이블 셀렉터로 파드를 선택한다"고 했는데, 실제로 "어떤 파드들이 매칭되는지"를 기록하는 리소스가 EndpointSlice입니다. 레이블 셀렉터에 매칭되는 파드들의 IP:Port 목록을 담고 있으며, 파드가 추가/삭제/교체될 때 자동으로 갱신됩니다.

그런데 EndpointSlice를 참고하는 컴포넌트가 두 개 있습니다 — CoreDNS와 kube-proxy. 둘 다 system:coredns / system:node-proxier ClusterRole에 EndpointSlice에 대한 list/watch 권한을 가지고 있습니다.

그렇다면 두 컴포넌트가 항상 EndpointSlice를 함께 참고하는 걸까요?

흥미로운 사실: 정확히 반대로 동작한다

결론부터 말하면, 같은 Service에 대해 두 컴포넌트가 동시에 EndpointSlice를 참고하는 경우는 없습니다.

일반 Service (ClusterIP가 있는 경우)에서는 CoreDNS는 Service 오브젝트의 ClusterIP만 반환하면 되므로 EndpointSlice를 참고하지 않습니다. 대신 kube-proxy가 EndpointSlice를 참고해서 "ClusterIP → 실제 파드 IP" 매핑 규칙(iptables/IPVS)을 만듭니다.

[일반 Service]
CoreDNS    → Service 오브젝트 참고 (ClusterIP 반환)
kube-proxy → EndpointSlice 참고 (iptables/IPVS 규칙 생성)

Headless Service (ClusterIP: None)에서는 ClusterIP가 없으므로 CoreDNS가 EndpointSlice를 참고해서 파드 IP 목록을 직접 DNS 응답으로 반환합니다. kube-proxy는 처리할 ClusterIP가 없으므로 아예 관여하지 않습니다.

[Headless Service]
CoreDNS    → EndpointSlice 참고 (파드 IP 목록 반환)
kube-proxy → 관여하지 않음

정리하면 이렇습니다:

컴포넌트	일반 Service	Headless Service
CoreDNS	Service 오브젝트 (ClusterIP)	EndpointSlice (파드 IP 목록)
kube-proxy	EndpointSlice (라우팅 규칙)	관여 안 함

서비스 유형에 따라 역할이 깔끔하게 나뉘는 구조입니다.

전체 아키텍처 한눈에 보기

지금까지 설명한 컴포넌트들의 관계를 하나의 흐름으로 정리하면 다음과 같습니다.

확인 명령어 모음

# CoreDNS 파드 상태 확인
kubectl get pods -n kube-system -l k8s-app=kube-dns

# kube-proxy 파드 확인
kubectl get pods -n kube-system -l k8s-app=kube-proxy

# 서비스의 EndpointSlice 확인
kubectl get endpointslices -l kubernetes.io/service-name=my-backend

# DNS 해석 테스트 (dnsutils 파드에서)
kubectl exec -it dnsutils -- nslookup my-backend.default.svc.cluster.local

# 파드 내부 resolv.conf 확인
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# kube-proxy 모드 확인 (노드에서 실행)
curl http://localhost:10249/proxyMode

# iptables 모드: 서비스 관련 규칙 확인
iptables-save | grep KUBE-SVC

# IPVS 모드: 가상 서버 테이블 확인
ipvsadm -ln

마무리

Kubernetes 파드 간 통신은 결국 4개의 핵심 컴포넌트가 협력하는 구조입니다. Service가 고정된 진입점을 제공하고, CoreDNS가 서비스명을 ClusterIP로 변환하고, kube-proxy가 ClusterIP를 실제 파드 IP로 라우팅하며, EndpointSlice가 "어떤 파드가 현재 이 서비스의 백엔드인지"를 추적합니다.

특히 EndpointSlice의 경우, 일반 Service에서는 kube-proxy만, Headless Service에서는 CoreDNS만 참고한다는 점이 핵심입니다. 서비스 유형에 따라 역할이 깔끔하게 분리되어 있다는 것을 이해하면, 네트워크 트러블슈팅 시 어디를 봐야 할지도 명확해집니다.

다음 글에서는 Service의 유형별 차이(ClusterIP, NodePort, LoadBalancer, ExternalName)와 Ingress/Gateway API를 통한 외부 트래픽 라우팅을 다뤄보겠습니다.

참고 문서

• DNS for Services and Pods | Kubernetes
• Virtual IPs and Service Proxies | Kubernetes
• Service | Kubernetes
• Using CoreDNS for Service Discovery | Kubernetes
• IPVS-Based In-Cluster Load Balancing Deep Dive | Kubernetes
• Debugging DNS Resolution | Kubernetes
• NFTables mode for kube-proxy | Kubernetes