Windows Server OS ノードプールのユーザーガイド

Anthos clusters on VMware（GKE On-Prem）バージョン 1.8 では、Windows Server OS ノードのノードプールを作成できます。Windows Server OS ノードプールを実行するユーザー クラスタでは、Ubuntu または Container-Optimized OS を使用するノードのノードプールを運用することもできます。

Windows Server OS ノードプールの要件

ノードプール内のノードは、すべて同じオペレーティング システムを使用する必要があり、osImageType パラメータで指定されます。

ユーザー クラスタに Windows Server OS ノードを持つノードプールを作成する前に、次の要件を満たしていることを確認してください。

  • Windows ノードプールを実行するユーザー クラスタが、Anthos clusters on VMware バージョン 1.8 以降であること。
  • このユーザー クラスタを制御する管理クラスタが、バージョン 1.7 以降であること。
  • Windows ノードプールを作成する前に、管理クラスタが用意されていること（Windows ノードプールは、ユーザー クラスタでのみサポートされています）。
  • ユーザー クラスタで、Linux ノードプールが 1 つ以上運用されていること（Windows ノードプールの作成には Linux ノードプールが必要です）。

  • Windows ノードプールがあるユーザー クラスタで、Dataplane V2 が有効になっていること。

  • Windows ノードプールに特化した VM テンプレートを作成するために、Microsoft から Windows Server 2019 ISO がダウンロードされていること。 ISO の言語 / 地域タグは en-US にする必要があります。

  • vSphere 環境が、vSphere 6.7、Update 3 以降であること。

ユーザー クラスタに Windows ノードプールを作成する

ステップ 1: Anthos clusters on VMware の Windows VM テンプレートを作成する

開始する前に、管理クラスタが作成されていることを確認します。

  1. Windows Server 2019 ISO からベース Windows VM テンプレートを作成します。

    • Windows Server 2019 ISO をインストールする Windows VM の初期ネットワーク アダプタ タイプは、E1000E であることが必要です。
    • Windows Server 2019 用の VMware vSphere テンプレートを作成の手順に沿って操作します。
    • Windows ISO インストーラを実行するときに設定された初期パスワードは、後で使用するためメモしておいてください。
    • Anthos clusters on VMware バージョン 1.8.0 に認定された最新の Windows Server 2019（10.0.17763.1999）用のパッチ バージョンを使用していることを確認します。セキュリティ パッチプロセスをご覧ください。
    • IDE コントローラを使用するデバイスは、ベース VM テンプレートにアタッチできません。
    • Windows バージョンが 10.0.17763.1757 以上の場合は、こちらの回避策をご覧ください。

  2. VMware ツールをベース Windows VM テンプレートにインストールしていない場合は、VMware の手順に沿ってインストールします。

  3. Windows VM テンプレートを作成します。

    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_KUBECONFIG_PATH

  4. コマンド出力の最後の行に、生成された Windows VM テンプレートの名前が表示されます。後で使用できるように、名前をメモしておきます。名前の形式は次のとおりです。

Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-10.0.17763.1999-1.8.0-gke.25"

ステップ 2: Windows コンテナ イメージを非公開レジストリにアップロードする

非公開レジストリを使用していない場合は、このステップを省略してください。

非公開レジストリの使用には、次の要件があります。

  • このステップの実行にあたっては、Docker がインストールされていて、gcr.io にアクセスできる Windows マシンを使用してください。Windows マシンのイメージは Windows マシンにしか pull できません。
  • docker login を実行して、非公開レジストリに対する認証を行います。

  • 次の手順で、Windows コンテナ イメージをベースレイヤとともに非公開レジストリにアップロードします。

    • Windows マシンの Docker daemon.json ファイルを確認します。

      PS C:> cat C:\ProgramData\docker\config\daemon.json

    • 次の行を追加して、Docker daemon.json ファイルを構成し、外部レイヤを非公開レジストリに push できるようにします。

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • 必要な Windows コンテナ イメージをローカルの Windows マシンにダウンロードし、タグ付けして限定公開レジストリに push します。daemon.json Docker 構成ファイルに変更を加えることで、ベースレイヤを限定公開レジストリに push できるようになります。これらの手順を完了するには、次のコマンドを実行します。
# Pull the Windows container images
docker pull gcr.io/gke-on-prem-release/pause-win:1.6.1
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.7.7-gke.2_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0

