GKE で NotReady ステータスのノードをトラブルシューティングする

Autopilot Standard

Google Kubernetes Engine（GKE）の NotReady ステータスは、ノードの kubelet がコントロール プレーンに正しく報告していないことを意味します。Kubernetes は NotReady ノードに新しい Pod をスケジュールしません。このため、アプリケーションの容量が減少し、ダウンタイムが発生する可能性があります。

このドキュメントでは、予期される NotReady ステータスと実際の問題を区別し、根本原因を診断して、リソースの枯渇、ネットワークの問題、コンテナ ランタイムの障害などの一般的な問題の解決策を見つける方法について説明します。

この情報は、クラスタの安定性を担当するプラットフォーム管理者とオペレーター、およびインフラストラクチャ関連のアプリケーションの動作を把握しようとしているアプリケーション デベロッパーを対象としています。 Google Cloud コンテンツで使用されている一般的なロールとタスクの例については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

始める前に

• このドキュメントのタスクの実行に必要な権限を取得するには、 Google Cloud プロジェクトに対する次の IAM のロールを付与するよう管理者に依頼してください。

  • GKE クラスタにアクセスする: Kubernetes Engine クラスタ閲覧者（roles/container.viewer）。
  • ログを表示する: ログビューア（roles/logging.viewer）。
  • 指標を表示する: モニタリング閲覧者（roles/monitoring.viewer）。

  ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

  必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

• GKE クラスタと通信するように kubectl コマンドライン ツールを構成します。

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location LOCATION \
      --project PROJECT_ID
  

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

  • CLUSTER_NAME: クラスタの名前。
  • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン（us-central1 や us-central1-a など）。
  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

ノードのステータスと条件を確認する

ノードのステータスが NotReady であることを確認し、根本原因の診断に役立てるには、次の手順でノードの条件、イベント、ログ、リソース指標を調べます。

1. ノードのステータスを表示します。診断に役立つ IP アドレスやカーネル バージョンなどの詳細情報を取得するには、-o wide フラグを使用します。

   kubectl get nodes -o wide
   

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

   NAME                                STATUS     ROLES    AGE   VERSION               INTERNAL-IP  EXTERNAL-IP  OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
   gke-cluster-pool-1-node-abc1        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.1   1.2.3.4      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
   gke-cluster-pool-1-node-def2        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.2   5.6.7.8      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
   gke-cluster-pool-1-node-ghi3        NotReady   <none>   94d   v1.32.3-gke.1785003   10.128.0.3   9.10.11.12   Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
   

   出力で、STATUS 列の値が NotReady のノードを探し、その名前をメモします。

2. NotReady ステータスの特定のノードに関する詳細情報（条件や最近の Kubernetes イベントなど）を表示します。

   kubectl describe node NODE_NAME
   

   NODE_NAME は、NotReady ステータスのノードの名前に置き換えます。

   出力で、Conditions セクションに注目してノードの健全性を把握し、Events セクションで最近の問題の履歴を確認します。例:

   Name:                   gke-cluster-pool-1-node-ghi3
   ...
   Conditions:
   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                   Message
   ----                          ------    -----------------                 ------------------                ------                   -------
   NetworkUnavailable            False     Wed, 01 Oct 2025 10:29:19 +0100   Wed, 01 Oct 2025 10:29:19 +0100   RouteCreated             RouteController created a route
   MemoryPressure                Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
   DiskPressure                  Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
   PIDPressure                   False     Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:29:00 +0100   KubeletHasSufficientPID  kubelet has sufficient PID available
   Ready                         Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
   Events:
   Type     Reason                   Age                  From                                   Message
   ----     ------                   ----                 ----                                   -------
   Normal   Starting                 32m                  kubelet, gke-cluster-pool-1-node-ghi3  Starting kubelet.
   Warning  PLEGIsNotHealthy         5m1s (x15 over 29m)  kubelet, gke-cluster-pool-1-node-ghi3  PLEG is not healthy: pleg was last seen active 5m1.123456789s ago; threshold is 3m0s
   Normal   NodeHasSufficientMemory  5m1s (x16 over 31m)  kubelet, gke-cluster-pool-1-node-ghi3  Node gke-cluster-pool-1-node-ghi3 status is now: NodeHasSufficientMemory
   

   Conditions セクションで、否定条件のステータスが True か、Ready 条件のステータスが Unknown の場合、問題が発生しています。これらの条件の Reason フィールドと Message フィールドには、問題の原因が説明されているため、注意してください。

   各条件タイプの意味は次のとおりです。

   • KernelDeadlock: ノードのオペレーティング システム カーネルがデッドロックを検出した場合は True です。デッドロックは、ノードをフリーズさせる可能性のある重大なエラーです。
   • FrequentUnregisterNetDevice: ノードがネットワーク デバイスの登録を頻繁に解除している場合は True です。これは、ドライバまたはハードウェアの問題の兆候である可能性があります。
   • NetworkUnavailable: ノードのネットワーキングが正しく構成されていない場合は True です。
   • OutOfDisk: 使用可能なディスク容量が完全に使い果たされた場合は True です。この状態は DiskPressure よりも深刻です。
   • MemoryPressure: ノードのメモリが少ない場合は True です。
   • DiskPressure: ノードのディスク容量が少ない場合は True です。
   • PIDPressure: ノードでプロセス ID（PID）の枯渇が発生している場合は True です。
   • Ready: ノードが正常で、Pod を受け入れる準備ができているかどうかを示します。
     • ノードが正常な場合は True です。
     • ノードが正常ではなく、Pod を受け入れていない場合は False です。
     • ノード コントローラが猶予期間（デフォルトは 50 秒）を過ぎてもノードから応答を受け取っておらず、ノードのステータスが不明な場合は Unknown です。

   次に、ノードに関するアクションとオブザベーションの時系列ログを提供する Events セクションを確認します。このタイムラインは、ノードが NotReady になる直前に何が起こったかを理解するうえで重要です。原因の特定に役立つ特定のメッセージ（リソース不足を示す削除警告、ヘルスチェックの失敗、修復のためのコーディングなどのノード ライフサイクル イベントなど）を探します。

