쿠버네티스 네트워킹: 서비스, DNS, Ingress, NetworkPolicy

서비스 네 유형의 개요는 쿠버네티스 구조와 핵심 개념에, 클러스터 밖에서 파드까지의 요청 경로와 사이드카·앰비언트 메시의 비교는 쿠버네티스 위 웹 서비스의 요청 경로에 있다. 이 노트는 각 계층이 어떻게 동작하는지를 다룬다.

네트워크 모델과 CNI

쿠버네티스의 네트워크 모델은 세 가지를 요구한다.

1. 모든 파드는 클러스터 안에서 고유한 IP를 가진다.
2. 모든 파드는 다른 노드의 파드와도 NAT 없이 그 IP로 통신한다.
3. 노드의 에이전트(kubelet 등)는 그 노드의 모든 파드와 통신한다.

이 모델은 그 전의 포트 매핑 방식이 남긴 문제를 피하려는 것이다. Docker 기본 브리지처럼 컨테이너가 호스트 IP를 함께 쓰고 호스트 포트를 매핑받으면, 같은 서비스라도 인스턴스마다 10.0.0.2:9000, 10.0.0.3:8722처럼 포트가 제각각이 된다. 클라이언트는 DNS SRV 레코드로 포트까지 조회해야 하고, HTTP는 프록시가 Host 헤더로 분기해 줄 수 있지만 MySQL·Redis처럼 포트를 고정해 쓰는 프로토콜은 다루기 어렵다. 파드마다 IP를 주면 모든 파드가 VM처럼 원래 포트(3306, 6379)를 그대로 쓰고, 이름은 A 레코드 조회로 충분하다. 대가는 노드마다 파드 대역을 나누고 노드 사이 경로를 관리하는 일이며, 그것을 CNI가 맡는다.

쿠버네티스는 이 모델을 직접 구현하지 않고 CNI(Container Network Interface) 플러그인에 맡긴다. 파드가 만들어질 때 런타임이 CNI 플러그인을 호출하면, 플러그인이 파드의 네트워크 네임스페이스에 veth 인터페이스를 만들고 IP를 배정(IPAM)하고 노드 사이 경로를 잡는다. 같은 노드 안 파드끼리는 노드의 브리지나 라우팅으로, 다른 노드의 파드와는 라우팅(BGP 등)이나 오버레이(VXLAN 캡슐화)로 통신한다. 파드 안에서 네트워크를 공유하는 pause 컨테이너는 구조 노트, veth와 네임스페이스의 원리는 리눅스 네트워크 네임스페이스와 ip 명령에 있다.

서비스가 파드에 닿는 원리

EndpointSlice와 kube-proxy

서비스의 ClusterIP는 어느 인터페이스에도 붙어 있지 않은 가상 IP다. 핑에 응답하지 않는 것도 그래서다. 실제 전달은 두 구성 요소가 나눠 맡는다.

flowchart TB
  esc["EndpointSlice 컨트롤러"] -->|"셀렉터에 맞고 Ready인 파드 IP:포트 목록을 기록"| es["EndpointSlice"]
  svc["Service"] -->|"watch"| kp["kube-proxy (노드마다)"]
  es -->|"watch"| kp
  kp -->|"규칙을 심음"| kr["노드 커널 규칙"]
  pod["파드"] -->|"10.96.0.10:80 으로 보냄"| kr
  kr -->|"목적지를 DNAT"| dst["10.244.2.7:8080 (파드 하나)"]

kube-proxy 자체는 패킷을 중계하지 않는다. 커널에 규칙만 심고, 전달은 커널이 한다.

서비스 유형별 세부 동작

externalTrafficPolicy는 외부 트래픽의 경로를 정한다. Cluster(기본)는 어느 노드로 들어와도 아무 파드로 보내지만 다른 노드로 한 번 더 건너가고 출발지 IP가 노드 IP로 바뀐다(SNAT). Local은 파드가 있는 노드만 트래픽을 받아 클라이언트 IP를 보존하고 홉을 줄이는 대신, 노드별 파드 수가 고르지 않으면 부하가 치우친다.

DNS: 이름으로 서비스 찾기

클러스터 DNS는 kube-system 네임스페이스의 CoreDNS(서비스 이름은 호환을 위해 kube-dns)가 맡는다. 파드의 /etc/resolv.conf는 kubelet이 이 DNS 서버와 검색 도메인으로 채운다.

# 파드 안의 /etc/resolv.conf
nameserver 10.96.0.10
search shop.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

