쿠버네티스 통신 문제, 더 이상 헤매지 마세요! Hubble 아키텍처 완전 정복 🚀

쿠버네티스 환경에서 서비스를 운영하다 보면 "분명 설정은 다 맞는데, 왜 이 파드에서 저 파드로 통신이 안 되지? 🤔" 와 같은 미스터리한 상황을 마주하게 됩니다. 로그를 뒤져봐도, describe 명령을 날려봐도 원인이 명확히 보이지 않을 때가 많죠.

이런 답답한 네트워크 문제를 해결해 줄 탐정이 바로 Cilium Hubble 입니다. Hubble은 eBPF 기술을 이용해 우리에게 쿠버네티스 클러스터 내부의 모든 통신을 투명하게 들여다볼 수 있는 마법 같은 능력을 부여합니다.

이번 글에서는 Hubble이 어떻게 동작하는지, 그 구조를 속속들이 파헤쳐 보겠습니다. 이 아키텍처만 제대로 이해하면, 앞으로 네트워크 문제 앞에서 당황하는 일은 없을 거예요!

---

Hubble 어벤져스: 세 명의 핵심 플레이어 🦸‍♂️

Hubble은 혼자 일하지 않습니다. 마치 어벤져스 팀처럼 각자 명확한 역할을 가진 세 가지 핵심 컴포넌트가 유기적으로 협력하며 동작합니다.

(출처: Cilium.io)

1. Hubble Agent (🕵️ 현장 요원)

• 배포 형태: DaemonSet (클러스터의 모든 노드에 하나씩!)
• 임무: 각 노드에서 발생하는 모든 네트워크 활동을 실시간으로 감시하고 수집하는 최전선 요원입니다.

Agent는 어떻게 모든 것을 알 수 있을까요? 비밀은 바로 eBPF에 있습니다.

1. 데이터 감지 🔍: Cilium은 커널 깊숙한 곳에서 eBPF를 이용해 모든 네트워크 패킷(L3/L4 정보, L7 HTTP 요청, DNS 쿼리 등)을 몰래 엿봅니다.
2. 버퍼에 기록 ✍️: 감지된 이벤트 정보는 커널과 사용자 공간 사이의 초고속 통로인 eBPF Perf Ring Buffer에 차곡차곡 쌓입니다.
3. 데이터 가공 🍳: 각 노드에 배치된 Hubble Agent는 이 버퍼에서 데이터를 꺼내와요. 그리고 그냥 날것의 데이터가 아닌, 파드 이름이나 레이블 같은 쿠버네티스 정보를 덧붙여 "누가 누구와 통신했고, 정책에 따라 허용됐는지 차단됐는지"와 같은 의미 있는 정보(Flow 객체)로 재탄생시킵니다.
4. 로컬 서버 오픈 📡: 마지막으로, Agent는 가공된 데이터를 자신의 로컬 gRPC 서버를 통해 제공할 준비를 마칩니다. 즉, 모든 노드는 각자의 실시간 통신 기록을 스트리밍하고 있는 셈이죠.

핵심 포인트: Agent는 모든 데이터 수집의 시작점이며, DaemonSet으로 배포되어 모든 노드를 커버합니다.

2. Hubble Relay (📡 중앙 관제소)

• 배포 형태: Deployment (클러스터에 보통 하나만!)
• 임무: 흩어져 있는 모든 현장 요원(Agent)들의 보고를 한데 모아 정리하고, 최종 사용자에게 전달하는 중앙 관제소 역할을 합니다.

만약 클러스터에 수백 개의 노드가 있다면, 우리가 통신 정보를 보기 위해 수백 개의 Agent에 일일이 접속해야 할까요? 🤯 생각만 해도 끔찍하죠. 바로 이 문제를 해결하는 것이 Relay입니다.

1. 요원들 찾아내기 🗺️: Relay는 쿠버네티스 API를 통해 클러스터 내의 모든 Hubble Agent들을 자동으로 찾아냅니다.
2. 보고 취합하기 📊: 찾아낸 모든 Agent들의 gRPC 서버에 접속해서, 각 노드에서 스트리밍되는 데이터를 실시간으로 빨아들여 하나로 합칩니다.
3. 단일 창구 제공 🚪: 이렇게 취합된 클러스터 전체의 통신 데이터를 자신의 gRPC 서버를 통해 단 하나의 창구로 제공합니다.

핵심 포인트: Relay는 분산된 데이터를 중앙에서 집계하여 사용자가 한 곳에서 클러스터 전체 상황을 볼 수 있게 해주는 고마운 존재입니다.

