本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
介绍 Windows 操作就绪性规范
自 2019 年 Kubernetes 1.14 将 Windows 支持升级为稳定版以来，运行 Windows 工作负载的能力备受最终用户社区的赞赏。Windows 工作负载支持的水平和可用性一直是大型企业使用的 Kubernetes 发行版的一个主要差异化因素。然而，随着越来越多的 Windows 工作负载被迁移到 Kubernetes，以及新的 Windows 功能不断发布，以有效和标准化的方式测试 Windows 工作节点变得具有挑战性。
Kubernetes 项目重视在不要求认证的发行版或服务使用闭源许可证的情况下进行一致性认证的能力，该发行版或服务无意提供 Windows 支持。
SIG Windows 注意到的一些显著示例包括：
- 负载均衡器源地址范围功能在 Windows 节点上无法正常运行的问题，详见 GitHub issue：kubernetes/kubernetes#120033。
- Windows 功能出现问题的报告，例如 “GMSA 无法与 containerd 配合使用”，相关讨论见 microsoft/Windows-Containers#44。
- 在开发能够客观评估不同操作系统配置下容器网络接口（CNI）插件的网络策略测试时面临的挑战，相关讨论见 kubernetes/kubernetes#97751。
因此，SIG Windows 认识到需要一个量身定制的解决方案，以确保 Windows 节点在部署到生产环境*之前*的运维就绪性。于是，开发 Windows Operational Readiness Specification（Windows 运维就绪性规范）的想法应运而生。
我们不能直接运行官方的一致性测试吗？
Kubernetes 项目包含一组一致性测试，这些是旨在确保 Kubernetes 集群满足所需 Kubernetes 规范的标准化测试。
然而，这些测试最初定义时，Linux 是与 Kubernetes 兼容的*唯一*操作系统，因此它们不容易扩展到与 Windows 一起使用。鉴于 Windows 工作负载尽管很重要，但在 Kubernetes 社区中只占一小部分，因此确保许多 Kubernetes 发行版用来认证 Linux 一致性的主要一致性套件，不会被 GMSA 或多操作系统 kube-proxy 行为等 Windows 特定功能或增强功能所拖累，这一点非常重要。
因此，由于对 Windows 一致性测试有特殊需求，SIG Windows 决定通过 Windows Operational Readiness Specification 提供 Windows 特定的一致性测试。
我们不能直接运行 Kubernetes 端到端测试套件吗？
在 Linux 世界中，像 Sonobuoy 这样的工具简化了一致性套件的执行，使用户无需了解 Kubernetes 的编译路径或 Ginkgo 标签的语义。
关于需要编译 Kubernetes 测试的问题，我们意识到 Windows 用户可能同样会觉得从头开始编译和运行 Kubernetes e2e 套件的过程不便，因此，明确需要提供一个用户友好、“一键式”的即用型解决方案。此外，关于 Ginkgo 标签，通过一组 Ginkgo 标签将一致性测试应用于 Windows 节点，对任何用户，包括 Linux 爱好者或经验丰富的 Windows 系统管理员来说，都会是一种负担。
为了弥补这一差距，并为用户提供一种直接的方式来确认他们的集群支持各种功能，Kubernetes SIG Windows 发现有必要创建 Windows Operational Readiness 应用程序。这个用 Go 语言编写的应用程序，简化了运行必要的 Windows 特定测试的过程，同时以清晰、易于理解的格式提供结果。
这项计划是一项协作努力，得到了不同云提供商和平台的贡献，包括 Amazon、Microsoft、SUSE 和 Broadcom。
深入了解 Windows Operational Readiness Specification
Windows Operational Readiness Specification 专门针对并执行 Kubernetes 仓库中的测试，其方式比简单地针对 Ginkgo 标签更用户友好。它引入了一个结构化的测试套件，分为核心测试和扩展测试两组，每组测试都包含针对特定测试领域（如网络）的类别。核心测试针对 Windows 节点应支持的基本和关键功能，这些功能由 Kubernetes 规范定义。另一方面，扩展测试涵盖更复杂的功能，更侧重于深入探讨 Windows 特定的能力，例如与 Active Directory 的集成。这些测试的目标是全面覆盖广泛的 Windows 特定能力，以确保与各种工作负载和配置的兼容性，超越基本要求。以下是当前的类别列表。
| 类别名称 | 类别描述 |
|---|---|
Core.Network | 测试最基本的网络功能（能够通过 Pod IP 访问 Pod）。 |
Core.Storage | 测试最基本的存储功能（能够挂载 hostPath 存储卷）。 |
Core.Scheduling | 测试最基本的调度功能（能够调度一个带有 CPU 限制的 Pod）。 |
Core.Concurrent | 测试最基本的并发功能（节点能够同时处理到多个 Pod 的流量）。 |
Extend.HostProcess | 测试与 Windows HostProcess Pod 功能相关的特性。 |
Extend.ActiveDirectory | 测试与 Active Directory 功能相关的特性。 |
Extend.NetworkPolicy | 测试与网络策略功能相关的特性。 |
Extend.Network | 测试高级网络功能（支持 IPv6 的能力）。 |
Extend.Worker | 测试与 Windows 工作节点功能相关的特性（节点能够访问同一集群中的 TCP 和 UDP 服务）。 |
如何为 Windows 节点进行运维就绪性测试
要运行 Windows Operational Readiness 测试套件，请参阅该测试套件的 README，其中解释了如何设置和运行它。该测试套件在执行测试方面提供了灵活性，您可以使用已编译的二进制文件或 Sonobuoy 插件。您还可以选择针对整个测试套件运行测试，或通过指定类别列表来运行。云提供商可以选择上传其一致性结果，以增强透明度和可靠性。
检出该代码后，您就可以运行测试。例如，以下示例命令运行来自 Core.Concurrent 类的测试。
./op-readiness --kubeconfig $KUBE_CONFIG --category Core.Concurrent
作为 Kubernetes 的贡献者，如果您想使用 Windows Operational Readiness Specification 针对特定的拉取请求测试您的更改，请在新的拉取请求中使用以下机器人命令。
/test operational-tests-capz-windows-2019
展望未来
我们希望通过向 Kubernetes 仓库添加新测试并识别可以作为目标测试用例的现有测试，来改进我们精选的 Windows 特定测试列表。该规范的长期目标是不断增强 Windows 工作节点的测试覆盖范围，并提高 Windows 支持的稳健性，从而促进在不同云环境中的无缝体验。我们还计划将 Windows Operational Readiness 测试集成到官方的 Kubernetes 一致性套件中。
如果您有兴趣帮助我们，请联系我们！我们欢迎任何形式的帮助，从一次性反馈到代码贡献，再到长期所有者帮助我们推动变革。Windows Operational Readiness Specification 由 SIG Windows 团队负责。您可以在 Kubernetes Slack 工作区的 #sig-windows 频道上与该团队联系。您也可以浏览 Windows Operational Readiness 测试套件，并直接向 GitHub 仓库做出贡献。
特别感谢 Kulwant Singh (AWS)、Pramita Gautam Rana (VMWare)、Xinqi Li (Google) 和 Marcio Morales (AWS) 为该规范做出的卓越贡献。此外，还要感谢 SIG Windows 团队的 James Sturtevant (Microsoft)、Mark Rossetti (Microsoft)、Claudiu Belu (Cloudbase Solutions) 和 Aravindh Puthiyaparambil (Softdrive Technologies Group Inc.) 的指导和支持。