# Tag the images to use private registry
docker tag gcr.io/gke-on-prem-release/pause-win:1.6.1 $PRIVATE_REGISTRY_URL/pause-win:1.6.1
docker tag gcr.io/gke-on-prem-release/fluent-bit-win:v1.7.7-gke.2_ltsc2019 $PRIVATE_REGISTRY_URL/fluent-bit-win:v1.7.7-gke.2_ltsc2019
docker tag gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0 $PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:1.6.1
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.7.7-gke.2_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0

ステップ 3: Windows ノードプールを作成するための URL を許可リストに登録する（プロキシを使用している場合は必須）

クラスタがプロキシ サーバーの背後にある場合は、Anthos clusters on VMware に必要な他のアドレスに加えて、次の URL をプロキシ サーバーの許可リストに追加します。

# Microsoft registry URLs, needed by every Windows node if using GCR
mcr.microsoft.com
.data.mcr.microsoft.com
go.microsoft.com
winlayers.cdn.mscr.io

# Microsoft WSUS server URLs, needed by `gkectl prepare windows` on the Windows VM
windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.update.microsoft.com
.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com

# Cloudbase-Init URL, needed by `gkectl prepare windows` on the Windows VM
https://cloudbase.it

# Powershell Gallery URLs, needed by `gkectl prepare windows` on the Windows VM
psg-prod-eastus.azureedge.net
az818661.vo.msecnd.net
devopsgallerystorage.blob.core.windows.net
.powershellgallery.com

# Windows Update Service, needed by `gkectl prepare windows` on the Windows VM
onegetcdn.azureedge.net
sws.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
fe3.delivery.mp.microsoft.com
.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
adl.windows.com
activation-v2.sls.microsoft.com
crl.microsoft.com
ocsp.digicert.com
ctldl.windowsupdate.com
login.live.com
licensing.mp.microsoft.com
www.msftconnecttest.com
settings-win.data.microsoft.com
wdcp.microsoft.com
smartscreen-prod.microsoft.com
checkappexec.microsoft.com
arc.msn.com
ris.api.iris.microsoft.com
.tlu.dl.delivery.mp.microsoft.com
.au.windowsupdate.com
www.microsoft.com
fe3.delivery.dsp.mp.microsoft.com.nsatc.net
cs9.wac.phicdn.net
geo-prod.do.dsp.mp.microsoft.com
slscr.update.microsoft.com
v10.events.data.microsoft.com

# Access for Installing docker, needed by `gkectl prepare windows` on the Windows VM
dockermsft.azureedge.net

ステップ 4: ユーザー クラスタの構成ファイルに Windows ノードプールを追加する

  1. Windows ノードプールを使用するには、ユーザー クラスタで Dataplane V2 を有効にする必要があります。ユーザー クラスタの構成ファイルに次の行を追加して、Dataplane V2 を有効にします。

    enableDataplaneV2: true

  2. ユーザー クラスタ構成ファイルの nodePools セクションに Windows ノードプールを追加します。Windows ノードプールに加えて、少なくとも 1 つの Linux ノードプールが必要です。osImage フィールドと osImageType フィールドを設定して、Windows ノードプールを作成します。

  • osImage: WINDOWS_VM_TEMPLATE_NAME は、ステップ 1 で準備した Windows VM テンプレートの名前に置き換えます。これは、ユーザー クラスタの構成ファイルで指定された vCenter データストアに存在する必要があります。
  • osImageType: OS イメージタイプには、windows を指定します。
# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

ステップ 5: Windows ノードプールを作成する

Windows ノードプールを作成する前に、Windows のプリフライト検証ツールのリストを実行します。- （省略可）プリフライト チェックの簡易版および詳細版の一方または両方を実行します。これにより、Windows 用のテスト VM が作成され、Windows VM テンプレートが検証されます。

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_KUBECONFIG
  • おすすめはしませんが、Windows のプリフライト チェックは、--skip-validation-windows フラグを使用してスキップできます。
  • Windows ノードプールの管理は、Linux ノードプールの管理と同じです。ノードプールの管理をご覧ください。クラスタとノードプールを作成、更新、アップグレードするコマンドも変更されず、ここに記載されています。
# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG

# Update an existing cluster with the new Windows node pool
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG

ステップ 6: Windows ノードが動作していることを確認する

  1. Windows ノードが作成されており、Ready であることを確認します。

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. ユーザー クラスタを診断し、正常かどうかを確認します。

    gkectl diagnose cluster --kubeconfig ADMIN_KUBECONFIG  --cluster-name CLUSTER_NAME

Windows Pod のデプロイ

Windows Server ノードは、この Key-Value ペア node.kubernetes.io/os=windows:NoSchedule で taint されます。

この taint によって、GKE スケジューラでは、Windows Server ノードで Linux コンテナの実行を試みることがなくなります。Windows Server ノードで Windows Server コンテナをスケジュール設定するには、マニフェスト ファイルに次の nodeSelector セクションを含める必要があります。

nodeSelector:
    kubernetes.io/os: windows

nodeSelector 構成済みの場合、クラスタで実行されるアドミッション Webhook は、この Windows ノードセレクタに新しいワークロードがあるかチェックします。新しいワークロードが発見された場合、次の許容値をワークロードに適用して、taint が設定された Windows Server ノードで動作できるようにします。

tolerations:
- key: "node.kubernetes.io/os"
  operator: "Equal"
  value: "windows"
  effect: "NoSchedule"

ステップ 1: Internet Information Services（IIS）デプロイメント ファイルを作成する

次の構成例では、Microsoft の公式 IIS イメージを 1 つの Pod にデプロイします。

次の内容で iis.yaml という名前の IIS ファイルを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: iis
  name: iis
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: iis
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: [Fill in with an available IP address]

ステップ 2: Deployment を作成し、Service を介して公開する

# Create the deployment
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG create -f iis.yaml

ステップ 3: Pod を検証する

kubectl を使用して、Pod のステータスを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

返される出力で Pod のステータスが「Running」になるまで待ちます。

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

Service のステータスを取得して、外部 IP フィールドが入力されるまで待ちます。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

予想される出力:

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   35.x.x.x     80:32233/TCP   17s

ブラウザを使用して http://EXTERNAL_IP を開き、IIS ウェブページを表示できます。

Windows ノードプールが含まれるユーザー クラスタをアップグレードする

Windows ノードプールがあるユーザー クラスタのアップグレード プロセスは、Linux 専用ユーザー クラスタのアップグレード プロセスと似ています。ただし前者では、アップグレードする前に、ベース VM テンプレートから Windows VM テンプレートを作成する必要があります。

アップグレード中に、ベース VM テンプレートのパッチビルド バージョンを更新するには、Microsoft から Windows Server 2019 の新しいパッチ バージョンをセキュリティ パッチとしてダウンロードします。セキュリティ パッチプロセスをご覧ください。

gkectl prepare windows --base-vm-template $BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path $BUNDLE_PATH --kubeconfig $ADMIN_CLUSTER_KUBECONFIG_PATH

ユーザー クラスタは、次のコマンドを実行してアップグレードします。

gkectl upgrade cluster --kubeconfig $ADMIN_KUBECONFIG --config $USER_CLUSTER_SEED_CONFIG

Windows ノードへのアクセス

Windows ノードにアクセスする標準的な方法は、ユーザー名とパスワードを使用することです。Linux ノードで一般的な、認証用の SSH 認証鍵ペアを介したアクセスとは異なります。

vSphere の Windows ノードの場合、ユーザー名は Administrator です。パスワードは、clusterapi-controller によって生成され、管理クラスタのユーザーの名前空間の windows-node-password Secret に保存されます。その Secret からパスワードを取得するコマンドは次のとおりです。

kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d

パスワードは、vCenter ユーザー インターフェースを使用して取得することもできます。ログインする VM に移動すると、その VM の password vApp プロパティでパスワードを確認できます。

ユーザー名とパスワードを取得したら、次のいずれかの方法で Windows VM にアクセスできます。

リモート デスクトップ プロトコルを使用する

RDP はテンプレートをビルドするときに有効にされているため、Windows VM には、RDP クライアントを使用してアクセスできます。

SSH を使用する

