Windows Server ノードプールを使用したクラスタの作成

スタンダード

このページでは、Microsoft Windows Server を実行するノードプールを使用して、Google Kubernetes Engine（GKE）クラスタを作成する方法について説明します。このクラスタでは、Windows Server コンテナを使用できます。Microsoft Hyper-V コンテナは、現時点ではサポートされていません。Linux コンテナと同様に、Windows Server コンテナではプロセスと Namespace を分離できます。

Windows Server ノードには、一般的な Linux ノードよりも多くのリソースが必要です。Windows Server ノードには、Windows OS の実行とコンテナで実行できない Windows Server コンポーネントのために、追加のリソースが必要です。Windows Server ノードでは、Linux ノードよりも多くのリソースが必要になるため、割り当て可能なリソースが少なくなります。

Windows Server ノードプールを使用したクラスタの作成

このセクションでは、Windows Server コンテナを使用するクラスタを作成します。

このクラスタを作成するには、以下のタスクを実行する必要があります。

Windows Server ノードイメージを選択する
gcloud を更新して構成する
クラスタとノードプールを作成する
kubectl 認証情報を取得する
クラスタの初期化を待機する

Windows Server ノードイメージを選択する

GKE で実行するには、Windows Server バージョン 2019（LTSC）、Windows Server バージョン 20H2（SAC）、または Windows Server バージョン 2022（LTSC）で Windows Server コンテナイメージをビルドする必要があります。1 つのクラスタで、異なる Windows Server バージョンを使用する複数の Windows Server ノードプールを使用できますが、各ノードプールで使用できる Windows Server のバージョンは 1 つのみです。

ノードイメージを選択する際は、次の点を考慮してください。

サポートのタイミング:
- OS イメージのサポートポリシーで説明されているように、Windows Server ノードイメージのサポートには Microsoft が提供するサポート時間が適用されます。GKE と Windows バージョンのマッピングで説明しているように、GKE Windows ノードイメージのサポート終了日は gcloud container get-server-config コマンドで確認できます。
- SAC のバージョンでは、最初のリリースから 18 か月間に限って Microsoft のサポートを受けられます。ノードプールのイメージタイプとして SAC を選択したものの、新しい SAC バージョンを対象とする新しい GKE バージョンにノードプールをアップグレードしない場合、SAC バージョンのサポートライフサイクルが終了すると、ノードプールに新しいノードを作成できなくなります。Google による Windows Server オペレーティングシステムのサポートの詳細をご覧ください。サポートライフサイクルがより長いため、LTSC の使用をおすすめします。
- Stable リリースチャンネルに GKE クラスタを登録している場合は、SAC を選択しないでください。SAC のバージョンでは、18 か月間のみ Microsoft によるサポートを受けられます。そのため、GKE の安定バージョンがまだ利用可能な間に、SAC ノードプールイメージがサポートされなくなるリスクがあります。
バージョンの互換性と複雑さ:
- SAC は、ノードプールと、その中で定期的に実行されているコンテナをアップグレードできる場合にのみ選択してください。GKE は、新しい GKE リリースで Windows ノードプールに使用される SAC バージョンを定期的に更新します。そのため、ノードプールのイメージタイプに対して SAC を選択した場合、コンテナの再構築を頻繁に行う必要が生じます。
- 使用する Windows Server のイメージタイプがわからない場合は、Windows Server LTSC を選択して、ノードプールをアップグレードする際のバージョンの非互換性の問題を回避することをおすすめします。詳細については、Microsoft のドキュメントの Windows Server サービスチャネル: LTSC と SAC をご覧ください。
- Windows Server Core と Nano Server の両方をコンテナのベースイメージとして使用できます。
- Windows Server コンテナには、バージョンの互換性に関する重要な要件があります。
  - LTSC 用に構築された Windows Server コンテナは、SAC ノードでは動作せず、その逆も同様です。
  - 特定の LTSC バージョンまたは SAC バージョン用にビルドされた Windows Server コンテナは、他のバージョンを対象とするように再ビルドしないと、他の LTSC バージョンまたは SAC バージョンでは動作しません。
