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

10

Anthos clusters on VMware（GKE On-Prem）を使用すると、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 を有効にする場合は、ユーザー クラスタの構成ファイルで enableWindowsDataplaneV2 フィールドを true に設定する必要があります。これを有効にする場合は、vSwitch（ユーザー クラスタ構成ファイルの network.vCenter.networkName で指定）で MAC ラーニングを有効にする必要があります。

  • 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 インストーラを実行するときに設定された初期パスワードは、後で使用するためメモしておいてください。
    • Windows Server 2019（10.0.17763.2803）用の最新のパッチ適用済みバージョンを使用していることを確認してください。セキュリティ パッチプロセスをご覧ください。
    • IDE コントローラを使用するデバイスは、ベース VM テンプレートにアタッチできません。

  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_CLUSTER_KUBECONFIG_PATH

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

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

ステップ 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 を許可リストに登録する（プロキシを使用している場合は必須）

クラスタがプロキシ サーバーの背後にある場合は、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
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

ステップ 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 されます。

この 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

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

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 によって生成され、管理クラスタのユーザーの名前空間の 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_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 のログを確認してください。

ロギングとモニタリング

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

Windows ノードの Node Problem Detector

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

Node Problem Detector 用に、次のモニタリング構成が使用できます。

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

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

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

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

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

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

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

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

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

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

ログ エクスプローラで Node Problem Detector のログを取得するには、次のフィルタを使用します。

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 ノードプールの containerd サポートを設定する（プレビュー）

containerd ランタイムが Windows ノードプールのプレビュー機能として利用可能になりました。Docker ランタイムのサポートは、今後のバージョンで終了します。

containerd を有効にするには、該当する各ユーザー クラスタ構成ファイルで enableWindowsDataplaneV2 を true に設定したことを確認します。

バージョン 1.10 より前に作成されたユーザー クラスタをアップグレードし、ユーザー クラスタ構成ファイルで enableWindowsDataplaneV2 を true に設定した場合、containerd ランタイムが使用されます。

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 ノードの既知の問題と、これらの問題を回避または復旧する方法について説明します。

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

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

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

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

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

非公開レジストリがあるクラスタで VM テンプレートを準備できない

非公開レジストリがあるクラスタで gkectl prepare windows を実行すると、次のエラーでオペレーションが失敗する場合があります。

Failed to prepare your Windows environment: failed to create Anthos Windows VM template: failed to setup Windows VM template: failed to preload docker container images: failed to run "powershell.exe Get-Content 'C:\ProgramData\docker\config\registry-key.json' | docker login --username="" --password-stdin """ on VM "": timed out waiting for the condition

これは、gkectl prepare windows コマンドで使用される Windows VM が非公開レジストリのルート証明書で更新されておらず、docker login コマンドが失敗するために発生します。

回避策は次のとおりです。

  • gkectl prepare windows を実行する前に、CA 証明書ファイルをベース VM テンプレートにアップロードします。ファイルパスは C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt です。

  • gkectl prepare windows コマンドを実行します。エラーが発生したら、Windows VM に SSH で接続し、CA 証明書ファイルをアップロードします。ファイルパスは C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt です。