[cilium] Hubble 개념과 설치

Hubble 이란

Hubble 은 Cilium 과 eBPF 위에 구축된 완전 분산형 네트워크 및 보안 관찰 가능성 플랫폼이다.

서비스 간 통신 및 네트워킹 인프라를 완전히 투명한 방식으로 깊이 있게 관찰할 수 있게 가시성을 제공한다.

eBPF 를 기반으로 하기 때문에 동적으로 프로그래머블하고 가시성을 제공할 수 있다. 성능 오버헤드를 최소화하면서 사용자에게 상세한 정보를 제공할 수 있다.

 

모니터링 monitoring 과 관측 가능성 observability 의 차이점은?
모니터링은 사전에 정의된 기준을 기반으로 시스템의 상태를 확인하는 용어이고, 관측 가능성은 수집된 다양한 데이터를 활용하여 예측되지 않은 문제까지 분석할 수 있는 성질을 의미한다.

 

Hubble 이 답할 수 있는 주요 질문들

 

서비스 의존성과 통신 과정 분석

• 어떤 서비스들이 서로 통신하고 있는가? 얼마나 자주 통신하는가?
• 서비스 흐름도는 어떻게 구성되어 있는가?
• 어떤 HTTP 호출이 이루어지고 있는가?
• 특정 서비스가 어떤 Kafka 토픽에서 데이터를 소비하거나 생산하는가?

네트워크 모니터링과 알림

• 네트워크 통신에 실패가 있는가? 왜 통신이 실패하는가?
• DNS 문제인가? 애플리케이션 문제인가, 네트워크 문제인가?
• 레이어 4(TCP)에서 문제인가, 레이어 7(HTTP)에서 문제인가?
• 지난 5분 동안 DNS 해결 문제를 겪은 서비스는 어떤 것들인가?
• 최근에 TCP 연결이 중단되거나 연결 타임아웃을 겪은 서비스는?

애플리케이션 모니터링

• 특정 서비스나 전체 클러스터에서 5xx, 4xx HTTP 응답 코드의 비율은?
• 클러스터 내 HTTP 요청과 응답 간의 95번째, 99번째 백분위수 지연시간은?
• 어떤 서비스가 가장 성능이 좋지 않은가?
• 두 서비스 간의 지연시간은 얼마인가?

보안 관찰 가능성

• 네트워크 정책으로 인해 연결이 차단된 서비스는?
• 클러스터 외부에서 액세스된 서비스는?
• 특정 DNS 이름을 해결한 서비스는?

 

Hubble 을 사용해야 하는 이유

현대 애플리케이션들은 마이크로서비스라고 불리는 서비스 지향 아키텍처로 개발되는 추세이다.

대규모 애플리케이션은 HTTP 같은 경량 API 를 통해 서로 통신하는 작은 독립적인 서비스들로 분할되면서 매우 동적인 경향이 있다.

개별 컨테이너들이 로드 변경이 될 때마다 애플리케이션이 스케일 아웃/인 할 때, 지속적 배포의 일부로 배포되는 롤링 업데이트 동안 시작되거나 종료된다.

 

전통적인 Linux 네트워크 보안 접근 방식(예 : iptables)은 IP 주소와 TCP/UDP 포트로 필터링하지만, IP 주소는 동적 마이크로서비스 환경에서 자주 변경된다. 컨테이너의 변동성이 높은 라이프사이클은 이런 접근 방식이 애플리케이션과 함께 확장하는 데 어려움을 겪게 만든다. 로드 밸런싱 테이블과 수십만 개의 규칙을 포함하는 액세스 제어 목록이 지속적으로 변경되어야 하기 때문이다.

프로토콜 포트(예: HTTP 트래픽을 위한 TCP 포트 80)는 서비스 전반에 걸쳐 광범위한 메시지를 전송하는데 사용되므로 애플리케이션 트래픽을 구분하는 데 더 이상 사용할 수 없게 되었다.

 

이에 Cilium 은 Linux eBPF 를 활용하여 서비스/포드/컨테이너 신원을 기반으로 하고 애플리케이션 계층(예: HTTP)을 필터링할 수 있는 방식으로 이를 수행한다. 동일한 보안 정책을 공유하는 애플리케이션 컨테이너 그룹에 Security Identifier 를 할당한다.

 

결과적으로 Cilium 은 보안을 주소(IP 나 MAC)에서 분리함으로써 매우 동적인 환경에서 보안 정책을 적용하는 것을 간단하게 만들 뿐만 아니라, 전통적인 레이어 3과 레이어 4 분할을 제공하는 것에 더해 HTTP 계층에서 작동함으로써 더 강력한 보안 격리를 제공할 수 있다.

 

Cilium 구성 요소

Cilium-Agent

Cilium 에이전트(cilium-agent)는 클러스터의 각 노드에서 실행된다. 에이전트는 네트워킹, 서비스 로드 밸런싱, 네트워크 정책, 가시성과 모니터링을 kubernets(API)를 통해 제공한다.

컨테이너나 워크로드가 시작되고 중지되는 시점을 확인하기 위해 오케스트레이션 시스템(Kubernetes 같은)의 이벤트를 수신한다.

또한, Linux 커널이 해당 컨테이너 안팎의 모든 네트워크 액세스를 제어하는 데 사용하는 eBPF 프로그램을 관리한다.

Cilium-Dbg

