EKS에서 Cilium 설치 모드 3가지 비교: ENI vs CNI Chaining vs BYOCNI(Overlay)

개요

EKS에서 Cilium을 “어떤 방식으로” 설치할지는 사실상 Pod IP를 누가/어떻게 할당하고(VPC ENI vs 오버레이), VPC가 Pod IP를 직접 라우팅할 수 있는지(Direct routing vs Encapsulation), 그리고 AWS 기본 애드온(AWS VPC CNI, kube-proxy)을 얼마나 유지할지를 결정하는 문제입니다.

이 글에서는 아래 3개 자료가 각각 어떤 글인지, 어떤 구조로 작업하는지, 구성 차이와 장단점은 무엇인지 정리합니다.

작성/검증 기준: 위 문서/블로그의 서술을 “그대로 재현 가능한가?”, “운영에서 어떤 제약이 생기는가?” 관점으로 비교합니다. (버전/기본값은 시간에 따라 바뀔 수 있으니, 실제 적용 전에는 반드시 최신 문서의 Helm 값과 EKS 애드온 상태를 확인하세요.)

TL;DR (결론)

• ENI 모드(추천/정공법): AWS VPC CNI를 빼고 Cilium이 ENI/IPAM을 맡습니다. VPC 네이티브 라우팅 + kube-proxy-free까지 한 번에 가기 좋지만, AWS 권한/운영 변경 폭이 큽니다.
• CNI chaining 모드(현실적 타협안): AWS VPC CNI는 그대로 두고, Cilium을 “두 번째 CNI”로 체이닝해 eBPF 정책/LB/암호화 등을 얹습니다. 기존 클러스터에 적용하기 비교적 쉽지만, “두 CNI 공존” 운영 복잡도가 생깁니다.
• BYOCNI(Overlay) 모드(ENI IP 한계 회피): AWS VPC CNI 없이 Cilium이 오버레이(VXLAN/Geneve)로 Pod 네트워크를 구성합니다. ENI 기반 IP 제약에서 자유로워지지만, 캡슐레이션 오버헤드/MTU/트러블슈팅 난이도가 올라갑니다.

1) 각 글은 “무슨 글”인가?

(1) eks-eni-install: “EKS에서 Cilium ENI 모드 설치” 튜토리얼

이 글은 EKS에서 Cilium을 ENI 모드로 설치하는 과정을 보여줍니다.

• 핵심 방향
  • addonsConfig.disableDefaultAddons: true로 기본 네트워킹 애드온(AWS VPC CNI, kube-proxy)을 비활성화한 상태로 클러스터를 만들고
  • Helm으로 Cilium을 설치할 때 eni.enabled=true, ipam.mode=eni, routingMode=native, kubeProxyReplacement=true 등을 켭니다.
• 작업 구조(큰 흐름)
  1. EKS 클러스터 생성(기본 애드온 비활성화) → 2) Cilium 설치(ENI/IPAM + kube-proxy replacement) → 3) 노드그룹 생성 → 4) cilium status, cilium connectivity test로 검증

글에서 “기본 애드온 비활성화로 클러스터+노드그룹을 한 번에 만들 수 없다”는 제약을 언급합니다. 이는 eksctl/EKS의 지원 범위가 변할 수 있는 부분이므로, 실제 적용 시점의 eksctl 문서를 확인하는 것이 안전합니다.

(2) byonci-overlay-install: “chaining vs overlay(BYOCNI)” 비교/설치 튜토리얼

이 글은 시리즈 2편으로, 설치 모드를 2개 더 다룹니다.

1. CNI chaining 모드

• 클러스터 생성 시 기본 애드온을 끄되, addons:에 vpc-cni를 명시적으로 포함시켜 AWS VPC CNI를 설치합니다.
• Cilium은 cni.chainingMode=aws-cni, cni.exclusive=false, routingMode=native 등으로 설치합니다.

2. BYOCNI(Overlay) 모드

• AWS VPC CNI를 포함하지 않고(= 사실상 BYOCNI), Cilium이 오버레이 네트워크를 구성하는 방식으로 설명합니다.
• 핵심 메시지는 “AWS ENI 기반의 Pod IP 제한(노드당 할당 가능 IP 수 등)에서 벗어날 수 있다”입니다.

