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 節點集區，因為建立 Windows 節點集區時需要 Linux 節點集區。
• 如果使用者叢集含有 Windows 節點集區，使用者叢集設定檔的 enabledataplanev2 欄位必須設為 true。這會啟用該叢集 Linux 節點上的 Dataplane V2。

• 根據預設，系統會為新使用者叢集的 Windows 節點集區啟用 Windows Dataplane V2。

• 您已從 Microsoft 下載 Windows Server 2019 ISO，用於建立 Windows 節點集區專用的 VM 範本。ISO 的語言/地區標記必須為 en-US。

• vSphere 環境必須為 vSphere 6.7 Update 3 以上版本。

• Windows Server OS 節點集區有下列限制：

  • 不支援 IPv6。
  • 進階叢集不支援 Windows 節點集區。

在使用者叢集中建立 Windows 節點集區

步驟 1：為 Google Distributed Cloud 建立 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 的最新合格修補程式版本，並參閱版本資訊，瞭解特定 Anthos 版本適用的最新合格 Windows OS 映像檔版本。請參閱安全性修補程式程序。
   • 您無法將使用 IDE 控制器的任何裝置附加至基本 VM 範本。

2. 如果尚未安裝，請在 Windows VM 基礎範本上安裝 VMware Tools。請參閱 VMware 說明文件中的「在 Windows 上手動安裝 VMware Tools」。

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 基礎 VM 範本，但不想執行 Windows sysprep，請在 gkectl prepare windows 指令中加入 --skip-sysprep。

4. 在指令輸出內容的最後一行，您可以找到產生的 Windows VM 範本名稱。請記下這個名稱，以供日後使用。 名稱格式如下：

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

步驟 2：將 Windows 容器映像檔上傳至私人登錄檔

如果未使用私人登錄檔，請略過這個步驟。

您可以在 Linux 管理工作站上使用 containerd，自動將 Windows 容器映像檔上傳至私人登錄檔。但 containerd 無法推送 Windows 容器映像檔基礎層，因此提取映像檔時，必須從 Microsoft 登錄檔提取基礎層。如要推送基礎層，請按照選項 2 的步驟操作。

選項 1：如果您不需要手動將 Windows 基礎層映像檔推送至私人登錄檔：

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

將 ADMIN_CLUSTER_CONFIG 替換為管理員叢集設定檔的路徑。

--upload-windows-images 旗標會指定要推送 Windows 容器映像檔。如未指定此旗標，系統只會將 Linux 容器映像檔推送至私有登錄檔。

方法 2：如需手動將 Windows 基礎層映像檔推送至私人登錄檔，請按照下列步驟操作：

• 請先使用已安裝 Docker 且可存取 gcr.io 的 Windows 電腦，再嘗試執行下列步驟。您只能將 Windows 容器映像檔提取到 Windows 電腦。
• 執行 docker login，向私人登錄檔進行驗證。

• 按照下列步驟，將 Windows 容器映像檔及其基礎層上傳至私人登錄檔：

  • 在 Windows 電腦上前往 Docker daemon.json 檔案：

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

  • 在 Docker daemon.json 檔案中新增下列程式碼，允許將外部層推送至私人登錄檔：

  {
    "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
  }
  

  • 將所需的 Windows 容器映像檔下載至本機 Windows 電腦，然後加上標記並推送至私人登錄檔。您對 daemon.json Docker 設定檔所做的變更，表示基本層可以推送至私人登錄檔。如要完成這些工作，請執行下列指令：

# 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：(使用 Proxy 時為必填) 將網址加入許可清單，以便建立 Windows 節點集區

如果叢集位於 Proxy 伺服器後方，除了 Google Distributed Cloud 要求的其他地址，請將這些網址新增至 Proxy 伺服器許可清單。

# 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 節點集區，您至少還需要一個 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

步驟 5：建立 Windows 節點集區

建立 Windows 節點集區前，請先執行 Windows 預檢驗證器清單。如果已有使用者叢集，請略過這個步驟。 - (選用) 執行快速或緩慢的預檢檢查 (或兩者都執行)，這會建立 Windows 測試 VM 並驗證 Windows VM 範本：

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

• 這個指令適用於建立使用者叢集前執行。如果您已有使用者叢集，某些檢查可能會失敗。舉例來說，hostconfig.yaml 檔案中的 IP 位址可能已由使用者叢集中的現有節點使用。
• 雖然不建議這麼做，但您可以使用 --skip-validation-windows 旗標略過 Windows 前置檢查。
• 管理 Windows 節點集區的方式與 Linux 節點集區相同。請參閱「Windows Server OS 節點集區適用的使用手冊」。建立、更新及升級叢集和節點集區的指令也維持不變，詳列如下。

# 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 節點會汙染這個鍵/值組合：node.kubernetes.io/os=windows:NoSchedule。

