このページは Cloud Translation API によって翻訳されました。

GKE のトラブルシューティングの概要

Autopilot Standard

問題のトラブルシューティングを効果的に行う方法を学習して、Google Kubernetes Engine（GKE）でサービスをスムーズに実行できるようにします。Kubernetes の初心者でも経験豊富なユーザーでも、一般的な問題のモニタリング、診断、解決のための体系的なアプローチを学ぶことができます。

次のツールと手法を使用して、GKE のトラブルシューティングスキルを構築します。

クラスタに影響を与える可能性のある進行中の信頼性インシデントについては、サービスの状態とインシデントを確認 Google Cloud してください。
Google Cloud コンソールでクラスタとワークロードの健全性を確認して、潜在的な問題をすばやく特定します。
kubectl コマンドラインツールを使用してクラスタの状態を調査することで、ノードや Pod などのリソースのライブステータスを表示します。
Cloud Logging で履歴分析を行うことで、障害の根本原因を特定します。
Cloud Monitoring でプロアクティブなモニタリングを行うことで、ユーザーに影響が及ぶ前に問題に対処します。
Gemini Cloud Assist で診断を迅速化: エラーを分析し、手順ごとのガイダンスを受け取り、問題を自動的に調査します。
トラブルシューティングのシナリオ例に沿って、これらのツールを組み合わせて使用し、実際のアプリケーションの障害を診断して解決する方法を学びます。

基本的な概念を理解する

Kubernetes と GKE を初めて使用する場合は、トラブルシューティングを開始する前に、クラスタアーキテクチャや Pod とノードの関係などのコアコンセプトを理解することが不可欠です。詳細については、GKE の学習を開始するをご覧ください。

また、GKE のどの部分のメンテナンスをお客様が担当し、どの部分を Google Cloud が担当するのかを理解することも重要です。詳細については、GKE の共有責任をご覧ください。

サービスの健全性とインシデントを確認する

Google Cloud が公開しているサービスの健全性とインシデントを確認すると、発生している問題がサービスインシデント、既知の問題、その他の重要なサービスの健全性の状況に関連しているかどうかを判断するのに役立ちます。 Google Cloudサービスの状態に関する情報は、次のソースから確認できます。

Google Cloud Service Health: リージョン別の Google Cloud サービスのステータス情報。
Personalized Service Health: プロジェクトに関連するサービスの中断。
サービスインシデントの分析情報と推奨事項: 進行中のサービスインシデントの影響を受けている GKE クラスタ。

Google Cloud サービス正常性を確認する

Google Cloud Service Health ページには、 Google Cloudに含まれるサービスのステータス情報が表示されます。

GKE 関連のインシデントを確認するには、Google Cloud Service Health ページに移動します。

Google Kubernetes Engine に関するすべてのインシデントのレポートに移動

Personalized Service Health を確認する

Personalized Service Health を使用すると、プロジェクトに関連する Google Cloud サービスの中断を特定できます。このような中断はサービス健全性イベントと呼ばれ、 Google Cloud コンソールとさまざまなインテグレーションポイントで情報を確認できます。

プロジェクトに関連する GKE 関連のインシデントを確認するには、 Google Cloud コンソールの Personalized Service Health ダッシュボードでサービスヘルスイベントを表示します。

Personalized Service Health に移動する

インシデントは、サービス、場所、関連性、ステータスでフィルタできます。ダッシュボードには、影響範囲、症状、回避策、解決の進捗状況の更新など、インシデントの詳細も表示されます。まず、クイックスタート: Google Cloud コンソールでサービスヘルスイベントを表示するをご覧ください。

サービスインシデントの分析情報と推奨事項を確認する

サービスインシデントの分析情報と推奨事項を使用すると、進行中のサービスインシデントの影響を受けている GKE クラスタを特定できます。

サービスインシデントの分析情報を取得するには、GKE_RELIABILITY_INCIDENT サブタイプの分析情報と推奨事項を表示します。分析情報は、 Google Cloud コンソール、Google Cloud CLI、または Recommender API を使用して取得できます。詳細については、分析情報と推奨事項を表示するをご覧ください。

分析情報と推奨事項には次の情報が含まれます。

影響を受けるクラスタ: インシデントの影響を受けるクラスタ。
インシデント名: Cloud カスタマーケアとの連絡時に参照するインシデント ID。
インシデントの説明: インシデント対応チームからのインシデントに関する情報。
最終有効時間: インシデントに関する情報が最後に更新された時刻。
緩和アクション: インシデント対応チームが推奨する緩和アクション（利用可能な場合）。

サービスインシデントの分析情報は、 Google Cloud インシデント対応チームがインシデントを緩和し、分析情報が関連しなくなったと判断するまで表示されます。インシデントが軽減され、リソースに影響しなくなった時点と、分析情報が削除される時点の間には遅延があります。回避策を実装して、分析情報を表示したくない場合は、分析情報を閉じることができます。

Google Cloud コンソールでクラスタとワークロードの健全性を確認する

Google Cloud コンソールは、クラスタとワークロードの健全性をすばやく確認できるため、トラブルシューティングの出発点として最適です。クラスタの健全性は、ノードやネットワーキングなどの基盤となる GKE インフラストラクチャの健全性を参照します。一方、ワークロードの健全性は、クラスタで実行されているアプリのステータスとパフォーマンスを参照します。

