Amazon EKS 환경에서 네트워크 구성은 대부분 AWS VPC CNI + kube-proxy 조합으로 시작된다.
이는 AWS 네이티브 통합과 기본 안정성 측면에서 합리적인 선택이지만, 네트워크 성능, 보안 정책, 관찰 가능성 측면에서는 한계가 존재한다.
이 글에서는 EKS 운영 환경에서 널리 사용되는 두 CNI: Calico와 Cilium을 기술적 관점과 실무 적용 가능성 중심으로 비교한 결과를 정리한다.
특히 Cilium 도입을 검토하거나 전환을 고려하는 팀을 위해, EKS에서의 실제 도입 배경과 고려 포인트까지 포함한다.
항목 | Calico | Cilium |
---|---|---|
데이터 플레인 | iptables, eBPF, VPP 등 유연한 구조 | eBPF 단일 기반 |
보안 정책 모델 | IP 기반 정책 + DNS, Enterprise 옵션 | ID 기반 정책 (ServiceAccount 등) |
라우팅 구조 | AWS VPC CNI 또는 Overlay 기반 + kube-proxy | eBPF로 kube-proxy 제거 가능, AWS ENI 지원 |
관찰 도구 | Prometheus, Grafana 등 외부 연동 | Hubble 내장, 네트워크 흐름 실시간 추적 |
멀티클러스터 | BGP 기반 구성이 가능 | ClusterMesh로 최대 255 클러스터 통합 |
운영 툴링 | calicoctl , API, 엔터프라이즈 UI 등 풍부 | Cilium CLI, CRD 중심 구성 |
EKS를 처음 구성했을 때는 기본 네트워크 구성인 AWS VPC CNI + kube-proxy를 사용했다.
이 조합은 다음과 같은 장점을 제공한다:
하지만 클러스터 운영 규모가 커지고, 보안 정책과 관찰 요구가 정교해지면서 다음과 같은 한계가 눈에 띄기 시작했다:
이런 문제를 해결하고자 Cilium을 검토하게 되었고, 실험적으로 일부 워크로드에 적용해 본 결과 다음과 같은 장점을 체감할 수 있었다:
Cilium은 강력한 기능을 제공하지만, EKS에 도입할 때는 AWS 특성과의 통합 및 기존 구조와의 충돌을 충분히 고려해야 한다.
EKS에서 제공하는 기본 AMI는 Linux 5.x 커널 기반 → eBPF 기능 활용 가능
TCX
(tc eXpress)는 지원되지 않아 직접 커널이 6.1 이상인 커스텀 AMI 빌드 또는 Bottlerocket 같은 배포판 활용을 고려해야 함Bottlerocket, Amazon Linux 2, Ubuntu 모두 사용 가능
eni
IPAM 모드를 통해 AWS VPC CNI처럼 ENI 기반 IP 할당 가능kube-proxy-free
모드는 성능적으로 유리하지만, 초기에는 kube-proxy
와 병행하는 hybrid 모드로 시작하는 것을 권장하나 가급적 kube-proxy
를 제거하여 사용하는 편이 좋음kubeProxyReplacement=true
또는 false
로 설정NetworkPolicy
→ Cilium의 CiliumNetworkPolicy
로 전환 필요auditMode=true
설정으로 트래픽 차단 없이 로그 수집 가능Cilium을 선택한 것은 단순히 성능 때문만은 아니다.
네트워크 장애의 원인을 빠르게 파악하고, 신뢰성 있는 정책 적용을 지속적으로 보장할 수 있는 구조가 필요했기 때문이다.
이러한 점에서 Cilium은 단순한 CNI를 넘어, 네트워크 운영을 더 예측 가능하고 명확하게 만들어주는 도구라고 판단했다.
참고 문서