CNI 깊이

3부 (깊이)의 첫 챕터입니다. 14장 RBAC / NetworkPolicy / ResourceQuota에서 NetworkPolicy를 다룰 때 한 줄을 남겨 두었습니다. “NetworkPolicy는 K8s 매니페스트 차원에서는 표준이지만, 실제 트래픽을 막는 일은 CNI 플러그인이 한다.” 그 한 줄이 이번 챕터의 주제입니다. 같은 kind: NetworkPolicy 매니페스트가 Calico 위에서는 iptables 룰로 풀리고 Cilium 위에서는 eBPF 프로그램으로 풀립니다. 모양이 같아도 실행 단의 동작 · 성능 · 관측 가능성은 다릅니다. 이번 챕터에서는 K8s 네트워크 모델의 요구, CNI 인터페이스의 정체, 데이터 플레인의 세 모델 (iptables / IPVS / eBPF), Calico와 Cilium의 비교, CNI 선택의 실전 기준까지 한 사이클로 정리합니다.

이번 챕터의 끝에서는 같은 K8s 매니페스트가 어느 CNI 위에서 어떤 모양으로 풀리는지를 한 줄로 읽어 낼 수 있는 상태가 됩니다. CNI 결정의 트레이드오프 — iptables 디버깅의 친숙함 vs eBPF의 성능과 가시성 — 도 손에 잡힙니다.

K8s 네트워크 모델이 요구하는 네 가지 #

CNI를 이야기하기 전에, K8s가 네트워크 구현에 요구하는 조건부터 짚어 둡니다. K8s 자체는 네트워크 구현체를 갖고 있지 않습니다. 대신 네트워크가 반드시 만족해야 하는 네 가지 조건을 명세로 정해 두었고, 이 조건을 만족시키는 일은 CNI 플러그인의 몫입니다.

세 번째 조건은 컨테이너 환경에서는 자명하지 않습니다. 도커의 기본 브리지 네트워크는 NAT를 거쳐서 외부와 통신하므로, 컨테이너 내부의 자기 IP와 외부에서 보는 자기 IP가 다릅니다. K8s는 이 NAT 모델을 거부합니다. **모든 Pod는 클러스터 내에서 유일한 IP를 갖고, 그 IP로 자기 자신과 다른 Pod를 모두 부른다.**이 단순한 모델 위에서 5장 Service의 ClusterIP · DNS, 14장의 NetworkPolicy 같은 상위 객체가 일관되게 굴러갑니다.

이 네 조건을 만족시키는 방식은 한 가지가 아닙니다. 노드 사이를 잇는 오버레이를 만들 수도 있고 (VXLAN, Geneve), 라우팅 테이블에 직접 BGP로 경로를 광고할 수도 있고, eBPF로 커널의 패킷 처리 경로 자체를 바꿀 수도 있습니다. 어느 길을 골랐느냐에 따라 데이터 플레인의 성능 특성과 관측 가능성이 갈립니다. CNI 선택은 그 길을 고르는 결정입니다.

CNI — Container Network Interface #

CNI는 K8s 만의 규격이 아니라 컨테이너 런타임이 컨테이너에 네트워크를 붙일 때 호출하는 표준 인터페이스입니다. CNCF가 관리하는 사양으로, kubelet 외에도 podman / cri-o / containerd가 같은 인터페이스를 사용합니다.

규격 자체는 매우 단순합니다. 컨테이너 런타임이 새 컨테이너를 만들 때 CNI 플러그인의 실행 파일을 호출하면서, 컨테이너 ID와 네트워크 namespace 경로를 전달합니다. 플러그인은 그 namespace 안에 인터페이스를 만들고, IP를 할당하고, 라우팅 테이블을 채우고, 결과를 JSON으로 돌려줍니다.

1. kubelet이 Pod 생성을 결정 (Pod에 새 sandbox 컨테이너 만들기)
2. 컨테이너 런타임(containerd 등)이 network namespace 생성
3. 그 namespace 경로를 인자로 CNI 플러그인 실행 (ADD 명령)
4. 플러그인이 namespace 안에 veth 인터페이스 만들고 IP 할당
5. 플러그인이 호스트 측 라우팅·iptables·eBPF map 등을 갱신
6. 플러그인이 할당된 IP를 JSON으로 반환
7. kubelet이 그 IP를 Pod status에 기록

