本文发布已超过一年。较旧文章可能包含过时内容。请检查页面中的信息自发布以来是否仍正确。
介绍 Windows 操作就绪规范
自 Windows 支持在 2019 年随 Kubernetes 1.14 升级到稳定版本以来，运行 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 操作就绪规范 的想法应运而生。
我们不能直接运行官方一致性测试吗？
Kubernetes 项目包含一套一致性测试，这些是标准化的测试，旨在确保 Kubernetes 集群满足所需的 Kubernetes 规范。
然而，这些测试最初定义时，Linux 是与 Kubernetes 兼容的唯一操作系统，因此它们不易扩展用于 Windows。鉴于 Windows 工作负载尽管重要，但在 Kubernetes 社区中占比较小，因此重要的是确保许多 Kubernetes 发行版依赖的主要一致性测试套件（用于认证 Linux 一致性）不会因 Windows 特有的功能或增强（如 GMSA 或多操作系统 kube-proxy 行为）而变得复杂。
因此，由于存在 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 操作就绪规范
Windows 操作就绪规范专门针对并以比简单地使用 Ginkgo 标签更用户友好的方式执行 Kubernetes 仓库中的测试。它引入了一个结构化的测试套件，该套件分为核心测试和扩展测试两部分，每部分测试都包含旨在测试特定领域（例如网络）的类别。核心测试针对根据 Kubernetes 规范定义的 Windows 节点应支持的基础和关键功能。另一方面，扩展测试涵盖更复杂的功能，更侧重于深入探究 Windows 特有的能力，例如与 Active Directory 的集成。这些测试的目标是广泛的，涵盖各种 Windows 特有的能力，以确保与各种工作负载和配置兼容，超越基本要求。以下是当前的类别列表。
| 类别名称 | 类别描述 |
|---|---|
核心.网络 | 测试基本的网络功能（通过 Pod IP 访问 Pod 的能力）。 |
核心.存储 | 测试基本的存储功能（挂载 hostPath 存储卷的能力）。 |
核心.调度 | 测试基本的调度功能（调度具有 CPU 限制的 Pod 的能力）。 |
核心.并发 | 测试基本的并发功能（节点同时处理多个 Pod 流量的能力）。 |
扩展.HostProcess | 测试与 Windows HostProcess Pod 功能相关的功能。 |
扩展.ActiveDirectory | 测试与 Active Directory 功能相关的功能。 |
扩展.网络策略 | 测试与网络策略功能相关的功能。 |
扩展.网络 | 测试高级网络功能（支持 IPv6 的能力） |
扩展.Worker | 测试与 Windows worker 节点功能相关的功能（节点访问同一集群中 TCP 和 UDP 服务的能力） |
如何对 Windows 节点执行操作就绪性测试
要运行 Windows 操作就绪测试套件，请参阅测试套件的 README，其中解释了如何进行设置和运行。测试套件提供了灵活的执行方式，可以使用编译后的二进制文件或 Sonobuoy 插件。你还可以选择针对整个测试套件运行测试，或通过指定类别列表运行。云提供商可以选择上传其一致性测试结果，从而增强透明度和可靠性。
检出代码后，即可运行测试。例如，此示例命令运行 Core.Concurrent 类别的测试：
./op-readiness --kubeconfig $KUBE_CONFIG --category Core.Concurrent
作为 Kubernetes 的贡献者，如果你想使用 Windows 操作就绪规范针对特定的 pull request 测试你的更改，请在新 pull request 中使用以下 bot 命令。
/test operational-tests-capz-windows-2019
展望未来
我们正寻求通过向 Kubernetes 仓库添加新测试并识别可以作为目标的现有测试用例来改进我们精选的 Windows 特定测试列表。该规范的长期目标是持续增强对 Windows worker 节点的测试覆盖范围并提高 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.) 提供的指导和支持。