Kubernetes 네트워킹 완전 정복: DNS부터 서비스, 크로스 노드 통신까지

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

왜 쿠버네티스 네트워킹을 이해해야 하는가

쿠버네티스를 학습하다 보면 파드를 배포하고 디플로이먼트를 만드는 것까지는 비교적 수월하게 따라간다. 하지만 "이 파드에서 저 파드로 어떻게 통신하지?", "외부에서 어떻게 접근하지?" 같은 질문에 부딪히는 순간 네트워킹이라는 벽을 만나게 된다.

이 글에서는 쿠버네티스 네트워킹의 핵심 3가지를 정리한다:

1. 파드 간 내부 통신 — DNS와 CoreDNS의 역할
2. 서비스 유형별 트래픽 흐름 — ClusterIP, LoadBalancer, NodePort, ExternalName
3. 다른 노드에 있는 파드끼리의 통신 — CNI와 VXLAN Overlay

---

1. 파드 간 통신의 근본적인 문제

파드가 다른 파드와 통신하려면 IP 주소가 필요하다. 그런데 여기서 두 가지 문제가 발생한다.

첫째, 파드는 일시적(ephemeral)이다. 파드가 재생성되면 IP 주소가 바뀐다. 둘째, 바뀐 IP를 알 방법이 마땅치 않다. 새 IP를 파악하려면 Kubernetes API를 직접 호출해야 한다.

인터넷에서 이 문제를 어떻게 해결했는지 떠올려 보면, 답은 같다. 도메인 네임 시스템(DNS)이다. 쿠버네티스도 클러스터 전용 DNS 서버를 두고, 서비스 이름과 IP 주소를 매핑하여 이 문제를 해결했다.

서비스 — 파드를 위한 안정적인 진입점

서비스(Service)는 파드들이 공유하는 가상 주소(Virtual IP)다. 디플로이먼트가 레이블 셀렉터로 파드를 관리하듯, 서비스도 레이블 셀렉터로 대상 파드와 느슨하게 연결된다. 이때 서비스와 파드 사이에는 Endpoints(또는 EndpointSlice) 리소스가 중간 다리 역할을 한다. 셀렉터에 일치하는 파드의 IP:Port 목록이 Endpoints에 자동 등록되고, kube-proxy는 이 목록을 참조하여 트래픽을 라우팅한다.

서비스가 없는 파드는 도메인 네임으로 접근할 수 없다. 서비스를 만들어야 DNS 레코드가 생성되고, 다른 파드에서 이름으로 통신할 수 있게 된다.

---

2. CoreDNS — 쿠버네티스의 전용 DNS 서버

쿠버네티스의 "전용 DNS 서버"는 바로 CoreDNS 파드다.

CoreDNS는 Go 언어로 작성된 플러그인 기반의 DNS 서버로, Kubernetes 1.11부터 기본 클러스터 DNS로 채택되었다. 이전에 사용하던 kube-dns는 dnsmasq + kube-dns + sidecar 3개의 컨테이너로 구성되었지만, CoreDNS는 단일 컨테이너, 단일 프로세스로 동작해 훨씬 단순하다.

CoreDNS 배포 구조

구성 요소	이름	설명
Deployment	coredns	kube-system 네임스페이스, 기본 2 레플리카 (고가용성)
Service	kube-dns	kube-system 네임스페이스. 이름이 "kube-dns"인 이유는 하위 호환성
ConfigMap	coredns	Corefile(설정 파일)을 담고 있음
ClusterRole	system:coredns	Service, Endpoints, Pod, Namespace에 대한 list/watch 권한

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

# CoreDNS 서비스의 ClusterIP 확인
kubectl get svc -n kube-system kube-dns
# NAME       TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)                  AGE
# kube-dns   ClusterIP   192.168.194.138   <none>        53/UDP,53/TCP,9153/TCP   573d

Corefile — CoreDNS의 핵심 설정

