Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

Standard

このページでは、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 認証情報を取得する
クラスタの初期化を待機する

GKE 用の IAM サービスアカウントを設定する

GKE は、ノードに接続されている IAM サービスアカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。これらのノードサービスアカウントには、プロジェクトに対する Kubernetes Engine デフォルトノードサービスアカウント（roles/container.defaultNodeServiceAccount）ロールが最低限必要です。デフォルトでは、GKE はプロジェクトに自動的に作成される Compute Engine のデフォルトのサービスアカウントをノードサービスアカウントとして使用します。

Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与する手順は次のとおりです。

コンソール

[ようこそ] ページに移動します。
[ようこそ] に移動
[プロジェクト番号] フィールドで、 [クリップボードにコピー] をクリックします。
[IAM] ページに移動します。
[IAM] に移動
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに次の値を指定します。
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
PROJECT_NUMBER は、コピーしたプロジェクト番号に置き換えます。
[ロールを選択] メニューで、[Kubernetes Engine デフォルトノードサービスアカウント] ロールを選択します。
[保存] をクリックします。

gcloud

Google Cloud プロジェクト番号を確認します。
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
PROJECT_ID は、実際のプロジェクト ID に置き換えます。

出力は次のようになります。
```
12345678901
```
Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与します。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"
```
PROJECT_NUMBER は、前の手順のプロジェクト番号に置き換えます。

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

GKE で実行するには、推奨の Windows Server バージョン 2022（LTSC）または Windows Server バージョン 2019（LTSC）で Windows Server コンテナノードイメージをビルドする必要があります。Windows Server バージョン 2019（LTSC）は GKE で非推奨となっており、GKE バージョン 1.37 以降を実行するノードプールでは使用できません。1 つのクラスタで、異なる Windows Server バージョンを使用する複数の Windows Server ノードプールを使用できますが、各ノードプールで使用できる Windows Server のバージョンは 1 つのみです。

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

更新: LTSC2019 は GKE で非推奨になったため、LTSC2022 を使用します。LTSC2019 について、次のことを理解します。
- ノードイメージの更新なし: Microsoft がイメージのメインストリームサポートを終了したため、基盤となるイメージの更新に安定性の問題があるため、GKE は LTSC2019 のノードイメージの更新を提供していません。GKE ノードイメージは、基盤となるイメージの 2025 年 12 月バージョンに固定されています。詳細については、Windows Server 2019 をご覧ください。
- 1.37 との互換性: GKE バージョン 1.37 以降では、LTSC2019 を使用できません。LTSC2019 で 1.37 の新しいノードプールを作成したり、既存の LTSC2019 ノードプールを 1.37 にアップグレードすることはできません。
サポートのタイミング:
- OS イメージのサポートポリシーで説明されているように、Windows Server ノードイメージのサポートには Microsoft が提供するサポート時間が適用されます。GKE と Windows バージョンのマッピングで説明しているように、GKE Windows ノードイメージのサポート終了日は gcloud container get-server-config コマンドで確認できます。
バージョンの互換性と複雑さ:
- Windows Server Core と Nano Server の両方をコンテナのベースイメージとして使用できます。
- Windows Server コンテナイメージを、複数の Windows Server バージョンを対象とするマルチアーキテクチャイメージとしてビルドすることで、バージョニングの複雑さに対処できます。

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

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

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API を有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
注: 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 ノードプールは、重要なクラスタアドオンを実行するために必要です。

Windows Server ノードプールを使用してクラスタを作成する前に、Windows Server ノードプールのアップグレードセクションを確認してください。

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

gcloud

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

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

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

CLUSTER_NAME: クラスタに付ける名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
--enable-ip-alias により、エイリアス IP が有効になります。Windows Server ノードにはエイリアス IP が必要です。そのメリットについて詳しくは、エイリアス IP でのネイティブコンテナルーティングについてをご覧ください。
NUMBER_OF_NODES: 作成する Linux ノードの数。クラスタアドオンを実行するために十分なコンピューティングリソースを提供する必要があります。これは省略可能なフィールドで、省略した場合、デフォルト値の 3 が使用されます。
VERSION_NUMBER: 使用する特定のクラスタバージョン。リリースチャンネルを指定しない場合、クラスタは、そのバージョンが利用できる最も新しいリリースチャンネルに登録されます。
CHANNEL: クラスタを登録するリリースチャンネル。rapid、regular、stable、None のいずれかです（非推奨）。デフォルトでは、クラスタは regular リリースチャンネルに登録されます。

Compute Engine のデフォルトのサービスアカウントの代わりに、ノードで使用できる最小権限の IAM サービスアカウントを指定することを強くおすすめします。最小権限のサービスアカウントを作成する方法については、最小権限のサービスアカウントを使用するをご覧ください。

gcloud CLI でカスタムサービスアカウントを指定するには、コマンドに次のフラグを追加します。

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

SERVICE_ACCOUNT_NAME は、最小権限のサービスアカウントの名前に置き換えます。

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

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

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

NODE_POOL_NAME: Windows Server ノードプールに付ける名前。
CLUSTER_NAME: 上記で作成したクラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
MACHINE_TYPE_NAME: マシンタイプを定義します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 が推奨される最小マシンタイプです。マシンタイプ f1-micro と g1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。
WINDOWS_OS_VERSION: イメージタイプ WINDOWS_LTSC_CONTAINERD に使用する Windows OS バージョンを定義するオプションのフラグです。GKE バージョン 1.37 以降では、LTSC2022（ltsc2022）のみを使用できます。1.36 以前の場合は、値を明示的に ltsc2022 に設定することをおすすめします。それ以外の場合、GKE は LTSC2019（ltsc2019）を使用します。これは GKE で非推奨となっているため、おすすめしません。

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

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --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 \
    --location=us-central1 \
    --windows-os-version=ltsc2022

コンソール

Google Cloud コンソールで、[Kubernetes クラスタを作成する] ページに移動します。
[Kubernetes クラスタの作成] に移動
[クラスタの基本] セクションで、次の操作を行います。
1. クラスタの名前を [名前] に入力します。
2. [ロケーションタイプ] で、クラスタのリージョンまたはゾーンを選択します。
3. [リリースチャンネル] で、[リリースチャンネル] と、必要に応じて [ターゲットバージョン] を選択します。
ナビゲーションパネルの [ノードプール] で [default-pool] をクリックし、Linux ノードプールを作成します。このノードプールの構成時に、クラスタアドオンを実行するために十分なコンピューティングリソースを提供する必要があります。ノードとそのリソース（ファイアウォールルートなど）に使用できるリソース割り当てが必要です。
ページ上部の [ノードプールを追加] をクリックして、Windows Server ノードプールを作成します。
[ノードプールの詳細] セクションで、次の操作を行います。
1. [名前] に、ノードプールの名前を入力します。
2. ノードプール内に作成するノードの数を入力します。
ナビゲーションパネルで、[ノードプール] の下の [ノード] をクリックします。
1. 画像タイプドロップダウンリストから、次のノード画像を選択します。
  - containerd を含む Windows Long Term Servicing Channel
  詳細については、Windows ノードイメージの選択のセクションをご覧ください。
2. インスタンスに使用するデフォルトのマシンの構成を選択します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 は推奨される最小サイズです。マシンタイプ f1-micro と g1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。
ナビゲーションパネルの [クラスタ] の下にある [ネットワーキング] をクリックします。
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
}

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 イメージのイメージタイプです（GKE で非推奨）。ノードイメージの詳細については、Windows ノードイメージを選択するをご覧ください。

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

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

kubectl 認証情報を取得する

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

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

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 は 2 ～ 3 年ごとに新しい LTSC バージョンをリリースしています。こうした新しいバージョンは通常、新しい GKE マイナーバージョンで利用できます。GKE のマイナーバージョンでは、通常、LTSC バージョンは固定されたままとなります。

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 \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- NODE_POOL_NAME: Windows Server ノードプールの名前。
- CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

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

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

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

gcloud beta container get-server-config \
    --location=$CONTROL_PLANE_LOCATION \
    --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_LTSC イメージタイプの Windows Server バージョンを取得します。

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

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

10.0.17763.1577

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

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

必要に応じて、メンテナンスの除外を使用してノードの自動アップグレードを防止します。
バージョンマッピングを確認し、複数の Windows Server バージョンを対象とすることが可能なマルチアーキテクチャイメージとして Windows Server コンテナイメージをビルドすることで、コンテナイメージとノードの互換性を維持します。その後、GKE ノードプールのアップグレードを手動で起動する前に、現在の GKE バージョンと次の GKE バージョンの両方で動作するマルチアーキテクチャイメージを対象としてコンテナデプロイを更新できます。
ノードの自動アップグレードを防止している場合は、ノードのバージョンはコントロールプレーンバージョンの 2 つ前のマイナーバージョン以降でなければならないため、ノードプールの手動アップグレードを定期的に実行してください。
新しい GKE バージョンとそれを使用する Windows OS バージョンに関する最新情報をあらかじめ受け取るには、アップグレードの通知に登録します。
最新の Windows Server バージョンを対象とするマルチアーキテクチャ Windows Server コンテナイメージを継続的にビルドする場合のみ、GKE でノードの自動アップグレードを実行します。ノードの自動アップグレードでは、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
    --location=CONTROL_PLANE_LOCATION

コンソール

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

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

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

制限事項

次の機能は、Windows Server ノードプールではサポートされていません。

コンピューティングとノードの機能:
- Autopilot モード
- ノードの自動プロビジョニング
- 第 3 世代より上のマシンシリーズ
- Z3 マシンシリーズ
- イメージストリーミング
- アルファクラスタ
- GPU や TPU などのアクセラレータ
ネットワーキング機能:
- ノードあたりの最大 Pod 数をデフォルトの制限値 110 より大きく設定しています
- ノード内の可視化
- ノードローカル DNS キャッシュ
- ネットワークポリシーロギング
- IP マスカレードエージェント。Windows ノードは外部宛先に対して IP マスカレードを実行しますが、エージェントはサポートされていません。
- IPv4/IPv6 デュアルスタックネットワーク。 Windows ノードでは IPv6 ネットワーキングはサポートされていません。
- クラス E の IP アドレスのプライベート使用
- パブリック IP アドレスのプライベート使用
- GKE Dataplane V2 の完全なサポート。GKE Dataplane V2 を搭載した Windows ノードは、参照ドキュメントに記載されている制限事項に加え、ネットワークポリシーの適用のみに制限されます。
セキュリティ機能：
- Confidential GKE Node
- Linux 固有のセキュリティ機能（例：Seccomp、Apparmor、SELinux）
Kubernetes の機能
- ホスト名前空間（例：hostNetwork、hostPID、hostIPC）。これらは Windows オペレーティングシステムではサポートされていません。
- Kubernetes service.spec.sessionAffinity
- 「Kubernetes の Windows コンテナ」ドキュメントの互換性と制限事項セクションに記載されている機能
ストレージ機能：
- デフォルトのファイルシステムタイプ（ext4）は、バランス型永続ディスクタイプで使用されます。詳細については、StorageClasses を参照してください。
- ファイルストア CSI ドライバ
- エフェメラルストレージ用の NVMe インターフェースを備えたローカル SSD
オブザーバビリティ機能:
- kubelet 読み取り専用ポートが無効になっている場合、ロギングエージェントが Pod ラベルを取得できないため、Windows ノードのワークロードログに Kubernetes Pod ラベルが表示されません。
Microsoft の機能:
- Microsoft Hyper-V 分離
その他:
- Docker ベースの CloudSQL Auth Proxy
- Windows Server ノードプールのみを使用するクラスタを作成することはできません。少なくとも 1 つの Linux ノードプールが必要です。

GKE クラスタで使用する可能性のある他の Google Cloud プロダクトの具体的な制限については、該当するプロダクトのドキュメントをご覧ください。

トラブルシューティング

Windows Server ノードプールに固有のトラブルシューティングガイダンスについては、Windows Server ノードプールのトラブルシューティングをご覧ください。

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

次のステップ

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

Windows Server ノードプールを使用したクラスタの作成 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

GKE 用の IAM サービス アカウントを設定する

コンソール

gcloud

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

gcloud を更新して構成する

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

gcloud

コンソール

Terraform

kubectl 認証情報を取得する

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

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

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

Windows Updates

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

ログの表示とクエリ

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

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

gMSA の使用

Windows Server ノードプールの削除

gcloud

コンソール

制限事項

トラブルシューティング

次のステップ

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

GKE 用の IAM サービスアカウントを設定する

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

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

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