Kubernetes AI Conformance: What the KARs Demand of a Platform

A vendor page said Certified Kubernetes AI Platform, and I wanted to know what that sentence promised before repeating it to anyone. The CNCF announcement of 24 March 2026 says certified offerings grew from 18 at the November 2025 launch to 31, but a count of badges does not tell you what each badge means. So I skipped the press release and read the checklists.

This post is built from the cncf/k8s-ai-conformance repository (the v1.35 and v1.37 checklists, the submission instructions and the FAQ), the upstream kubernetes-sigs/ai-conformance repository (the KAR process and the test suite README) and the CNCF announcement. I diffed the two checklist files myself. I did not run the conformance suite against a cluster, and where a claim comes only from the announcement I say so.

What the badge certifies, and what it does not

Certification is per product and per configuration, and the FAQ gives the example that a cloud deployment and an air-gapped one are different configurations. A platform must already be Kubernetes conformant before it can be AI conformant. A certification is valid for one year and must be renewed, and CNCF review typically takes up to 10 business days after the pull request is opened.

The program defines the capabilities a cluster must offer to run AI and ML workloads, and it covers training, inference and agentic workloads together, on purpose, to avoid fragmentation. Its stated goals are interoperability and portability. That is a statement about the platform, not about your model server, your GPUs or your latency, and the rest of this post keeps returning to that distinction.

How a KAR is born: SHOULD first, MUST later

A Kubernetes AI conformance Requirement, or KAR, is a numbered proposal in kubernetes-sigs/ai-conformance. The README says each KAR starts at SHOULD and is meant to graduate to MUST in step with the KEP process in each Kubernetes release. Requirements are versioned per release in a conformance-versions file, which must be merged before code freeze and then copied into cncf/k8s-ai-conformance. The README marks requirement removal criteria as TBD, so nobody has yet written down how a requirement leaves.

Two rules matter for anyone planning ahead. Every requirement needs a test design in the KAR, specific enough to automate, and from v1.37 an automated test is a prerequisite for new SHOULDs and MUSTs. And no new requirements are accepted after KEP and KAR freeze. The announcement names three KARs that arrived with the v1.35-based update: KAR-10 high-performance pod-to-pod communication, KAR-11 advanced inference ingress and KAR-41 disaggregated inference support.

The v1.35 to v1.37 checklist, requirement by requirement

I diffed AIConformance-1.35.yaml against AIConformance-1.37.yaml. The v1.35 file has 12 requirement ids, 9 of them MUST. The v1.37 file has 15, 8 of them MUST. Everything outside the rows marked as changed in the table below is identical between the two files, apart from the header comment and the metadata block.

Two readings are worth making explicit. First, dra_support was a MUST in the v1.35 file and does not appear in the v1.37 file. I can see the removal in the diff but I could not find a source that explains it, so I am not going to guess. Second, the announcement says certified platforms must support Stable In-Place Pod Resizing and Workload-Aware Scheduling. Neither name appears as an id in either checklist, and the nearest id is gang_scheduling, so treat the press release as a summary and the YAML as the spec.

What a submission actually looks like

A submission is a pull request that adds vX.Y/dir/PRODUCT.yaml, plus optional test artifacts, under a directory named for your product. The fields id, description and level must not be changed. You fill in status, evidence and notes, and for every MUST all three need addressing. The vendorName must exactly match your name in the CNCF Members list on the landscape, and the legal entity needs a signed participation form on file. Here is a trimmed example in that shape, with a fictional vendor.

# vX.Y/$dir/PRODUCT.yaml, trimmed to the fields that decide the review.
# id, description and level are copied from AIConformance-1.37.yaml and must
# not be edited; only status, evidence and notes are yours to fill in.
metadata:
  kubernetesVersion: v1.37
  platformName: Acme GPU Cloud        # the product, not the Kubernetes version
  platformVersion: v4.2.0
  vendorName: Acme Ltd                # must match your CNCF Members landscape name exactly
  k8sConformanceUrl: https://github.com/cncf/k8s-conformance/tree/master/v1.37/acme-gpu-cloud

spec:
  schedulingOrchestration:
    - id: gang_scheduling
      level: MUST
      status: Implemented
      evidence:
        - "file://v1.37/acme-gpu-cloud/junit.xml#TestGangScheduling"
        - "file://v1.37/acme-gpu-cloud/e2e.log"
    - id: cluster_autoscaling
      level: MUST
      status: N/A                     # the one MUST that accepts N/A today
      notes: "Air-gapped configuration: nodes are racked, there is no autoscaler to observe."
  security:
    - id: workload_sandboxing
      level: SHOULD
      status: Implemented
      evidence:
        - "https://docs.acme.example/runtime-classes/gvisor"   # manual attestation, no URL = no credit

Evidence is either a public URL or, from v1.37, a file reference into the artifacts in your submission directory. That is the hybrid model: requirements with an automated test are recommended to be verified with the upstream suite, and the rest rely on documentation or reference URLs. A requirement with no evidence is a claim, and the reviewer is the only check on it.

The test suite, and the green run that skipped

The upstream suite in kubernetes-sigs/ai-conformance covers five tests: TestSecureAcceleratorAccess, TestGangScheduling, TestAcceleratorClusterAutoscaling and TestRobustCRDControllerOperation for MUST requirements, and TestWorkloadSandboxing for a SHOULD. That is five of the 15 requirements. Gateway routing, both metrics requirements, HPA and the three new inference requirements have no automated test in that list, so they stay on documentation.

