Kubernetes Workload Conformance: What It Tests

Kubernetes workload conformance is an emerging effort to define repeatable tests for how an application behaves on a Kubernetes cluster—not just whether the cluster implements Kubernetes correctly. Application developers and platform teams need this distinction when they assess upgrades, security settings, resource use, and routine maintenance. The working group is still defining its specification and tooling, so workload conformance is a direction of work rather than a finished certification or test suite.

What Is Kubernetes Workload Conformance?

A Kubernetes workload is an application running in one or more Pods, typically managed by resources such as Deployments, StatefulSets, Jobs, and DaemonSets. The Kubernetes project provides the orchestration platform, while its workload documentation describes the objects that run and manage those applications.

Workload conformance asks whether a particular workload behaves according to a shared, objectively testable baseline on Kubernetes. The Workload Conformance Working Group announcement describes a specification organized by Kubernetes minor version, a way to test requirements against a running workload, and upstream tooling to run those tests.

The scope is runtime behavior: how a workload uses Kubernetes and responds to its environment. It does not assess whether the application implements the right business logic, and it is not intended to require a specific packaging format, policy engine, scanner, or vendor product. The working group’s charter frames these boundaries and states that requirements must be verifiable programmatically rather than based on subjective judgments.

The Problem Workload Conformance Solves

Kubernetes cluster conformance checks the platform implementation. It helps establish that different Kubernetes distributions provide compatible cluster behavior. The CNCF Certified Kubernetes Conformance Program describes this as interoperability between Kubernetes installations.

That does not establish that every application running on a conformant cluster can safely use it. A workload may fail when a node is drained, rely on an API version later removed from Kubernetes, request excessive privileges, or reserve resources inaccurately. Operators often have to repeat similar application reviews for each cluster or upgrade, while application maintainers face different checklists from every platform team.

Kubernetes already provides the mechanisms applications need to handle these conditions. For example, Pod disruption budgets can limit voluntary disruptions for selected replicated workloads, and resource requests and limits inform scheduling and resource enforcement. The missing piece is a shared way to verify that a running workload’s configuration and behavior meet an agreed baseline.

How Workload Conformance Is Intended to Work

Workload conformance adds a workload-focused layer alongside other Kubernetes checks. These programs answer different questions:

The Kubernetes AI Conformance program is a useful comparison: it evaluates platform capabilities for a particular workload class, whereas workload conformance focuses on how an individual workload behaves.

The planned process is to define requirements for each Kubernetes minor version, specify how each requirement can be verified, and maintain upstream tooling for those checks. Each requirement must have an objective test. A check might inspect a workload’s live state, exercise a supported runtime behavior, or gather evidence from Kubernetes APIs; the exact method depends on the requirement.

At present, the working group is defining the specification and verification approach. The precise requirements, test invocation, output format, permissions, and stable release process are not established. The charter also says the Kubernetes project will not endorse or support a certification program until the standard is created and approved by SIG Architecture. That makes it important to distinguish a proposed conformance effort from an available product: there is not yet a general workload-conformance command that operators can run to certify their applications.

Candidate Checks and Key Concepts

The charter identifies areas the specification may cover. The examples below illustrate what objective checks could examine; they are not a finalized checklist or a guarantee that each behavior will become a requirement.

These categories connect several layers. A Pod’s security context is part of the workload configuration, but the effective isolation also depends on the node and container runtime. A disruption budget affects voluntary eviction through the Kubernetes Eviction API, but it does not prevent hardware failures. A resource request influences scheduling, while a limit is enforced at runtime. A useful test therefore needs to say what it observes and what its result does—and does not—mean.

Real-World Use Cases

Planning a cluster upgrade: Teams can use a version-specific workload baseline to identify dependencies that may fail when the Kubernetes API or runtime changes. The upstream API deprecation guide shows why version-specific checks matter: deprecated API versions are eventually removed.

Preparing routine maintenance: Platform operators need to know whether applications can tolerate node drains and other voluntary disruptions. A repeatable check could help identify workloads with insufficient replicas or unsuitable disruption settings before a maintenance window.

Improving application portability: Software vendors and internal platform teams can test the same workload expectations across supported clusters instead of maintaining entirely separate manual reviews for each environment.

Reducing repeated security reviews: A shared baseline could provide a starting point for evaluating workload security settings, while leaving organizations free to apply stricter policies based on their threat model.

In each case, conformance would provide evidence about defined behaviors, not a guarantee of uptime, security, or correct application output. Teams would still need workload-specific testing and operational monitoring.

Getting Started: Prepare and Inspect a Workload

Because the proposed conformance suite is not ready as a general certification tool, teams can start by making workload behavior explicit and collecting a repeatable baseline. Kubernetes Pod Security Standards and startup, readiness, and liveness probes provide existing mechanisms to review.

For example, the following Deployment declares two replicas, resource requests and limits, a non-root identity, dropped Linux capabilities, and HTTP health checks. Replace the image and probe paths with values appropriate to the application; the resource values are illustrative, not universal recommendations.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 101
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: web
          image: nginxinc/nginx-unprivileged:stable
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          startupProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10

For voluntary maintenance, a separate PodDisruptionBudget can limit simultaneous evictions of these replicas:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
  namespace: apps
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

A PodDisruptionBudget does not protect against involuntary failures, and it does not constrain a Deployment’s own rolling update. Confirm that its selector matches the workload and that the replica count can satisfy the budget before relying on it.

Use read-only inspection and server-side validation to establish a baseline. These commands do not run a workload-conformance suite:

kubectl get deployments,statefulsets,daemonsets,jobs -A
kubectl get pods -n apps -o wide
kubectl get pdb -n apps
kubectl describe deployment web -n apps
kubectl rollout status deployment/web -n apps
kubectl get events -n apps --sort-by=.lastTimestamp
kubectl apply --dry-run=server -f workload.yaml

Record the cluster version, workload manifest, relevant events, resource settings, and observed behavior during a controlled maintenance or upgrade test. A server-side dry run confirms that the API server accepts an object; it does not prove the live application is resilient or compliant. For broader Kubernetes architecture context, see our Kubernetes architecture explainer, and use Kubernetes cluster monitoring to understand operational signals such as restarts and resource pressure.

Common Misconceptions

A conformant cluster makes every application conformant. Cluster conformance evaluates the Kubernetes platform. It does not automatically test the security, resource use, API dependencies, or disruption behavior of each application deployed on it.

Workload conformance is already a certification operators can run. The working group is developing a standard and tooling. Its existence does not mean a stable, officially approved workload certification suite is available today.

A passing test proves that an application is production-ready. A repeatable test can verify only the requirements it covers. It cannot establish business correctness, every failure mode, or suitability for an organization’s service-level objectives.

The work requires one packaging or security vendor. The charter explicitly avoids mandating a particular delivery format, policy engine, scanner, or vendor tool. Workload conformance is intended to define behavior, not prescribe a product stack.

Related Articles

• Kubernetes architecture explained
• Kubernetes cluster monitoring
• Kubernetes deployment strategies
• Kubernetes Pod Security Admission

Changelog

• Initial publication. The working group is still defining its specification and upstream verification tooling.