- Windows Server コンテナイメージを、複数の Windows Server バージョンを対象とするマルチアーキテクチャイメージとしてビルドすることで、バージョニングの複雑さに対処できます。
新機能:
- 通常、新しい Windows Server の機能は最初に SAC バージョンに導入されます。このため、新しい GKE Windows 機能が最初に SAC ノードプールに導入される可能性があります。
- LTSC リリースではまだ使用できない機能に依存している場合は、SAC を検討してください。
コンテナランタイム:
- Windows Server LTSC ノードと SAC ノードイメージの場合、Docker または containerd をコンテナランタイムに使用できます。GKE ノードバージョン 1.21.1-gke.2200 以降の場合は、containerd ランタイムを使用することをおすすめします。詳細については、ノードイメージをご覧ください。
  
  警告: GKE バージョン 1.24 以降では、Docker ベースのノードイメージタイプはサポートされていません。GKE バージョン 1.23 では、Docker ノードイメージタイプを含む新しいノードプールも作成できません。containerd ノードイメージタイプに移行する必要があります。この変更の詳細については、Docker ノードイメージのサポート終了についてをご覧ください。

`gcloud` を更新して構成する

始める前に、次の作業が完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防ぐことができます。

クラスタを作成するための適切な権限があることを確認します。少なくとも、Kubernetes Engine Cluster 管理者である必要があります。

クラスタとノードプールを作成する

Windows Server コンテナを実行するには、クラスタに少なくとも 1 つの Windows ノードプールと 1 つの Linux ノードプールが必要です。Windows Server ノードプールのみを使用するクラスタを作成することはできません。Linux ノードプールは、重要なクラスタアドオンを実行するために必要です。

Linux ノードプールは重要です。クラスタアドオンを実行するのに十分な容量を確保するため、自動スケーリングを有効にすることをおすすめします。

gcloud

次のフィールドを使用してクラスタを作成します。

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

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

CLUSTER_NAME: クラスタに付ける名前。
--enable-ip-alias により、エイリアス IP が有効になります。Windows Server ノードにはエイリアス IP が必要です。そのメリットについて詳しくは、エイリアス IP でのネイティブコンテナルーティングについてをご覧ください。
NUMBER_OF_NODES: 作成する Linux ノードの数。クラスタアドオンを実行するために十分なコンピューティングリソースを提供する必要があります。これは省略可能なフィールドで、省略した場合、デフォルト値の 3 が使用されます。
VERSION_NUMBER: 使用する特定のクラスタバージョン。1.16.8-gke.9 以降である必要があります。リリースチャンネルを指定しないと、そのバージョンが利用できる最も新しいリリースチャンネルにクラスタが登録されます。
CHANNEL: クラスタを登録するリリースチャンネル。rapid、regular、stable、None のいずれかです。少なくとも --cluster-version、--release-channel、--no-enable-autoupgrade、--no-enable-autorepair のいずれかのフラグが指定されていない限り、デフォルトではクラスタは regular リリースチャンネルに登録されます。クラスタバージョンを選択してクラスタをリリースチャンネルに登録しない場合は、None を指定する必要があります。

次のフィールドを使用して、Windows Server ノードプールを作成します。

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

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

NODE_POOL_NAME: Windows Server ノードプールに付ける名前。
CLUSTER_NAME: 上記で作成したクラスタの名前。
IMAGE_NAME: 次のいずれかの値を指定できます。
- WINDOWS_LTSC_CONTAINERD: containerd を含む Windows Server LTSC。これは、Windows Server 2022 と Windows Server 2019 の両方の OS イメージのイメージタイプです
- WINDOWS_SAC_CONTAINERD: containerd を含む Windows Server SAC（2022 年 8 月 9 日以降はサポートされません）
- WINDOWS_LTSC: Docker を含む Windows Server LTSC
- WINDOWS_SAC: Docker を含む Windows Server SAC（2022 年 8 月 9 日以降はサポートされません）
警告: GKE バージョン 1.24 以降では、Docker ランタイムを含むイメージはサポートされません。GKE 1.24 にアップグレードする前に、containerd ランタイムを含むイメージに移行してください。この変更の詳細については、Docker から containerd への移行をご覧ください。
これらのノードイメージの詳細については、Windows ノードイメージを選択するをご覧ください。
--no-enable-autoupgrade は、ノードの自動アップグレードを無効にします。有効にする前に、Windows Server ノードプールのアップグレードを確認してください。
MACHINE_TYPE_NAME: マシンタイプを定義します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 が推奨される最小マシンタイプです。マシンタイプ f1-micro と g1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。
WINDOWS_OS_VERSION: イメージタイプ WINDOWS_LTSC_CONTAINERD に使用する Windows OS バージョンを定義します。これはオプションのフラグです。指定しない場合、デフォルトの OS バージョン LTSC2019 が使用されます。Windows Server 2022 ノードプールを作成する場合は、値を ltsc2022 に設定します。Windows Server 2019 ノードプールを作成する場合は、値を ltsc2019 に設定します。