Windows VM に SSH 接続するには、次のコマンドを実行します。

ssh Administrator@[VM_IP_ADDRESS]

表示されたメッセージに従ってパスワードを入力し、VM に接続します。

Windows VM との間のファイルの転送

Windows VM との間のファイル転送は、SCP を使用して行えます。

次のコマンドで、Windows VM にファイルをアップロードします。

scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]

次のコマンドで、Windows VM からファイルをダウンロードします。

scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]

入力を求めるメッセージが表示されたらパスワードを入力します。

また、Windows VM へのファイルの転送で説明されているように、Cloud Storage や RDP を使用してファイルを転送することも可能です。

トラブルシューティング

SSH / RDP で Windows VM に接続できない

vCenter ウェブ コンソールで Test-NetConnection を実行して、VM がネットワークに接続しているかどうかを確認します。

ネットワークに接続されている場合は、結果に「PingSucceeded: true」が含まれます。VM がネットワークに接続されていない場合は、この VM に使用しているネットワーク アダプタを確認します。このネットワークでは、SSH / RDP を実行するワークステーションから VM への受信接続を許可してください。

kubelet、kube-proxy、flanneld が Windows VM で実行されていることを確認する

こちらの手順に沿って VM に接続し、次のコマンドを実行します。

# Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy
# Check that the flanneld process exists
Get-Process flanneld

スナップショット ツールの使用

スナップショット ツールを使用して、スナップショット tarball を取得します。この tarball には、ノード上のログファイルと、ノード上で実行されるトラブルシューティング コマンドの出力が含まれます。

gkectl diagnose snapshot --scenario system-with-logs --cluster-name [USER_CLUSTER_NAME] --kubeconfig [PATH_TO_KUBECONFIG]

Windows VM の作成に失敗する

管理クラスタのユーザー名前空間の clusterapi-controllers Pod にある vsphere-controller-manager コンテナのログを確認します。

kubectl --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME logs clusterapi-controllers-POD_NAME_SUFFIX vsphere-controller-manager

ユーザー クラスタの構成ファイルで指定したデータセンターのデータストアと同じ場所に VM テンプレートが配置されていることを確認します。

Windows VM は作成されたが、ノードが正常に起動しないか、ノードが表示されない

  • C:\var\log\startup.log にあるノードの起動ログを調べて、起動に失敗したものがあるかどうかを確認します。

    • flanneld が動作していない場合は、C:\Program Files\Cloudbase Solutions\Cloudbase-Init\startup.ps1 にある起動スクリプトを再実行してみてください。
    • kubelet が動作していない場合は、「C:\var\log」にある kubelet のログを確認してください。
    • kube-proxy が動作していない場合は、C:\var\log にある kube-proxy のログを確認してください。

ロギングとモニタリング

VMware の Anthos クラスタは、Linux ノードと Pod と同様に、Windows ノードと Pod のロギングとモニタリングをサポートします。

ロギングとモニタリングが構成されている場合は、Windows ノードにエージェントがデプロイされます。これらのエージェントでは、ノードのログと指標を収集、処理、エクスポートします。

Windows Logging エージェント

Windows Logging エージェントは、次のログを収集します。

  • Pod リソースタイプ: システム アプリケーションとユーザー アプリケーションのワークロード。

    デフォルトでは、Windows ユーザー アプリケーションのワークロード ログが収集されます。アプリケーション ログを無効にするには:

    • fluent-bit-windows-config ConfigMap を編集して、アプリケーション ログを収集する [Input] 項目（最初の [Input] 項目）をコメントアウトします。
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      この項目の下にあるすべての項目をコメントアウトしてください。次に例を示します。
      #    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?a-z0-9?(?:.a-z0-9?))_(?[^]+)(?.+)-(?[a-z0-9]{64}).log$
#      Tag                k8s_container...
#      Path               C:\var\log\containers\.log
#      Exclude_Path       kube-system.log,gke-connect.log,knative-serving.log,gke-system.log,istio-system.log,monitoring-system.log,config-management-system.log,gatekeeper-system.log,cnrm-system.log
#      DB                 C:\var\log\fluent-bit-k8s-container-application.db
#      Mem_Buf_Limit      30MB
#      Skip_Long_Lines    On
#      Refresh_Interval   10
#      # storage.type       filesystem
#      Buffer_Chunk_Size  512KB
#      Buffer_Max_Size    5M
#      Rotate_Wait        30
#      Ignore_Older       4h
    • rollout restart コマンドを実行して、fluent-bit-windows DaemonSet を再起動します。
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

  • ノードのリソースタイプ: kubelet、kube-proxy、Windows event-logs