以降のセクションでは、クラスタページとワークロードページについて説明します。アプリの健全性を完全に把握するために、 Google Cloud コンソールでは強力なロギングツールとモニタリングツールにもアクセスできます。これにより、過去の障害の根本原因を調査し、将来の障害を未然に防ぐことができます。これらのツールの詳細については、Cloud Logging で履歴分析を行うと Cloud Monitoring で事前対応型モニタリングを行うをご覧ください。

クラスタに関する問題を見つける

[Kubernetes クラスタ] ページには、クラスタの健全性の概要が表示されます。クラスタの問題を特定するには、このページから始めます。

まず、 Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

Kubernetes クラスタに移動

このページをトラブルシューティングに活用する方法の例をいくつかご紹介します。

クラスタの健全性、アップグレード戦略、費用の最適化を改善するためのアドバイスについては、[推奨事項を表示] をクリックします。
異常なクラスタを特定するには、[ステータス] 列を確認します。緑色のチェックマークが付いていないクラスタには注意が必要です。
潜在的な問題を確認するには、[通知] 列を確認します。通知メッセージをクリックすると、詳細が表示されます。

特定のクラスタを調査する

クラスタで問題が見つかったら、クラスタの [詳細] ページで詳細情報を確認します。この情報は、クラスタのトラブルシューティングや構成の把握に役立ちます。

クラスタの [詳細] ページに移動する手順は次のとおりです。

[Kubernetes クラスタ] ページに移動します。

Kubernetes クラスタに移動
[名前] 列を確認し、調査するクラスタの名前をクリックします。

クラスタの [詳細] ページを使用してクラスタのトラブルシューティングを行う方法の例を次に示します。

一般的なヘルスチェックの場合は、次のオプションをお試しください。
- クラスタレベルのダッシュボードを表示するには、[オブザーバビリティ] タブに移動します。デフォルトでは、クラスタを作成すると、GKE は Cloud Monitoring を有効にします。Cloud Monitoring が有効になっている場合、GKE はこのページのダッシュボードを自動的に設定します。トラブルシューティングに最も役立つビューをいくつかご紹介します。
  - 概要: クラスタの健全性、リソース使用率、主要なイベントの概要を表示します。このダッシュボードを使用すると、クラスタの全体的な状態をすばやく評価し、潜在的な問題を特定できます。
  - トラフィック指標: ノードベースのネットワーク指標を表示して、Kubernetes ワークロード間のトラフィックに関する分析情報を取得します。
  - ワークロードの状態: Deployment、Pod、コンテナの状態を表示します。障害が発生しているインスタンスまたは異常なインスタンスを特定し、リソース制約を検出します。
  - コントロールプレーン: コントロールプレーンの健全性とパフォーマンスを表示します。このダッシュボードでは、kube-apiserver や etcd などのコンポーネントの主要な指標をモニタリングし、パフォーマンスのボトルネックを特定して、コンポーネントの障害を検出できます。
    
    ヒント: これらのダッシュボードは、カスタマイズされたダッシュボードを作成するための出発点として使用できます。事前定義されたダッシュボードをコピーして、ニーズに関連する特定の指標、フィルタ、可視化を含めるようにカスタマイズできます。
- 最近のアプリエラーを表示するには、[アプリのエラー] タブに移動します。このタブの情報は、発生回数、エラーが最初に発生した日時、最後に発生した日時を表示することで、エラーの優先順位付けと解決に役立ちます。
  
  エラーをさらに調査するには、エラーメッセージをクリックして、関連するログへのリンクを含む詳細なエラーレポートを表示します。
最近のアップグレードや変更後に問題のトラブルシューティングを行う場合は、クラスタの [詳細] タブの [クラスタの基本] セクションを確認します。[バージョン] フィールドに表示されているバージョンが想定どおりであることを確認します。詳細を調べるには、[アップグレード] セクションで [アップグレード履歴を表示] をクリックします。
Standard クラスタを使用しているときに、Pod が Pending 状態のままになった場合や、ノードが過負荷になっている疑いがある場合は、[ノード] タブを確認します。GKE がノードを管理するため、Autopilot クラスタでは [ノード] タブは使用できません。
- [ノードプール] セクションで、自動スケーリングが正しく構成され、マシンタイプがワークロードに適していることを確認します。
- [ノード] セクションで、ステータスが Ready 以外のノードを探します。NotReady ステータスは、リソースの圧迫や kubelet の問題など、ノード自体に問題があることを示します（kubelet は、各ノードで実行されてコンテナを管理するエージェントです）。

ワークロードの問題を検出する

特定のアプリ（デプロイの失敗など）に問題があると思われる場合は、 Google Cloud コンソールの [ワークロード] ページに移動します。このページには、クラスタ内で実行されているすべてのアプリが一覧表示されます。

まず、 Google Cloud コンソールで [ワークロード] ページに移動します。

[ワークロード] に移動

このページをトラブルシューティングに活用する方法の例をいくつかご紹介します。

異常なワークロードを特定するには、[ステータス] 列を確認します。緑色のチェックマークが付いていないワークロードは、注意が必要です。
アプリが応答しない場合は、[Pods] 列を確認します。たとえば、ステータスが 1/3 の場合、3 つのアプリレプリカのうち 1 つしか実行されておらず、問題があることを示します。

特定のワークロードを調査する

概要から問題のあるワークロードを特定したら、ワークロードの [詳細] ページを調べて根本原因の切り分けを開始します。