같은 네임스페이스에서는 api, 다른 네임스페이스는 api.shop만 써도 검색 도메인이 붙어 풀린다. 다만 ndots:5는 점이 5개 미만인 이름을 먼저 검색 도메인을 붙여 시도하게 하므로, api.example.com 같은 외부 이름 하나에 실패 질의가 여러 번 먼저 나간다. 외부 호출이 많으면 끝에 점을 붙인 FQDN(api.example.com.)을 쓰거나 파드의 dnsConfig로 ndots를 낮추고, 노드마다 DNS 캐시를 두는 NodeLocal DNSCache로 CoreDNS 부하를 줄인다. DNS 자체의 동작은 DNS에 있다.

파드에서 외부로 나가는 트래픽

flowchart TB
  pod["파드(10.244.2.7)"] --> rt["노드의 라우팅"]
  rt --> snat["노드에서 SNAT(masquerade):<br/>출발지를 노드 IP로"]
  snat -->|"(프라이빗 서브넷이면)"| nat["NAT 게이트웨이에서 공인 IP로 다시 변환"]
  nat --> ext["외부 서비스"]
  ext -.->|"응답은 변환 테이블(conntrack)을 거슬러 파드로 돌아온다"| pod

외부 서비스가 IP 허용 목록을 요구하면 출발지가 노드마다 달라지므로, NAT 게이트웨이의 고정 IP나 CNI·서비스 메시의 이그레스 게이트웨이로 나가는 경로를 하나로 모은다. VPC 쪽 NAT 게이트웨이는 AWS VPC 네트워크 구성에 있다.

Ingress

서비스는 L4(IP·포트)까지만 다룬다. Ingress는 HTTP(S) 요청을 호스트 이름과 경로에 따라 여러 서비스로 나누는 L7 라우팅 규칙이다. 외부 진입점 하나(로드 밸런서 하나)로 여러 서비스를 노출할 수 있어, 서비스마다 LoadBalancer를 만드는 비용을 줄인다.

Ingress 리소스는 규칙일 뿐이고, 규칙을 읽어 실제 프록시를 설정하는 Ingress 컨트롤러를 따로 설치해야 동작한다. ingressClassName으로 어느 컨트롤러가 처리할지 고른다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt   # cert-manager가 인증서 발급
spec:
  ingressClassName: traefik
  tls:
    - hosts: [shop.example.com, api.example.com]
      secretName: shop-tls                        # kubernetes.io/tls 타입 Secret
  rules:
    - host: shop.example.com                      # 호스트 기반
      http:
        paths:
          - { path: /, pathType: Prefix, backend: { service: { name: web, port: { number: 80 } } } }
    - host: api.example.com
      http:
        paths:
          - { path: /v1, pathType: Prefix, backend: { service: { name: api-v1, port: { number: 80 } } } }   # 경로 기반

• pathType은 Prefix(경로 구간 단위 접두사), Exact(정확히 일치), ImplementationSpecific(컨트롤러 마음대로)이다.
• TLS: 인증서와 키를 kubernetes.io/tls Secret에 넣고 spec.tls에서 가리키면 컨트롤러가 TLS를 종료한다. cert-manager는 Issuer·ClusterIssuer(Let's Encrypt 같은 ACME, 사설 CA)를 정의해 두면, 어노테이션이나 Certificate 리소스를 보고 인증서를 받아 Secret에 넣고 만료 전에 갱신한다.
• 어노테이션: 리라이트, 레이트 리밋, 타임아웃, CORS 같은 기능은 Ingress 명세에 없어 컨트롤러별 어노테이션(예: Ingress NGINX의 nginx.ingress.kubernetes.io/rewrite-target, limit-rps)으로 켰다. 어노테이션은 컨트롤러마다 달라 이식되지 않고 검증도 약하다. 이것이 Gateway API가 나온 이유다.

Gateway API

Gateway API는 Ingress의 후속 표준이다. Ingress API는 기능 추가가 멈췄고, 새 기능은 Gateway API에 들어간다.

NetworkPolicy

NetworkPolicy는 파드 사이 L3·L4(IP·포트) 트래픽을 허용 목록으로 제한하는 네임스페이스 단위 방화벽이다.

• 기본은 모두 허용이다. 어떤 정책도 고르지 않은 파드는 누구와도 통신한다.
• 한 파드가 어떤 정책의 podSelector에 걸리고 그 정책의 policyTypes에 Ingress(또는 Egress)가 있으면, 그 방향은 정책들이 허용한 것만 통과한다. 정책은 더해지기만 하고 「거부」 규칙은 없다.
• 상대는 podSelector, namespaceSelector, ipBlock(CIDR)으로, 포트는 ports로 지정한다.

# 1. 네임스페이스의 모든 파드에 들어오는 트래픽 기본 거부
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: shop }
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
# 2. web 파드에서 api 파드의 8080만 허용
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: api-from-web, namespace: shop }
spec:
  podSelector: { matchLabels: { app: api } }
  policyTypes: [Ingress]
  ingress:
    - from: [{ podSelector: { matchLabels: { app: web } } }]
      ports: [{ protocol: TCP, port: 8080 }]

