LabHub

블로그

Cilium Service Mesh: eBPF 기반 사이드카 없는 서비스 메시 구축과 운영 가이드

2026-03-07 · 23 분 읽기 · #kubernetes#cilium#service-mesh#ebpf#sidecarless#envoy#2026-03

한국어English日本語

Cilium Service Mesh eBPF

들어가며

서비스 메시(Service Mesh)는 마이크로서비스 간 통신을 안전하고 관찰 가능하게 만드는 인프라 계층입니다. Istio, Linkerd 등 기존 서비스 메시 솔루션은 각 Pod에 사이드카 프록시를 주입하는 방식을 사용합니다. 이 접근법은 동작하지만, 사이드카마다 별도의 CPU와 메모리를 소비하고, Pod 시작 시간이 늘어나며, 네트워크 홉이 추가되어 지연 시간이 증가하는 문제가 있습니다.

Cilium Service Mesh는 이 패러다임을 근본적으로 바꿉니다. eBPF를 활용하여 커널 수준에서 L4 트래픽을 처리하고, L7 기능이 필요한 경우에만 노드당 공유 Envoy 프록시를 사용합니다. 사이드카가 없으므로 리소스 오버헤드가 크게 줄어들고, Pod별 프록시 관리의 복잡성이 사라집니다.

이 글에서는 Cilium Service Mesh의 아키텍처 원리부터 설치, mTLS 설정, 트래픽 관리, 성능 비교, 그리고 프로덕션에서 겪을 수 있는 장애 사례와 복구 절차까지 종합적으로 다룹니다.

아키텍처와 핵심 개념

기존 사이드카 모델의 한계

전통적인 서비스 메시에서는 모든 Pod에 Envoy 사이드카가 주입됩니다. 100개의 Pod가 있으면 100개의 Envoy 인스턴스가 추가로 실행됩니다.

사이드카 모델의 비용:

Cilium Service Mesh의 사이드카리스 아키텍처

Cilium Service Mesh는 두 계층으로 서비스 메시 기능을 구현합니다.

L4 계층 (eBPF): TCP 연결 관리, 로드밸런싱, mTLS 암호화/복호화, 네트워크 정책 적용 등을 커널 내 eBPF 프로그램으로 처리합니다. 사이드카 없이 커널에서 직접 동작하므로 오버헤드가 극히 작습니다.

L7 계층 (공유 Envoy): HTTP 라우팅, 헤더 기반 트래픽 분할, gRPC 필터링 등 L7 기능이 필요한 경우에만 노드당 하나의 공유 Envoy 프록시(DaemonSet)가 트래픽을 처리합니다. Pod별이 아닌 노드별이므로 Envoy 인스턴스 수가 대폭 줄어듭니다.

핵심 컴포넌트

설치 및 서비스 메시 활성화

사전 요구사항

# 커널 버전 확인 (5.10+ 필수, 6.1+ 권장)
uname -r

# eBPF 지원 확인
cat /boot/config-$(uname -r) | grep CONFIG_BPF
# CONFIG_BPF=y
# CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT=y

# Cilium CLI 설치
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --fail --remote-name-all \
  https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
sudo tar xzvf cilium-linux-amd64.tar.gz -C /usr/local/bin

Helm을 이용한 서비스 메시 설치

# Helm repo 추가
helm repo add cilium https://helm.cilium.io/
helm repo update

# Cilium Service Mesh 설치 (kube-proxy 대체 + 서비스 메시 활성화)
helm install cilium cilium/cilium --version 1.19.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost="API_SERVER_IP" \
  --set k8sServicePort=6443 \
  --set envoyConfig.enabled=true \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=shared \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set authentication.mutual.spire.enabled=true \
  --set authentication.mutual.spire.install.enabled=true

이 설정에서 핵심 파라미터를 설명합니다:

설치 확인

# Cilium 전체 상태 확인
cilium status --wait

# 예상 출력:
#     /¯¯\
#  /¯¯\__/¯¯\    Cilium:             OK
#  \__/¯¯\__/    Operator:           OK
#  /¯¯\__/¯¯\    Envoy DaemonSet:    OK
#  \__/¯¯\__/    Hubble Relay:       OK
#     \__/        ClusterMesh:        disabled
#                 SPIRE Server:       OK
#                 SPIRE Agent:        OK

# 서비스 메시 기능 확인
cilium config view | grep -E "envoy|mesh|mutual"

# 연결 테스트 (서비스 메시 포함)
cilium connectivity test

mTLS 설정: SPIRE 기반 상호 인증

mTLS가 필요한 이유

서비스 메시의 핵심 기능 중 하나는 서비스 간 통신의 상호 인증(mTLS)입니다. mTLS는 클라이언트와 서버 모두가 인증서를 제시하여 상호 신원을 확인합니다. 이를 통해 중간자 공격(MITM)을 방지하고, 네트워크 정책과 별개로 워크로드 신원(identity) 기반의 보안을 구현합니다.

