Kubernetes Monitoring概要

Kubernetesは、現代の運用チームがアプリケーションをデプロイし、スケーリングする方法を変革しました。Kubernetesによって本番環境でのコンテナ利用は大幅に簡素化されましたが、システムの状態を把握するための堅牢な監視システムの必要性がなくなったわけではありません。

Kubernetes監視は、パフォーマンスメトリクスの追跡、デプロイ環境への変更の監査、アプリケーションクラッシュのデバッグに役立つログの取得を行うために不可欠です。監視ソリューションなしでのKubernetesのトラブルシューティングは、退屈でエラーが発生しやすく、問題が見過ごされて深刻化する原因となります。

ここでは、Kubernetesクラスター監視の基礎を解説し、Kubernetesメトリクスを収集する主要なポイントを特定することで、ワークロードの可視性を最大化する方法を説明します。これにより、システムライフサイクルにおけるエラーの早期検出が可能になります。

Kubernetesを監視すべき5つの理由

本番環境のアプリケーションは、エラーの検出、リソース使用量の最適化、コスト管理のために監視する必要があります。Kubernetesも例外ではありません。監視の有無は、多くの場合、効果的なクラスターとなるか、十分に活用されずパフォーマンスの低いクラスターとなるかの分かれ目となります。

1. リアルタイムアラートとエラーの早期検出

Kubernetesクラスターをプロアクティブに監視することで、ユーザーに影響が及ぶ前にエラーを早期に検出できます。ログファイル、トレース、パフォーマンスメトリクスは、クラスター内で何が起きているかの可視性を提供し、使用量のスパイクやエラー率の増加を事前に警告します。リアルタイムアラートにより、問題が発生した瞬間に通知を受け取ることができるため、ユーザーが最初に問題を発見した際に生じる信頼を損なう事態を回避できます。これによりサービスの復旧時間が短縮され、ブランドの評判を守ることができます。

2. ワークロード管理と最適化の向上

包括的な監視は、ワークロード管理の改善とリソースのより最適な利用を促進します。Kubernetesクラスターを監視することで、リソースの競合が多すぎることや、ノード間でのアプリケーションPodの分布が不均等であることなどが明らかになる場合があります。アフィニティやアンチアフィニティの設定といった単純なスケジューリングの調整で、パフォーマンスと信頼性を大幅に向上させることができますが、実際のクラスター使用状況に関するインサイトがなければ、こうした機会を逃してしまいます。

3. トラブルシューティングの容易化

監視は、問題のトラブルシューティングを行う際の助けとなります。アプリケーションやKubernetesコンポーネントのログへのアクセスは、多くの場合、再現手順を発見し、根本原因の究明に向けた作業を行うための最良の方法です。監視ソリューションがなければ、問題の原因と思われるものを仮説立て、試行錯誤で修正をテストしなければなりません。これは開発者、特にシステムに慣れていない新規メンバーの作業負荷を増大させます。問題を早期に特定できることで、ダウンタイムを最小限に抑え、全員が貢献しやすい環境を作ることができます。

4. コストのリアルタイム可視化

Kubernetesの請求ショック（bill shock）は現実に起こり得ます。オートスケーリングアーキテクチャにより、変化する需要にリアルタイムで適応できますが、これはコストの急増を招く可能性もあります。現在クラウドアカウントにデプロイされているノード、ロードバランサー、永続ボリューム（Persistent Volumes）の数を確認するためには、監視が不可欠です。これらのオブジェクトのそれぞれに対して、通常、プロバイダーから個別のコストが発生します。

5. 強力なインサイト

Kubernetes監視は、サービスの強化につながる機会を浮き彫りにするユニークなインサイトをもたらします。単純なパフォーマンスメトリクスを超えて、監視はユーザーがアプリケーションとどのように対話しているかを明らかにし、将来の製品決定に役立てることができます。Ingressコントローラーなどのコンポーネントからのデータは、最も呼び出されているエンドポイントや、インフラストラクチャを流れるデータ量を明らかにします。この情報は、活発なエンゲージメントがあるために拡張が必要な機能や、発見しにくさが原因で利用率が低い機能を探す際の出発点となります。