ワークロードの [詳細] ページに移動する手順は次のとおりです。

[ワークロード] ページに移動します。

[ワークロード] に移動
[名前] 列を表示し、調査するワークロードの名前をクリックします。

ワークロードの [詳細] ページを使用してワークロードのトラブルシューティングを行う方法の例を次に示します。

ワークロードの構成を確認するには、ワークロードの [概要] タブと [詳細] タブを使用します。この情報を使用すると、正しいコンテナイメージタグがデプロイされたかどうかなどのイベントの確認や、ワークロードのリソースリクエストと上限を確認できます。

注: ワークロードのタイプによっては、[概要] タブが表示されないことがあります。たとえば、StatefulSet には [詳細] タブのみがあります。ただし、どちらのタブも構成の確認に役立ちます。
クラッシュしている特定の Pod の名前を確認するには、[マネージド Pod] セクションに移動します。この情報は kubectl コマンドで必要になることがあります。このセクションには、ワークロードによって制御されるすべての Pod とそのステータスが一覧表示されます。ワークロードの最近の変更履歴を確認するには、[変更履歴] タブに移動します。新しいデプロイ後にパフォーマンスの問題が発生した場合は、このセクションを使用して、アクティブなリビジョンを特定します。これにより、現在のリビジョンの構成と以前のリビジョンの構成を比較して、問題の原因を特定できます。このタブが表示されない場合、ワークロードはリビジョンを使用しないタイプであるか、まだ更新されていないかのいずれかです。
Deployment が失敗したと思われる場合は、[イベント] タブに移動します。このページには Kubernetes レベルのイベントが表示されるため、多くの場合、最も価値のある情報源となります。
アプリのログを確認するには、[ログ] タブをクリックします。このページでは、クラスタ内で何が起こっているかを把握できます。問題の診断に役立つエラーメッセージとスタックトレースについては、こちらをご覧ください。
デプロイされた内容を正確に確認するには、[YAML] タブを表示します。このページには、クラスタに存在するワークロードのライブ YAML マニフェストが表示されます。この情報は、ソース管理されたマニフェストとの不一致を見つけるのに役立ちます。単一の Pod の YAML マニフェストを表示している場合、このタブには Pod のステータスも表示されます。これにより、Pod レベルの障害に関する分析情報を確認できます。

`kubectl` コマンドラインツールを使用してクラスタの状態を調査する

Google Cloud コンソールは問題の有無を把握するのに役立ちますが、kubectl コマンドラインツールは問題の原因を特定するのに不可欠です。Kubernetes コントロールプレーンと直接通信することで、kubectl コマンドラインツールを使用して、GKE 環境のトラブルシューティングに必要な詳細情報を収集できます。

以降のセクションでは、GKE のトラブルシューティングの強力な出発点となる重要なコマンドについて説明します。

始める前に

開始する前に、次のタスクを実行します。

kubectl をインストールします。
クラスタと通信するように kubectl コマンドラインツールを構成します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
権限を確認します。kubectl コマンドを実行するために必要な権限があるかどうかを確認するには、kubectl auth can-i コマンドを使用します。たとえば、kubectl get nodes を実行する権限があるかどうかを確認するには、kubectl auth can-i get nodes コマンドを実行します。

必要な権限がある場合、コマンドは yes を返します。それ以外の場合、コマンドは no を返します。

kubectl コマンドを実行する権限がない場合は、次のようなエラーメッセージが表示されることがあります。
```
Error from server (Forbidden): pods "POD_NAME" is forbidden: User
"USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
namespace "default"
```
必要な権限がない場合は、クラスタ管理者に必要なロールの割り当てを依頼してください。

実行中の概要を確認する

kubectl get コマンドを使用すると、クラスタで発生していることの全体像を把握できます。次のコマンドを使用して、最も重要なクラスタコンポーネントであるノードと Pod のステータスを確認します。

ノードが正常かどうかを確認するには、すべてのノードとそのステータスの詳細を表示します。

kubectl get nodes

出力は次のようになります。

NAME                                        STATUS   ROLES    AGE     VERSION

gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003

Ready 以外のステータスは、追加の調査が必要です。

Pod が正常かどうかを確認するには、すべての Pod とそのステータスの詳細を表示します。
```
kubectl get pods --all-namespaces
```
出力は次のようになります。
```
NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
kube-system netd-6nbsq 3/3     Running     0          4d23h
kube-system netd-g7tpl 3/3     Running     0          4d23h
```
Running 以外のステータスは、追加の調査が必要です。一般的なステータスは次のとおりです。
- Running: 正常に実行されている状態。
- Pending: Pod はノードでスケジュールされるのを待機している状態です。
- CrashLoopBackOff: アプリが起動してエラーで終了し、Kubernetes によって再起動されるため、Pod 内のコンテナがループ内で繰り返しクラッシュしています。
- ImagePullBackOff: Pod がコンテナイメージを pull できません。

上記のコマンドは、kubectl get コマンドの使用方法の 2 つの例にすぎません。このコマンドを使用して、さまざまなタイプの Kubernetes リソースの詳細を確認することもできます。確認できるリソースの完全なリストについては、Kubernetes ドキュメントの kubectl get をご覧ください。

特定のリソースの詳細

問題を特定したら、詳細情報を取得する必要があります。問題の例としては、ステータスが Running ではない Pod があります。詳細を取得するには、kubectl describe コマンドを使用します。

たとえば、特定の Pod の説明を取得するには、次のコマンドを実行します。