3. ノードが NotReady ステータスになっている理由について、ノードとそのコンポーネントのログを調べます。

   1. kubelet ログで NotReady ステータスを確認します。

      kubelet はノードのステータスをコントロール プレーンに報告するプライマリ エージェントであるため、そのログは NotReady メッセージが見つかる可能性が最も高い場所です。これらのログは、Pod ライフサイクル イベント、リソースの圧迫状態（MemoryPressure や DiskPressure など）、Kubernetes コントロール プレーンへのノードの接続に関する問題を診断するための信頼できる情報源です。

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

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

   3. クエリペインに次のクエリを入力します。

      resource.type="k8s_node"
      resource.labels.node_name="NODE_NAME"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      log_id("kubelet")
      textPayload=~"(?i)NotReady"
      

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

      • NODE_NAME: 調査するノードの名前。
      • CLUSTER_NAME: クラスタの名前。
      • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン（us-central1 や us-central1-a など）。

   4. [クエリを実行] をクリックして結果を確認します。

   5. kubelet ログで根本原因が特定できない場合は、container-runtime ログと node-problem-detector ログを確認します。これらのコンポーネントは NotReady ステータスを直接ログに記録しない場合がありますが、多くの場合、問題の原因となった根本的な問題（ランタイム エラーやカーネル パニックなど）をログに記録します。

   6. ログ エクスプローラのクエリペインに次のクエリを入力します。

      resource.type="k8s_node"
      resource.labels.node_name="NODE_NAME"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      log_id("COMPONENT_NAME")
      

      COMPONENT_NAME は次のいずれかの値に置き換えます。

      • container-runtime: イメージの pull やコンテナ実行の管理など、コンテナのライフサイクル全体を担うランタイム（containerd）。container-runtime ログの確認は、コンテナのインスタンス化、ランタイム サービスのエラー、ランタイムの構成が原因で発生した問題に関連する障害のトラブルシューティングに不可欠です。
      • node-problem-detector: さまざまなノードレベルの問題をプロアクティブにモニタリングしてコントロール プレーンに報告するユーティリティ。このログは、ノードの不安定性を引き起こす可能性のある根本的なシステムの問題（カーネル デッドロック、ファイル システムの破損、ハードウェア障害など）を特定するために不可欠です。これらの問題は、他の Kubernetes コンポーネントではキャプチャされない可能性があります。

   7. [クエリを実行] をクリックして結果を確認します。

4. Metrics Explorer を使用して、ノードが NotReady になった時間帯のリソース枯渇を探します。

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

      Metrics Explorer に移動

   2. Metrics Explorer を使用して、ノードの基盤となる Compute Engine インスタンスでリソースの枯渇が発生していないか確認します。CPU、メモリ、ディスク I/O の指標に関連する指標に注目します。例:

      • GKE ノード指標: kubernetes.io/node/ で始まる指標（kubernetes.io/node/cpu/allocatable_utilization や kubernetes.io/node/memory/allocatable_utilization など）から始めます。これらの指標は、ノードの使用可能なリソースのうち、Pod で使用されているリソースの量を示します。使用可能な量には、Kubernetes がシステム オーバーヘッド用に予約しているリソースは含まれません。
      • ゲスト OS 指標: ノードのオペレーティング システム内部からのビューの場合は、compute.googleapis.com/guest/ で始まる指標（compute.googleapis.com/guest/cpu/usage や compute.googleapis.com/guest/memory/bytes_used など）を使用します。
      • ハイパーバイザ指標: ハイパーバイザ レベルから VM のパフォーマンスを確認するには、compute.googleapis.com/instance/ で始まる指標（compute.googleapis.com/instance/cpu/utilization など）またはディスク I/O 指標（compute.googleapis.com/instance/disk/read_bytes_count など）を使用します。

      ゲスト OS とハイパーバイザの指標では、Kubernetes ノード名ではなく、基盤となる Compute Engine インスタンス名でフィルタする必要があります。ノードのインスタンス名を確認するには、kubectl describe node NODE_NAME コマンドを実行して、出力の ProviderID フィールドを探します。インスタンス名は、その値の最後の部分です。例:

      ...
      Spec:
      ProviderID: gce://my-gcp-project-123/us-central1-a/gke-my-cluster-default-pool-1234abcd-5678
      ...
      

      この例では、インスタンス名は gke-my-cluster-default-pool-1234abcd-5678 です。

症状から原因を特定する

ログ メッセージ、ノード条件、クラスタ イベントなどの特定の症状を特定した場合は、次の表でトラブルシューティングのアドバイスを見つけてください。

カテゴリ	症状またはログ メッセージ	考えられる原因	トラブルシューティング手順
ノードの条件	NetworkUnavailable: True	ノードからコントロール プレーンへの接続の問題、または Container Network Interface（CNI）プラグインの障害。	ネットワーク接続をトラブルシューティングする
	MemoryPressure: True	ノードのメモリが不足しています。	ノードのリソース不足をトラブルシューティングする
	DiskPressure: True	ノードのディスク容量が不足しています。	ノードのリソース不足をトラブルシューティングする
	PIDPressure: True	ノードで使用可能なプロセス ID が不足しています。	ノードのリソース不足をトラブルシューティングする
イベントとログ メッセージ	PLEG is not healthy	CPU/IO の使用率が高いか、Pod が多すぎるため、Kubelet が過負荷状態になっています。	PLEG の問題を解決する
	Out of memory: Kill process sys oom event	ノードメモリがすべて消費されています。	システムレベルの OOM イベントを解決する
	leases.coordination.k8s.io...is forbidden	kube-node-lease Namespace が終了処理で停止しています。	kube-node-lease Namespace に関する問題を解決する
	Container runtime not ready runtime is down /run/containerd/containerd.sock または docker.sock を示すエラー	Containerd または Docker サービスが失敗したか、正しく構成されていません。	コンテナ ランタイムの問題を解決する
	Pod が Terminating 状態のままになる Kubelet ログにコンテナの強制終了を示す DeadlineExceeded が表示される containerd ログに Kill container メッセージが繰り返し表示される	割り込み不可のディスク スリープ（D 状態）でスタックしているプロセス。多くの場合、I/O に関連しています。	D 状態のままになっているプロセスを解決する