여기서 핵심은 K8s 자체는 4단계부터 6단계 사이의 실제 네트워크 구현을 알지 못한다는 점입니다. veth를 만들든, MACVLAN을 만들든, eBPF 훅으로 패킷을 가로채든 — 그 책임은 전적으로 CNI 플러그인에 있습니다. K8s는 “Pod에 IP가 붙었고 위 네 조건이 만족된다"는 결과만 받습니다.

이 분리 구조 덕분에 같은 K8s 클러스터에서 CNI를 갈아끼울 수 있습니다 (클러스터 셋업 시점에). Calico를 깔든 Cilium을 깔든 Flannel을 깔든, K8s API 사용자는 같은 매니페스트를 씁니다. 다만 그 매니페스트가 실제로 어떻게 풀리는가가 달라집니다. 이번 챕터의 주제가 그 “어떻게 풀리는가"입니다.

CNI 플러그인의 두 부분 #

운영 클러스터의 CNI 플러그인은 보통 두 부분으로 나뉩니다.

• 노드 에이전트 (DaemonSet) — 각 노드에 한 개씩 떠서 라우팅 / 정책 / IP 할당을 관리합니다. Calico의 calico-node, Cilium의 cilium-agent가 이 역할을 맡습니다.
• CNI 바이너리 — /opt/cni/bin/에 설치되어 컨테이너 런타임이 직접 호출합니다. 노드 에이전트가 부팅 시 이 바이너리를 노드의 디렉터리에 풀어 둡니다.

이 두 부분이 같이 동작하면서 K8s가 요구하는 네 조건을 노드 단위로 구현해 냅니다. 매니페스트는 단순한데 운영 단의 모양은 두 층으로 나뉘어 있다는 점을 기억해 두면 디버깅이 쉬워집니다. Pod에 IP가 안 붙는 문제는 CNI 바이너리 · 노드 에이전트 · kubelet 중 어디가 막혔는지 한 층씩 짚어 가는 일입니다. 이 진단 트리는 27장 kubectl 디버깅 패턴에서 한 번 더 정리합니다.

데이터 플레인의 세 모델 #

K8s 네트워크 트래픽이 실제로 흐르는 길을 데이터 플레인이라고 부릅니다. 클러스터에서 흔히 만나는 모델은 셋입니다 — iptables 기반, IPVS 기반, eBPF 기반. 하나씩 짚습니다.

iptables 기반 — 가장 오래된 길 #

K8s의 기본 컴포넌트인 kube-proxy는 처음부터 iptables를 기반으로 만들어졌습니다. ClusterIP로 들어오는 트래픽을 뒤에 있는 Pod IP 들로 분산하는 일을 iptables의 NAT 룰로 다룹니다. Service 한 개당 룰이 추가되고, Pod의 IP가 바뀔 때마다 룰이 갱신됩니다. 5장 Service의 §“kube-proxy"에서 이 모델을 한 번 짚어 두었고, 본 챕터에서 그 깊이를 더합니다.

이 모델의 장점은 단순함과 호환성입니다. 거의 모든 리눅스 커널이 iptables를 지원하고, 디버깅 도구 (iptables -L, iptables-save)가 풍부합니다. 단점은 규모가 커지면 성능이 깎인다는 점입니다. iptables는 룰을 선형으로 검사합니다. Service가 1,000 개고 각 Service 뒤에 10개의 Pod가 있다면, 한 트래픽 결정에 평균 5,000 줄 가까운 룰을 훑어야 합니다. 클러스터 규모가 중대형으로 가면 패킷당 CPU 비용이 눈에 띄게 올라갑니다.

sudo iptables -t nat -L KUBE-SERVICES -n

