728x90
이 글에서는 Cilium의 내부 아키텍처와 주요 구성요소들에 대해 자세히 알아보겠습니다. Cilium Agent, Hubble, Operator 등 핵심 컴포넌트들의 역할과 상호작용 방식을 이해하면 Cilium의 동작 원리를 더 명확하게 파악할 수 있습니다. 또한 데이터 플레인과 컨트롤 플레인의 차이점과 Cilium이 사용하는 다양한 CRD 리소스도 살펴보겠습니다.
📌 Cilium 아키텍처 개요
Cilium은 크게 컨트롤 플레인과 데이터 플레인으로 구성된 아키텍처를 가지고 있습니다. 각 구성요소들이 어떻게 상호작용하는지 전체적인 관점에서 살펴보겠습니다.
✅ Cilium의 주요 구성요소
Cilium의 전체 아키텍처를 이루는 주요 구성요소는 다음과 같습니다:
# Cilium 아키텍처 주요 구성요소
├── 컨트롤 플레인 (Control Plane)
│ ├── Cilium Agent - 각 노드에 배포되는 핵심 구성요소
│ ├── Cilium Operator - 클러스터 수준의 관리 담당
│ └── 외부 통합 요소 (etcd, Kubernetes API 등)
│
├── 데이터 플레인 (Data Plane)
│ ├── eBPF 프로그램 - 커널 내 실행되는 eBPF 코드
│ └── eBPF 맵 - 데이터 저장 및 공유
│
└── 모니터링 & 관찰성 (Monitoring & Observability)
├── Hubble - 네트워크 흐름 관찰 도구
├── Hubble Relay - 다중 노드 데이터 집계
└── Hubble UI - 시각화 인터페이스
# 이 구성요소들이 함께 작동하여
# 네트워킹, 로드 밸런싱, 보안 정책, 관찰성 등의 기능을 제공합니다.
# 각 구성요소의 상세 역할과 상호작용은 아래에서 자세히 설명합니다.
✅ 전체 아키텍처 동작 흐름
Cilium의 구성요소들이 어떻게 함께 작동하는지 기본적인 흐름을 살펴보겠습니다.
- 설정 및 정책 관리 흐름:
- 사용자가 Kubernetes API를 통해 정책, 서비스 등을 정의
- Cilium Operator가 클러스터 범위의 리소스 관리
- Cilium Agent가 각 노드에서 정책을 수신하고 eBPF 프로그램으로 변환
- eBPF 프로그램이 커널에 로드되어 정책 시행
- 패킷 처리 흐름:
- 패킷이 네트워크 인터페이스에 도착
- eBPF 프로그램이 패킷 처리 (필터링, 로드 밸런싱, 변환 등)
- 허용된 패킷만 대상 Pod로 전달
- 네트워크 흐름 정보가 Hubble에 수집
- 모니터링 흐름:
- Hubble이 eBPF 맵에서 네트워크 흐름 데이터 수집
- Hubble Relay가 여러 노드의 데이터 집계
- Hubble UI 또는 CLI를 통해 데이터 시각화 및 분석
📌 Cilium Agent 상세 분석
Cilium Agent는 각 Kubernetes 노드에서 실행되는 핵심 구성요소로, 데몬셋(DaemonSet)으로 배포됩니다. 노드 수준에서 Cilium의 모든 기능을 관리하고 구현합니다.
✅ Cilium Agent의 주요 책임
# Cilium Agent의 주요 책임 및 기능
1. eBPF 프로그램 관리
- 컴파일 및 커널 로드
- 업데이트 및 적용
- 모니터링 및 상태 확인
2. 네트워크 정책 관리
- Kubernetes NetworkPolicy 및 CiliumNetworkPolicy 해석
- 정책을 eBPF 프로그램 및 맵으로 변환
- 정책 충돌 해결 및 최적화
3. 엔드포인트 관리
- Pod 생성/삭제 감지
- 엔드포인트 생성 및 구성
- IP 주소 할당 및 관리
4. 서비스 디스커버리 및 로드 밸런싱
- Kubernetes Service 감지 및 처리
- eBPF 기반 로드 밸런싱 구현
- 서비스-엔드포인트 매핑 관리
5. 네트워크 연결 관리
- 노드 간 연결 설정
- 클러스터 외부 연결 관리
- 네트워크 인터페이스 설정
6. eBPF 맵 관리
- 맵 생성 및 초기화
- 맵 데이터 업데이트
- 효율적인 데이터 조회 지원
7. 모니터링 데이터 수집
- 네트워크 흐름 데이터 수집
- 성능 및 상태 메트릭 제공
- Hubble 통합 및 데이터 전달✅ Cilium Agent 내부 구조
Cilium Agent는 여러 내부 컴포넌트로 구성되어 있습니다. 주요 구성요소와 역할을 살펴보겠습니다.
// Cilium Agent 내부 구성요소 및 역할 (의사 코드)
type Agent struct {
// 엔드포인트 관리
EndpointManager *endpointmanager.EndpointManager
// 정책 저장소
PolicyRepository *policy.Repository
// 데몬 구성
Config *daemonConfig
// IP 주소 관리 (IPAM)
IPAM *ipam.IPAM
// 프록시 관리 (L7 정책용)
Proxy *proxy.Proxy
// eBPF 맵 매니저
BPFMapManager *maps.BPFMapManager
// DNS 정책 매니저
DNSManager *dns.Manager
// 상태 수집기
StatusCollector *status.Collector
// Kubernetes 통합 컴포넌트
K8sWatcher *watchers.K8sWatcher
// Hubble 통합 컴포넌트
Hubble *hubble.Server
// 기타 구성요소...
}
// 위 의사 코드는 Cilium Agent의 주요 내부 구성요소를 보여줍니다.
// 실제 구현은 더 복잡하지만, 이 모델을 통해 주요 컴포넌트를
// 이해할 수 있습니다.EndpointManager
- Pod와 1:1로 매핑되는 엔드포인트 관리
- 엔드포인트 상태 추적 및 생명주기 관리
- eBPF 프로그램과 엔드포인트 연결
PolicyRepository
- 모든 네트워크 정책 저장 및 관리
- 정책 충돌 해결 및 최적화
- 정책 변경 이벤트 처리
IPAM (IP Address Management)
- IP 주소 할당 및 관리
- 주소 풀 관리 및 중복 방지
- CNI와 연동한 IP 프로비저닝
K8sWatcher
- Kubernetes API 이벤트 감시
- 서비스, 엔드포인트, 정책 변경 감지
- 변경사항을 내부 컴포넌트에 전달
✅ Cilium Agent 초기화 및 시작 과정
Cilium Agent가 시작될 때 어떤 과정을 거치는지 살펴보겠습니다.
# Cilium Agent 시작 및 초기화 과정
# 1. 구성 로드 및 검증
$ cilium-agent --config-dir=/etc/cilium
# 2. 커널 eBPF 기능 확인
# - BTF 지원 확인
# - 필요한 eBPF helpers 및 maps 지원 확인
# - 커널 버전 호환성 검증
# 3. 내부 컴포넌트 초기화
# - IPAM 초기화
# - 정책 저장소 초기화
# - 엔드포인트 매니저 초기화
# - DNS 캐시 및 프록시 설정
# 4. 기존 엔드포인트 복원
# - 노드 재시작 시 기존 엔드포인트 상태 복원
# - eBPF 맵 데이터 복원
# 5. Kubernetes 연결 설정
# - kube-apiserver 연결
# - 리소스 워치 설정
# - 노드 정보 등록
# 6. eBPF 프로그램 컴파일 및 로드
# - 필요한 eBPF 프로그램 컴파일
# - 커널에 프로그램 로드
# - 프로그램과 맵 연결
# 7. CNI 플러그인 설정
# - Kubernetes CNI와 통합
# - CNI 구성 파일 생성
# 8. 상태 모니터링 시작
# - 주기적인 상태 확인
# - 메트릭 수집 시작
# - API 엔드포인트 활성화
# 위 과정이 모두 완료되면 Agent는 준비 상태가 되어
# 새 Pod 생성, 정책 변경 등의 이벤트를 처리할 수 있습니다.📌 Cilium Operator 이해하기
Cilium Operator는 클러스터 수준의 작업을 담당하는 중앙 관리 구성요소입니다. 개별 노드가 아닌 클러스터 전체에 관련된 작업을 처리합니다.
✅ Operator의 역할과 책임
# Cilium Operator 주요 역할 및 책임
clusterWideResponsibilities:
# 1. IP 주소 풀 관리
ipAddressManagement:
- CRD 기반 IPAM 풀 관리
- IP 할당 조정
- 주소 충돌 방지
# 2. 노드 관리
nodeManagement:
- 노드 검색 및 등록
- 노드 상태 모니터링
- 노드 메타데이터 관리
# 3. CRD 관리
crdManagement:
- CiliumNetworkPolicy 검증
- 클러스터 전체 정책 관리
- CRD 마이그레이션 및 업데이트
# 4. 서비스 동기화
serviceSynchronization:
- 외부 서비스 동기화
- 글로벌 서비스 관리
- 서비스 헬스체크
# 5. 클러스터 메시 관리
clusterMeshManagement:
- 멀티 클러스터 연결 설정
- 클러스터 간 정책 동기화
- 클러스터 간 서비스 검색
# 6. 리소스 관리
resourceManagement:
- 가비지 컬렉션
- 리소스 정리
- 고아 리소스 처리
# Cilium Operator는 이러한 클러스터 수준의 작업을 담당하여
# 개별 Agent들이 효율적으로 작동할 수 있는 환경을 제공합니다.✅ Operator와 Agent의 상호작용
Cilium Operator와 Agent는 서로 다른 수준에서 작동하지만, 원활한 시스템 운영을 위해 긴밀하게 협력합니다.
# Operator와 Agent 간 상호작용 흐름
Kubernetes API Server
↕
Operator
↙ ↘
Agent1 Agent2 ... AgentN
# 주요 상호작용 사례:
1. IP 주소 할당
Operator: IP 풀 관리 및 할당 정책 설정
Agent: Operator로부터 IP 블록 요청 및 개별 Pod에 IP 할당
2. 노드 검색 및 등록
Operator: 클러스터 내 모든 노드 검색 및 상태 추적
Agent: 자신의 노드 정보 등록 및 상태 보고
3. 정책 관리
Operator: 클러스터 전체 정책 유효성 검사 및 충돌 해결
Agent: 노드 관련 정책 적용 및 시행
4. 클러스터 메시
Operator: 클러스터 간 연결 설정 및 관리
Agent: 클러스터 메시 정보 기반 라우팅 처리
5. 가비지 컬렉션
Operator: 사용되지 않는 리소스 식별
Agent: Operator의 지시에 따라 로컬 리소스 정리
✅ Operator 배포 및 고가용성
Cilium Operator는 고가용성(HA) 모드로 배포할 수 있으며, 리더 선출 메커니즘을 통해 한 번에 하나의 인스턴스만 활성 상태로 작동합니다.
# Cilium Operator 배포 매니페스트 예시 (일부)
apiVersion: apps/v1
kind: Deployment
metadata:
name: cilium-operator
namespace: kube-system
spec:
# 고가용성을 위한 복제본 설정
replicas: 2
selector:
matchLabels:
io.cilium/app: operator
name: cilium-operator
template:
metadata:
labels:
io.cilium/app: operator
name: cilium-operator
spec:
containers:
- name: cilium-operator
image: quay.io/cilium/operator:v1.13.0
args:
# 리더 선출 활성화
- --enable-leader-election
# 기타 구성 옵션
- --kvstore=kubernetes
- --log-level=info
# 리소스 제한
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 100m
memory: 128Mi
# 상태 프로브
livenessProbe:
httpGet:
path: /healthz
port: 9234
initialDelaySeconds: 60
timeoutSeconds: 3
periodSeconds: 10
failureThreshold: 6
# 이 배포는 두 개의 Operator 인스턴스를 생성하지만,
# 리더 선출 메커니즘을 통해 한 번에 하나의 인스턴스만 활성화됩니다.
# 활성 인스턴스에 문제가 생기면 다른 인스턴스가 자동으로 인계받습니다.📌 데이터 플레인 심층 분석
Cilium의 데이터 플레인은 eBPF 프로그램과 맵으로 구성되며, 실제 패킷 처리와 정책 시행을 담당합니다.
✅ eBPF 프로그램 유형 및 역할
Cilium은 다양한 유형의 eBPF 프로그램을 사용하여 네트워크 기능을 구현합니다.
/* Cilium에서 사용하는 eBPF 프로그램 유형 예시 */
// 1. XDP (eXpress Data Path) 프로그램
// 패킷이 네트워크 드라이버에 도착 직후 처리
SEC("xdp")
int handle_xdp(struct xdp_md *ctx) {
// 패킷 처리 로직
// - 초기 필터링
// - DDoS 방어
// - 빠른 리다이렉션
return XDP_PASS; // 또는 XDP_DROP, XDP_TX 등
}
// 2. TC (Traffic Control) 프로그램
// 네트워크 스택의 인그레스/이그레스 지점에서 실행
SEC("tc")
int handle_tc_ingress(struct __sk_buff *ctx) {
// 패킷 처리 로직
// - L3/L4 정책 시행
// - 연결 추적
// - NAT 및 로드 밸런싱
return TC_ACT_OK; // 또는 TC_ACT_SHOT 등
}
// 3. 소켓 프로그램
// 소켓 수준에서 통신 제어
SEC("sockops")
int handle_sockops(struct sockops_md *ctx) {
// 소켓 작업 처리
// - 소켓 리다이렉션
// - 소켓 수준 로드 밸런싱
return 0;
}
// 4. cgroup 프로그램
// 컨테이너 그룹 수준에서 제어
SEC("cgroup_skb/ingress")
int handle_cgroup_ingress(struct __sk_buff *ctx) {
// cgroup 수준 정책 시행
// - 네트워크 네임스페이스 제어
return 1; // 허용
}
// 5. 트레이싱 프로그램
// 네트워크 이벤트 추적 및 디버깅
SEC("tracepoint/net/netif_receive_skb")
int trace_packet_receive(struct trace_event_raw_net_dev_xmit *ctx) {
// 패킷 추적 및 로깅
// - 성능 데이터 수집
// - 디버그 정보 수집
return 0;
}
/* 각 프로그램 유형은 서로 다른 네트워크 스택 지점에서 실행되며,
* 특정 기능을 구현하기 위해 최적화되어 있습니다.
* Cilium은 이러한 다양한 프로그램을 조합하여 종합적인
* 네트워킹 및 보안 솔루션을 제공합니다.
*/✅ 주요 eBPF 맵과 데이터 구조
eBPF 맵은 데이터 플레인의 상태를 저장하고 프로그램 간에 데이터를 공유하는 데 사용됩니다.
/* Cilium의 주요 eBPF 맵 예시 */
// 1. 엔드포인트 맵
// Pod ID와 정보 매핑
struct bpf_elf_map __section_maps endpoint_map = {
.type = BPF_MAP_TYPE_HASH,
.size_key = sizeof(uint32_t), // 엔드포인트 ID
.size_value = sizeof(struct endpoint_info), // 엔드포인트 정보
.max_elem = 65536, // 최대 엔드포인트 수
};
// 2. 정책 맵
// 엔드포인트 간 정책 정보 저장
struct bpf_elf_map __section_maps policy_map = {
.type = BPF_MAP_TYPE_HASH,
.size_key = sizeof(struct policy_key), // 소스+대상 엔드포인트
.size_value = sizeof(struct policy_entry), // 정책 결정 정보
.max_elem = 1048576, // 정책 엔트리 수
};
// 3. 연결 추적 맵
// 활성 연결 상태 추적
struct bpf_elf_map __section_maps ct_map = {
.type = BPF_MAP_TYPE_LRU_HASH, // 최근 사용 기반 해시
.size_key = sizeof(struct ct_key), // 연결 식별자
.size_value = sizeof(struct ct_entry), // 연결 상태
.max_elem = 524288, // 최대 연결 수
};
// 4. 서비스 맵
// 서비스 IP:포트와 백엔드 매핑
struct bpf_elf_map __section_maps services_map = {
.type = BPF_MAP_TYPE_HASH,
.size_key = sizeof(struct service_key), // 서비스 IP+포트
.size_value = sizeof(struct service_value), // 백엔드 정보
.max_elem = 65536, // 최대 서비스 수
};
// 5. 라우팅 맵
// 다음 홉 정보 저장
struct bpf_elf_map __section_maps routes_map = {
.type = BPF_MAP_TYPE_LPM_TRIE, // 최장 접두사 매치
.size_key = sizeof(struct lpm_key), // IP 접두사
.size_value = sizeof(struct route_info), // 라우팅 정보
.max_elem = 16384, // 라우팅 엔트리 수
};
// 6. 이벤트 맵
// 모니터링 이벤트 저장
struct bpf_elf_map __section_maps events_map = {
.type = BPF_MAP_TYPE_PERF_EVENT_ARRAY, // 성능 이벤트 배열
.size_key = sizeof(int), // CPU ID
.size_value = sizeof(int), // 인덱스
.max_elem = 1024, // 이벤트 수
};
/* 이러한 맵들은 eBPF 프로그램과 사용자 공간의 Cilium Agent 사이에서
* 데이터를 교환하는 핵심 메커니즘입니다. eBPF 프로그램은 패킷 처리 중
* 이 맵들을 조회하여 정책 결정, 라우팅, 로드 밸런싱 등을
* 수행합니다.
*/✅ 패킷 처리 흐름 상세 분석
eBPF 기반 데이터 플레인에서 패킷이 어떻게 처리되는지 자세히 살펴보겠습니다.
# Cilium eBPF 패킷 처리 흐름
[패킷 수신] → [XDP 프로그램] → [TC 인그레스] → [라우팅] → [정책 시행] → [L7 프록시?] → [변환(NAT)] → [TC 이그레스] → [전달]
## 1. 패킷 수신 및 초기 처리 (XDP)
- 드라이버 수준에서 패킷 수신
- XDP 프로그램 실행
- DDoS 공격 필터링
- 허용되지 않은 IP 드롭
- 서비스 로드 밸런싱 (빠른 경로)
## 2. TC 인그레스 처리
- 네트워크 스택 진입 시점
- 패킷 분류 및 메타데이터 추출
- 연결 추적 맵 조회 (상태 추적)
- 서비스 IP 변환 (로드 밸런싱)
## 3. 정책 결정 및 시행
- 소스/대상 ID 결정
- 정책 맵 조회
- L3/L4 정책 적용
- 거부된 패킷 드롭
## 4. L7 정책 처리 (필요시)
- 해당하는 경우 패킷을 프록시로 리다이렉션
- HTTP, Kafka, gRPC 등 프로토콜 인식
- L7 정책 적용 후 원래 경로로 복귀
## 5. 패킷 변환 및 전달
- 필요한 NAT 수행
- 패킷 헤더 다시 작성
- 라우팅 결정
- 대상 인터페이스로 전달
## 6. 이벤트 기록 (모니터링)
- 패킷 메타데이터 수집
- 정책 결정 기록
- 연결 상태 업데이트
- 이벤트 맵에 데이터 저장 (Hubble 사용)
# 이러한 처리 과정은 대부분 커널 내에서 발생하므로
# 전통적인 네트워킹 스택보다 훨씬 효율적입니다.
# 컨텍스트 전환이 최소화되고, 중복 처리가 제거됩니다.📌 Hubble: 네트워크 가시성 확보
Hubble은 Cilium의 네트워크 관찰성 계층으로, eBPF 데이터 플레인에서 수집한 정보를 기반으로 강력한 네트워크 모니터링 기능을 제공합니다.
✅ Hubble 아키텍처 개요
# Hubble 아키텍처 구성요소
[Cilium eBPF 데이터 플레인]
↑
│ (이벤트 수집)
↓
[Hubble Server] ← 각 노드의 Cilium Agent 내 포함
↑
│ (이벤트 집계)
↓
[Hubble Relay] ← 클러스터 수준 이벤트 집계
↑
│ (쿼리 및 시각화)
↓
[Hubble CLI/UI] ← 사용자 인터페이스
# Hubble의 각 구성요소는 서로 다른 범위와 책임을 가지고 있으며,
# 함께 작동하여 포괄적인 네트워크 가시성을 제공합니다.✅ Hubble 구성요소 세부 설명
Hubble은 네트워크 흐름을 관찰하고 분석하기 위한 여러 구성요소로 이루어져 있습니다.
# Hubble 주요 구성요소 상세 설명
hubble-components:
# 1. Hubble Server
server:
description: Cilium Agent에 내장된 컴포넌트
functions:
- eBPF 맵에서 네트워크 흐름 데이터 수집
- 네트워크 이벤트 버퍼링 및 필터링
- gRPC API를 통한 데이터 노출
deployment: "Cilium Agent의 일부로 각 노드에서 실행"
# 2. Hubble Relay
relay:
description: 여러 Hubble Server의 데이터를 집계하는 컴포넌트
functions:
- 다중 노드 데이터 집계
- 클러스터 전체 뷰 제공
- 데이터 스트리밍 및 필터링
deployment: "별도 배포로 클러스터에 설치"
# 3. Hubble CLI
cli:
description: 명령줄 인터페이스
functions:
- Hubble Server 또는 Relay에 쿼리
- 네트워크 흐름 필터링 및 검색
- 데이터 분석 및 출력
deployment: "사용자 워크스테이션에 설치"
# 4. Hubble UI
ui:
description: 웹 기반 시각화 인터페이스
functions:
- 서비스 맵 시각화
- 네트워크 흐름 대시보드
- 연결 및 정책 분석
deployment: "별도 배포로 클러스터에 설치"
# 이러한 구성요소들이 함께 작동하여 쿠버네티스 네트워크에 대한
# 전례 없는 가시성을 제공합니다.✅ 네트워크 흐름 관찰 기능
Hubble이 수집하고 분석할 수 있는 네트워크 흐름 정보에 대해 알아봅시다.
# Hubble이 수집하는 주요 네트워크 흐름 정보
# 1. 기본 연결 메타데이터
$ hubble observe
# 출력: TIMESTAMP SOURCE DESTINATION TYPE VERDICT ...
# 10:00:01.123 default/pod-a:34234 default/pod-b:80 http forwarded
# 2. L3/L4 정보
# - 소스/대상 IP 및 포트
# - 프로토콜 (TCP/UDP)
# - 패킷/바이트 카운트
# - 연결 추적 상태
# 3. L7 프로토콜 정보
# - HTTP 메소드, 경로, 상태 코드
$ hubble observe --protocol http
# 출력: HTTP/1.1 GET /api/users -> 200 OK
# - Kafka 토픽, 메소드
$ hubble observe --protocol kafka
# 출력: Kafka Produce topic:orders -> success
# - DNS 쿼리 및 응답
$ hubble observe --protocol dns
# 출력: DNS IN A example.com -> successful NOERROR
# 4. 쿠버네티스 컨텍스트
# - 네임스페이스, Pod 이름, 서비스 이름
# - 워크로드 레이블
# - 노드 정보
# 5. 정책 결과
# - 정책 결정 (허용/거부)
$ hubble observe --verdict DROPPED
# 출력: (패킷이 정책에 의해 거부된 연결 표시)
# - 정책 이름 및 원인
# - L3/L4/L7 정책 정보
# 이러한 풍부한 메타데이터를 통해 네트워크 문제 디버깅,
# 보안 모니터링, 애플리케이션 성능 분석이 가능합니다.✅ Hubble 설치 및 구성
Hubble 구성요소를 설치하고 구성하는 기본 방법을 알아보겠습니다. 상세한 설치 과정은 EP05에서 다룰 예정입니다.
# Hubble 설치 기본 단계 (Cilium CLI 사용)
# 1. Hubble 서버 활성화 (Cilium Agent 구성)
$ cilium hubble enable --ui
# 2. Hubble Relay 설치
$ cilium hubble enable --relay
# 3. Hubble CLI 설치 (로컬 머신)
$ curl -L --remote-name-all https://github.com/cilium/hubble/releases/latest/download/hubble-linux-amd64.tar.gz
$ tar -xzf hubble-linux-amd64.tar.gz
$ sudo mv hubble /usr/local/bin
# 4. Hubble UI 접근 설정
$ cilium hubble ui
# 주요 구성 옵션
# - 흐름 히스토리 크기 (--flow-buffer-size)
# - 메트릭 활성화 (--metrics)
# - TLS 인증서 설정
# - 포트 구성
# 더 자세한 설치 방법과 고급 구성 옵션은 EP05에서 다룰 예정입니다.📌 Cilium CRD 리소스 이해하기
Cilium은 여러 Kubernetes Custom Resource Definition(CRD)을 통해 고급 기능을 구현합니다. 주요 CRD 리소스와 그 용도를 살펴보겠습니다.
✅ 주요 Cilium CRD 목록
# Cilium CRD 확인하기
$ kubectl get crds | grep cilium
# 출력:
# ciliumclusterwidenetworkpolicies.cilium.io
# ciliumendpoints.cilium.io
# ciliumexternalworkloads.cilium.io
# ciliumidentities.cilium.io
# ciliumnetworkpolicies.cilium.io
# ciliumnodes.cilium.io
# ...✅ CiliumNetworkPolicy
가장 많이 사용되는 CRD로, Kubernetes NetworkPolicy를 확장하여 더 세분화된 네트워크 정책을 정의할 수 있습니다.
# CiliumNetworkPolicy 예시
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: secure-api
namespace: app
spec:
# 정책이 적용될 엔드포인트 선택
endpointSelector:
matchLabels:
app: api-server
# 들어오는 통신 규칙
ingress:
# 프론트엔드 앱에서 오는 트래픽만 허용
- fromEndpoints:
- matchLabels:
app: frontend
# 허용할 포트 및 프로토콜 지정
toPorts:
- ports:
- port: "8080"
protocol: TCP
# L7 HTTP 규칙 (Cilium의 고유 기능)
rules:
http:
# GET 메소드와 특정 API 경로만 허용
- method: "GET"
path: "/api/v1/public.*"
# 인증된 사용자를 위한 추가 경로
- method: "GET"
path: "/api/v1/users"
headers:
- 'Authorization: Bearer [a-zA-Z0-9\-\_]+' # 정규식 패턴
# 위 정책은 다음과 같은 기능을 제공합니다:
# 1. 'app: api-server' 레이블이 있는 모든 Pod 보호
# 2. 'app: frontend' 레이블이 있는 Pod에서의 트래픽만 허용
# 3. TCP 포트 8080으로만 접근 가능
# 4. HTTP GET 메소드와 특정 경로만 허용
# 5. 일부 경로는 인증 헤더가 있는 요청만 허용✅ CiliumClusterwideNetworkPolicy
네임스페이스 경계를 넘어 전체 클러스터에 적용되는 네트워크 정책을 정의합니다.
# CiliumClusterwideNetworkPolicy 예시
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: block-malicious-ips
spec:
# 모든 엔드포인트에 적용
endpointSelector: {}
# 들어오는 통신 규칙
ingress:
# 특정 IP 범위에서 오는 모든 트래픽 차단
- fromCIDRSet:
- cidr: "198.51.100.0/24"
except:
- "198.51.100.10/32" # 예외 IP 허용
- cidr: "203.0.113.0/24"
# 모든 포트 및 프로토콜에 적용
toPorts:
- ports:
- port: "0"
protocol: "ANY"
# 이 규칙 위반 시 거부
action: Deny
# 이 정책은:
# 1. 클러스터 내 모든 엔드포인트에 적용됨
# 2. 지정된 CIDR 블록(알려진 악성 IP 범위)에서 오는 모든 트래픽 차단
# 3. 특정 IP는 예외로 허용
# 4. 명시적으로 'Deny' 액션 지정 (기본값은 'Allow')
# 5. 모든 네임스페이스에 적용됨✅ CiliumEndpoint
Cilium이 관리하는 각 엔드포인트(Pod)에 대한 상태 정보를 저장합니다.
# CiliumEndpoint 예시 (자동 생성됨)
apiVersion: cilium.io/v2
kind: CiliumEndpoint
metadata:
name: app-api-server-6d94f7b475-2hlc9
namespace: app
ownerReferences:
- apiVersion: v1
kind: Pod
name: api-server-6d94f7b475-2hlc9
spec:
# 컨테이너 ID
container-id: 3cf780a7cfbea516f3dcdd65e2c2b5f8c23f8056b416a860a85c7419b0cf0a0a
# 엔드포인트 ID
id: 42
# IP 주소 정보
addressing:
- ip: "10.0.0.42"
primary: true
# 아이덴티티 정보
identity:
id: 13453
labels:
- k8s:app=api-server
- k8s:io.kubernetes.pod.namespace=app
# 네트워크 정책 상태
policy:
ingress:
enforcing: true
egress:
enforcing: true
# 상태 정보
state: ready
# 적용된 네트워크 정책 목록
policy-revision: "23"
# 네임스페이스
namespace: app
# 노드 이름
node: worker-1
# 이 리소스는 Cilium이 자동으로 생성하고 관리합니다.
# 엔드포인트 상태 확인, 문제 해결에 유용한 정보를 제공합니다.✅ CiliumIdentity
Cilium의 ID 기반 보안 모델에 사용되는 ID 정보를 저장합니다.
# CiliumIdentity 예시 (자동 생성됨)
apiVersion: cilium.io/v2
kind: CiliumIdentity
metadata:
name: "13453"
spec:
# 아이덴티티 레이블 정보
security-labels:
k8s:app: api-server
k8s:io.kubernetes.pod.namespace: app
# 이 리소스는 레이블 세트를 숫자 ID에 매핑합니다.
# Cilium은 이 숫자 ID를 사용하여 eBPF 맵에서 정책을 효율적으로 조회합니다.✅ 기타 Cilium CRD
# CiliumNode 예시 (자동 생성됨)
apiVersion: cilium.io/v2
kind: CiliumNode
metadata:
name: worker-1
spec:
# 노드 IP 주소
addresses:
- type: InternalIP
ip: 192.168.1.101
# IPAM 정보
ipam:
pools:
- pool: 10.0.0.0/24
poolID: 1
# CiliumExternalWorkload 예시
apiVersion: cilium.io/v2
kind: CiliumExternalWorkload
metadata:
name: external-app
spec:
# 외부 워크로드 IP
ipAddress: 192.168.100.10
# 메타데이터 및 레이블
labels:
- key: role
value: external-app
# CiliumLocalRedirectPolicy 예시
apiVersion: cilium.io/v2
kind: CiliumLocalRedirectPolicy
metadata:
name: proxy-redirect
spec:
# 리다이렉션 대상
redirectTarget:
localEndpointSelector:
matchLabels:
app: proxy
port: 8080
# 리다이렉션할 트래픽 지정
redirectFrontend:
- addressMatcher:
ip: "169.254.169.254"
toPorts:
- port: "80"
protocol: TCP📌 데이터 플레인 vs 컨트롤 플레인
Cilium 아키텍처에서 데이터 플레인과 컨트롤 플레인의 차이점과 상호작용을 이해하는 것이 중요합니다.
✅ 데이터 플레인과 컨트롤 플레인 비교
| 특성 | 데이터 플레인 | 컨트롤 플레인 |
|---|---|---|
| 주요 구성요소 | eBPF 프로그램 및 맵 | Cilium Agent, Cilium Operator |
| 실행 환경 | 커널 공간 | 사용자 공간 |
| 처리 대상 | 패킷 및 네트워크 데이터 | 구성, 정책, 상태 정보 |
| 지연 시간 특성 | 초저지연, 실시간 처리 | 상대적으로 높은 지연 |
| 규모 확장성 | 성능 영향 최소화 | 리소스 사용량 증가 |
| 처리 방식 | 모든 패킷 검사 및 결정 | 이벤트 기반 처리 |
| 장애 영향 | 서비스 중단 가능성 | 새 구성 적용 불가 |
| 기능 역할 | 패킷 필터링, 라우팅, NAT | 정책 컴파일, 리소스 관리 |
두 계층은 각자 다른 특성과 책임을 가지고 있지만, 함께 작동하여 완전한 네트워킹 솔루션을 제공합니다
✅ 플레인 간 상호작용
데이터 플레인과 컨트롤 플레인이 어떻게 상호작용하는지 알아보겠습니다.
# 컨트롤 플레인과 데이터 플레인 간 상호작용 흐름
1. 구성 및 정책 변경
컨트롤 플레인:
- Kubernetes API 변경 감지
- 정책 유효성 검사 및 컴파일
- eBPF 프로그램 및 맵 업데이트
데이터 플레인:
- 새 구성으로 패킷 처리 시작
- 최신 정책 적용
2. 상태 및 메트릭 수집
데이터 플레인:
- 네트워크 활동 추적
- 이벤트 및 메트릭 생성
- eBPF 맵에 데이터 저장
컨트롤 플레인:
- eBPF 맵 데이터 읽기
- 상태 집계 및 보고
- 모니터링 시스템에 메트릭 전송
3. 고장 감지 및 복구
컨트롤 플레인:
- 엔드포인트 상태 모니터링
- 문제 감지 및 진단
- 복구 작업 수행
데이터 플레인:
- 패킷 처리 계속 (가능한 경우)
- 기존 연결 유지
4. 확장 및 업그레이드
컨트롤 플레인:
- 새 리소스 배포
- 롤링 업데이트 조정
- 마이그레이션 처리
데이터 플레인:
- 다운타임 없이 프로그램 교체
- 트래픽 지속적 처리
# 이러한 상호작용을 통해 두 계층이 조화롭게 작동하면서
# 견고하고 확장 가능한 네트워킹 솔루션을 제공합니다.✅ 분리된 플레인 구조의 이점
# 데이터 플레인과 컨트롤 플레인 분리의 주요 이점
1. 안정성 향상
- 컨트롤 플레인 장애 시에도 데이터 플레인은 계속 작동
- 기존 연결 및 정책은 중단 없이 유지
- 점진적 업그레이드 가능
2. 성능 최적화
- 데이터 플레인은 고성능 경로에 최적화
- 컨트롤 플레인 오버헤드가 패킷 처리에 영향 없음
- 리소스 사용 효율화
3. 확장성 개선
- 데이터 플레인 성능은 트래픽 증가에 일정하게 유지
- 컨트롤 플레인은 독립적으로 확장 가능
- 대규모 클러스터 지원 용이
4. 명확한 책임 분리
- 문제 해결 및 디버깅 용이
- 구성요소별 최적화 가능
- 아키텍처 이해 및 관리 단순화
5. 보안 강화
- 권한 분리 및 최소 권한 원칙 적용
- 취약점 영향 범위 제한
- 격리된 업데이트 및 패치 적용
# 이러한 이점들로 인해 Cilium의 아키텍처는
# 엔터프라이즈급 환경에서도 안정적으로 작동합니다.📌 Summary
이번 글에서는 Cilium의 아키텍처와 내부 구성요소에 대해 상세히 알아보았습니다. 주요 내용을 정리하면:
- Cilium의 주요 구성요소는 컨트롤 플레인(Cilium Agent, Operator)과 데이터 플레인(eBPF 프로그램, 맵)으로 나뉩니다.
- Cilium Agent는 각 노드에서 실행되며, eBPF 프로그램 관리, 정책 시행, 엔드포인트 관리 등 노드 수준의 작업을 담당합니다.
- Cilium Operator는 클러스터 수준에서 IP 풀 관리, 노드 검색, CRD 관리 등의 작업을 수행합니다.
- 데이터 플레인은 eBPF 프로그램과 맵으로 구성되며, 커널 내에서 효율적으로 패킷을 처리하고 정책을 시행합니다.
- Hubble은 네트워크 흐름 모니터링 도구로, Server, Relay, UI 등의 구성요소를 통해 네트워크 가시성을 제공합니다.
- Cilium CRD는 CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, CiliumEndpoint 등 다양한 리소스를 통해 고급 기능을 구현합니다.
- 데이터 플레인과 컨트롤 플레인의 분리는 안정성, 성능, 확장성, 보안 측면에서 많은 이점을 제공합니다.
728x90
'Kubernetes Tools > Cilium' 카테고리의 다른 글
| EP06. 기본 L3/L4 정책 설정 | CiliumNetworkPolicy 기초 실습 (0) | 2025.03.22 |
|---|---|
| EP05. Hubble 설치 및 구성 | 쿠버네티스 네트워크 가시성 확보 (0) | 2025.03.22 |
| EP04. Cilium 설치하기 | Docker Desktop 기반 실습 환경 구성 (0) | 2025.03.22 |
| EP02. eBPF란 무엇인가? | Cilium의 핵심 엔진 이해하기 (0) | 2025.03.21 |
| EP01. CNI란 무엇인가? | 쿠버네티스 네트워크의 시작 (0) | 2025.03.21 |