Kubernetes監視：主要コンポーネント

Kubernetesクラスターは、コンテナ化されたワークロードをサポートするために連携して動作する多数の異なるコンポーネントで構成されています。日々の管理業務でこれらの一部に触れることはありますが、その他は舞台裏でオペレーションを調整しています。

基本的なKubernetesアーキテクチャでは、アプリケーションはPod内のコンテナとして実行されます。Podは、クラスター内の物理マシンを表す複数のノードに分散されます。ノードはコントロールプレーンによって調整されます。コントロールプレーンには、クラスターと対話するためのAPIサーバーや、いくつかのコントローラーが含まれています。コントローラーはクラスター内の変更を監視し、Podオブジェクトを追加した際にコンテナを起動するなど、新しい望ましい状態を実現するためのアクションを実行します。

Kubernetesクラスターの複雑さは、多面的な監視アプローチが常に必要であることを意味します。インフラストラクチャ全体のパフォーマンスを追跡するためには、以下の図にあるすべての項目を観測（オブザーブ）する必要があります:

次に、これらのコンポーネントの一部と、それらからメトリクスを収集する方法について確認していきましょう。

パフォーマンスメトリクス

パフォーマンス監視を行うことで、クラスターのキャパシティ問題を調査し、リソースを追加すべきタイミングを特定できます。収集されたメトリクスによってリソース消費の傾向を発見でき、ユーザーが気づくような遅延が発生する前に対処することが可能になります。

ノードリソース使用率メトリクス

CPUやメモリ消費量などのノードリソース使用率メトリクスは、いくつかのメカニズムを使用して取得できます。最も一般的なのは、各ノードでPrometheus Node Exporterなどのエージェントを実行することです。メトリクスエージェントは定期的にノードの現在のメトリクスをスクレイピング（収集）し、データをオブザーバビリティプラットフォームに送信します。

あるいは、クラスターにMetrics APIがインストールされている場合、Kubernetes自身がこのデータを収集できます。Metrics APIを使用すると、ターミナルでkubectl topコマンドを使用してノードメトリクスにアクセスできます。これにより、外部依存関係なしで便利なリソース監視が可能になります。

主要なクラウドプロバイダーからデプロイされたKubernetesクラスターには、通常、独自の監視ダッシュボードもあります。クラウドアカウントにログインして、自分で設定を行うことなく主要なメトリクスの基本的なグラフを表示できる場合があります。これは便利なクイックスタートオプションを提供しますが、必ずしも知るべきことすべてが表示されるわけではありません。

将来の使用量を予測し、需要に先立ってキャパシティを増強するためには、これらの基本的なハードウェア使用率メトリクスを定期的に監視することが不可欠です。CPUやメモリの消費量が日常的に高い状態は、サービスのパフォーマンスの余地を減少させます。これは、使用量のスパイクが発生した場合に、停止や不安定さにつながる可能性があります。

オブジェクトのキャパシティと健全性メトリクス

kube-state-metrics (KSM) サービスは、Kubernetes APIサーバーのイベントをリッスンし、クラスターのオブジェクトの状態を文書化したPrometheusメトリクスを公開します。1,000を超える異なるメトリクスにより、個々のコンテナ、Pod、Deployment、およびその他のリソースのステータス、キャパシティ、健全性が提供されます。

このインストルメンテーション（計装）を使用して、クラスター内のオブジェクトを詳細に調査できます。たとえば、Pod Metrics APIは、Podのステータス、最後の状態遷移からの経過時間、発生した再起動回数、適用されているリソース制限など、各Podに関する40以上の個別のデータポイントを提供します。個別のAPIは、他のすべてのKubernetes組み込みオブジェクトタイプに対しても利用可能です。