kubectl describe pod POD_NAME -n NAMESPACE_NAME

次のように置き換えます。

POD_NAME: 問題が発生している Pod の名前。
NAMESPACE_NAME: Pod が存在する Namespace。Namespace がわからない場合は、kubectl get pods コマンドの出力から Namespace 列を確認します。

kubectl describe コマンドの出力には、リソースに関する詳細情報が含まれます。Pod のトラブルシューティングを行う際に確認すると役立つセクションを以下に示します。

Status: Pod の現在のステータス。
Conditions: Pod の全体的な健全性と readiness。
Restart Count: Pod 内のコンテナが再起動した回数。数値が高い場合は注意が必要です。
Events: この Pod に発生した重要なことのログ（ノードへのスケジュール、コンテナイメージの pull、エラーの発生など）。Events セクションには、Pod が失敗した理由を直接示す情報が記載されていることがよくあります。

kubectl get コマンドと同様に、kubectl describe コマンドを使用して、複数のタイプのリソースの詳細を確認できます。確認できるリソースの完全なリストについては、Kubernetes ドキュメントの kubectl describe をご覧ください。

Cloud Logging で履歴分析を行う

kubectl コマンドラインツールは Kubernetes オブジェクトのライブ状態を検査するうえで非常に重要ですが、そのビューは現在の瞬間に限定されることがよくあります。問題の根本原因を把握するには、時間の経過とともに何が起こったかを調査する必要があります。履歴コンテキストが必要な場合は、Cloud Logging を使用します。

Cloud Logging は、GKE クラスタ、コンテナ化されたアプリ、その他の Google Cloud サービスからログを集約します。

トラブルシューティングの主なログタイプについて

Cloud Logging は、トラブルシューティングに役立つさまざまな種類の GKE ログを自動的に収集します。

ノードとランタイムのログ（kubelet、containerd）: 基盤となるノードサービスからのログ。kubelet はノード上のすべての Pod のライフサイクルを管理するため、コンテナの起動、メモリ不足（OOM）イベント、プローブの失敗、ボリュームのマウントエラーなどの問題のトラブルシューティングには、そのログが不可欠です。これらのログは、NotReady ステータスのノードなど、ノードレベルの問題の診断にも不可欠です。

containerd はイメージの pull など、コンテナのライフサイクルを管理するため、そのログは kubelet がコンテナを起動する前に発生した問題のトラブルシューティングに不可欠です。containerd ログは、コンテナランタイムの特定のアクティビティと潜在的なエラーを記録するため、GKE でノードレベルの問題を診断するのに役立ちます。
アプリログ（stdout、stderr）: コンテナ化されたプロセスからの標準出力ストリームとエラーストリーム。これらのログは、クラッシュ、エラー、予期しない動作などのアプリ固有の問題をデバッグするうえで不可欠です。
監査ログ: クラスタで「誰が、どこで、いつ、何をしたのか」を把握できます。これらは、Kubernetes API サーバーに対して行われた管理アクションと API 呼び出しを追跡します。これは、構成の変更や不正アクセスによって発生した問題を診断するのに役立ちます。

一般的なトラブルシューティングのシナリオ

問題を特定したら、これらのログに対してクエリを実行して、何が起こったのかを確認できます。作業を開始するにあたって、ログを確認すると、次のような問題の解決に役立ちます。

ノードのステータスが NotReady の場合は、ノードログを確認します。kubelet ログと containerd ログには、ネットワークの問題やリソースの制約など、根本原因が示されていることがよくあります。
新しいノードのプロビジョニングとクラスタへの参加に失敗した場合は、ノードのシリアルポートログを確認します。これらのログは、ノードのロギングエージェントが完全にアクティブになる前の、アーリーブートと kubelet の起動アクティビティをキャプチャします。
過去に Pod の起動に失敗した場合は、その Pod のアプリログを調べて、クラッシュがないか確認します。ログが空の場合や、Pod をスケジュールできない場合は、関連するイベントの監査ログ、またはターゲットノードのノードログで、リソースの圧迫やイメージの pull エラーの手がかりを探します。
重要な Deployment が削除されたが、その理由が不明な場合は、管理アクティビティ監査ログに対してクエリを実行します。これらのログは、削除 API 呼び出しを発行したユーザーまたはサービスアカウントを特定するのに役立ち、調査の明確な出発点となります。

ログへのアクセス方法

ログエクスプローラを使用して、 Google Cloud コンソールで GKE ログのクエリ、表示、分析を行います。ログエクスプローラには、問題の分離に役立つ強力なフィルタリングオプションが用意されています。

ログエクスプローラにアクセスして使用する手順は次のとおりです。

Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。

[ログエクスプローラ] に移動

クエリペインにクエリを入力します。Logging のクエリ言語を使用して、ターゲットクエリを記述します。始めるにあたって、以下に、一般的なフィルタをいくつかご紹介します。

フィルタの種類	説明	値の例
`resource.type`	Kubernetes リソースのタイプ。	`k8s_cluster`、`k8s_node`、`k8s_pod`、`k8s_container`
`log_id`	リソースからのログストリーム。	`stdout`、`stderr`
`resource.labels.RESOURCE_TYPE.name`	特定の名を持つリソースをフィルタします。は、`RESOURCE_TYPE` をクエリを実行するリソースの名前に置き換えます。例: `namespace`、`pod` など。	`example-namespace-name`、`example-pod-name`
`severity`	ログの重大度レベル。	`DEFAULT`、`INFO`、`WARNING`、`ERROR`、`CRITICAL`
`jsonPayload.message=~`	ログメッセージ内のテキストの正規表現検索。	`scale.down.error.failed.to.delete.node.min.size.reached`

