이 글에서는 Cilium의 개념과 아키텍처, 그리고 eBPF 기반 네트워킹이 제공하는 주요 장점에 대해 알아보겠습니다. 특히 MinIO와 같은 스토리지 서비스를 운영할 때 Cilium이 어떤 이점을 제공하는지 자세히 설명하겠습니다.
📌 Cilium 소개
✅ Cilium이란 무엇인가?
Cilium은 Linux 커널의 eBPF 기술을 활용하는 오픈소스 소프트웨어 정의 네트워킹 솔루션으로, 쿠버네티스 환경에서 CNI(Container Network Interface)로 작동합니다.
▶️ Cilium의 핵심 특징:
- eBPF 기반의 데이터 플레인 구현
- L3-L7 계층에서의 네트워크 보안 정책 지원
- 높은 성능과 낮은 리소스 사용량
- 애플리케이션 프로토콜 인식 기능
- 풍부한 모니터링 및 트러블슈팅 기능
✅ 일반 CNI와 Cilium의 차이점
일반적인 CNI 플러그인과 Cilium의 주요 차이점을 비교해 봅시다.
특성 | 일반 CNI (Flannel, Calico 등) | Cilium |
기술 기반 | iptables, IPVS | eBPF |
성능 | 규칙 수에 따라 성능 저하 | 규모 확장에도 일정한 성능 |
보안 정책 | L3/L4 수준 지원 | L3-L7 수준 정밀 제어 |
프로토콜 인식 | 제한적 | HTTP, gRPC, Kafka 등 지원 |
모니터링 | 기본적 수준 | 상세한 네트워크 흐름 추적 |
자원 사용 | 규칙 증가에 따라 증가 | 최적화된 자원 사용 |
📌 eBPF의 이해
✅ eBPF란 무엇인가?
eBPF(Extended Berkeley Packet Filter)는 리눅스 커널에서 안전하게 프로그래밍 가능한 샌드박스 환경을 제공하는 기술입니다.
▶️ eBPF의 주요 특징:
- 커널 공간에서 안전하게 사용자 정의 프로그램 실행
- 커널 수정 없이 커널 동작 확장 가능
- JIT(Just-In-Time) 컴파일러를 통한 높은 성능
- 다양한 이벤트에 연결 가능 (네트워크 패킷, 시스템 콜 등)
- 커널 업그레이드 없이 기능 확장 가능
✅ eBPF의 작동 방식
eBPF가 어떻게 작동하는지 간략히 살펴봅시다.
- eBPF 프로그램 작성 (C 또는 Rust로 작성)
- LLVM 컴파일러가 eBPF 바이트코드로 변환
- 검증기(Verifier)가 안전성 검사
- JIT 컴파일러가 네이티브 머신 코드로 변환
- 커널 내부에서 특정 이벤트 발생 시 실행
사용자 공간 커널 공간
+-------------+ +------------------+
| eBPF 프로그램 | --- 로드 ---> | 안전성 검증기 |
| (C/Rust) | +------------------+
+-------------+ |
^ v
| +------------------+
| | JIT 컴파일러 |
| +------------------+
| |
| v
| +------------------+
| | eBPF 맵 |
| +------------------+
| |
+-------------+ |
| 사용자 도구 | <-- 데이터 교환 ------ |
+-------------+
📌 Cilium 아키텍처
✅ Cilium의 구성 요소
Cilium의 주요 구성 요소와 아키텍처를 살펴봅시다.
▶️ 주요 구성 요소:
- Cilium Agent: 각 노드에서 실행되는 데몬으로 eBPF 프로그램 관리
- Cilium Operator: 클러스터 수준의 리소스 관리 담당
- eBPF 프로그램: 데이터 경로 처리를 위한 커널 내 프로그램
- Hubble: 네트워크 흐름 관찰을 위한 관찰성 도구
- CNI 플러그인: 쿠버네티스와의 통합을 위한 인터페이스
apiVersion: apps/v1 # 쿠버네티스 앱 API 그룹 버전
kind: DaemonSet # 각 노드에 하나씩 실행되는 DaemonSet 유형
metadata:
name: cilium # DaemonSet 이름
namespace: kube-system # 시스템 네임스페이스에 배포
spec:
selector:
matchLabels:
k8s-app: cilium # Pod 선택자
template:
metadata:
labels:
k8s-app: cilium # Pod 라벨
spec:
containers:
- name: cilium-agent # Cilium 에이전트 컨테이너
image: quay.io/cilium/cilium:v1.13.4 # Cilium 이미지
command: ["cilium-agent"] # 실행 명령어
args: # 에이전트 설정 인자
- "--config-dir=/tmp/cilium/config-map"
- "--debug=$(CILIUM_DEBUG)"
securityContext: # 보안 컨텍스트
privileged: true # 특권 모드 필요 (eBPF 사용을 위함)
volumeMounts: # 볼륨 마운트
- name: bpf-maps # BPF 맵을 위한 볼륨
mountPath: /sys/fs/bpf # BPF 파일시스템 마운트 경로
mountPropagation: Bidirectional # 양방향 마운트 전파
volumes: # 볼륨 정의
- name: bpf-maps # BPF 맵 볼륨
hostPath: # 호스트 경로 볼륨
path: /sys/fs/bpf # BPF 파일시스템 경로
type: DirectoryOrCreate # 없으면 생성
✅ Cilium의 네트워킹 모델
Cilium이 컨테이너 간 통신을 처리하는 방식을 알아봅시다.
▶️ Cilium 네트워킹 모델 특징:
- ID 기반 보안 모델: IP 주소 대신 서비스 ID 기반 정책
- 오버레이 또는 직접 라우팅: VXLAN/Geneve 또는 BGP 기반 직접 라우팅
- 커넥션 추적: 스테이트풀 연결 관리
- L7 프록시: HTTP, gRPC 등 애플리케이션 프로토콜 인식
- NAT 및 로드 밸런싱: 효율적인 네트워크 주소 변환 및 부하 분산
+-------------+ +-------------+
| 컨테이너 A | | 컨테이너 B |
+-------------+ +-------------+
| |
v v
+-------------+ +-------------+
| 가상 이더넷 | | 가상 이더넷 |
+-------------+ +-------------+
| |
v v
+--------------------------------------------------+
| eBPF |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| 물리 네트워크 인터페이스 |
+--------------------------------------------------+
📌 Cilium의 핵심 기능
✅ 고성능 데이터 경로
Cilium의 eBPF 기반 데이터 경로는 기존 iptables 기반 솔루션보다 높은 성능을 제공합니다.
▶️ 성능 향상 요소:
- 커널 내 프로세싱: 패킷이 커널 공간에서 직접 처리
- Tail Call 최적화: 연속된 eBPF 프로그램 호출 최적화
- 프로그램 가능한 패킷 처리: 필요한 처리만 수행
- 오버헤드 감소: iptables 규칙 조회 오버헤드 제거
- 패킷 처리 병렬화: 멀티코어 효율적 활용
✅ 세밀한 네트워크 정책
Cilium은 L3부터 L7까지 다양한 수준의 네트워크 정책을 지원합니다.
▶️ 다양한 네트워크 정책 예시:
- L3/L4 정책 (IP 주소 및 포트):
apiVersion: "cilium.io/v2" # Cilium API 그룹 버전
kind: CiliumNetworkPolicy # Cilium 네트워크 정책 리소스
metadata:
name: "minio-l3-l4-policy" # 정책 이름
namespace: minio-system # 정책이 적용될 네임스페이스
spec:
endpointSelector: # 정책 적용 대상
matchLabels:
app: minio # MinIO Pod 라벨
ingress: # 인바운드 규칙
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 기준 매칭
app: frontend # 프론트엔드 앱에서의 접근 허용
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
- L7 HTTP 정책 (API 경로 기반):
apiVersion: "cilium.io/v2" # Cilium API 그룹 버전
kind: CiliumNetworkPolicy # Cilium 네트워크 정책 리소스
metadata:
name: "minio-l7-policy" # 정책 이름
namespace: minio-system # 네임스페이스
spec:
endpointSelector: # 정책 적용 대상
matchLabels:
app: minio # MinIO Pod 라벨
ingress: # 인바운드 규칙
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 기준 매칭
app: api-client # API 클라이언트 앱
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
rules: # L7 규칙
http: # HTTP 프로토콜 규칙
- method: "GET" # HTTP GET 메서드만 허용
path: "/mybucket/public/.*" # 특정 경로 패턴만 허용
✅ Kube-Proxy 대체
Cilium은 쿠버네티스의 kube-proxy 컴포넌트를 완전히 대체할 수 있습니다.
▶️ Kube-Proxy 대체 장점:
- 성능 향상: eBPF 기반 구현으로 지연 시간 감소
- 리소스 절약: 추가 컴포넌트 제거로 리소스 효율성 증가
- 세션 어피니티: 더 효율적인 세션 어피니티 구현
- 소스 IP 보존: 원본 소스 IP 보존 개선
- 외부 트래픽 정책: 더 효율적인 외부 트래픽 정책 지원
# Helm 차트 설치 시 kubeProxyReplacement 활성화
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=strict \ # kube-proxy 완전 대체
--set k8sServiceHost=API_SERVER_IP \ # API 서버 IP
--set k8sServicePort=API_SERVER_PORT # API 서버 포트
✅ 클러스터 메시
Cilium은 여러 쿠버네티스 클러스터를 연결하는 ClusterMesh 기능을 제공합니다.
▶️ ClusterMesh 주요 기능:
- 멀티 클러스터 연결: 여러 클러스터 간 직접 연결
- 글로벌 서비스: 여러 클러스터에 걸친 서비스 정의
- 정책 공유: 클러스터 간 네트워크 정책 공유
- 장애 조치: 클러스터 장애 시 자동 장애 조치
- 분산 배포: 지리적으로 분산된 클러스터 지원
📌 Hubble: Cilium의 관찰성 도구
✅ Hubble 소개
Hubble은 Cilium의 네트워크 흐름 관찰을 위한 도구로, 네트워크 트래픽에 대한 강력한 가시성을 제공합니다.
▶️ Hubble의 주요 기능:
- 실시간 네트워크 흐름 모니터링
- 서비스 의존성 매핑
- 네트워크 정책 디버깅
- 보안 관찰 및 감사
- 성능 병목 현상 식별
# Hubble 활성화 (Cilium CLI 사용)
cilium hubble enable --ui
# Hubble UI 접근
cilium hubble ui
✅ Hubble UI
Hubble UI는 네트워크 흐름을 시각적으로 보여주는 웹 인터페이스입니다.
▶️ Hubble UI 주요 기능:
- 서비스 맵: 서비스 간 통신 시각화
- 플로우 뷰어: 개별 네트워크 흐름 검사
- 필터링: 특정 조건에 맞는 흐름 필터링
- 메트릭: 네트워크 성능 메트릭 제공
- 정책 분석: 정책 적용 결과 확인
# Hubble UI를 위한 ServiceAccount
apiVersion: v1 # 쿠버네티스 API 버전
kind: ServiceAccount # 리소스 종류
metadata:
name: hubble-ui # ServiceAccount 이름
namespace: kube-system # 네임스페이스
# Hubble UI Deployment
apiVersion: apps/v1 # 앱 API 그룹
kind: Deployment # 리소스 종류
metadata:
name: hubble-ui # Deployment 이름
namespace: kube-system # 네임스페이스
spec:
replicas: 1 # 복제본 수
selector:
matchLabels:
k8s-app: hubble-ui # Pod 선택자
template:
metadata:
labels:
k8s-app: hubble-ui # Pod 라벨
spec:
serviceAccountName: hubble-ui # 사용할 ServiceAccount
containers:
- name: hubble-ui # 컨테이너 이름
image: quay.io/cilium/hubble-ui:v0.12.0 # Hubble UI 이미지
ports:
- containerPort: 8081 # 컨테이너 포트
name: http # 포트 이름
# Hubble UI Service
apiVersion: v1 # 쿠버네티스 API 버전
kind: Service # 리소스 종류
metadata:
name: hubble-ui # Service 이름
namespace: kube-system # 네임스페이스
spec:
selector:
k8s-app: hubble-ui # Pod 선택자
ports:
- name: http # 포트 이름
port: 80 # Service 포트
targetPort: 8081 # 대상 Pod 포트
type: ClusterIP # Service 유형
📌 MinIO에서 Cilium 활용하기
✅ MinIO 네트워킹 요구사항
MinIO의 네트워킹 요구사항과 Cilium이 어떻게 이를 충족시킬 수 있는지 알아봅시다.
▶️ MinIO 네트워킹 요구사항:
- 안정적인 데이터 통신: 분산 MinIO 인스턴스 간 안정적 통신
- 보안: 인가된 클라이언트만 접근 가능
- 성능: 대용량 데이터 전송에 최적화된 성능
- 모니터링: 네트워크 문제 조기 탐지
- 확장성: 수요 증가에 따른 확장 지원
✅ MinIO를 위한 Cilium 네트워크 정책
MinIO 워크로드를 보호하기 위한 Cilium 네트워크 정책의 예시입니다.
apiVersion: "cilium.io/v2" # Cilium API 그룹 버전
kind: CiliumNetworkPolicy # Cilium 네트워크 정책 리소스
metadata:
name: "minio-security-policy" # 정책 이름
namespace: minio-system # 네임스페이스
spec:
endpointSelector: # 정책 적용 대상
matchLabels:
app: minio # MinIO Pod 선택
ingress: # 인바운드 규칙
# API 서비스 접근
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 매칭
app: api-service # API 서비스 앱
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
# 내부 API 생성 서비스 접근
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 매칭
app: content-generator # 컨텐츠 생성기 앱
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
rules: # L7 규칙
http: # HTTP 프로토콜 규칙
- method: "PUT" # HTTP PUT 메서드만 허용
path: "/content-bucket/.*" # 특정 버킷 경로만 허용
# 콘솔 UI 접근
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 매칭
app: admin-client # 관리자 클라이언트 앱
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9001" # MinIO 콘솔 포트
protocol: TCP # TCP 프로토콜
# 분산 설정에서 MinIO 노드 간 통신
- fromEndpoints: # 소스 엔드포인트
- matchLabels: # 라벨 매칭
app: minio # 다른 MinIO Pod와의 통신
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
egress: # 아웃바운드 규칙
# DNS 요청 허용
- toEndpoints: # 목적지 엔드포인트
- matchLabels: # 라벨 매칭
k8s:app: kube-dns # 쿠버네티스 DNS
toPorts: # 대상 포트
- ports: # 포트 목록
- port: "53" # DNS 포트
protocol: UDP # UDP 프로토콜
✅ Cilium을 활용한 MinIO 성능 최적화
Cilium을 사용하여 MinIO의 네트워크 성능을 최적화하는 방법입니다.
▶️ 성능 최적화 방법:
- 직접 라우팅 사용: 가능한 경우 오버레이 네트워크 대신 직접 라우팅 사용
- eBPF 기반 로드 밸런싱: 효율적인 클라이언트 트래픽 분산
- 대규모 연결 최적화: eBPF 소켓 처리로 연결 오버헤드 감소
- 네트워크 정책 최적화: 필요한 정책만 선택적으로 적용
- TCP BBR 활성화: 대역폭 활용 최적화
# Cilium 직접 라우팅 설정 (Helm 값)
tunnel: disabled # 오버레이 터널링 비활성화
autoDirectNodeRoutes: true # 직접 노드 라우팅 활성화
ipv4NativeRoutingCIDR: 10.0.0.0/8 # 라우팅 CIDR
bpf:
hostRouting: true # eBPF 호스트 라우팅 활성화
tcpKeepAlive: true # TCP 연결 유지 활성화
sockops: true # 소켓 작업 최적화 활성화
📌 Cilium 운영 고려사항
✅ 성능 모니터링
Cilium 성능을 모니터링하기 위한 주요 메트릭과 도구입니다.
▶️ 주요 모니터링 영역:
- eBPF 맵 사용량: 메모리 리소스 사용 추적
- 네트워크 처리량: 초당 패킷/바이트 처리량
- 연결 추적 테이블: 연결 상태 모니터링
- 정책 업데이트 시간: 정책 변경 적용 소요 시간
- 패킷 드롭: 드롭된 패킷 수와 이유
# Cilium 에이전트 상태 확인
cilium status --verbose
# eBPF 맵 상태 확인
cilium bpf maps
# Cilium 엔드포인트 상태
cilium endpoint list
# 네트워크 정책 상태
cilium policy get
✅ 업그레이드 고려사항
Cilium을 안전하게 업그레이드하기 위한 고려사항입니다.
▶️ 업그레이드 모범 사례:
- 미리 릴리스 노트 확인: 호환성 및 주요 변경사항 파악
- 단계적 업그레이드: 중요 환경은 단계적으로 업그레이드
- 백업 활성화: 업그레이드 전 CRD 백업
- 롤백 계획 수립: 문제 발생 시 이전 버전으로 롤백 방법 마련
- 무중단 업그레이드 활용: Pod 중단 최소화
# CRD 백업
kubectl get crd -o yaml > cilium_crd_backup.yaml
# 단계적 업그레이드 (Helm 사용)
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--version 1.13.4
📌 Summary
- Cilium은 eBPF 기술 기반의 고성능 쿠버네티스 CNI 솔루션
- eBPF를 통해 커널 수준에서의 프로그래밍 가능한 네트워킹 제공
- L3부터 L7까지 세밀한 네트워크 정책으로 MinIO 보안 강화 가능
- Kube-Proxy 대체로 성능 향상 및 리소스 사용량 감소
- Hubble을 통한 네트워크 가시성 제공으로 트러블슈팅 용이
- MinIO와 같은 데이터 집약적 서비스에 최적화된 네트워크 성능 제공
- eBPF 기반 최적화로 대용량 데이터 전송 효율 향상
- 분산 MinIO 환경에서 안정적인 노드 간 통신 보장