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

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

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

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

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

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

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

gcloud を更新して構成する

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

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

  • gcloud init。デフォルトの設定全般を確認する場合に使用します。
  • gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. デフォルトの Compute Engine ゾーンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project project-id
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone compute-zone
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region compute-region
  • gcloud を最新バージョンに更新します。
    gcloud components update

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

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

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

  • SAC のバージョンは、最初のリリースから 18 か月間のみ Microsoft によってサポートされます。ノードプールのイメージタイプとして SAC を選択したものの、新しい SAC バージョンを対象とする新しい GKE バージョンにノードプールをアップグレードしない場合、SAC バージョンのサポート ライフサイクルが終了すると、ノードプールに新しいノードを作成できなくなります。

  • SAC は、ノードプールと、その中で定期的に実行されているコンテナをアップグレードできる場合にのみ選択してください。GKE では、新しい GKE リリースで Windows ノードプールに使用される SAC バージョンが定期的に更新されるため、ノードプールのイメージタイプに対して SAC を選択すると、コンテナの再構築を頻繁に行う必要があります。

  • 通常、新しい Windows Server の機能は最初に SAC バージョンに導入されます。このため、新しい GKE Windows 機能が最初に SAC ノードプールに導入される可能性があります。

使用する Windows Server のイメージタイプがわからない場合は、Windows Server LTSC を選択して、ノードプールをアップグレードする際のバージョンの非互換性の問題を回避することをおすすめします。詳細については、Microsoft のドキュメントの Windows Server サービス チャネル: LTSC と SAC をご覧ください。

バージョンの互換性

Windows Server CoreNano Server の両方をコンテナのベースイメージとして使用できます。

Windows Server コンテナには、バージョンの互換性に関する重要な要件があります。

  • LSC 用に構築された Windows Server コンテナは、SAC ノードでは動作せず、その逆も同様です。
  • 特定の LTSC バージョンまたは SAC バージョン用にビルドされた Windows Server コンテナは、他のバージョンを対象とするように再ビルドしないと、他の LTSC バージョンまたは SAC バージョンでは動作しません。

Windows Server コンテナ イメージを、複数の Windows Server バージョンを対象とするマルチ アーキテクチャ イメージとしてビルドすると、バージョニングの複雑さを管理できます。

バージョン マッピング

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

次の表は、GKE バージョンを Windows Server バージョンにマッピングする方法を示しています。

GKE バージョン SAC バージョン LTSC バージョン
1.14.x(早期アクセスのみ) 10.0.17763(Windows Server バージョン 1809 Core) なし
1.15.x(早期アクセスのみ) 10.0.17763(Windows Server バージョン 1809 Core) なし
1.16.4-gke.25-1.16.7.x(ベータ版のみ) 10.0.18363.592(Windows Server バージョン 1909 Core) 10.0.17763.973(Windows Server 2019 Core)
1.16.8-gke.8 以上 10.0.18363.720(Windows Server バージョン 1909 Core) 10.0.17763.1098(Windows Server 2019 Core)
1.17.x 10.0.18363.720(Windows Server バージョン 1909 Core) 10.0.17763.1098(Windows Server 2019 Core)

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

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

ここで

  • cluster-name は、クラスタに付ける名前です。
  • --enable-ip-alias により、エイリアス IP が有効になります。Windows Server ノードにはエイリアス IP が必要です。そのメリットについて詳しくは、エイリアス IP でのネイティブ コンテナ ルーティングについてをご覧ください。
  • number-of-nodes では、作成する Linux ノードの数を指定します。クラスタ アドオンを実行するために十分なコンピューティング リソースを提供する必要があります。これはオプションのフィールドで、省略した場合、デフォルト値の 3 が使用されます。
  • version-number は 1.16.8-gke.9 以上にする必要があります。また、--release-channel フラグを使用して、デフォルト バージョンの 1.16.8-gke.9 以上のリリース チャンネルを選択することもできます。

次のフィールドを使用して、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

