Kubernetes環境でサービスを運用していると、「設定は間違いなく合っているのに、なぜこのPodからあのPodへ通信できないのだろう？🤔」といった不可解な状況に遭遇することがよくあります。ログを調べたり、`describe`コマンドを実行しても、原因が明確に見えないことが多いでしょう。
このような厄介なネットワーク問題を解決してくれる探偵が、まさにCilium Hubbleです。HubbleはeBPF技術を利用して、Kubernetesクラスター内部のすべての通信を透過的に覗き見ることができる魔法のような能力を私たちに与えてくれます。
この記事では、Hubbleがどのように動作するのか、その構造を徹底的に掘り下げていきます。このアーキテクチャさえきちんと理解すれば、今後ネットワーク問題に直面しても慌てることはなくなるでしょう！
Hubbleアベンジャーズ：3人の主要プレイヤー 🦸♂️
Hubbleは単独で動作しません。まるでアベンジャーズチームのように、それぞれ明確な役割を持つ3つの主要コンポーネントが有機的に連携して動作します。
(出典: Cilium.io)
1. Hubble Agent (🕵️ 現場エージェント)
- デプロイ形態: DaemonSet (クラスターのすべてのノードに1つずつ！)
- 任務: 各ノードで発生するすべてのネットワーク活動をリアルタイムで監視し、収集する最前線のエージェントです。
Agentはどのようにしてすべてを知ることができるのでしょうか？その秘密はまさにeBPFにあります。
- データ検出 🔍: Ciliumはカーネルの深部でeBPFを利用し、すべてのネットワークパケット（L3/L4情報、L7 HTTPリクエスト、DNSクエリなど）を密かに監視します。
- バッファに記録 ✍️: 検出されたイベント情報は、カーネルとユーザー空間間の超高速通路であるeBPF Perf Ring Bufferに次々と蓄積されます。
- データ加工 🍳: 各ノードに配置されたHubble Agentは、このバッファからデータを取り出します。そして、生のデータではなく、Pod名やラベルのようなKubernetes情報を付加し、「誰が誰と通信し、ポリシーによって許可されたのかブロックされたのか」といった意味のある情報（Flowオブジェクト）として再構築します。
- ローカルサーバーオープン 📡: 最後に、Agentは加工されたデータを自身のローカルgRPCサーバーを通じて提供する準備を整えます。つまり、すべてのノードがそれぞれのリアルタイム通信記録をストリーミングしていることになります。
> 重要ポイント: Agentはすべてのデータ収集の開始点であり、DaemonSetとしてデプロイされ、すべてのノードをカバーします。
2. Hubble Relay (📡 中央管制室)
- デプロイ形態: Deployment (クラスターに通常1つだけ！)
- 任務: 散らばっているすべての現場エージェント（Agent）からの報告をまとめ、整理し、最終ユーザーに伝える中央管制室の役割を果たします。
もしクラスターに数百のノードがあったら、通信情報を見るために数百のAgentにいちいち接続しなければならないのでしょうか？🤯 考えるだけでも恐ろしいですね。まさにこの問題を解決するのがRelayです。
- エージェントの発見 🗺️: RelayはKubernetes APIを通じて、クラスター内のすべてのHubble Agentを自動的に見つけ出します。
- 報告の集約 📊: 見つけ出したすべてのAgentのgRPCサーバーに接続し、各ノードからストリーミングされるデータをリアルタイムで吸い上げ、一つにまとめます。
- 単一窓口の提供 🚪: このように集約されたクラスター全体の通信データを、自身のgRPCサーバーを通じて単一の窓口として提供します。
> 重要ポイント: Relayは分散されたデータを中央で集計し、ユーザーが1箇所でクラスター全体の状況を見ることができるようにしてくれる、ありがたい存在です。
3. Hubble UI & CLI (💻 指揮本部)
- デプロイ形態: UI (Deployment & Service), CLI (ローカルにインストール)
- 任務: Relayが提供するデータを視覚的に確認し、コマンドを発行できるようにするインターフェースです。
- Hubble UI (視覚的ダッシュボード) ✨:
- ウェブブラウザを通じてアクセスし、クラスターのすべてのサービスと通信フローを一目で確認できるサービスマップ(Service Map)を提供します。
- あるPodで通信がブロックされた場合？サービスマップに赤い線で表示され、数回のクリックでなぜブロックされたのか（Policy denied）という理由まで詳細に知ることができます。これによりデバッグ時間が画期的に短縮されます！
- Hubble CLI (ターミナルコマンド) ⌨️:
- `hubble observe`のようなコマンドで、ターミナルからリアルタイムの通信フローをテキストで確認できます。
- `–verdict DROPPED`（ブロックされた通信のみ表示）、`–to-port 80`（80番ポートへの通信のみ表示）など、強力なフィルタリング機能で必要な情報だけをピンポイントで確認できるため、自動化スクリプトなどにも有用です。
> 重要ポイント: UIとCLIはHubble Relayに接続し、複雑なネットワークデータを私たちが理解しやすい形で表示する最終的なゲートウェイです。
データはどのようにして私たちの目の前に届くのか？🗺️
一つのネットワークパケットが私たちの目に触れるまでの旅を追ってみましょう。
- [カーネル] 📦 Pod AがPod Bにパケットを送信します。
- [eBPF] 🕵️♂️ カーネルに埋め込まれたCiliumのeBPFプログラムがパケットを傍受し、送信元/宛先情報、ポリシー違反の有無などを記録します。
- [Perf Buffer] 📝 この情報はカーネルのeBPF Perf Ring Bufferに保存されます。
- [Hubble Agent] 👨💻 ノードのHubble Agentがバッファからデータを取り出し、Kubernetes情報を付加して意味のあるFlowデータを作成します。
- [Hubble Relay] 📡 RelayがクラスターのすべてのAgentからFlowデータを収集し、一つにまとめます。
- [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) 👈 問題解決の決定的な手がかり！
もうKubernetesでネットワーク問題が発生しても、推測に頼る必要はありません。Hubbleを開き、データの流れを追いながら、明確な根拠に基づいて問題を解決する専門家になりましょう！
コメントを残す