Cilium & Hubble 소개

Cilium & Hubble 소개 (Introduction to Cilium & Hubble)

Cilium은 Docker나 Kubernetes 같은 Linux 컨테이너 관리 플랫폼을 사용해 배포된 애플리케이션 서비스 간의 네트워크 연결을 투명하게 보호하는 오픈소스 소프트웨어예요. 이 문서는 Cilium이 eBPF를 기반으로 어떻게 보안·가시성을 제공하는지, 그리고 Hubble이 어떤 역할을 하는지 소개합니다.

출처: Introduction to Cilium & Hubble

본문

Cilium이란 무엇인가?

Cilium은 Docker와 Kubernetes 같은 Linux 컨테이너 관리 플랫폼을 사용해 배포된 애플리케이션 서비스 간의 네트워크 연결을 투명하게 보호하는 오픈소스 소프트웨어예요.

Cilium의 기반에는 eBPF라는 새로운 Linux 커널 기술이 있습니다. eBPF는 강력한 보안 가시성과 제어 로직을 Linux 자체 안에 동적으로 삽입할 수 있게 해줘요. eBPF는 Linux 커널 내부에서 실행되므로, Cilium 보안 정책은 애플리케이션 코드나 컨테이너 구성을 변경하지 않고도 적용·업데이트할 수 있습니다.

Video

Cilium에 대한 영상 소개를 원한다면 Cilium 공동 창업자 Thomas Graf의 설명을 확인하세요.

Hubble이란 무엇인가?

Hubble은 완전히 분산된 네트워킹·보안 관측성 플랫폼이에요. Cilium과 eBPF 위에 구축되어 서비스의 통신·동작과 네트워킹 인프라를 완전히 투명한 방식으로 깊이 있게 들여다볼 수 있게 해줍니다.

Cilium 위에 구축함으로써 Hubble은 가시성을 위해 eBPF를 활용할 수 있어요. eBPF에 의존하면 모든 가시성이 프로그래밍 가능하며, 사용자가 요구하는 깊이 있고 상세한 가시성을 제공하면서 오버헤드를 최소화하는 동적 접근이 가능합니다. Hubble은 이러한 새 eBPF 능력을 최대한 활용하도록 만들어졌어요.

Hubble은 다음과 같은 질문에 답할 수 있습니다:

서비스 의존성 & 통신 맵

어떤 서비스들이 서로 통신하고 있을까? 얼마나 자주? 서비스 의존성 그래프는 어떻게 생겼을까?
어떤 HTTP 호출이 이루어지고 있을까?

네트워크 모니터링 & 알림

네트워크 통신 중 실패하는 것이 있나? 왜 실패하지? DNS 문제인가? 애플리케이션 문제인가 네트워크 문제인가? 통신이 레이어 4(TCP)에서 깨졌나 레이어 7(HTTP)에서 깨졌나?
지난 5분간 어떤 서비스가 DNS 해석 문제를 겪었나? 최근 어떤 서비스가 중단된 TCP 연결이나 타임아웃되는 연결을 겪었나? 응답하지 않은 TCP SYN 요청의 비율은?

애플리케이션 모니터링

특정 서비스 또는 모든 클러스터에서 5xx나 4xx HTTP 응답 코드의 비율은?
클러스터에서 HTTP 요청과 응답 사이의 95번째·99번째 백분위 지연은? 어떤 서비스가 가장 나쁜가? 두 서비스 사이의 지연은?

보안 관측성

어떤 서비스가 네트워크 정책으로 인해 연결이 차단되었나? 클러스터 밖에서 접근된 서비스는 무엇인가? 특정 DNS 이름을 해석한 서비스는 무엇인가?

Video

Hubble에 대한 영상 소개를 원한다면 eCHO 에피소드 2: Introduction to Hubble을 확인하세요.

왜 Cilium & Hubble인가?

eBPF는 이전에는 불가능했던 세분화와 효율로 시스템과 애플리케이션에 대한 가시성과 제어를 가능하게 해줘요. 애플리케이션을 조금도 변경할 필요 없이 완전히 투명한 방식으로 이루어집니다. eBPF는 현대의 컨테이너화된 워크로드뿐 아니라 가상 머신, 표준 Linux 프로세스 같은 전통적인 워크로드도 동등하게 잘 처리할 수 있어요.

