Windows Server 操作系统节点池用户指南

借助 GKE on VMware，您可以创建 Windows Server 操作系统节点的节点池。运行 Windows Server 操作系统节点池的用户集群还可以运行包含使用 Ubuntu 或 Container-Optimized OS 的节点的节点池。

Windows Server 操作系统节点池的要求

节点池中的节点必须全部使用相同的操作系统，由 osImageType 参数指明。

在用户集群中创建 Windows Server 操作系统节点的节点池之前，请确保满足下列要求：

  • 在创建 Windows 节点池之前，管理员集群必须已经存在，因为 Windows 节点池仅在用户集群中受支持。
  • 用户集群必须至少运行一个 Linux 节点池，因为创建 Windows 节点池需要 Linux 节点池。
  • 拥有 Windows 节点池的用户集群必须在用户集群配置文件中将 enabledataplanev2 字段设置为 true。这将在该集群中的 Linux 节点上启用 Dataplane V2。

  • 默认情况下，系统会为新用户集群的 Windows 节点池启用 Windows Dataplane V2。

  • 已从 Microsoft 下载 Windows Server 2019 ISO，以创建特定于 Windows 节点池的虚拟机模板。 ISO 的语言/区域标记必须是 en-US。

  • vSphere 环境必须是 vSphere 6.7 Update 3 或更高版本。

在用户集群中创建 Windows 节点池

第 1 步：为 GKE on VMware 创建 Windows 虚拟机模板

开始之前，请确保您已创建管理员集群。

  1. 通过 Windows Server 2019 ISO 创建基础 Windows 虚拟机模板。

    • 要安装 Windows Server 2019 ISO 的 Windows 虚拟机的初始网络适配器类型应为 E1000E。
    • 遵循以下步骤：为 Windows Server 2019 创建 VMware vSphere 模板。
    • 记下运行 Windows ISO 安装程序时设置的初始密码，以供后续使用。
    • 确保您使用的是适用于 Windows Server 2019 的最新合格补丁版本，并查看我们的版本说明，以了解给定 Anthos 发布版本的最新合格 Windows 操作系统映像版本。请参阅安全补丁流程。
    • 您不能将使用 IDE 控制器的任何设备附加到基础虚拟机模板。

  2. 按照 VMWare 说明在基础 Windows 虚拟机模板上安装 VMware 工具（如果尚未安装）。

  3. 创建 Windows 虚拟机模板：

    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 虚拟机模板的路径

    • BUNDLE：GKE on VMware 软件包文件的路径

    在构建基本 Windows 虚拟机模板时，gkectl prepare windows 会运行 Windows sysprep。这样可以泛化虚拟机模板并清理虚拟机的网络设置，因此有助于在从同一模板克隆虚拟机时避免 IP 地址冲突。但是，Windows sysprep 作为封闭框运行，因此很难处理某些 sysprep 故障。

    如果您想在不运行 Windows sysprep 的情况下构建基础 Windows 虚拟机模板，请在 gkectl prepare windows 命令中添加 --skip-sysprep。

  4. 在命令输出的最后一行，您可以找到生成的 Windows 虚拟机模板的名称。记下该名称以备后续使用。 名称格式如下：

    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 步：（如使用代理则为必需）将网址列入许可名单以创建 Windows 节点池

如果集群位于代理服务器后面，则除了 GKE on VMware 所需的其他地址之外，还要将以下网址添加到代理服务器许可名单。

# 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. 必须在用户集群中启用 Dataplane V2 才能使用 Windows 节点池。将以下行添加到用户集群配置文件以启用 Dataplane V2：

    enableDataplaneV2: true

  2. 将 Windows 节点池添加到用户集群配置文件中的 nodePools 部分。除了 Windows 节点池之外，至少需要一个 Linux 节点池。设置 osImage 和 osImageType 字段以创建 Windows 节点池：

  • osImage：将 WINDOWS_VM_TEMPLATE_NAME 替换为第 1 步中准备好的 Windows 虚拟机模板的名称，该名称应位于用户集群配置文件中指定的相同 vCenter 数据存储区中。
  • osImageType：将操作系统映像类型指定为 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 测试虚拟机并验证 Windows 虚拟机模板：

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • 此命令适合在创建用户集群之前运行。如果您已有用户集群，则某些检查可能会失败。例如，hostconfig.yaml 文件中的 IP 地址可能已被用户集群中的现有节点使用。
  • 您可以使用 --skip-validation-windows 标志跳过 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 节点已使用以下键值对添加了污点：node.kubernetes.io/os=windows:NoSchedule。

