Kubernetes announces Workload Conformance Working Group

On Tuesday, October 27, 2026, Nabarun Pal of Broadcom announced on behalf of WG Workload Conformance that the Kubernetes community now has a Workload Conformance Working Group. Kubernetes Blog's report says the group is writing a shared standard for how workloads behave at runtime on Kubernetes. "To get it right, we need input from the people who build those workloads and from the people who run the clusters they're deployed on," Pal wrote. It was last modified October 26, 2026 at 9:08 AM PST.

This piece covers the missing standard for workloads, the three deliverables in the charter, the SIG sponsors, and how operators, maintainers, reviewers, and test authors can take part. It is for cluster operators who check each application by hand before routine maintenance or a Kubernetes upgrade, and for application maintainers who get the same questions from each environment they support.

Kubernetes Workload Conformance Working Group: the announcement

Certified Kubernetes tests the cluster, and Kubernetes AI Conformance tests whether a cluster can run AI and ML workloads. Nothing comparable exists for the workloads themselves, so cluster operators still check each application by hand before routine maintenance or a Kubernetes upgrade. A routine node drain is often how an operator discovers that an application cannot tolerate disruption. An upgrade can break an application that still depends on a removed API version. Others show up in day-to-day operation: workloads that ask for privileges they do not need, or reserve resources they never use.

Kubernetes already documents much of this, including security and handling disruptions. Even so, every cluster operator ends up repeating the same assessment, and application maintainers get the same questions from each environment they support. A common specification with repeatable tests would give both groups the same baseline to start from. Pal announced the working group on behalf of WG Workload Conformance and thanked everyone who reviewed and supported the working group proposal. The blog revision cited on the page is 67216389b4.

What actually changed with Kubernetes Workload Conformance Working Group

The Workload Conformance Working Group charter sets out three deliverables: a specification of workload behavior for each Kubernetes minor version, a method for testing each requirement against a running workload, and upstream conformance tooling that implements those tests. The first step is deciding which workloads and behaviors the specification covers. The scope includes security, resilience during disruptions, resource use, networking, storage, API usage, and observability. The group has not yet agreed on specific requirements or on how to test them.

One rule is already set: every requirement needs an objective test that a test binary can run, so nothing subjective goes into the specification. "The specification covers how a workload runs, and importantly not what it does," the announcement states. Application logic is out of scope of workload conformance. The binary will not retest anything Certified Kubernetes already covers, and it will not require a particular workload packaging format, or a vendor tool such as a policy engine or a security scanner.

Who should care about Kubernetes Workload Conformance Working Group

Two Special Interest Groups (SIGs) are sponsors for the working group. SIG Architecture will own the specification and tooling through a subproject, created once the first artifacts are proposed by the Working Group. SIG Apps will bring the application perspective. When a requirement touches another SIG's area, such as node behavior or networking, the working group will initiate conversations with those SIGs. The working group is a forum where SIGs shape the direction of Workload Conformance while the specification is being written.

Cluster operators should care because they still assess each application by hand before routine maintenance or a Kubernetes upgrade, and a node drain is often the moment an application shows it cannot tolerate disruption. Application maintainers should care because each environment they support asks the same questions, including about a removed API version, extra privileges, and reserved resources the workload never uses. The subproject will outlive the working group, so the organizers are also looking for people who want to maintain it for the long term.

How to try Kubernetes Workload Conformance Working Group

The specification will be built from real examples, and the working group wants those examples now. Cluster operators can describe how they assess workloads today and what broke during their last upgrade or maintenance window. Application maintainers can describe what an application needs from the cluster and where the existing guidance left them guessing. Beyond examples, the work needs reviewers for proposed requirements and contributors to write the tests and tooling. The group wants early testers when early versions of the tests are ready.

Early testers are asked to run the binary against their own workloads and say where the results differ between runs or environments. If a requirement touches a SIG's area, that SIG helps check its scope and the test behind it. The group is in #wg-workload-conformance on Kubernetes Slack. Invitations are at slack.k8s.io, and discussion also runs on the mailing list. Meetings are every other Wednesday at 15:00 UTC, with the Zoom link and the agenda in the meeting notes. A topic is raised by adding it to the agenda. Joining the mailing list usually adds the meeting invite to the calendar.

What to watch after Kubernetes Workload Conformance Working Group

The group has not yet agreed on specific requirements or on how to test them. The open choice is which workloads and behaviors to cover across security, resilience during disruptions, resource use, networking, storage, API usage, and observability. Every requirement that is accepted needs an objective test that a test binary can run, so nothing subjective goes into the specification. The aim is a stable first specification and working tests within two to three Kubernetes release cycles. Nabarun Pal stated that aim in the announcement.

The deliverable to watch is a specification of workload behavior for each Kubernetes minor version, a test method that runs each requirement against a running workload, and upstream conformance tooling. SIG Architecture creates the subproject that will own the specification and tooling once the Working Group proposes the first artifacts. That subproject will outlive the working group. When early versions of the tests are ready, testers run the binary on their own workloads and report where results differ between runs or environments.