ここで

  • node-pool-name は、Windows Server ノードプールに対して選択した名前です。
  • cluster-name は、上記で作成したクラスタの名前です。
  • image-nameWINDOWS_SAC または WINDOWS_LTSC です。これらのノードイメージの詳細については、Windows ノードイメージを選択するをご覧ください。
  • --no-enable-autoupgrade は、ノード autoupgrade を無効にします。有効にする前に、Windows Server ノードプールのアップグレードを確認してください。
  • machine-type-name はマシンタイプを定義します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 は推奨される最小マシンタイプです。マシンタイプ f1-microg1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. [クラスタの基本] セクションで、次の操作を行います。

    1. クラスタの名前を [名前] に入力します。
    2. [ロケーション タイプ] で、クラスタに使用するリージョンまたはゾーンを選択します。
    3. [マスター バージョン] で、1.16.8-gke.9 以上の静的バージョンを選択します。
      または
      [マスター バージョン] で、デフォルト バージョンの 1.16.8-gke.9 以上のリリース チャンネルを選択します。
  4. ナビゲーション パネルの [ノードプール] で [default-pool] をクリックし、Linux ノードプールを作成します。このノードプールの構成時に、クラスタ アドオンを実行するために十分なコンピューティング リソースを提供する必要があります。ノードとそのリソース(ファイアウォール ルートなど)に使用できるリソース割り当てが必要です。

  5. ページ上部の [ノードプールを追加] をクリックして、Windows Server ノードプールを作成します。

  6. [ノードプールの詳細] セクションで、次の操作を行います。

    1. ノードプール名前を入力します。
    2. [ノードのバージョン] で、ノードのバージョンを選択します。
    3. ノードプール内に作成するノードの数を入力します。
  7. ナビゲーション パネルで、[ノードプール] の下の [ノード] をクリックします。

    1. [イメージタイプ] プルダウン リストから、[Windows Server Semi-Annual Channel] または [Windows Server Long-Term Servicing Channel] を選択します。これらのノードイメージの詳細については、Windows ノードイメージを選択するをご覧ください。
    2. インスタンスに使用するデフォルトの [マシンの構成] を選択します。Windows Server ノードには追加でリソースが必要になるため、n1-standard-2 は推奨される最小サイズです。マシンタイプ f1-microg1-small はサポートされていません。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。
  8. ナビゲーション パネルで、Windows Server ノードプールの名前を選択します。[ノードプールの詳細] ページに戻ります。

    1. [自動化] で、[ノードの自動アップグレードを有効にする] をオフにします。有効にする前に、Windows Server ノードプールのアップグレード セクションを確認してください。
  9. ナビゲーション パネルで [ネットワーキング] を選択します。

    1. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] が選択されていることを確認します。Windows Server ノードにはエイリアス IP が必要です。そのメリットについて詳しくは、エイリアス IP でのネイティブ コンテナ ルーティングについてをご覧ください。
  10. [作成] をクリックします。

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

kubectl 認証情報を取得する

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

gcloud container clusters get-credentials 

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

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

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

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 アプリケーションをデプロイできるようになります。

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

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

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

特に、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 ノードイメージが更新されます。

ログの表示とクエリ

ロギングは、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 インスタンスへの接続をご覧ください。

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

Docker では、マルチ アーキテクチャ(またはマルチ プラットフォーム)イメージがサポートされています。マルチ アーキテクチャ イメージにより、ノード上のコンテナ ランタイムはプラットフォームの互換イメージを pull できます。マルチ アーキテクチャ イメージ マニフェストをビルドするには、プラットフォームごとにイメージをビルドしてから、各プラットフォームのイメージを参照するマニフェストをビルドします。

マルチ アーキテクチャ イメージ マニフェストをビルドするには:

  1. LTSC 2019 Docker イメージを作成します。例: gcr.io/my-project/foo:1.0-2019
  2. SAC 1909 Docker イメージを作成します。例: gcr.io/my-project/foo:1.0-1909
  3. Windows Server バージョン 1909 VM を作成します。
  4. RDP を使用して VM に接続します。
  5. PowerShell を実行します。
  6. docker manifest 試験運用機能を有効にします。
    PS C:> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
    
  7. マルチ アーキテクチャ マニフェストを作成します。
    docker manifest create gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    
  8. 新しく作成したマニフェストを push します。
    docker manifest push gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    

