CNI

정의

- Pod가 네트워크에 연결되도록 인프라를 구성하는 플러그인

- Pod IP 간 통신은 CNI만으로 동작, kube-proxy, netfilter 관여하지 않음
	- 같은 Node, 다른 Node

수행 시점

- Pod 생성/삭제 시 kubelet이 CNI 플러그인을 호출

하는 일

1. veth 쌍 생성 (Pod 쪽 eth0 <-> 호스트 쪽(브리지) vethXXXX)

2. cni0(or cbr0) 브리지 생성 및 veth 연결

3. Pod에 IP 할당(IPAM)

4. 노드 간 라우팅 설정(API 서버에서 각 노드의 Pod CIDR을 watch -> 라우팅 테이블 등록)
	- 노드별 Pod CIDR 단위로 저장
		EX. Node 3개
			- 10.244.1.0/24 -> Node A (192.168.59.4)
			- 10.244.2.0/24 -> Node B (192.168.60.3)
			- 10.244.3.0/24 -> Node C (192.168.60.4)
		 => 이후
			- 도착한 노드에서 개별 Pod를 찾는 건 cni0 브리지나 MAC 테이블로 L2 스위칭
				- 이게 가능한 이유는 CNI가 veth 쌍으로 만들어서 cni0 브리지에 연결하면, 브리지가
					해당 veth의 MAC 주소를 자동으로 학습

Pod IP로만 통신하는 경우

1. Pod IP를 이미 아는 경우
- 코드에서 하드코딩하거나 환경변수로 받았거나, 이때는 coreDNS 안 거치고 바로 Pod IP로 요청
- CNI 라우팅만 탐

2. Headless Service(ClusterIP를 Nonde으로 설정한 Service)를 쓰는 경우
- coreDNS에 질의하면 ClusterIP 대신 Pod IP를 직접 응답
- 이때는 coreDNS를 거치지만 DNAT 없이 바로 CNI 라우팅으로 전달

플러그인 별 노드 간 전달 방식 차이

[ Flannel ]
- VXLAN 캡슐화(Pod 패킷을 노드 IP간 UDP로 감쌈)
- 어떤 네트워크에서든 동작
- 추가 기능은 없음

[ Calico ]
- BGP로 직접 라우팅(캡슐화 X)
- 성능 좋음, 네트워크 폴리시 지원
- 네트워크 장비가 BGP 지원하거나 같은 L2 서브넷이어야 함

[ Cilium ]
- eBPF 기반
- kube-proxy 대체 가능
- 네트워크 폴리시 + L7 모니터링 등 가장 기능 풍부

[ Weave ]
- 캡슐화 + 암호화 지원