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

Google Distributed Cloud では、Windows Server OS ノードのノードプールを作成できます。Windows Server OS ノードプールを実行するユーザー クラスタでは、Ubuntu または Container-Optimized OS を使用するノードを含むノードプールを運用することもできます。

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

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

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

• Windows ノードプールを作成する前に、管理クラスタが用意されていること（Windows ノードプールは、ユーザー クラスタでのみサポートされています）。
• ユーザー クラスタで、Linux ノードプールが 1 つ以上運用されていること（Windows ノードプールの作成には Linux ノードプールが必要です）。
• Windows ノードプールを持つユーザー クラスタでは、ユーザー クラスタの構成ファイルで enabledataplanev2 フィールドが true に設定されていること。これにより、そのクラスタ内の Linux ノードで Dataplane V2 が有効になります。

• デフォルトでは、新しいユーザー クラスタの Windows ノードプールで Windows Dataplane V2 が有効になっています。

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

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

注: IPv6 はサポートされていません。

注: enableDataplaneV2 フィールドは true に設定する必要があります。

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

注: Windows コンテナ イメージは、Microsoft レジストリから提供されるベースレイヤ（外部レイヤとも呼ばれます）とのバンドルとしては使用できません。Microsoft レジストリからのベースレイヤ イメージは、再配布できないためです。したがって、ベースレイヤ イメージは、Google Container Registry（GCR）から pull する必要があります。

ステップ 1: Google Distributed Cloud の Windows VM テンプレートを作成する

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

注: 管理ワークステーションの場合、Windows VM が稼働している ESXi ホスト IP に、管理ワークステーションとジャンプホストがアクセスできるようにする必要があります。これにより、gkectl prepare windows を実行できるようになります。

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

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

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

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

   gkectl prepare windows \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
       --bundle-path BUNDLE \
       [--skip-sysprep]
   

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

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス

   • BASE_WINDOWS_VM_TEMPLATE: ベース Windows VM テンプレートへのパス

   • BUNDLE: Google Distributed Cloud バンドル ファイルへのパス

   ベース Windows VM テンプレートの作成の一環として、gkectl prepare windows で Windows の sysprep が実行されます。これにより、VM テンプレートが一般化され、VM のネットワーク設定がクリーンアップされるため、同じテンプレートから VM のクローンを作成する際の IP アドレスの競合を回避できます。ただし、Windows sysprep はクローズド ボックスとして実行されるため、特定の sysprep の障害を処理するのは困難です。

   Windows sysprep を実行せずにベース Windows VM テンプレートを構築する場合は、gkectl prepare windows コマンドに --skip-sysprep を指定します。

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

   Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"
   

注: 作成された VM テンプレートは、Windows ノードプールの OS イメージとして使用され、ノードが正しく機能するために必要なスクリプトを初回起動時にトリガーするように準備されます。そのため、この VM テンプレートに対しては操作を行わないことをおすすめします（たとえば、このテンプレートを VM に変換してなんらかの操作を実行してから再度 VM テンプレートに変換するなど）。

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

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

Linux 管理ワークステーションで containerd を使用すると、非公開レジストリへの Windows コンテナ イメージのアップロードを自動化できます。ただし、containerd は Windows コンテナ イメージのベースレイヤを push できません。つまり、イメージを pull するときにベースレイヤを Microsoft レジストリから pull する必要があります。ベースレイヤを push するには、オプション 2 の手順に沿って操作します。

オプション 1: Windows ベースレイヤのイメージを非公開レジストリに手動で push する必要がない場合は、次のコマンドを実行します。

gkectl prepare --config <var class="edit">ADMIN_CLUSTER_CONFIG</var> --upload-windows-images

ADMIN_CLUSTER_CONFIG は、管理クラスタの構成ファイルへのパスに置き換えます。

--upload-windows-images フラグは、Windows コンテナ イメージが push されることを指定します。このフラグを指定しないと、Linux コンテナ イメージのみが非公開レジストリに push されます。

オプション 2: Windows ベースレイヤのイメージを非公開レジストリに手動で push する必要がある場合は、次のようにします。

