宣布成立工作负载一致性工作组
内容提要
Kubernetes社区成立工作负载一致性工作组，制定工作负载运行时行为的共享标准，以弥补现有集群认证和AI认证的空白。规范涵盖安全、中断韧性、资源使用、网络、存储、API使用和可观测性，每项要求须有客观测试，不涉及应用逻辑。目标是在两三个发布周期内推出稳定规范和测试，并呼吁用户反馈经验。
延伸解读
填补工作负载层面的认证空白
现有认证体系只覆盖集群本身和AI运行能力，工作负载的运行时行为缺乏统一标准。集群运维在升级或维护前仍需手动检查每个应用，重复发现节点排空导致中断、API版本移除引发故障等问题。该工作组旨在为工作负载建立可重复测试的共享基线，减少各环境重复评估的成本。
规范边界：只测运行行为，不碰应用逻辑
规范聚焦工作负载在Kubernetes上的运行方式，而非具体功能，因此应用逻辑被明确排除。每项要求必须有测试二进制可执行的客观测试，不接受主观判断。同时不重复集群认证已覆盖的内容，也不强制特定打包格式或厂商工具，这有助于保持规范的中立性和可移植性。
跨SIG协作与两三个发布周期的节奏
工作组由两个SIG赞助，当需求涉及节点行为、网络等其他SIG领域时会主动发起沟通，使各SIG能在规范编写阶段参与并影响方向。目标是在两到三个Kubernetes发布周期内推出稳定规范和可运行的测试。这一时间表意味着早期反馈尤为关键，实际案例将直接影响规范内容。
用户经验是规范落地的关键输入
规范需要从真实案例中构建，工作组公开征集两类经验：集群运维者当前如何评估工作负载、上次升级或维护窗口出了什么问题；应用维护者需要集群提供什么、现有指南在哪些地方让人困惑。这些反馈可通过Slack频道和邮件列表提交，也可在双周会议上提出议题，直接影响首批要求的取舍。
Q&A
Kubernetes 工作负载一致性工作组是做什么的？
该工作组正在制定工作负载在 Kubernetes 上运行时行为的共享标准，并计划提供可重复的测试，以弥补现有集群认证和 AI 认证未覆盖工作负载本身的空白。
为什么需要工作负载一致性标准？
因为目前没有针对工作负载本身的标准，集群运维人员仍需在例行维护或升级前手动检查每个应用，常发现应用无法容忍中断、依赖已移除的 API 版本、申请不必要权限或预留未使用资源等问题，导致重复评估和重复提问。
工作负载一致性规范涵盖哪些方面？
规范范围包括安全、中断韧性、资源使用、网络、存储、API 使用和可观测性，但具体要求和测试方法尚未达成一致。
工作负载一致性规范会涉及应用逻辑吗？
不会。规范只关注工作负载如何运行，不关注它做什么，因此应用逻辑不在工作负载一致性的范围内。
工作负载一致性测试有哪些要求？
每项要求都必须有可由测试二进制运行的客观测试，不能包含主观内容；测试不会重复认证 Kubernetes 已覆盖的内容，也不会要求特定的工作负载打包格式或供应商工具（如策略引擎、安全扫描器等）。
工作负载一致性工作组计划何时推出稳定规范和测试？
目标是在两到三个 Kubernetes 发布周期内推出稳定的第一版规范和可用的测试。
如何参与或反馈工作负载一致性工作组？
可以通过 Kubernetes Slack 的 #wg-workload-conformance 频道（访问 slack.k8s.io 获取邀请）或邮件列表参与；工作组每两周的周三 15:00 UTC 开会，会议链接和议程在会议记录中，也可在议程中添加议题。