此污点可确保 GKE 调度器不会尝试在 Windows Server 节点上运行 Linux 容器。如需在 Windows Server 节点上调度 Windows Server 容器，您的清单文件必须包含此 nodeSelector 部分：

nodeSelector:
    kubernetes.io/os: windows

配置 nodeSelector 后，在集群中运行的准入网络钩子会检查新工作负载中是否存在此 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 的用户集群类似，但您必须先通过基础虚拟机模板创建 Windows 虚拟机模板，然后才能升级。

您可以从 Microsoft 下载 Windows Server 2019 的较新补丁程序版本作为安全补丁程序，从而在升级期间更新基础虚拟机模板的补丁程序构建版本。请参阅安全补丁程序流程。

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

使用新的虚拟机模板名称更新配置文件中节点池的 osImage 字段。运行以下命令来升级用户集群：

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 密钥中。从该密钥获取密码的命令是：

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

您还可以通过 vCenter 界面获取密码。导航到您要登录的虚拟机，然后在该虚拟机的 password vApp 属性中找到密码。

获得用户名和密码后，您可以使用以下任一方法访问 Windows 虚拟机：

使用远程桌面协议

由于在模板构建期间启用了 RDP，您可以使用 RDP 客户端访问 Windows 虚拟机。

使用 SSH

要通过 SSH 连接到 Windows 虚拟机，请执行以下操作：

ssh Administrator@[VM_IP_ADDRESS]

按照提示输入密码以连接到虚拟机。

在 Windows 虚拟机中传输文件

您可以使用 scp 命令在 Windows 虚拟机中传输文件：

将文件上传到 Windows 虚拟机：

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

从 Windows 虚拟机下载文件：

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

出现提示时，请输入密码。

或者，您也可以使用 Cloud Storage 或 RDP 传输文件，如将文件传输到 Windows 虚拟机中所述。

更新 Windows Server 配置

Containerd 和 Windows Dataplane V2 从 1.11 版开始推出正式版。

在后续版本中，Windows 节点的 Docker 和 Flannel 将被弃用。我们建议您立即更新配置（如果适用），以改用 containerd 和 Windows Dataplane V2。请参阅更新 Windows Server 配置。

无法通过 SSH/RDP 连接到 Windows 虚拟机

通过在 vCenter 网页控制台上运行 Test-NetConnection，检查虚拟机是否连接到网络。

如果有网络连接，结果应包含 PingSucceeded: true。如果虚拟机没有网络连接，请检查用于此虚拟机的网络适配器。确保网络允许从要运行 SSH/RDP 的工作站到虚拟机的入站连接。

验证 kubelet、kube-proxy 和 CNI 服务是否正在 Windows 虚拟机上运行

按照此处介绍的步骤连接到您的虚拟机，并根据您的设置运行以下命令：

  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 虚拟机创建失败

检查管理员集群的用户命名空间中的 clusterapi-controllers pod 中 vsphere-controller-manager 容器的日志。

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

确保虚拟机模板位于用户集群配置文件中指定的数据中心和数据存储区。

Windows 虚拟机已创建，但节点无法正常启动或显示

  • 检查节点上的启动日志（位于 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 虚拟机的 SSH 连接，然后运行以下命令：

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

如果您在输出中找到 UserDataPlugin: 1，则表示 cloudbase-init 已执行该插件，这会导致启动脚本执行被跳过，并且完全不会引导 Windows 节点。

这通常是由于将 gkectl prepare windows 生成的虚拟机模板转换回虚拟机并启动引起的。

如需解决此问题，请通过再次运行 gkectl prepare windows 来创建新的虚拟机模板，并将其用于创建/升级/更新 Windows 节点池。

Logging 和 Monitoring