Cilium은 SPIFFE/SPIRE 프레임워크를 사용하여 mTLS를 구현합니다. 각 워크로드에 SPIFFE ID가 자동 할당되며, 인증서 발급과 갱신이 투명하게 이루어집니다.

mTLS 인증 정책 적용

# mtls-authentication-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: require-mutual-auth
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: order-service
      authentication:
        mode: required # mTLS 인증 필수
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP

이 정책은 payment-service에 대한 인바운드 트래픽에 mTLS 인증을 필수로 요구합니다. order-service가 유효한 SPIFFE ID를 가지고 있지 않으면 연결이 거부됩니다.

클러스터 전역 mTLS 강제

# cluster-wide-mtls.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: enforce-mtls-cluster-wide
spec:
  endpointSelector:
    matchExpressions:
      - key: io.kubernetes.pod.namespace
        operator: NotIn
        values:
          - kube-system
  ingress:
    - fromEndpoints:
        - {}
      authentication:
        mode: required

주의사항: 클러스터 전역 mTLS를 활성화하기 전에 모든 워크로드가 SPIRE에 등록되어 있는지 확인해야 합니다. 미등록 워크로드는 즉시 통신이 차단됩니다. 반드시 스테이징 환경에서 먼저 테스트하고, 프로덕션에는 네임스페이스별로 단계적으로 적용하세요.

# SPIRE에 등록된 워크로드 확인
kubectl exec -n kube-system spire-server-0 -- \
  /opt/spire/bin/spire-server entry show

# mTLS 인증 상태 확인
cilium-dbg identity list | grep -i auth
hubble observe --namespace production --verdict DROPPED -o json | \
  jq 'select(.drop_reason_desc == "Authentication required")'

L4/L7 트래픽 관리

CiliumEnvoyConfig를 이용한 L7 라우팅

Cilium Service Mesh는 CiliumEnvoyConfig CRD를 통해 L7 트래픽 관리를 수행합니다. 이는 Istio의 VirtualService/DestinationRule과 유사한 역할을 합니다.

# l7-traffic-split.yaml
apiVersion: cilium.io/v2
kind: CiliumEnvoyConfig
metadata:
  name: api-traffic-split
  namespace: production
spec:
  services:
    - name: api-service
      namespace: production
  backendServices:
    - name: api-service-v1
      namespace: production
    - name: api-service-v2
      namespace: production
  resources:
    - '@type': type.googleapis.com/envoy.config.listener.v3.Listener
      name: api-listener
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: api-traffic
                route_config:
                  name: api-routes
                  virtual_hosts:
                    - name: api-host
                      domains: ['*']
                      routes:
                        - match:
                            prefix: '/'
                            headers:
                              - name: 'x-canary'
                                exact_match: 'true'
                          route:
                            cluster: 'production/api-service-v2'
                        - match:
                            prefix: '/'
                          route:
                            weighted_clusters:
                              clusters:
                                - name: 'production/api-service-v1'
                                  weight: 90
                                - name: 'production/api-service-v2'
                                  weight: 10
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      '@type': type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

이 설정은 두 가지 라우팅 규칙을 정의합니다:

L4 로드밸런싱 정책

L4 수준의 로드밸런싱은 eBPF에서 직접 처리되므로 Envoy를 거치지 않아 매우 효율적입니다.

# l4-lb-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-l4-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
            - port: '9090'
              protocol: TCP
  egress:
    - toEndpoints:
        - matchLabels:
            app: database
      toPorts:
        - ports:
            - port: '5432'
              protocol: TCP
    - toEndpoints:
        - matchLabels:
            app: cache
      toPorts:
        - ports:
            - port: '6379'
              protocol: TCP

L7 HTTP 정책과 Rate Limiting

# l7-rate-limiting.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-with-ratelimit
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: public-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: GET
                path: '/api/v1/products.*'
              - method: GET
                path: '/api/v1/categories.*'
              - method: POST
                path: '/api/v1/orders'
                headers:
                  - 'Content-Type: application/json'

성능 비교: Cilium vs Istio vs Linkerd

서비스 메시 선택 시 가장 중요한 판단 기준 중 하나가 성능입니다. 아래는 동일한 워크로드(gRPC 마이크로서비스, 100 RPS)에서 측정한 벤치마크 결과입니다.

