这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
Windows 操作就绪规范简介
自从 2019 年 Kubernetes 1.14 将对 Windows 的支持升级为稳定版以来， 能够运行 Windows 工作负载的能力一直深受最终用户社区的认可。对于大型企业来说， 对 Windows 工作负载支持的水平和可用性一直是各大企业选择 Kubernetes 发行版的重要差异化因素。 然而，随着越来越多的 Windows 工作负载迁移到 Kubernetes，以及新的 Windows 特性不断发布， 要高效且标准化地测试 Windows 工作节点变得越来越具有挑战性。
对于那些无意提供 Windows 支持的、经过认证的发行版或服务， Kubernetes 项目非常重视它们无需闭源许可证即可通过一致性认证的能力。
一些引起 SIG Windows 注意的典型示例包括：
- 负载均衡器源地址范围功能在 Windows 节点上无法正常运行的问题，详情见 GitHub 讨论： kubernetes/kubernetes#120033。
- 有关 Windows 功能异常的报告，例如 “GMSA 无法与 containerd 协同工作”，相关讨论见 microsoft/Windows-Containers#44。
- 在开发网络策略测试时遇到的挑战，这类测试需要能够在不同操作系统配置下客观评估容器网络接口 （CNI）插件，相关讨论见kubernetes/kubernetes#97751。
因此，SIG Windows 认识到需要一个定制化的解决方案，以确保 Windows 节点在进入生产环境之前 就达到操作就绪状态。 于是， Windows 操作就绪规范的想法就此产生。
我们不能直接运行官方的一致性测试吗？
Kubernetes 项目中提供了一套一致性测试， 这是一套标准化测试，旨在确保 Kubernetes 集群满足规定的 Kubernetes 规范。
然而，这些测试最初设计时，Linux 是 唯一 与 Kubernetes 兼容的操作系统， 因此很难直接扩展应用于 Windows。虽然 Windows 工作负载十分重要， 但它在 Kubernetes 社区中只占较小的份额。因此必须确保主要的一致性测试套件 不会因为 Windows 特定功能或增强（例如 GMSA 或跨操作系统的 kube-proxy 行为）而变得负担过重， 许多 Kubernetes 发行版依赖它来认证 Linux 的一致性。
因此，由于对 Windows 一致性测试有特殊需求，SIG Windows 走上了通过 Windows 操作就绪规范提供 特定于 Windows 的一致性测试的路线。
难道我们不能只运行 Kubernetes 的端到端测试套件吗？
在 Linux 生态中，Sonobuoy 这样的工具简化了一致性测试套件的执行， 使用户无需了解 Kubernetes 的编译路径或 Ginkgo 标签的语义。
在需要编译 Kubernetes 测试这件事上，我们意识到 Windows 用户同样会觉得从零开始编译并运行 Kubernetes e2e 套件同样不受欢迎，因此很明显需要一个用户友好的、“一键式”的开箱即用解决方案。 另外，在 Ginkgo 标签方面，把一致性测试通过一组 Ginkgo 标签应用到 Windows 节点，对所有用户来说都很繁琐，不管是Linux 爱好者还是经验丰富的 Windows 系统管理员。
为了填补这个空白，为用户提供一种直接的方法来确认他们的集群是否支持多种功能， Kubernetes 社区的 Windows SIG 认为有必要开发 Windows 操作就绪应用。 这个应用由 Go 语言编写，可以简化运行特定于 Windows 的必要测试，并以清晰、易于获取的格式提供结果。
这项工作是多方协作的成果，亚马逊 (Amazon)、微软 (Microsoft)、SUSE 和 Broadcom 等多家云服务商和平台都为此做出了贡献。
更深入地了解 Windows 操作就绪规范
相对于以往单纯通过 Ginkgo 标签的方式， Windows 操作就绪规范专门用于执行 Kubernetes 仓库中的测试，这种新方法更为用户友好。 它引入了一个结构化的测试套件，分为核心测试和扩展测试，每组测试又包含针对特定领域的类别， 例如网络。核心测试聚焦于 Kubernetes 规范定义的 Windows 节点应支持的基本和关键功能。 而扩展测试则覆盖更复杂的功能，更侧重于深入考察 Windows 特有的功能，例如与 Active Directory 的集成。 这些测试的目标是确保全面覆盖，涵盖广泛的 Windows 特有的功能，以确保与各种工作负载和配置兼容， 其范围也超出了基本要求。下面是当前的类别列表。
| 类别名字 | 类别描述 |
|---|---|
Core.Network |
测试最小网络功能（访问各个 Pod 的 IP 地址）。 |
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 操作就绪测试套件，可以查看它的
README，
其中解释了如何安装和运行它。这个测试套件提供了灵活的执行方式，你可以使用编译好的二进制文件或
Sonobuoy 插件来运行。你还可以选择运行整个测试套件，或者只运行指定类别的测试。
云服务商也可以选择上传他们的一致性测试结果，从而提升透明度和可靠性。
一旦你检出代码，就可以运行测试。例如，这个示例命令运行来自 Core.Concurrent 类别的测试：
./op-readiness --kubeconfig $KUBE_CONFIG --category Core.Concurrent
作为 Kubernetes 的贡献者，如果你想使用 Windows 操作就绪规范来针对某个特定 Pull Request 测试你的更改，请在新的 Pull Request 中使用以下机器人命令。
/test operational-tests-capz-windows-2019
展望未来
我们希望通过在 Kubernetes 仓库中添加新的测试，以及识别可被纳入的现有测试用例， 来改进我们整理的 Windows 特定测试列表。这个规范的长期目标是持续扩大对 Windows 工作节点的测试覆盖范围，并提升 Windows 支持的稳健性，从而在不同云环境中带来无缝的体验。 我们还计划把 Windows 操作就绪测试集成到官方的 Kubernetes 一致性测试套件里。
如果你有兴趣帮助我们，欢迎与我们联系！我们欢迎任何形式的帮助， 不管是一次性的反馈、提交代码，还是成为长期负责人来帮助我们推动变更。 Windows 操作就绪规范由 SIG Windows 团队负责。 你可以在 Kubernetes Slack 工作区 的 #sig-windows 频道联系团队。你也可以查看 Windows 操作就绪测试套件， 直接在 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.），感谢他们的指导和支持。