クラスタレベルの症状	DaemonSet のロールアウト後に複数のノードが失敗します。	DaemonSet がノード オペレーションを妨害しています。	サードパーティの DaemonSet に起因する問題を解決する
	監査ログの compute.instances.preempted。	Spot VM がプリエンプトされました。これは想定される動作です。	ノードのプリエンプションを確認する
	kube-system Pod が Pending のままになっています。	アドミッション Webhook が重要なコンポーネントをブロックしています。	アドミッション Webhook によって発生した問題を解決する
	exceeded quota: gcp-critical-pods	割り当てが正しく構成されていないため、システム Pod がブロックされています。	リソース割り当てが原因で発生した問題を解決する

想定される NotReady イベントを確認する

NotReady ステータスは、必ずしも問題を示しているわけではありません。ノードプールのアップグレードなどの計画されたオペレーションの実行中や、特定のタイプの仮想マシンを使用している場合は、想定される動作です。

ノードのライフサイクル オペレーションを確認する

症状:

特定のライフサイクル イベント中に、ノードが一時的に NotReady ステータスを示します。

原因:

ノードのステータスは、一般的なライフサイクル イベントの実行中に一時的に NotReady になります。この動作は、次のようなシナリオでノードが作成または再作成されるたびに発生します。

• ノードプールのアップグレード: アップグレード中に、各ノードがドレインされて置き換えられます。アップグレードされた新しいノードは、初期化が完了してクラスタに参加するまで、ステータスが NotReady になります。
• ノードの自動修復: GKE が機能不全のノードを置き換える場合、プロビジョニング中に置き換え対象のノードが NotReady のままになります。
• クラスタ オートスケーラーのスケールアップ: 新しいノードが追加されると、NotReady ステータスで開始され、完全にプロビジョニングされてクラスタに参加した後に Ready になります。
• インスタンス テンプレートの手動変更: テンプレートの変更を適用すると、GKE はノードを再作成します。新しいノードは、起動フェーズで NotReady ステータスになります。

解決策:

ノードのステータスが NotReady になるのは一時的です。このステータスが 10 分以上続く場合は、他の原因を調査します。

ノードのプリエンプションを確認する

ノードが Spot VM またはプリエンプティブル VM で実行されている場合、Compute Engine はリソースを再利用するためにノードを突然終了する可能性があります。これは、このような短命の仮想マシンでは想定される動作であり、エラーではありません。

症状:

次の症状が見られる場合、ノードの NotReady ステータスは、想定される Spot VM のプリエンプションが原因である可能性があります。

• クラスタ オートスケーラーによって削除されて再作成される前に、ノードが予期せず NotReady ステータスになります。
• Cloud Audit Logs に、基盤となる VM インスタンスの compute.instances.preempted イベントが示されます。

原因:

ノードが Spot VM またはプリエンプティブル VM インスタンスで実行されていて、Compute Engine が別のタスクのためにこれらのコンピューティング リソースを再利用しました。Spot VM はいつでも中断できますが、通常は 30 秒前に終了通知が送信されます。

解決策:

Spot VM またはプリエンプティブル VM は、頻繁な終了を適切に処理するように設計されたフォールト トレラント、ステートレス、またはバッチ ワークロードでのみ使用してください。突然の中断を許容できない本番環境またはステートフル ワークロードの場合は、標準のオンデマンド VM を使用してノードプールをプロビジョニングします。

ノードのリソース不足をトラブルシューティングする

ノードが NotReady になるのは、CPU、メモリ、ディスク容量などの重要なリソースが不足していることが原因であることがよくあります。ノードにこれらのリソースが不足している場合、重要なコンポーネントが正しく機能せず、アプリケーションの不安定性やノードの無応答につながる可能性があります。以降のセクションでは、一般的な不足状態からより深刻なシステム全体のイベントまで、これらの不足がさまざまな形で現れる可能性について説明します。

ノードのリソース不足を解決する

リソースの枯渇は、ワークロードを実行するのに十分な CPU、メモリ、ディスク容量、プロセス ID（PID）がノードにない場合に発生します。この問題により、NotReady ステータスになる可能性があります。

症状:

次のノード条件とログが確認された場合、リソースの枯渇が原因でノードのステータスが NotReady になっている可能性があります。

• kubectl describe node コマンドの出力で、OutOfDisk、MemoryPressure、DiskPressure、PIDPressure などの条件のステータスが True と表示されます。
• kubelet ログに、システムで OOM Killer が呼び出されたことを示す Out of Memory（OOM）イベントが含まれている場合があります。

原因:

ノード上のワークロードが、ノードが提供できるリソースよりも多くのリソースを要求しています。

解決策:

Standard クラスタの場合は、次の解決策を試してください。

• ワークロードの需要を減らす:
  • デプロイのレプリカ数をスケールダウンして、影響を受けるノードで実行されている Pod の数を減らします。詳細については、アプリケーションのスケーリングをご覧ください。
  • アプリケーションを確認して最適化し、リソースの消費量を減らします。
• ノード容量を増やす:
  • ノードに割り当てられた CPU とメモリを増やします。詳細については、ノードマシン属性を変更して垂直方向にスケーリングするをご覧ください。
  • 問題がディスクに関連している場合は、ノードのブートディスクのサイズを増やします。パフォーマンスを向上させるには、SSD ブートディスクの使用を検討してください。

Autopilot クラスタの場合、ノードのマシンタイプやブートディスク サイズを直接制御することはできません。ノード容量は、Pod リクエストに基づいて自動的に管理されます。ワークロードのリソース リクエストが Autopilot の上限内にあり、アプリケーションのニーズを正確に反映していることを確認します。リソースの問題が継続的に発生する場合は、Pod リクエストの最適化が必要であることを示している可能性があります。まれに、Cloud カスタマーケアのサポートが必要なプラットフォームの問題であることもあります。

システムレベルの OOM イベントを解決する

システムレベルのメモリ不足（OOM）イベントは、ノードのメモリの合計が不足し、Linux カーネルがリソースを解放するためにプロセスを終了せざるを得なくなったときに発生します。このイベントは、単一の Pod がメモリ上限を超えた場合に発生するコンテナレベルの OOM イベントとは異なります。

症状:

次の症状が見られる場合、ノードの不安定さの原因はシステムレベルの OOM イベントである可能性があります。

• ノードのシリアル コンソール ログに Out of memory: Kill process メッセージが表示されます。
• kubelet ログに oom_watcher イベントが含まれています。これは、kubelet がシステムレベルの OOM イベントを検出したことを示します。
• メモリ消費量が最も多いとは限らない、潜在的に重要なシステム デーモンやワークロード Pod など、さまざまなプロセスが予期せず終了しています。