.:53 {
    errors                          # 에러를 stdout으로 출력
    health { lameduck 5s }          # 헬스체크 엔드포인트
    ready                           # readiness 프로브 엔드포인트

    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure               # 파드 A 레코드 생성 (kube-dns 호환)
        fallthrough in-addr.arpa ip6.arpa
        ttl 30                      # DNS TTL 30초
    }

    prometheus :9153                # 메트릭 노출
    forward . /etc/resolv.conf      # cluster.local 외 쿼리를 upstream DNS로 전달
    cache 30                        # 30초간 응답 캐시
    loop                            # 무한 루프 감지 시 종료
    reload                          # Corefile 변경 시 자동 리로드
    loadbalance                     # A/AAAA 레코드 라운드로빈
}

가장 중요한 것은 kubernetes 플러그인이다. CoreDNS가 시작되면 Kubernetes API 서버에 연결하여 Service, Endpoints, Pod 리소스를 watch하고, 수신한 정보를 인메모리에 캐시한다. DNS 쿼리가 들어오면 API 서버에 매번 질의하지 않고 캐시에서 바로 응답한다. 서비스가 생성/삭제되면 watch 이벤트를 통해 실시간으로 캐시가갱신된다.

DNS 조회 전체 흐름 (7단계)

파드에서 서비스로 트래픽이 전달되는 전체 과정은 다음과 같다.

1. 파드 내 애플리케이션이 서비스 이름(예: my-service)으로 요청을 보낸다.
2. 파드의 /etc/resolv.conf에 지정된 nameserver(CoreDNS의 ClusterIP)로 DNS 쿼리가 전송된다.
3. resolv.conf의 search 도메인에 따라 my-service.<namespace>.svc.cluster.local로 확장된다.
4. CoreDNS가 캐시에서 해당 서비스의 ClusterIP를 찾아 반환한다.
5. 파드가 반환받은 ClusterIP로 패킷을 전송한다.
6. kube-proxy가 설정한 iptables/IPVS 규칙에 의해 ClusterIP가 실제 파드 IP로 DNAT된다.
7. 패킷이 CNI 플러그인이 구성한 네트워크를 통해 대상 파드에 도달한다.

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

💡 ndots:5란? 쿼리에 점(.)이 5개 미만이면 FQDN이 아닌 것으로 간주하고, search 도메인을 앞에서부터 하나씩 붙여서 조회한다. my-service라고 입력하면 먼저 my-service.default.svc.cluster.local을 시도하는 이유다.

DNS 이름 해석 규칙

쿼리	해석 결과	설명
my-service	my-service.default.svc.cluster.local	같은 네임스페이스
my-service.prod	my-service.prod.svc.cluster.local	다른 네임스페이스
my-service.prod.svc.cluster.local	그대로	FQDN 직접 조회
google.com	upstream DNS로 forward	cluster.local에 없는 외부 도메인

CoreDNS가 생성하는 DNS 레코드

레코드	대상	FQDN 형식	반환값
A/AAAA	일반 Service	<svc>.<ns>.svc.cluster.local	ClusterIP
A/AAAA	Headless Service	<svc>.<ns>.svc.cluster.local	파드 IP 목록
SRV	이름 있는 포트	_<port>._<proto>.<svc>.<ns>.svc.cluster.local	포트 번호 + 도메인
CNAME	ExternalName Service	<svc>.<ns>.svc.cluster.local	외부 도메인명

네임스페이스와 DNS

모든 쿠버네티스 리소스는 네임스페이스 안에 존재한다. 같은 네임스페이스에서는 서비스 이름만으로 접근 가능하고, 다른 네임스페이스의 서비스는 FQDN이 필요하다.

# 같은 네임스페이스 (default → default)
kubectl exec deploy/sleep-1 -- sh -c 'nslookup numbers-api'
# → numbers-api.default.svc.cluster.local → 192.168.194.228

