K8s Networking - 03. cni model

Pod끼리 통신이 안 되면 범인은 거의 항상 이 층이다 — CNI가 Pod 네트워크를 만드는 법

Service로는 통신이 되는데, Pod IP로 직접 연결하면 안 된다. 클러스터를 처음 세팅한 팀이 가장 먼저 부딪히는 네트워크 문제다. 01장에서 kube-proxy(Service 층)와 CNI(Pod 간 층)가 다른 층이라고 했다 — 범인은 거의 항상 CNI 쪽이다. 그런데 CNI가 정확히 뭘 만드는가? 왜 Pod마다 IP가 붙고, 서로 다른 노드의 Pod가 통신 가능한가?

이 글이 푸는 것은: CNI(Container Network Interface)가 Pod 네트워크를 어떻게 만드는가, 그리고 오버레이(overlay)와 언더레이(underlay)라는 두 근본 접근이 어떻게 다른가다. 이 글이 04(Calico)/05(Cilium)의 기초다.

CNI가 풀어야 할 두 문제

Pod가 노드 N개에 흩어져 있다. CNI가 풀어야 할 두 문제를 먼저 분리해 두자 — 이 두 개를 풀어가는 과정이 이 글 전체의 서사다.

1. 한 노드 안에서: 컨테이너마다 IP를 어떻게 붙이고, 같은 노드의 컨테이너끼리 통신하게?
2. 노드 간에: 다른 노드의 Pod와 어떻게 통신하게? (노드 자체는 서로 다른 네트워크에 있을 수 있다.)

flowchart TD
    N1["노드 1<br/>Pod IP대역 10.244.1.x"] -. 어떻게 통신? .-> N2["노드 2<br/>Pod IP대역 10.244.2.x"]
    N1 --> BR1["cni0 브리지<br/>(같은 노드 Pod 연결)"]
    N2 --> BR2["cni0 브리지"]

첫 번째 문제(한 노드 안)부터 파고든다. 그 답이 "Pod IP"의 실체를 드러내고, 그 답이 만들어내는 새로운 문제가 두 번째(노드 간)를 부른다. 오버레이/언더레이는 그 두 번째 문제에 대한 두 답이다.

컨테이너마다 IP가 따로 있으려면 — 네트워크 네임스페이스

보통 리눅스 프로세스는 모두 같은 네트워크 스택을 공유한다. 같은 라우팅 테이블, 같은 포트 공간, 같은 eth0. 그래서 한 프로세스가 80번 포트를 잡으면 다른 프로세스는 80번을 못 쓴다. 이 구조로는 "컨테이너마다 자기만의 IP, 자기만의 포트 공간"을 줄 수 없다.

리눅스는 이를 위해 네트워크 네임스페이스(network namespace)를 제공한다. 네임스페이스는 네트워크 스택(인터페이스·라우팅 테이블·포트 공간·iptables 규칙)을 통째로 복제·격리한다. 네임스페이스 안에는 그 네임스페이스만의 eth0이 있고, 그 네임스페이스만의 라우팅 테이블이 있다. 컨테이너 런타임은 컨테이너마다 네임스페이스를 하나씩 만들어 할당한다 — 이것이 "컨테이너마다 IP가 따로 있다"의 물리적 실체다. (ip-netns man page)

직접 만져보면 감이 온다:

# Linux — 네임스페이스 만들고 그 안의 인터페이스 보기
ip netns add demo
ip netns exec demo ip addr

확인할 것: demo 네임스페이스 안에는 호스트와 다른 인터페이스 목록이 나온다. 보통 루프백(lo) 하나뿐이다. 호스트의 eth0은 보이지 않는다 — 격리됐으니까.

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

핵심 통찰: "Pod IP"는 네임스페이스 안의 eth0에 붙은 IP다. 노드에서 ip addr을 봐도 Pod IP가 안 보이는 이유가 바로 이것이다 — IP는 네임스페이스 안에 있으니까. 노드에서 보려면 ip netns exec <ns> ip addr로 그 네임스페이스에 들어가야 한다. 이 추상화를 모르면 "왜 노드에서 Pod IP가 안 보이나?"라는 혼란이 생긴다.

격리했더니 바깥과 통신이 안 된다 — veth pair