# Run the upstream suite at the tag that matches your cluster, from a checkout
# of kubernetes-sigs/ai-conformance. Needs cluster-admin on the target cluster.
export KUBECONFIG=$HOME/.kube/acme-gpu.yaml

# The four MUST tests plus the one SHOULD test; names are from test/README.md.
go test -v ./test -timeout 75m \
  -sandbox-runtime-class=gvisor \
  -autoscaler-node-pool-label=<your-pool-label> \
  | tee e2e.log

# Trap: with no -autoscaler-node-pool-label the autoscaling test is SKIPPED, and
# go test still exits 0. Read the log, do not trust the exit code.
grep -E '^(--- (SKIP|FAIL)|=== RUN)' e2e.log

# The two machine-readable artifacts the submission directory can carry.
go test -v ./test -json > results.json
go run gotest.tools/gotestsum@latest --junitfile junit.xml -- ./test

# Hermetic unit tests that need no cluster and no accelerators.
go test -v -short ./test

The prerequisites are strict. Autoscaling needs a running cluster autoscaler and an isolated accelerator pool with minimum size N of at least 1, maximum size at least N plus 1, scale-down enabled and one stable node label, and the README recommends a timeout of 75 minutes or more. The sandbox test needs a RuntimeClass such as gVisor or Kata and runs the same probe in a plain control pod pinned to the same node, checking process, kernel and memory, filesystem and network isolation.

Where conformance stops: four limits

A badge compresses a lot of caveats. These are the four I would want a procurement reviewer to know, each taken from the program's own documents.

• SHOULD is optional. Seven of the 15 v1.37 requirements are SHOULD, and that includes inference ingress, disaggregated inference, high-performance networking and sandboxing, which are the ones agent and LLM serving teams care about most.
• No performance floor. In the review thread for KAR-10 the maintainers agreed that specifying thresholds was impractical, and the proposed test checks that two pods on secondary interfaces can transfer data, not how fast. Conformant does not mean fast.
• Layers do not inherit. The FAQ says building on a conformant distribution does not make the layered platform conformant, that a layered product must re-test, and that it must uniquely contribute at least one feature. Ask which layer owns each requirement.
• N/A is narrow. The justification cannot be that the platform does not support the feature, and on a MUST it is accepted today only for cluster_autoscaling. The pod_autoscaling text is also conditional on HPA support, but the instructions name only the cluster autoscaler.

None of this is a flaw in the program. A conformance suite exists to make a floor testable, and the FAQ is candid about what it does not claim. The risk sits with the reader who treats a floor as a ranking.

Where the program is heading in 2026

The announcement describes a move from self-assessment toward automated conformance testing, including a Verify Conformance Bot for third-party validation, and says Sovereign AI standards focused on sandboxing and data privacy are planned for later in 2026. The repository already points that way: the v1.37 checklist and instructions introduce the hybrid model, and the test suite ships a sandboxing test.

The announcement also cites CNCF's AI Tech Radar report, which says 41 percent of AI developers identify as cloud native. I would not lean on that number for any decision, since it describes a survey population rather than a platform property, but it explains why the program is moving quickly. Plans in a press release are plans, so check the repository before you rely on a date.

What to do on Monday

Whether you are buying a platform or certifying one, the work is reading and running, not trusting a logo.

1. Buying: ask for the exact vX.Y/dir/PRODUCT.yaml in cncf/k8s-ai-conformance and read it, not the vendor's landing page. Check the Kubernetes version and the configuration it covers.
2. Search that file for N/A and Partially Implemented, and for SHOULD rows marked Implemented without an evidence URL. Those are where the badge is thinnest.
3. Certifying: run the upstream suite at the tag matching your cluster, with the sandbox runtime class and autoscaler pool label set, and read the log for SKIP lines.
4. Map every requirement to the layer that owns it, and write that mapping into notes before the reviewer asks.

# Monday, step 1: read what your vendor actually claimed, per Kubernetes version.
git clone --depth=1 https://github.com/cncf/k8s-ai-conformance.git
ls k8s-ai-conformance/v1.36/          # one directory per certified product
ls k8s-ai-conformance/docs/           # AIConformance-1.35.yaml .. 1.37.yaml

# Step 2: find every requirement the vendor answered with N/A or Partially Implemented.
grep -nE 'status: *("?N/A|"?Partially)' -B3 k8s-ai-conformance/v1.36/*/PRODUCT.yaml

# Step 3: diff the checklist you were promised against the one now in force.
diff k8s-ai-conformance/docs/AIConformance-1.35.yaml \
     k8s-ai-conformance/docs/AIConformance-1.37.yaml | grep -E '^[<>] +- id:'

The commands below do the reading and the diffing. Clone the repository shallowly, list what a vendor filed, and compare the checklist you were promised with the one in force today.

Read AI conformance as a published floor with a named owner for each rung: the YAML tells you what was claimed, the test suite tells you what was checked, and everything else is attestation. When a vendor shows the badge, ask for the PRODUCT.yaml, the Kubernetes version, the configuration and the list of requirements that were skipped or answered N/A.