Cilium と GKE Dataplane V2 をお使いですか？オブザーバビリティには、ぜひ Hubble をお試しください

※この投稿は米国時間 2024 年 12 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes プラットフォーム エンジニアの方なら、これまで eBPF と それが Kubernetes ネットワーキングに対して及ぼしてきた革命的な影響に注目されてきたのではないでしょうか。eBPF を活用した人気のソリューションである Cilium を試し、Google Kubernetes Engine（GKE）がこの技術をどう活用しているのか疑問に思われたこともあるかもしれません。その過程で GKE Dataplane V2 に出会った方もいるのではないでしょうか。そして、eBPF が進む先には、強化されたオブザーバビリティがあることにお気づきであることは間違いないでしょう。

この記事では、GKE Dataplane V2 と一緒に利用できるツール、Hubble についてご紹介します。この強力なオブザーバビリティ ツールは、ネットワーク パケット フローに Kubernetes のコンテキストを追加することで可視性を高めています。

GKE Dataplane V2 のオブザーバビリティは Managed Hubble ソリューションを提供します。これには次の要素が含まれます。

• Hubble Relay: ポッドとノードに関するネットワーク テレメトリ データを収集するサービス

• Hubble CLI: クラスタ内のライブ トラフィック情報を提供するコマンドライン インターフェース ツール

Google Cloud コンソールまたは gcloud コマンドのいずれかを通じて、GKE で Dataplane V2 のオブザーバビリティを有効化すると、単一の Pod で動作する専用の hubble-relay のデプロイがトリガーされます。この Pod には、Hubble Relay と CLI コンポーネントの両方が専用のコンテナとして格納されています。そのため、この Pod を利用して分析用のネットワーク テレメトリ データやコマンドライン ツールに即座にアクセスできます。

Hubble UI は初期デプロイには含まれていませんが、追加することでオブザーバビリティ設定を簡単に強化することができます。このウェブベースのインターフェースは、Hubble Relay が収集したデータを視覚的かつインタラクティブに探索、分析する方法を提供し、トレンドの特定、異常の検出、問題のトラブルシューティングを容易にします。

Hubble の CLI と UI を自由に使って、これらのツールが Kubernetes 環境の効果的なトラブルシューティングにどのように役立つかを見ていきましょう。

始める前に

• Hubble CLI の操作に慣れておく必要があります（ドキュメントへのリンク）。

• Hubble UI のバイナリ ディストリビューションをデプロイする方法を把握しておいてください（ドキュメントへのリンク）。

環境の設定

ここでは、2 つの Pod を使用します。それぞれ別の　Namespace にデプロイされ、サービスとして公開されています。

シナリオ 1: シンプルなリクエストをトレースする

このシナリオでは、Pod とサービス間の基本的なやりとりを観察します。

1. リクエストを開始する: store-frontend Pod から backend-svc Service へ curl リクエストを実行します:

$ kubectl exec store-frontend -n fe -it -- curl “backend-svc.be.svc.cluster.local.”

2. Hubble で観察する: Hubble CLI を使ってトラフィックを確認します:

$ hubble observe --pod fe/store-frontend --follow

ヒント: Hubble のフィルタやフラグの一覧を見るには、hubble observe --help のコマンドを実行してください

Hubble はフロー全体をキャプチャします: まず、store-frontend Pod が kube-dns に Service の名前解決を問い合わせ、その後 store-backend Pod への TCP 接続が行われます。Hubble がパケットに Namespace と Pod の名前を追加しているのがわかると思います。この Kubernetes に特化した分析情報により、ネットワーク トラフィックの理解と分析が格段に容易になります。

シナリオ 2: DNS に問題が発生した場合

DNS サーバーが過負荷状態になるシナリオをシミュレートしてみましょう。クラスタに大量の DNS リクエストを送信するアプリケーションをデプロイし、kube-dns Pod に大きな負荷をかけます。その後、シナリオ 1 で行ったリクエストを再試行します。

