컴포넌트 개요
컴포넌트 개요 (Component Overview)
Cilium과 Hubble 배포는 클러스터에서 실행되는 여러 컴포넌트로 구성돼요. 이 문서에서는 Cilium, Hubble, eBPF, 데이터 스토어가 각각 어떤 역할을 하는지 컴포넌트별로 정리합니다.
본문
클러스터에서 실행되는 Cilium과 Hubble 배포는 다음과 같은 컴포넌트로 구성돼요.
Cilium
- Agent —
Cilium 에이전트(
cilium-agent)는 클러스터의 각 노드에서 실행돼요. 높은 수준에서 보면, 에이전트는 네트워킹, 서비스 로드 밸런싱, 네트워크 정책, 가시성·모니터링 요구사항을 기술하는 구성을 Kubernetes 또는 API를 통해 받습니다.
Cilium 에이전트는 Kubernetes 같은 오케스트레이션 시스템의 이벤트를 수신해서 컨테이너나 워크로드가 시작·중지되는 시점을 파악해요. 그리고 Linux 커널이 해당 컨테이너 안팎의 모든 네트워크 접근을 제어하는 데 사용하는 eBPF 프로그램을 관리합니다.
- 디버그 클라이언트(CLI) —
Cilium 디버그 CLI 클라이언트(
cilium-dbg)는 Cilium 에이전트와 함께 설치되는 커맨드라인 도구예요. 같은 노드에서 실행 중인 Cilium 에이전트의 REST API와 상호작용합니다. 디버그 CLI로 로컬 에이전트의 상태를 점검할 수 있고, eBPF 맵에 직접 접근해서 상태를 검증하는 도구도 제공해요.
Note
여기서 설명하는 에이전트 내장 Cilium 디버그 CLI 클라이언트를 Kubernetes 클러스터에서 Cilium을 빠르게 설치·관리·트러블슈팅하는
cilium커맨드라인 도구와 혼동하면 안 돼요. 그 도구는 보통 클러스터와 떨어진 곳에 설치되며,kubeconfig정보를 이용해 Kubernetes API를 통해 클러스터에서 실행 중인 Cilium에 접근합니다.
- Operator — Cilium Operator는 클러스터의 각 노드마다 처리할 필요 없이 클러스터 전체에 대해 한 번만 논리적으로 처리하면 되는 작업을 담당해요. Cilium Operator는 포워딩이나 네트워크 정책 결정의 중요 경로(critical path)에 있지 않습니다. 따라서 Operator가 일시적으로 사용 불가능하더라도 클러스터는 일반적으로 계속 동작해요. 다만 구성에 따라 Operator 가용성에 문제가 생기면 다음과 같은 일이 발생할 수 있습니다:
- IP 주소 관리(IPAM)가 지연되어, Operator가 새 IP 주소를 할당해야 하는 경우 새 워크로드 스케줄링이 지연될 수 있어요.
- kvstore 하트비트 키 업데이트에 실패해서 에이전트가 kvstore 비정상으로 판단하고 재시작할 수 있어요.
- CNI 플러그인 —
CNI 플러그인(
cilium-cni)은 노드에 파드가 스케줄되거나 종료될 때 Kubernetes가 호출해요. 노드의 Cilium API와 상호작용해서 해당 파드에 네트워킹, 로드 밸런싱, 네트워크 정책을 제공하는 데 필요한 데이터패스 구성을 트리거합니다.
Hubble
-
Server — Hubble 서버는 각 노드에서 실행되며 Cilium에서 eBPF 기반 가시성을 가져와요. 높은 성능과 낮은 오버헤드를 위해 Cilium 에이전트에 내장되어 있습니다. 흐름(flow)과 Prometheus 메트릭을 가져오는 gRPC 서비스를 제공해요.
-
Relay — Relay(
hubble-relay)는 실행 중인 모든 Hubble 서버를 인식하는 독립 컴포넌트예요. 각 서버의 gRPC API에 연결해서 클러스터 전체의 가시성을 제공하고, 클러스터의 모든 서버를 나타내는 API를 제공합니다. -
클라이언트(CLI) — Hubble CLI(
hubble)는hubble-relay의 gRPC API나 로컬 서버에 연결해 흐름 이벤트를 가져올 수 있는 커맨드라인 도구예요. -
그래픽 UI(GUI) — 그래픽 사용자 인터페이스(
hubble-ui)는 relay 기반 가시성을 활용해 그래픽형 서비스 의존성·연결 맵을 제공해요.
eBPF
eBPF는 원래 네트워크 패킷 필터링(tcpdump, 소켓 필터 등)을 위해 도입된 Linux 커널 바이트코드 인터프리터예요. 이후 hashtable, 배열 같은 추가 데이터 구조와 함께 패킷 변형(mangling), 포워딩, 캡슐화 등을 지원하는 추가 동작으로 확장되었습니다. 커널 내부의 verifier가 eBPF 프로그램이 안전하게 실행될 수 있는지 보장하고, JIT 컴파일러가 바이트코드를 CPU 아키텍처별 명령어로 변환해 네이티브 실행 효율을 높여요. eBPF 프로그램은 수신·송신 패킷 같은 커널의 다양한 훅(hook) 지점에서 실행될 수 있어요.
Cilium은 Linux 커널의 사용 가능한 기능을 프로빙해서, 새 기능이 감지되면 자동으로 활용합니다.
커널 버전에 대한 자세한 내용은 Linux 커널을 참고하세요.
데이터 스토어
Cilium은 에이전트 간 상태를 전파하기 위해 데이터 스토어가 필요해요. 다음과 같은 데이터 스토어를 지원합니다:
-
Kubernetes CRD(기본값) — 데이터를 저장하고 상태를 전파하는 기본 선택지는 Kubernetes 커스텀 리소스 정의(CRD)를 사용하는 거예요. CRD는 클러스터 컴포넌트가 Kubernetes 리소스를 통해 구성과 상태를 나타내도록 Kubernetes가 제공하는 기능입니다.
-
키-값 스토어(Key-Value Store) — 상태 저장과 전파에 필요한 모든 요구사항은 Cilium 기본 구성대로 Kubernetes CRD로 충족돼요. 키-값 스토어는 선택적으로 사용할 수 있는데, 변경 알림과 저장 요구사항이 직접 키-값 스토어를 사용할 때 더 효율적이므로 클러스터 확장성(scalability)을 높이는 최적화 역할을 합니다.
현재 지원되는 키-값 스토어는 다음과 같아요:
Note
Kubernetes의 etcd 클러스터를 그대로 사용하거나 전용 etcd 클러스터를 유지하는 것도 가능해요.