항목Cilium Service MeshIstio (사이드카)Linkerd
아키텍처사이드카리스 (eBPF + 노드 Envoy)Pod별 사이드카 EnvoyPod별 사이드카 linkerd2-proxy
P50 지연 추가~0.1ms (L4), ~0.3ms (L7)~1.0ms~0.5ms
P99 지연 추가~0.3ms (L4), ~0.8ms (L7)~3.0ms~1.5ms
Pod당 메모리 오버헤드0MB (L4) / 노드당 ~150MB 공유~50-100MB~20-30MB
Pod당 CPU 오버헤드거의 없음 (L4)~10-50m~5-20m
Pod 시작 지연0초 (사이드카 없음)2-5초 (사이드카 주입)1-3초
mTLSSPIRE/WireGuard내장 (Citadel)내장 (자체 PKI)
L7 기능CiliumEnvoyConfigVirtualService/DestinationRuleHTTPRoute/ServiceProfile
관측성Hubble (내장)Kiali, Jaeger (별도)Linkerd Viz (내장)
Gateway API 지원네이티브네이티브네이티브
커뮤니티CNCF GraduatedCNCF GraduatedCNCF Graduated
학습 곡선중간 (eBPF 이해 필요)높음 (복잡한 CRD 체계)낮음

벤치마크 실행 방법

# fortio를 이용한 성능 측정
kubectl run fortio-client --rm -it --image=fortio/fortio -- \
  load -c 50 -qps 1000 -t 60s -json - \
  http://api-service.production:8080/api/v1/health

# 결과 분석 포인트:
# - P50, P90, P99 레이턴시
# - 최대 QPS (Queries Per Second)
# - 에러율
# - CPU/메모리 사용량 (kubectl top pods로 별도 측정)

# Hubble 메트릭으로 L7 지연 시간 확인
hubble observe --namespace production --protocol http -o json | \
  jq '.l7.latency_ns / 1000000'

핵심 포인트: Cilium Service Mesh는 L4 트래픽 처리 시 사이드카 모델 대비 3~10배 낮은 지연 시간을 보여줍니다. L7 기능을 사용해도 공유 Envoy 모델 덕분에 Pod당 메모리 오버헤드가 0이며, 노드당 하나의 Envoy만으로 해당 노드의 모든 L7 트래픽을 처리합니다.

트러블슈팅: 장애 사례와 복구

사례 1: mTLS 인증 실패로 서비스 간 통신 불가

증상: 특정 서비스가 갑자기 다른 서비스와 통신하지 못하고, Hubble에서 Authentication required 드롭이 관찰됨

# 인증 실패 트래픽 확인
hubble observe --namespace production --verdict DROPPED -o compact

# SPIRE 에이전트 상태 확인
kubectl get pods -n kube-system -l app=spire-agent
kubectl logs -n kube-system -l app=spire-agent --tail=50

# 특정 워크로드의 SVID(인증서) 상태 확인
kubectl exec -n kube-system spire-server-0 -- \
  /opt/spire/bin/spire-server entry show -selector k8s:ns:production

# Cilium 엔드포인트의 인증 상태 확인
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg endpoint list -o json | jq '.[].status.policy.realized.auth'

원인과 해결:

  1. SPIRE 에이전트 OOMKilled: SPIRE 에이전트의 메모리 limit을 높입니다. 대규모 클러스터에서는 512Mi 이상 권장
  2. 인증서 만료: SPIRE의 SVID TTL 기본값은 1시간입니다. SPIRE 서버가 다운되면 인증서가 갱신되지 않아 1시간 후 통신이 끊깁니다. SPIRE 서버의 고가용성을 반드시 확보하세요
  3. 잘못된 셀렉터: CiliumNetworkPolicy의 authentication.mode: required가 의도하지 않은 범위에 적용되었을 수 있습니다. 먼저 특정 네임스페이스만 대상으로 테스트하세요

사례 2: Envoy DaemonSet 장애로 L7 정책 동작 불능

증상: L7 HTTP 정책(경로/헤더 기반 필터링)이 동작하지 않고, L4 정책만 적용됨

# Envoy DaemonSet 상태 확인
kubectl get ds -n kube-system cilium-envoy
kubectl describe ds -n kube-system cilium-envoy

# 특정 노드의 Envoy 로그 확인
kubectl logs -n kube-system -l k8s-app=cilium-envoy --tail=100

# Cilium Agent와 Envoy 간 연결 확인
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg status --verbose | grep -A5 "Envoy"

# CiliumEnvoyConfig 상태 확인
kubectl get cec -n production -o yaml

원인과 해결:

  1. Envoy Pod 리소스 부족: 노드의 L7 트래픽이 많은 경우 Envoy 메모리가 부족해질 수 있습니다. Helm values에서 envoy.resources.limits.memory를 늘리세요
  2. 잘못된 CiliumEnvoyConfig: Envoy 설정 문법 오류 시 해당 리스너가 로드되지 않습니다. cilium-dbg envoy config 명령으로 실제 로드된 설정을 확인하세요
  3. Node Affinity 문제: 특정 노드에서만 Envoy가 스케줄되지 않는 경우 해당 노드의 L7 정책이 동작하지 않습니다

