Kubernetes AI Conformance Moves Into SIG Architecture

Every vendor will sell you "AI-ready Kubernetes". Kubernetes AI Conformance is the closest thing to a neutral way to check that claim, and on October 29 the Kubernetes project made it a permanent part of its governance.

What happened to Kubernetes AI Conformance

A Kubernetes blog post from October 29 says the AI Conformance working group has been archived and the program now lives as a permanent subproject under SIG Architecture. Working groups are temporary by design. This one existed to publish the first requirements and get certification running, and it did both. The subproject's goal is to keep the standards current and vendor-neutral.

The post describes a change of owner, not a new certification process. For scale, the CNCF said on March 24 that certified platforms had grown from 18 to 31 since the November 2025 launch. I found no newer count.

Two days earlier, the project announced a separate Workload Conformance Working Group. AI Conformance asks whether a cluster can run AI workloads. The new group is drafting a standard for how workloads behave at runtime, with a specification per Kubernetes minor version, a way to test each requirement, and upstream tooling. It has not yet agreed on specific requirements or tests, so there is nothing to certify against. Keep it out of this quarter's RFP.

What the program asks of a GPU platform

The prerequisite is base Kubernetes conformance. On top of that, the program tests infrastructure capabilities, such as accelerator support through Dynamic Resource Allocation (DRA), not specific AI frameworks or model servers. New requirements start as recommended SHOULD items and become mandatory MUST once the APIs stabilize and adoption follows.

The v1.37 checklist has 15 requirements, 8 MUST and 7 SHOULD:

| Area | MUST | SHOULD | | --- | --- | --- | | Accelerators | none | driver and runtime management, GPU sharing, virtualized accelerators | | Networking | Gateway API for inference traffic | advanced inference ingress, high-performance networking, disaggregated inference | | Scheduling | gang scheduling, cluster autoscaling, pod autoscaling | none | | Observability | accelerator metrics, AI service metrics | none | | Security | secure accelerator access | workload sandboxing | | Operator support | a complex CRD-based AI operator (Ray or Kubeflow, for example) installs and runs reliably | none |

Two details matter when you read a vendor slide. Accelerators have no MUST, so "certified" says nothing about GPU sharing. And the only MUST that accepts N/A is cluster autoscaling, for platforms without a cluster autoscaler. Any other N/A is rejected.

Audit a Kubernetes AI Conformance claim before you sign

Certification is a self-assessment: a checklist plus links to public evidence. CNCF review typically takes up to 10 business days. From v1.37, the repo recommends automated test artifacts where tests exist, and names Secure Accelerator Access and Gang Scheduling. The March announcement lists third-party validation through a verification bot as a 2026 roadmap item, not something shipped.

Submissions are public, so you can read them yourself:

git clone https://github.com/cncf/k8s-ai-conformance.git
cd k8s-ai-conformance

# Which products are certified for a given Kubernetes version?
ls v1.36/

# What exactly did the vendor certify?
cat v1.36/<product-dir>/PRODUCT.yaml

# When did that submission land?
git log --format='%cs %s' -- v1.36/<product-dir>/PRODUCT.yaml

# The current checklist: requirement ids and MUST/SHOULD levels
grep -n -E 'id:|level:' docs/AIConformance-1.37.yaml

Replace <product-dir> with the vendor's folder, such as gke or openshift. In PRODUCT.yaml, compare kubernetesVersion and platformVersion with what you would actually run, and follow k8sConformanceUrl to the base conformance entry. Then open the evidence links on the requirements you care about.

Gotchas

• Certification applies to a specific platform version. A new or materially modified version is a separate platform and must be certified separately.
• It is also per product and per configuration. The FAQ's example is cloud versus air-gapped.
• The program's terms say certification is valid for one year from the date the checklist pull request is merged. Sources describe renewal differently, so check the terms file in the repo.
• Evidence can be documentation rather than a test run. Read it.

What to do on Monday morning

Put three lines in your next platform questionnaire: link the merged submission, state the certified Kubernetes and platform versions, and name which SHOULD items the vendor actually runs. Then ask for the same evidence on any GPU cluster you already operate. If you run a service desk or an internal platform, you now have a shared checklist to hold providers to in the contract.

If you deploy AI in production, a neutral, versioned checklist that now has a permanent owner is a better basis for platform decisions than a vendor's "AI-ready" badge.