• このステップでは、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:gke_windows_pause_20210302_RC00_2019
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019

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

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

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

クラスタがプロキシ サーバーの背後にある場合は、Google Distributed Cloud に必要な他のアドレスに加えて、次の 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

注: Windows Server で使用される URL の一覧をご覧ください。

ステップ 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: 8
  memoryMB: 16384
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

注: Windows Server ノードは、Linux ノードよりも多くのリソースを必要とします。前の例で示した CPU とメモリの値をおすすめします。

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

Windows ノードプールを作成する前に、Windows のプリフライト検証ツールのリストを実行します。すでにユーザー クラスタがある場合は、この手順をスキップします。-（省略可）高速および低速のプリフライト チェックのいずれかまたは両方を実行します。これにより、Windows 用のテスト VM が作成され、Windows VM テンプレートが検証されます。

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

• このコマンドは、ユーザー クラスタを作成する前に実行します。すでにユーザー クラスタがある場合は、特定のチェックが失敗する可能性があります。たとえば、hostconfig.yaml ファイルの IP アドレスが、ユーザー クラスタ内の既存のノードですでに使用されている場合があります。
• おすすめはしませんが、Windows のプリフライト チェックは、--skip-validation-windows フラグを使用してスキップできます。
• Windows ノードプールの管理は、Linux ノードプールの管理と同じです。ノードプールの管理をご覧ください。クラスタとノードプールを作成、更新、アップグレードするコマンドも変更されず、ここに記載されています。

# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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

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

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

   kubectl --kubeconfig USER_KUBECONFIG get nodes 
   

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

   gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG  --cluster-name CLUSTER_NAME
   

Windows Pod のデプロイ

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

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

nodeSelector:
    kubernetes.io/os: windows

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

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

ステップ 1: Internet Information Services（IIS）Deployment ファイルを作成する

次の構成例では、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 ノードプールで動作するように、Windows Server 2019 でビルドする必要があります。コンテナホストのバージョンをコンテナ イメージのバージョンと一致させるをご覧ください。

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

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

警告: ベース VM テンプレートは、空の Windows Server 2019 VM テンプレートである必要があります。現在のノードプールで使用されている既存の Windows VM テンプレートを使用して、新しい 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

注: このコマンドは、新しく準備された VM テンプレート名を出力します。

構成ファイルでノードプールの osImage フィールドを新しい VM テンプレート名に更新します。ユーザー クラスタは、次のコマンドを実行してアップグレードします。

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

• ADMIN_CLUSTER_KUBECONFIG は、管理 kubeconfig ファイルのパスに置き換えます。
• ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパスに置き換えます。

Windows ノードへのアクセス

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

vSphere の Windows ノードの場合、ユーザー名は Administrator です。パスワードは、clusterapi-controller によって生成され、管理クラスタのユーザーの Namespace の 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 にアクセスできます。

Remote Desktop Protocol の使用

注: RDP（Remote Desktop Protocol）アクセスは、gkectl prepare windows で Windows VM テンプレートをビルドする際に有効になります。また、ファイアウォール ルールが TCP ポート 3389 での RDP アクセスを許可していることを確認する必要があります。

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

SSH の使用

注: SSH サーバーは、gkectl prepare windows で Windows VM テンプレートをビルドする際にインストールされます。そのため、Windows VM には、その SSH サーバーを使用して SSH 接続できます。

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

ssh Administrator@[VM_IP_ADDRESS]

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

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

scp コマンドを使用すると、Windows VM 間でファイルを転送できます。

次のコマンドで、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 を使用してファイルを転送することも可能です。

Windows Server 構成の更新

containerd と Windows Dataplane V2 は、バージョン 1.11 より一般提供になりました。

Windows ノードの Docker と Flannel は、今後のリリースで非推奨となります。可能であれば、代わりに containerd と Windows Dataplane V2 を使用するように、今すぐ構成を更新することをおすすめします。Windows Server 構成を更新するをご覧ください。

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

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

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

kubelet、kube-proxy、CNI サービスが Windows VM で動作していることを確認する

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