Cilium 디버그 CLI 클라이언트(cilium-dbg)는 Cilium 에이전트와 함께 설치되는 명령줄 도구다. 같은 노드에서 실행 중인 Cilium 에이전트의 REST API를 통해 구동된다. 디버그 CLI를 통해 로컬 에이전트의 상태와 상황을 검사할 수 있으며, eBPF 맵에 직접 액세스하여 상태를 검증할 수 있다.

Cilium-Operator

Cilium 오퍼레이터는 클러스터 전체에 대해 한 번만 처리되어야 하는 클러스터 내 업무를 관리한다.

패킷 포워딩이나 네트워크 정책을 결정하지는 않아, 오퍼레이터가 일시적으로 사용할 수 없더라도 클러스터는 계속 동작할 수 있다.

하지만 오퍼레이터가 동작하지 않는다면 아래와 같은 문제점이 발생할 수 있다.

• IP 주소 관리(IPAM) 지연으로 인한 새 워크로드 스케줄링 지연
• kvstore heartbeat 키 업데이트 실패로 인한 에이전트 재시작

CNI 플러그인

CNI 플러그인(cilium-cni)은 파드가 노드에서 스케줄되거나 종료될 때 Kubernetes에 의해 호출된다. 파드에 대한 네트워킹, 로드 밸런싱, 네트워크 정책을 서비스하기 위해 필요한 data-path 설정을 트리거하도록 노드의 Cilium API와 상호작용한다.

 

Hubble 구성 요소

Hubble 서버

Hubble 서버는 각 노드에서 실행되며 Cilium 으로부터 eBPF 기반 가시성을 수집한다.

성능 최적화를 위해 Cilium 에이전트에 내장되어 있다. gRPC 서비스를 통해 데이터 플로우와 Prometheus 메트릭을 제공한다.

Hubble-relay

Hubble-relay 는 모든 실행 중인 Hubble 서버를 인식하고, 각각의 gRPC API에 연결하여 클러스터 전체 가시성을 제공한다.

Hubble CLI

Hubble CLI(hubble)는 hubble-relay의 gRPC API 나 로컬 서버에 연결하여 데이터 플로우 이벤트를 검색할 수 있는 명령줄 도구다.

Hubble-ui

Hubble-ui 는 Hubble-relay 기반 가시성을 활용하여 서비스 의존성과 연결 구성을 시각적으로 제공한다.

 

Cilium 의 데이터 보관

Cilium은 에이전트 간 상태를 전파하기 위해 데이터 저장소가 필요하다.

기본적으로 상태를 전파하기 위해 데이터 저장소로 Kubernetes CRD 를 사용한다.

CRD만으로 모든 상태 저장이 가능하지만, 대규모 클러스터에서는 성능 최적화를 위해 key-value 저장소를 병행할 수 있다.

Kubernetes의 etcd 클러스터를 직접 활용하거나 전용 etcd 클러스터를 유지하는 것이 가능하다.

 

---

 

Hubble 설치

hubble 은 helm upgrade 를 통해 hubble 관련 파라미터를 설정하거나, cilium cli 명령어로 hubble 을 활성화 할 수 있다.

 

방법 1

helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set hubble.ui.service.type=NodePort \
--set hubble.ui.service.nodePort=31234 \
--set hubble.export.static.enabled=true \
--set hubble.export.static.filePath=/var/run/cilium/hubble/events.log \
--set prometheus.enabled=true \
--set operator.prometheus.enabled=true \
--set hubble.metrics.enableOpenMetrics=true \
--set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,httpV2:exemplars=true;labelsContext=source_ip\,source_namespace\,source_workload\,destination_ip\,destination_namespace\,destination_workload\,traffic_direction}"

 

hubble.enabled=true 옵션과 hubble.relay.enabled=ture 옵션을 통해 활성화한다. 필수 옵션이다.

hubble relay 는 각 hubble api 들을 모두 수집하여 로그 중앙 집중화하기 때문에 각 서버에 질의를 하지 않으려면 필수다...

 

방법 2

cilium hubble enable
cilium hubble enable --ui

 

Hubble 을 설치완료하면, Hubble Relay 옵션이 OK 되고, 4244 포트가 활성화된다.

설치 전과 설치 후 ss -tnlp 명령어 비교 화면

 

hubble-relay-config 컨피그 맵을 살펴보면 hubble-peer.kube-system.svc.cluster.local DNS 주소 443 포트로 peer-service 가 구성되어 있다. hubble-peer 엔드포인트는 컨트롤 노드, 워커 노드의 4244 포트들의 집합이다. 4244 포트는 peer-service 를 통해 relay 에 전달하기 위한 창구임을 확인할 수 있다.

 

 

Hubble CLI 설치

hubble 데이터들은 GUI 말고 CLI 로도 확인할 수 있다.

# Linux 실습 환경에 설치 시
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
HUBBLE_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then HUBBLE_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}
sudo tar xzvfC hubble-linux-${HUBBLE_ARCH}.tar.gz /usr/local/bin
which hubble
hubble status

 

hubble-cli 바이너리는 설치되었지만 hubble-relay 서비스 포트인 4245 포트가 외부에 노출되어 있지 않아 접근이 되지 않는다.

아래처럼 포트 포워딩을 통해 접근 가능하도록 변경해준다.

( 참고 : https://docs.cilium.io/en/latest/observability/hubble/setup/#validate-hubble-api-access )

 

cilium hubble port-forward&

 

ss -tnlp 명령어와 hubble status, hubble config view 명령어를 통해 포트포워딩이 정상인지 확인한다.

 

hubble 이 정상적으로 설치되었다. hubble observe -h 명령어로 패킷 덤프하며 네트워크 흐름도를 파악해보자.