Windows Server ノードプールのトラブルシューティング

Google Kubernetes Engine（GKE）で Windows Server ノードプールを実行している場合、Pod の起動失敗、Windows コンテナ イメージの pull エラー、ネットワーク接続の問題、ノードの起動失敗などの問題が発生することがあります。

このドキュメントでは、これらの一般的な問題を診断して解決し、Windows ベースのアプリケーションを確実に実行する方法について説明します。

この情報は、Windows ノードプールを含む GKE クラスタを管理するプラットフォーム管理者と運用担当者、および GKE で Windows ベースのアプリケーションをデプロイして実行するアプリケーション デベロッパーにとって重要です。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

一般的なガイダンスについては、Pod のデバッグと Service に関する Kubernetes のドキュメントをご覧ください。

containerd ノードに関する問題

containerd ノードイメージを使用している場合に問題を解決する方法については、Windows Server ノードプールに関する問題をご覧ください。

Windows Pod が起動しない

ベースイメージと Windows Server ホスト OS のバージョン間に互換性がないと、Pod が起動しないことがあります。

現象

  • Windows Pod が起動しない。
  • ノードは NotReady ステータスを報告します。

原因

コンテナ イメージが、ホストノードの Windows Server バージョンと互換性のない古いベース Windows イメージでビルドされている。

解決策

2020 年 3 月以降の Windows Update が含まれるベース Windows イメージを使用してコンテナ イメージを構築します。Microsoft コンテナの互換性について詳しくは、2020 年 2 月の Windows Server コンテナの非互換性の問題に関する Microsoft のドキュメントをご覧ください。

Image pull のエラー

Windows Server コンテナ イメージは Linux イメージよりも大幅に大きくなることが多く、タイムアウトが発生する可能性があります。

現象

  • Failed to pull image や context cancelled などのエラー メッセージ。
  • Pod に ErrImagePull ステータスが表示されます。

原因

Windows Server コンテナ イメージとそれを構成する個々のレイヤが大きくなる場合があります。そうしたサイズになると、コンテナレイヤをダウンロードして抽出するときに、kubelet エージェントがタイムアウトして失敗するおそれがあります。

解決策

これらのイメージ pull の失敗を解決するには、次の解決策を試してください。

  • ノード CPU を増やす: コンテナ抽出はコア間で並列に実行されるため、コア数が多いマシンタイプのほうが全体的な pull 時間が短縮されます。
  • イメージレイヤを最適化する: Docker レイヤ キャッシュを改善し、イメージ pull の再試行が成功する可能性を高めるには、アプリケーション レイヤをより小さなレイヤに分割します。詳細については、Docker ストレージ ドライバのドキュメントのイメージとレイヤをご覧ください。
  • 手動プルを使用する: Pod を作成する前に、Windows Server ノードに接続し、コンテナ イメージで docker pull コマンドを手動で実行します。

一般的なアドバイスについては、イメージの pull のトラブルシューティングをご覧ください。

サポート終了となったイメージ ファミリー

GKE は、ベンダーのサポートが終了すると、古い Windows Server イメージ ファミリーを定期的に非推奨にします。この非推奨により、これらのイメージを使用したノードプールの作成がブロックされます。

現象

Windows イメージを使用してノードプールを作成すると、次のようなエラーが発生します。

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

原因

選択した Windows Server イメージ ファミリーは、GKE でサポートされなくなりました。

解決策

使用可能でサポートされている Windows イメージを選択します。GKE と Windows バージョンのマッピングで説明しているように、GKE Windows ノードイメージのサポート終了日は gcloud container get-server-config コマンドで確認できます。

ノードプールの作成中のタイムアウト

多数の Windows Server ノードを同時に初期化すると、タイムアウトが発生する可能性があります。

現象

ノードプールの作成オペレーションが完了する前にタイムアウトする。

原因

多数のノード（たとえば、500 個）を作成し、Windows Server イメージを使用するクラスタ内の最初のノードプールである場合、ノードプールの作成がタイムアウトになります。

解決策