(3) cni-chaining-aws-cni: “체이닝 모드”에 대한 공식 레퍼런스

공식 문서는 “AWS VPC CNI + Cilium” 조합을 명확한 책임 분리로 정의합니다.

• AWS VPC CNI: ENI 기반 디바이스 구성 + IPAM
• Cilium: 해당 디바이스에 eBPF 부착(정책/LB/암호화 등)

또한 운영에서 놓치기 쉬운 포인트를 강조합니다.

• AWS VPC CNI 플러그인 버전 요구사항(예: v1.11.2 이상)
• 기존 Pod 재시작 필요(체이닝 구성은 이미 떠있는 Pod에 자동 적용되지 않음)
• (고급) EKS의 Security Groups for Pods(Pod ENI) 연동 방법

2) 각 구성의 “작업 구조(구성요소/흐름)”는 어떻게 다른가?

핵심은 Pod 생성 시점에 어떤 CNI가 먼저 실행되고, 누가 IP를 책임지는지입니다.

(A) ENI 모드: “Cilium이 ENI/IPAM까지 담당”

• AWS VPC CNI(aws-node)는 제거/비활성화되는 방향입니다.
• Pod IP는 ENI에서 나오므로(= VPC에서 직접 라우팅 가능), 오버레이 캡슐레이션이 필요 없습니다.
• 블로그 예시에서는 kube-proxy까지 비활성화하고 kubeProxyReplacement=true를 켭니다.

(B) CNI chaining 모드: “AWS VPC CNI가 IPAM, Cilium이 eBPF”

• Pod IP는 여전히 ENI 기반이라 VPC 네이티브 라우팅을 사용합니다.
• 운영 관점의 핵심 차이는 CNI가 2개라는 점입니다(aws-node + cilium).
• 공식 문서가 “기존 Pod 재시작 필요”를 명시하는 이유도 여기서 나옵니다(이미 만들어진 네트워크 디바이스에는 체이닝 단계가 적용되지 않음).

(C) BYOCNI(Overlay) 모드: “Cilium이 오버레이로 Pod 네트워크 구성”

• Pod IP가 VPC에서 “직접 라우팅”되는 모델이 아니라, 노드 간 트래픽이 캡슐레이션됩니다.
• 이 방식의 목적은 “ENI IP 리밋/주소계획” 같은 VPC-네이티브 제약에서 벗어나는 것입니다.
• 대신 MTU/오버헤드/네트워크 가시성 문제를 운영에서 감당해야 합니다.

3) 구성별 차이점 요약(결정 포인트)

한눈에 비교표

4) 장단점 분석(운영 관점)

ENI 모드

장점

• VPC 네이티브 Pod IP(오버레이/캡슐레이션 불필요) → 성능/단순성 측면에서 유리
• kubeProxyReplacement=true로 kube-proxy-free 구성까지 자연스럽게 연결
• EKS의 “기본 애드온 없이 클러스터 생성” 기능과 궁합이 좋음(블로그가 이 흐름을 사용)

단점/주의점

• AWS VPC CNI를 대체하는 만큼 운영 변경 폭이 큼(기존 표준/런북/트러블슈팅 체계가 바뀜)
• Helm 값의 정확성이 중요:
  • k8sServiceHost에는 https://를 제거해야 한다는 주의가 블로그에 명시되어 있음(잘못 넣으면 에이전트 크래시)
  • 블로그 예시의 egressMasqueradeInterfaces=eth+는 그대로 쓰기 전에 노드 인터페이스 이름을 확인하는 게 안전함(예: eth0, ens5 등)

CNI chaining 모드

장점

• AWS VPC CNI를 유지하면서 Cilium의 정책/관측/기능을 단계적으로 도입하기 쉬움
• 공식 문서가 제공하는 전제/검증/업그레이드 포인트가 비교적 명확함
• (고급) EKS Security Groups for Pods 연동 가이드가 존재

단점/주의점

