Announcing the Workload Conformance Working Group

Cluster operators currently check each application manually before upgrades or routine maintenance, a necessity because existing tools like Certified Kubernetes or Kubernetes AI Conformance do not test the workloads themselves.

This gap means familiar issues surface frequently; for instance, a routine node drain might reveal an application's inability to handle disruption, or an upgrade could break something still relying on a deprecated API version.

The Kubernetes community has launched a Workload Conformance Working Group to address this, aiming to create a shared standard detailing how workloads operate at runtime within Kubernetes.

This standard seeks to provide both application maintainers and cluster operators with a common baseline, reducing the need for repetitive assessments across different environments.

The group's charter outlines three key deliverables: a specification of workload behavior for every Kubernetes minor version, a method for testing each requirement against a running workload, and the actual upstream conformance tooling implementing those tests.

The scope of this specification covers areas like security, resource use, networking, storage, API usage, and observability, though the group has not yet finalized specific requirements or testing methodologies.

A key constraint is that every requirement must possess an objective test that a binary can execute, ensuring the specification avoids subjective criteria; furthermore, it focuses on *how* a workload runs, not *what* it functionally does.

The effort is sponsored by two Special Interest Groups (SIGs): SIG Architecture will manage the specification and tooling via a subproject, while SIG Apps provides the application viewpoint, ensuring collaboration with other relevant SIGs when necessary.

The team anticipates delivering a stable first specification and working tests within two to three Kubernetes release cycles.

Those interested in contributing are encouraged to share real-world experiences—whether you run clusters and can detail what failed during maintenance, or if you maintain an application and can point out where current guidance is ambiguous.