ノードプールの作成時に初期ノード数を減らします。ノードプールの作成後に、ノード数を増やすことができます。

エラー PLEG is not healthy が発生し、Windows ノードが NotReady になる

単一ノードで複数の Windows コンテナを迅速にスケジュールすると、Pod Lifecycle Event Generator（PLEG）が過負荷になる可能性があります。

現象

  • Windows ノードが NotReady ステータスになる。
  • イベントまたはログに PLEG is not healthy エラー メッセージが表示される。

原因

1 つの Windows ノードで複数の Pod を急激に起動すると、Kubernetes の既知の問題が発生します。

解決策

PLEG の障害から復旧し、再発を防ぐには:

  • 影響を受ける Windows Server ノードを再起動します。
  • Windows Pod の作成を 30 秒ごとに 1 つ以下に制限します。

一貫性がない TerminationGracePeriod

Windows コンテナのシャットダウン タイマーと Kubernetes の猶予期間の設定が異なると、コンテナが予期せず終了することがあります。

現象

TerminationGracePeriodSeconds フィールドで構成された期間が経過する前に、コンテナが Windows によって強制終了されます。

原因

コンテナの内部 Windows システム タイムアウトが、Kubernetes Pod マニフェストで指定された猶予期間と異なる。

解決策

Windows コンテナのタイムアウトを変更するには、イメージのビルド時にコンテナ ローカルのレジストリキーを編集します。Pod マニフェストの TerminationGracePeriodSeconds フィールドを適宜調整します。

ネットワーク接続の問題

Windows Server コンテナ ネットワーキングと Google Cloud ネットワーク間の最大伝送単位（MTU）サイズの不一致により、パケットが破棄される可能性があります。

現象

Windows Server コンテナ内で実行されているアプリケーションで、ネットワーク接続の障害やパケットのドロップが発生します。

原因

Windows Server コンテナ ネットワーキングは、ネットワーク MTU 1500 を前提としていることがよくあります。この MTU は、 Google Cloudの MTU 1460 と互換性がありません。

解決策

コンテナ ネットワーク インターフェースの MTU と Windows Server ノードのネットワーク インターフェースの MTU 値の両方を 1460 以下に構成します。詳細については、Compute Engine のドキュメントの Windows コンテナの既知の問題をご覧ください。

ノードの起動に関する問題

新しい Windows Server インスタンスで、初期化スクリプトの完了やコントロール プレーンへの登録が失敗することがあります。

現象

Windows Server ノードが初期化に失敗するか、クラスタへの参加に失敗します。

原因

ノードの初期化中にエラーが発生すると、ノードが起動したり、クラスタに参加したりできなくなります。

解決策

問題の原因となっている起動エラーを特定するには、ノードのシリアルポートの出力を確認します。

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

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

1.24 以前を実行している Windows ノードでサービスが断続的にアクセス不能になる

バージョン 1.24 以前を実行しているクラスタでは、kube-proxy コンポーネントを再起動すると、ホスト ネットワーク サービス（HNS）ロードバランサ ルールが再処理される間、一時的なネットワーク ルーティングの遅延が発生します。

現象

Windows ノードで実行されている Pod からサービスに断続的にアクセスできなくなる。

原因

バージョン 1.24 以前を実行している GKE クラスタでは、イベントによって Windows ノードの kube-proxy コンポーネントが再起動されると（ノードの起動、ノードのアップグレード、手動再起動など）、コンポーネントはすべての HNS ロードバランサ ルールを同期して再作成する必要があります。クラスタにこのようなルールが多数ある場合、ルールの処理に大幅な遅延が発生し、ルールごとに約 30 秒かかることがあります。この同期の遅延中、そのノードで実行されている Pod からサービスに断続的にアクセスできなくなります。詳しくは、GitHub で元の問題をご覧ください。

解決策

クラスタ コントロール プレーンをバージョン 1.25 以降にアップグレードします。この動作は、GitHub の pull リクエストで説明されているように、新しいバージョンで大幅に改善されています。

次のステップ

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