排查 Windows Server 节点池问题

在 Google Kubernetes Engine (GKE) 中运行 Windows Server 节点池时，您可能会遇到 Pod 无法启动、拉取 Windows 容器映像时出错、网络连接问题或节点无法启动等问题。

您可以使用本文档诊断和解决这些常见问题，并确保基于 Windows 的应用可靠运行。

对于管理具有 Windows 节点池的 GKE 集群的平台管理员和运维人员，以及在 GKE 上部署和运行基于 Windows 的应用的应用开发者，此信息非常重要。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

如需了解更多常规指导信息，请参阅 Kubernetes 文档中有关调试 Pod 和 Service 的内容。

Containerd 节点问题

如需了解如何解决使用 containerd 节点映像时出现的问题，请参阅 Windows Server 节点池中的问题。

Windows Pod 无法启动

基础映像与 Windows Server 主机操作系统版本之间的不兼容可能会导致 Pod 无法启动。

表现

  • Windows Pod 无法启动。
  • 节点报告 NotReady 状态。

原因

容器映像是基于与宿主节点的 Windows Server 版本不兼容的旧基础 Windows 映像构建的。

解决方法

使用基础 Windows 映像（包含 2020 年 3 月或之后的 Windows 更新）构建容器映像。如需详细了解 Microsoft 容器兼容性，请参阅关于 2020 年 2 月 Windows Server 容器不兼容问题的 Microsoft 文档。

映像拉取错误

Windows Server 容器映像通常比 Linux 映像大得多，这可能会导致超时。

表现

  • 出错提示，例如 Failed to pull image 或 context cancelled。
  • Pod 显示 ErrImagePull 状态。

原因

Windows Server 容器映像及其组成的各个层可能很大。它们的大小可能会导致 kubelet 代理在下载和提取容器层时超时并失败。

解决方法

如需解决这些映像拉取失败问题，请尝试以下解决方案：

  • 增加节点 CPU：容器提取在各个核心之间并行执行，因此具有更多核心的机器类型可缩短总体拉取时间。
  • 优化映像层：为了提高 Docker 层缓存的效率，以及映像拉取的重试成功概率，请将应用层拆分为更小的层。如需了解详情，请参阅 Docker 存储驱动程序文档中的映像和层。
  • 使用手动拉取：连接到 Windows Server 节点，并在创建 Pod 之前在容器映像上手动执行 docker pull 命令。

如需了解更多常规建议，请参阅排查映像拉取问题。

映像系列已达到使用期限

当供应商支持结束时，GKE 会定期弃用较旧的 Windows Server 映像系列。此弃用会阻止创建使用这些映像的节点池。

表现

创建具有 Windows 映像的节点池时，您会收到类似于以下内容的错误：

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

原因

所选 Windows Server 映像系列在 GKE 中不再受支持。

解决方法

选择可用的受支持 Windows 映像。 您可以使用 gcloud container get-server-config 命令查找 GKE Windows 节点映像的支持结束日期，如映射 GKE 和 Windows 版本中所述。

创建节点池期间超时

同时初始化大量 Windows Server 节点可能会导致超时。

表现

节点池创建操作在完成之前超时。

原因

如果您要创建大量节点（例如 500 个），并且这是集群中第一个使用 Windows Server 映像的节点池，则节点池创建可能会超时。

解决方法

创建节点池时减少初始节点数。创建节点池后，您可以增加节点数量。

Windows 节点变为 NotReady，出现错误：PLEG is not healthy

在单个节点上快速调度多个 Windows 容器可能会使 Pod 生命周期事件生成器 (PLEG) 不堪重负。

表现

  • Windows 节点进入 NotReady 状态。
  • 事件或日志显示 PLEG is not healthy 出错提示。

原因

在单个 Windows 节点上以非常快的速度启动多个 Pod 时，会出现已知的 Kubernetes 问题。

解决方法

如需从 PLEG 故障中恢复并防止故障再次发生，请执行以下操作：

  • 重启受影响的 Windows Server 节点。
  • 将 Windows Pod 创建限制为每 30 秒不超过一个 Pod。

不一致TerminationGracePeriod

Windows 容器关停计时器与 Kubernetes 宽限期设置之间的差异可能会导致容器意外终止。

表现

在 TerminationGracePeriodSeconds 字段中配置的时长到期之前，Windows 会强制终止容器。

原因

容器的内部 Windows 系统超时时间与 Kubernetes Pod 清单中指定的宽限期不同。

解决方法

在映像构建时，通过修改容器本地注册表键来修改 Windows 容器超时。相应地调整 Pod 清单中的 TerminationGracePeriodSeconds 字段。

网络连接问题

Windows Server 容器网络与 Google Cloud 网络之间的最大传输单元 (MTU) 大小不匹配可能会导致数据包丢失。

表现

在 Windows Server 容器内运行的应用遇到网络连接失败或丢包问题。

原因

Windows Server 容器网络通常假定网络 MTU 为 1500，而该 MTU 与 Google Cloud的 MTU 1460 不兼容。

解决方法

将容器网络接口 MTU 和 Windows Server 节点网络接口 MTU 值都配置为 1460 或更低。如需了解详情，请参阅 Compute Engine 文档中的 Windows 容器的已知问题。

节点启动问题

新的 Windows Server 实例可能无法完成初始化脚本或向控制平面注册。

表现

Windows Server 节点无法初始化或无法加入集群。

原因

节点初始化期间发生的错误会阻止节点启动或加入集群。

解决方法

如需确定哪些启动错误可能导致了问题，请查看节点的串行端口输出：

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

替换以下内容：

  • NODE_NAME：节点的名称。
  • COMPUTE_ZONE：节点的计算可用区。

在运行 1.24 或更早版本的集群中，Windows 节点间歇性无法访问 Service

在运行 1.24 版或更早版本的集群上，重启 kube-proxy 组件会在重新处理主机网络服务 (HNS) 负载均衡器规则时造成临时网络路由延迟。

表现

在 Windows 节点上运行的 Pod 间歇性无法访问 Service。

原因

对于运行 1.24 版或更早版本的 GKE 集群，如果某个事件重启了 Windows 节点上的 kube-proxy 组件（例如节点启动、节点升级或手动重启），该组件必须同步并重新创建所有 HNS 负载均衡器规则。如果集群包含大量此类规则，则处理这些规则可能会出现明显的延迟，每条规则约延迟 30 秒。在此同步延迟期间，在相应节点上运行的 Pod 无法间歇性地访问服务。如需了解详情，请参阅 GitHub 中的原问题。

解决方法

将集群控制平面升级到 1.25 版或更高版本。此行为在较新版本中得到了显著改进，如 GitHub 中的拉取请求中所详述。

后续步骤