次の例は、Windows Server 2022 ノードプールを作成する方法を示しています。

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

次の例は、Windows Server 2022 OS イメージを使用するように既存の Windows ノードプールを更新する方法を示しています。

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --windows-os-version=ltsc2022

コンソール

Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
[ 作成] をクリックします。
[クラスタの基本] セクションで、次の操作を行います。
1. [名前] に、クラスタの名前を入力します。
2. [ロケーションタイプ] で、クラスタに使用するリージョンまたはゾーンを選択します。
3. [コントロールプレーンのバージョン] で [リリースチャンネル] を選択するか、[静的バージョン] を指定します。静的バージョンは 1.16.8-gke.9 以降である必要があります。
ナビゲーションパネルの [ノードプール] で [default-pool] をクリックし、Linux ノードプールを作成します。このノードプールの構成時に、クラスタアドオンを実行するために十分なコンピューティングリソースを提供する必要があります。ノードとそのリソース（ファイアウォールルートなど）に使用できるリソース割り当てが必要です。
ページ上部の [ノードプールを追加] をクリックして、Windows Server ノードプールを作成します。
[ノードプールの詳細] セクションで、次の操作を行います。
1. [名前] に、ノードプールの名前を入力します。
2. 静的バージョンノードの場合は、[ノードのバージョン] を選択します。
3. ノードプール内に作成するノードの数を入力します。
ナビゲーションパネルで、[ノードプール] の下の [ノード] をクリックします。
1. [イメージの種類] プルダウンリストから、次のいずれかのノードイメージを選択します。
  - Docker を含む Windows Long Term Servicing Channel
  - containerd を含む Windows Long Term Servicing Channel
  - Docker を含む Windows Semi-Annual Channel
  - containerd を含む Windows Semi-Annual Channel
  警告: GKE バージョン 1.24 以降では、Docker ベースのノードイメージタイプはサポートされていません。GKE バージョン 1.23 では、Docker ノードイメージタイプを含む新しいノードプールも作成できません。containerd ノードイメージタイプに移行する必要があります。この変更の詳細については、Docker ノードイメージのサポート終了についてをご覧ください。
  詳細については、Windows ノードイメージの選択のセクションをご覧ください。
2. インスタンスに使用するデフォルトのマシンの構成を選択します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 は推奨される最小サイズです。マシンタイプ f1-micro と g1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。
ナビゲーションパネルで、Windows Server ノードプールの名前を選択します。[ノードプールの詳細] ページに戻ります。
1. [自動化] で、[ノードの自動アップグレードを有効にする] チェックボックスをオフにします。自動アップグレードを有効にする前に Windows Server ノードプールのアップグレードセクションを確認してください。
ナビゲーションパネルの [クラスタ] の下にある [ネットワーキング] をクリックします。
1. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィックルーティングを有効にする（エイリアス IP を使用）] が選択されていることを確認します。Windows Server ノードにはエイリアス IP が必要です。そのメリットについて詳しくは、エイリアス IP でのネイティブコンテナルーティングについてをご覧ください。
[作成] をクリックします。

Terraform

Terraform を使用して GKE Standard クラスタと Windows Server ノードプールを作成するには、次の例を参考にしてください。

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

この例では、containerd で Windows Server LTSC を使用します。これは、Windows Server 2022 と Windows Server 2019 の両方の OS イメージのイメージタイプです。ノードイメージの詳細については、Windows ノードイメージを選択するをご覧ください。

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

Windows Server ノードプールを作成した後、コントロールプレーンが更新されるまでの数分間、クラスタが RECONCILE 状態になります。

kubectl 認証情報を取得する

作成したクラスタで kubectl が動作するようにするには、get-credentials コマンドを使用します。

