Kubernetes クラスタ向けのログ可視化ツール、Kubernetes History Inspector のご紹介

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

コンテナ オーケストレーション プラットフォームである Kubernetes は、本質的に複雑な分散システムです。レジリエンスとスケーラビリティを実現する一方で、特にトラブルシューティングの際には、運用が複雑になる場合もあります。Kubernetes には自己修復機能が備わっていますが、問題の根本原因を特定するには、多くの場合、さまざまな独立したコンポーネントのログを詳しく調べる必要があります。

Google Cloud のエンジニアは、大規模で複雑な運用をサポートするなかで、長年にわたりこの Kubernetes のトラブルシューティングの課題に直接取り組んできました。膨大な数のカスタマー サポート チケットを定期的に分析し、ユーザー環境を掘り下げ、集合的な知識を活用して問題の根本原因を特定していくにつれ、Google Cloud サポートチームは Kubernetes 環境内の問題の診断に関する深い専門知識を持つようになりました。この広範な課題に対処するために、チームは Kubernetes History Inspector（KHI）というツールを内製開発し、このたびコミュニティ向けにオープンソースとしてリリースしました。

Kubernetes のトラブルシューティングの課題

Kubernetes では、各 Pod、Deployment、Service、ノード、コントロール プレーン コンポーネントが独自のログストリームを生成します。効果的なトラブルシューティングのためには、これらの異なるログストリームを収集し、関連付けて、分析する必要があります。しかし、コンポーネントごとにログを手動で構成するには、細部に注意を払い、Kubernetes エコシステムを十分に理解する必要があり、これは大きな負担になり得ます。幸い、Google Kubernetes Engine（GKE）などのマネージド Kubernetes サービスでは、ログの収集が簡素化されています。たとえば、GKE は Cloud Logging との組み込みのインテグレーションにより、Kubernetes 環境のあらゆる部分からのログを集約します。この一元化されたリポジトリは、重要な第一歩です。

ただし、ログを収集するだけでは、問題の半分しか解決できません。本当に重要な課題は、それらを効果的に分析することです。Kubernetes の運用で発生する問題の多くは、単一の明確なエラー メッセージで明らかになるわけではありません。問題は実際には一連のイベントとして現れるため、複数のコンポーネントにわたり多数のログエントリ間の因果関係を深く理解することが必要となります。

規模を考えてみてください。中規模の Kubernetes クラスタなら、ログデータは短時間ですぐに数ギガバイトに達し、そこには数万件の個別エントリが含まれます。パフォーマンスの低下、断続的な障害、構成エラーの根本原因を特定するために、この量のデータを手作業で精査するとなると、時間がかかるのはもちろんのこと、人間のオペレーターでは事実上不可能な場合もあります。シグナル対ノイズ比がこれを非常に困難にします。

Kubernetes History Inspector のご紹介

KHI は、Cloud Logging によって収集されたログを分析し、各コンポーネントの状態情報を抽出して、時系列で可視化する強力なツールです。また、このタイムラインは元のログデータにリンクされるため、各要素が時間の経過とともにどのように変化したかを追跡できます。

多くの場合、Google Cloud サポートチームがユーザーを支援するのは、時間的制約のある重大な状況のときです。長時間のセットアップやエージェントのインストールを必要とするツールは実用的ではありません。そのため、KHI はコンテナ イメージとしてパッケージ化されています。事前のセットアップは不要で、1 つのコマンドで起動できます。

わかりやすいように、画像を使って説明します。GKE クラスタで実行されているサービスで「接続タイムアウト」エラーが発生しているとエンドユーザーから報告があったとします。KHI を起動すると、次のような画面が表示されます。

まず、左側にあるカラフルな横長の長方形に注目してください。これは、ログから抽出された、個々のコンポーネントの状態が時間の経過とともに変化する様子を表した「タイムライン」です。このタイムラインは、Kubernetes 環境の全体像を示しています。一方、インターフェースの右側には、タイムラインで選択したコンポーネントに関連する詳細（元のログ、マニフェスト、その変更履歴）が表示されます。このように KHI では、マクロとミクロの両方の視点から、ログを簡単に探索できます。

それでは、前述の例に戻りましょう。タイムラインの「Ready」の行には、緑とオレンジのセクションが交互に並んでいます。

これは、readiness プローブが失敗（オレンジ）と成功（緑）の間を変動していることを示しています。これが動かぬ証拠となります。これで、トラブルシューティングの取り組みをどこに集中させるべきかが明確になりました。

KHI は、過去の任意の時点でのコンポーネント間の関係を可視化することにも優れています。Kubernetes クラスタ内の複雑な相互依存関係が、わかりやすい方法で提示されます。

KHI と Kubernetes のトラブルシューティングの今後

KHI の機能は、ここで紹介した以外にもたくさんあります。タイムラインの色の実際の仕組み、小さなひし形のマーカーの意味、トラブルシューティングを迅速に行うためのその他の機能などです。これを誰もが利用できるようにするため、KHI をオープンソース化しました。

詳細な仕様、視覚的要素の詳細な説明、独自のマネージド Kubernetes クラスタに KHI をデプロイする方法については、KHI の GitHub ページをご覧ください。現在、KHI は GKE または Google Cloud 上の Kubernetes と Cloud Logging の組み合わせでのみ機能しますが、その機能はまもなく標準のオープンソース Kubernetes の設定に拡張される予定です。

KHI は Kubernetes のログ分析を大きく前進させるものですが、既存の専門知識に取って代わるものではなく、それを補完することを目的としています。効果的なトラブルシューティングのためには、今後も Kubernetes のコンセプトとアプリケーション アーキテクチャの確固たる理解が必要です。KHI は、ログから問題をより迅速かつ効率的に診断できる優れたマップを提供することで、エンジニアの皆様が複雑な状況を乗り越えられるよう支援します。

KHI は、Kubernetes の運用の簡素化に向けた Google の継続的な取り組みの第一歩にすぎません。コンテナ化されたアプリケーションのオブザーバビリティと管理性を高めるために、コミュニティが KHI をどのように使用し、拡張していくのか、楽しみにしています。Kubernetes のトラブルシューティングを簡素化するための取り組みは今後も続きます。皆様もぜひご参加ください。

-テクニカル ソリューション エンジニア Kakeru Ishii
-テクニカル ソリューション エンジニア Takeie Torinomi