原因:

ノードの全体的なメモリが不足しています。この問題は、システム サービスのバグ、過剰なメモリを消費するワークロードの構成ミス、実行中のすべての Pod のメモリ需要に対してノードが小さすぎることが原因で発生する可能性があります。

解決策:

システムレベルの OOM イベントを解決するには、原因を診断し、メモリ需要を減らすか、ノード容量を増やします。詳細については、OOM イベントをトラブルシューティングするをご覧ください。

PLEG の問題を解決する

Pod Lifecycle Event Generator（PLEG）は、kubelet 内のコンポーネントです。ノード上のすべてのコンテナの状態を定期的にチェックし、変更を kubelet に報告します。

PLEG でパフォーマンスの問題が発生すると、kubelet にタイムリーな更新を提供できなくなり、ノードが不安定になる可能性があります。

症状:

次の症状が見られる場合は、PLEG が正しく機能していない可能性があります。

• ノードの kubelet ログに「PLEG is not healthy」のようなメッセージが含まれています。
• ノードのステータスが Ready と NotReady の間で頻繁に切り替わります。

原因:

PLEG の問題は通常、パフォーマンスの問題が原因で、kubelet がコンテナ ランタイムからタイムリーに更新を受け取れない場合に発生します。一般的な原因は次のとおりです。

• CPU 負荷が高い: ノードの CPU が飽和状態になり、kubelet とコンテナ ランタイムに必要な処理能力が不足しています。
• I/O スロットリング: ノードのブートディスクで大量の I/O オペレーションが発生しています。これにより、ディスク関連のすべてのタスクの速度が低下する可能性があります。
• Pod 数が過剰: 単一ノード上の Pod の数が多すぎると、kubelet とコンテナ ランタイムに過剰な負荷がかかり、リソース競合が発生する可能性があります。

解決策:

Standard クラスタの場合は、ノードのリソースへの負荷を軽減します。

• ノードの負荷を軽減する: デプロイをスケールダウンして、ノードの全体的なワークロードを減らします。taint と toleration、ノード アフィニティ、Pod トポロジの分散の制約を使用してスケジューリングに影響を与え、クラスタ内の他のノードに Pod をより均等に分散することもできます。
• CPU 上限を設定する: 単一のワークロードが使用可能なすべての CPU リソースを消費しないように、Pod に CPU 上限を適用します。詳細については、Kubernetes ドキュメントの Pod とコンテナのリソース管理をご覧ください。
• ノード容量を増やす: ワークロードを処理するために、より多くの CPU とメモリを備えた大きなノードの使用を検討します。詳細については、ノードマシン属性を変更して垂直方向にスケーリングするをご覧ください。
• ディスク パフォーマンスを向上させる: 問題が I/O スロットリングに関連している場合は、より大きなブートディスクを使用するか、SSD ブートディスクにアップグレードします。この変更により、ディスクのパフォーマンスが大幅に向上します。詳細については、ディスク パフォーマンスに関する問題のトラブルシューティングをご覧ください。

Autopilot クラスタの場合、既存のノードのサイズやディスクタイプを直接変更することはできませんが、カスタム ComputeClass を使用して、ワークロードが実行されるハードウェアに影響を与えることができます。この機能を使用すると、ワークロード マニフェストで要件（最小 CPU とメモリの量や特定のマシンシリーズなど）を指定して、Pod のスケジュール先を制御できます。

ComputeClass を使用しない場合は、ワークロードのデプロイ（レプリカ数やリソース リクエストまたは上限など）を調整し、Autopilot の制約内に収まるようにします。ワークロードを最適化しても PLEG の問題が解決しない場合は、Cloud カスタマーケアにお問い合わせください。

D 状態のままになっているプロセスを解決する

割り込み不可のディスク スリープ（D 状態）でスタックしたプロセスにより、ノードが応答しなくなることがあります。この問題により、Pod が終了せず、containerd などの重要なコンポーネントが失敗して NotReady ステータスになる可能性があります。

症状:

• Pod（特に NFS などのネットワーク ストレージを使用している Pod）が Terminating ステータスのまま長時間停止しています。
• コンテナの停止を試みると、Kubelet ログに DeadlineExceeded エラーが表示されます。
• ノードのシリアル コンソールログに、hung tasks またはタスクが 120 秒以上ブロックされていることに関するカーネル メッセージが表示されることがあります。

原因:

プロセスは、I/O オペレーションの完了を待機していて、割り込みできない場合に D 状態になります。一般的な原因は次のとおりです。

• リモート ファイル システムの速度が遅い、または応答がない（構成ミスや NFS 共有の過負荷など）。
• ノードのローカル ディスクでディスク パフォーマンスが大幅に低下するか、ハードウェア I/O エラーが発生する。

解決策:

D 状態のプロセスに関する問題を解決するには、I/O ソースを特定し、次のいずれかのオプションを選択して状態をクリアします。

Standard クラスタ

1. 停止しているプロセスを見つけて、そのプロセスが待機しているものを特定します。

   1. 影響を受けたノードに SSH を使用して接続します。

      gcloud compute ssh NODE_NAME \
          --zone ZONE \
          --project PROJECT_ID
      

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

      • NODE_NAME: 接続先のノードの名前。
      • ZONE: ノードの Compute Engine ゾーン。
      • PROJECT_ID: プロジェクト ID。

   2. D 状態のプロセスを見つけます。

      ps -eo state,pid,comm,wchan | grep '^D'
      

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

      D  12345  my-app      nfs_wait
      D  54321  data-writer io_schedule
      

      出力にはヘッダーがありません。列は、次の順に並んでいます。

      • 状態
      • プロセス ID（PID）
      • コマンド
      • 待機チャネル（wchan）

   3. wchan 列で I/O ソースを確認します。

      • wchan 列に nfs や rpc などが含まれている場合、プロセスは NFS 共有を待機しています。
      • wchan 列に io_schedule、jbd2、ext4 などが含まれている場合、プロセスはノードのローカル ブートディスクで待機しています。

   4. プロセスが待機しているカーネル関数の詳細については、プロセスのカーネル コールスタックを確認します。

      cat /proc/PID/stack
      

      PID は、前の手順で確認したプロセス ID に置き換えます。