たとえば、特定の Pod のトラブルシューティングを行う場合は、そのエラーログを分離することがあります。その Pod の重大度が ERROR のログのみを表示するには、次のクエリを使用します。

resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

次のように置き換えます。

POD_NAME: 問題が発生している Pod の名前。
NAMESPACE_NAME: Pod が存在する Namespace。Namespace がわからない場合は、kubectl get pods コマンドの出力から Namespace 列を確認します。

他の例については、Google Cloud Observability ドキュメントの Kubernetes 関連のクエリをご覧ください。

[クエリを実行] をクリックします。
JSON ペイロード、メタデータ、タイムスタンプなどの完全なログメッセージを表示するには、ログエントリをクリックします。

GKE ログの詳細については、GKE ログについてをご覧ください。

Cloud Monitoring を使用して事前対応型のモニタリングを行う

問題が発生した後、ログを確認することはトラブルシューティングの重要なステップです。ただし、真に復元力のあるシステムには、停止を引き起こす前に問題を特定する事前対応型のアプローチも必要です。

将来の問題を事前に特定し、主要業績評価指標を長期にわたって追跡するには、Cloud Monitoring を使用します。Cloud Monitoring には、ダッシュボード、指標、アラート機能が用意されています。これらのツールは、エラー率の上昇、レイテンシの増加、リソース制約を特定するのに役立ちます。これにより、ユーザーに影響が及ぶ前に対応できます。

有用な指標を確認する

GKE は、一連の指標を Cloud Monitoring に自動的に送信します。以降のセクションでは、トラブルシューティングに最も重要な指標をいくつか示します。

コンテナのパフォーマンスと健全性指標
ノードのパフォーマンスと健全性指標
Pod のパフォーマンスと健全性指標

GKE 指標の完全なリストについては、GKE システム指標をご覧ください。

コンテナのパフォーマンスと健全性指標

特定のアプリに問題があると思われる場合は、これらの指標から始めます。これらの指標は、コンテナが頻繁に再起動しているか、メモリ不足になっているか、CPU 制限によってスロットリングされているかなど、アプリの健全性をモニタリングするのに役立ちます。

指標	説明	トラブルシューティングの重要性
`kubernetes.io/container/cpu/limit_utilization`	インスタンスで現在使用されている CPU 上限の割合。コンテナが CPU 上限を超えることが許可されている場合があるため、この値が 1 より大きくなることがあります。	CPU スロットリングを識別します。値が大きいと、パフォーマンスが低下する可能性があります。
`kubernetes.io/container/memory/limit_utilization`	インスタンスで現在使用されているメモリ上限の割合。この値は 1 を超えることはできません。	メモリ不足（OOM）エラーのリスクをモニタリングします。
`kubernetes.io/container/memory/used_bytes`	コンテナが実際に使用したメモリ（バイト単位）。	メモリ使用量を追跡して、メモリリークの可能性や OOM エラーのリスクを特定します。
`kubernetes.io/container/memory/page_fault_count`	メジャーとマイナーのタイプ別に分類したページフォールトの数の数。	メモリ負荷が高いことを示します。メジャーページフォルトは、メモリ上限に達していなくても、メモリがディスクから読み取られている（スワッピング）ことを意味します。
`kubernetes.io/container/restart_count`	コンテナが再起動した回数。	再起動の回数が多い、または増加している場合、アプリのクラッシュ、構成ミス、リソースの枯渇などの潜在的な問題をハイライト表示します。
`kubernetes.io/container/ephemeral_storage/used_bytes`	ローカルエフェメラルストレージの使用量（バイト単位）。	一時ディスクの使用量をモニタリングし、エフェメラルストレージの容量不足による Pod の強制排除を防ぎます。
`kubernetes.io/container/cpu/request_utilization`	インスタンスでリクエストされ、現在使用されている CPU の割合。使用量がリクエストを超える可能性があるため、この値が 1 より大きくなることがあります。	CPU リクエストのプロビジョニングが過剰または過少になっていることを特定し、リソース割り当ての最適化に役立ちます。
`kubernetes.io/container/memory/request_utilization`	インスタンスでリクエストされ、現在使用されているメモリの割合。使用量がリクエストを超える可能性があるため、この値が 1 より大きくなることがあります。	メモリリクエストの過剰または過小なプロビジョニングを特定し、スケジューリングを改善して OOM エラーを防止します。

ノードのパフォーマンスと健全性指標

基盤となる GKE インフラストラクチャの問題を診断する必要がある場合は、これらの指標を確認します。これらの指標は、ノードの全体的な健全性と容量を把握するうえで重要です。ノードが異常な状態か、負荷がかかっているか、新しい Pod をスケジュールするのに十分なメモリがあるかどうかを調査するのに役立ちます。

