Kubernetes 環境が常に低速に感じられます。かつてはパフォーマンス ベンチマークとサービス レベル アグリーメントを満たしていたアプリケーションが、今では対応に苦戦しており、運用コストは上昇し続けています。明確な指標がないため、根本原因を見つけるためにアプリケーション ログと依存関係を精査するしかありません。
現代のCloudOpsチームにとって、このシナリオはあまりにも馴染み深いものであり、コンテナ化されたアプリケーションが複雑になるにつれて、頻度が高まっています。この課題の核心は、 Kubernetes それ自体：本質的に動的なシステムであり、 ポッド , ノード , コンテナ 常に作成、拡張、破棄されています。このような環境では、1 つのポッドの障害でもアプリケーション全体の停止につながる可能性があります。
堅牢な監視は役立つだけでなく、Kubernetes エコシステム全体の可視性を維持するために不可欠です。これらの動的リソースをプロアクティブに管理することで、スムーズな運用が保証され、問題がユーザーに支障をきたす前に回避できます。
このガイドでは、ハイブリッド クラウド アプリケーションの健全性とパフォーマンスを維持する上での Kubernetes モニタリングの役割について学習します。
Kubernetes モニタリングの理解 Kubernetes モニタリングには、Kubernetes クラスター内で実行されているアプリケーションとインフラストラクチャの追跡と分析が含まれます。ログ、メトリック、イベントを使用してヘルスとパフォーマンスを監視し、潜在的な問題の特定、ワークロードの最適化、高可用性の維持に役立ちます。さらに、Kubernetes の展開は開発チーム全体に分散していることが多く、可視性が限られていると、次のような問題が発生する可能性があります。 雲が広がる インフラの非効率性。
コントロールプレーンとワーカーノード全体の主要な監視ポイントを示すKubernetesクラスターアーキテクチャの包括的なビュー。赤いインジケーターは、監視のためにメトリックが収集される重要な監視ポイントを表します。
Kubernetes デプロイメントを監視するための戦略 Kubernetesインフラストラクチャ内には、Kubernetes固有のコンポーネントを備えたマスターノードがあります。 スケジューラ および APIサーバー 、およびそれぞれのポッド、コンテナ、コンテナ化されたアプリケーションを持つワーカー ノードも含まれます。Kubernetes クラスターとそれがビジネス サービスに与える影響を明確に把握するには、Kubernetes クラスター、個々のポッド、アプリケーション固有のメトリックの監視など、あらゆるレベルでそのコンポーネントの健全性とパフォーマンスを追跡することが重要です。
インフラストラクチャ、ワークロード、およびアプリケーション監視の関係を示す Kubernetes メトリックの階層ビュー。カスケード効果 (赤い破線) は、あらゆるレベルの問題がシステム全体の健全性とパフォーマンスにどのように影響するかを示しています。
Kubernetes インフラストラクチャの各レイヤーを調べて、重要なメトリックとその理由を理解しましょう。
Kubernetes クラスターの監視 Kubernetes環境を効果的に理解するには、クラスタ全体の可観測性を獲得する必要があります。これは、次のことを意味します。 リソースメトリック クラスター内で何が使用されているか、ポッドなどの現在実行中の要素を識別し、Kubernetes環境内のコンポーネント（APIサーバー、スケジューラなど）の現在の状態を評価します。Kubernetesは自動的に これらのデータポイントを収集する そして、API を通じてそれらを公開します。
Kubernetes APIからメトリックとリソースデータを収集して分析するには、 Cloud Native Computing Foundation（CNCF） 次のような解決策を推奨します ロジックモニター エンビジョン LMエンビジョン クラスター内のポッドとして統合 Kubernetesを聴いている イベントストリーム 追加の監視エージェントは必要ありません。新しいリソースを自動的に検出し、運用データを集約し、包括的なダッシュボードを通じて実用的な洞察を提供します。これにより、リソース使用率メトリックの効果的な監視が可能になり、ノード、ポッド、アプリケーションを分析してクラスターのパフォーマンスを最適化するために必要な可視性が提供されます。
クラスター内のリソース使用率 CPU、メモリ、ネットワーク、ディスクの使用率メトリックは、Kubernetes クラスターの健全性を監視するための鍵となります。これらのメトリックは、リソースが効率的に使用されているかどうかを識別し、ワークロードに影響を与える可能性のある潜在的なボトルネックやパフォーマンスの問題を検出するのに役立ちます。これらのメトリックは、Kubernetes API への定期的なクエリを通じて自動的に検出および追跡できるため、監視が Kubernetes 環境の変化に適応できるようになります。
プロのヒント: リアルタイムの使用状況と時間の経過に伴う傾向の両方を監視して、パフォーマンスに影響する前に潜在的な容量の問題を特定します。
たとえば、クラスターのインフラストラクチャの可視性を維持するには、ノードの数とポッドのステータスを監視する必要があります。ダウンしたノードは容量の問題を示している可能性があり、ポッドの障害と再起動はアプリケーションまたはリソースの制約に問題があることを示している可能性があります。
追跡の可用性 Kubernetesコンポーネント、例えば APIサーバー は、クラスターとのすべての通信と Kubernetes 操作の中核を形成します。クラスターの API サーバーの健全性と可用性を監視すると、デバッグやクラスター内でのスムーズな実行に役立ちます。
クラスターレベルのメトリクス 以下は、クラスター内で確認すべき重要なデータ ポイントです。これらのメトリックは、大規模な Kubernetes の停止を事前に防止するのに役立ちます。
ノード CPU 使用率: CPU 使用率が高くなると、ノード上のすべてのポッドでスロットリングが発生し、パフォーマンスが低下する可能性があります。CPU 使用率に対して、警告しきい値を 70%、重大なしきい値を 85% など、特定のアラートしきい値を設定します。これにより、CPU の制約によって広範囲にわたる問題が発生する前に、効果的に介入することができます。 ノードメモリ使用率: メモリ不足により、ポッドの削除や OOM による強制終了が発生します。これらの問題を防ぐには、ノードの合計メモリの 80% (警告) と 90% (重大) でアラートを設定します。 ポッドのスケジュール失敗と保留中のポッド: クラスター容量の問題の指標です。リソースの制約や構成の問題が原因である可能性があります。5 分以内に 3 つのポッド、10 分以上にわたって 5 つのポッドなど、障害や保留中のポッドの急増を監視します。ノード割り当て可能リソースとリクエスト/制限の比率: この比率は、容量を最大化し、リソースの枯渇を回避するのに役立ちます。また、スケーラビリティのニーズを予測し、使用量の急増に対処するためにも使用できます。割り当て可能なリソースの約 20% のバッファーを維持するようにしてください。容量がこの値を下回った場合にアラートを設定します。 Kubelet 応答遅延: kubelet の応答が遅い場合は、ノードの健全性に問題があることを示しています。800 ミリ秒を超える遅延は、ノードがポッドの管理に苦労していることを示しており、ポッドのライフサイクル操作と健全性チェックに影響する可能性があります。etcd の健全性状態とリーダー選出率: etcd の問題は、クラスター全体を混乱させる可能性があります。リーダー選出の問題は、通常、etcd ネットワークまたはコンセンサスの問題を意味します。リーダー選出の発生を監視します。15 分以内に XNUMX 回以上発生する場合は警告サインです。API サーバーのレイテンシ: 200 ミリ秒を超えるレイテンシは、デプロイメント、スケーリング、および kubectl コマンドに影響します。また、コントロール プレーンの操作と応答性を妨げる可能性もあります。ノードの準備ができていないイベント: これらのイベントは、kubelet の問題、ネットワークの問題、またはポッドのスケジュールに影響するハードウェア障害を示している可能性があります。複数のノードで繰り返し発生するイベントはクラスター全体の問題を示している可能性があるため、イベントの期間を注意深く監視してください。 永続ボリューム要求の失敗: これらの障害は、ステートフル アプリケーションとデータの永続性に影響します。また、ポッドのスケジュール設定とアプリケーションの展開がブロックされる可能性もあります。操作に十分なバッファーを確保するために、ストレージ クラスに容量アラートを設定してください。
プロのヒント: クラスター全体の問題を防ぐために、これらのメトリックに適切なしきい値とアラートを設定します。
一般的なクラスター監視の設定により、クラスター全体およびインフラストラクチャ関連の問題に関する可視性のギャップに対処しました。次のステップでは、個々のポッドのより詳細なレベルと、それらの特定の監視要件を調べます。
個々のポッドの監視 クラスター レベルの監視では全体像を把握できますが、ポッド レベルの可観測性により、問題がアプリケーションに影響する前にそれを検出できます。
個々のポッド内では、ポッド自体がどのように機能しているか、およびポッド内での操作の実行状況を把握する必要があります。まずは、リソースの使用状況を追跡します。たとえば、CPU 使用率 (リクエストと制限の両方)、メモリ消費量、ストレージ メトリック (永続ボリュームが使用されている場合)、ネットワーク スループット (入力トラフィックと出力トラフィック) は、追跡する上で重要な要素です。ポッドの現在のステータス (実行中、保留中、不明、成功、失敗など) と再起動回数も、ポッドの準備状況を示す優れた指標です。この情報は、Kubernetes API へのクエリを通じて取得でき、LogicMonitor などのツールで自動的に収集および表示できます。
ポッドログ ログ また、ポッドとそのコンテナ内の操作に関する洞察も提供します。操作間のタイムスタンプを分析して、応答時間を観察し、効率を最適化できます。警告とエラー メッセージは障害とボトルネックを明らかにし、トラブルシューティングに重要な情報を提供します。Kubernetes は本質的にログを提供し、API を介して監視ソリューションに転送できます。
LM Envisionを使用すると、 Kubernetes ログを取り込む ポッドの作成や削除などのイベントも記録できます。 アラートを設定する リソース メトリックとログに記録されたイベントに基づいて、失敗した操作や計画外の急増に迅速に対応できるようになります。
プロのヒント: ログ集約を使用して、複数のポッド間でイベントを相関させ、パターンを識別します。
構成変更の追跡 Kubernetes環境の構成変更は、ポッドやサービス全体に渡る広範な変換につながる可能性があります。これは、デプロイされたアプリケーションで問題の原因となる可能性があります。デプロイメントマニフェスト、リソースクォータ、またはネットワークポリシーの更新により、以前に実行されていたワークロードが不安定になる可能性があります。LM Envisionなどのソリューションは、 構成の監視 、デプロイメントとネットワーク構成の変更の詳細なログを提供します。これにより、変更をパフォーマンス メトリックに直接関連付け、これらの監視対象データポイントにアラートとトリガーを設定できます。構成の変更を監視および保存すると、トラブルシューティングとデバッグのための詳細な監査証跡も得られます。
リソースのグループ化 Kubernetesのリソースとコンポーネントをグループ化して集約することで、ポッド、アプリケーション、および一般的なクラスター全体で観察された動作をより適切に相関させることができます。これは通常、Kubernetesリソースに添付されたキー値ラベルを使用するか、 Kubernetes 名前空間 リソースを描写します。この設定により、高レベルのメトリックと詳細なイベント間を移動して、クラスターとポッドのパフォーマンスの概要から個々のコンポーネント内の操作の詳細情報に移動できます。
ポッドレベルのメトリクス インフラストラクチャの健全性にとって重要であり、問題のデバッグと予測に役立つ特定のポッドレベルのメトリックをいくつか見てみましょう。
コンテナの再起動回数: kubelet は、コンテナ内の障害やエラーを処理するためにコンテナを再起動します。頻繁な再起動は、アプリケーションの不安定性またはリソース制約の問題があることを示します。たとえば、15 分間に XNUMX 回以上再起動する場合は警告サインです。ポッドのスケジューリングの遅延: 新しいポッドが配置される速度を指します。スケジュール時間が長いと、デプロイメント速度とスケーリング効率に影響します。新しいポッドのスケジュールに 10 秒以上かかる場合は、ポッドに問題がある可能性があります。保留中のポッド数: ポッドは、ノードにスケジュールできない場合は保留中とみなされます。この数が観測されたベンチマークを超える場合は、リソース、ノード テイント、アフィニティ ルール、および PVC バインディングを調べてください。 ポッドの起動時間: 更新中または障害時に起動時間が長くなると、アプリケーションの可用性が損なわれる可能性があります。ポッドの起動に 30 秒以上かかる場合は、リソースまたはアプリケーションの障害が発生している可能性があります。OOMKilled イベント: これらのイベントは、アプリケーション内のメモリ制限の問題またはメモリ リークを示しています。これらのイベントの発生に対してアラートを設定します。30 分以内に XNUMX 回以上のスパイクが発生すると重大です。 コンテナスロットルメトリック: 例としては、コンテナがスロットルされた回数やスロットルされた時間などがあります。これらのメトリックを監視して、リソースの割り当てと操作を最適化します。ポッドネットワーク I/O エラー: ネットワーク I/O のエラーは、ポッド内のサービスと操作に直接影響します。 ボリュームI/Oレイテンシ: データベース アプリケーションとトランザクション集約型のワークロードにとって重要です。ストレージの非効率性とボトルネックの解消に役立ちます。100 ミリ秒を超える遅延は、ワークフローのさらなる詰まりにつながる可能性があります。 コンテナの初期化の失敗: アプリケーションとポッドの起動に重要です。アプリケーション ロジック内の問題を示すことができます。 プローブの失敗: 活性プローブと準備プローブは、アプリケーションの健全性とサービスの可用性を示す重要な指標です。 ImagePullBackOff エラー: 障害のあるコンテナ イメージを示し、ポッドの展開と更新に影響します。 クラスターとポッドの健全性を理解することは重要ですが、最終的には、エンドユーザーにとって重要なのはアプリケーションのパフォーマンスです。
アプリケーションのログとトレース アプリケーションを効果的に監視するには、まずアプリケーションログを収集してエラーメッセージ、デバッグ情報、リクエストの詳細を照会します。一貫性のあるログメタデータは、 分散トレーシング LM Envisionの分散トレース機能は、 OpenTelemetry コレクター 分析のためにトレース データを追跡および転送します。アプリケーションとサービスは複数のポッドとノードにまたがり、リクエストはさまざまなアプリケーションを通過する場合があります。分散トレースは、これらのリクエストを追跡し、サービスの相互作用とボトルネックに関する洞察を得るために必要な可視性を提供します。
プロのヒント: 分散トレースを使用して、マイクロサービス全体のリクエストを追跡し、ボトルネックを特定します。
などのツールを統合する プロメテウス OpenTelemetryは、アプリケーション内でより詳細なメトリクスとトレースを可能にします。これらのツールは、アプリケーション内の特定の領域と動作を監視するために必要な制御と柔軟性を提供します。相互運用性と オープンメトリクス 標準では、カスタム データを簡単に公開し、LM Envision に統合して、効率的な分析を行うことができます。
カスタマイズされた監視 アプリケーションによって監視方法やパフォーマンス指標は異なります。Webアプリケーションの場合は、可用性に重点を置きます。 コンテンツ配信メトリクス 、およびユーザーの行動。データ量の多いアプリケーションやデータベース アプリケーションの場合は、クエリ パフォーマンス、処理能力、およびストレージ容量を優先します。
LM Envision などのツールを使用すると、アプリケーションと Kubernetes インフラストラクチャの両方のメトリックが 1 つのプラットフォームに統合されます。たとえば、Prometheus から収集されたアプリケーション メトリックは、アプリケーションのパフォーマンスと基盤となるインフラストラクチャの健全性を相関させる Kubernetes 固有のインフラストラクチャ メトリックと一緒に表示できます。これにより、統合されたダッシュボードが提供され、迅速な可視性が得られ、ボトルネックを特定してインフラストラクチャとアプリケーションの問題を修正するのに役立ちます。
アプリケーションレベルのメトリクス 最後に、デバッグとプロアクティブな最適化のためのいくつかの重要なアプリケーション レベルのデータ ポイントを見てみましょう。
リクエストレイテンシパーセンタイル: アプリケーションのパフォーマンス、速度、ユーザー エクスペリエンスに影響を与える最大応答時間を示します。たとえば、p95 が 150 ミリ秒の場合、ユーザーによるリクエストの 95 パーセントが 150 ミリ秒以内に完了したことを意味します。 エラーバジェット消費率: SLO にエラーの許容範囲が明示的に定められている場合は、これを追跡し、サービスの信頼性の目標が満たされていることを確認することが重要です。問題を迅速にデバッグするために、短期間で繰り返し発生するエラーを監視するようにしてください。 サービス レベル インジケーター (SLI) メトリック: 顧客へのサービスに関する契約上の指標です。一般的には次のような内容が含まれます。 ゴールデンシグナル 遅延、トラフィック、エラーなど、さまざまなリスク要因が考えられます。サービス契約に基づいてアラートしきい値を設定できます (例: トラフィックの急激な低下 (> 20%) やリソース使用率の 80% を超えると警告する)。 包み込む 特にハイブリッド クラウド環境で運用中の Kubernetes クラスターを管理する場合、監視スイートが成功を左右する可能性があります。運用は複数の環境とサービスにまたがり、1 つのコンポーネントの障害が広範囲にわたる問題を引き起こす可能性があります。規模が拡大するにつれて、明確な可視性と問題を追跡して解決する能力が重要になります。
LMエンビジョン あります AI電源 Kubernetes環境（オンプレミスとクラウド）とクラウドプロバイダーをシームレスに統合するハイブリッド監視プラットフォーム。 Amazon エラスティック Kubernetes サービス (Amazon EKS) , Azure Kubernetes Service（AKS） , Google Kubernetes Engine（GKE） LogicMonitorには、メトリック、イベント、ログ、トレースの完全なスイートがあり、 生成AIエージェント IT チームがアラートのノイズを減らし、リアクティブからプロアクティブに移行できるように設計されています。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
