Quick facts
- Program: CNCF Kubernetes AI Conformance, Kubernetes v1.35
- Version: Cozystack v1.6.1
- Accepted: 14 September 2026
- Requirements: 12 of 12 implemented
- Evidence: cozystack.io/compliance/ai-conformance/
When a GPU cloud or an enterprise ML team shortlists platforms, one of the first filters is now a list kept by the CNCF: which Kubernetes platforms have shown that they provide what AI workloads actually depend on. Being missing from that list says “unverified”, whatever the platform can do. Since 14 September 2026, Cozystack is on it: version 1.6.1 was accepted into the CNCF Kubernetes AI Conformance program for Kubernetes v1.35, with all 12 requirements implemented.
The v1.35 list includes GKE, EKS, AKS, OpenShift, RKE2, Rafay and k0rdent among others — the platforms our customers compare us with.
What the program checks
Plain Kubernetes conformance answers whether a cluster behaves like Kubernetes. AI Conformance asks a narrower, more practical question: can you run training and inference on it without assembling the missing pieces yourself? Its twelve requirements cover how accelerators are exposed, shared and kept with the right drivers, how inference traffic is routed, whether a distributed job can be scheduled all at once or not at all, whether node pools with GPUs scale with demand, whether operators for frameworks like Ray work with their webhooks and custom resources, and whether accelerator and workload metrics reach the monitoring stack.
Nine of the requirements are met by how Cozystack is configured out of the box. The other three we proved by running them on a tenant cluster with Kubernetes v1.35.6:
- Inference traffic. Through the Gateway API with Cilium, a weighted 80/20 split between two model versions sent 26 of 30 requests to the first and 4 to the second, and header-based routing sent requests to the version named in the header.
- Gang scheduling. With Kueue and a queue quota of two CPUs, a job of two pods was admitted whole; a job of four pods that did not fit the quota stayed at zero pods instead of starting half of them and holding the resources.
- Operators. Kueue’s controller and webhooks and KubeRay brought a Ray cluster to ready.
What we wrote down as limitations
Conformance submissions are public, and we kept ours honest. Two points are recorded in it as they are. The default KubeRay installation does not deploy its own webhooks, so the webhook part of the operator requirement rests on Kueue, whose mutating webhook suspends batch jobs until they are admitted. And Dynamic Resource Allocation is served by the API, but no DRA driver is installed, so device classes and resource slices stay empty until a driver is added.
The full evidence, requirement by requirement, is on cozystack.io, and our overview of Cozystack’s conformance results is on the Kubernetes conformance page.
What it means for Ænix customers
Every tenant cluster on the Ænix AI Platform and the other Ænix platforms is created by the same Cozystack engine that passed the program, so the capabilities checked here are the ones you get. For a GPU cloud selling capacity to its own customers, this is the mark tenders increasingly ask for; how such a cloud is built on Cozystack is described on the GPU as a service page.
The submission was prepared by Ænix engineers for the Cozystack project, which Ænix created and co-maintains with maintainers from other companies.