KUBE-SVC-XYZAB1234567  tcp  --  *  *  0.0.0.0/0  10.96.0.10  /* kube-system/kube-dns:dns */
KUBE-SVC-ABCDE9876543  tcp  --  *  *  0.0.0.0/0  10.96.45.12  /* default/web:http */
...

NetworkPolicy가 깔리면 iptables 룰이 더 늘어납니다. Calico의 기본 데이터 플레인 모드가 이 길이고, Pod 한 개당 ingress · egress 정책 룰이 호스트의 iptables 체인에 추가됩니다. 정책의 수와 Pod의 수가 곱해져 룰 개수가 빠르게 늘어납니다.

IPVS 기반 — 커널 단의 부하 분산 #

IPVS는 리눅스 커널이 가진 4계층 부하 분산 모듈입니다. iptables가 NAT 룰을 일반화한 도구라면, IPVS는 부하 분산 그 자체를 위한 전용 도구입니다. 해시 테이블 기반으로 동작하므로 룰 개수가 늘어도 검색 비용이 거의 일정합니다.

K8s의 kube-proxy는 1.11부터 IPVS 모드를 정식 지원합니다. --proxy-mode=ipvs로 부팅하면 ClusterIP 부하 분산이 IPVS로 이뤄집니다. 대형 클러스터 (Service 수천 개 이상)에서는 iptables 모드보다 평균 latency와 CPU 사용량이 일관되게 낮습니다. 다만 NetworkPolicy 같은 정책 차원은 여전히 iptables (또는 nftables)가 담당하므로, IPVS는 부분적인 개선입니다.

eBPF 기반 — 커널 자체를 다시 쓰는 길 #

eBPF (extended Berkeley Packet Filter)는 리눅스 커널 안에 사용자 정의 프로그램을 안전하게 끼워 넣을 수 있는 메커니즘입니다. 원래는 패킷 필터링용으로 시작됐지만, 지금은 커널의 거의 모든 훅 포인트 (시스템 콜, 네트워크 처리 단계, 트레이싱 포인트)에 작은 프로그램을 매달 수 있습니다.

네트워크 측면에서 eBPF가 의미 있는 이유는 단순합니다. iptables / IPVS의 역할을 eBPF 프로그램이 대체할 수 있고, 같은 방향과를 더 적은 CPU로 더 풍부한 관측 정보와 함께 만들어 낼 수 있습니다. 패킷이 커널을 통과하는 길에 직접 코드가 끼어들 수 있으므로, NAT · 부하 분산 · 정책 검사가 한 묶음으로 처리됩니다. iptables 룰을 선형 검사하지도 않고, NetworkPolicy를 위해 별도 체인을 만들지도 않습니다.

[iptables 모델]
  패킷 → conntrack → KUBE-SERVICES 체인 → KUBE-SVC-XXX → KUBE-SEP-YYY → DNAT → 라우팅
        (룰 N개 선형 검사)

[eBPF 모델]
  패킷 → tc/XDP 훅의 eBPF 프로그램
        → eBPF map 조회(Service → Pod 목록, O(1))
        → 정책 map 조회(허용 여부, O(1))
        → DNAT 후 전달

Cilium이 이 모델의 대표 구현체입니다. Calico도 3.13부터 eBPF 데이터 플레인 모드를 옵션으로 제공합니다. 두 제품의 차이는 다음 절에서 짚습니다.

Calico와 Cilium — 두 가지 길 #

K8s 클러스터에서 가장 자주 마주치는 CNI 플러그인이 Calico와 Cilium입니다. 둘 다 NetworkPolicy를 완전히 지원하고, 둘 다 운영 규모로 굴러간 실적이 충분히 쌓여 있습니다. 차이는 데이터 플레인의 기본 모델과 eBPF에 얼마나 깊이 의존하는가에 있습니다.

Calico — BGP · iptables가 기본, eBPF는 옵션 #

Calico의 기본 데이터 플레인은 두 부분의 결합입니다.