현대 데이터센터 애플리케이션의 개발은 흔히 마이크로서비스라고 불리는 서비스 지향 아키텍처로 전환되었어요. 여기서 큰 애플리케이션은 HTTP 같은 가벼운 프로토콜로 API를 통해 서로 통신하는 작고 독립적인 서비스들로 나뉩니다. 마이크로서비스 애플리케이션은 매우 동적이며, 부하 변화에 적응하기 위해 스케일 아웃/인할 때와 지속적 전달의 일부로 배포되는 롤링 업데이트 동안 개별 컨테이너가 시작되거나 파괴되는 경향이 있어요.

이런 고도로 동적인 마이크로서비스로의 전환은 마이크로서비스 간 연결 보안 측면에서 도전이자 기회를 제시해요. 전통적인 Linux 네트워크 보안 접근(예: iptables)은 IP 주소와 TCP/UDP 포트로 필터링하지만, 동적 마이크로서비스 환경에서는 IP 주소가 자주 변합니다. 컨테이너의 매우 휘발성 높은 수명주기는 부하 분산 테이블과 수십만 개의 규칙을 지닌 접근 제어 목록을 계속 증가하는 빈도로 업데이트해야 하므로, 이런 접근이 애플리케이션과 나란히 확장하기 어렵게 만듭니다. 프로토콜 포트(예: HTTP 트래픽의 TCP 80)는 포트가 서비스 전반의 광범위한 메시지에 사용되므로 더 이상 보안 목적으로 애플리케이션 트래픽을 구분하는 데 사용할 수 없습니다.

또 다른 도전은 정확한 가시성을 제공하는 능력이에요. 전통적인 시스템은 IP 주소를 기본 식별 수단으로 사용하는데, 이는 마이크로서비스 아키텍처에서 수명이 몇 초밖에 안 되는 수준으로 급격히 줄어들 수 있기 때문입니다.

Linux eBPF를 활용해 Cilium은 보안 가시성 + 적용을 투명하게 삽입하는 능력을 유지하지만, (전통 시스템의 IP 주소 식별과 달리) 서비스/파드/컨테이너 identity를 기반으로 하고 애플리케이션 레이어(예: HTTP)에서 필터링할 수 있는 방식으로 수행합니다. 그 결과 Cilium은 보안을 주소 지정에서 분리해 고도로 동적인 환경에서 보안 정책 적용을 단순하게 만들 뿐 아니라, 전통적인 레이어 3·레이어 4 분할에 더해 HTTP 레이어에서 동작해 더 강력한 보안 격리를 제공합니다.

eBPF 사용 덕분에 Cilium은 대규모 환경에서도 매우 확장 가능한 방식으로 이 모든 것을 달성할 수 있어요.

기능 개요

CNI (Container Network Interface)

Cilium을 CNI 플러그인으로 사용하면 Kubernetes 클러스터에 빠르고 확장 가능하며 안전한 네트워킹 레이어를 제공해요. eBPF를 기반으로 하며 여러 배포 옵션을 제공합니다:

오버레이 네트워킹: VXLAN과 Geneve를 지원하며 모든 호스트에 걸친 캡슐화 기반 가상 네트워크. 유일한 요구사항이 호스트 간 IP 연결(보통 이미 주어짐)이므로 거의 모든 네트워크 인프라에서 동작해요.
네이티브 라우팅 모드: Linux 호스트의 일반 라우팅 테이블 사용. 네트워크가 애플리케이션 컨테이너의 IP 주소를 라우팅할 수 있어야 합니다. 클라우드 라우터, 라우팅 데몬, IPv6 네이티브 인프라와 통합됩니다.
유연한 라우팅 옵션: 노드가 레이어 2 도메인을 공유할 때 L2 이웃 발견을 사용하거나 레이어 3 경계를 가로질러 라우팅할 때 BGP를 사용하는 등 일반적인 토폴로지에서 라우트 학습·광고를 자동화할 수 있어요.

각 모드는 운용 부담을 최소화하면서 기존 인프라와의 최대 상호운용성을 위해 설계되었어요.

로드 밸런싱

Cilium은 애플리케이션 컨테이너 간 및 외부 서비스와의 트래픽을 위한 분산 로드 밸런싱을 구현해요. 로드 밸런싱은 효율적인 해시 테이블을 사용해 eBPF로 구현되며, 높은 서비스 밀도와 낮은 지연을 확장성 있게 제공합니다.