네임스페이스로 격리는 됐다. 그런데 격리된 네임스페이스 안의 컨테이너는 바깥(호스트, 다른 컨테이너, 인터넷)과 통신을 못 한다. 네임스페이스는 격리할 뿐 연결하지 않기 때문이다. 방금 만든 demo 네임스페이스에서 ping 8.8.8.8을 치면 아무것도 나가지 않는다 — 나갈 길이 없으니까.

연결 고리가 필요하다. 리눅스는 veth pair(가상 이더넷 쌍)로 이걸 만든다. veth pair는 연결된 두 개의 가상 인터페이스다 — 한쪽에 패킷을 넣으면 반대쪽에서 나온다. 가상 케이블을 상상하면 된다.

CNI가 Pod를 만들 때 하는 기본 동작:

1. veth pair를 하나 만든다.
2. 한쪽 끝(컨테이너 안에서는 eth0)을 컨테이너의 네임스페이스로 옮긴다.
3. 다른 끝(호스트에는 vethxxx로 보임)은 호스트에 둔다.

flowchart LR
    subgraph NS["컨테이너 네임스페이스"]
        C_ETH["eth0<br/>(10.244.1.5)"]
    end
    C_ETH == "veth pair<br/>(가상 케이블)" ==> VETH["vethxxx<br/>(호스트)"]
    VETH --- BR["cni0 브리지<br/>(호스트)"]
    BR --- OTHER["다른 Pod의 veth"]

이제 컨테이너의 eth0에서 나온 패킷이 호스트의 vethxxx로 튀어나온다. 그런데 나오기만 하면 끝이 아니다 — 호스트의 다른 인터페이스(다른 Pod의 veth, 물리 eth0)로 가려면 누군가 중개해줘야 한다. 그 역할이 다음 절의 브리지다.

같은 노드의 Pod를 하나로 묶는 스위치 — 리눅스 브리지

Pod 개수만큼 호스트에는 vethxxx 인터페이스가 생긴다. 각각이 다른 Pod로 가는 출입구다. 그런데 이 veth들이 서로 연결돼 있지 않으면, 같은 노드의 Pod끼리도 패킷이 안 간다 — Pod-A의 veth에서 나온 패킷이 Pod-B의 veth로 어떻게 건너가나?

여기에 리눅스 브리지(cni0, flannel.1 등 CNI마다 이름이 다름)가 들어온다. 브리지는 L2 이더넷 스위치의 소프트웨어 구현이다. CNI는 호스트 쪽 veth들을 이 브리지에 꽂는다. 그러면 같은 브리지에 연결된 인터페이스끼리 MAC 주소로 직접 통신할 수 있다 — 같은 노드의 Pod끼리는 브리지가 L2 스위치처럼 패킷을 건네준다.

# Kubernetes 1.36, kind — 노드에서 브리지와 veth 보기
docker exec <kind-node> ip link show type bridge
docker exec <kind-node> ip link show type veth

확인할 것: cni0이나 br-... 같은 브리지 인터페이스와, 여러 vethxxx가 보인다. 각 veth의 peer(짝)가 한 Pod의 eth0이다.

노드 종속 경로라 노드 접속 또는 컨테이너 exec 필요. 미검증 환경은 노트.

여기까지가 "한 노드 안에서 Pod가 통신한다"의 완성이다. 네임스페이스(격리) → veth pair(연결 고리) → 브리지(같은 노드 묶기)의 세 단계. 이건 오버레이든 언더레이든, CNI라면 거의 공통으로 거치는 기반층이다. 첫 번째 문제가 풀렸다.

다른 노드의 Pod와 통신하려면 — 물리 네트워크는 Pod IP를 모른다

이제 두 번째 문제: 다른 노드의 Pod다. 그리고 여기서부터가 진짜 어렵다.

문제를 정확히 보자. Pod IP 대역(예: 10.244.x.x)은 노드 자체의 물리 IP 대역(예: 192.168.x.x)과 다르다. 노드1의 Pod-A(10.244.1.5)가 노드2의 Pod-B(10.244.2.3)에게 패킷을 보낸다고 치자. 이 패킷은 노드1을 빠져나가 물리 네트워크(라우터/스위치)를 거쳐 노드2에 닿아야 한다.

그런데 물리 네트워크 장비는 10.244.x.x 대역을 모른다. 그 장비들은 192.168.x.x(노드 IP)만 알도록 설정돼 있다. 10.244.x.x 패킷이 오면 어디로 보내야 할지 모른다 — 그래서 드롭하거나 기본 게이트웨이로 무작정 보내버린다.