指標	説明	トラブルシューティングの重要性
`kubernetes.io/node/cpu/allocatable_utilization`	インスタンスで現在使用されている割り当て可能な CPU の割合。	Pod の使用量の合計がノードの使用可能な CPU リソースに負荷をかけているかどうかを示します。
`kubernetes.io/node/memory/allocatable_utilization`	インスタンスで割り当て可能であり、現在使用されているメモリの割合。使用量が割り当て可能なメモリのバイト数を超えることはないため、この値が 1 を超えることはできません。	特に値が高い場合、新しい Pod のスケジュール設定や既存の Pod を動作させるためのメモリが不足していることを示します。
`kubernetes.io/node/status_condition`（ベータ版）	ノードのステータス条件フィールドのノードの条件。	`Ready`、`MemoryPressure`、`DiskPressure` などのノードの健全性状態を報告します。
`kubernetes.io/node/ephemeral_storage/used_bytes`	ノードにより使用されるローカルエフェメラルストレージのバイト数。	エフェメラルストレージの使用量が多い場合に警告を発行することで、Pod の起動エラーや強制排除を回避できます。
`kubernetes.io/node/ephemeral_storage/inodes_free`	ローカルエフェメラルストレージ上のインデックスノード（i ノード）の空き数。	空き i ノードの数をモニタリングします。ディスク容量が使用可能であっても、i ノードが不足するとオペレーションが停止する可能性があります。
`kubernetes.io/node/interruption_count`（ベータ版）	中断は、お客様がインフラストラクチャを制御している間にインフラストラクチャがシステムによって強制排除されることです。この指標は、タイプと理由別の現在の中断数です。	システムの強制排除が原因でノードが予期せず消える可能性がある理由について説明します。

Pod のパフォーマンスと健全性指標

これらの指標は、ネットワーキングやストレージなど、Pod と環境のインタラクションに関連する問題のトラブルシューティングに役立ちます。これらの指標は、起動が遅い Pod の診断、ネットワーク接続性の問題の調査、ストレージの事前管理によってボリュームの満杯による書き込みエラーの防止を行う必要がある場合に使用します。

指標	説明	トラブルシューティングの重要性
`kubernetes.io/pod/network/received_bytes_count`	ネットワーク経由でポッドにより受信された累積バイト数。	アプリやネットワークの問題を示す可能性がある異常なネットワークアクティビティ（高または低）を特定します。
`kubernetes.io/pod/network/policy_event_count`（ベータ版）	データプレーンで確認されたネットワークポリシーイベント数の変化。	ネットワークポリシーが原因で発生した接続性の問題を特定します。
`kubernetes.io/pod/volume/utilization`	インスタンスにより現在使用されているボリュームの割合。使用量が使用可能なボリューム容量の合計を超えることはないため、この値が 1 を超えることはありません。	使用率が高い（1 に近づいている）と書き込みエラーが発生する可能性がある場合に警告を発し、ボリュームスペースのプロアクティブな管理を可能にします。
`kubernetes.io/pod/latencies/pod_first_ready`（ベータ版）	イメージの pull を含む、Pod のエンドツーエンドの起動レイテンシ（Pod Created から Ready まで）。	起動が遅い Pod を診断します。

Metrics Explorer で指標を可視化する

GKE 環境の状態を可視化するには、Metrics Explorer で指標に基づいてグラフを作成します。

Metrics Explorer を使用する手順は次のとおりです。

Google Cloud コンソールで、[Metrics Explorer] ページに移動します。

Metrics Explorer に移動
[指標] フィールドで、検査する指標を選択または入力します。
結果を表示し、経時的な傾向を確認します。

たとえば、特定の Namespace の Pod のメモリ使用量を調査するには、次の操作を行います。

[指標を選択] リストで、指標 kubernetes.io/container/memory/used_bytes を選択し、[適用] をクリックします。
[フィルタを追加] をクリックし、[namespace_name] を選択します。
[値] リストで、調査する Namespace を選択します。
[集計] フィールドで、[合計] > [pod_name] を選択し、[OK] をクリックします。この設定では、Pod ごとに個別の時系列線が表示されます。
[グラフを保存] をクリックします。

結果のグラフには、各 Pod のメモリ使用量の推移が表示されます。これにより、メモリ消費量が異常に多い Pod や急増している Pod を視覚的に特定できます。

Metrics Explorer では、表示する指標を柔軟に構築できます。Metrics Explorer の詳細オプションの詳細については、Cloud Monitoring ドキュメントの Metrics Explorer でグラフを作成するをご覧ください。

問題の事前検出に関するアラートを作成する

問題が発生した場合や、指標が特定のしきい値を超えた場合に通知を受け取るには、Cloud Monitoring でアラートポリシーを設定します。

たとえば、コンテナの CPU 上限が 5 分間 80% を超えたときに通知するアラートポリシーを設定するには、次の操作を行います。

Google Cloud コンソールで、[アラート] ページに移動します。

アラートに移動
[ポリシーを作成] をクリックします。
[指標を選択] ボックスで CPU limit utilization をフィルタし、次の指標を選択します。kubernetes.io/container/cpu/limit_utilization。
[適用] をクリックします。
[フィルタを追加] フィールドは空白のままにします。この設定では、クラスタがしきい値を超えるとアラートがトリガーされます。
[データの変換] セクションで、次のようにします。
1. [ローリングウィンドウ] リストで、[1 分] を選択します。この設定は、 Google Cloud が 1 分ごとに平均値を計算することを意味します。
2. [ローリングウィンドウ関数] リストで、[平均] を選択します。
  
  これらの設定はどちらも、各コンテナの CPU 上限使用率を毎分平均します。