Hubble CLI の出力で DNS リクエストと DNS レスポンスのタイムスタンプを確認すると、kube-dns が応答するまでに約 5 秒の遅延があることが明らかにわかります。これは、過負荷状態の DNS サーバーが与える影響を示しており、システムで観測された遅延の原因を説明しています。

DNS サーバーへの負荷をさらに強め、Service 名の解決ができず DNS リクエストが完全に失敗となる状況を作り出します。

$ kubectl exec -it store-frontend -n fe -- curl "backend-svc.be.svc.cluster.local."
curl: (6) Could not resolve host: backend-svc.be.svc.cluster.local.

この極端なシナリオでは、Hubble のドロップにより、DNS クエリに応答がなく、名前解決が完全に機能しなくなったことがわかります。

最後に、kube-dns Pod を停止させ、利用不可の状態にします。

Hubble のフローログを見ると、何が起きているのかが明確にわかります。store-frontend Pod が kube-dns Service に接続しようと試みますが、正常に動作している kube-dns Pod が存在しないため、リクエストが失敗しています。

Hubble CLI は単なるトラブルシューティング ツールではありません。最適化にも役立つ強力なツールです。たとえば、最初のシナリオを実行中に、1 つの curl コマンドから驚くほど多くの DNS リクエストが生成されているのに気づいたかと思います。

少し調べてみると、根本原因がわかります。Service 名に末尾のドットが欠けており、Pod の resolv.conf が ndots:5 で構成されています。この組み合わせが意味するのは、クエリが絶対的なものとして扱われず、代わりに resolv.conf にリストされている 5 つの検索ドメインすべてで展開されたということです。その結果、curl を 1 回呼び出すごとに 6 つの DNS リクエストが発生しました。

シナリオ 3: ネットワーク ポリシーの問題

新しい上り（内向き）NetworkPolicy に見落としがあったと仮定しましょう。月曜の朝にネットワーク ポリシーをいじると、そんなミスが起こることも珍しくありません。フロントエンド アプリケーションが誤って許可リストから漏れていました。

フロントエンド アプリケーションとバックエンド アプリケーション間の通信がハングし、タイムアウトします。フロントエンド エンジニアが急いで Hubble CLI で確認すると、Hubble はフロントエンド アプリケーションのトラフィックがネットワーク ポリシーによって拒否され、ドロップされていることを示しています。

幸いなことに、Hubble CLI では --type フラグを使ってイベントをタイプ別にフィルタできます。たとえば、--type policy-verdict は、ネットワーク ポリシーに関連するイベントのみを表示します。さらに、--verdict DROPPED を使用すれば、ポリシーによってトラフィックがドロップされたイベントだけに絞り込むことが可能です。

Hubble UI

Hubble CLI が強力であることは間違いありませんが、Hubble UI は補完的で同様に価値のある視点を提供します。また UI は、CLI の機能を複製するだけでなく、クラスタ内のネットワーク トラフィックのビジュアル マップを提供します。これにより、Pod と Service が内部で、また外部とどのように接続しているかを簡単に把握できます。また、Namespace やラベルなどのフィルタリング オプションを活用することで、特定のトラフィック フローを素早く分離し、潜在的な問題をトラブルシューティングできます。

Hubble で GKE Dataplane V2 の奥深さを探る

今回ご紹介したのは Hubble の入門的な内容ですが、その機能を理解するうえで重要な基礎となるものです。より高度なクエリやフィルタを作成すれば、特定のネットワークの問題についてより深い分析情報を得ることが可能です。Hubble について知り、そのアクセス方法を理解することは、Cilium ベースの Dataplane V2 クラスタを効果的に運用し、トラブルシューティングするための重要な第一歩です。Hubble の能力をさらに掘り下げていけば、GKE 環境におけるオブザーバビリティや最適化に関する能力を最大限に引き出すことができるでしょう。

ー Cloud テクニカル ソリューション スペシャリスト Ghadeer Shaaya

ー スタッフ テクニカル ソリューション エンジニア Ankita Ojha