Kubernetes plans Workload Conformance: How resilient is your application?

A maintenance window begins. An operator needs to drain a node before updating it. For the application, this becomes a practical test of its architecture: Are other instances available? Can replacement Pods start? Do the existing instances finish their work cleanly?

The Kubernetes community wants a shared basis for assessing operational questions like these. On 27 October 2026, it publicly announced the Workload Conformance Working Group. The initiative concerns the applications running on a cluster and could change how platform teams and software vendors work together.

The significant advance would be a shared testing contract. Tools such as Kyverno and Chainsaw already support extensive policies and tests. What would be new is an upstream agreement on the runtime properties a workload should meet for a particular Kubernetes version. A finished testing tool automatically built into Kubernetes has not been announced. Kubernetes announcement

Key takeaways

• The plans cover a version-specific standard, verification methods and corresponding upstream testing tools.
• Specific requirements and test methods remain undecided. The project aims to reach an initial stable state within two to three Kubernetes release cycles.
• Kyverno, Chainsaw and existing Kubernetes mechanisms remain relevant building blocks.
• The potential benefit lies in jointly defined tests and more comparable results across software vendors and operators.
• Upstream does not automatically mean built into the API server or kubelet. A certification program has not started either.

Editorial status: 29 October 2026. This article reports an announcement and provides technical analysis. The practical examples below are our own suggestions for preparation, not an agreed test catalog from the working group.

What Kubernetes plans for Workload Conformance

The working group is to develop a specification for each Kubernetes minor version, objective verification methods for running workloads, and corresponding tools. This would give platform operators and application vendors a common reference for expected operational behavior. The public announcement does not commit to a particular Kubernetes version for delivery.

The charter covers areas including security, resilience during disruptions, resource use, networking, storage, API usage and observability. It also sets boundaries: the application's business logic is outside the scope. A particular packaging format, policy engine or vendor product should not be a prerequisite.

The specification and tools are intended for a future subproject under SIG Architecture, with SIG Apps contributing the application perspective. Any later CNCF certification program would be a separate step after the standard has stabilized and been approved. Today's announcement therefore establishes neither an available certificate nor a new Kubernetes API.

Why a node drain reveals so much about an application

A node drain makes a node unavailable for new regular scheduling and removes the eligible Pods in a controlled way. The responsible controllers can create replacement Pods. A Pod is not moved unchanged to another node. The documented drain procedure takes permitted evictions and the termination of affected Pods into account, among other things.

This is routine maintenance involving several mechanisms: scheduling, available capacity, storage attachment, application readiness and shutdown behavior. A plausible deployment manifest alone cannot predict the outcome.

A PodDisruptionBudget is a safeguard with a limited purpose

A PodDisruptionBudget, or PDB, limits voluntary disruptions to selected Pods. For example, it can block an eviction if too few instances would remain available afterward. That may be precisely the protection the operator intended.

PDBs do not prevent involuntary failures such as losing a node, although those failures count against the budget. They also do not constrain a workload controller's rolling updates. The controller's own update settings govern those. Kubernetes: Disruptions

Consider our own example: an application has three replicas and a PDB requiring at least two available instances. After the first eviction, insufficient capacity prevents the replacement Pod from being scheduled. Further evictions may remain blocked while the two remaining instances continue to work. The operator now needs to resolve capacity, placement and the maintenance procedure. Simply bypassing the budget would remove the limit that was intended in the first place.

Readiness and shutdown behavior must fit the application

Readiness, liveness and startup probes serve different purposes. A readiness probe helps determine whether an instance is ready to receive traffic. Whether the chosen endpoint meaningfully represents the required state depends on the application. An HTTP endpoint that always succeeds may say little about whether its dependencies are usable. Kubernetes: Probes

During normal termination, a configured preStop hook runs before the stop signal. Its execution already consumes part of the grace period. Long-running work, connection draining and the chosen deadline therefore need to fit together. Adding a hook is not a universal solution for every application. Kubernetes: Container Lifecycle Hooks

This suggests specific observations for a test: Which requests were in progress during the transition? Were jobs completed, retried in a controlled way or lost? How long did replacement instances take to become ready? These are our test ideas. Which of them a future standard will include remains undecided.

What Kyverno can already do today

Kyverno is an established Kubernetes-focused policy engine. Depending on the version and policy type, it can validate or mutate resources at admission. Policies can also trigger the generation of additional resources. Supported checks can be applied to existing resources and surfaced in Policy Reports. Kyverno: Applying Policies

This has immediate value for Kubernetes security: operators can define permitted configurations and address deviations before a new workload enters normal operation. Background reports add visibility into existing resources. The limits depend on the particular rule, its execution mode and the available context.

For example, the official policy catalog includes rules for:

• the presence of probes,
• resource requests and limits,
• matching a PodDisruptionBudget.

These examples need careful reading. The published probe example requires at least one of the listed probe types. It does not prove that the readiness endpoint is meaningful. The resource rule requires requests and memory limits; it does not establish a general requirement for CPU limits. The PDB example has its own prerequisites and should not be adopted as a universal rule for every workload without checking them.