# 다른 네임스페이스의 서비스 (default → kube-system)
kubectl exec deploy/sleep-1 -- sh -c 'nslookup kube-dns.kube-system.svc.cluster.local'
# → 192.168.194.138

---

3. 서비스 유형별 트래픽 흐름

ClusterIP — 클러스터 내부 전용

가장 기본이 되는 서비스 유형이다. 클러스터 전체에서 유효한 가상 IP를 생성하며, 파드가 어느 노드에 있든 이 IP로 접근 가능하다. 단, 클러스터 외부에서는 접근 불가하다.

kubectl apply -f sleep/sleep2-service.yaml
# service/sleep-2 created

kubectl get svc sleep-2
# NAME      TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
# sleep-2   ClusterIP   192.168.194.221   <none>        80/TCP    7s

⚠️ ClusterIP로는 ping이 안 된다. ClusterIP는 네트워크 인터페이스에 바인딩된 실제 IP가 아니라, kube-proxy가 iptables 규칙으로 특정 프로토콜:포트 조합에 대해서만 DNAT을 수행하는 가상 IP다. 포트 개념이 없는 ICMP(ping) 패킷은 매칭되는 규칙이 없어 드롭된다.

# ping은 실패한다
kubectl exec deploy/sleep-1 -- ping -c 1 sleep-2
# PING sleep-2 (192.168.194.221): 56 data bytes
# (응답 없음)

# TCP 기반 확인은 성공한다
kubectl exec deploy/sleep-1 -- wget -qO- http://sleep-2
kubectl exec deploy/sleep-1 -- nc -zv sleep-2 80

LoadBalancer — 외부 트래픽의 프로덕션 진입점

외부에서 클러스터로 트래픽을 전달하는 가장 일반적인 방법이다. 클라우드 환경에서는 실제 로드밸런서가 프로비저닝된다.

kubectl get svc numbers-web
# NAME          TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
# numbers-web   LoadBalancer   192.168.194.241   192.168.139.2   8080:30732/TCP   61s

여기서 주목할 점은 8080:30732/TCP라는 출력이다. 8080은 서비스 포트, 30732는 자동 생성된 NodePort다. 이것이 서비스의 Superset 구조를 보여준다:

┌──────────────────────────────────────┐
│       LoadBalancer Service            │
│  ┌──────────────────────────────────┐ │
│  │      NodePort Service             │ │
│  │  ┌──────────────────────────────┐ │ │
│  │  │    ClusterIP Service          │ │ │
│  │  │    (가상 IP: 10.96.x.x)       │ │ │
│  │  └──────────────────────────────┘ │ │
│  │  NodePort: 30000-32767            │ │
│  └──────────────────────────────────┘ │
│  External LB + External IP            │
└──────────────────────────────────────┘

LoadBalancer를 만들면 NodePort와 ClusterIP가 자동으로 포함된다. 즉, LoadBalancer 서비스는 외부 IP + NodePort + ClusterIP 세 가지 접근 방식을 모두 가진다.

💡 분산 환경에 따른 차이: 같은 YAML 매니페스트라도 환경에 따라 결과가 달라진다. Docker Desktop은 localhost 주소를 사용하고, K3s는 호스트 VM IP를 사용하며, AKS/EKS 같은 클라우드에서는 공인 IP가 할당된다. 쿠버네티스가 동일하더라도 로드밸런서를 구현하는 방식에 차이가 있기 때문이다.

NodePort — 간단하지만 제약이 있는 외부 접근

외부 로드밸런서 없이 모든 노드의 특정 포트(기본 30000-32767)를 개방하여 트래픽을 받는 방식이다. 트래픽이 특정 노드로 들어온 후에는 kube-proxy가 클러스터 전체의 파드로 분산한다.

단, NodePort는 노드 수준의 로드밸런싱이 없다는 것이 핵심 단점이다. 외부에서 특정 노드 하나로만 요청이 집중될 수 있으며, 노드들 사이에서 트래픽을 분산하는 외부 로드밸런서의 역할이 빠져 있다.