2. ノードを再起動します。再起動は、D 状態のままになっているプロセスをクリアする最も効果的な方法であることがよくあります。

   1. ノードをドレインします。
   2. 基盤となる VM インスタンスを削除します。通常、GKE は新しい VM を作成して置き換えます。

3. 当面の問題を解決したら、根本原因であるストレージ システムを調査して、再発を防止します。

   • ネットワーク ストレージ（NFS）に問題がある場合: ストレージ プロバイダのモニタリング ツールを使用して、GKE ノードと NFS サーバー間の高レイテンシ、サーバーサイド エラー、ネットワークの問題を確認します。

   • ローカル ディスクに問題がある場合: Compute Engine インスタンスの compute.googleapis.com/instance/disk/throttled_read_ops_count 指標と compute.googleapis.com/instance/disk/throttled_write_ops_count 指標を表示して、Cloud Monitoring で I/O スロットリングを確認します。

Autopilot クラスタ

1. ブロックの原因を特定します。

   Autopilot クラスタでは、ノードへの直接 SSH アクセスや、ps や cat /proc などのコマンドの実行はできません。ログと指標を使用する必要があります。

   1. ノードログを確認する: Cloud Logging で、影響を受けたノードのログを分析します。ノード名と問題の時間枠でフィルタします。I/O エラー、ストレージ タイムアウト（ディスクや NFS など）、CSI ドライバからのメッセージを示すカーネル メッセージを探します。
   2. ワークロード ログを確認する: 影響を受けるノードで実行されている Pod のログを調べます。アプリケーション ログには、ファイル オペレーション、データベース呼び出し、ネットワーク ストレージ アクセスに関連するエラーが記録されている場合があります。
   3. Cloud Monitoring を使用する: プロセスレベルの詳細は取得できませんが、ノードレベルの I/O の問題を確認します。

2. ノードの交換をトリガーして状態をクリアします。

   基盤となる VM を手動で削除することはできません。置き換えをトリガーするには、ノードをドレインします。この操作により、ノードが分離され、Pod が強制排除されます。

   GKE は異常なノードを自動的に検出し、通常は基盤となる VM を置き換えることで修復を開始します。

   ドレイン後にノードが停止したままになり、自動的に置き換えられない場合は、Cloud カスタマーケアにお問い合わせください。

3. 当面の問題を解決したら、根本原因であるストレージ システムを調査して、再発を防止します。

   • ローカル ディスクに問題がある場合: compute.googleapis.com/instance/disk/throttled_read_ops_count 指標と compute.googleapis.com/instance/disk/throttled_write_ops_count 指標を表示して、Cloud Monitoring で I/O スロットリングを確認します。これらの指標は、ノードプールの基盤となるインスタンス グループでフィルタできます。ただし、個々のインスタンスは Google によって管理されます。
   • ネットワーク ストレージ（NFS）に問題がある場合: ストレージ プロバイダのモニタリング ツールを使用して、GKE ノードと NFS サーバー間の高レイテンシ、サーバーサイド エラー、ネットワークの問題を確認します。Cloud Logging で CSI ドライバ Pod のログを確認します。

コア コンポーネントの障害をトラブルシューティングする

想定される原因とリソース不足を除外した後、ノードのソフトウェアまたは Kubernetes のコアメカニズムが問題の原因である可能性があります。NotReady ステータスは、コンテナ ランタイムなどの重要なコンポーネントが失敗した場合に発生することがあります。また、ノードリース システムなどの Kubernetes のコア ヘルスチェック メカニズムが機能しなくなった場合にも発生する可能性があります。

コンテナ ランタイムの問題を解決する

containerd などのコンテナ ランタイムの問題により、kubelet がノードで Pod を起動できないことがあります。

症状:

kubelet ログに次のメッセージが表示されている場合、コンテナ ランタイムの問題が原因でノードのステータスが NotReady になっている可能性があります。

• Container runtime not ready
• Container runtime docker failed!
• docker daemon exited
• ランタイム ソケット（unix:///var/run/docker.sock や unix:///run/containerd/containerd.sock など）への接続エラー。

原因:

コンテナ ランタイムが正しく機能していないか、構成が誤っています。あるいは、再起動ループに陥っています。

解決策:

コンテナ ランタイムの問題を解決するには、次の操作を行います。

1. コンテナ ランタイム ログを分析する:

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

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

   2. 影響を受けるノードのコンテナ ランタイムの警告ログとエラーログをすべて表示するには、クエリペインに次の内容を入力します。

      resource.type="k8s_node"
      resource.labels.node_name="NODE_NAME"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      log_id("container-runtime")
      severity>=WARNING
      

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

      • NODE_NAME: 調査するノードの名前。
      • CLUSTER_NAME: クラスタの名前。
      • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン（us-central1 や us-central1-a など）。

   3. [クエリを実行] をクリックし、ランタイムが失敗した理由を示す特定のエラー メッセージの出力を確認します。Cloud Logging の containerd ログに failed to load TOML などのメッセージが表示される場合、多くはファイル形式が正しくないことを示しています。

   4. ランタイムが再起動ループで停止しているかどうかを確認するには、起動メッセージを検索するクエリを実行します。このメッセージが短期間に多数表示される場合は、頻繁に再起動していることを示します。

      resource.type="k8s_node"
      resource.labels.node_name="NODE_NAME"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      log_id("container-runtime")
      ("starting containerd" OR "Containerd cri plugin version" OR "serving..."
      OR "loading plugin" OR "containerd successfully booted")
      

      頻繁な再起動は、構成ファイルの破損やリソースの圧迫など、サービスが繰り返しクラッシュする根本原因を示していることがよくあります。

