Skip to content

Commit 2a631e0

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #51957 from qlijin/sync-file-2025-08-18
[zh-cn] sync blog file 2024-04-03-windows-ops-readiness.md
2 parents 06ce4cb + 8fa84a9 commit 2a631e0

File tree

1 file changed

+302
-0
lines changed

1 file changed

+302
-0
lines changed

‎content/zh-cn/blog/_posts/2024-04-03-windows-ops-readiness.md‎

Lines changed: 302 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,302 @@
1+
---
2+
layout: blog
3+
title: "Windows 操作就绪规范简介"
4+
date: 2024-04-03
5+
slug: intro-windows-ops-readiness
6+
author: >
7+
Jay Vyas (Tesla),
8+
Amim Knabben (Broadcom),
9+
Tatenda Zifudzi (AWS)
10+
translator: >
11+
[Jin Li](https://github.com/qlijin) (UOS)
12+
---
13+
<!--
14+
layout: blog
15+
title: "Introducing the Windows Operational Readiness Specification"
16+
date: 2024-04-03
17+
slug: intro-windows-ops-readiness
18+
author: >
19+
Jay Vyas (Tesla),
20+
Amim Knabben (Broadcom),
21+
Tatenda Zifudzi (AWS)
22+
-->
23+
24+
<!--
25+
Since Windows support [graduated to stable](/blog/2019/03/25/kubernetes-1-14-release-announcement/)
26+
with Kubernetes 1.14 in 2019, the capability to run Windows workloads has been much
27+
appreciated by the end user community. The level of and availability of Windows workload
28+
support has consistently been a major differentiator for Kubernetes distributions used by
29+
large enterprises. However, with more Windows workloads being migrated to Kubernetes
30+
and new Windows features being continuously released, it became challenging to test
31+
Windows worker nodes in an effective and standardized way.
32+
-->
33+
自从 2019 年 Kubernetes 1.14 将对 Windows
34+
的支持[升级为稳定版](/zh-cn/blog/2019/03/25/kubernetes-1-14-release-announcement/)以来，
35+
能够运行 Windows 工作负载的能力一直深受最终用户社区的认可。对于大型企业来说，
36+
对 Windows 工作负载支持的水平和可用性一直是各大企业选择 Kubernetes 发行版的重要差异化因素。
37+
然而，随着越来越多的 Windows 工作负载迁移到 Kubernetes，以及新的 Windows 特性不断发布，
38+
要高效且标准化地测试 Windows 工作节点变得越来越具有挑战性。
39+
40+
<!--
41+
The Kubernetes project values the ability to certify conformance without requiring a
42+
closed-source license for a certified distribution or service that has no intention
43+
of offering Windows.
44+
45+
Some notable examples brought to the attention of SIG Windows were:
46+
-->
47+
对于那些无意提供 Windows 支持的、经过认证的发行版或服务，
48+
Kubernetes 项目非常重视它们无需闭源许可证即可通过一致性认证的能力。
49+
50+
一些引起 SIG Windows 注意的典型示例包括：
51+
52+
<!--
53+
- An issue with load balancer source address ranges functionality not operating correctly on
54+
Windows nodes, detailed in a GitHub issue:
55+
[kubernetes/kubernetes#120033](https://github.com/kubernetes/kubernetes/issues/120033).
56+
- Reports of functionality issues with Windows features, such as
57+
“[GMSA](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) not working with containerd,
58+
discussed in [microsoft/Windows-Containers#44](https://github.com/microsoft/Windows-Containers/issues/44).
59+
- Challenges developing networking policy tests that could objectively evaluate
60+
Container Network Interface (CNI) plugins across different operating system configurations,
61+
as discussed in [kubernetes/kubernetes#97751](https://github.com/kubernetes/kubernetes/issues/97751).
62+
-->
63+
- 负载均衡器源地址范围功能在 Windows 节点上无法正常运行的问题，详情见 GitHub 讨论：
64+
[kubernetes/kubernetes#120033](https://github.com/kubernetes/kubernetes/issues/120033)。
65+
- 有关 Windows 功能异常的报告，例如
66+
“[GMSA](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)
67+
无法与 containerd 协同工作”，相关讨论见
68+
[microsoft/Windows-Containers#44](https://github.com/microsoft/Windows-Containers/issues/44)。
69+
- 在开发网络策略测试时遇到的挑战，这类测试需要能够在不同操作系统配置下客观评估容器网络接口
70+
（CNI）插件，相关讨论见[kubernetes/kubernetes#97751](https://github.com/kubernetes/kubernetes/issues/97751)。
71+
72+
<!--
73+
SIG Windows therefore recognized the need for a tailored solution to ensure Windows
74+
nodes' operational readiness *before* their deployment into production environments.
75+
Thus, the idea to develop a [Windows Operational Readiness Specification](https://kep.k8s.io/2578)
76+
was born.
77+
-->
78+
因此，SIG Windows 认识到需要一个定制化的解决方案，以确保 Windows
79+
节点在进入生产环境**之前** 就达到操作就绪状态。 于是，
80+
[Windows 操作就绪规范](https://kep.k8s.io/2578)的想法就此产生。
81+
82+
<!--
83+
## Can’t we just run the official Conformance tests?
84+
85+
The Kubernetes project contains a set of [conformance tests](https://www.cncf.io/training/certification/software-conformance/#how),
86+
which are standardized tests designed to ensure that a Kubernetes cluster meets
87+
the required Kubernetes specifications.
88+
-->
89+
## 我们不能直接运行官方的一致性测试吗？ {#cant-we-just-run-the-official-conformance-tests}
90+
91+
Kubernetes 项目中提供了一套[一致性测试](https://www.cncf.io/training/certification/software-conformance/#how)，
92+
这是一套标准化测试，旨在确保 Kubernetes 集群满足规定的 Kubernetes 规范。
93+
94+
<!--
95+
However, these tests were originally defined at a time when Linux was the *only*
96+
operating system compatible with Kubernetes, and thus, they were not easily
97+
extendable for use with Windows. Given that Windows workloads, despite their
98+
importance, account for a smaller portion of the Kubernetes community, it was
99+
important to ensure that the primary conformance suite relied upon by many
100+
Kubernetes distributions to certify Linux conformance, didn't become encumbered
101+
with Windows specific features or enhancements such as GMSA or multi-operating
102+
system kube-proxy behavior.
103+
-->
104+
然而，这些测试最初设计时，Linux 是 **唯一** 与 Kubernetes 兼容的操作系统，
105+
因此很难直接扩展应用于 Windows。虽然 Windows 工作负载十分重要，
106+
但它在 Kubernetes 社区中只占较小的份额。因此必须确保主要的一致性测试套件
107+
不会因为 Windows 特定功能或增强（例如 GMSA 或跨操作系统的 kube-proxy 行为）而变得负担过重，
108+
许多 Kubernetes 发行版依赖它来认证 Linux 的一致性。
109+
110+
<!--
111+
Therefore, since there was a specialized need for Windows conformance testing,
112+
SIG Windows went down the path of offering Windows specific conformance tests
113+
through the Windows Operational Readiness Specification.
114+
115+
## Can’t we just run the Kubernetes end-to-end test suite?
116+
-->
117+
因此，由于对 Windows 一致性测试有特殊需求，SIG Windows 走上了通过 Windows 操作就绪规范提供
118+
特定于 Windows 的一致性测试的路线。
119+
120+
## 难道我们不能只运行 Kubernetes 的端到端测试套件吗？ {#cant-we-just-run-the-kubernetes-end-to-end-test-suite}
121+
122+
<!--
123+
In the Linux world, tools such as [Sonobuoy](https://sonobuoy.io/) simplify execution of the
124+
conformance suite, relieving users from needing to be aware of Kubernetes'
125+
compilation paths or the semantics of [Ginkgo](https://onsi.github.io/ginkgo) tags.
126+
-->
127+
在 Linux 生态中，[Sonobuoy](https://sonobuoy.io/) 这样的工具简化了一致性测试套件的执行，
128+
使用户无需了解 Kubernetes 的编译路径或 [Ginkgo](https://onsi.github.io/ginkgo) 标签的语义。
129+
130+
<!--
131+
Regarding needing to compile the Kubernetes tests, we realized that Windows
132+
users might similarly find the process of compiling and running the Kubernetes
133+
e2e suite from scratch similarly undesirable, hence, there was a clear need to
134+
provide a user-friendly, "push-button" solution that is ready to go. Moreover,
135+
regarding Ginkgo tags, applying conformance tests to Windows nodes through a set
136+
of [Ginkgo](https://onsi.github.io/ginkgo/) tags would also be burdensome for
137+
any user, including Linux enthusiasts or experienced Windows system admins alike.
138+
-->
139+
在需要编译 Kubernetes 测试这件事上，我们意识到 Windows 用户同样会觉得从零开始编译并运行
140+
Kubernetes e2e 套件同样不受欢迎，因此很明显需要一个用户友好的、“一键式”的开箱即用解决方案。
141+
另外，在 Ginkgo 标签方面，把一致性测试通过一组 [Ginkgo](https://onsi.github.io/ginkgo/)
142+
标签应用到 Windows 节点，对所有用户来说都很繁琐，不管是Linux 爱好者还是经验丰富的
143+
Windows 系统管理员。
144+
145+
<!--
146+
To bridge the gap and give users a straightforward way to confirm their clusters
147+
support a variety of features, the Kubernetes SIG for Windows found it necessary to
148+
therefore create the Windows Operational Readiness application. This application
149+
written in Go, simplifies the process to run the necessary Windows specific tests
150+
while delivering results in a clear, accessible format.
151+
-->
152+
为了填补这个空白，为用户提供一种直接的方法来确认他们的集群是否支持多种功能，
153+
Kubernetes 社区的 Windows SIG 认为有必要开发 Windows 操作就绪应用。
154+
这个应用由 Go 语言编写，可以简化运行特定于 Windows 的必要测试，并以清晰、易于获取的格式提供结果。
155+
156+
<!--
157+
This initiative has been a collaborative effort, with contributions from different
158+
cloud providers and platforms, including Amazon, Microsoft, SUSE, and Broadcom.
159+
160+
## A closer look at the Windows Operational Readiness Specification {#specification}
161+
-->
162+
这项工作是多方协作的成果，亚马逊 (Amazon)、微软 (Microsoft)、SUSE 和 Broadcom
163+
等多家云服务商和平台都为此做出了贡献。
164+
165+
## 更深入地了解 Windows 操作就绪规范 {#specification}
166+
167+
<!--
168+
The Windows Operational Readiness specification specifically targets and executes
169+
tests found within the Kubernetes repository in a more user-friendly way than
170+
simply targeting [Ginkgo](https://onsi.github.io/ginkgo/) tags. It introduces a
171+
structured test suite that is split into sets of core and extended tests, with
172+
each set of tests containing categories directed at testing a specific area of
173+
testing, such as networking. Core tests target fundamental and critical
174+
functionalities that Windows nodes should support as defined by the Kubernetes
175+
specification. On the other hand, extended tests cover more complex features,
176+
more aligned with diving deeper into Windows-specific capabilities such as
177+
integrations with Active Directory. These goal of these tests is to be extensive,
178+
covering a wide array of Windows-specific capabilities to ensure compatibility
179+
with a diverse set of workloads and configurations, extending beyond basic
180+
requirements. Below is the current list of categories.
181+
-->
182+
相对于以往单纯通过 [Ginkgo](https://onsi.github.io/ginkgo) 标签的方式，
183+
Windows 操作就绪规范专门用于执行 Kubernetes 仓库中的测试，这种新方法更为用户友好。
184+
它引入了一个结构化的测试套件，分为核心测试和扩展测试，每组测试又包含针对特定领域的类别，
185+
例如网络。核心测试聚焦于 Kubernetes 规范定义的 Windows 节点应支持的基本和关键功能。
186+
而扩展测试则覆盖更复杂的功能，更侧重于深入考察 Windows 特有的功能，例如与 Active Directory 的集成。
187+
这些测试的目标是确保全面覆盖，涵盖广泛的 Windows 特有的功能，以确保与各种工作负载和配置兼容，
188+
其范围也超出了基本要求。下面是当前的类别列表。
189+
190+
<!--
191+
| Category Name | Category Description |
192+
|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------|
193+
| `Core.Network` | Tests minimal networking functionality (ability to access pod-by-pod IP.) |
194+
| `Core.Storage` | Tests minimal storage functionality, (ability to mount a hostPath storage volume.) |
195+
| `Core.Scheduling` | Tests minimal scheduling functionality, (ability to schedule a pod with CPU limits.) |
196+
| `Core.Concurrent` | Tests minimal concurrent functionality, (the ability of a node to handle traffic to multiple pods concurrently.) |
197+
| `Extend.HostProcess` | Tests features related to Windows HostProcess pod functionality. |
198+
| `Extend.ActiveDirectory` | Tests features related to Active Directory functionality. |
199+
| `Extend.NetworkPolicy` | Tests features related to Network Policy functionality. |
200+
| `Extend.Network` | Tests advanced networking functionality, (ability to support IPv6) |
201+
| `Extend.Worker` | Tests features related to Windows worker node functionality, (ability for nodes to access TCP and UDP services in the same cluster) |
202+
-->
203+
| 类别名字 | 类别描述 |
204+
|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------|
205+
| `Core.Network` | 测试最小网络功能（访问各个 Pod 的 IP 地址）。 |
206+
| `Core.Storage` | 测试最小存储功能（能够挂载 hostPath 存储卷）。 |
207+
| `Core.Scheduling` | 测试最小调度功能（能够调度带有 CPU 限制的 Pod）。 |
208+
| `Core.Concurrent` | 测试最小并发功能（节点能够并发处理多个 Pod 的流量）。 |
209+
| `Extend.HostProcess` | 测试与 Windows `HostProcess` Pod 功能相关的特性。 |
210+
| `Extend.ActiveDirectory` | 测试与 Active Directory 功能相关的特性。 |
211+
| `Extend.NetworkPolicy` | 测试与网络策略功能相关的功能。 |
212+
| `Extend.Network` | 测试高级网络功能（支持 IPv6）。 |
213+
| `Extend.Worker` | 测试与 Windows 工作节点功能相关的功能（节点能够访问同一集群中的 TCP 和 UDP 服务）。 |
214+
215+
216+
<!--
217+
## How to conduct operational readiness tests for Windows nodes
218+
219+
To run the Windows Operational Readiness test suite, refer to the test suite's
220+
[`README`](https://github.com/kubernetes-sigs/windows-operational-readiness/blob/main/README.md), which explains how to set it up and run it. The test suite offers
221+
flexibility in how you can execute tests, either using a compiled binary or a
222+
Sonobuoy plugin. You also have the choice to run the tests against the entire
223+
test suite or by specifying a list of categories. Cloud providers have the
224+
choice of uploading their conformance results, enhancing transparency and reliability.
225+
-->
226+
## 如何对 Windows 节点做操作就绪测试 {#how-to-conduct-operational-readiness-tests-for-windows-nodes}
227+
228+
要运行 Windows 操作就绪测试套件，可以查看它的
229+
[`README`](https://github.com/kubernetes-sigs/windows-operational-readiness/blob/main/README.md)，
230+
其中解释了如何安装和运行它。这个测试套件提供了灵活的执行方式，你可以使用编译好的二进制文件或
231+
Sonobuoy 插件来运行。你还可以选择运行整个测试套件，或者只运行指定类别的测试。
232+
云服务商也可以选择上传他们的一致性测试结果，从而提升透明度和可靠性。
233+
234+
<!--
235+
Once you have checked out that code, you can run a test. For example, this sample
236+
command runs the tests from the `Core.Concurrent` category:
237+
-->
238+
一旦你检出代码，就可以运行测试。例如，这个示例命令运行来自 `Core.Concurrent` 类别的测试：
239+
240+
```shell
241+
./op-readiness --kubeconfig $KUBE_CONFIG --category Core.Concurrent
242+
```
243+
244+
<!--
245+
As a contributor to Kubernetes, if you want to test your changes against a specific pull
246+
request using the Windows Operational Readiness Specification, use the following bot
247+
command in the new pull request.
248+
-->
249+
作为 Kubernetes 的贡献者，如果你想使用 Windows 操作就绪规范来针对某个特定
250+
Pull Request 测试你的更改，请在新的 Pull Request 中使用以下机器人命令。
251+
252+
253+
```shell
254+
/test operational-tests-capz-windows-2019
255+
```
256+
257+
<!--
258+
## Looking ahead
259+
260+
We’re looking to improve our curated list of Windows-specific tests by adding
261+
new tests to the Kubernetes repository and also identifying existing test cases
262+
that can be targetted. The long term goal for the specification is to continually
263+
enhance test coverage for Windows worker nodes and improve the robustness of
264+
Windows support, facilitating a seamless experience across diverse cloud
265+
environments. We also have plans to integrate the Windows Operational Readiness
266+
tests into the official Kubernetes conformance suite.
267+
-->
268+
## 展望未来 {#looking-ahead}
269+
270+
我们希望通过在 Kubernetes 仓库中添加新的测试，以及识别可被纳入的现有测试用例，
271+
来改进我们整理的 Windows 特定测试列表。这个规范的长期目标是持续扩大对
272+
Windows 工作节点的测试覆盖范围，并提升 Windows 支持的稳健性，从而在不同云环境中带来无缝的体验。
273+
我们还计划把 Windows 操作就绪测试集成到官方的 Kubernetes 一致性测试套件里。
274+
275+
<!--
276+
If you are interested in helping us out, please reach out to us! We welcome help
277+
in any form, from giving once-off feedback to making a code contribution,
278+
to having long-term owners to help us drive changes. The Windows Operational
279+
Readiness specification is owned by the SIG Windows team. You can reach out
280+
to the team on the [Kubernetes Slack workspace](https://slack.k8s.io/) **#sig-windows**
281+
channel. You can also explore the [Windows Operational Readiness test suite](https://github.com/kubernetes-sigs/windows-operational-readiness/#readme)
282+
and make contributions directly to the GitHub repository.
283+
-->
284+
如果你有兴趣帮助我们，欢迎与我们联系！我们欢迎任何形式的帮助，
285+
不管是一次性的反馈、提交代码，还是成为长期负责人来帮助我们推动变更。
286+
Windows 操作就绪规范由 SIG Windows 团队负责。
287+
你可以在 [Kubernetes Slack 工作区](https://slack.k8s.io/) 的
288+
**#sig-windows** 频道联系团队。你也可以查看
289+
[Windows 操作就绪测试套件](https://github.com/kubernetes-sigs/windows-operational-readiness/#readme)，
290+
直接在 GitHub 仓库中参与贡献。
291+
292+
<!--
293+
Special thanks to Kulwant Singh (AWS), Pramita Gautam Rana (VMWare), Xinqi Li
294+
(Google) and Marcio Morales (AWS) for their help in making notable contributions to the specification. Additionally,
295+
appreciation goes to James Sturtevant (Microsoft), Mark Rossetti (Microsoft),
296+
Claudiu Belu (Cloudbase Solutions) and Aravindh Puthiyaparambil
297+
(Softdrive Technologies Group Inc.) from the SIG Windows team for their guidance and support.
298+
-->
299+
特别感谢 Kulwant Singh（AWS）、Pramita Gautam Rana（VMWare）、Xinqi Li（Google）和 Marcio Morales（AWS），
300+
感谢他们为本规范做出的重要贡献。同时，也要感谢 SIG Windows 团队的 James Sturtevant（Microsoft）、
301+
Mark Rossetti（Microsoft）、Claudiu Belu（Cloudbase Solutions）和
302+
Aravindh Puthiyaparambil（Softdrive Technologies Group Inc.），感谢他们的指导和支持。

0 commit comments

Comments
 (0)