EKS에서 Cilium 도입하기: eBPF 기반 네트워크 전환과 그 이유

이언철·2025년 4월 4일
0

DevOps

목록 보기
19/19

Amazon EKS 환경에서 네트워크 구성은 대부분 AWS VPC CNI + kube-proxy 조합으로 시작된다.

이는 AWS 네이티브 통합과 기본 안정성 측면에서 합리적인 선택이지만, 네트워크 성능, 보안 정책, 관찰 가능성 측면에서는 한계가 존재한다.

이 글에서는 EKS 운영 환경에서 널리 사용되는 두 CNI: CalicoCilium을 기술적 관점과 실무 적용 가능성 중심으로 비교한 결과를 정리한다.

특히 Cilium 도입을 검토하거나 전환을 고려하는 팀을 위해, EKS에서의 실제 도입 배경과 고려 포인트까지 포함한다.


1. 기술 기반 비교

항목CalicoCilium
데이터 플레인iptables, eBPF, VPP 등 유연한 구조eBPF 단일 기반
보안 정책 모델IP 기반 정책 + DNS, Enterprise 옵션ID 기반 정책 (ServiceAccount 등)
라우팅 구조AWS VPC CNI 또는 Overlay 기반 + kube-proxyeBPF로 kube-proxy 제거 가능, AWS ENI 지원
관찰 도구Prometheus, Grafana 등 외부 연동Hubble 내장, 네트워크 흐름 실시간 추적
멀티클러스터BGP 기반 구성이 가능ClusterMesh로 최대 255 클러스터 통합
운영 툴링calicoctl, API, 엔터프라이즈 UI 등 풍부Cilium CLI, CRD 중심 구성



2. 왜 Cilium을 고려하게 되었는가

EKS를 처음 구성했을 때는 기본 네트워크 구성인 AWS VPC CNI + kube-proxy를 사용했다.

이 조합은 다음과 같은 장점을 제공한다:

  • Pod IP가 AWS ENI를 직접 사용 → VPC 내 IP 레벨 접근 제어 연동
  • AWS IAM for ServiceAccount(IAM Roles for Pods)와 쉽게 통합
  • 관리형 서비스로서 안정적이고, 빠른 배포 가능

하지만 클러스터 운영 규모가 커지고, 보안 정책과 관찰 요구가 정교해지면서 다음과 같은 한계가 눈에 띄기 시작했다:

  • iptables 기반 정책 룰 증가에 따른 성능 저하
  • kube-proxy의 복잡한 NAT 처리와 디버깅 어려움
  • Pod 간 흐름 추적 불가 → 네트워크 장애 분석 속도 저하
  • DNS 지연이나 Drop 발생 시 원인 파악 어려움

이런 문제를 해결하고자 Cilium을 검토하게 되었고, 실험적으로 일부 워크로드에 적용해 본 결과 다음과 같은 장점을 체감할 수 있었다:

  • Hubble을 통한 L3~L7 흐름 추적 → 네트워크 장애 분석 시간 단축
  • kube-proxy 제거 → iptables 룰 복잡도 해소
  • ID 기반 정책 → 보안 정책 설계 단순화
  • AWS VPC CNI chainingMode 연동 → ENI 기반 IP 그대로 활용 가능



3. Cilium 도입 시 고려할 포인트

Cilium은 강력한 기능을 제공하지만, EKS에 도입할 때는 AWS 특성과의 통합 및 기존 구조와의 충돌을 충분히 고려해야 한다.

커널 및 플랫폼 요구사항

  • EKS에서 제공하는 기본 AMI는 Linux 5.x 커널 기반 → eBPF 기능 활용 가능

    • 다만, Cilium 1.14부터 도입된 eBPF 기반의 새로운 트래픽 제어 프레임워크인 TCX(tc eXpress)는 지원되지 않아 직접 커널이 6.1 이상인 커스텀 AMI 빌드 또는 Bottlerocket 같은 배포판 활용을 고려해야 함
  • Bottlerocket, Amazon Linux 2, Ubuntu 모두 사용 가능

IPAM 및 ENI 연동

  • Cilium은 eni IPAM 모드를 통해 AWS VPC CNI처럼 ENI 기반 IP 할당 가능
  • 기존 VPC CNI와 병행 사용하지 않고 대체하려면 IPAM 모드 설정 필요
  • 기존 VPC CNI와 병행하여 사용하려면 체이닝 모드 설정 필요

kube-proxy 제거 여부

  • kube-proxy-free 모드는 성능적으로 유리하지만, 초기에는 kube-proxy와 병행하는 hybrid 모드로 시작하는 것을 권장하나 가급적 kube-proxy를 제거하여 사용하는 편이 좋음
  • Cilium Helm 값에서 kubeProxyReplacement=true 또는 false로 설정

Hubble 구성 및 Prometheus 연동

  • Hubble UI, Relay, CLI를 함께 구성하면 실시간 흐름 추적 가능
  • Prometheus/Grafana로 연동하여 주요 핵심 지표 수집 가능

정책 전환 방식

  • 기존 NetworkPolicy → Cilium의 CiliumNetworkPolicy로 전환 필요
  • 테스트 및 적용 단계에서 auditMode=true 설정으로 트래픽 차단 없이 로그 수집 가능



4. Cilium을 선택한 이유

Cilium을 선택한 것은 단순히 성능 때문만은 아니다.

네트워크 장애의 원인을 빠르게 파악하고, 신뢰성 있는 정책 적용을 지속적으로 보장할 수 있는 구조가 필요했기 때문이다.

  • 관찰 가능성: Hubble로 트래픽 흐름을 실시간으로 확인할 수 있다는 점은 SRE 입장에서 매우 큰 장점이다.
  • kube-proxy 제거: iptables 복잡도를 줄이고, L3~L4 라우팅 구조를 단순화함으로써 네트워크 제어가 쉬워졌다.
  • 보안 정책의 명확성: IP가 아닌 서비스 ID 기준 정책으로 인해 실수 가능성을 줄일 수 있었다.

이러한 점에서 Cilium은 단순한 CNI를 넘어, 네트워크 운영을 더 예측 가능하고 명확하게 만들어주는 도구라고 판단했다.


참고 문서

profile
DevOps Engineer @Soomgo | Grafana Champion

0개의 댓글