• 노드 간 라우팅 — BGP (Border Gateway Protocol)로 각 노드의 Pod CIDR을 다른 노드에 광고합니다. 노드 자체가 라우터처럼 동작하므로 오버레이 (VXLAN 같은 캡슐화)가 필요 없습니다. 클라우드의 라우팅 테이블이 Pod CIDR을 알지 못하는 환경에서는 IP-in-IP나 VXLAN으로 캡슐화하는 옵션도 있습니다.
• 노드 내 정책 / NAT — iptables로 Service 부하 분산과 NetworkPolicy를 다룹니다. kube-proxy의 iptables 모드와 같은 위치입니다.

이 조합의 장점은 운영 단의 친숙함입니다. 라우팅이 BGP로 굴러가므로 데이터 센터의 BGP 인프라 (특히 온프레미스, ToR 스위치 환경)와 자연스럽게 묶입니다. iptables 룰은 표준 도구로 디버깅할 수 있습니다. 단점은 규모가 커지면 iptables의 한계가 그대로 옵니다. Service / Pod / 정책의 수가 늘면 룰 개수가 빠르게 불어나고, kube-proxy의 동기화 시간도 길어집니다.

Calico 3.13부터는 데이터 플레인을 eBPF로 갈아 끼우는 모드가 추가됐습니다. 이 모드에서는 kube-proxy가 더 이상 필요하지 않고, Service 부하 분산과 NetworkPolicy가 모두 eBPF로 풀립니다. 다만 Calico의 BGP 라우팅 모델은 그대로 유지되므로, “라우팅은 BGP, 데이터 플레인은 eBPF"의 혼합 모양이 됩니다.

Cilium — 처음부터 eBPF #

Cilium은 처음부터 eBPF를 전제로 설계된 CNI입니다. Service 부하 분산, NetworkPolicy, 7계층 정책 (HTTP · gRPC 메서드 단위 허용 / 거부), 노드 간 암호화 (WireGuard / IPsec), 옵저버빌리티 (Hubble)까지 모두 eBPF 프로그램으로 다룹니다.

[각 노드]
  cilium-agent (DaemonSet)
    ├─ eBPF 프로그램을 컴파일·로드
    ├─ Service / Endpoint / NetworkPolicy를 eBPF map에 채움
    └─ Pod 생성 시 veth + eBPF 훅 부착

  Hubble (선택)
    └─ eBPF에서 수집한 흐름·메트릭을 노출

Cilium의 차별점은 셋입니다.

• kube-proxy 대체 — Cilium 만으로 Service 부하 분산이 처리되므로 kube-proxy를 끌 수 있습니다. 클러스터의 컴포넌트 수가 줄고, iptables 룰이 사라지므로 노드의 패킷 처리 경로가 짧아집니다.
• 7계층 정책 — NetworkPolicy의 표준 스펙은 4계층 (IP / 포트)에 한정되지만, Cilium은 자체 CRD (CiliumNetworkPolicy)로 HTTP 메서드 · 경로, gRPC 서비스 / 메서드, Kafka 토픽 단위 정책을 표현할 수 있습니다. 이 정책도 eBPF 프로그램으로 풀립니다.
• Hubble — eBPF 기반 옵저버빌리티 — 패킷이 eBPF 훅을 지날 때 메타데이터를 수집해 흐름 단위 가시성을 제공합니다. “어느 Pod가 어느 Pod의 어느 포트를 부르는가"를 실시간으로 볼 수 있습니다. 옵저버빌리티는 19장 옵저버빌리티에서 따로 다루지만, Hubble이 eBPF의 부산물로 자연스럽게 따라온다는 점은 Cilium의 매력 중 하나입니다.

한눈에 보는 비교 #

같은 K8s 매니페스트가 세 칼럼 어디서나 동작합니다. 다만 그 매니페스트가 노드 안에서 어떤 모양으로 풀리는가는 칼럼마다 다릅니다. 이 차이가 성능 · 관측 가능성 · 운영 도구의 선택에 그대로 반영됩니다.

eBPF가 바꾸는 것 #

CNI 선택을 이야기할 때 eBPF가 자주 등장하므로, eBPF가 K8s 네트워크에 가져온 변화를 한 번 짚어 둡니다. eBPF 자체는 K8s 컴포넌트가 아니라 리눅스 커널 기능이지만, K8s 네트워크의 데이터 플레인이 이 기능을 적극적으로 쓰면서 운영 모델의 결이 바뀌었습니다.