ログには、コンソールでログ エクスプローラを使用してアクセスできます。詳細については、ログにアクセスするをご覧ください。

Windows モニタリング エージェント

Windows モニタリング エージェントは、Linux モニタリング エージェントとは異なる CPU とメモリ使用量の指標一式を収集します。Windows ノードと Pod のステータスをモニタリングするには、用意されたダッシュボードを使用します。コンソールで、[Monitoring] > [ダッシュボード] の順に選択し、[すべてダッシュボード] リストから [GKE On-Prem Windows node status] と [GKE On-Prem Windows Pod status] を選択します。

ダッシュボードは、Cloud Monitoring が有効になっている場合、管理クラスタのインストール時に自動的に作成されます。すでに管理クラスタを実行している場合は、次の JSON ファイルを使用し、これら手順に沿ってダッシュボードを作成します。

Windows エージェントが収集する指標の全一覧をご覧ください。

Windows 永続ストレージ

永続ストレージを使用して Windows Server コンテナを操作する場合は、StorageClass オブジェクトを作成し、そのオブジェクトの名前を PersistentVolumeClaim オブジェクトの storageClassName フィールドに指定する必要があります。これは、オンプレミス ユーザー クラスタのデフォルトの StorageClass は、ファイル システム タイプとして ext4 を使用するためです。これは、Linux コンテナでのみ機能します。Windows の場合は、ファイル システム タイプを ntfs に設定する必要があります。

Windows ストレージ クラスの例:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-storage-class
provisioner: kubernetes.io/vsphere-volume
parameters:
  datastore: my-datastore
  diskformat: thin
  fstype: ntfs

セキュリティ パッチプロセス

サポート対象の Anthos バージョンの定期的なパッチリリースとは別に、Anthos チームでは、リリース以外の期間中も新しい Windows パッチの更新を継続的に認定し、その結果を参考用に公開します。Anthos の次のパッチリリースを待たずに緊急のセキュリティ パッチの更新が必要な場合は、最新バージョンを使用して新しい VM テンプレートを作成し、既存の Windows ノードプールで新しいテンプレートが使用されるようにローリング アップデートを実行できます。

セキュリティ パッチ プロセスには、次の手順が含まれます。

  • Microsoft によって Windows Server 2019 用の新しいセキュリティ パッチがリリースされます。
  • Anthos では、最新のセキュリティ パッチ バージョンを認定し、その結果を公表します。
  • 認定された場合、ユーザーは次のことを行います。
    • Microsoft から最新のパッチ バージョンをダウンロードします。
    • こちらの手順に沿って、このパッチ バージョンを使用して新しい Windows VM テンプレートを作成します。
    • 次のコマンドを実行して、新しいテンプレートを使用するように Windows ノードプールを更新します。
gkectl update cluster --kubeconfig $ADMIN_KUBECONFIG --config $USER_CLUSTER_SEED_CONFIG

  • 新しいバージョンによって Anthos 側の変更が必要な場合は、次の月次 Anthos パッチリリースを待ってから、クラスタをアップグレードする必要があります。

  • 新しい Windows バージョンも Anthos との互換性がまったくない場合、Anthos チームはそのバージョンをスキップし、Microsoft による次のセキュリティ アップデートを待ちます。

Active Directory ドメイン参加

Active Directory ドメイン参加では、VM ホスト名の長さが 15 文字以下となる必要があります。IPAM モードの場合は、ユーザー クラスタの構成ファイルで VM ホスト名が設定されているため、長さを 15 文字以下にする必要があります。ここでの手順には、Windows ノードプールを作成する手順をベースとして、Windows VM テンプレートの作成時に、カスタマイズしたスクリプトを指定する手順が追加されています。

Active Domain DNS サーバーにアクセスできることを確認する