[次へ] をクリックします。
[アラートを構成する] セクションで、次の操作を行います。
1. [条件タイプ] で [しきい値] を選択します。
2. [Alert trigger] で [任意の時系列の違反] を選択します。
3. [しきい値の位置] で [しきい値より上] を選択します。
4. [しきい値] に「0.8」と入力します。この値は、モニタリングする 80% のしきい値を表します。
5. [詳細オプション] をクリックします。
6. [再テストウィンドウ] リストで、[5 分] を選択します。この設定は、CPU 使用率が 5 分間継続して 80% を超えた場合にのみアラートがトリガーされることを意味します。これにより、短いスパイクによる誤報が減少します。
7. [条件名] フィールドに、条件にわかりやすい名前を付けます。
8. [次へ] をクリックします。
[通知を構成してアラートを確定する] セクションで、次の操作を行います。
1. [通知チャンネル] リストで、アラートを受信するチャンネルを選択します。チャンネルがない場合は、[通知チャンネルを管理] をクリックして作成します。
2. [アラートポリシーの名前を付ける] フィールドに、わかりやすい名前を入力します。
3. 他のフィールドはデフォルト値のままにしておきます。
4. [次へ] をクリックします。
ポリシーを確認し、問題がなければ [ポリシーを作成] をクリックします。

アラートを作成するその他の方法については、Cloud Monitoring ドキュメントのアラートの概要をご覧ください。

Gemini Cloud Assist で診断を迅速化する

前述のセクションで説明したツールを使用しても、問題の原因がすぐに明らかにならないことがあります。複雑なケースの調査には時間がかかり、高度な専門知識が必要です。このようなシナリオでは、Gemini Cloud Assist が役立ちます。隠れたパターンやサーフェス異常を自動的に検出し、概要を提供して、考えられる原因を迅速に特定するのに役立ちます。

Gemini Cloud Assist にアクセスする

Gemini Cloud Assist にアクセスする手順は次のとおりです。

Google Cloud コンソールで、任意のページに移動します。
Google Cloud コンソールのツールバーで、spark「Gemini Cloud Assist チャットを開始または終了します」をクリックします。

[Cloud Assist] パネルが開きます。表示されているプロンプトの例をクリックするか、[プロンプトを入力] フィールドにプロンプトを入力します。

プロンプトの例を調査する

Gemini Cloud Assist がどのように役立つかを確認するために、プロンプトの例をいくつか示します。

テーマ	シナリオ	サンプルプロンプト	Gemini Cloud Assist の活用方法
わかりにくいエラーメッセージ	Pod のステータスが `CrashLoopBackoff` ですが、エラーメッセージがわかりにくい。	GKE Pod エラー `panic: runtime error: invalid memory address or nil pointer dereference` はどういう意味ですか？一般的な原因は何ですか？	Gemini Cloud Assist はメッセージを分析し、わかりやすい言葉で説明します。考えられる原因と解決策も提示します。
パフォーマンスの問題	チームは、GKE で実行されているアプリのレイテンシが高いことに気づきました。	`prod` GKE クラスタの `api-gateway` サービスでレイテンシが高くなっています。最初に確認すべき指標は何ですか？また、この問題の一般的な GKE 関連の原因をいくつか教えてください。	Gemini Cloud Assist は、調査する主要な指標を提案、潜在的な問題（リソース制約やネットワークの輻輳など）を調査して、さらなる調査のためのツールと手法を推奨します。
ノードに関する問題	GKE ノードが `NotReady` のステータスで停止している。	GKE ノード（`node-xyz`）の一つが `NotReady` ステータスを示しています。この問題をトラブルシューティングするための一般的な手順を教えてください。	Gemini Cloud Assist は、ノードの自動修復などのコンセプトを説明し、関連する `kubectl` コマンドを提案する、段階的な調査計画を提供します。
GKE について	特定の GKE 機能やベストプラクティスの実装方法がわからない。	GKE クラスタを保護するためのベストプラクティスは何ですか？詳細を確認する方法はありますか？	Gemini Cloud Assist は、GKE のベストプラクティスを明確に説明します。[関連コンテンツを表示] をクリックすると、公式ドキュメントへのリンクが表示されます。

詳しくは、次のリソースをご覧ください。

より良いプロンプトを作成する方法を学習する。
Gemini Cloud Assist パネルの使用方法を学習する。
Gemini for Google Cloud の概要を読む。
Gemini for Google Cloud がデータを使用する方法について学習する。

Gemini Cloud Assist Investigations を使用する

Gemini Cloud Assist は、インタラクティブなチャットに加えて、Gemini Cloud Assist Investigations を通じて、より自動化された詳細な分析を実行できます。この機能は、ログエクスプローラなどのワークフローに直接統合されており、強力な根本原因分析ツールです。

エラーまたは特定のリソースから調査を開始すると、Gemini Cloud Assist はログ、構成、指標を分析します。このデータを使用して、考えられる根本原因に関するランク付けされた観測結果と仮説を生成し、推奨される次のステップを提供します。これらの結果を Google Cloud サポートケースに転送して、問題の迅速な解決に役立つ貴重なコンテキストを提供することもできます。

詳細については、Gemini ドキュメントの Gemini Cloud Assist Investigationsをご覧ください。

すべてをまとめる: トラブルシューティングのシナリオの例

この例では、GKE ツールの組み合わせを使用して、一般的な実際の問題（メモリ不足が原因でコンテナが繰り返しクラッシュする）を診断して理解する方法を示します。

シナリオ