externalTrafficPolicy — 알아두면 좋은 설정

LoadBalancer와 NodePort 서비스에는 externalTrafficPolicy라는 중요한 설정이 있다:

값	동작	장점	단점
Cluster (기본)	클러스터 전체 파드로 분산	균등 분산	다른 노드로 추가 홉 발생, 클라이언트 IP가 SNAT됨
Local	요청 받은 노드의 파드로만 전달	클라이언트 원본 IP 보존, 추가 홉 없음	해당 노드에 파드가 없으면 트래픽 드롭

---

4. 클러스터 외부로 트래픽 전달하기

쿠버네티스 클러스터 내부 파드가 외부 시스템(매니지드 DB, 외부 API 등)과 통신해야 할 때가 있다. 이때 로컬 도메인 네임을 활용하여 외부를 가리키는 두 가지 방법이 있다.

ExternalName 서비스 — DNS 수준의 리다이렉트

ExternalName 서비스는 로컬 서비스 이름을 외부 도메인의 CNAME으로 치환하는 방식이다. 파드는 클러스터 내부 이름만 알고 있으면 되고, 쿠버네티스 DNS가 이를 외부 도메인으로 해소해준다.

apiVersion: v1
kind: Service
metadata:
  name: numbers-api
spec:
  type: ExternalName
  externalName: raw.githubusercontent.com

kubectl exec deploy/sleep-1 -- sh -c 'nslookup numbers-api | tail -n 5'
# Name:   raw.githubusercontent.com
# Address: 185.199.111.133
# Address: 185.199.108.133

⚠️ HTTP Host 헤더 문제: ExternalName의 가장 큰 제약이다. HTTP 요청 시 Host 헤더에는 파드가 알고 있는 로컬 이름(numbers-api)이 들어간다. 외부 서버(GitHub)는 Host: numbers-api를 인식하지 못하므로 요청이 실패한다. 비유하자면, 편지가 올바른 건물(GitHub 서버)에 도착했지만 편지 안에 "수신: numbers-api 귀하"라고 적혀 있어서 건물 관리인이 "그런 사람 없는데요?"라고 거부하는 셈이다. HTTPS의 경우 TLS SNI 불일치로 인증서 검증 자체가 실패하므로 더 심각하다.

TCP 프로토콜(DB 등)은 Host 헤더 개념이 없으므로 이 문제가 발생하지 않는다. 따라서 ExternalName은 TCP 기반 외부 서비스(DB 등)에 적합하다.

주의할 점이 하나 더 있다. externalName 필드에 IP 주소 문자열(예: 1.2.3.4)을 넣으면 IP가 아닌 DNS 이름으로 취급되어 조회가 실패한다. IP 주소로 연결하려면 다음 방식을 사용해야 한다.

셀렉터 없는 서비스 + 수동 Endpoints — IP 수준의 프록시

ExternalName이 DNS 수준에서 동작한다면, 이 방식은 kube-proxy를 통한 IP 수준 프록시다. ClusterIP 서비스를 셀렉터 없이 만들고, Endpoints 리소스에 외부 IP를 직접 지정한다.

apiVersion: v1
kind: Service
metadata:
  name: numbers-api
spec:
  type: ClusterIP
  ports:
    - port: 80
---
kind: Endpoints
apiVersion: v1
metadata:
  name: numbers-api   # 서비스와 이름이 같아야 한다
subsets:
  - addresses:
      - ip: 192.168.123.234
    ports:
      - port: 80

kubectl get svc numbers-api
# NAME          TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
# numbers-api   ClusterIP   192.168.194.228   <none>        80/TCP    4m27s

kubectl exec deploy/sleep-1 -- sh -c 'nslookup numbers-api | grep "^[^*]"'
# Name:   numbers-api.default.svc.cluster.local
# Address: 192.168.194.228    ← Endpoints IP가 아닌 ClusterIP가 반환됨