이 "물리 네트워크의 무지"가 노드 간 Pod 통신의 핵심 장애물이다. 오버레이와 언더레이는 이 무지를 서로 다른 방식으로 처리한다.

오버레이 — Pod 패킷을 노드 IP 안에 숨겨 보낸다

가장 직관적 접근: 물리 라우터가 10.244.x.x를 모른다면, 모르는 채로 두자. 대신 Pod 패킷을 노드 IP(192.168.x.x) 패킷 안에 숨겨서 보낸다. 물리 라우터는 바깥의 노드 IP만 보고 라우팅한다 — 안에 Pod 패킷이 들어있는 건 모른 채.

이것이 캡슐화(encapsulation)다. 가장 널리 쓰이는 캡슐화 형식이 VXLAN이다. (VXLAN, RFC 7348)

VXLAN 캡슐화 구조:
[외부 IP 헤더: 노드1 IP → 노드2 IP][UDP 8472][VXLAN 헤더][내부 이더넷][Pod IP 헤더][페이로드]

외부 IP 헤더가 물리 네트워크가 라우팅하는 대상이다. 받는 노드2가 VXLAN 헤더를 인식하고, 내부 Pod 패킷을 꺼내 자기 Pod에게 전달한다.

왜 이 방식이 "어디서든 동작"할까? 물리 네트워크가 특별히 지원할 게 없기 때문이다. 노드 IP만 라우팅되면 된다. 그래서 클라우드 VPC, 온프렘, 심지어 노트북의 kind 클러스터까지 — 어디서든 오버레이는 돌아간다. Flannel(VXLAN), kindnetd가 기본으로 쓰는 방식이다.

대가가 있다. 패킷이 한 번 더 싸이므로 MTU가 감소하고(뒤에 자세히), CPU에서 캡슐화/캡슐해제 연산이 든다. 또한 물리 네트워크에서 패킷을 tcpdump로 봐도 Pod IP가 안 보인다 — VXLAN 안에 숨어있으니까. 디버깅이 한 단계 더 어렵다.

언더레이 — 물리 네트워크에게 Pod 대역을 가르쳐준다

반대 접근: 캡슐화로 숨기지 말고, 물리 라우터에게 Pod 대역을 가르쳐주자. 노드들이 BGP(Border Gateway Protocol)로 이웃 라우터에게 "내 노드엔 10.244.1.0/24가 있다"고 광고하면, 라우터가 그 정보를 학습한다. 그러면 10.244.1.x로 가는 패킷을 노드1로 보내는 방법을 알게 된다.

flowchart LR
    N1["노드1<br/>10.244.1.0/24"] -. "BGP 광고<br/>나는 10.244.1.0/24를 가짐" .-> R["물리 라우터"]
    N2["노드2<br/>10.244.2.0/24"] -. "BGP 광고<br/>나는 10.244.2.0/24를 가짐" .-> R
    R -->|"10.244.2.x → 노드2로 라우팅"| N2

패킷이 캡슐화 없이 그대로 간다. 그래서 성능이 좋고(CPU 오버헤드 없음), 가시성도 좋다 — tcpdump로 잡으면 Pod IP가 그대로 보인다. 디버깅이 훨씬 쉽다.

대가: 물리 네트워크가 BGP를 지원·허용해야 한다. 클라우드 VPC는 보통 노드 간 BGP를 막는다(클라우드 라우터는 사용자 정의 라우팅을 제한). 그래서 클라우드에선 언더레이를 못 쓰고 오버레이로 갈 수밖에 없다. 온프렘 베어메탈이나 자체 데이터센터에서 BGP가 빛을 발한다.

정리: 오버레이는 "물리 네트워크 몰래, 어디서든 동작, 대가는 성능·가시성·MTU". 언더레이는 "물리 네트워크 협력 필요, 성능·가시성 좋음, 대가는 설정 복잡·클라우드 제약". 이 트레이드오프가 CNI 선택의 핵심이다.

두 접근 비교 — 그리고 Calico/Cilium은 둘 다 지원

	오버레이 (VXLAN)	언더레이 (BGP)
Pod 패킷	캡슐화(노드 IP 안에 숨김)	그대로
물리 네트워크 요구	낮음 (어디서나)	높음 (BGP 지원/허용)
성능	캡슐화 오버헤드	더 좋음
가시성	캡슐화돼 덜 보임	패킷 그대로라 보기 쉬움
대표	Flannel(VXLAN), kindnetd	Calico(BGP), Cilium(직접 라우팅)

