Search

docs-001

Tag
Documents

1. 개요

본 문서는 Chaos Mesh 기반 장애 실험을 수행하기 위해, kubeadm 기반으로 Kubernetes 클러스터를 직접 구축/운영하는 과정에서 적합한 Container Network Interface(CNI) 플러그인을 선택하기 위한 기술 검토 문서입니다.
•
실험 도구: Chaos Mesh
•
실험 워크로드: podinfo
•
클러스터 성격: 소규모(학습/운영 겸용) + 재현 가능한 장애 실험 환경

2. CNI (Container Network Interface) 개요

2.1 정의

CNI(Container Network Interface)는 컨테이너 런타임과 네트워크 플러그인 간의 인터페이스를 표준화하는 사양이다. Pod가 생성될 때 CNI 플러그인이 호출되어 해당 Pod에 IP 주소를 할당하고, 네트워크 인터페이스를 연결하며, 다른 Pod와 통신할 수 있도록 라우팅 규칙을 설정한다. 즉, CNI는 Kubernetes에서 Pod 간 네트워크가 가능하도록 만드는 실질적인 실행 주체이다. Kubernetes는 네트워크 구현을 CNI에 위임하기 때문에, 클러스터 구성에 반드시 CNI 플러그인을 필요로 한다.

2.2 Kubernetes 네트워크 모델 요구사항

Kubernetes는 네트워크 모델에 대해 다음 네 가지 기본 규칙을 요구하며, 선택하는 CNI는 이를 반드시 만족해야 한다.
1.
모든 Pod는 NAT 없이 다른 모든 Pod와 통신 가능해야 한다.
2.
모든 Node는 NAT 없이 모든 Pod와 통신 가능해야 한다.
3.
Pod가 자신을 인식하는 IP와 외부에서 인식하는 IP가 동일해야 한다.
4.
Pod 내부의 컨테이너는 동일한 네트워크 네임스페이스(IP, MAC)를 공유한다.

3. 후보 CNI 플러그인

3.1 Calico

Tigera에서 개발 및 관리하는 Calico는 대규모 프로덕션 환경에서 널리 사용되는 CNI 중 하나이다. 네트워킹·보안·가시성 요구사항을 단일 플랫폼으로 해결하며, 일관된 네트워킹/보안 제어를 제공하여 워크로드 이식성을 보장한다.
•
Dataplane: iptables, eBPF(옵션)
•
NetworkPolicy: Kubernetes 기본 정책 + Calico 확장 정책 (L3/L4)
•
라우팅: BGP, VXLAN, IP-in-IP
•
IPAM: 자체 IPAM 내장

3.2 Cilium

Cilium은 Linux 컨테이너 관리 플랫폼에서 배포된 애플리케이션 서비스 사이의 네트워크 연결을 투명하게(transparent) 보호하기 위한 CNI이다. Linux eBPF 기술을 핵심으로 사용하며, 커널 수준에서 패킷을 처리하여 iptables 의존도를 줄이고 심층 가시성 및 고성능을 제공한다.
•
Dataplane: eBPF 기반
•
NetworkPolicy: L3/L4/L7(HTTP, gRPC) 정책
•
가시성: Hubble 기반 네트워크 흐름 관찰(Flow visibility)
•
IPAM: 자체 IPAM, 일부 환경 통합 지원

3.3 Flannel

경량 CNI로 단순한 L3 네트워크 구성에 초점을 둔다. 설정이 간단하고 리소스 소모가 적어 소규모/학습 환경에 적합하다.
•
Dataplane: VXLAN(기본), host-gw, UDP 등 Backend 선택 가능
•
NetworkPolicy: 미지원(별도 플러그인 필요)
•
라우팅: 단순 오버레이 네트워크
•
IPAM: etcd 또는 Kubernetes API 기반

3.4 Antrea

OVS(Open vSwitch) 기반 CNI이다. eBPF와 OVS 모두를 지원하며 Kubernetes-native 설계를 지향한다.
•
Dataplane: OVS, eBPF(선택적)
•
NetworkPolicy: Kubernetes 정책 + Antrea 확장 정책
•
Windows Node 지원

4. CNI 플러그인 비교

4.1 핵심 기능 비교

항목
Calico
Cilium
Flannel
Antrea
Dataplane
iptables / eBPF
eBPF
iptables / VXLAN
OVS / eBPF
NetworkPolicy
L3/L4 확장
L3/L4/L7
미지원
확장 지원
라우팅 방식
BGP / VXLAN
VXLAN / BGP
VXLAN / host-gw
Geneve / VXLAN
자체 IPAM
(간단)
커널 요구사항
낮음
높음 (5.4+)
낮음
중간
흐름 추적
 Hubble
부분
Prometheus 통합
설치 복잡도
중간
중간~높음
낮음
중간
커뮤니티 성숙도
매우 높음
높음
높음
중간

4.2 사용 시나리오별 적합성

시나리오
추천 CNI
이유
Chaos Mesh 실험(네트워크 장애) + 원인 관측/디버깅
Cilium
eBPF 기반 관측(Hubble)로 장애 전/후 트래픽 흐름을 추적하기 쉬움
정책 기반 격리/차단(NetworkPolicy) 실험까지 포함
Cilium 또는 Calico
NetworkPolicy 지원(확장 정책 포함)으로 시나리오 설계가 용이
가장 단순하게 빠른 구축(네트워크만 최소 충족)
Flannel
설치/운영 부담이 낮음(단, 정책 실험은 별도 구성 필요)

5. CNI 선택 기준

5.1 체크리스트

평가 항목
내용
우선순위
가시성/디버깅 용이성
Chaos Mesh 실험 전/후 네트워크 흐름/드랍/정책 적용 여부를 빠르게 확인할 수 있는가
높음
NetworkPolicy 필요 여부
격리/차단/허용을 “정책”으로 재현 가능해야 하는가
높음
커널 버전/호환성
실습 VM/베어메탈 커널이 요구사항(eBPF 등)을 충족하는가
중간~높음
운영 복잡도 허용 수준
운영 리소스/학습 시간 대비 복잡도가 과도하지 않은가
중간
커뮤니티/문서 성숙도
트러블슈팅/레퍼런스의 양과 질이 충분한가
중간
클러스터 규모
100+ 노드 등 대규모 라우팅 요구가 있는가(본 프로젝트는 낮음)
낮음

5.2 평가 방법

•
1차 목표: 기본 네트워크 안정성 + NetworkPolicy + 관측 확보
•
PoC(간단 검증) 항목
◦
Baseline: Pod-to-Pod / Service 통신 확인
◦
Chaos: NetworkChaos(지연/손실) 적용 후 증상 재현
◦
Observability: 장애 전/후 트래픽 흐름 확인 가능 여부(원인 설명 가능성)

6. 최종 선정

선정 CNI: Cilium

본 프로젝트는 “클러스터 직접 구축” 자체가 목적이 아니라, Chaos Mesh로 장애를 주입하고 그 영향을 관측/분석하는 것이 핵심이다. 따라서 CNI 선택에서 가장 중요한 요소를 가시성/디버깅 능력으로 두며, 이 기준에 따라 Cilium을 CNI로 선정한다.

선정 근거 1 — Chaos Mesh와의 레이어 분리

Chaos Mesh의 NetworkChaos는 traffic control(tc)과 iptables를 통해 패킷 지연/드랍을 주입한다. Calico(iptables)는 CNI 자신도 iptables를 사용하기 때문에 Chaos가 주입한 규칙과 CNI 규칙이 같은 레이어에서 혼재할 수 있다. 반면에 Cilium은 eBPF 기반으로 iptables와 독립된 레이어에서 동작하므로, 장애 주입 원인과 CNI 동작이 분리된다.
구분
Calico (iptables)
Cilium (eBPF)
Chaos 규칙 레이어
iptables
tc / eBPF
CNI 동작 레이어
iptables
eBPF
규칙 혼재 가능성
존재
없음

선정 근거 2 — Observability

Cilium + Hubble은 Prometheus 메트릭을 export하여 기존 Grafana 스택과 통합된다. Calico와 모니터링 도구 자체는 동일하나, 아래 메트릭이 추가로 제공되어 Chaos 실험 결과를 수치로 증명할 수 있다.
Hubble 메트릭
설명
Chaos 실험에서의 활용
hubble_drop_total
드랍된 패킷 수 (원인별: Policy, Invalid 등)
NetworkChaos 적용 전/후 드랍 수 비교
hubble_flows_processed_total
처리된 흐름 수 (방향/프로토콜별)
정상 트래픽 대비 장애 시 흐름 감소 측정
hubble_http_requests_total
HTTP 요청 수 (경로/상태코드별)
podinfo 엔드포인트 응답 코드 변화 추적
hubble_http_request_duration_seconds
HTTP 응답 지연 시간
NetworkChaos 지연 주입 효과 정량화

선정 근거 3 — L7 NetworkPolicy 지원

Cilium은 HTTP 경로/메서드 수준의 NetworkPolicy를 지원한다. Calico는 L4(IP/Port)까지만 지원하기 때문에 podinfo의 HTTP 엔드포인트를 대상으로 세밀한 격리 테스트를 설계할 때 Cilium이 더 넓은 시나리오를 커버한다.
정책 수준
Calico
Cilium
예시
L3 (IP)
특정 IP 대역 차단
L4 (Port)
포트 8080 차단
L7 (HTTP 경로)
GET /healthz 허용, POST /api 차단
L7 (HTTP 메서드)
GET만 허용, 나머지 차단

7. 참고 문서