Windows Server ノードプールの削除

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

gcloud

gcloud container node-pools delete --cluster=cluster-name node-pool-name

Console

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

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. 削除するノードプールが含まれるクラスタの横にある [編集] アイコン(鉛筆の形をしたアイコン)をクリックします。

  3. [ノードプール] セクションで、削除するノードプールの横にある [削除] アイコン(ごみ箱のようなアイコン)をクリックします。

  4. 確認するメッセージが表示されたら、もう一度 [削除] をクリックします。

制限事項

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

また、一部の GKE 機能はサポートされていません。

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

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

トラブルシューティング

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

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 でノードに不具合が生じる可能性もあります。

イメージ pull エラー

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

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

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

  • Windows Server コンテナ イメージのアプリケーション レイヤを小さなレイヤに分割して、各レイヤをすばやく pull し、抽出できるようにします。これにより、Docker のレイヤ キャッシュがより効果的になり、イメージ pull 再試行が成功する可能性が高くなります。レイヤについて詳しくは、Docker の記事 About images, containers, and storage drivers をご覧ください。

  • Pod を作成する前に、Windows Server ノードに接続し、コンテナ イメージで docker pull コマンドを手動で使用します。

  • コンテナ イメージを pull するためのタイムアウトが長くなるように kubelet サービスの image-pull-progress-deadline フラグを設定します。

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

    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 `
      "${name}.*(C:.*kubelet\.exe.*)\r"
      
      PS C:\> $kubelet_cmd = $Matches[1]
      
    2. Kubelet サービスの新しいコマンドラインを設定し、タイムアウトを長くするためのフラグを追加します。

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
      --image-pull-progress-deadline=15m
      
    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
      

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

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

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

gMSA の使用

グループ マネージド サービス アカウント(gMSA)を使用できない場合は、Active Directory のコンピュータ名の制限が原因である可能性があります。Active Directory では、コンピュータ名が 15 文字に制限されています。GKE を使用している場合、この名前は GKE ノード名から取得されます。ノード名は、ノードプールの名前とその後に続く一意の文字列から生成されます。ノード名が 15 文字を超えると、15 文字に切り捨てられます。

たとえば、ノード名が gke-cluster-windows--node-pool-window-3d3afc34- wnnn の場合、GKE-CLUSTER-WIN に切り捨てられます。

gke-cluster-windows--node-pool-window-123gtj12-aabb という名前のノードも、GKE-CLUSTER-WIN に切り捨てられます。

Active Directory ではコンピュータと名前の間に 1 対 1 の関係があるため、2 台のコンピュータが名前を共有すると、エラーが発生します。

この問題を回避するには、Active Directory に参加するときにコンピュータの名前を変更します。コンピュータ名を変更したら、ノードをクラスタに接続できなくなる問題を防ぐために、ノードの kubelet と kube-proxy の構成も更新する必要があります。これを行うには、kubelet と kube-proxy のサービスパスに --hostname-override フラグを追加します。このフラグをノードのインスタンス名に設定し、サービスを再起動します。

構成を更新するには、次のコマンドを実行します。

sc.exe config service-name binPath="existing-service-binpath --hostname-override=node-instance-name"

ここで

  • service-namekubelet または kube-proxy です。このスクリプトは、サービスごとに 1 回実行します。
  • existing-service-binpath はサービスの binPath です。これは sc.exe qc service-name を使用して取得できます。
  • node-instance-name は、ノード VM のインスタンス名です。

これにより、問題が解決され、ノードとホストの Pod が表示されます。また、Active Directory での名前の競合も回避されます。

Managed Service for Microsoft Active Directory に関する注意事項

Managed Service for Microsoft Active Directory で gMSA を設定するには、いくつかの追加手順が必要です。マネージド Microsoft AD のデフォルトのオブジェクトと権限と標準の AD の間にいくつかの違いがあるため、プロセスが少し異なります。マネージド Microsoft AD で gMSA を作成する方法をご確認ください。

エラー「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 と互換性がありません。

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

次のステップ