Kubernetes Workload Conformance 工作组解决什么兼容性问题

Kubernetes Workload Conformance 工作组要解决的是：应用部署到 Kubernetes 后，对权限、资源、中断和平台接口的依赖缺少共同、可重复判断的运行行为标准。集群提供兼容的基础设施，并不意味着每个应用都能承受节点维护、版本升级或环境差异。工作组希望让应用维护者与集群运维者围绕同一套客观要求沟通，减少各环境反复评估同一应用的成本。

2026 年 10 月 27 日，Kubernetes 官方博客宣布成立该工作组。这是一项标准与工具建设工作，不能据此认定所有工作负载已经获得兼容性保证，也不能把规划中的测试当成现成的认证服务。

官方地址：https://kubernetes.io/

集群正常，为什么应用在维护时出问题

设想一个内部报表服务：平时请求能返回，容器也处于运行状态；维护节点时，报表任务却中断，迁移到另一套集群后又需要额外权限。这是用于分析的假设场景，并非真实事故记录。它说明“能创建资源”“能启动容器”和“运行行为满足平台要求”是不同判断。

排查这种问题时，最小可用做法是先写清三件事：应用在哪个条件下出问题、它期望平台提供什么、实际观察到什么。不要直接把结果归结为 Kubernetes 不兼容。例如，应用依赖一个目标环境没有提供的扩展，与应用使用了已移除的 API，需要采取的动作就不同。

工作组的价值正在于给这类判断提供共同起点。应用团队可以更清楚地说明运行前提；平台团队可以更一致地表达维护要求。它减少的是判断口径的分散，并不会消除所有环境配置差异。

把兼容性分成集群、运行行为和业务结果

Certified Kubernetes 面向 Kubernetes 实现和集群的一致性。Workload Conformance 将目光放到运行在其上的工作负载。应用的报表金额是否算对、业务审批是否符合规则，则仍属于应用自身的测试范围。

因此，跨环境比较时应把“版本、环境条件、应用构件、要求范围”放在一起。只记录一个通过标记，之后很难说明它对应哪个版本、哪组条件。工作组提出按 Kubernetes 次版本定义规范，也意味着讨论不能脱离具体平台版本。

按现象整理运行时依赖

目前可以先把团队遇到的现象整理成依赖清单。下面是本文给出的工程记录方式，不是工作组已经通过的正式测试条款，也不应据此宣称应用通过 Workload Conformance。

记录中要把事实与假设分开。“恢复用了多久”是观察值，“由存储后端导致”则可能只是待确认的解释。同样，“申请了较多资源”不等于声明错误；需要结合负载与运行条件判断，不能仅凭一张空闲时刻的曲线下结论。

同一条件下比较证据，再选择修复动作

以节点维护为例，先区分自愿中断和非自愿中断。Kubernetes 的中断文档说明了 PodDisruptionBudget 对自愿中断的约束，也说明它不能阻止非自愿中断。一次正常维护中的表现，不能替代节点故障场景的判断。

如果应用维护时不可用，应先看故障发生在驱逐、终止、替代副本启动还是业务恢复阶段，再决定修改副本配置、退出处理或平台依赖。不要把“加上一个 PDB”当成所有不可用问题的共同修复：预算设置、可用副本和应用恢复能力需要一起考虑。

反向比较也应保持条件一致。修复前后若同时更换镜像、资源配置和存储后端，即便表现改善，也无法确定是哪项改动起作用。更有效的记录是固定应用构件与场景条件，说明修改项及其预期影响，再观察相同场景。这里给出的是读者的工程方法，本文没有执行集群操作或生成实测数据。

工作组准备交付什么，尚未承诺什么

官方公告列出的交付方向有三部分：按 Kubernetes 次版本描述工作负载行为的规范、针对运行中工作负载的测试方法，以及实现这些测试的上游工具。公告同时说明，具体要求及其测试方式仍在讨论；每项要求必须能够被测试程序客观判断。

章程进一步区分了组织职责：SIG Architecture 的子项目将承接规范与工具，SIG Apps 提供应用视角，涉及其他领域时与相关 SIG 协作。工作组不指定必须使用哪种打包格式、策略引擎或厂商工具，也不承担运营认证项目的职责。

这对选型有一个直接影响：团队不必为了这则公告立即更换 Helm、Operator 或现有交付方式。应该先关注运行前提能否说清、问题能否重复观察，以及后续规范到底覆盖哪些要求。两到三个 Kubernetes 发布周期是公告中的推进目标，不能换算成已承诺的上线日期。

迁移前留下可重复的检查清单

• 记录应用构件、目标 Kubernetes 次版本及依赖的扩展能力。
• 把日常运行、节点维护和升级等场景分开，给每个场景写出观察条件。
• 区分平台接口问题、应用运行行为问题与业务逻辑问题。
• 给修复动作保留前后对照，说明条件是否变化。
• 关注工作组后续规范与工具进展，不把内部检查清单包装成官方认证。

通过集群一致性测试，应用还需要评估吗？

需要。应用自己的运行假设、外部依赖和业务结果仍要单独确认；工作组的方向正是为运行行为评估提供共享基线。

将来通过工作负载测试，就能保证任意环境性能相同吗？

不能这样推断。任何结果都应结合规范覆盖范围、版本和测试条件理解；吞吐、延迟及业务服务目标还需要自己的评估依据。

应用维护者现在可以做什么？

把具体的维护失败、升级障碍和环境依赖整理成可讨论案例，明确预期与观察值，再通过工作组渠道反馈。相比笼统地说“迁移有问题”，这样的材料更便于讨论哪些要求可以客观测试。

官方资料：工作组公告 https://kubernetes.io/blog/2026/10/27/announcing-workload-conformance-wg/；章程 https://github.com/kubernetes/community/blob/master/wg-workload-conformance/charter.md；中断说明 https://kubernetes.io/docs/concepts/workloads/pods/disruptions/；集群一致性项目 https://www.cncf.io/training/certification/software-conformance/。