동서(East-west) 로드 밸런싱은 소켓 레벨(connect())에서 서비스 연결을 재작성해 패킷별 NAT의 오버헤드를 피하고 kube-proxy를 완전히 대체합니다.
남북(North-south) 로드 밸런싱은 높은 처리량 시나리오를 위한 XDP와, Direct Server Return(DSR) 및 Maglev 일관 해싱을 포함한 레이어 4 로드 밸런싱을 지원합니다.

Cluster Mesh

Cilium Cluster Mesh는 여러 Kubernetes 클러스터 간에 안전하고 매끄러운 연결을 가능하게 해줘요. 하이브리드나 멀티 클라우드 환경을 운영하는 운영자에게 일관된 보안·연결 경험을 보장합니다.

글로벌 서비스 발견: 클러스터 간 워크로드가 마치 로컬인 것처럼 서비스를 발견하고 연결할 수 있어요. 이는 다른 클러스터의 백엔드로 자동 장애 조치하는 것 같은 내결함성을 가능하게 하며, 로깅·인증·데이터베이스 같은 공유 서비스를 환경 전반에 노출합니다.
통합 identity 모델: 보안 정책이 모든 클러스터에서 IP 주소가 아닌 identity를 기반으로 적용됩니다.

네트워크 정책

Cilium 네트워크 정책은 L3-L7에 걸친 identity 인식 적용을 제공해요. 일반적인 컨테이너 방화벽은 소스 IP 주소와 대상 포트로 필터링해 워크로드를 보호합니다. 이 개념은 클러스터 어디에서든 컨테이너가 시작될 때마다 모든 서버의 방화벽을 조작해야 함을 요구합니다.

확장을 제한하는 이 상황을 피하기 위해 Cilium은 동일한 보안 정책을 공유하는 애플리케이션 컨테이너 그룹에 보안 identity를 할당해요. 그런 다음 identity는 애플리케이션 컨테이너가 내보내는 모든 네트워크 패킷과 연결되어, 수신 노드에서 identity를 검증할 수 있습니다.

identity 기반 보안은 깨지기 쉬운 IP 주소에 대한 의존을 제거해요.
L3/L4 정책은 라벨, 프로토콜, 포트를 기반으로 트래픽을 제한합니다.
DNS 기반 정책: FQDN이나 와일드카드 도메인(예: api.example.com, *.trusted.com)으로의 트래픽을 허용·거부. 특히 서드파티 서비스로의 egress 트래픽을 보호하는 데 유용해요.
L7 인식 정책은 HTTP 메서드, URL 경로, gRPC 호출 등으로 필터링할 수 있습니다:
- 예: /public/.*에 대한 GET 요청만 허용.
- X-Token: [0-9]+ 같은 헤더의 존재를 강제.

외부 IP에 대한 접근을 제어하는 CIDR 기반 egress·ingress 정책도 지원되며, 레거시 시스템이나 규제 경계와 통합하는 데 이상적이에요.

서비스 메시

Cilium 서비스 메시로 운영자는 전통적인 프록시 기반 설계의 비용과 복잡성 없이 세밀한 트래픽 제어, 암호화, 관측성, 접근 제어의 이점을 얻을 수 있어요. 주요 기능:

IPSec 또는 WireGuard를 사용한 워크로드 간 자동 identity 기반 암호화를 통한 상호 인증(mutual authentication).
보안과 컴플라이언스를 위한 L7 인식 정책 적용.
Kubernetes Gateway API와의 깊은 통합: Gateway API 호환 데이터 플레인 역할을 하며, Kubernetes 네이티브 CRD를 사용해 인그레스, 트래픽 분할, 라우팅 동작을 선언적으로 관리할 수 있어요.

관측성과 트러블슈팅

관측성은 처음부터 Cilium에 내장되어 있어, 운영자가 시스템 동작을 진단·이해하는 데 도움이 되는 풍부한 가시성을 제공합니다:

Hubble: 실시간 서비스 맵, identity·라벨 메타데이터가 있는 흐름 가시성, DNS 인식 필터링과 프로토콜별 인사이트를 제공하는 완전 통합 관측성 플랫폼.
메트릭과 알림: Prometheus, Grafana 및 기타 모니터링 시스템과의 통합.
드랍 이유와 감사 추적(audit trails): 정책·포트 위반이나 DNS 조회 실패 같은 문제를 포함해 트래픽이 왜 드랍되었는지에 대한 실행 가능한 인사이트를 얻을 수 있어요.

Cilium & Hubble 소개