Kubernetes has established itself as a platform for running containerized applications. The open-source technology handles container orchestration, distributes applications across available servers, and supports their scaling and management.
The underlying infrastructure is known as a Kubernetes cluster. It consists of multiple interconnected systems on which applications run in so-called Pods. Kubernetes coordinates these resources and provides functions that allow applications to keep running even when the infrastructure changes.
Especially in larger IT environments, these clusters need regular maintenance and updates. Applications should continue running with as little interruption as possible.
Yet this is precisely where a gap exists: A Kubernetes cluster can pass every conformance test while the applications running on it cause problems during a routine upgrade.
The Kubernetes community now wants to close this gap.
Kubernetes currently tests infrastructure, not applications
Programs such as “Certified Kubernetes” already provide established procedures for checking the conformance of a Kubernetes cluster. “Kubernetes AI Conformance” also evaluates certain prerequisites for running AI and machine-learning applications.
However, these checks focus on the cluster itself. They do not examine whether the applications running on it can reliably handle typical operational procedures.
There is currently no comparable conformance standard for these so-called workloads.
This means that before maintenance or cluster upgrades, administrators often have to check for themselves whether their applications can cope with the planned changes.
The necessary best practices are already documented within the Kubernetes project. In practice, however, compliance with them has to be checked individually time and again.
Why applications cause problems during routine maintenance
A typical example is the so-called node drain.
This prepares a Kubernetes node for maintenance. The Pods running on it are terminated in a controlled manner or restarted on other nodes.
Applications must be able to handle these interruptions. However, this does not always work.
For example, without suitable Pod Disruption Budgets, more application instances may become unavailable simultaneously during maintenance than intended. These budgets define how many Pods of an application may be unavailable at the same time during voluntary disruptions.
Another problem arises when processes do not respond correctly to termination signals. Kubernetes can terminate a Pod, but the application itself must respond appropriately to the process.
Difficulties also arise regularly during cluster upgrades.
Kubernetes continuously develops its programming interfaces. Older API versions are first deprecated and may later be removed. Applications that still depend on these versions may no longer work as intended after an upgrade.
There are also problems that do not immediately cause outages but impair operations.
Some workloads request unnecessarily broad permissions. Others permanently reserve hardware resources they do not actually need.
All these cases have one thing in common: They concern application behavior and cannot be ruled out through cluster conformance alone.
A new working group aims to create common standards
To close this gap, the Kubernetes community has established the “Workload Conformance Working Group.”
Its goal is to develop a common standard for the runtime behavior of applications on Kubernetes.
In the future, the requirements a conformant application must meet are to be defined for each Kubernetes minor version.
A minor version is a regular Kubernetes release within a major version series. The requirements are therefore intended to match the respective stage of Kubernetes development.
Alongside the specification, the working group plans to provide a standardized testing methodology and an upstream testing tool that can automatically check running workloads.
The proposed scope is extensive. It covers security, resource consumption, resilience to disruptions, networking and storage behavior, API usage, and observability.
Observability refers to the ability to understand an application's state and behavior through its operational data.
Which specific requirements will ultimately become part of the standard has not yet been decided.
Objective tests instead of individual assessments
The working group has already established one key rule: every requirement must be objectively verifiable using a test binary.
Technical verifiability therefore becomes a prerequisite for inclusion in the standard.
Subjective criteria are explicitly excluded.
The tests are intended solely to assess how an application runs on a Kubernetes cluster. Internal business logic remains outside the scope.
The question is therefore not whether an application correctly performs its business tasks, but how it behaves within the Kubernetes environment.
The working group also sets boundaries regarding the technologies used.
The standard is not intended to require particular packaging formats such as Helm charts. Nor will it prescribe external policy engines or security scanners.
It also aims to avoid repeating tests already covered by existing cluster certification.
The new workload conformance standard is intended to complement existing infrastructure checks, not replace them.
What could change for platform teams and developers
Today, platform teams often have to repeat the same checks in different environments before maintenance and upgrades.
At the same time, application developers repeatedly answer similar questions about the technical characteristics of their workloads.
A standardized testing methodology could make these recurring checks consistent.
Instead of interpreting requirements individually, developers and administrators could refer to a shared specification and verify runtime behavior using defined tests.
This would be particularly relevant for cluster upgrades. Application compatibility could be examined against consistent criteria before changes are made to the infrastructure.
However, the practical benefit depends on which requirements actually make it into the specification and how reliably they can be checked automatically.
No final decisions have yet been made on these points.
First stable version expected only after several release cycles
The initiative is supported organizationally by two Kubernetes Special Interest Groups.
SIG Apps contributes the perspective of application developers. Once initial drafts are available, SIG Architecture is intended to manage the specification and tools in a dedicated subproject over the long term.
Where requirements affect other technical areas, such as networking functions or the behavior of individual nodes, the responsible SIGs are to be involved directly.
The participants estimate two to three Kubernetes release cycles for an initial stable specification including working tests.
The working group is therefore still at an early stage of development.
Administrators and developers are currently being sought to contribute concrete problems from past maintenance windows, review proposed requirements, or run early versions of the test binary against their own workloads.
Collaboration takes place through the Kubernetes Slack channel #wg-workload-conformance, a mailing list, and video conferences.
Conclusion: conformance must extend beyond the cluster
The new initiative addresses a specific weakness in the existing Kubernetes conformance model.
While infrastructure can already be checked against defined standards, there is no comparable procedure for application runtime behavior.
The consequences become apparent during maintenance, cluster upgrades, and day-to-day operations. Applications do not respond to disruptions as expected, use removed APIs, or request unnecessary permissions and resources.
The Workload Conformance Working Group aims to develop objective, automatable checks for these issues.
Whether this produces a practical standard will only become clear once the specification and its associated tools are available.
The approach nevertheless makes sense: a conformant Kubernetes cluster currently says little about whether the applications running on it meet the requirements for reliable operation. This is precisely the distinction that should become verifiable in the future.