对于 Windows 节点和 Pod，GKE on VMware 支持日志记录和监控，其方式与 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.(?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-log

您可以使用控制台中的日志浏览器访问日志。如需了解详情，请参阅访问日志。

Windows 监控代理

Windows 监控代理收集的 CPU 和内存用量指标与 Linux 监控代理不同。如需监控 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

CSI 代理会自动部署到 Windows 节点上。您可以安装和使用所需的 Windows CSI 驱动程序，例如 SMB CSI 驱动程序。

Windows 节点上的 Node Problem Detector

Node Problem Detector 守护程序可用于 Windows 节点。如果您已升级到版本 1.9，则系统会自动启用 Node Problem Detector。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 时，节点的就绪条件将变为 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 补丁程序版本之间需要紧急安全补丁程序更新，您可以使用最新版本构建新的虚拟机模板，然后对现有 Windows 节点池执行滚动更新以使用新模板。

安全补丁程序流程包括以下步骤：

  • Microsoft 发布 Windows Server 2019 的新安全补丁程序。
  • Anthos 对最新的安全补丁程序版本进行资格审查并公布资格审查结果。
  • 如果通过审查，用户将执行以下操作：
    • 从 Microsoft 下载最新的补丁程序版本
    • 按照此处的步骤使用此补丁程序版本构建新的 Windows 虚拟机模板。
    • 运行以下命令来更新 Windows 节点池以使用新模板：
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • 如果新版本需要 Anthos 端进行更改，您必须等待下一个每月 Anthos 补丁程序版本并升级集群。

  • 如果新的 Windows 版本与 Anthos 完全不兼容，Anthos 团队将跳过该版本，并等待 Microsoft 的下一次安全更新。

Active Directory 网域加入

Active Directory 网域加入要求虚拟机主机名的长度不超过 15 个字符。对于 IPAM 模式，由于虚拟机主机名在用户集群配置文件中设置，因此您必须确保长度不超过 15 个字符。这些说明基于创建 Windows 节点池的说明，并增加了在 Windows 虚拟机模板构建期间提供自定义脚本的步骤。

验证 Active Domain DNS 服务器可访问

Active Directory 域服务 (AD DS) 使用域名系统 (DNS) 名称解析服务，使客户端能够找到网域控制器，并使托管目录服务的网域控制器能够相互通信。

DNS 服务器是在 AD DS 角色安装根林时创建的。要让任何 Windows 虚拟机加入 AD 网域，该虚拟机必须能够访问 DNS 服务器。按照您所使用的 DNS 服务提供商的指导配置 DNS 和防火墙配置。您可以运行以下命令来验证当前网络中的 Windows 虚拟机是否能够联系 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 虚拟机模板

  1. 在 Windows 节点加入用户集群以加入 Active Directory 网域之前执行自定义脚本。将此脚本存储在管理员工作站上的本地路径中。请注意以下事项：

    • 您可以将此脚本替换为您自己的脚本，以执行 Active Directory 网域加入。
    • 我们建议您使用具有 Active Directory 网域加入所需的最低权限的用户账号，而不是使用管理员用户。
    • （可选）要避免将密码以明文形式存储在此脚本中，请将密码存放在虚拟机模板的一个文件中，让脚本从该密码文件中读取，然后在加入网域后删除该文件。
    $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 虚拟机模板：

    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 虚拟机模板创建 Windows 节点池。

第 3 步：验证 Windows 节点已加入 Active Domain

在 AD 网域控制器虚拟机上，运行以下命令：

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 虚拟机模板。- 运行以下命令来更新 Windows 节点池以使用新模板：

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Windows 容器的注意事项

Windows 和 Linux 容器之间的一些显著差异包括：

  • Windows 容器映像与主机/节点操作系统映像的版本兼容性。
    • Windows Server 操作系统版本元组包含四个部分：主要版本、次要版本、内部版本和修订版本。
    • Windows 服务器容器基础映像必须与主机操作系统映像版本元组的前三部分匹配。修订版本不需要匹配，但建议您同时更新主机和容器基础映像。
    • 每当操作系统映像版本发生变化时，用户都需要重新构建容器映像
  • 不支持特权容器和主机命名空间。
    • 用户无法通过部署容器（如 Daemonset）来配置/更改节点。

vSphere Windows 上的 GKE on VMware 的限制

  • 用户集群必须包含至少一个 Linux 节点池。

    • 您无法创建仅包含 Windows 节点池的集群
    • 运行关键插件需要 Linux 节点池。

  • 由于为 Windows 节点预留的资源比 Linux 节点多 1.5 倍，因此 Windows 的可分配资源较低。

  • 使用 Windows 节点时，所需的机器大小下限可能大于 GKE on VMware Linux 机器大小下限。由于运行节点组件/服务的开销较高，Windows 节点通常需要更多资源。

已知问题

本部分列出了与 GKE on VMware 搭配使用的 Windows 节点的已知问题，以及用于避免这些问题或从这些问题中恢复的解决方法。

Windows pod 无法联系外部 IP 地址

Microsoft 文档中描述了此问题，其中指出“您需要从 ExceptionList 中排除您尝试查询的外部 IP”。

请联系 Google Cloud 支持团队，以寻求解决方法。

移除 Windows pod 后，Windows 容器不会被清理

这是一个已知问题，docker RemoveContainer 也尝试在 Windows 上调用 CreateFile。要解决此问题，请登录有问题的 Windows 节点并运行 Restart-Service docker，如此应该可缓解问题。 从 GKE on VMware 1.9 开始，fluent-bit-win 容器映像版本和 Docker 版本已更新以为此问题获取上游修复程序，此问题应该不会再重现。如果遇到此问题，请与 Google Cloud 支持团队联系。

具有 IP 地址冲突的 Windows 节点

这是一个很少发生的已知问题，如果您在 Windows 节点池创建过程中遇到此问题，可以按照以下步骤缓解此问题：

  • 如果您使用的是 IPAM 模式，可以手动从 vCenter 中移除存在 IP 地址冲突的虚拟机，系统会自动创建新虚拟机，该虚拟机应具有正确的 IP 地址分配。或者，您可以等待节点自动修复来检测此问题并重新创建 Windows 节点。

  • 如果您使用的是 DHCP 模式，则由于 DHCP 服务器遇到 IP 地址分配问题，新创建的虚拟机可能会再次具有重复的 IP 地址，您可以运行 gkectl update cluster 来删除待处理的 Windows 节点池，然后将它重新添加到 user-cluster.yaml，再次运行 gkectl update cluster 以创建它，新创建的节点池应具有正确的 IP 地址分配。

重新启动虚拟机后，Windows 节点变为 NotReady 状态

目前，节点启动脚本仅在虚拟机第一次启动时运行，因此如果您重新启动虚拟机，启动脚本不会再次运行。这将导致某些 Windows 服务停止运行，包括 kubelet、kube-proxy 服务等。这会导致节点处于 NotReady 状态。如果您使用的是 Windows Dataplane V2，则还需要清理过时的网络，然后 Dataplane V2 服务才能重启，并且需要运行脚本来清理，这可能会引起问题。因此，请重新创建节点。如需解决此问题，您可以运行以下命令来删除节点，然后等待控制器自动重新创建该节点。

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

诊断命令在 Windows 虚拟机硬件版本低于预期时失败

当 Windows 虚拟机模板使用旧硬件版本时，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. 重命名当前正在使用的虚拟机模板。

    这对于能够在后续步骤中创建新的虚拟机模板是必需的。

  2. 将 Windows 基础虚拟机模板转换为虚拟机。

  3. 按照将虚拟机升级到最新硬件版本中的步骤升级虚拟机的硬件版本。

  4. 将虚拟机转换回虚拟机模板。

  5. 运行以下命令，准备新的虚拟机模板，并使用之前的步骤中升级后的虚拟机模板作为基本虚拟机模板。

    gkectl prepare windows

    新生成的虚拟机模板名称应与用户集群配置文件中的 Windows 节点池 osImage 字段值匹配。如果值匹配，请执行下一步以重新创建 Windows 节点。

    如果模板名称与 osImage 字段值不匹配，请更新 osImage 值以与新生成的虚拟机模板名称匹配，然后运行以下命令：

    gkectl update cluster

  6. 通过运行以下命令重新创建 Windows 节点：

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    等待控制器自动重新创建节点。