• “2개 CNI”는 곧 장애/디버깅 경로가 2배가 된다는 뜻(누가 어디서 패킷을 바꿨는지 추적이 어려워짐)
• 공식 문서에 명시된 대로, 체이닝 적용을 위해 기존 Pod 재시작이 사실상 필수
• aws-node 버전 요구사항 존재(문서는 v1.11.2+ 권고)
• 공식 문서의 라벨 표기에서 vps.amazonaws.com/has-trunk-attached가 등장하지만, 명령 예시는 vpc.amazonaws.com/has-trunk-attached를 사용합니다. 실제 현장에선 vpc.amazonaws.com/has-trunk-attached가 일반적이므로, 적용 시 클러스터에서 실제 라벨 키를 확인하세요.

BYOCNI(Overlay) 모드

장점

• ENI 기반 Pod IP 한계(노드당 할당 가능한 IP 수, 주소 계획 등)에서 상대적으로 자유로움
• VPC가 Pod IP를 직접 라우팅하지 않아도 되므로, 네트워크 설계가 단순해질 때가 있음(대신 터널이 등장)

단점/주의점

• 캡슐레이션 오버헤드 + MTU 이슈로 성능/장애 포인트가 증가
• 보안그룹/네트워크 정책/관측(Flow) 이슈가 있을 때, “VPC 라우팅 문제”가 아니라 “터널/MTU/경로 문제”로 바뀌어 문제 공간이 넓어짐

5) “나는 무엇을 선택해야 하나?” (실전 선택 가이드)

• EKS 신규 클러스터이고, 표준화를 원하며, kube-proxy-free까지 고려한다 → ENI 모드가 1순위 후보
• 기존 EKS에 AWS VPC CNI를 유지한 채로, Cilium의 정책/관측을 먼저 도입하고 싶다 → CNI chaining 모드가 현실적
• 노드당 Pod 수가 많고(ENI IP가 병목), VPC 주소계획/ENI 리밋이 계속 발목 잡는다 → BYOCNI(Overlay) 검토(단, MTU/오버레이 운영 비용을 감당할 준비가 필요)

5.1) “Pod IP 부족”이 출발점이라면 (오해 방지)

많은 팀이 Cilium을 검토하는 계기가 “Pod가 사용할 수 있는 IP 수가 금방 찬다”인데, 이때는 먼저 아래를 정리하는 게 좋습니다.

• IP가 부족한 원인이 무엇인가?
  • (1) 노드 인스턴스 타입의 ENI/IP 한도 때문에 노드당 Pod가 막히는지
  • (2) 서브넷 CIDR 자체가 작아서(= VPC 전체 주소가 부족해서) 더 이상 IP를 못 쓰는지

그리고 결론은 꽤 단순합니다.

• Cilium을 ENI 모드로 “대체”하거나, AWS VPC CNI와 chaining(혼용)해도, Pod가 여전히 VPC-routable IP(ENI 기반 IP) 를 쓰는 구조라면 VPC IP 고갈 문제를 “근본적으로” 해결하지 못할 수 있습니다.
  • 다만 노드당 ENI/IP 한도 문제라면, “인스턴스 타입 변경/노드 확장/Prefix Delegation” 같은 AWS 네이티브 튜닝이 더 직접적인 해법인 경우가 많습니다.
• VPC IP 고갈에서 정말로 멀어지는 선택지는 대체로 Overlay(BYOCNI)처럼 Pod IP를 VPC 밖(오버레이 IP 풀)에서 쓰는 방식인데, 대신 “AWS 네이티브 통합”과 트레이드오프가 생깁니다.

5.2) AWS 네이티브 연동 관점에서의 트레이드오프

Pod IP 부족을 해결하려고 네트워킹 구성을 바꾸면, “VPC가 Pod IP를 직접 라우팅/관찰할 수 있느냐”가 AWS 네이티브 기능 사용성에 큰 영향을 줍니다.

CNI chaining (AWS VPC CNI 유지)

• 장점: AWS VPC CNI가 계속 ENI/IPAM을 담당하므로, 기존 EKS 운영/연동의 연속성이 가장 좋습니다.
• 단점: Pod가 계속 VPC IP를 소모하므로 IP 고갈 문제는 그대로일 가능성이 큽니다.

Cilium ENI 모드 (AWS VPC CNI 대체)