DNS 결과가 Endpoints IP(192.168.123.234)가 아닌 ClusterIP(192.168.194.228)인 이유는, clusterIP: None이 아닌 일반 ClusterIP 서비스이기 때문이다. DNS는 ClusterIP를 반환하고, 실제 외부 IP로의 라우팅은 kube-proxy가 DNAT으로 처리한다.

💡 공식 Headless Service와의 차이: clusterIP: None으로 정의한 서비스가 공식적인 Headless Service다. Headless Service는 ClusterIP 없이 DNS가 파드 IP를 직접 반환한다. 위 예시는 ClusterIP가 할당된 서비스이므로 정확히는 "셀렉터 없는 서비스(Service without selector)"에 해당한다.

이 패턴은 점진적 마이그레이션에 특히 유용하다. 외부 DB를 클러스터 내부로 이전할 때 Endpoints의 IP만 변경하면 클라이언트 파드는 수정할 필요가 없다.

두 방식 비교

구분	ExternalName	셀렉터 없는 서비스 + Endpoints
동작 수준	DNS (CNAME 치환)	IP (kube-proxy DNAT)
ClusterIP	할당 안 됨	할당됨
외부 대상 지정	도메인 네임만	IP 주소만
HTTP Host 헤더 문제	있음	있음
HTTPS/TLS SNI 문제	있음 (더 심각)	있음
TCP 서비스 호환	좋음 (DB에 최적)	좋음
마이그레이션 활용	외부→외부 전환	외부→내부 전환 (Endpoints IP만 교체)

---

5. 서비스의 해소 과정과 Endpoints 라이프사이클

서비스의 내부 동작을 요약하면 이렇다. 파드의 DNS 조회는 CoreDNS가 응답하고, 파드에서 나온 모든 통신은 각 노드에서 동작하는 kube-proxy가 라우팅을 담당한다. kube-proxy는 Endpoints의 최신 정보를 유지하면서, 운영체제의 패킷 필터(iptables 또는 IPVS)를 사용하여 가상 ClusterIP를 실제 파드 IP로 연결한다.

서비스 컨트롤러와 Endpoints의 라이프사이클을 실습으로 확인할 수 있다:

# 1. 서비스가 있을 때 — Endpoints에 파드 IP가 등록됨
kubectl get endpoints sleep-2
# NAME      ENDPOINTS           AGE
# sleep-2   192.168.194.38:80   3m28s

# 2. 파드를 삭제하면 — 새 파드가 생성되고 Endpoints가 자동 갱신됨
kubectl delete pods -l app=sleep-2
kubectl get endpoints sleep-2
# NAME      ENDPOINTS           AGE
# sleep-2   192.168.194.40:80   4m2s   ← IP가 바뀌었지만 자동 갱신

# 3. 디플로이먼트를 삭제하면 — 파드가 없으므로 Endpoints가 비어짐
kubectl delete deploy sleep-2
kubectl get endpoints sleep-2
# NAME      ENDPOINTS   AGE
# sleep-2   <none>      4m20s       ← 대상 파드 없음

# 4. 서비스를 삭제하면 — Endpoints도 함께 삭제됨
kubectl delete svc sleep-2
kubectl get endpoints sleep-2
# Error from server (NotFound): endpoints "sleep-2" not found

이것이 서비스의 핵심 가치다. ClusterIP는 서비스가 삭제될 때까지 변하지 않으며, 파드가 교체되어도 Endpoints가 자동으로 갱신되어 클라이언트는 항상 최신 상태의 백엔드에 접근할 수 있다.

---

6. 다른 노드에 있는 파드끼리는 어떻게 통신할까?

쿠버네티스 네트워크 모델의 핵심 요구사항은 "모든 파드는 NAT 없이 다른 모든 파드와 직접 통신할 수 있어야 한다"는 것이다. 같은 노드든, 다른 노드든 상관없다. 이것을 실현하는 것이 CNI(Container Network Interface) 플러그인이다.