これらのメトリクスを監視することで、クラスターとアプリケーションの両方の問題を警告できます。再起動回数が多いPodは、クラスター内でリソースの競合があるか、アプリケーションにクラッシュを引き起こすバグがあることを示唆している可能性があります。KSMによって公開されるメトリクスは、Kubernetesコントロールプレーンによって収集された生の状態で提供されるため、前処理なしで処理および分析できます。

ストレージの健全性

Kube-state-metrics (KSM) は、ストレージの健全性の監視にも使用できます。これには、StorageClass、PersistentVolume、PersistentVolumeClaimのメトリクスを公開するAPIが含まれており、ボリュームの容量、現在利用可能かどうか、各クレームによって要求されたスペース量などを把握できます。

ストレージの健全性を確認するもう一つの方法は、Volume Health Monitoringシステムを使用することです。このアルファ機能はKubernetesに組み込まれており、永続ボリュームの全体的な健全性を記述するメトリクスを提供します。これには、ストレージに問題があることを示す異常なボリューム状態を監視する専用のコントローラーが含まれています。また、このコントローラーは、ボリュームにアクセスするPodが障害のあるノードにスケジュールされた場合に、ボリュームにイベントを設定します。これにより、ボリュームを要求したPodが実際に稼働しているかどうかを確認できます。

Kubeletメトリクス

Kubernetesノード上で実行されるKubeletプロセスは、Prometheusを使用してスクレイピングできる詳細なメトリクスを提供します。これらは、ポート10255の /metrics エンドポイント経由でアクセスされます。

まず、クラスター内でのノードのIPアドレスを確認します：

$ kubectl get nodes -o wide
NAME   	STATUS   ROLES              	AGE   VERSION   INTERNAL-IP	EXTERNAL-IP   OS-IMAGE         	KERNEL-VERSION  	CONTAINER-RUNTIME
minikube   Ready	control-plane,master   74d   v1.23.3   192.168.49.2   <none>    	Ubuntu 20.04.2 LTS   5.4.0-122-generic   docker://20.10.12

このノードのIPアドレスは 192.168.49.2 です。これで、ポート10255にアクセスしてメトリクスデータをクエリできます：

curl http://192.168.49.2:10255/metrics
# HELP apiserver_audit_event_total [ALPHA] Counter of audit events generated and sent to the audit backend.
# TYPE apiserver_audit_event_total counter
apiserver_audit_event_total 0
# HELP apiserver_audit_requests_rejected_total [ALPHA] Counter of apiserver requests rejected due to an error in audit logging backend.
# TYPE apiserver_audit_requests_rejected_total counter
apiserver_audit_requests_rejected_total 0
# HELP apiserver_client_certificate_expiration_seconds [ALPHA] Distribution of the remaining lifetime on the certificate used to authenticate a request.
# TYPE apiserver_client_certificate_expiration_seconds histogram
apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="3600"} 0
...

Kubeletメトリクスエンドポイントは、クラスター内でのノードのパフォーマンスを調査するために使用できます。このデータは、ワークキュー内のタスク数やAPIリクエストの処理にかかった時間など、KubeletとKubernetesコントロールプレーンとの相互作用に関連する統計情報を公開します。

Kubeletはまた、/metrics/cadvisor エンドポイントで cAdvisorメトリクス も提供します。cAdvisor (Container Advisor) は、コンテナのリソース使用量とパフォーマンス特性を分析するツールです。

curl http://192.168.49.2:10255/metrics/cadvisor
# HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision.
# TYPE cadvisor_version_info gauge
cadvisor_version_info{cadvisorRevision="",cadvisorVersion="",dockerVersion="",kernelVersion="5.4.0-122-generic",osVersion="Ubuntu 20.04.2 LTS"} 1
# HELP container_blkio_device_usage_total Blkio Device bytes usage
# TYPE container_blkio_device_usage_total counter
container_blkio_device_usage_total{container="",device="/dev/nvme0n1",id="/",image="",major="259",minor="0",name="",namespace="",operation="Async",pod=""} 0 1660656772812
container_blkio_device_usage_total{container="",device="/dev/nvme0n1",id="/",image="",major="259",minor="0",name="",namespace="",operation="Discard",pod=""} 0 1660656772812
container_blkio_device_usage_total{container="",device="/dev/nvme0n1",id="/",image="",major="259",minor="0",name="",namespace="",operation="Read",pod=""} 778240 1660656772812
...

