您可以使用 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 範本
開始前,請確認您已建立管理員叢集。
使用 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 範本。
如果尚未安裝,請在 Windows VM 基礎範本上安裝 VMware Tools。請參閱 VMware 說明文件中的「在 Windows 上手動安裝 VMware Tools」。
建立 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
會執行 Windowssysprep
。這會將 VM 範本一般化,並清除 VM 的網路設定,因此有助於避免從相同範本複製 VM 時發生 IP 位址衝突。不過,Windowssysprep
是以封閉式方塊的形式執行,因此難以處理某些sysprep
失敗情形。如要建構 Windows 基礎 VM 範本,但不想執行 Windows
sysprep
,請在gkectl prepare windows
指令中加入--skip-sysprep
。在指令輸出內容的最後一行,您可以找到產生的 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 節點集區
如要使用 Windows 節點集區,必須在使用者叢集中啟用 Dataplane V2。在使用者叢集設定檔中新增下列指令行,即可啟用 Dataplane V2:
enableDataplaneV2: true
在使用者叢集設定檔的
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 節點是否正在執行
確認 Windows 節點已建立並處於
Ready
狀態。kubectl --kubeconfig USER_KUBECONFIG get nodes
診斷使用者叢集,檢查是否正常運作。
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,然後根據設定執行下列指令:
如要查看所有設定,請執行下列指令:
# Check that kubelet and kube-proxy services have status 'Running' Get-Service kubelet Get-Service kube-proxy
如果叢集已將
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
否則,請檢查 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 記錄。
- 如果 flanneld 未執行,請嘗試重新執行位於
執行開機指令碼前,請先檢查 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 代理程式收集的完整指標清單,請參閱相關說明。
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 範本
在 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
使用自訂指令碼建立 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", }
如要修正這個問題,請按照下列步驟操作:
重新命名目前使用的 VM 範本。
這是必要步驟,因為您需要在後續步驟中建立新的 VM 範本。
將 Windows 基礎 VM 範本轉換為 VM。
按照「將虛擬機器升級至最新硬體版本」一文的步驟,升級虛擬機器的硬體版本。
將 VM 轉換回 VM 範本。
執行下列指令,準備新的 VM 範本,並使用先前步驟中升級的 VM 範本做為基本 VM 範本。
gkectl prepare windows
新產生的 VM 範本名稱應與使用者叢集設定檔中的 Windows 節點集區
osImage
欄位值相符。如果值相符,請繼續下一個步驟,重新建立 Windows 節點。如果範本名稱與
osImage
欄位值不符,請更新osImage
值,使其與新產生的 VM 範本名稱相符,然後執行下列指令:gkectl update cluster
執行下列指令,重新建立 Windows 節點:
kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
等待控制器自動重新建立節點。