Kubernetes 成立 Workload Conformance 工作组，为应用运行时行为制定一致性标准

关闭提示

本文也有英文版本。

本文在技术协助下完成翻译，并在发布前经过编辑审校。

。

Kubernetes 社区成立了“Workload Conformance Working Group”（工作负载一致性工作组）。该工作组旨在为应用在集群上的运行时行为制定统一标准，并提供用于自动化测试的配套工具。

广告后继续阅读

迄今为止，Kubernetes 生态系统中的一致性测试仅聚焦于基础设施。诸如“Certified Kubernetes”或“Kubernetes AI Conformance”之类的项目只检查集群本身是否符合规范，或者是否适合 AI 和 ML 任务。而对于运行在其上的应用，则不存在可比的衡量标准。正如发起人 Nabarun Pal 在新工作组的公告中所解释的那样，管理员因此往往在例行维护工作或集群升级之前，仍需手动检查各个工作负载能否应对这些操作。

日常运维中的后果众所周知：往往要到例行的节点排空（Node-Drain）时才会发现，某个应用无法妥善容忍中断。例如，这可能是因为缺少 Pod Disruption Budgets，或者进程未能正确响应终止信号。同样，集群升级也常常因为所用软件仍依赖已弃用并最终被移除的 API 版本而失败。在运行过程中，还不断有工作负载引起注意：它们申请了不必要的大范围权限，或者长期预留硬件资源却并未实际使用。虽然 Kubernetes 项目已经详细记录了针对此类情况的最佳实践，但在实践中，平台团队仍会为每个环境重复相同的检查，而应用开发者也不得不反复回答相同的追问。

针对运行中应用的客观测试

如今，一个具有约束力的基础应当为此提供解决方案：它为 Kubernetes 的每个次要版本规定，符合规范的应用应具备怎样的运行时行为。除该规范外，工作组还希望开发一套针对运行中工作负载的测试方法，以及配套的上游测试工具。在内容上，该委员会划定了广泛的范围：从安全方面、资源消耗和故障时的可用性，到网络和存储行为，再到 API 使用和可观测性。目前尚未确定哪些具体要求会被纳入目录。

不过，有一条基本原则是确定的：每项要求都必须能够通过测试二进制文件进行客观验证。该工作组的章程明确排除了主观标准。此外，只检查应用在集群上的运行方式。软件的内部业务逻辑不在考察范围内。而且，计划中的工具不应重复现有集群认证已经覆盖的测试。它也不规定特定的打包格式（如 Helm Charts），也不规定第三方工具（如外部策略引擎或安全扫描器）。

首个稳定版本将在两到三个发布周期后推出

广告后继续阅读

在组织层面，该倡议由两个特别兴趣小组（SIG）支持。SIG Apps 贡献应用开发者的视角，而 SIG Architecture 将在首批草案出现后，长期在自有子项目中管理规范和工具。如果计划中的要求涉及其他专业领域，如网络或节点行为，工作组会直接纳入相应的 SIG。

参与者估计，从启动到首个稳定规范及可运行的测试出台，需要两到三个 Kubernetes 发布周期。目前，工作组仍在寻找管理员和开发者，以贡献过往维护窗口中的真实问题案例、评审要求，或针对自有工作负载运行测试二进制文件的早期版本。协调工作通过 Kubernetes Slack 中的 #wg-workload-conformance 频道、邮件列表和视频会议进行。

(fo)