kube-proxy의 역할이 사라진다 #

오랫동안 kube-proxy는 K8s 클러스터의 필수 컴포넌트였습니다. ClusterIP의 가상 IP를 실제 Pod IP 들로 분산하는 일이 이 컴포넌트의 책임이었고, 그 일을 iptables 또는 IPVS로 풀어냈습니다.

Cilium이 kubeProxyReplacement: true 옵션으로 kube-proxy를 완전히 대체할 수 있고, Calico의 eBPF 모드도 같은 일을 합니다. 컴포넌트 한 개가 빠지면 운영의 표면적이 그만큼 줄어듭니다 — 모니터링할 대상이 한 개 줄고, 동기화 지연을 의심할 후보가 한 개 줄고, 룰 폭증의 원인이 한 개 사라집니다.

NetworkPolicy의 비용 모델이 바뀐다 #

iptables 기반의 NetworkPolicy는 정책의 수와 Pod의 수에 비례해 룰이 늘어납니다. eBPF 기반에서는 정책이 map으로 표현되므로 검색 비용이 거의 일정합니다. 정책 수가 수백 · 수천 개로 늘어나는 멀티테넌트 클러스터에서 이 차이가 패킷당 latency로 드러납니다.

옵저버빌리티가 데이터 플레인의 부산물이 된다 #

전통적 모델에서 트래픽 가시성은 별도 작업이었습니다 — Pod에 사이드카를 붙이거나, NodePort에 tcpdump를 걸거나, 별도 모니터링 에이전트를 깔거나. eBPF 데이터 플레인에서는 패킷이 어차피 eBPF 훅을 지나므로, 그 길에서 메타데이터 (소스 Pod / 목적 Pod / 정책 검사 결과 / latency)를 함께 수집하면 자연스럽게 흐름 단위 가시성이 만들어집니다. Cilium의 Hubble이 이 모델의 직접적인 결과물입니다.

CNI 선택 — 실전 기준 #

이론적으로는 어떤 CNI 든 K8s가 요구하는 네 조건을 만족합니다. 그러나 운영 클러스터의 CNI 결정은 다음 다섯 차원이 모이는 결정입니다.

매니지드 K8s에는 클라우드 사업자가 미는 기본 CNI가 있습니다. EKS는 aws-vpc-cni (VPC IP를 Pod에 직접 할당하는 모델), GKE는 자체 CNI (VPC-native 모드), AKS는 Azure CNI 또는 kubenet입니다. 이 기본 CNI는 그 클라우드의 네트워킹과 가장 매끄럽게 묶이지만, NetworkPolicy 지원이나 eBPF 기능이 부족할 수 있어서 운영 요구에 따라 Calico / Cilium으로 갈아끼우는 경우가 많습니다. EKS에서는 aws-vpc-cni를 유지하면서 NetworkPolicy만 Calico 또는 Cilium의 chained 모드로 얹는 패턴이 흔합니다. EKS 위 본격적인 셋업 결정은 21장 EKS 클러스터 셋업에서 한 번 더 다룹니다.

소규모 · 단순 클러스터에서는 매니지드 사업자의 기본 CNI를 그대로 쓰는 결정이 가장 합리적입니다. 운영 부담이 가장 작고, 클라우드 지원과의 호흡도 가장 좋습니다. NetworkPolicy 요구가 본격적으로 들어오는 단계, 또는 멀티테넌트 격리 · 7계층 정책 · 세밀한 흐름 가시성이 운영 요구가 되는 단계에서 Calico / Cilium의 도입 검토가 자연스럽게 시작됩니다.

선택의 미세한 결을 한 줄씩 정리합니다.