2. containerd 構成の変更を確認する: 設定が正しくないと、コンテナ ランタイムが失敗する可能性があります。構成の変更は、ノードシステム構成ファイルを介して行うか、権限が昇格されたワークロードによって直接変更できます。

   1. ノードプールがノードシステム構成ファイルを使用しているかどうかを確認します。

      gcloud container node-pools describe NODE_POOL_NAME \
          --cluster CLUSTER_NAME \
          --location LOCATION \
          --format="yaml(config.containerdConfig)"
      

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

      • NODE_POOL_NAME: ノードプールの名前。
      • CLUSTER_NAME: クラスタの名前。
      • LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。

      出力に containerdConfig セクションが表示されている場合、GKE はこれらのカスタム設定を管理しています。設定を変更または元に戻すには、GKE ノードで containerd 構成をカスタマイズするの手順に沿って操作します。

   2. GKE 管理のカスタマイズが有効になっていない場合や、他の変更が疑われる場合は、ノードのファイル システムを直接変更している可能性のあるワークロードを探します。権限（securityContext.privileged: true）が昇格している DaemonSet や、/etc などの機密性の高いディレクトリをマウントしている hostPath ボリュームを探します。

      構成を調べるには、すべての DaemonSet を YAML 形式で一覧表示します。

      kubectl get daemonsets --all-namespaces -o yaml
      

      出力を確認し、不審な DaemonSet のログを調べます。

   3. Standard クラスタの場合は、構成ファイルを直接検査します。Google がランタイム構成を管理するため、Autopilot クラスタでは SSH アクセスと手動ファイル検査はできません。ランタイムの問題が解決しない場合は、Google Cloud カスタマーケアにお問い合わせください。

      重要: 次の手順は検査のみを目的としています。変更は GKE によって上書きされる可能性があるため、ノードで /etc/containerd/config.toml ファイルを直接編集しないでください。永続的な変更を適用するには、ノード構成ファイルを使用します。

      Standard クラスタを使用する場合は、ファイルを検査します。

      1. SSH を使用してノードに接続します。

         gcloud compute ssh NODE_NAME \
             --zone ZONE \
             --project PROJECT_ID
         

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

         • NODE_NAME: 接続先のノードの名前。
         • ZONE: ノードの Compute Engine ゾーン。
         • PROJECT_ID: プロジェクト ID。

      2. containerd 構成ファイルの内容を表示します。

         sudo cat /etc/containerd/config.toml
         

      3. 最近の変更を確認するには、ファイルの詳細を一覧表示します。

         ls -l /etc/containerd/config.toml
         

   4. このファイルの内容と、前の手順で実行した gcloud node-pools describe コマンドの containerdConfig 出力を比較します。/etc/containerd/config.toml の設定のうち、gcloud の出力に含まれていないものは、管理されていない変更です。

   5. 構成の誤りを修正するには、ノードシステム構成で適用されていない変更を削除します。

3. 一般的なランタイムの問題をトラブルシューティングする: その他のトラブルシューティングの手順については、コンテナ ランタイムのトラブルシューティングをご覧ください。

kube-node-lease Namespace に関する問題を解決する

kube-node-lease Namespace のリソースは、ノードの健全性を維持する役割を担います。この Namespace は削除しないでください。この Namespace を削除しようとすると、Namespace が Terminating ステータスのままになります。kube-node-lease Namespace が Terminating ステータスで停止すると、kubelet はヘルスチェック リースを更新できません。この問題により、コントロール プレーンはノードが正常でないと判断し、ノードのステータスが Ready と NotReady の間で交互に切り替わるクラスタ全体の問題が発生します。

症状:

次の症状が見られる場合は、kube-node-lease Namespace の問題がクラスタ全体の不安定さの原因となっている可能性があります。

• すべてのノードの kubelet ログに、次のようなエラーが継続的に表示されます。

  leases.coordination.k8s.io NODE_NAME is forbidden: unable to create new content in namespace kube-node-lease because it is being terminated
  

• クラスタ内のノードのステータスが Ready と NotReady の間で繰り返し切り替わります。

原因:

ノードのハートビートを管理する kube-node-lease Namespace が Terminating ステータスのままになっています。このエラーにより、Kubernetes API サーバーは Namespace 内のオブジェクトの作成や変更を許可できなくなります。その結果、kubelet はコントロール プレーンに liveness を通知するために不可欠な Lease オブジェクトを更新できません。これらのステータス更新がないと、コントロール プレーンはノードが正常であることを確認できず、ノードのステータスが Ready と NotReady の間で交互に切り替わります。

kube-node-lease Namespace 自体が Terminating ステータスで停止する根本的な原因は次のとおりです。

• ファイナライザを含むリソース: システム kube-node-lease Namespace（主に Lease オブジェクトを含む）では一般的ではありませんが、そのリソースにファイナライザが含まれている可能性があります。Kubernetes ファイナライザは、リソースを削除する前にコントローラがクリーンアップ タスクを実行する必要があることを示すキーです。ファイナライザの削除を担当するコントローラが正しく機能していない場合、リソースは削除されず、Namespace の削除プロセスが停止します。
• 集約された API サービスが異常または応答しない: 集約された API サーバーの登録に使用される APIService オブジェクトが Namespace にリンクされ、異常になると、Namespace の終了がブロックされる可能性があります。コントロール プレーンは、集約された API サーバーが適切にシャットダウンまたはクリーンアップされるのを待機することがあります。サービスが応答しない場合、これは発生しません。
• コントロール プレーンまたはコントローラの問題: まれに、Kubernetes コントロール プレーン（特に Namespace コントローラ）内のバグや問題により、Namespace のガベージ コレクションと削除が正常に完了しないことがあります。

解決策:

Namespace が終了状態のままになる場合のトラブルシューティングのガイダンスに従います。

ネットワーク接続をトラブルシューティングする

ネットワークの問題により、ノードがコントロール プレーンと通信できなくなったり、CNI プラグインなどの重要なコンポーネントが機能しなくなり、NotReady ステータスになることがあります。

症状:

次の症状が見られる場合は、ネットワークの問題がノードの NotReady ステータスの原因である可能性があります。

• NetworkNotReady 条件は True です。
• ノードの Kubelet ログに、次のようなエラーが表示されます。
  • connection timeout to the control plane IP address
  • network plugin not ready
  • CNI plugin not initialized
  • コントロール プレーンの IP アドレスにアクセスしようとしたときに connection refused または timeout メッセージが表示される。
• Pod（特に kube-system Namespace の Pod）が ContainerCreating でスタックし、NetworkPluginNotReady などのイベントが発生する。

原因:

ネットワーク関連の症状は通常、次のいずれかの領域の障害を示します。

• 接続の問題: ノードが Kubernetes コントロール プレーンへの安定したネットワーク接続を確立できません。
• CNI プラグインの障害: Pod ネットワーキングの構成を担当する CNI プラグインが正しく実行されていないか、初期化に失敗しています。
• Webhook の問題: アドミッション Webhook の構成が誤っていると、CNI プラグイン関連のリソースが妨害され、ネットワークが正しく構成されなくなる可能性があります。