The Kyverno CLI lets teams test policies and their expected results in a pipeline. A policy test establishes whether the rule handles particular inputs correctly. Actively running a disruption scenario answers an additional operational question.

Chainsaw can test real cluster workflows too

It would be incorrect to say that Kyverno can only check YAML. Chainsaw, from the Kyverno ecosystem, is an end-to-end testing tool for Kubernetes. Tests can apply resources, assert states and orchestrate commands or scripts. This allows teams to investigate real cluster workflows in a suitable test environment.

A team combining a drain test, assertions and its own load measurements today does not need to wait for the new working group. It does, however, define the scenario, permitted privileges, observation window and success criteria itself. That definition is precisely where the proposed common testing baseline comes in.

Kubernetes already has native security checks

Native checks are not an entirely new idea either. Pod Security Admission enforces the Pod Security Standards and has been stable since Kubernetes 1.25. Operators can distinguish between enforcement, audit and warning modes and pin a version, among other options.

ValidatingAdmissionPolicy has been stable since Kubernetes 1.30. It supports declarative validation using CEL within the API server process, providing an alternative to validating webhooks for suitable checks. That execution location is a genuine form of native integration.

An admission mechanism, a shared requirements standard and an executed runtime test serve different purposes. A rule evaluated inside the API server does not, by itself, run a maintenance exercise. Conversely, an effective runtime test does not necessarily need to be implemented inside the API server.

Why a shared upstream baseline could make a difference

Our assessment: The strongest potential benefit of Workload Conformance is a shared technical contract between application vendors and platform teams. That goes beyond deciding which engine executes a rule.

1. A clear link to the Kubernetes version

A claim that an application “works on Kubernetes” provides little precision for an upgrade decision. A versioned specification could describe more clearly which requirements were tested for the target version. API usage, known expectations and changes to tests would become easier to identify.

The specific application version, its configuration and the test environment would still form part of the result. The standard's version number cannot replace that context.

2. Fewer competing definitions of the same basic question

Today, different operators may understand “safe to maintain” as different scenarios. If vendors and operators use the same defined tests, they can clarify a basic expectation earlier in the delivery process. Discussion can focus more on remaining differences and organization-specific requirements.

This is an expected organizational benefit, not a measured time saving from the new project.

3. Checks informed by several areas of expertise

Workload behavior involves applications, scheduling, networking, storage and security. A jointly maintained upstream specification provides a place to bring these perspectives together. It could complement local rules with a more broadly agreed baseline.

How reproducible the eventual tests are, and what they cost to run, will need to be assessed when the first tools become available. Community governance alone does not solve those technical challenges.

4. More freedom in implementation

A vendor-neutral testing standard can allow multiple implementations. Kyverno, other policy engines, native admission rules and testing frameworks can each continue to serve useful purposes. Operators will still need their own rules and application tests.

That is why “natively integrated” is the wrong promise at this stage. What the sources establish is work on an upstream standard with testing tools. They do not establish integration into kubelet or the API server, automatic enforcement during operation, or the removal of additional components. The potential benefit is the jointly maintained definition, not an inherently superior engine.

What platform teams can usefully prepare now

The working group explicitly asks for real experiences from maintenance and upgrades. Describing a specific case, its conditions and the behavior observed helps standardization more than a general request for “greater resilience.”

For your own workloads, you can start by bringing existing information together:

This table is our own practical aid. It does not designate any particular configuration as a future conformance standard.

Read-only queries are enough for an initial inventory, for example in a selected test namespace:

kubectl get deployments,pods,pdb -n <test-namespace> -o wide
kubectl get deployment <deployment-name> -n <test-namespace> -o yaml
kubectl get pdb <pdb-name> -n <test-namespace> -o yaml

An active disruption test belongs in a suitable test environment or an explicitly authorized maintenance scenario. Define the affected workload, simulated load, acceptable impact and stop procedure in advance. The queries above do not perform an eviction.

What Workload Conformance means for cybersecurity and security management

Availability, unnecessary privileges and incompatible APIs all affect secure operations. The planned standard is therefore relevant to cybersecurity. It is not a penetration test, an assessment of the application's entire business logic or evidence of complete organizational compliance.

An operational finding needs an accountable team and a decision about how to address it. A failed test may lead to a configuration change, additional capacity or an application change. In some cases, a limitation will need explicit evaluation. Our article on reviewing risks covers this organizational aspect.

Kopexa can represent this workflow: risks, measures, responsible people and evidence are linked together. A technical tool's report can be an input to your process. Which data can be transferred through available import options or the GraphQL API needs to be checked against the specific model. This article does not promise a native Kyverno integration or an available Workload Conformance import.

Technical verification remains the job of the tools used for that purpose. Our practical OSCAL article also explains how to keep observations, assessments and follow-up work distinct.

What to look for in the next project update

The next meaningful steps will be a concrete set of requirements, precisely defined tests and traceable results from real workloads. Only then will it be possible to assess how much common ground the initiative creates and what operational work remains.

Until then, the initiative provides a useful basis for discussion: vendors and operators may gain a clearer way to agree on the runtime behavior they expect and how to test it. You can improve existing policies and application tests today—and contribute those experiences to the emerging specification.