GKE で実行される product-catalog という名前のウェブアプリのオンコールエンジニアです。

調査は、Cloud Monitoring から自動アラートを受信したときに開始されます。

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

このアラートは、問題が存在することと、その問題が product-catalog ワークロードに関連していることを示します。

Google Cloud コンソールで問題を確認する

まず、ワークロードの概要を確認して、問題を確認します。

Google Cloud コンソールで、[ワークロード] ページに移動し、product-catalog ワークロードでフィルタします。
[Pods] ステータス列を確認します。正常な 3/3 ではなく、値が 2/3 のように異常な状態を示しています。この値は、アプリの Pod のいずれかのステータスが Ready ではないことを示します。
さらに調査するため、product-catalog ワークロードの名前をクリックして詳細ページに移動します。
詳細ページで、[マネージド Pod] セクションを表示します。すぐに問題が特定されます。Pod の Restarts 列に、異常に高い数値である 14 が表示されています。

再起動回数が多い場合は、問題によってアプリが不安定になっていることが確認できます。また、コンテナがヘルスチェックに失敗しているか、クラッシュしていることが示唆されます。

`kubectl` コマンドで理由を確認する

アプリが繰り返し再起動していることがわかったので、その理由を調べる必要があります。この場合は、kubectl describe コマンドが役立ちます。

不安定な Pod の正確な名前を取得します。

kubectl get pods -n prod

次のような出力が表示されます。

NAME                             READY  STATUS            RESTARTS  AGE
product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m

不安定な Pod の説明を取得して、イベント履歴の詳細を確認します。
```
kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
```

出力を確認すると、Last State セクションと Events セクションに手がかりが見つかります。

Containers:
  product-catalog-api:
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 23 Jun 2025 10:50:15 -0700
      Finished:     Mon, 23 Jun 2025 10:54:58 -0700
    Ready:          False
    Restart Count:  14
...
Events:
  Type     Reason     Age                           From                Message
  ----     ------     ----                          ----                -------
  Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
  Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
  Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
  Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
  Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container

出力には、次の 2 つの重要な手がかりが表示されます。

まず、Last State セクションには、コンテナが Reason: OOMKilled で終了したことが示されています。これは、メモリ不足になったことを示しています。この理由は Exit Code: 137 によって確認できます。これはメモリ消費量が多すぎるために強制終了されたプロセスの標準的な Linux 終了コードです。
次に、Events セクションにはメッセージ Back-off restarting failed container を含む Warning: BackOff イベントが表示されます。このメッセージは、コンテナが失敗ループに陥っていることを確認するものです。これは、先ほど確認した CrashLoopBackOff ステータスの直接の原因です。

指標を使用して動作を可視化する

kubectl describe コマンドは発生したことを示しますが、Cloud Monitoring では環境の動作を時系列で確認できます。

Google Cloud コンソールで、[Metrics Explorer] に移動します。
container/memory/used_bytes 指標を選択します。
出力を特定のクラスタ、Namespace、Pod 名にフィルタします。

グラフには、メモリ使用量が着実に増加し、コンテナが OOM で強制終了して再起動すると、急激にゼロに低下するという明確なパターンが示されています。この視覚的な証拠は、メモリリークまたはメモリ上限の不足のいずれかを示しています。

ログで根本原因を見つける

これで、コンテナのメモリが不足していることはわかりましたが、その原因はまだ特定できていません。根本原因を特定するには、ログエクスプローラを使用します。

Google Cloud コンソールで、[ログエクスプローラ] に移動します。

クエリを作成して、最後のクラッシュの直前の特定のコンテナのログをフィルタします（kubectl describe コマンドの出力で確認できます）。

resource.type="k8s_container"
resource.labels.cluster_name="example-cluster"
resource.labels.namespace_name="prod"
resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
timestamp >= "2025-06-23T17:50:00Z"
timestamp < "2025-06-23T17:55:00Z"

ログには、クラッシュの直前にメッセージの繰り返しパターンが見られます。

{
  "message": "Processing large image file product-image-large.jpg",
  "severity": "INFO"
},
{
  "message": "WARN: Memory cache size now at 248MB, nearing limit.",
  "severity": "WARNING"
}

これらのログエントリは、アプリが大きな画像ファイルをメモリに完全に読み込んで処理しようとしており、最終的にコンテナのメモリ上限に達したことを示しています。

検出結果

これらのツールを併用することで、問題の全体像を把握できます。

モニタリングアラートで問題が発生したことが通知されました。
Google Cloud コンソールには、問題がユーザーに影響している（再起動）ことが示されています。
kubectl コマンドで、再起動の正確な理由（OOMKilled）を特定しました。
Metrics Explorer に、メモリリークのパターンが時系列で表示されています。
ログエクスプローラで、メモリの問題の原因となっている特定の動作が明らかになりました。

これで、ソリューションを実装する準備が整いました。アプリコードを最適化して大きなファイルをより効率的に処理するか、短期的な修正として、ワークロードの YAML マニフェストでコンテナのメモリ上限（具体的には spec.containers.resources.limits.memory 値）を引き上げることができます。

次のステップ

特定の問題の解決に関するアドバイスについては、GKE のトラブルシューティングガイドをご覧ください。
このドキュメントに問題のソリューションが見当たらない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。
- Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
- StackOverflow で質問する、google-kubernetes-engine タグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engine Slack チャネルに参加して、コミュニティサポートを利用することもできます。
- 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。