gcloud container clusters get-credentials CLUSTER_NAME

get-credentials コマンドについて詳しくは、SDK get-credentials のドキュメントをご覧ください。

クラスタの初期化を待機する

クラスタを使用する前に、windows.config.common-webhooks.networking.gke.io が作成されるまで数秒間お待ちください。この Webhook は、kubernetes.io/os: windows ノードセレクタで作成された Pod にスケジュール許容範囲を追加して、Pod が Windows Server ノードで動作できるようにします。さらに Pod を検証し、Windows でサポートされている機能のみを使用することを確認します。

Webhook が作成されるようにするには、次のコマンドを実行します。

kubectl get mutatingwebhookconfigurations

出力には、Webhook の実行が次のように表示されます。

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

これでノードプールが 2 つある（Linux と Windows 用に 1 つずつ）クラスタが作成されたので、Windows アプリケーションをデプロイできます。

GKE と Windows のバージョンのマッピング

Microsoft は約 6 か月ごとに新しい SAC バージョンをリリースし、2～3 年ごとに新しい LTSC バージョンをリリースしています。こうした新しいバージョンは通常、新しい GKE マイナーバージョンで利用できます。GKE のマイナーバージョンでは、通常、LTSC バージョンと SAC バージョンは固定されたままとなります。

GKE バージョンと Windows Server バージョンのバージョンマッピングを確認するには、gcloud beta container get-server-config コマンドを使用します。

gcloud beta container get-server-config

バージョンマッピングは、レスポンスの windowsVersionMaps フィールドで返されます。レスポンスをフィルタして、クラスタ内の特定の GKE バージョンのバージョンマッピングを表示するには、Linux シェルまたは Cloud Shell で次の手順を行います。

以下の変数を設定します。
```
CLUSTER_NAME=CLUSTER_NAME
NODE_POOL_NAME=NODE_POOL_NAME
ZONE=COMPUTE_ZONE
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- NODE_POOL_NAME: Windows Server ノードプールの名前。
- COMPUTE_ZONE: クラスタのコンピューティングゾーン。

ノードプールのバージョンを取得し、NODE_POOL_VERSION 変数に格納します。

NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`

NODE_POOL_VERSION の Windows Server バージョンを取得します。

gcloud beta container get-server-config \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

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

windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

WINDOWS_SAC イメージタイプの Windows Server バージョンを取得します。

gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

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

10.0.18363.1198

Windows Server ノードプールのアップグレード

Windows Server コンテナバージョンの互換性の要件により、ノードプールをアップグレードする前に、新しい GKE バージョンの Windows Server バージョンに合わせてコンテナイメージを再ビルドする必要がある可能性があります。

コンテナイメージとノードの互換性を維持するために、バージョンマッピングを確認し、Windows Server コンテナイメージを、複数の Windows Server バージョンを対象とすることが可能なマルチアーキテクチャイメージとしてビルドします。その後、GKE ノードプールのアップグレードを手動で起動する前に、現在の GKE バージョンと次の GKE バージョンの両方で動作するマルチアーキテクチャイメージを対象としてコンテナデプロイを更新できます。ノードのバージョンは、コントロールプレーンバージョンの 2 つ前のマイナーバージョン以降でなければならないため、ノードプールの手動アップグレードは定期的に実行する必要があります。

Pub/Sub を使用してアップグレードの通知に登録し、新しい GKE バージョンとそれを使用する Windows OS バージョンに関する最新情報をあらかじめ受け取ることをおすすめします。

Windows Server SAC をノードイメージタイプとして使用している場合は特に、最新の Windows Server バージョンを対象とするマルチアーキテクチャ Windows Server コンテナイメージを継続的にビルドする場合のみノードの自動アップグレードを有効にすることをおすすめします。ノードの自動アップグレードでは、Windows Server LTSC ノードイメージタイプの場合は問題を引き起こす可能性が低くなりますが、バージョンの互換性の問題が発生するリスクがあります。

Windows Updates

Windows Server ノードでは Windows Update が無効になります。自動更新を行うと、予期しないタイミングでノードが再起動する可能性があります。GKE によってノードが再作成された場合、ノードの起動後にインストールされた Windows Updates が失われることになります。GKE では、新しい GKE リリースで使用される Windows Server ノードイメージを定期的に更新することで、Windows Updates を利用できるようにします。そのため、Microsoft が Windows Updates をリリースしてから GKE で利用可能になるまでに時間がかかることがあります。重要なセキュリティアップデートがリリースされた場合、GKE はできる限り早く Windows Server ノードイメージを更新します。