Active Directory Domain Services（AD DS）は、ドメイン ネーム システム（DNS）名前解決サービスを使用して、クライアントがドメイン コントローラを配置できるようにするとともに、ディレクトリ サービスをホストするドメイン コントローラが相互に通信できるようにすることができます。

DNS サーバーは、AD DS のロールでルート フォレストをインストールするときに作成されています。Windows VM が AD ドメインに参加するためには、その DNS サーバーにアクセスできる必要があります。DNS とファイアウォールは、使用している DNS サービス プロバイダのガイダンスに従って構成します。現在のネットワーク内の Windows VM が、AD ドメインの DNS サーバーに接続できるかどうかは、次のコマンドを実行することで確認できます。

PS C:\> nslookup DOMAIN_NAME DOMAIN_SERVER_IP
Server:  example-1-2-3-4.anthos
Address:  1.2.3.4
Name:    example.org
Address:  1.2.3.4

ステップ 1: カスタマイズしたスクリプトを使用して Windows VM テンプレートを作成する

  1. Windows ノードが Active Directory ドメイン参加のユーザー クラスタに参加する前に、カスタマイズしたスクリプトを実行します。このスクリプトは、管理ワークステーションのローカルパスに保存します。次のことに注意してください。

    • このスクリプトは、Active Directory ドメイン参加を行うために独自のスクリプトに置き換えることができます。
    • 管理者ユーザーを使用するのではなく、Active Directory ドメイン参加に必要な最小限の権限を持つユーザー アカウントを使用することをおすすめします。
    • （省略可）このスクリプトにパスワードを平文で保存しないようにするには、VM テンプレートで、パスワードをファイル内に配置し、スクリプトがそのパスワード ファイルを読み取り、ドメイン参加後にファイルを削除できるようにします。
    $domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force

  2. カスタマイズしたスクリプトを使用して Windows VM テンプレートを作成します。

    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG --customized-script CUSTOMIZED_SCRIPT_PATH

ステップ 2: Windows ノードプールを作成する

ステップ 2～6 では、標準的な手順に沿って、カスタマイズされた Windows VM テンプレートを使用して Windows ノードプールを作成します。

ステップ 3: Windows ノードの Active Domain 参加を確認する

AD ドメイン コントローラ VM で、次のコマンドを実行します。

PS C:\> Get-ADComputer -Filter 'Name -like "user-host-prefix*"'

DistinguishedName : CN=AD-VM-1,CN=Computers,DC=example,DC=org
DNSHostName       : ad-vm-1.example.org
Enabled           : True
Name              : AD-VM-1
ObjectClass       : computer
ObjectGUID        : b3609717-d24b-4df6-bccb-26ca8e8b9eb0
SamAccountName    : AD-VM-1$
SID               : S-1-5-21-3236879623-1561052741-2808297733-1103

ステップ 4: グループ マネージド サービス アカウントを構成する（省略可）

Windows Pod とコンテナの GMSA を構成するの手順を行います。Windows Pod とコンテナの GMSA は、ノードがドメインに参加した後に構成できます。

トラブルシューティング

cloudbase-init のカスタム スクリプト実行のログは、C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log にあります。ログファイルで LocalScriptPlugin を探し、関連するログを確認します。- 新しい Windows VM テンプレートを作成します。- 次のコマンドを実行して、新しいテンプレートを使用するように Windows ノードプールを更新します。

gkectl update cluster --kubeconfig $ADMIN_KUBECONFIG --config $USER_CLUSTER_SEED_CONFIG

Windows コンテナに関する考慮事項

Windows コンテナと Linux コンテナの主な違いは次のとおりです。

  • Windows コンテナ イメージとホスト/ノードの OS イメージのバージョン互換性。
    • Windows Server OS のバージョン番号は、メジャー、マイナー、ビルド、リビジョンの 4 つの部分から構成されています。
    • Windows Server コンテナ ベースイメージは、バージョン番号の最初の 3 つの部分が、ホスト OS イメージのものと一致する必要があります。ホストイメージとコンテナ ベースイメージの両方を更新することをおすすめしますが、リビジョンが一致する必要はありません。
    • OS イメージのバージョンが変更されるたびに、ユーザー側ではコンテナ イメージを再ビルドする必要があります。
  • 特権付きコンテナとホスト名前空間はサポートされていません。
    • ユーザーは、DaemonSet などのコンテナをデプロイしてノードを構成または変更することはできません。