사례 3: 서비스 메시 업그레이드 후 연결 끊김

증상: Cilium 버전 업그레이드 후 일부 Pod 간 통신이 간헐적으로 실패

# Cilium Agent 롤링 재시작 상태 확인
kubectl rollout status ds/cilium -n kube-system

# eBPF 맵 동기화 상태 확인
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg bpf endpoint list

# 엔드포인트 복구 대기
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg endpoint list | grep -v ready

복구 절차:

  1. 먼저 Cilium Agent가 모든 노드에서 정상적으로 재시작되었는지 확인합니다
  2. eBPF 맵이 정상적으로 재로드되었는지 cilium-dbg bpf endpoint list로 확인합니다
  3. 문제가 지속되면 영향을 받는 Pod를 재시작하여 엔드포인트를 재등록합니다
  4. 최후의 수단으로 cilium-dbg endpoint regenerate --all을 실행하여 모든 엔드포인트의 eBPF 프로그램을 재생성합니다

주의: 업그레이드 시 반드시 helm diff upgrade로 변경사항을 사전 확인하고, 한 번에 한 마이너 버전씩 업그레이드하세요. Cilium 1.17에서 1.19로 건너뛰는 것은 지원되지 않습니다.

사례 4: Hubble 관측 데이터가 수집되지 않음

증상: hubble observe 명령이 빈 결과를 반환하거나 타임아웃

# Hubble Relay 상태 확인
kubectl get pods -n kube-system -l k8s-app=hubble-relay
kubectl logs -n kube-system -l k8s-app=hubble-relay --tail=50

# Hubble 연결 테스트
cilium hubble port-forward &
hubble status

# Cilium Agent의 Hubble 모니터링 상태
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg monitor --type drop --type trace

해결: Hubble Relay의 gRPC 연결이 끊어진 경우가 가장 흔합니다. kubectl rollout restart deployment hubble-relay -n kube-system으로 Relay를 재시작하세요.

운영 노트

Istio에서 Cilium Service Mesh로의 마이그레이션

기존 Istio 환경에서 Cilium Service Mesh로 마이그레이션하는 경우, 한 번에 전환하지 말고 단계적으로 진행해야 합니다.

1단계 - 공존 (2~4주): Cilium을 CNI로 설치하되 서비스 메시 기능은 비활성화합니다. Istio 사이드카가 계속 동작합니다.

2단계 - 네임스페이스별 전환: 비핵심 네임스페이스부터 Istio 사이드카 주입을 비활성화하고 Cilium의 mTLS와 L7 정책을 활성화합니다.

3단계 - 완전 전환: 모든 네임스페이스에서 Istio를 제거하고 Cilium Service Mesh로 전환합니다.

# 네임스페이스별 Istio 사이드카 주입 비활성화
kubectl label namespace staging istio-injection-
kubectl rollout restart deployment -n staging

# Cilium mTLS 정책 적용
kubectl apply -f cilium-mtls-policy-staging.yaml

# 전환 후 확인
hubble observe --namespace staging --protocol http

리소스 사이징 가이드라인

Cilium Agent (DaemonSet):

Envoy DaemonSet:

SPIRE Server:

모니터링 필수 메트릭

# Prometheus에서 수집해야 할 핵심 메트릭

# 1. Cilium Agent 상태
# cilium_agent_api_process_time_seconds - API 처리 시간
# cilium_agent_bootstrap_seconds - Agent 시작 시간
# cilium_bpf_map_ops_total - BPF 맵 작업 수

# 2. 서비스 메시 관련
# cilium_proxy_upstream_reply_seconds - L7 프록시 업스트림 응답 시간
# cilium_proxy_redirects - L7 프록시로 리다이렉트된 연결 수
# cilium_auth_map_entries - mTLS 인증 맵 엔트리 수

# 3. Hubble 관측성
# hubble_flows_processed_total - 처리된 흐름 수
# hubble_tcp_flags_total - TCP 플래그별 카운트

# Grafana 대시보드 임포트
# Cilium 공식 대시보드: https://grafana.com/grafana/dashboards/16611

운영 체크리스트

배포 전 체크리스트

업그레이드 체크리스트

장애 대응 체크리스트

참고자료

  1. Cilium 공식 문서 - Service Mesh
  2. Cilium 공식 문서 - Mutual Authentication (mTLS)
  3. Cilium GitHub - Service Mesh Examples
  4. Cilium 공식 문서 - CiliumEnvoyConfig
  5. SPIFFE/SPIRE 공식 문서
  6. Kubernetes 공식 문서 - Service Mesh Interface
  7. Isovalent - Cilium Service Mesh Performance Benchmark
  8. Cilium 공식 문서 - Hubble Observability

원문 보기: https://www.youngju.dev/blog/kubernetes/2026-03-07-kubernetes-cilium-service-mesh-ebpf-sidecarless

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다