1. すべての構成で、次のコマンドを実行します。

   # Check that kubelet and kube-proxy services have status 'Running'
   Get-Service kubelet
   Get-Service kube-proxy
   

2. クラスタの構成で windowsDataplaneV2 が true に設定されている場合は、antrea-agent、ovsdb-server、ovs-vswitchd の各サービスが「実行中」であることを確認します。

   # Check that CNI services have the status of 'Running'
   Get-Service antrea-agent
   Get-Service ovsdb-server
   Get-Service ovs-vswitchd
   

3. それ以外の場合は、flanneld プロセスが「実行中」であることを確認します。

   # 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 の作成に失敗する

管理クラスタの Namespace の clusterapi-controllers Pod に含まれる vsphere-controller-manager コンテナのログを確認します。

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

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

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

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

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

• 起動スクリプトを実行する前に、cloudbase-init が UserDataPlugin をすでに実行しているかどうかを確認します。

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

ls "HKLM:\\Software\Cloudbase Solutions\Cloudbase-Init\id-ovf\"

出力に UserDataPlugin: 1 が含まれている場合、cloudbase-init がそのプラグインをすでに実行していることを意味します。この場合、起動スクリプトの実行がスキップされ、Windows ノードがブートストラップされることはありません。

これは通常、gkectl prepare windows で生成された VM テンプレートを再び VM に変換して電源を入れる場合に発生します。

この問題を解決するには、もう一度 gkectl prepare windows を実行して新しい VM テンプレートを作成し、これを Windows ノードプールの作成 / アップグレード / 更新に使用します。

ロギングとモニタリング

Google Distributed Cloud は、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_pod_status.json
• windows_node_status.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

CSI プロキシは Windows ノードに自動的にデプロイされます。SMB CSI ドライバなど、任意の Windows CSI ドライバをインストールして使用できます。

Windows ノードの問題検出機能

Windows ノードでは、ノードの問題検出機能デーモンを使用できます。ノードの問題の検出機能は、バージョン 1.9 にアップグレードすると、自動的に有効になります。ノードの問題の検出機能は、一般的なノードの問題の迅速な検出に役立ちます。ノードの問題の検出機能は、潜在的な問題を継続的にチェックし、ノードのイベントおよび状態として報告します。ノードが正しく動作していない場合は、kubectl コマンドを使用して、対応するイベントや状態を検索できます。

ノードの問題の検出機能用に、次のモニタリング構成が使用できます。

• windows-health-checker-kubelet
• windows-health-checker-kubeproxy
• windows-health-checker-docker
• windows-health-checker-containerd
• windows-defender-monitor

ノードのイベントと状態を取得するには、次のコマンドを実行します。

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

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

• KUBECONFIG は、ノードを含むクラスタの kubeconfig ファイルのパスに置き換えます。
• NODE_NAME は、ノードの名前に置き換えます。

ノードの問題の検出機能が生成したイベントを特定するには、rules セクションで指定されているルールの reason フィールドでモニター名を探します。

ノードの問題の検出機能モニターは、ノードに関する次の状態も生成します。ノードの問題の検出機能がノード上の対応する障害シナリオを検出すると、これらがそれぞれ true に設定されます。

• KubeletUnhealthy
• KubeProxyUnhealthy
• ContainerRuntimeUnhealthy

いずれかの状態が true に設定されている場合、ノードの Ready 状態は false になり、新しい Pod がノードでスケジュールされなくなります。

異常な状態が見つかると、ノードの問題の検出機能は、関連するシステム サービスを再起動してノードの自動修復を試みます。

注: containerd の場合、ノードの問題の検出機能は API サーバーにのみ問題を表示し、containerd サービスを再起動してノードの自動修復は図りません。

ノードの問題の検出機能のログは、ノードの C:\var\log\node-problem-detector フォルダにあります。ロギングとモニタリングが有効になっている場合、ログは Cloud Logging にエクスポートされ、ログ エクスプローラで表示できます。

ログ エクスプローラでノードの問題の検出機能のログを取得するには、次のフィルタを使用します。

resource.type="k8s_node"
log_name="projects/PROJECT_NAME/logs/node-problem-detector"