주의할 점: Calico와 Cilium은 둘 다 모드를 지원한다. Calico는 BGP(언더레이) 또는 IPIP/VXLAN(오버레이). Cilium은 VXLAN 또는 직접 라우팅. (Calico networking modes) (Cilium routing) 그래서 "Calico 쓴다"만으론 부족하다 — 어느 모드인지까지 봐야 그 Calico가 오버레이로 동작하는지 언더레이로 동작하는지 알 수 있다.

MTU 함정 — 오버레이가 패킷 크기를 깎는 이유

오버레이의 캡슐화는 단순히 "패킷이 커진다"를 넘어 MTU(Maximum Transmission Unit)에 실질적 영향을 준다. VXLAN은 패킷 앞에 ~50바이트 헤더(외부 IP+UDP+VXLAN)를 붙인다. 물리 네트워크의 MTU가 1500이라면, Pod가 보낼 수 있는 유효 페이로드는 1500 - 50 = 1450바이트로 줄어든다.

왜 문제인가. 애플리케이션이 1500바이트 패킷을 보내면 — VXLAN 캡슐화 후 전체가 1550바이트가 돼 물리 MTU를 넘는다. 결과: 단편화(fragmentation) 또는 드롭. 느린 전송, 간헐 실패의 원인. 그래서 오버레이 CNI는 Pod 인터페이스의 MTU를 1450 등으로 미리 낮춰 놓는다.

# Kubernetes 1.36, kind — Pod 인터페이스의 MTU 확인
kubectl exec <pod> -- cat /sys/class/net/eth0/mtu

확인할 것: VXLAN/IPIP 오버레이면 1450(또는 유사)으로 감소. 언더레이(BGP/직접)면 물리 MTU(1500) 유지.

정확한 MTU 값은 CNI/모드에 따라 다름. 미검증 환경은 노트.

이 함정이 "클라우드에선 Calico를 BGP가 아니라 VXLAN으로" 쓰는 이유이기도 하다 — 클라우드 VPC가 BGP를 허용 안 하니 어쩔 수 없이 오버레이, 그 대가로 MTU 감소를 감수. 대용량 전송(이미지/파일)이 잦은 워크로드에선 이 MTU 차이가 누적 지연으로 나타난다.

패킷 한 번의 여정 — 두 노드 간 Pod 통신 추적

이해를 굳히기 위해, 노드1의 Pod-A가 노드2의 Pod-B에게 패킷을 보내는 전체 경로를 따라가자(오버레이 VXLAN 기준):

flowchart LR
    A["Pod-A<br/>10.244.1.5"] -->|"1. Pod-A → eth0"| V1["vethA (호스트1)"]
    V1 --> BR1["cni0 브리지"]
    BR1 -->|"2. 목적지 10.244.2.x<br/>→ VXLAN 캡슐화"| VX1["vxlan.calico 등<br/>터널 인터페이스"]
    VX1 -->|"3. 외부 IP(노드1→노드2)로<br/>물리 네트워크 전송"| NET["물리 네트워크"]
    NET --> VX2["vxlan 인터페이스 (호스트2)"]
    VX2 -->|"4. 캡슐 해제<br/>→ 내부 Pod 패킷"| BR2["cni0 브리지"]
    BR2 --> V2["vethB"]
    V2 -->|"5. → Pod-B eth0"| B["Pod-B<br/>10.244.2.3"]

5단계 모두가 제대로 돼야 패킷이 닿는다. 어느 한 단계(브리지 규칙, 터널 인터페이스, 물리 라우팅)가 망가지면 통신 실패. 그래서 "Pod 간 통신 안 됨" 디버깅이 어렵다 — 실패 지점이 5곳이니까.

지금까지 세운 인과 사슬이 이 한 장면에 다 들어있다: 네임스페이스 안 eth0(1) → veth(12) → 브리지(2) → 캡슐화(23) → 물리 라우팅(3) → 역순으로 풀기(4~5). 각 단계가 왜 필요한지 이제 보일 것이다.

IPAM — Pod에 IP를 어떻게 나누는가

IPAM(IP Address Management)이 Pod에 IP를 할당한다. 이것이 단순해 보이지만 대규모에서 설계 과제다. 방식:

• host-local: 각 노드에 CIDR 블록을 미리 할당(예: 노드1은 10.244.1.0/24). 노드 안에선 그 블록에서 순차 할당. 흔한 방식.
• DHCP / 중앙 IPAM: 중앙에서 동적 할당.

보통 각 노드가 자기 CIDR 블록을 갖고(host-local), 그 블록 안의 IP를 Pod에 준다. 노드가 추가되면 새 블록 할당.

여기서 설계 함정: 블록 크기. 노드마다 /24(256개)를 주면 — 노드에 Pod가 256개 넘게 필요하면 IP가 떨어진다. 새 Pod는 IP 못 받아 스케줄 실패. 반대로 /8(6만 개)을 주면 — 노드가 적을 때 IP 대역 낭비, 그리고 라우팅 테이블이 커진다(각 노드가 큰 블록을 BGP로 광고하면 집약이 덜 됨).

좋은 IPAM 설계는 "노드당 예상 Pod 수 × 여유"로 블록 크기를 잡고, 클러스터 전체 CIDR이 노드 수 × 블록을 감당하는지 확인. Calico는 블록 단위 IPAM으로 이것을 구조화.

CNI 체인 — 여러 플러그인을 이어 쓰기

CNI는 체인(chain)으로 여러 플러그인을 이어 쓸 수 있다. 예: Calico(네트워크) + portmap(포트 매핑) + bandwidth(대역 제한). /etc/cni/net.d/의 JSON 설정으로 순서대로 실행. (CNI spec) kindnetd 같은 단순 CNI는 단일 플러그인, Calico/Cilium은 체인 구성이 흔하다.

