排查 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 容器兼容性，请参阅 Microsoft 关于 2020 年 2 月 Windows Server 容器不兼容问题的文档。

映像拉取错误

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

表现

  • 错误消息，例如 Failed to pull image 或 context cancelled。
  • Pod 显示 ErrImagePull 状态。

原因

Windows Server 容器映像及其所含的各个层可能非常大。它们的大小可能会导致 kubelet 代理在下载和提取容器层时发生超时和失败。

解决方法

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

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

原因

这是一个已知的 Kubernetes 问题，在单个 Windows 节点上以非常快的速度启动 多个 Pod 时，就会发生此问题。

解决方法

如需从 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 间歇性无法访问 Service。如需了解详情，请参阅 GitHub 中的 原问题。

解决方法

将集群控制平面升级到 1.25 或更高版本。新版本中此行为已得到 大幅改进，如 GitHub 中的拉取请求中所述。

后续步骤