3. Hubble UI & CLI (💻 지휘 본부)

• 배포 형태: UI (Deployment & Service), CLI (로컬에 설치)
• 임무: 우리가 Relay가 제공하는 데이터를 눈으로 보고, 명령을 내릴 수 있게 해주는 인터페이스입니다.

1. Hubble UI (시각적 대시보드) ✨:
   • 웹 브라우저를 통해 접속하며, 클러스터의 모든 서비스와 통신 흐름을 한눈에 볼 수 있는 서비스 맵(Service Map)을 제공합니다.
   • 어떤 파드에서 통신이 막혔다면? 서비스 맵에 붉은색 선으로 표시되고, 클릭 몇 번으로 왜 차단되었는지(Policy denied) 이유까지 상세히 알 수 있습니다. 디버깅 시간이 획기적으로 줄어들죠!
2. Hubble CLI (터미널 명령어) ⌨️:
   • hubble observe 같은 명령어로 터미널에서 실시간 통신 흐름을 텍스트로 확인할 수 있습니다.
   • --verdict DROPPED (차단된 통신만 보기), --to-port 80 (80번 포트로 가는 통신만 보기) 등 강력한 필터링 기능으로 원하는 정보만 콕 집어 볼 수 있어 자동화 스크립트 등에도 유용합니다.

핵심 포인트: UI와 CLI는 Hubble Relay에 접속하여, 복잡한 네트워크 데이터를 우리가 이해하기 쉬운 형태로 보여주는 최종 관문입니다.

---

데이터는 어떻게 우리 눈앞까지 오는 걸까? 🗺️

하나의 네트워크 패킷이 우리 눈에 보이기까지의 여정을 따라가 봅시다.

1. [커널] 📦 파드 A가 파드 B에게 패킷을 보냅니다.
2. [eBPF] 🕵️‍♂️ 커널에 심어진 Cilium의 eBPF 프로그램이 패킷을 가로채고, 출발지/목적지 정보, 정책 위반 여부 등을 기록합니다.
3. [Perf Buffer] 📝 이 정보는 커널의 eBPF Perf Ring Buffer에 저장됩니다.
4. [Hubble Agent] 👨‍💻 노드의 Hubble Agent가 버퍼에서 데이터를 꺼내 쿠버네티스 정보를 덧붙여 의미 있는 Flow 데이터로 만듭니다.
5. [Hubble Relay] 📡 Relay가 클러스터의 모든 Agent로부터 Flow 데이터를 수집하여 하나로 합칩니다.
6. [Hubble UI/CLI] 🖥️ 사용자가 UI를 켜거나 CLI 명령을 실행하면, Relay에 연결하여 통합된 데이터를 받아 화면에 예쁘게 표시해 줍니다.

이 흐름을 이해하면, Hubble의 각 부분이 왜 필요하고 어떻게 함께 작동하는지 명확하게 그림을 그릴 수 있습니다.

---

그래서 이걸 알면 뭐가 좋은데? (핵심 요약) 💡

Hubble 아키텍처를 이해하는 것은 단순히 지식을 쌓는 것을 넘어, 실제 문제 해결 능력을 비약적으로 향상시킵니다.

• Agent는 DaemonSet vs Relay는 Deployment: 왜 이렇게 배포되는지 이제 설명할 수 있습니다. 데이터는 모든 노드에서 수집해야 하고(DaemonSet), 집계는 중앙에서 한 번만 하면 되니까요(Deployment).
• 데이터의 원천은 eBPF Perf Ring Buffer: Hubble이 보여주는 모든 정보의 뿌리는 커널 레벨의 eBPF입니다. 이것이 Hubble 데이터가 신뢰성 높은 이유죠.
• Relay의 존재 이유: 확장성과 단일 접근점! Relay 덕분에 수천 개 노드가 있는 대규모 클러스터에서도 효율적으로 전체 상황을 모니터링할 수 있습니다.
• Hubble로 알 수 있는 것들:
  • 단순 IP, 포트 정보 (L3/L4)
  • HTTP 경로, Kafka 토픽 등 애플리케이션 레벨 정보 (L7)
  • DNS 쿼리 정보
  • 가장 중요한 것: 네트워크 정책 판결 결과 (ALLOWED / DROPPED) 👈 문제 해결의 결정적 단서!

이제 쿠버네티스에서 네트워크 문제가 발생하면 더 이상 추측에 의존하지 마세요. Hubble을 열고, 데이터의 흐름을 따라가며 명확한 근거를 바탕으로 문제를 해결하는 전문가가 되어보세요!

---