Windows Pod と Service の通信方法を制御する

ネットワークポリシーを使用して、Windows Pod と Windows Service の通信方法を制御できます。

GKE バージョン 1.22.2 以降でネットワークポリシーが有効になっているクラスタに Windows Server コンテナを配置できます。この機能は、WINDOWS_LTSC または WINDOWS_LTSC_CONTAINERD ノードイメージタイプを使用するクラスタで使用できます。

コントロールプレーンまたはノードが以前のバージョンを実行している場合は、ノードプールとコントロールプレーンを GKE バージョン 1.22.2 以降にアップグレードすることで、ネットワークポリシーをサポートするバージョンにノードプールを移行できます。このオプションは、--enable-dataplane-v2 フラグを使用してクラスタを作成した場合にのみ使用できます。

ネットワークポリシーを有効にすると、以前に構成したすべてのポリシー（この機能を有効にする前に Windows Server コンテナで動作しなかったポリシー）もアクティブになります。

ネットワークポリシーが有効になっているクラスタでは、Windows Server コンテナで一部のクラスタを使用できません。詳しくは、制限事項のセクションをご覧ください。

ログの表示とクエリ

ロギングは、GKE クラスタで自動的に有効になります。Kubernetes Engine Monitoring を使用して、コンテナのログと Windows Server ノード上の他のサービスからのログを表示できます。

以下に、コンテナログを取得するフィルタの例を示します。

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

リモートデスクトッププロトコル（RDP）を使用して Windows Server ノードにアクセスする

RDP を使用して、クラスタ内の Windows Server ノードに接続できます。接続方法については、Compute Engine ドキュメントの Windows インスタンスへの接続をご覧ください。

マルチアーキテクチャイメージをビルドする

マルチアーキテクチャイメージを手動でビルドすることも、Cloud Build ビルダーを使用することもできます。手順については、Windows マルチアーキテクチャイメージのビルドをご覧ください。

gMSA の使用

次の手順は、Windows Server ノードプールでグループマネージドサービスアカウント（gMSA）を使用する方法を示しています。

AD ドメインに自動的に参加するようにクラスタ内の Windows Server ノードを構成します。手順については、Active Directory ドメインに自動的に参加するように Windows Server ノードを構成するをご覧ください。
ドメイン参加サービスによって自動的に作成されたセキュリティグループへの gMSA アクセスを作成して付与します。この手順は、AD ドメインに対する管理者権限があるマシンで行う必要があります。
```
$instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName
```
次のように置き換えます。
- NODE_POOL_NAME: Windows Server ノードプールの名前。自動生成されるセキュリティグループの名前は、Windows Server ノードプールと同じです。
- CLUSTER_NAME: クラスタの名前。
- GMSA_NAME: 新しい gMSA に付ける名前。
- DNS_HOST_NAME: 作成したサービスアカウントの完全修飾ドメイン名（FQDN）。たとえば、GMSA_NAME が webapp01 でドメインが example.com の場合、DNS_HOST_NAME は webapp01.example.com となります。
Windows Pod とコンテナに GMSA を構成するのチュートリアルに従い、gMSA を構成します。

Windows Server ノードプールの削除

gcloud または Google Cloud コンソールを使用して、Windows Server ノードプールを削除します。

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

コンソール

Google Cloud コンソールを使用して Windows Server ノードプールを削除するには、次の操作を行います。

Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
編集するクラスタの横にある [アクション] をクリックし、 [編集] をクリックします。
[ノード] タブを選択します。
[ノードプール] セクションで、削除するノードプールの横にある [削除] をクリックします。
確認するメッセージが表示されたら、もう一度 [削除] をクリックします。

制限事項

Kubernetes 機能の中には、Windows Server コンテナでまだサポートされていないものがあります。また、Linux 固有のもので、Windows では動作しない機能もあります。サポートされている Kubernetes 機能とサポートされていない Kubernetes 機能の完全なリストについては、Kubernetes のドキュメントをご覧ください。

サポートされていない Kubernetes 機能に加えて、サポートされていない GKE 機能もあります。