これらのメトリクスは、コンテナレベルでのCPU、メモリ、ディスク、ネットワーク使用率の分析を容易にします。前述のクラスターレベルのメトリクスを使用して高負荷なノードを特定したら、そのノードのcAdvisor出力を使用して、リソースを過剰に使用し他のオブジェクトとの競合を引き起こしているコンテナを見つけることができます。高い使用率は、ユーザーアクティビティの増加（Podを増やしてサービスをスケーリングする必要性を示唆）や、負荷の上昇を引き起こしているコンテナ内の最適化不足に起因する可能性があります。

Kubernetesログ

パフォーマンスメトリクスやリソース使用率に加えて、将来参照できるようにKubernetesログをキャプチャし保持することも重要です。複数のKubernetesコンポーネントが、イベントやエラーをホストファイルシステム上のログファイルに直接書き込みます。以下に、検査すべき一般的なパスをいくつか示します。

Kubernetesコントロールプレーンノードでは、以下を確認してください：

/var/log/kube-apiserver.log: Kubernetes APIサーバー内で発生したイベントが含まれています。
/var/log/kube-scheduler.log: スケジューリングの決定記録です。KubernetesがPodをどのノードに配置するかを決定した際に作成されます。
/var/log/kube-controller-manager.log: Kubernetesコントローラーマネージャーからのログです。クラスター内のアクティビティを監視するすべての組み込みコントローラーの実行を担当します。

個々のワーカーノードでは、以下を確認してください：

/var/log/kubelet.log: kubeletプロセスは、ノードとKubernetesコントロールプレーンサーバー間の通信維持を担当します。ノードが利用できなくなった理由をトラブルシューティングする際は、このログファイルから始めるべきです。
/var/log/kube-proxy.log: kube-proxy プロセスのログが保存される場所です。kube-proxy プロセスは、サービスを経由してノード上のPodにトラフィックをルーティングする役割を担います。

PromtailやGrafana Agentなどのデータコレクターを使用して新しい行を監視プラットフォームに直接ストリーミングすることで、これらのログファイルにアクセスできます。これらのエージェントをノードにインストールすると、ログ収集が自動化されます。これにより、パフォーマンスメトリクスと並行してログを表示できるようになり、catやtailなどのUnixツールを使用してログにアクセスするために手動でノードに接続する手間がなくなります。

Promtailは、アプリケーションによって書き込まれるコンテナレベルのログにも対応しています。Kubernetesは、プロセスが標準出力および標準エラーストリームに書き込むデータからコンテナログを作成します。コンテナのファイルシステムに直接書き込まれたログは再起動時に破棄されるため、アプリケーションはこのメカニズムをサポートするように構成する必要があります。ファイルシステムへの直接書き込みは、ログに記録されたエラーメッセージやスタックトレースへのアクセスを失うことになるため、バグやクラッシュの調査をはるかに困難にする可能性があります。

エージェントを使用してコンテナログを収集し、監視プラットフォームに送信することで、その内容へのアクセス性が向上します。kubectl logsコマンドが提供する単純な時系列出力に頼るのではなく、ログ行を検索したりフィルタリングしたりできるようになります。Grafana Lokiなどのほとんどのログ集約ソリューションは、長期的なログアーカイブもサポートしているため、コンテナが再起動または置換された後でも問題を再検討できます。

トレース

トレーシングは、プログラムの実行中に発生するイベントに関する非常に詳細な情報を記録するロギングの一形態です。トレーシングとロギングの区別は曖昧な場合もありますが、生のトレースは冗長でノイズが多く、開発者が状況を正確に把握できるように設計されていると考えられます。トレースは多くの場合、イベントに至るまでのコードスタック層のシーケンスで構成されています。

