Kubernetes SIG Windows 2021 年度技术盘点：HostProcess 容器、Windows CSI 与运维就绪之路
【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community
导读
本文以 sig-windows/annual-report-2021.md 年度报告为核心，系统梳理 SIG Windows 在 2021 年（Kubernetes v1.22/v1.23 周期）交付的关键技术成果：HostProcess 容器支持进入 Beta、Windows CSI 支持走向 Stable、kubectl node logs命令接口定义、Windows 节点运维就绪标准等。读完本文，你将完整掌握 SIG Windows 当年的 KEP 演进脉络、子项目生态布局、社区健康指标，以及普通贡献者可以切入的具体参与方向，并能结合 sig-windows/CONTRIBUTING.md 与 sig-windows/README.md 快速上手 Windows 节点相关的开发与测试工作。
年度核心成果：五大高光技术项
按照 charter.md 的定义，SIG Windows 的职责范围是"Kubernetes 在 Windows 操作系统上的运行"，包括维护 Kubernetes 与 Windows 容器之间的接口，以及 kube-proxy 等存在 Windows 专属实现的组件。2021 年度报告列出的五项重点工作正是这一范围的具体落地：
- HostProcess 容器支持进入 Beta 并跨社区推广：这是当年最受关注的能力。HostProcess 容器允许 Windows 容器以主机进程形态运行，从而可以在 Windows 节点上部署 flannel、calico、csi-proxy、kube-proxy 等基础设施组件。报告明确给出了 sig-windows-tools 项目中 hostprocess 目录下的部署示例，并提到 KuReD（Windows 节点重启守护）与 prometheus-community/windows_exporter（Node Exporter 的 Windows 版）均已通过 HostProcess 容器形态获得支持。
- 定义
kubectl node logs命令接口：为后续 Windows 节点日志查询能力（即 2023 年 v1.27 的 Node log query 特性，见 sig-windows/annual-report-2023.md）奠定接口基础。 - 以 sig-windows-dev-tools 打通透明的开发者体验：该工具链致力于让"在本地构建一个带 Windows 节点的 Kubernetes 集群"变得简单，是 SIG 持续投入的开发者体验项目。
- 定义 Windows 运维就绪（Operational Readiness）标准：为 Windows 节点在生产环境的可观测性、可靠性建立量化标准，最终孵化出独立的 windows-operational-readiness 子项目。
- 定义 Pod 的 OS 字段：为 API 层权威识别 Windows Pod 铺路（对应 KEP 2802）。
KEP 演进全览：从 Alpha 到 Stable 的 2021 成绩单
2021 年 SIG Windows 的 KEP 工作横跨 v1.22、v1.23 两个版本周期，覆盖 Stable / Beta / Alpha / Pre-alpha 四个阶段：
| 阶段 | 版本 | KEP 编号 | 主题 |
|---|---|---|---|
| Stable | v1.22 | 1122 | Windows CSI 支持（windows-csi-support） |
| Beta | v1.23 | 1981 | Windows 特权容器支持（HostProcess 容器） |
| Beta | v1.23 | 2802 | 在 API 准入层权威识别 Windows Pod |
| Alpha | v1.22 | 1981 | Windows 特权容器支持 |
| Alpha | v1.23 | 2802 | 在 API 准入层权威识别 Windows Pod |
| Pre-alpha | 目标 v1.24 | 2578 | Windows 运维就绪（Windows Conformance） |
从这张表可以看到清晰的演进节奏：KEP 1981 在 v1.22 以 Alpha 起步，v1.23 即升入 Beta；KEP 2802 则在 v1.23 同时完成了 Alpha 与 Beta 两个阶段。而 KEP 2578（Windows Operational Readiness）当时仍处于 Pre-alpha，目标定在 v1.24。
值得注意的是，后续年度的报告验证了这条路线图的兑现情况：sig-windows/annual-report-2022.md 记录到——KEP 2802 于 v1.25 升为 Stable，KEP 1981（HostProcess 容器）于 v1.26 正式毕业为 Stable，KEP 2578 则于 v1.24 以 Alpha 形态落地（Windows Conformance）；KEP 2258（Node log query）于 v1.27 进入 Alpha，正是 2021 年kubectl node logs接口定义的后续开花结果。
未纳入 KEP 的三条并行工作线
年度报告同时披露了三条未以 KEP 形式跟踪、但对 Windows 生产化同样关键的工作线：
- Windows kube-proxy 向 KPNG 迁移：将 Windows 版 kube-proxy 迁往 KPNG（Kubernetes Proxy Next Generation）架构。这一迁移后来在 2022 年演化出独立的 windows-service-proxy 子项目，并成为"使用 KPNG 构建树外 kube-proxy"的样板工程（见 sig-windows/annual-report-2023.md）。
- TestGrid 上报任务从 aks-engine 迁往 Cluster API（cluster-api/cluster-api-provider-azure）：把 Windows 的端到端测试基础设施迁移到更现代化的 Cluster API 体系上。
- Dockershim 移除对 Windows 节点的验证：在 Kubernetes 全面移除 Dockershim 的过程中，同步验证 Windows 节点侧的兼容与迁移路径。
这三条线体现了 SIG Windows 2021 年的工程重心：既向前推进新特性，也不断重构测试基础设施与组件实现，为 Windows 节点的长期可维护性筑基。
项目健康：最需要帮助的领域与社区健康指标
年度报告坦率地指出，csi-proxy 与存储领域是 Windows 生态中服务最不足的方向——尽管 Windows CSI 支持（KEP 1122）已进入 Stable，但负责承载该能力的 csi-proxy 子项目仍需要更多社区力量（会议信息见其仓库 README，2021 年社区已跨 VMware、Rancher 等公司围绕新的优化 issue 展开协作）。
SIG 关注并测量的社区健康指标包括：
- sig-windows-dev-tools 仓库 Star 数：2021 年已增长至 46，被视为社区兴趣度的风向标；
- sig-windows-tools 仓库 Star 数：代表"尝试在 k8s 节点上安装 Windows"的用户规模；
- windows-gmsa 仓库 Star 数：代表将 Windows Pod 集成进 GMSA（组托管服务账户）的企业采用度。
这些指标与 sig-windows/README.md 中列出的子项目矩阵一一对应：windows-gmsa、windows-operational-readiness、windows-samples、windows-service-proxy、windows-testing、windows-tools，构成了 SIG Windows 的可观察生态版图。
社区与成员数据
截至 2021 年度报告，SIG Windows 的社区规模与治理数据如下：
- 主 Slack 频道成员：1507 人
- 主邮件列表成员：188 人
- 主会议参会/参与人数（估算）：约 10 人
- SIG 自有包的独立 Reviewers：6 人
- SIG 自有包的独立 Approvers：4 人
在治理方面，报告确认了多项运营状态：README 与 CONTRIBUTING 已按 committee-steering/governance/sig-governance.md 的要求审核更新；sigs.yaml 中的子项目列表与 OWNERS 链接已核验；SIG 领导层活跃且来自多家公司（报告中明确确认存在多公司/多组织贡献者）；并在 2021 年完成了两次社区级对外更新（KubeCon EU 与 KubeCon NA 的虚拟演讲）。整体符合 community-membership.md 所描述的贡献者阶梯治理模型。
用户与公司可以切入的贡献方向
年度报告明确列出了四类"用户/公司当前尚未充分参与、但亟需力量"的方向，这也正是读者最实际的切入点：
- 在多个 Windows 应用上测试 HostProcess 实现：验证 HostProcess 容器在真实业务负载下的表现，覆盖 flannel、calico、csi-proxy、kube-proxy 之外的更多场景；
- 改进开发者工具环境以壮大社区：即参与 sig-windows-dev-tools 的迭代，降低 Windows 相关开发的门槛（2022 年报告再次强调这是"一贯被识别的贡献障碍"，并补充了 M1/M2 MacBook 支持等工作）；
- 加固 CSI proxy 与 CSI 支持生态：对应上文提到的 csi-proxy 服务不足问题；
- 大规模开展 Kubernetes on Windows 性能测试并发布结果：产出可公开引用的性能数据，支撑 Windows 节点在生产环境的推广决策。
附：Windows 贡献者的上手路线（仓库配套资源）
想要实际参与上述方向，可结合 sig-windows/CONTRIBUTING.md 的完整流程：
- 加入社区：通过 Slack 的 #sig-windows 频道与 SIG-Windows Google Group 与维护者建立联系，查看 SIG 的 Open Issues / Open PRs 看板；
- 从源码构建 Windows 二进制：Kubernetes 构建脚本未移植到 Windows，需要在 Linux 或 WSL2 环境下执行交叉构建，例如
./build/run.sh make kubelet KUBE_BUILD_PLATFORMS=windows/amd64单独构建 kubelet，或./build/run.sh make cross KUBE_BUILD_PLATFORMS=windows/amd64一次构建全部二进制，产物输出到_output/dockerized/bin； - 更新节点二进制：对已有集群，可先
kubectl drain <nodename>排空节点，再通过 PowerShell 执行Stop-Service kube-proxy -Force、Stop-Service kubelet -Force，替换 kubelet.exe/kube-proxy.exe 后Start-Service kubelet重启（可用sc.exe qc kubelet查询二进制路径）； - 运行测试：使用 windows-testing 项目构建 e2e 测试二进制并参考 TestGrid 上的 SIG-Windows 配置；
- 提交 PR：在 PR 描述中加
/sig windows打上标签，并用/test pull-kubernetes-e2e-aks-engine-windows-containerd触发 Windows 专属 e2e 测试； - 排障与日志收集：对 Windows 容器网络依赖服务启动失败，可用容器 lifecycle 的 postStart 钩子轮询等待 DNS 解析（如
ping -n 1 dbhost.example.com命中后再Restart-Service -Name dbconnect）；日志收集可用 nssm.exe 的AppStdout/AppStderr选项（例如nssm set kubelet AppStdout C:\k\kubelet.log），网络问题则可借助 Microsoft SDN 的 collectlogs.ps1 抓取C:\server.etl跟踪文件。
总结
从 2021 年度报告可以勾勒出 SIG Windows 的清晰技术主线：以HostProcess 容器打破 Windows 节点上基础设施容器化的限制，以Windows CSI补齐存储生态，以Pod OS 字段 + 准入层识别让 Windows 负载被 API 权威感知，以运维就绪标准 + node logs 接口打通生产可运维性，再配合 dev-tools 与测试基建的持续投入。后续 2022、2023 年度报告（sig-windows/annual-report-2022.md、sig-windows/annual-report-2023.md）则逐一兑现了这张路线图。对希望深耕 Windows 容器生态的开发者而言，从 csi-proxy 加固、HostProcess 场景测试到 dev-tools 改进，都是当前仍然开放且价值明确的参与窗口。
【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