GKE クラスタの場合、次の機能は Windows Server ノードプールでサポートされていません。

Cloud TPU（--enable-tpu）
イメージストリーミング
ノード内の可視化（--enable-intra-node-visibility）
IP マスカレードエージェント
Kubernetes アルファクラスタ（--enable-kubernetes-alpha）
ノードローカル DNS キャッシュ
クラス E の IP アドレスのプライベート使用
パブリック IP アドレスのプライベート使用
ネットワークポリシーロギング
Kubernetes service.spec.sessionAffinity
GPU（--accelerator）
ノードあたりの最大 Pod 数をデフォルトの上限（110）よりも大きく設定する
Filestore CSI ドライバ
Docker ベースの CloudSQL Auth Proxy
Windows ノードでは IPv4 / IPv6 デュアルスタックネットワーキングの IPv6 はサポートされていません。

Windows ノードプールでのローカル外部トラフィックポリシーは、GKE バージョン v1.23.4-gke.400 以降でのみサポートされます。

GKE クラスタで使用する他の Google Cloud プロダクトでは、Windows Server ノードプールがサポートされていない場合があります。具体的な制限については、該当するプロダクトのドキュメントをご覧ください。

トラブルシューティング

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

containerd ノードに関する問題

containerd ノードイメージの使用に関する既知の問題については、既知の問題をご覧ください。

Windows Pod が起動しない

Windows Server コンテナと、コンテナを実行しようとしている Windows ノードのバージョンが一致しない場合、Windows Pod が起動しないことがあります。

Windows ノードプールのバージョンが 1.16.8-gke.8 以上の場合は、2020 年 2 月の Windows Server コンテナの非互換性の問題に関する Microsoft のドキュメントを確認し、2020 年 3 月以降の Windows Update が含まれるベース Windows イメージを使用してコンテナイメージを構築してください。以前のベース Windows イメージでビルドされたコンテナイメージは、これらの Windows ノードで動作せず、ステータス NotReady でノードに不具合が生じる可能性もあります。

Image pull のエラー

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

この問題は、Pod でエラーメッセージ「Failed to pull image」または「Image pull context cancelled」が表示されるか、Pod のステータスが ErrImagePull になった場合に発生します。

pull イメージが頻繁に発生する場合は、より高い CPU 仕様のノードプールを使用する必要があります。コンテナ抽出はコア間で並列に実行されるため、コア数が多いマシンタイプのほうが全体的な pull 時間が短縮されます。

Windows Server コンテナを正常に pull するには、次のオプションを試してください。

Windows Server コンテナイメージのアプリケーションレイヤを小さなレイヤに分割して、各レイヤをすばやく pull し、抽出できるようにします。これにより、Docker のレイヤキャッシングがより効果的になり、image pull の再試行が成功する確率が高くなります。レイヤについて詳しくは、Docker の記事 About images, containers, and storage drivers をご覧ください。
Pod を作成する前に、Windows Server ノードに接続し、コンテナイメージで docker pull コマンドを手動で使用します。
コンテナイメージを pull するためのタイムアウトが長くなるように kubelet サービスの image-pull-progress-deadline フラグを設定します。

フラグを設定するには、Windows ノードに接続して、次の PowerShell コマンドを実行します。

