Windows 操作就绪规范介绍
自从 Windows 支持在 2019 年 Kubernetes 1.14 中升级为稳定版以来，运行 Windows 工作负载的功能受到了最终用户社区的高度赞赏。Windows 工作负载支持的水平和可用性一直是大型企业使用的 Kubernetes 发行版的主要区别因素。然而，随着越来越多的 Windows 工作负载迁移到 Kubernetes，以及不断发布新的 Windows 功能，以有效且标准化的方式测试 Windows 工作节点变得具有挑战性。
Kubernetes 项目重视在不要求不打算提供 Windows 的认证发行版或服务的闭源许可证的情况下进行一致性认证的能力。
一些引起 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 社区中所占比例较小，因此重要的是要确保许多 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 SIG for Windows 认为有必要创建 Windows 运营准备应用程序。这个用 Go 编写的应用程序简化了运行必要的 Windows 特定测试的过程，同时以清晰、可访问的格式提供结果。
这项计划是一项协作努力，来自不同的云提供商和平台，包括亚马逊、微软、SUSE 和博通。
更详细地了解 Windows 运营准备规范
Windows 运营准备规范专门针对并执行 Kubernetes 存储库中的测试，其方式比仅仅针对 Ginkgo 标签更加用户友好。它引入了一个结构化的测试套件，该套件分为核心测试和扩展测试集，每组测试都包含针对测试特定领域的类别，例如网络。核心测试针对 Windows 节点应支持的基本和关键功能，如 Kubernetes 规范所定义。另一方面，扩展测试涵盖更复杂的功能，更侧重于深入了解 Windows 特有的功能，例如与 Active Directory 的集成。这些测试的目标是广泛的，涵盖各种 Windows 特有的功能，以确保与各种工作负载和配置的兼容性，超出基本要求。以下是当前的类别列表。
| 类别名称 | 类别描述 |
|---|---|
Core.Network | 测试最小网络功能（访问 pod 到 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 运营准备规范针对特定拉取请求测试您的更改，请在新拉取请求中使用以下机器人命令。
/test operational-tests-capz-windows-2019
展望未来
我们希望通过在 Kubernetes 存储库中添加新测试，并确定可以针对的现有测试用例，来改进我们精选的 Windows 特定测试列表。该规范的长期目标是不断增强 Windows 工作节点的测试覆盖率，并提高 Windows 支持的稳健性，从而促进跨各种云环境的无缝体验。我们还计划将 Windows 运营准备测试集成到官方 Kubernetes 一致性套件中。
如果您有兴趣帮助我们，请联系我们！我们欢迎任何形式的帮助，从提供一次性反馈到贡献代码，再到拥有长期维护者来帮助我们推动变更。Windows Operational Readiness 规范由 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.) 提供的指导和支持。