借助 Anthos clusters on VMware (GKE On-Prem),您可以创建 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,则用户集群配置文件必须将
enableWindowsDataplaneV2
字段设置为true
。如果您启用此功能,则您的 vSwitch(在用户集群配置文件中使用network.vCenter.networkName
指定)必须启用 MAC 学习。已从 Microsoft 下载 Windows Server 2019 ISO,以创建特定于 Windows 节点池的虚拟机模板。 ISO 的语言/区域标记必须是 en-US。
vSphere 环境必须是 vSphere 6.7 Update 3 或更高版本。
在用户集群中创建 Windows 节点池
第 1 步:为 Anthos clusters on VMware 创建 Windows 虚拟机模板
开始之前,请确保您已创建管理员集群。
通过 Windows Server 2019 ISO 创建基础 Windows 虚拟机模板。
- 要安装 Windows Server 2019 ISO 的 Windows 虚拟机的初始网络适配器类型应为 E1000E。
- 遵循以下步骤:为 Windows Server 2019 创建 VMware vSphere 模板。
- 记下运行 Windows ISO 安装程序时设置的初始密码,以供后续使用。
- 确保您使用的是适用于 Windows Server 2019 的最新合格补丁程序版本 10.0.17763.2114。请参阅安全补丁程序流程。
- 您不能将使用 IDE 控制器的任何设备附加到基础虚拟机模板。
按照 VMWare 说明在基础 Windows 虚拟机模板上安装 VMware 工具(如果尚未安装)。
创建 Windows 虚拟机模板:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG_PATH
在命令输出的最后一行,您可以找到生成的 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 节点池
如果集群位于代理服务器后面,则除了 Anthos clusters 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 节点池添加到用户集群配置文件
必须在用户集群中启用 Dataplane V2 才能使用 Windows 节点池。将以下行添加到用户集群配置文件以启用 Dataplane V2:
enableDataplaneV2: true
将 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: 4 memoryMB: 8192 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 节点正在运行
确认 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
后,在集群中运行的准入网络钩子会检查新工作负载中是否存在此 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
运行以下命令来升级用户集群:
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 虚拟机传输文件:
将文件上传到 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 虚拟机中所述。
问题排查
无法通过 SSH/RDP 连接到 Windows 虚拟机
通过在 vCenter 网页控制台上运行 Test-NetConnection
,检查虚拟机是否连接到网络。
如果有网络连接,结果应包含 PingSucceeded: true
。如果虚拟机没有网络连接,请检查用于此虚拟机的网络适配器。确保网络允许从要运行 SSH/RDP 的工作站到虚拟机的入站连接。
验证 kubelet、kube-proxy 和 flanneld 在 Windows 虚拟机上运行。
按照此处介绍的步骤连接到您的虚拟机,并运行以下命令:
# 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 虚拟机创建失败
检查管理员集群的用户命名空间中的 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 日志。
- 如果 flanneld 未在运行,请尝试重新运行位于
日志和监控
对于 Windows 节点和 pod,Anthos clusters 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?))_(? [^]+)(? .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.+)-(? [a-z0-9]{64}).log$ # Tag k8s_container. . . # Path C:\var\log\containers\ - 运行
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
Windows 节点上的 Node Problem Detector
Node Problem Detector 守护程序可用于 Windows 节点。如果您已升级到版本 1.9,则系统会自动启用 Node Problem Detector。Node Problem Detector 有助于快速检测一些常见节点问题。Node Problem Detector 会不断检查可能的问题,并将其报告为节点上的事件和条件。当节点行为异常时,您可以使用 kubectl
命令查找相应的事件和条件。
Node Problem Detector 启用了以下监控配置:
- windows-health-checker-kubelet
- windows-health-checker-kubeproxy
- windows-health-checker-docker
- windows-defender-monitor
如需获取节点上的事件和条件,请运行以下命令:
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 虚拟机模板
在 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
使用自定义脚本创建 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 上的 Anthos clusters on VMware 的限制
用户集群必须包含至少一个 Linux 节点池。
- 您无法创建仅包含 Windows 节点池的集群
- 运行关键插件需要 Linux 节点池。
由于为 Windows 节点预留的资源比 Linux 节点多 1.5 倍,因此 Windows 的可分配资源较低。
使用 Windows 节点时,所需的机器大小下限可能大于 Anthos clusters on VMware Linux 机器大小下限。由于运行节点组件/服务的开销较高,Windows 节点通常需要更多资源。
已知问题
本部分列出了与 Anthos clusters on VMware 搭配使用的 Windows 节点的已知问题,以及用于避免这些问题或从这些问题中恢复的解决方法。
Windows pod 无法联系外部 IP 地址
Microsoft 文档中描述了此问题,其中指出“您需要从 ExceptionList 中排除您尝试查询的外部 IP”。
请联系 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 模式,可以手动从 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
未能在具有私有注册表的集群上准备虚拟机模板
在具有私有注册表的集群上运行 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 虚拟机尚未使用私有注册表根证书进行更新,从而导致 docker login
命令失败。
解决方法如下:
在运行
gkectl prepare windows
之前,将 CA 证书文件上传到基础虚拟机模板。文件路径应为C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt
。运行
gkectl prepare windows
命令。当您看到出现错误时,请通过 SSH 连接到 Windows 虚拟机并上传 CA 证书文件。其文件路径应为C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt
。