対照的に、ログメッセージには通常、より人間中心の情報が含まれています。ログは何に至ったかを説明することなく、イベントが発生したことを文書化します。ログメッセージは「支払いの処理に失敗しました」のようなものかもしれません。対応するトレースには、アプリケーションのエントリーポイントから外部の決済プロバイダーを呼び出し、応答としてエラーを受け取るまでのコードのステップが表示されるはずです。

トレース内の個々の操作は、*スパン（Spans）*と呼ばれます。上記の例では、トレースはユーザーが支払いを開始してから結果が決定されるまでの操作全体です。トレース内には、以下のスパンが含まれる可能性があります：

カードの詳細やクーポンコードなど、ユーザー入力の検証。
ユーザーの買い物かごの内容の取得。
バックエンドの決済プロバイダーへのデータ送信。
取引結果の保存。
注文確認メールの送信。

スパンには通常、直近の親、所要時間（Duration）、実行された操作など、独自のメタデータが関連付けられています。この区別により、個々のイベントの特定部分にドリルダウンし、問題の検索範囲を絞り込むことができます。

リクエストが通ったコードパスを確認できる機能は、ユーザーから報告された問題をデバッグする際に非常に貴重です。すべての問題が開発環境で簡単に再現できるわけではありません。トレースを使用すると、ユーザーのセッション中に何が起こったかを正確に確認できるため、問題解決がより効率的になります。トレースがなければ、バグが発生する前にどのような手順を踏んだかをユーザーに確認する必要があります。これは常に可能とは限らず、必ずしも再現の成功につながるとは限りません。トレースは必要なすべてのデータを提供するため、すぐに修復に取り掛かることができます。

Kubernetesには組み込みのトレーシング機能もあります。いくつかのシステムコンポーネントがトレースを公開しており、クラスターの内部動作をより深く理解し、パフォーマンスを測定できます。統合されたクラスターレベルのトレーシングは、すべてのアプリケーションに影響を与えている一般的な問題を診断する際に役立ちますが、コードの実行を正確に分析する場合は、アプリケーションレベルでのユーザーによるトレーシングの実装がより効果的です。

Kubernetesイベント

Kubernetesは、クラスター内で発生するすべてのイベントの包括的な履歴を保持しています。kubectlを使用してターミナルでイベントを表示できます：

$ kubectl get events
LAST SEEN 	TYPE  	REASON  	OBJECT       	MESSAGE
1m    		   Normal	Created 	pod/demo-pod 	Created container demo-pod
1m        	Normal	Started 	pod/demo-pod 	Started container demo-pod

各イベントには、参照するオブジェクトの名前、発生したアクション、オブジェクトの状態（「Normal」や「Failed」など）、および何が起こったかを簡単に説明するメッセージが含まれています。これにより、Kubernetesコントロールプレーンによって生成されたイベントや、ユーザーのアクションに応じて生成されたイベントを含む、クラスター内のアクティビティの包括的な履歴が提供されます。

--field-selector フラグを使用してフィルタリングすることで、特定のオブジェクトに関連するイベントを取得できます。この例では、イベントオブジェクトの involvedObject.kind フィールドと involvedObject.name フィールドを一致させることで、demo-pod Podのイベントを取得します：

$ kubectl get events \
    --field-selector involvedObject.kind=Pod \
    --field-selector involvedObject.name=demo-pod
LAST SEEN 	TYPE  	REASON  	OBJECT       	MESSAGE
1m    		   Normal	Created 	pod/demo-pod 	Created container demo-pod
1m        	Normal	Started 	pod/demo-pod 	Started container demo-pod

この例を変更して、involvedObject.kind フィールドを Deployment、ReplicaSet、Job など、探しているオブジェクトタイプの名前に置き換えることで、他のオブジェクトをサポートするようにできます。