• 장점: Pod IP가 VPC에서 직접 라우팅되는 모델(ENI 기반)을 쓰는 방향이라, 오버레이에 비해 네트워크 모델이 단순한 편입니다.
• 단점: aws-node(AWS VPC CNI)에 의존하던 운영/튜닝 포인트(예: aws-node 중심의 파라미터/런북)는 재정의가 필요할 수 있습니다. 적용 전에는 “우리 조직이 aws-node 기반으로 기대하는 기능이 무엇인지”를 목록으로 뽑아 검토하는 게 안전합니다.

Overlay(BYOCNI)

• 장점: VPC IP 고갈에서 가장 직접적으로 벗어날 수 있는 선택지입니다(설계에 따라).
• 단점: Pod IP가 VPC에서 직접 라우팅되지 않기 때문에, 아래처럼 “Pod IP가 VPC에서 reachable/routable 하다”를 전제로 하는 구성이 제약을 받을 수 있습니다.
  • AWS Load Balancer Controller에서 target-type: ip 기반 설계(파드 IP를 VPC에서 직접 찍어야 하는 구성)
  • 네트워크 가시성/트러블슈팅을 VPC Flow Logs/보안그룹/NACL 관점에서 Pod 단위로 단순하게 가져가던 방식
  • MTU/캡슐레이션 이슈로 인한 장애 포인트 증가

5.3) IP 부족일 때 “먼저” 보는 AWS 네이티브 해법(체크리스트)

Overlay로 가기 전에, 아래는 EKS에서 실제로 가장 자주 쓰는 해결책입니다.

(1) AWS VPC CNI Prefix Delegation

노드당 Pod 수가 “ENI/IP 한도”에 의해 막히는 경우, Prefix Delegation이 체감 효과가 큰 편입니다(단, 서브넷 CIDR이 너무 작으면 결국 전체 주소가 먼저 고갈됩니다).

예시(개념): aws-node에 Prefix Delegation 관련 env를 설정

kubectl -n kube-system set env ds/aws-node \
  ENABLE_PREFIX_DELEGATION=true \
  WARM_PREFIX_TARGET=1

(2) 서브넷 CIDR 확장/추가(주소계획)

VPC 전체 주소가 부족해지는 형태라면, CNI를 바꿔도 결국 한계가 오기 때문에 서브넷 CIDR 확장/추가가 더 정공법입니다.

(3) 노드 인스턴스 타입/노드 수 전략

인스턴스 타입별 ENI/IP 한도가 다르므로, IP 병목이 “노드 단위”라면 인스턴스 타입 변경/노드 확장이 가장 간단하게 풀릴 때가 많습니다.

(4) (가능하다면) IPv6/듀얼스택 검토

조직/서비스 제약이 허용한다면 IPv6는 주소 고갈 문제를 구조적으로 완화할 수 있습니다(다만 생태계/연동 요구사항 검토가 필요).

6) 재현 가능한 체크리스트(공통)

(1) 클러스터 애드온 상태 확인

kubectl get ds -n kube-system
kubectl get pods -n kube-system

(2) API Server Host/Port 확인 (블로그 공통 흐름)

kubectl cluster-info

ENI 모드 블로그는 k8sServiceHost에 넣을 때 https://를 제거하라고 명시합니다.

(3) 설치 검증

cilium status --wait
cilium connectivity test

(4) 체이닝 모드라면 “기존 Pod 재시작”을 계획에 포함

공식 문서에 따르면, 체이닝 구성은 이미 떠있는 Pod에 자동 적용되지 않습니다. 유지보수 윈도우(롤링 재시작 계획)를 반드시 포함하세요.

마무리

세 가지 문서는 사실상 같은 주제를 다른 “깊이”로 다룹니다.

• 블로그 2개는 “EKS 설치를 실제로 끝내는 절차” 중심(시리즈)
• 공식 문서는 “체이닝 모드의 운영 제약/검증 포인트” 중심(레퍼런스)

정리하면 성능/단순성/정석을 원하면 ENI, 점진 도입이면 chaining, ENI IP 한계 회피가 목적이면 overlay(BYOCNI)입니다. 다만 어떤 선택이든, “클러스터 생성 단계의 애드온 상태(aws-node/kube-proxy)”와 “Pod 재시작/검증 루틴”을 계획에 넣는 것이 운영 성공률을 크게 올립니다.