這項汙點可確保 GKE 排程器不會嘗試在 Windows Server 節點上執行 Linux 容器。如要在 Windows Server 節點上排定 Windows Server 容器，資訊清單檔案必須包含以下 nodeSelector 區段：

nodeSelector:
    kubernetes.io/os: windows

設定 nodeSelector 後，叢集中執行的准入 Webhook 會檢查新工作負載是否含有這個 Windows 節點選取器，如果有的話，就會將下列容許度套用至工作負載，讓工作負載在受汙染的 Windows Server 節點上執行：

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

步驟 1：建立 Internet Information Services (IIS) 部署檔案

以下是設定範例，可將 Microsoft 的官方 IIS 映像檔部署至單一 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：建立部署並透過服務公開

# 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

取得服務狀態，並等待外部 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 範本，才能升級。

升級期間，您可以從 Microsoft 下載較新的 Windows Server 2019 修補程式版本做為安全性修補程式，藉此更新基本 VM 範本的修補程式建構版本。請參閱安全性修補程式程序。

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

在設定檔中，使用新的 VM 範本名稱更新節點集區的 osImage 欄位。 執行下列指令，升級使用者叢集：

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

更改下列內容：

• ADMIN_CLUSTER_KUBECONFIG，並提供管理員 kubeconfig 檔案的路徑
• ADMIN_CLUSTER_CONFIG，並提供管理員叢集設定檔的路徑

存取 Windows 節點

存取 Windows 節點的標準方式是使用使用者名稱和密碼，這與 Linux 節點不同，Linux 節點通常是透過 SSH 金鑰配對進行驗證。

如果是 vSphere 上的 Windows 節點，使用者名稱為 Administrator。密碼是由 clusterapi-controller 產生，並儲存在管理員叢集使用者命名空間的 windows-node-password 密碼中。從該密鑰取得密碼的指令如下：

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：

使用遠端桌面通訊協定

由於遠端桌面通訊協定是在範本建構期間啟用，因此您可以使用遠端桌面通訊協定用戶端存取 Windows VM。

使用 SSH

如要透過 SSH 連線至 Windows VM，請按照下列步驟操作：

ssh Administrator@[VM_IP_ADDRESS]

按照提示輸入密碼，連線至 VM。

將檔案傳輸至 Windows VM，以及從 Windows VM 傳輸檔案

您可以使用 scp 指令，將檔案傳輸至 Windows VM，以及從 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]

系統出現提示時，輸入密碼。

您也可以使用 Cloud Storage 或 RDP 轉移檔案，詳情請參閱「將檔案轉移至 Windows VM」。

更新 Windows Server 設定

自 1.11 版起，Containerd 和 Windows Dataplane V2 現已正式發布。

Windows 節點的 Docker 和 Flannel 將在後續版本中淘汰。建議您立即更新設定 (如適用)，改用 containerd 和 Windows Dataplane V2。請參閱「更新 Windows Server 設定」。

無法透過 SSH/RDP 連線至 Windows VM

在 vCenter 網頁控制台上執行 Test-NetConnection，檢查 VM 是否已連上網路。

如果網路連線正常，結果應包含 PingSucceeded: true。如果 VM 沒有網路連線，請檢查用於這個 VM 的網路介面卡。確認網路允許從工作站連入 VM，以便執行 SSH/RDP。

確認 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 服務是否為「Running」。

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

3. 否則，請檢查 flanneld 程序是否為「Running」：

   # 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 記錄。

• 執行開機指令碼前，請先檢查 cloudbase-init 是否已執行 UserDataPlugin。

如要檢查，請透過 SSH 連線至 Windows VM，然後執行下列指令：

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 支援 Windows 節點和 Pod 的記錄和監控，與 Linux 節點和 Pod 相同。

設定記錄與監控功能後，代理程式就會部署在 Windows 節點上。這些代理程式會收集、處理及匯出節點的記錄和指標。

Windows 記錄代理程式

Windows 記錄代理程式會收集下列記錄：

• 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.(?<podname>[a-z0-9](?:[-a-z0-9][a-z0-9])?(?:.[a-z0-9]([-a-z0-9][a-z0-9])?)*)(?<namespacename>[^]+)_(?<container_name>.+)-(?<docker_id>[a-z0-9]{64}).log$
    #      Tag                k8s_container.<namespace_name>.<pod_name>.<container_name>
    #      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 事件記錄

您可以使用控制台中的記錄檔探索工具存取記錄。詳情請參閱「存取記錄」。

Windows 監控代理程式

Windows 監控代理程式收集的 CPU 和記憶體用量指標，與 Linux 監控代理程式不同。如要監控 Windows 節點和 Pod 的狀態，請使用準備好的資訊主頁。在主控台中，依序選取「Monitoring」>「Dashboards」，然後從「All Dashboards」清單中選取「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 Proxy 會自動部署到 Windows 節點。您可以安裝及使用所選的 Windows CSI 驅動程式，例如 SMB CSI 驅動程式。