• Calico (기본 모드) — BGP 인프라가 이미 있고, iptables 디버깅에 익숙한 팀이 가장 빠르게 도입할 수 있는 길입니다. 중소 규모 클러스터에서 가장 부담이 적은 선택입니다.
• Calico (eBPF 모드) — 라우팅은 그대로 두고 데이터 플레인 성능만 끌어올리고 싶을 때 쓰는 모드입니다. BGP 자산을 살리면서 eBPF의 이점을 가져오는 절충입니다.
• Cilium — 7계층 정책 · Hubble 옵저버빌리티 · kube-proxy 제거를 한 묶음으로 가져가고 싶을 때 맞는 선택입니다. eBPF에 본격적으로 베팅하는 선택입니다.

이 결정은 한 번 내리면 바꾸기가 쉽지 않습니다. CNI 교체는 클러스터 전체의 네트워크 재설정에 가까워서 보통은 클러스터 신규 셋업 시점에 잡힙니다. 따라서 처음 결정할 때 운영의 향후 1~2년 그림을 같이 보는 편이 좋습니다.

연습문제 #

1. 본인이 운영 중이거나 학습 중인 클러스터의 CNI가 무엇인지 확인합니다 (kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|aws-node'). 그 CNI의 데이터 플레인 모델 (iptables / IPVS / eBPF)을 §“데이터 플레인의 세 모델"과 맞춰 한 줄로 정리하고, 같은 K8s 매니페스트가 그 위에서 어떻게 풀리는지를 자신의 표현으로 한 단락으로 적습니다.
2. iptables 기반 클러스터에서 sudo iptables -t nat -L KUBE-SERVICES -n | wc -l로 룰 개수를 세고, 같은 클러스터의 Service 개수 (kubectl get svc -A | wc -l)와 어떤 비율로 곱해지는지 메모합니다. Service 수가 수천 개로 늘었을 때 §“iptables 기반"의 선형 검사 비용이 어떻게 누적되는지를 추론하고, eBPF 기반의 map 조회 (O(1))와 어떻게 다른지 비교합니다.
3. Calico와 Cilium의 §“한눈에 보는 비교” 표를 보고, 본인이 운영하려는 클러스터의 다섯 결정 차원 (규모, 네트워크 환경, 7계층 정책 필요 여부, 팀 친숙도, 매니지드 기본값)에 비춰 어느 쪽을 고를지 한 단락으로 결정하고 이유를 적습니다. EKS 환경이라면 aws-vpc-cni + Calico/Cilium chained 모드와 단일 Cilium 중 어느 쪽이 자기 요구에 맞는지도 함께 비교합니다.

한 줄 요약: K8s 네트워크 모델의 네 조건 (NAT 없는 Pod-to-Pod, Node-to-Pod, Pod self IP, Service 추상화)을 만족시키는 책임은 CNI 플러그인에 있다. 같은 매니페스트가 Calico (BGP + iptables) · Calico eBPF · Cilium (처음부터 eBPF) 위에서 다르게 풀린다. eBPF 데이터 플레인은 kube-proxy의 역할을 대체하고, NetworkPolicy의 비용 모델을 O(N)에서 O(1)로 바꾸며, 옵저버빌리티 (Hubble)를 데이터 플레인의 부산물로 만든다. CNI 선택은 한 번 내리면 바꾸기 어려운 결정이므로 클러스터 셋업 시점에 운영 1~2년 그림을 같이 본다.

다음 챕터 #

본 챕터에서 CNI의 데이터 플레인을 풀어 봤으니, 다음 챕터에서는 같은 방향으로 14장의 RBAC 절에서 한 줄로 끊었던 부분을 다룹니다 — Aggregated ClusterRole, impersonation, EKS의 IRSA와 GKE의 Workload Identity처럼 K8s 권한 모델이 외부 IAM과 묶이는 길입니다.

16장 RBAC / ServiceAccount 깊이에서는 ClusterRole의 aggregation 메커니즘, --as 옵션의 impersonation 흐름, ServiceAccount 토큰의 라이프사이클 (projected token), 그리고 클라우드 IAM과의 매핑 — EKS의 IRSA · Pod Identity, GKE의 Workload Identity — 까지 한 사이클로 정리합니다. 본 챕터의 CNI처럼 K8s 표준 객체가 클라우드 인프라와 어떻게 연결되는가의 또 다른 단면입니다.