イベントは、特定の問題に至るまでのアクションのシーケンスを理解する上で非常に貴重です。コンテナの作成成功から、ジョブの失敗、イメージのプルエラー、メモリ不足の状態まで、オブジェクトに関連する事実上すべてのアクションがリストに表示されます。

Kubernetesはイベントを一時的な記録として扱い、発生後すぐに自動的にクリーンアップします。ほとんどの場合、イベントはわずか1時間後に削除されます。エージェントベースのデータコレクターを使用して、Grafanaなどのオブザーバビリティソリューションにイベントをストリーミングする必要があります。これにより、イベントが発生してから長時間経過した後でもイベントを検索、検索、アーカイブできるようになり、将来の問題をトラブルシューティングする際のもう一つの参照ポイントが提供されます。

コンテナ化されたアプリケーションのメトリクス

クラスターの健全性とともに、コンテナ化されたワークロードを監視することが重要です。Prometheus互換データをエクスポートする独自のアプリ内メトリクスAPIを作成することで、オブザーバビリティソリューションを使用してパフォーマンス統計をスクレイピングできます。

Prometheusには、Go、Java/Scala、Python、Ruby、Rust用の公式クライアントサイドライブラリがあります。他のほとんどの人気言語についても、コミュニティがサポートするオプションが利用可能です。これらのライブラリを使用すると、アプリケーションインスタンス上のHTTPエンドポイントを使用して、カスタムアプリケーションメトリクスを定義し公開できます。

例として、ログイン処理や支払い取引の完了など、特定のビジネス機能を実行するのにかかる時間を追跡したい場合があります。Prometheusは、これらの所要時間（Duration）を測定し、スクレイピング可能なメトリクスとして公開することを簡素化し、記述が必要なコード量を最小限に抑えます。

ワークロードにインストルメンテーションを行う時間を取ることで、アプリケーションレベルでパフォーマンスを分析できるようになり、オブザーバビリティが強化されます。ユーザーにとって最も重要なのは、絶対的なCPU消費量やクラスター使用率ではなく、最終的にはアプリケーション機能の処理にかかる時間です。ビジネス固有の測定値の傾向を追跡することで、ユーザーエクスペリエンスを向上させる機会が見つかり、ノードレベルやクラスターレベルの問題になる前に、新たなパフォーマンスの問題を発見できます。

まとめ

Kubernetesは従来のデプロイメントソリューションよりも多くの可動部分を持っており、監視とオブザーバビリティに対する新しいアプローチが必要です。基本的なロギング、アプリケーションの健全性、リソース使用率メトリクスに加えて、Kubernetesコントロールプレーン内の個々のコンポーネントのパフォーマンスも評価する必要があります。

この記事では、包括的なKubernetes監視ソリューションを作成する際に考慮すべきコンポーネントについて見てきました。上記に挙げた分野に焦点を当てることで、クラスターとそのワークロードの内部動作を明らかにするインサイトが得られます。新たな問題を早期に特定できるだけでなく、クラスターの使用方法を改善・強化する新しい機会も見つけることができるでしょう。

Grafana CloudでKubernetes Monitoringを始める
新しい変更を展開するアプリケーション開発者であれ、インフラストラクチャのインシデントをトラブルシューティングするより良い方法を探しているSREであれ、クラスターを実行するベアメタルサーバーを保守するDevOps管理者であれ、Grafana Labsがお手伝いします。Kubernetes Monitoringは、Kubernetesインフラストラクチャのメトリクス、ログ、Kubernetesイベントへのすぐに使えるアクセスに加え、構築済みのダッシュボードやアラートを備えた、あらゆるレベルのKubernetes利用に対応する完全なソリューションです。Kubernetes Monitoringは、充実した永年無料枠を含む、すべてのGrafana Cloudユーザーが利用可能です。

このページ内

さらに表示するにはスクロール

Kubernetes Monitoringを始めましょう

Grafana Cloudを始める