PROJECT_NAME は、プロジェクト名に置き換えます。

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

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

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

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_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
   

BUNDLE_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_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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

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

vSphere Windows 上の Google Distributed Cloud の制限事項

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

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

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

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

既知の問題

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

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

注: この問題は、Flannel（WindowsDataplaneV2 が無効になっている場合）にのみ適用されます。この問題は、WindowsDataplaneV2 が有効な場合は発生しません。

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

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

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

これは既知の問題であり、Docker RemoveContainer も Windows で CreateFile を呼び出そうとします。回避策として、問題が発生している Windows ノードにログインして Restart-Service docker を実行すると、問題が軽減されるはずです。Google Distributed Cloud 1.9 から、fluent-bit-win コンテナ イメージ バージョンと Docker バージョンが更新され、この問題のアップストリーム修正が取得されたため、これ以上再現されないはずです。この問題が発生した場合は、Google Cloud サポートにお問い合わせください。

IP アドレスの競合がある Windows ノード

これはごくまれに発生する既知の問題ですが、Windows ノードプールの作成時にこの問題が発生した場合は、次の手順で軽減できます。

• IPAM モードを使用している場合は、IP が競合する VM を vCenter から手動で削除できます。新しい VM は自動的に作成され、正しい IP が割り振られます。または、ノードの自動修復がこの問題を検知するのを待ってから、Windows ノードを再作成することもできます。

• DHCP モードを使用している場合、DHCP サーバーで IP 割り振りの問題が発生すると、この場合も新しく作成された VM で IP が重複する可能性があります。gkectl update cluster を実行して保留中の Windows ノードプールを削除します。それを再度 user-cluster.yaml に追加し、gkectl update cluster を実行してノードプールをもう一度作成すると、新しく作成されるノードプールには正しい IP が割り振られます。

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

現時点では、ノード起動スクリプトは VM を初めて起動したときにのみ実行されるため、VM を再起動しても起動スクリプトは再度実行されません。これにより、kubelet、kube-proxy サービスなど、一部の Windows サービスが停止します。このため、ノードが NotReady ステータスになります。Windows Dataplane V2 を使用している場合は、Dataplane V2 サービスを再起動する前に、古いネットワークもクリーンアップする必要があります。また、クリーンアップ用のスクリプトを実行する必要があり、問題が発生する可能性があります。したがって、代わりにノードを再作成します。回避策として、以下のコマンドを実行してノードを削除し、コントローラが自動的に再作成するまで待ちます。

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Windows VM のハードウェア バージョンが想定より低い場合、診断コマンドが失敗する

Windows VM テンプレートが古いハードウェア バージョンを使用している場合、gkectl diagnose cluster コマンドは失敗して次のメッセージが出力されます。

Checking storage...FAILURE
    Reason: 1 storage error(s).
    Unhealthy Resources:
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue. Use --detailed=true for the list of VMs.
    Debug Information:
    {
      "NODE_NAME": "vmx-XX",
    }

この問題の解決手順は次のとおりです。

1. 現在使用している VM テンプレートの名前を変更します。

   これは、次の手順で新しい VM テンプレートを作成できるようにするために必要です。

2. Windows のベース VM テンプレートを VM に変換します。

3. 仮想マシンの最新のハードウェア バージョンへのアップグレードの手順に沿って、VM のハードウェア バージョンをアップグレードします。

4. VM を再び VM テンプレートに変換します。

5. 次のコマンドを実行して、前の手順でアップグレードした VM テンプレートをベース VM テンプレートとして使用し、新しい VM テンプレートを準備します。

   gkectl prepare windows
   

   新しく生成された VM テンプレート名は、ユーザー クラスタ構成ファイルの Windows ノードプール osImage フィールド値と一致する必要があります。値が一致する場合は、次のステップに進んで Windows ノードを再作成します。

   テンプレート名が osImage フィールド値と一致しない場合は、osImage の値を新しく生成された VM テンプレート名に合わせて更新し、次のコマンドを実行します。

   gkectl update cluster
   

6. 次のコマンドを実行して Windows ノードを再作成します。

   kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
   

   コントローラによってノードが自動的に再作成されるまで待ちます。