Cilium 2.0 — Service Mesh + Network Policy + Cluster Mesh 통합

핵심 요약

Cilium은 단순 CNI에서 시작해 2.0 시점에 eBPF로 모든 네트워크·보안·관측성을 통합한 플랫폼이 됐다. Calico·Istio·Hubble 각각 하던 일을 단일 도구로.

• Cilium 2.0 (2026-03)
• L3-L7 Network Policy
• Service Mesh (sidecar 없음)
• Cluster Mesh (다중 클러스터)
• Hubble (관측성)

1. eBPF가 게임 체인저인 이유

전통 Service Mesh는 sidecar(envoy proxy)를 Pod마다. 트래픽이 application → sidecar → kernel → network로 흐름. Cilium은 eBPF로 kernel 안에서 바로 처리.

2. 설치

# Helm으로 (가장 흔함)
helm install cilium cilium/cilium \
  --version 2.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set serviceMesh.enabled=true

3. Network Policy — L3-L7

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"
        - method: "POST"
          path: "/api/v1/users"

HTTP method·path까지 정책으로. Calico·Cilium 1.x 모두 못 했던 L7.

4. Service Mesh — 사이드카 없이

apiVersion: cilium.io/v2
kind: CiliumEnvoyConfig
metadata:
  name: api-mesh
spec:
  services:
    - name: api
      namespace: production
  resources:
    - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
      # mTLS, retries, circuit breaker 등 envoy spec 그대로

Envoy 기능 그대로 + sidecar 안 띄움. waypoint도 선택적.

5. mTLS

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: mtls-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    authentication:
      mode: required

모든 통신 자동 mTLS 암호화·인증.

6. Cluster Mesh — 다중 클러스터

# 클러스터 1, 2를 mesh로 연결
cilium clustermesh enable --context cluster1
cilium clustermesh enable --context cluster2
cilium clustermesh connect --context cluster1 --destination-context cluster2

# Service를 클러스터 간 자동 동기화
kubectl annotate service api io.cilium/global-service="true"

다른 클러스터의 서비스가 로컬 서비스처럼 보임. 자동 failover·load balancing.

7. Hubble — 관측성

# 실시간 트래픽 관찰
hubble observe --pod api-server --since 1m

# Service Map
hubble observe --output json | hubble ui

# 정책 위반 추적
hubble observe --verdict DROPPED

Wireshark급 패킷 분석을 클러스터 단위로. Service Map 자동 생성.

8. eBPF 기반 부하 분산

# kube-proxy 대체
kubeProxyReplacement: true

# 결과:
# - kube-proxy iptables 사라짐
# - eBPF가 service traffic 직접 라우팅
# - 1만+ Service에서도 iptables처럼 느려지지 않음

9. 실측 — 대규모 클러스터

10. 마이그레이션 — Calico → Cilium

1. 스테이징에 Cilium 설치, kube-proxy mode 유지
2. NetworkPolicy 패턴 변환 (Calico → CiliumNetworkPolicy)
3. kubeProxyReplacement 활성화 — kube-proxy 제거
4. Hubble 활성화로 관측성 검증
5. 운영 클러스터 단계적 적용 (드라이 런 모드 활용)

11. 한계

• 커널 5.10+ 필수
• 일부 클라우드 (AKS Windows 노드) 제약
• L7 정책 표현력은 Istio보다 약간 낮음 (특수 케이스)
• 네트워크 디버깅 학습 곡선 가파름 (eBPF 이해 필요)

도입 결정 매트릭스

자주 묻는 질문

Cilium 도입 부담?새 클러스터는 매우 간단. 기존 Calico 마이그레이션은 1~2주 (정책 변환).

Istio Ambient vs Cilium?Cilium이 성능 우위, Istio가 표현력 우위. 대부분은 Cilium이 충분.

Windows 노드?제한적. Cilium 2.0이 Windows 지원 확대했지만 Linux만큼은 아님.