[k8s] CNI (Container Network Interface)

CNI는 쿠버네티스의 Pod 간 통신을 제어할 수 있게 해주는 네트워크 계층을 말한다.
성능, 보안 수준과 밀접한 관련이 있다.

CNI에 어떤 것들이 있고, 어떤 역할을 하는지 대략적으로 정리해본다.

CNI (Container Network Interface)

쿠버네티스의 장점 중 하나는 클러스터 내의 컨테이너(Pod)들끼리 간편하게 내부 통신을 수행할 수 있다는 것이다.
각 Pod에는 10.244.2.8 같은 클러스터 내부 IP가 할당되며, POD들끼리는 내부 IP를 통해 직접 통신이 가능하다.

CNI는 이런 Pod <> Pod간 통신이 가능하게끔 연결해주는 역할을 한다.

하지만 CNI는 정해져있는 것이 없으며, 구현체가 여럿 있고 상세 동작 방식도 각자 다르다.
널리 쓰이는 CNI 구현체로는 Calico와 Flannel, Cilium 등이 있다.

Flannel은 간단한 구성에 안정적인 성능을 가진 경량 CNI로, 적당한 규모에서는 매우 훌륭한 선택이 될 수 있다.

하지만 복잡한 네트워크 정책 구성이나 높은 성능이 필요하다면 Calico와 Cilium을 선택하는 경향이 있다. 복잡하지만 많은 기능을 제공한다.

CNI: Flannel

Flannel은 k3s의 기본 CNI이기도 하며, 상기했든 단순함을 최대 장점으로 내세우는 구현체다.
Flannel은 Overlay 네트워크 방식을 통해 Pod 간 통신을 구현한다.

쉽게 말해 클러스터 전체에 공유되는 가상 네트워크를 구축하고, 통신이 발생할때마다 Flannel이 그걸 가로채서 Pod에 목적지에 전송해주는 것이다. 이걸 VXLAN 모드라고 부른다.

Flannel은 이 과정에서 가로챈 패킷을 자체적인 UDP 기반 패킷으로 감싼 다음에 목적지로 전송한다.
그리고 수신자 입장에서는 다시 패킷을 추출해서 원래의 데이터로 받는 것이다.

이 방식은 많은 환경에서 아주 안정적으로 동작한다. 다른 CNI들은 장비 환경에 종속돼서 클라우드면 잘 안될수도 있고 변수가 있는데, 이건 어지간하면 문제없이 동작할 것이다.

이렇게 보면 직관적이고 간편해보이지만, 당연히 단점도 있다.
아무튼 Flannel이 패킷을 다시 감싸고 푸는 과정이 추가되기 때문에, 약간의 성능 손실은 발생한다.

그리고 무엇보다 큰 단점은 보안 수준 기능이다.
Network Policy가 지원되지 않는다. 다시 말해 Pod들끼리 통신을 자유롭게 열 수는 있지만, 방화벽을 원하는대로 걸 수는 없다. 그래서 보안 정책을 엄격하게 지켜야 하는 경우에는 적합하지 않을 수 있다.
내부 트래픽에 대한 암호화 등도 불가능하다.

CNI: Calico

calico는 연식이 좀 된 CNI 구현체 중 하나다. 예전에는 많이 썼는데 요즘은 트렌드에서 약간 밀린 것 같다.
그래도 여전히 대규모의 프로덕션 환경에서는 가장 적합하다고 이야기한다. 설정과 관리가 매우 까다로운 대신, 높은 성능, 보안 수준을 전부 가져갈 수 있기 때문이다.

이건 매우 근본적인 방식으로 Pod 간의 통신구조를 잇는다. 가상 네트워크 그런걸 따로 구성하진 않고, 전부 라우팅 테이블에 등록한 다음에 계층 없이 직접 통신하도록 하는 것이다.

예를 들면, 같은 노드 안에 있는 Pod들의 경우에는 커널 기능만을 사용해서 veth pair 기반의 내부 통신을 한다.

그리고 다른 노드 안에 있는 Pod들끼리 통신할 경우에는 BGP (Border Gateway Protocol)이란 것을 통해 상호간 통신을 수행한다. 물리 네트워크를 거치되 원본 패킷을 직접 forwarding해버리는 것이다. 따로 패킷을 가공하는 과정이 없어서 빠르다.
BGP 통신에는 TCP 179 포트를 사용한다.

최적의 성능을 내고 보안 정책을 구성하기도 좋지만, 구성이 쓸데없이 복잡하다는 단점이 있다.
이걸 제대로 쓰려면 부가적인 플러그인들을 덕지덕지 발라야 한다.

게다가 하드웨어 제약도 있다. BGP는 사실 모든 환경에서 쓸 수 있는 통신 규격이 아니다. AWS/GCP/Azure 같은 가상화 기반의 클라우드 서비스들은 대부분 BGP 사용 자체가 불가능하다.

CNI: Cilium

cilium은 최근 부상하고 있는 CNI 구현체다. 전반적인 접근법은 Flannel과 비슷하다.

높은 성능과 관측성, 보안 기능을 장점으로 내세운다. 가장 특별한 부분은 L7 NetworkPolicy 기능을 제공한다는 것이다. HTTP 수준의 필터링 제약이 가능하다.

이건 eBPF이라는 패킷 전송용 커널 기능으로 네트워킹을 구현하며, 그 덕분에 높은 수준의 성능과 관측성을 달성할 수 있다는 것이 장점이다.

같은 노드에서 통신할 경우에는 eBPF를 통해서 패킷을 전달한다.
다른 노드에서 통신할 경우에는 eBPF VXLAN라는 eBPF 기반의 오버레이 네트워크 시스템을 사용한다. Flannel보다 빠른 성능을 제공하는 것은, iptables의 역할을 빠른 eBPF가 가져가기 때문이다.

단점은 트러블슈팅 복잡도가 매우 높고, 기술 자체의 전반적인 성숙도가 낮다는 것이다.

근데 성능이 가장 압도적이라는 홍보성 글들이 많이 보이는데, 실제로는 calico 등과 성능 차이가 의미있게 나지 않는다. calico라고 eBPF를 쓰지 못하는 것은 아니기 때문이다... 바이럴이 심한 편이다.

참조
https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/
https://daily.dev/blog/kubernetes-cni-comparison-flannel-vs-calico-vs-canal
https://github.com/containernetworking/cni