
현재까지 EKS에서 기본 제공하는 AWS VPC CNI를 사용하면서 AWS VPC CNI가 최고인줄 알았다.👍🏻
기존 Calico나 flannel과 같은 전통적인 CNI보다는 세련됐다고 생각되었기 때문이다.
그도 그럴것이, IP모드를 지원하기도 하여 서비스를 중간에 거치지 않고 파드로 직접적인 트래픽을 보내 latency를 감소시킬 수도 있고, Node와 파드의 IP가 동일하기에 오버레이 네트워크(IPIP, VXLAN) 작업을 해줄 필요가 없기 때문이다.
하지만, 이번 뉴욕타임즈에서 개최된 실리움 콘을 보고나서 생각이 좀 달라졌다.
🍯Celium CNI에 관한 영상이였는데 AWS VPC CNI의 iptables보다 eBEF🐝를 사용하기에 훨씬 빠르게 통신이 가능하다는 것이였다.

AWS VPC CNI는 사용자의 요청을 서비스 ➡️ 파드로 보낼 때, kubeproxy가 동작한다. 이때, kubeproxy는 iptables 기술을 사용하는데, 이러한 iptables 기술은 그림과 같이 여러 네트워크 스택을 거치면서 큰 오버헤드가 발생하게된다.
반면 Celium CNI는 eBEF🐝기술을 사용하므로 호스트 라우팅을 통해 네트워크 스택을 거치지 않고, 트래픽을 커널에서 직접 전달하게 된다.

Celium CNI를 EKS에서 사용하기 위해서는 기존 AWS VPC CNI의 전유물인 aws-node와 kube-proxy를 삭제하는 작업을 진행 후 Celium CNI를 설치해 주어야한다.
이를 삭제하는 이유는 실리움(Cilium)을 통해 kube-proxy가 수행하는 기능들, 즉 서비스 디스커버리와 로드 밸런싱을 eBPF🐝를 통해 대체할 수 있기 때문이다.
먼저 AWS VPC CNI는 IP 부족 문제를 해결하기 위해서 IP prefix 방식을 사용한다.
IP prefix 방식이란 기존 ENI 슬롯당 /32 Prefix을 /28 Prefix로 변경하여 4개의 Prefix를 호스트 IP로 사용하는 것이다.
이를 통해서 ENI의 슬롯 당 16개의 IP를 할당할 수 있게 된다.

Celium CNI또한 이러한 IP prefix 기능을 동일하게 제공한다.
또한, 🌐다른 IP대역의 사용 또한 제공한다. 예를들어, 기존 사용하는 10대역(10.0.0.0~10.255.255.255)에서 IP를 전부 소진하면, 100대역(100.64.0.0~100.127.255.255)을 추가해서 사용하는 것이다.
사실 이러한 다른 IP 대역을 추가하는 것은 대부분의 VPC CNI가 전부 가지고 있는 기능이다. 하하😅

iptables는 각각의 규칙을 순차적으로 적용하기 때문에, 규칙이 많아질수록 성능 저하가 발생한다.
반면에 eBPF🐝는 호스트 라우팅을 통해 더 효율적인 경로를 제공하고, 트래픽 처리가 가능하다. 따라서 eBPF🐝를 사용하는 Cilium을 사용한다면 성능과 확장성을 향상시킬 수 있다!