# Kubernetes 1.36 — 노드의 CNI 설정
docker exec <kind-node> ls /etc/cni/net.d/
docker exec <kind-node> cat /etc/cni/net.d/*.conflist | head -40

확인할 것: 설치된 CNI와 그 체인 구성. kind는 kindnet.

노드 종속 경로라 노드 접속 또는 컨테이너 exec 필요. 미검증 환경은 노트.

CNI와 kube-proxy의 관계 — 다시 한 번 (핵심)

flowchart LR
    P1["Pod1"] -->|"Pod IP로 직접"| CNI["CNI<br/>Pod 간 라우팅"]
    P1 -->|"Service IP로"| KP["kube-proxy<br/>(iptables/IPVS)"]
    KP -->|"DNAT"| CNI
    CNI --> P2["Pod2"]

Service IP로 가는 패킷은 kube-proxy가 DNAT해 Pod IP로 바꾸고, 그 뒤는 CNI가 Pod 간 라우팅. 두 층이 협력하지만 역할이 다르다. Service로 안 되고 Pod IP로도 안 되면 → CNI. Service로만 안 되면 → kube-proxy/EndpointSlice. 이 분기가 장애 진단의 핵심이다.

CNI와 kube-proxy의 협력을 한 문장으로: kube-proxy가 "어느 Pod로 갈지" 결정(DNAT)하고, CNI가 "거기까지 어떻게 보낼지" 실행(라우팅). 둘 중 하나가 고장 나면 각기 다른 증상.

CNI가 안 깔려 있으면 — 14장과의 연결

kubeadm init 직후 노드가 NotReady인 가장 흔한 원인이 "CNI 미설치"다. 그 이유가 여기서 명확해진다 — CNI가 없으면 Pod 네트워크(IPAM/라우팅/veth)가 안 만들어지고, kubelet은 "네트워크 준비 안 됨"으로 노드를 NotReady로 둔다. CNI 설치가 클러스터 부트스트랩의 필수 단계인 이유다.

CRI/CNI/CSI — 세 인터페이스의 대칭

02장에서 CRI(런타임)/CNI(네트워크)/CSI(스토리지)를 봤다. CNI의 위치를 이 대칭 안에서 보면: Kubernetes 코어는 "Pod를 만들되, 어떤 런타임으로(CRI), 어떤 네트워크로(CNI), 어떤 스토리지로(CSI)"를 강제하지 않는다. 세 인터페이스 모두 "이 규격만 지키면 누구나 갈아끼울 수 있다"는 같은 철학. CNI는 그중 네트워크 축. 그래서 Calico/Cilium/Flannel이 다 같은 Kubernetes에서 공존·교체 가능하다.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"CNI는 Service 라우팅을 한다"	Service→Pod는 kube-proxy. CNI는 Pod 간. 다른 층
"오버레이가 항상 느리다"	캡슐화 오버헤드는 있지만 현대 하드웨어에선 큰 차이 아닐 수 있음. MTU 영향이 더 체감
"BGP는 클라우드에서 쓴다"	반대. 클라우드는 VXLAN(오버레이) 흔함. 온프렘 BGP(언더레이)
"CNI 없어도 Pod는 뜬다"	뜨지만 서로 통신 안 됨. 노드도 NotReady
"Calico/Cilium은 한 가지 방식만"	둘 다 오버레이/언더레이 모드 지원. 모드가 성격 결정
"IPAM은 자동이라 신경 안 써도 된다"	CIDR 설계 잘못하면 노드 추가 시 블록 부족. 대규모에선 설계 필요
"Pod IP는 노드의 ip addr에 보인다"	안 보임. 네임스페이스 안 eth0에 붙음. 노드에선 veth만 보임
"MTU는 CNI와 무관하다"	오버레이가 MTU 깎음. 대용량 전송에 영향

요약 — 이 글의 결론

• Pod 네트워크는 세 단계로 만들어진다. 네임스페이스(격리) → veth pair(연결 고리) → 브리지(같은 노드 묶기). 이것이 "한 노드 안 Pod 통신"의 전부이며, 오버레이/언더레이 공통의 기반층이다.
• "Pod IP"는 네임스페이스 안의 eth0에 붙은 IP다. 노드에서 바로 안 보이는 이유. 보려면 네임스페이스에 들어가야.
• 노드 간 문제는 "물리 네트워크가 Pod IP 대역을 모른다"는 데서 시작한다. 오버레이/언더레이는 이 무지를 다루는 두 방식.
• 오버레이(VXLAN)는 Pod 패킷을 노드 IP 안에 숨겨 보낸다 — 어디서든 동작, 대가는 MTU 감소·가시성 저하.
• 언더레이(BGP)는 물리 라우터에게 Pod 대역을 가르쳐준다 — 성능·가시성 좋음, 대가는 BGP 지원 필요(클라우드 제약).
• Calico/Cilium은 둘 다 지원한다. "어느 모드인지"까지 봐야 성격이 보인다.
• MTU 함정 — 오버레이 캡슐화가 Pod 유효 MTU를 ~50 줄임. 대용량 전송 지연/단편화 원인. 클라우드가 VXLAN 쓰는 대가.
• CNI와 kube-proxy는 다른 층. Service→Pod는 kube-proxy(DNAT), Pod 간은 CNI(라우팅). 장애 진단의 핵심 분기.
• CNI 미설치가 kubeadm 직후 NotReady의 흔한 원인.

생각해 볼 문제

1. Pod IP로 직접 접속하는 코드를 Service로 바꿔야 한다. 구체적 변경점은? (이유까지)
2. Service로 접속은 되는데 Pod IP로는 안 된다. 어느 층의 문제인가? 어떻게 진단하나?
3. 노드에서 ip addr을 봐도 Pod IP가 안 보인다. 어디서 봐야 하나? 왜?
4. 오버레이(VXLAN)가 MTU를 감소시키는 이유는? 앱에 미치는 영향은?
5. 클라우드 VPC에서 Calico를 BGP 모드로 쓰면 안 되는 이유는? (VPC 라우팅과 BGP)
6. 네임스페이스로 격리한 뒤 veth pair를 안 만들면 컨테이너가 겪는 현상은?
7. 노드가 1000개일 때 host-local IPAM의 블록 설계를 고민해 보라. 블록 크기는?
8. 오버레이가 "어디서든 동작한다"는 장점의 대가로 지불하는 것 세 가지는?

---

참고

• Kubernetes 공식 문서 - Cluster Networking - 접근 2026-07-13 (CNI 개요)
• CNI spec - containernetworking/cni - 접근 2026-07-13 (체인, IPAM)
• Calico networking modes (overlay/underlay) - 접근 2026-07-13 (모드 비교)
• Cilium networking (VXLAN vs routing) - 접근 2026-07-13
• 리눅스 네임스페이스/veth - man ip-netns - 접근 2026-07-13 (네임스페이스, veth)
• VXLAN (RFC 7348) - 접근 2026-07-13 (캡슐화 구조)
• 리눅스 브리지 - man bridge - 접근 2026-07-13 (L2 스위치 역할)