Kubernetes workload conformance: no spec, two real tests

The Kubernetes project announced a Workload Conformance Working Group on 27 October 2026, and the most useful sentence in the announcement is a disclaimer: "No spec, test suite, tooling, or certification is released." So there is nothing you must do about kubernetes workload conformance this quarter. What the group did publish is a scope, and it names two failures you can rehearse on your own cluster this week.

The facts, as of 1 November 2026, all from the announcement itself:

• It is a working group inside the Kubernetes project. Not a SIG, not a CNCF certification programme.
• 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".
• Scope "includes security, resilience during disruptions, resource use, networking, storage, API usage, and observability". Application logic is out of scope, and it "won't require a particular workload packaging format, or vendor tool".
• Status: "The group hasn't yet agreed on specific requirements or on how to test them."
• Target: "a stable first specification and working tests within two to three Kubernetes release cycles". No calendar date is given anywhere in the post.
• Governance: SIG Architecture will own the spec and tooling through a subproject created once the working group proposes the first artifacts. SIG Apps brings the application perspective.

What kubernetes workload conformance is for, and what it replaces

Certified Kubernetes already tests clusters. The announcement's framing of the gap is precise: "Nothing comparable exists for the workloads themselves, so cluster operators still check each application by hand before routine maintenance or a Kubernetes upgrade."

If you run a platform team you recognise that hand-checking. It is the spreadsheet of application owners you chase before every minor upgrade, and the reason the window slips. The charter goal is "writing a shared standard for how workloads behave at runtime on Kubernetes" — a contract the application side has to meet, rather than one more thing the cluster absorbs.

One constraint narrows the eventual spec usefully: "every requirement needs an objective test that a test binary can run". Requirements a binary cannot assert against a live workload will not survive that filter, so expect probes, API calls and disruption injection rather than architecture-review questionnaires.

Any workload conformance checklist published today is invented

The group has not agreed its requirements. That is a direct quote, not an inference. So an article listing "the seven workload conformance requirements" has taken the seven scope areas — security, resilience, resource use, networking, storage, API usage, observability — and dressed them as requirements. Those are headings for future discussion, not tests, and nobody yet knows which of them produces a mandatory check versus an optional one.

Give the opposite case its strongest form: the scope plus the Certified Kubernetes precedent is enough to guess at requirements, and a guess you can act on beats waiting. The problem is that you would be guessing twice — the requirement, then the test shape, and the test shape is what decides whether your workload passes. "Must declare resource requests and limits" could become a hard failure, a warning, or nothing at all, depending on how the group measures it.

When someone senior asks whether you are compliant, the accurate answer is that the standard does not exist, the two-to-three-release-cycle target is a target, and the work worth doing now is work you would want done anyway.

Test one: does a node drain take your application down?

A node drain revealing an application that cannot tolerate disruption is the first failure the announcement cites, and you can provoke it today. The mechanism is the PodDisruptionBudget, stable since Kubernetes v1.21, which caps how many pods of a set may be disrupted at once by voluntary disruptions.

Three things in the PDB documentation catch teams out. A budget sets either minAvailable or maxUnavailable, never both. Percentages round up, and for maxUnavailable the rounding is applied to the number of pods that may be disrupted, so a real disruption can exceed the percentage you wrote. And where the desired replica count is one, a percentage-based maxUnavailable still permits that single replica to go — effective unavailability of 100%, from a budget that looks protective.

Start with coverage rather than tuning. List every Deployment and StatefulSet that serves traffic, then list the PDBs, and look at the set difference. Workloads with no budget at all are the finding; so is any single-replica workload that someone expects to survive maintenance, because no budget can save one replica on one node.

Then rehearse the drain on one real node in a maintenance window:

kubectl drain ip-10-0-3-21 --ignore-daemonsets --delete-emptydir-data --timeout=300s

Read what it tells you. The Eviction API returns 429 Too Many Requests when a budget currently blocks an eviction, which is the system working, and 500 Internal Server Error "because there is a misconfiguration, like if multiple PodDisruptionBudgets reference the same Pod" — that one retrying will never fix. If drain refuses to proceed without --force, you have pods with no controller behind them, which is a finding in itself.

One flag to leave alone during a rehearsal. --disable-eviction forces drain to use delete and, in the documentation's words, "will bypass checking PodDisruptionBudgets" — it skips exactly the behaviour you are trying to measure. And a budget is not a guarantee: the docs note that a node holding a pod can fail while the set is already at its minimum size.

Test two: are you calling an API version that is already gone?

The second cited failure is an upgrade breaking an application that uses a removed API version. This one has had tooling for years. The Kubernetes deprecated API migration guide lists removals per release, and the pattern is unkind to manifests nobody has opened since 2022.

Removed in	API version	Use instead
v1.25	policy/v1beta1 PodDisruptionBudget	policy/v1, available since v1.21
v1.25	batch/v1beta1 CronJob	batch/v1, available since v1.21
v1.26	autoscaling/v2beta2 HorizontalPodAutoscaler	autoscaling/v2, available since v1.23
v1.32	flowcontrol.apiserver.k8s.io/v1beta3	flowcontrol.apiserver.k8s.io/v1, available since v1.29

Note the first row, because it bites the first test: a PodDisruptionBudget written at policy/v1beta1 has been unservable since v1.25. The guide's method for finding this is "client warnings, metrics, and audit information available in 1.19+" — your API server already logs deprecated use, and almost nobody alerts on it. To simulate a removal before it lands, start an API server with --runtime-config=<group>/<version>=false. To fix manifests, kubectl convert -f <file> --output-version apps/v1, noting that kubectl convert is not installed by default and its conversions "may use non-ideal default values".

This audit pays for itself against a date you already have. Managed-platform support windows move whether or not your manifests do, which is why we wrote up the EKS 1.34 end of support price jump, and version-specific behaviour keeps arriving — the new Unused condition on Kubernetes PVCs in 1.37 is a recent example. If you run several clusters the audit has to be fleet-wide, as our write-up on multi-cluster Kubernetes after Karmada's CNCF graduation covers: spot checks miss the one cluster still on the old manifest.

What to do with the next two or three release cycles

Do not staff a conformance project. Spend the interval producing two artefacts you will want regardless of what the working group ships: a PDB coverage report with named owners for the gaps, and a deprecated-API report generated from API server audit data rather than from grepping a repository. Both are inputs to whatever the spec becomes, because resilience during disruptions and API usage are already in its scope.

This is the wrong priority if you are not yet upgrading on a schedule. A team that upgrades reactively, once a support date forces it, gets more from fixing the upgrade cadence than from either test — the tests tell you what will break, which is only useful if someone is going to act on it.

If you want those two reports without pulling your platform engineers off delivery, that is the kind of work our Kubernetes implementation team takes on: drain rehearsal on a real node, PDB coverage across your namespaces, and a deprecated-API audit mapped to the version your managed control plane is heading for. We will tell you which of your workloads would have failed, in the words of the people who own them.