Kubernetesにおいて、可観測性(オブザーバビリティ)とは、メトリクス、ログ、トレース(しばしば可観測性の3本柱と呼ばれる)を収集・分析し、クラスターの内部状態、パフォーマンス、健全性をより深く理解するプロセスです。
Kubernetesコントロールプレーンコンポーネントや多くのアドオンは、これらのシグナルを生成・出力します。 これらを集約・相関付けることで、クラスター全体のコントロールプレーン、アドオン、アプリケーションの統合された全体像を得ることができます。
図1は、クラスターコンポーネントが、3つの主要なシグナルタイプをどのように出力するかを示しています。
図1. クラスターコンポーネントによって出力される高レベルなシグナルとそのコンシューマー。
Kubernetesコンポーネントは、/metricsエンドポイントからPrometheus形式でメトリクスを出力します。
以下が含まれます:
kubeletは、/metrics/cadvisor、/metrics/resource、/metrics/probesでもメトリクスを公開します。
また、kube-state-metricsなどのアドオンは、Kubernetesオブジェクトのステータスを追加して、これらのコントロールプレーンシグナルを充実させます。
一般的なKubernetesメトリクスパイプラインは、これらのエンドポイントを定期的にスクレイピングし、サンプルを時系列データベースに保存します(例: Prometheus)
詳細や設定オプションについては、システムメトリクスガイドを参照してください。
図2は、一般的なKubernetesメトリクスパイプラインを示しています。
図2. 一般的なKubernetesメトリクスパイプラインのコンポーネント。
マルチクラスターやマルチクラウドで可視性を高めるには、分散時系列データベース(例: ThanosやCortex)とPrometheusを組み合わせて使用することができます。
メトリクススクレイパーや時系列データベースについては、一般的な可観測性ツール - メトリクスツールを参照してください。
ログは、アプリケーション内、Kubernetesシステムコンポーネント内、および監査ログなどのセキュリティに関連するアクティビティのイベントを時系列で記録します。
コンテナランタイムは、コンテナ化されたアプリケーションの標準出力(stdout)および標準エラー出力(stderr)ストリームからの出力をキャプチャします。
ランタイムごとに実装方法は異なりますが、kubeletとの統合は CRIログ形式 を通じて標準化されており、kubeletはこれらのログをkubectl logsで取得できるようにします。

図3a. ノードレベルのログ記録アーキテクチャ。
システムコンポーネントログは、クラスターからのイベントをキャプチャし、デバッグやトラブルシューティングに役立つことがよくあります。
これらのコンポーネントは、コンテナ内で実行されるものと実行されないものの2つに分類されます。
例えば、kube-schedulerやkube-proxyは通常コンテナ内で実行されますが、kubeletやコンテナランタイムはホスト上で直接実行されます。
systemdを使用するマシンでは、kubeletとコンテナランタイムはjournaldに書き込みます。
それ以外の場合は、/var/logディレクトリの.logファイルに書き込みます。/var/logの.logファイルに書き込みます。/var/log配下に保存されるシステムコンポーネントのログやコンテナのログは、無制限に増大しないようにログローテーションが必要です。
一部のクラスタープロビジョニングスクリプトは、デフォルトでログローテーションを設定します。
自身の環境を確認し、必要に応じて調整してください。
ログファイルの保存場所、形式、設定オプションの詳細については、システムログリファレンスを参照してください。
ほとんどのクラスターは、これらのファイルをtailして中央ログストアにエントリを転送するノードレベルのログエージェント(例: Fluent BitまたはFluentd)を実行しています。 ログアーキテクチャガイダンスでは、このようなパイプラインの設計、保持の適用、バックエンドへのログフローについて説明しています。
図3は、一般的なログ集約パイプラインを示しています。
図3. 一般的なKubernetesログパイプラインのコンポーネント。
ログエージェントと中央ログストアについては、一般的な可観測性ツール - ログツールを参照してください。
トレースは、リクエストがKubernetesコンポーネントとアプリケーション間をどのように移動するかをキャプチャし、レイテンシー、タイミング、処理間の関係を結び付けます。 トレースを収集することで、エンドツーエンドのリクエストフローを可視化し、パフォーマンスの問題を診断し、コントロールプレーン、アドオン、またはアプリケーションのボトルネックや予期しない動作を特定できます。
Kubernetes 1.35は、組み込みのgRPCエクスポーターを介して直接、またはOpenTelemetry Collectorを通じて転送することで、OpenTelemetry Protocol(OTLP)経由でスパンをエクスポートできます。
OpenTelemetry Collectorは、コンポーネントやアプリケーションからスパンを受信し、それらを処理(例: サンプリングやリダクションの適用)して、保存と分析のためにトレーシングバックエンドに転送します。
図4は、一般的な分散トレーシングパイプラインを示しています。
図4. 一般的なKubernetesトレースパイプラインのコンポーネント。
トレーシングコレクターとバックエンドについては、一般的な可観測性ツール - トレーシングツールを参照してください。
注意: このセクションは、Kubernetesが必要とする可観測性機能を提供するサードパーティプロジェクトにリンクしています。 Kubernetesプロジェクトのメンテナーは、アルファベット順にリストされているこれらのプロジェクトに対して責任を負いません。 このリストにプロジェクトを追加するには、変更を提出する前にコンテンツガイドを読んでください。
このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、CNCFウェブサイトのガイドラインをご覧ください。第三者のリンクを追加するような変更を提案する前に、コンテンツガイドを読むべきです。