RBAC가 쿠버네티스 API에 대한 사람·프로그램의 접근을 제어한다면, NetworkPolicy는 파드 사이 네트워크 접근을 제어한다. RBAC는 쿠버네티스 보안에 있다.

서비스 메시

서비스 메시는 서비스 간 트래픽을 프록시 계층에 통과시켜, 앱 코드를 고치지 않고 트래픽 제어·보안(mTLS)·관측을 붙이는 인프라 계층이다. 서비스가 많아지면 재시도·타임아웃·서킷 브레이커·인증·지표를 언어마다 라이브러리로 넣기 어려워 플랫폼으로 내린다.

flowchart TB
  cp["컨트롤 플레인 (istiod)"] -->|"설정·인증서 배포 (xDS)"| dp
  subgraph dp["데이터 플레인 프록시들"]
    direction LR
    appa["앱 A"] <--> p1["프록시"]
    p1 <-->|"mTLS"| p2["프록시"]
    p2 <--> appb["앱 B"]
  end

사이드카 프록시는 iptables 규칙(또는 CNI 플러그인)으로 파드의 들고 나는 트래픽을 모두 가로채, 앱은 평문으로 http://b를 불러도 프록시끼리 mTLS로 통신한다. 사이드카와 앰비언트(노드 공용 프록시) 방식의 비교는 요청 경로 노트에 있다.

Istio

라우팅은 Istio 전용 리소스 대신 Gateway API의 HTTPRoute로도 쓸 수 있다.

Linkerd

메시가 필요 없는 규모라면 도입하지 않는 편이 낫다. 프록시 비용과 운영 복잡도가 생기기 때문이다. mTLS만 필요하면 앰비언트 L4 모드나 Cilium의 기능으로도 충분할 수 있다.

연결 문제 진단

서비스로 파드에 닿지 않을 때

kubectl get svc api -o wide                                   # selector, port, targetPort
kubectl get endpointslices -l kubernetes.io/service-name=api  # 엔드포인트가 비었나
kubectl get pods -l app=api --show-labels                     # 라벨이 셀렉터와 맞나, READY인가
kubectl run tmp --rm -it --image=busybox:1.37 -- wget -qO- http://api:80/healthz

DNS 문제

kubectl get pods -n kube-system -l k8s-app=kube-dns           # CoreDNS가 떠 있나
kubectl logs -n kube-system -l k8s-app=kube-dns
kubectl exec -it <파드> -- cat /etc/resolv.conf               # nameserver가 kube-dns IP인가
kubectl run dnstest --rm -it --image=busybox:1.37 -- nslookup kubernetes.default

이름은 안 풀리고 IP로는 되면 DNS 문제다. CoreDNS 파드 상태, 이그레스 정책의 53번 포트 허용, CoreDNS 설정(ConfigMap coredns)의 업스트림 DNS, ndots로 인한 지연을 차례로 본다.

정리

• 쿠버네티스는 「모든 파드가 NAT 없이 서로 통신」이라는 모델만 정하고 구현은 CNI에 맡긴다.
• 서비스의 ClusterIP는 가상 IP다. kube-proxy가 EndpointSlice를 보고 커널에 DNAT 규칙을 심는다. 새 클러스터는 nftables 모드를 쓰고, IPVS는 폐기 예정이다.
• 이름 해석은 CoreDNS가 맡고, ndots:5 때문에 외부 이름 조회에 질의가 늘 수 있다.
• Ingress는 컨트롤러가 있어야 동작하는 L7 규칙이고, 후속 표준은 역할별로 나뉜 Gateway API다.
• NetworkPolicy는 기본 허용에서 출발하는 허용 목록 방화벽이며, CNI가 지원해야 효과가 있다.
• 서비스 메시는 프록시로 mTLS·트래픽 제어·관측을 앱 밖에서 처리한다.

관련 노트: 쿠버네티스 구조와 핵심 개념, 쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소, 쿠버네티스 워크로드와 파드 생명주기, 쿠버네티스 보안, 리눅스 네트워크 네임스페이스와 ip 명령, DNS, 배포 전략