Windows 節點上的節點問題偵測工具

節點問題偵測工具 Daemon 適用於 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 替換為節點名稱。

如要找出 Node Problem Detector 監控器產生的事件，請在 rules 區段中指定的規則的 reason 欄位中，尋找監控器名稱。

節點問題偵測工具監控器也會在節點上產生下列條件。如果節點問題偵測工具在節點上偵測到對應的失敗情況，這些值都會設為 true。

• KubeletUnhealthy
• KubeProxyUnhealthy
• ContainerRuntimeUnhealthy

只要其中一個條件設為 true，節點的 Ready 條件就會變成 false，防止系統在節點上排定新 Pod。

如果發現健康狀態不良，節點問題偵測工具會嘗試重新啟動相關系統服務，自動修復節點。

節點問題偵測工具記錄位於節點的 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 Directory 網域 DNS 伺服器

Active Directory 網域服務 (AD DS) 會使用網域名稱系統 (DNS) 名稱解析服務，讓用戶端能找到網域控制器，並讓代管目錄服務的網域控制器彼此通訊。

AD DS 角色安裝根樹系時，系統會建立 DNS 伺服器。如要讓任何 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 Directory 網域

在 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 作業系統版本元組包含四個部分：主要、次要、建構和修訂版本。
  • Windows 伺服器容器基本映像檔的前三個部分，必須與主機 OS 映像檔的版本元組相符。修訂版本不必相符，但建議您更新主機和容器基本映像檔。
  • OS 映像檔版本變更時，使用者必須重建容器映像檔
• 系統不支援具備特殊權限的容器和主機命名空間。
  • 使用者無法透過部署容器 (例如 Daemonset) 設定/變更節點。

適用於 vSphere Windows 的 Google Distributed Cloud 限制

• 使用者叢集至少須包含一個 Linux 節點集區。

  • 您無法只使用 Windows 節點集區建立叢集
  • 執行重要外掛程式時，必須使用 Linux 節點集區。

• 由於系統為 Windows 節點保留的資源是 Linux 節點的 1.5 倍，因此 Windows 的可分配資源較少。

• 使用 Windows 節點時，可能需要比 Google Distributed Cloud Linux 最小機器大小更大的機器。Windows 節點通常需要更多資源，因為執行節點元件/服務的負擔較重。

已知問題

本節列出搭配 Google Distributed Cloud 使用的 Windows 節點已知問題，以及避免或解決這些問題的因應措施。

Windows Pod 無法與外部 IP 位址通訊

如要瞭解這個問題，請參閱 Microsoft 說明文件，其中指出「您需要從 ExceptionList 中排除要查詢的外部 IP」。

如要繼續使用替代解決方案，請與 Google Cloud 支援團隊聯絡。

移除 Windows Pod 後，Windows 容器不會清除

這是已知問題，docker RemoveContainer 也會嘗試在 Windows 上呼叫 CreateFile。如要解決這個問題，請登入發生問題的 Windows 節點，然後執行 Restart-Service docker，即可降低問題風險。從 Google Distributed Cloud 1.9 開始，fluent-bit-win 容器映像檔版本和 Docker 版本已更新，可擷取這個問題的上游修正程式，因此不應再重現問題。如果遇到這個問題，請與 Google Cloud 支援團隊聯絡。

Windows 節點的 IP 位址衝突

這是極少發生的已知問題。如果在建立 Windows 節點集區時遇到這個問題，請按照下列步驟解決：

• 如果您使用 IPAM 模式，可以從 vCenter 手動移除 IP 衝突的 VM，系統會自動建立新的 VM，這些 VM 應會正確分配 IP。或者，您也可以等待節點自動修復功能偵測到這個問題，然後重新建立 Windows 節點。

• 如果您使用 DHCP 模式，由於 DHCP 伺服器在 IP 分配時發生問題，新建立的 VM 可能會再次出現重複的 IP。您可以執行 gkectl update cluster 刪除待處理的 Windows 節點集區，然後在 user-cluster.yaml 中重新新增，再次執行 gkectl update cluster 建立，新建立的節點集區應會正確分配 IP。

重新啟動 VM 後，Windows 節點會變成 NotReady

目前節點開機指令碼只會在 VM 首次啟動時執行，因此如果重新啟動 VM，開機指令碼不會再次執行。這會導致部分 Windows 服務停止執行，包括 kubelet、kube-proxy 服務等。這會導致節點處於 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. 按照「將虛擬機器升級至最新硬體版本」一文的步驟，升級虛擬機器的硬體版本。

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
   

   等待控制器自動重新建立節點。