解決策:

ネットワークの問題を解決するには、次の操作を行います。

1. 一時的な NetworkNotReady ステータスに対処する: 新しく作成されたノードで、短い NetworkNotReady イベントが発生するのは正常です。このステータスは、CNI プラグインと他のコンポーネントが初期化されると、1～2 分以内に解決されます。このステータスが引き続き表示される場合は、次の手順に進みます。

2. ノードとコントロール プレーン間の接続とファイアウォール ルールを確認する: ノードとコントロール プレーン間のネットワーク パスが開いていて、正しく機能していることを確認します。

   1. ファイアウォール ルールを確認する: VPC ファイアウォール ルールで、GKE ノードとコントロール プレーン間の必要なトラフィックが許可されていることを確認します。ノードとコントロール プレーン間の通信に必要な GKE のルールについては、自動的に作成されるファイアウォール ルールをご覧ください。
   2. 接続をテストする: Network Intelligence Center の接続テストを使用して、ノードの内部 IP アドレスとポート 443 のコントロール プレーンのエンドポイント IP アドレス間のネットワーク パスを確認します。Not Reachable の結果は、通信をブロックしているファイアウォール ルールまたはルーティングの問題を特定する際に役立ちます。

3. CNI プラグインのステータスとログを調査する: ノードのネットワークが準備できていない場合、CNI プラグインに問題がある可能性があります。

   1. CNI Pod のステータスを確認する: 使用中の CNI プラグイン（netd や calico-node など）を特定し、kube-system Namespace 内の Pod のステータスを確認します。次のコマンドを使用して、特定のノードをフィルタできます。

      kubectl get pods \
          -n kube-system \
          -o wide \
          --field-selector spec.nodeName=NODE_NAME \
          | grep -E "netd|calico|anetd"
      

   2. CNI Pod のログを調べる: Pod が正しく機能していない場合は、Cloud Logging でログを調べて、詳細なエラー メッセージを確認します。特定のノードの netd Pod には、次のようなクエリを使用します。

      resource.type="k8s_container"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      resource.labels.namespace_name="kube-system"
      labels."k8s-pod/app"="netd"
      resource.labels.node_name="NODE_NAME"
      severity>=WARNING
      

   3. 特定の CNI エラーに対処する:

      • ログに Failed to allocate IP address が示されている場合は、Pod の IP アドレス範囲が枯渇している可能性があります。Pod IP アドレスの使用率を確認し、クラスタの CIDR 範囲を確認します。
      • ログに NetworkPluginNotReady または cni plugin not initialized が示されている場合は、ノードに十分な CPU とメモリリソースがあることを確認します。CNI Pod を削除して再起動することもできます。これにより、DaemonSet が Pod を再作成します。
      • GKE Dataplane V2 を使用していて、ログに Cilium API client timeout exceeded が示される場合は、ノードで anetd Pod を再起動します。

   4. アドミッション Webhook の干渉を確認する: 誤動作している Webhook があると、CNI Pod が起動せず、ノードが NetworkNotReady ステータスのままになることがあります。

   5. API サーバーのログを確認する: Cloud Logging で API サーバーのログを確認し、Webhook 呼び出しに関連するエラーがないか確認します。Webhook が CNI リソースの作成をブロックしているかどうかを確認するには、failed calling webhook などのメッセージを検索します。

      Webhook が問題の原因となっている場合は、問題のある ValidatingWebhookConfiguration または MutatingWebhookConfiguration を特定し、一時的に無効にしてノードを準備状態にする必要があります。詳細については、アドミッション Webhook によって発生した問題を解決するをご覧ください。

クラスタの構成ミスをトラブルシューティングする

以降のセクションでは、通常のノード オペレーションを妨げている可能性のあるクラスタ全体の構成を監査する方法について説明します。

アドミッション Webhook によって発生した問題を解決する

アドミッション Webhook の構成が誤っていたり、アドミッション Webhook が使用できないか遅すぎる場合は、重要な API リクエストをブロックし、重要なコンポーネントの起動やノードのクラスタへの参加を妨げる可能性があります。

症状:

次の症状が見られる場合は、構成が誤っているか使用できないアドミッション Webhook が、クラスタの重要なオペレーションをブロックしている可能性があります。

• Pod（特に kube-system Namespace の Pod（CNI Pod やストレージ Pod など））が Pending または Terminating ステータスのままになる。
• 新しいノードがクラスタに参加できない。多くの場合、NotReady ステータスでタイムアウトします。

原因:

構成が誤っているか応答しないアドミッション Webhook が、クラスタの重要なオペレーションをブロックしている可能性があります。

解決策:

Webhook 構成を確認して、復元力があり、スコープが適切に設定されていることを確認します。停止を防ぐには、重要度の低い Webhook の failurePolicy フィールドを Ignore に設定します。重要な Webhook の場合は、バッキング サービスが高可用性であることを確認してから、namespaceSelector を使用して kube-system Namespace を Webhook の監視から除外し、コントロール プレーンのデッドロックを回避します。詳細については、Webhook 使用時のコントロール プレーンの安定性を確保するをご覧ください。

リソース割り当てが原因で発生した問題を解決する

kube-system Namespace のリソース割り当てが正しく計算されていないと、GKE で重要なシステム Pod を作成できなくなる可能性があります。ネットワーキング（CNI）や DNS などのコンポーネントがブロックされるため、この問題により、新しいノードがクラスタに正常に参加できなくなることがあります。

症状:

• kube-system Namespace の重要な Pod（netd、konnectivity-agent、kube-dns など）が Pending ステータスのままになります。
• クラスタログまたは kubectl describe pod 出力のエラー メッセージに、exceeded quota: gcp-critical-pods などの障害が表示されます。

原因:

この問題は、Kubernetes リソース割り当てコントローラが ResourceQuota オブジェクトの使用数を正確に更新しなくなった場合に発生します。一般的な原因は、コントローラの更新をブロックするサードパーティのアドミッション Webhook の誤動作です。これにより、割り当て使用量が実際よりもはるかに多く表示されます。

解決策:

1. 問題のある Webhook が根本原因である可能性が高いため、アドミッション Webhook が原因で発生した問題を解決するの手順に沿って、システム コンポーネントをブロックしている可能性のある Webhook を特定して修正します。通常、Webhook を修正すると、割り当ての問題は自動的に解決されます。

2. 記録された割り当て使用量が、実行中の Pod の実際の数と同期していないことを確認します。この手順では、ResourceQuota オブジェクトのカウントが正しくないかどうかを確認します。

   1. 報告された割り当て使用量を確認します。

      kubectl get resourcequota gcp-critical-pods -n kube-system -o yaml
      

   2. Pod の実際の数を確認します。

      kubectl get pods -n kube-system --no-headers | wc -l
      

3. ResourceQuota の使用数が正しくないと思われる場合（実際の Pod 数よりもはるかに多いなど）、gcp-critical-pods オブジェクトを削除します。GKE コントロール プレーンは、正しい調整済みの使用回数でこのオブジェクトを自動的に再作成するように設計されています。

   kubectl delete resourcequota gcp-critical-pods -n kube-system
   

4. kube-system Namespace を数分間モニタリングして、オブジェクトが再作成され、保留中の Pod のスケジューリングが開始されることを確認します。

サードパーティの DaemonSet に起因する問題を解決する

セキュリティ、モニタリング、ロギングによく使用される、新しくデプロイまたは更新されたサードパーティの DaemonSet が、ノードの不安定性を引き起こすことがあります。この問題は、DaemonSet がノードのコンテナ ランタイムまたはネットワーキングを妨害したり、システム リソースを過剰に消費したり、予期しないシステム変更を行った場合に発生する可能性があります。

症状:

次の症状が見られる場合は、最近デプロイまたは変更されたサードパーティの DaemonSet がノード障害の原因である可能性があります。

• DaemonSet のデプロイまたは更新の直後に、クラスタ全体にわたる複数のノードが NotReady ステータスになります。
• 影響を受けるノードの Kubelet ログに、次のようなエラーが報告されます。
  • container runtime is down
  • Failed to create pod sandbox
  • コンテナ ランタイム ソケット（/run/containerd/containerd.sock など）への接続エラー。
• システム Pod や DaemonSet 独自の Pod などが PodInitializing 状態または ContainerCreating 状態で停止している。
• アプリケーションのコンテナログに、exec format error などの異常なエラーが示される。
• Node Problem Detector が、ランタイムの健全性またはリソースの負荷に関連する条件を報告することがある。

原因:

サードパーティの DaemonSet がノードの安定性に影響する原因として、次のことが考えられます。

• CPU、メモリ、ディスク I/O を過剰に消費し、重要なノード コンポーネントのパフォーマンスに影響を与えている。
• コンテナ ランタイムのオペレーションを妨害する。
• ノードのネットワーク構成または Container Network Interface（CNI）プラグインとの競合が発生する。
• システム構成やセキュリティ ポリシーが意図しない方法で変更されている。

解決策:

DaemonSet が原因かどうかを判断するには、DaemonSet を分離してテストします。

1. DaemonSet を特定する: クラスタで実行されているすべての DaemonSet を一覧表示します。

   kubectl get daemonsets --all-namespaces
   

   デフォルトの GKE インストールに含まれていない DaemonSet には特に注意してください。

   多くの場合、次の内容を確認することで、これらの DaemonSet を特定できます。

   • Namespace: 通常、デフォルトの GKE コンポーネントは kube-system Namespace で実行されます。他の Namespace の DaemonSet は、サードパーティ製またはカスタムである可能性があります。
   • 命名: デフォルトの DaemonSet には、gke-metrics-agent、netd、calico-node などの名前が付けられていることがよくあります。サードパーティ エージェントには、製品を反映した名前が付けられていることがよくあります。

2. デプロイ時間を関連付ける: NotReady ノードの出現が、特定のサードパーティの DaemonSet のデプロイまたは更新と一致するかどうかを確認します。

3. 単一ノードでテストする:

   1. 影響を受けるノードを 1 つ選択します。
   2. ノードを閉鎖してドレインします。
   3. このノードで DaemonSet がスケジュールされないように一時的に設定します。
      • 一時的なノードラベルを適用し、DaemonSet のマニフェストでノード アフィニティまたはアンチ アフィニティを構成します。
      • その特定のノードで DaemonSet の Pod を削除します。
   4. ノードの仮想マシン インスタンスを再起動します。
   5. DaemonSet がノードで実行されていない間、ノードが Ready になり、安定した状態を維持しているかどうかを確認します。DaemonSet を再度導入した後に問題が再発した場合は、その DaemonSet が原因である可能性が高くなります。

4. ベンダーに問い合わせる: サードパーティ エージェントが原因である疑いがある場合は、ベンダーのドキュメントで既知の互換性の問題や、GKE でエージェントを実行するためのベスト プラクティスを確認します。さらにサポートが必要な場合は、ソフトウェア ベンダーにお問い合わせください。

ノードが復元されたことを確認する

解決策を適用したら、次の手順でノードが正常に復元され、安定していることを確認します。

1. ノードのステータスを確認します。

   kubectl get nodes -o wide
   

   出力で影響を受けるノードを探します。Status 列に Ready の値が表示されるようになります。修正が適用されてからステータスが更新されるまで、数分かかることがあります。ステータスが NotReady のままの場合や、ステータスが切り替わる場合は、問題が完全に解決していません。

2. ノードの Conditions セクションを検査します。

   kubectl describe node NODE_NAME
   

   Conditions セクションで、次の値を確認します。

   • Ready 条件のステータスは True です。
   • 以前にステータスが True だった否定条件（MemoryPressure や NetworkUnavailable など）のステータスが False になっています。これらの条件の Reason フィールドと Message フィールドに、問題が解決されたことが示されている必要があります。

3. Pod のスケジューリングをテストします。以前にノードでワークロードを実行できなかった場合は、新しい Pod がノードにスケジュールされているかどうか、既存の Pod が問題なく実行されているかどうかを確認します。

   kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
   

   ノード上の Pod のステータスは Running または Completed である必要があります。Pod が Pending などのエラー ステータスで停止することはありません。

次のステップ

• このドキュメントで問題を解決できない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。

  • Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
  • StackOverflow で質問する、google-kubernetes-engine タグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engine Slack チャネルに参加して、コミュニティ サポートを利用することもできます。
  • 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。