注: この手順を行うには kubelet restart が必要です。これは、ノードで実行中の Pod を中断できます。
1. Windows レジストリから Kubelet サービスの既存のコマンドラインを取得します。
```
PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
```
```
PS C:\> $name = "ImagePath"
```
```
PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
"(?s)${name}.*(C:.*kubelet\.exe.*)"
```
```
PS C:\> $kubelet_cmd = $Matches[1] -replace `
"--image-pull-progress-deadline=.* ","" -replace "\r\n"," "
```
2. Kubelet サービスの新しいコマンドラインを設定し、タイムアウトを長くするためのフラグを追加します。
```
PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
--image-pull-progress-deadline=40m "
```
3. この変更が正常に完了したことを確認します。
```
PS C:\> reg query ${regkey} /v ${name}
```
4. kubelet サービスを再起動して、この新しいフラグを有効にします。
```
PS C:\> Restart-Service kubelet
```
5. kubelet サービスが正常に再起動したことを確認します。
```
PS C:\> Get-Service kubelet # ensure state is Running
```

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

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

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

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

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

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

この問題を解決するには、作成するノードの数を減らします。ノードの数は後で増やすことが可能です。

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

これは Kubernetes の既知の問題であり、1 つの Windows ノードで複数の Pod を急激に起動した場合に発生します。この状況から回復するには、Windows Server ノードを再起動します。この問題を回避するために、Windows Pod の作成頻度を 30 秒につきに 1 つに制限することをおすすめします。

一貫性のない TerminationGracePeriod

コンテナの Windows システムタイムアウトが、構成した猶予期間とは異なる場合があります。この違いにより、ランタイムに渡された猶予期間が終了する前に、コンテナが強制終了する場合があります。

Windows タイムアウトを変更するには、イメージのビルド時にコンテナローカルのレジストリキーを編集します。Windows タイムアウトを変更した場合は、それに合わせて TerminationGracePeriodSeconds を調整する必要があります。

ネットワーク接続の問題

Windows Server コンテナでネットワーク接続の問題が発生する場合は、Windows Server コンテナネットワーキングがネットワーク MTU 1500 を前提としている可能性があります。この MTU は、Google Cloud の MTU 1460 と互換性がありません。

コンテナ内のネットワークインターフェースの MTU と Windows Server ノード自体のネットワークインターフェースの両方が同じ値（1460 以下）に設定されていることを確認します。MTU の設定方法については、Windows コンテナの既知の問題をご覧ください。

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

ノードがクラスタ内の起動に失敗する場合や、クラスタに正常に参加できない場合は、ノードのシリアルポート出力で提供される診断情報を確認します。

次のコマンドを実行して、シリアルポート出力を表示します。

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

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

NODE_NAME: ノードの名前。
COMPUTE_ZONE: 特定のノードのコンピューティングゾーン。

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

多くのホストネットワークサービスロードバランサのルールを含む Kubernetes クラスタで Windows ノードを起動すると、ルールの処理に遅延が発生します。ルールあたり約 30 秒の遅延が発生すると、サービスに断続的にアクセスできなくなります。また、相当な数のルールがある場合、合計の遅延時間はかなり大きくなる可能性があります。詳しくは、GitHub で元の問題をご覧ください。

バージョン 1.24 以前を実行している GKE クラスタの場合、Windows ノードで kube-proxy の再起動イベント（ノードの起動、ノードのアップグレード、手動再起動など）が発生すると、コンポーネントによってすべてのルールが同期されるまで、そのノード上で実行されている Pod からアクセスされている Service がすべて到達不能になります。

バージョン 1.25 以降を実行している GKE クラスタでは、この動作が大幅に改善されています。この改善の詳細については、GitHub で pull リクエストをご覧ください。この問題が発生した場合は、クラスタのコントロールプレーンを 1.25 以降にアップグレードすることをおすすめします。

次のステップ

Windows アプリケーションをデプロイする方法を学習する。
Microsoft による Windows コンテナの簡単な紹介を読む。
コンテナベースイメージの選択に関する Microsoft のガイダンスを読む。
Windows コンテナのバージョンの互換性に関する Microsoft の資料を読む。

Windows Server ノードプールを使用したクラスタの作成

Windows Server ノードプールを使用したクラスタの作成

Windows Server ノードイメージを選択する

gcloud を更新して構成する

クラスタとノードプールを作成する

gcloud

コンソール

Terraform

kubectl 認証情報を取得する

クラスタの初期化を待機する

GKE と Windows のバージョンのマッピング

Windows Server ノードプールのアップグレード

Windows Updates

Windows Pod と Service の通信方法を制御する

ログの表示とクエリ

リモート デスクトップ プロトコル（RDP）を使用して Windows Server ノードにアクセスする

マルチアーキテクチャ イメージをビルドする

gMSA の使用

Windows Server ノードプールの削除

gcloud

コンソール

制限事項

トラブルシューティング

containerd ノードに関する問題

Windows Pod が起動しない

Image pull のエラー

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

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

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

一貫性のない TerminationGracePeriod

ネットワーク接続の問題

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

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

次のステップ

`gcloud` を更新して構成する

リモートデスクトッププロトコル（RDP）を使用して Windows Server ノードにアクセスする

マルチアーキテクチャイメージをビルドする

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

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