같은 노드 내 통신

같은 노드에 있는 파드끼리는 단순하다. 각 파드는 veth pair(가상 이더넷 쌍)로 노드의 브릿지(cni0 또는 cbr0)에 연결되어 있다. veth pair의 한쪽 끝은 파드 안에, 다른 쪽은 노드의 브릿지에 있다. 브릿지가 L2 스위치 역할을 하므로, 같은 노드의 파드 간 통신은 브릿지 내에서 MAC 주소 기반으로 직접 전달된다.

다른 노드 간 통신 — VXLAN Overlay

다른 노드에 있는 파드끼리 통신할 때는 패킷이 물리 네트워크를 거쳐야 한다. 가장 널리 사용되는 방식은 VXLAN Overlay다. Flannel(기본 모드), Calico(vxlan 모드), Cilium 등이 이 방식을 지원한다.

핵심 아이디어는 캡슐화(Encapsulation)다. 원본 파드 패킷을 UDP 패킷으로 한번 더 감싸서 노드 간 물리 네트워크를 통과시킨다.

트래픽 흐름을 단계별로 보면

1. Pod A (10.244.1.5, Node1)가 Pod C (10.244.2.10, Node2)로 패킷을 보낸다.
2. 패킷이 veth → cni0 브릿지로 전달된다.
3. Node1의 라우팅 테이블에서 10.244.2.0/24가 VXLAN 터널(flannel.1) 인터페이스를 통해 도달 가능함을 확인한다.
4. flannel.1 (VTEP)이 원본 패킷을 UDP:4789로 캡슐화한다. 외부 헤더의 목적지는 Node2의 IP다.
5. 물리 네트워크를 통해 Node2로 전송된다. 물리 네트워크 입장에서는 그냥 Node1→Node2의 일반 UDP 트래픽이다.
6. Node2의 flannel.1이 외부 UDP 헤더를 벗겨내고 원본 파드 패킷을 복원한다.
7. 복원된 패킷이 cni0 → veth → Pod C에 도달한다.

CNI 모드 비교

구분	VXLAN (Overlay)	IP-in-IP	BGP (Direct Routing)
캡슐화	UDP:4789	IP 프로토콜 4	없음
오버헤드	50바이트	20바이트	0바이트
네트워크 요구	L3 (어디서든 동작)	L3 (IP 프로토콜 4 허용)	L2 또는 BGP 라우터
성능	보통	좋음	최고
대표 CNI	Flannel, Calico, Cilium	Calico (기본)	Calico BGP, Flannel host-gw
클라우드 호환	모든 환경	대부분	베어메탈/온프레미스에 적합

---

마무리

쿠버네티스 네트워킹을 한 문장으로 요약하면 이렇다: CoreDNS가 이름을 IP로 바꿔주고, kube-proxy가 가상 IP를 실제 파드 IP로 연결해주며, CNI가 노드 간 패킷 전달을 책임진다.

학습하면서 느낀 점은, 쿠버네티스가 특별히 새로운 기술을 발명한 것이 아니라는 것이다. DNS, iptables, VXLAN, BGP — 모두 이미 검증된 네트워크 기술이다. 쿠버네티스는 이것들을 컨테이너 오케스트레이션에 맞게 조합하고 자동화한 것이다. 그래서 기존 네트워크 지식이 있다면 쿠버네티스 네트워킹을 이해하는 데 큰 도움이 된다.

다음으로 학습할 주제로는 Ingress/Gateway API(HTTP 경로 기반 라우팅), NetworkPolicy(파드 간 방화벽), 서비스 메시(Istio/Linkerd)(mTLS, 트래픽 관리) 등을 추천한다.

---

참고 문서

• DNS for Services and Pods | Kubernetes
• Using CoreDNS for Service Discovery | Kubernetes
• Service | Kubernetes
• Cluster Networking | Kubernetes
• Determine best networking option | Calico