vSphere Windows 上の Anthos clusters on VMware の制限事項

  • ユーザー クラスタには、Linux ノードプールが 1 つ以上含まれている必要があります。

    • Windows ノードプールのみを使用するクラスタを作成することはできません。
    • Linux ノードプールは、重要なアドオンを実行するために必要です。

  • Windows ノードには、Linux ノードよりも 1.5 倍多くのリソースが予約されるため、Windows の割り当て可能なリソースは少なくなります。

  • Windows ノードを使用するにあたり、最小マシンサイズは、Anthos clusters on VMware Linux の最小マシンサイズよりも大きくする必要が生じる場合があります。一般に、Windows ノードは、ノード コンポーネントとサービスの実行のオーバーヘッドが高くなるため、より多くのリソースを必要とします。

既知の問題

このセクションでは、Anthos clusters on VMware で使用される Windows ノードの既知の問題と、これらの問題を回避または復旧する方法について説明します。

バージョン 10.0.17763.1757 以降の Windows Update サービスはデフォルトで無効

バージョン 10.0.17763.1757 では、デフォルトで Windows Update サービスが無効になっているため、Windows VM テンプレート ビルドが中断され、サービスの実行を停止しようとします。「The service has not been started」というエラー メッセージが表示されます。

バージョン 10.0.17763.1757 以降を使用している場合は、回避策として、ベース Windows VM テンプレートでこのサービスを手動で開始してください。次のコマンドを実行して、Windows Update サービスを開始します。

sc.exe config wuauserv start= auto
Start-Service wuauserv

VM のシャットダウンを待機しているときに、Windows VM テンプレートのビルドがハングする

Windows VM テンプレートのビルドは、VM がシャットダウンされるのを約 40 分間待ちます。そのまま待ち続けてください。しばらくすると、コマンドは正常に完了します。

Windows ネットワーク インターフェース名の不一致により、ノードの起動中に問題が生じる

現在、Ethernet0 2 はノードの起動時にネットワーク インターフェース名として使用されます。実際のネットワーク インターフェース名が Ethernet0 2 でない場合、ノードはブートストラップに失敗し、ユーザー クラスタに参加できません。ベース VM テンプレートの元のネットワーク アダプタ タイプがすでに VMXNET 3 の場合、ノードの起動時のネットワーク インターフェース名は Ethernet0 であるため、想定の名前 Ethernet0 2 と一致しません。

回避策として、Windows Server 2019 ISO をインストールするときに Windows VM の作成時に指定した初期ネットワーク アダプター タイプには、E1000E が使用されていることを確認してください。あるいは、各 Windows ノードに手動でログインし、ネットワーク インターフェースの名前を Ethernet0 2 に変更した後、起動スクリプトを再実行します。

Rename-NetAdapter -Name 'Ethernet0' -NewName 'Ethernet0 2'
Rename-NetAdapter -Name 'vEthernet (Ethernet0)' -NewName 'vEthernet (Ethernet0 2)'
./etc/startup/start-script.ps1

Windows Pod が外部 IP アドレスと通信できない

この問題については、Microsoft のドキュメントに記載されています。このドキュメントには、「クエリを実行しようとしている外部 IP を ExceptionList から除外する必要があります」と記載されています。

回避策については、Cloud サポートまでお問い合わせください。

Windows Pod を削除した後、Windows コンテナがクリーンアップされない

これは既知の問題であり、Docker RemoveContainer も Windows で CreateFile を呼び出そうとします。回避策として、問題が発生している Windows ノードにログインして Restart-Service docker を実行すると、問題が軽減されるはずです。

VM の再起動後に Windows ノードが NotReady になる

現時点では、ノード起動スクリプトは VM を初めて起動したときにのみ実行されるため、VM を再起動しても起動スクリプトは実行されません。これにより、kubelet、kube-proxy サービスなど、一部の Windows サービスが停止します。そのため、ノードは NotReady ステータスになります。回避策として、以下のコマンドを実行してノードを削除し、コントローラが自動的に再作成するまで待ちます。

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME