Every few months, a new set of AI categories appears on the CNCF landscape. On 28 October 2026 the landscape data included categories for Inference, Training, AI Agent and AI Native Infra, each filling up with projects and products. For a platform team that already runs Kubernetes, the question is obvious: should AI workloads run on the same platform?
Sometimes, yes. Kubernetes has gained genuinely important capabilities for accelerated workloads, and several AI projects have reached real maturity. But this is also the part of the landscape where levels move fastest, where some of the most important projects are not CNCF projects at all, and where the hardware you need may not be available in the region you have to use.
CloudNala's position is that AI on Kubernetes should be adopted with the same capability-first discipline as the rest of the platform, with extra attention to where each project is hosted, what level it holds, and whether the accelerators exist where your data has to stay. Self-hosting is a choice to make deliberately, not a default because the cluster already exists.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab's data team wants to run demand forecasting models and a product-search assistant. The platform team has been asked whether both should run on the existing Kubernetes clusters.
What we checked
Each item below was checked against primary sources on 28 October 2026.
The Kubernetes AI Conformance programme. The CNCF launched the Certified Kubernetes AI Conformance programme in November 2025. It defines capabilities a Kubernetes platform needs to run AI workloads reliably, across areas the programme lists as accelerators, networking, scheduling, observability, security and operator support. In March 2026 the CNCF said the number of certified platforms had grown from 18 at launch to 31, that validation now covered agentic workloads, and that certification required alignment with Kubernetes v1.35. The programme's repository says certification has so far been based on a documented self-assessment, with a hybrid model that adds automated tests for some requirements from v1.37. Certifications are per product and configuration, and valid for one year. The repository holds submissions from many platforms, including AKS, EKS and GKE.
Dynamic Resource Allocation. Kubernetes v1.34, released in August 2025, graduated the core Dynamic Resource Allocation (DRA) APIs to stable. DRA gives Kubernetes a richer way to request and share devices such as GPUs than the older device plugin model. Stable APIs still depend on drivers from hardware vendors, so check what your provider and accelerator support.
Kubeflow. The CNCF announced Kubeflow's graduation in August 2026. Kubeflow is a collection of components for the machine learning lifecycle on Kubernetes, including pipelines, training operators, notebooks and a model registry.
KServe. KServe, a model serving platform that grew out of the Kubeflow ecosystem, is a CNCF Incubating project, listed as accepted on 29 September 2025.
llm-d. llm-d, a Kubernetes-native framework for distributed large language model inference, was accepted into the CNCF Sandbox in March 2026.
Ray and vLLM. Ray, the distributed computing framework, joined the PyTorch Foundation in October 2025, and its announcements describe it sitting alongside PyTorch and vLLM, the inference engine. KubeRay, Ray's Kubernetes operator, is part of the Ray project. None of these carry a CNCF maturity level, because the CNCF does not host them.
Reading these levels sensibly
Three points follow from that list.
A missing CNCF level is not a red flag. Ray and vLLM are among the most widely used tools in AI infrastructure. They are governed by a different Linux Foundation umbrella. To assess them, look at the PyTorch Foundation's governance and the projects' own maintainer and security practices, using the same scorecard criteria from Part 3.
Conformance is about the platform, not your region. An AI-conformant managed Kubernetes product tells you the platform supports the required capabilities. It does not tell you that suitable accelerators are available in the region your data must stay in. When we checked Google Cloud's Compute Engine zone table on 28 October 2026, it listed no GPU machine families for the three Johannesburg zones. Check accelerator availability in each South African region directly, on the day you decide, rather than assuming it from a global announcement.
Sandbox means experiment. llm-d addresses a real problem and has significant industry backing. It is also, by the CNCF's own definition of the level, early. Baobab would trial it in a non-production cluster and not build a customer-facing service on it yet.
Managed AI service or self-hosted?
Baobab works through the same staircase as Part 4, with four AI-specific questions added.
| Question | Points towards managed | Points towards self-hosting on Kubernetes |
|---|---|---|
| Do we need open-weight or custom models? | No, a hosted model will do | Yes, we must run our own weights |
| Where must data and inference stay? | The provider runs suitable models where we need them | Only our own infrastructure meets the requirement |
| Do accelerators exist where we need them? | We cannot get them in-region at sensible cost | We can, with capacity we can rely on |
| Do we have the skills? | Not yet for model serving at scale | Yes, at least two people per layer |
Demand forecasting came out as self-hosted on Kubernetes. The models are classical, they run on CPUs, they need Baobab's sales data, and the team already runs batch jobs on the clusters. Kubeflow Pipelines, from a Graduated project, was the obvious candidate to evaluate first.
The product-search assistant came out as managed, for now. It needs a large language model, Baobab has no requirement for its own weights, and self-hosting would need GPU capacity the team could not confirm in its region and serving skills it does not yet have. The decision record lists the conditions under which it would be revisited: in-region accelerators at a cost Baobab can carry, a requirement to run open-weight models, or two engineers with production model-serving experience.
For the governance side of promoting AI services, Every AI pilot needs a graduation path applies a lifecycle with evidence gates to exactly this kind of decision.
How to watch the landscape for change
This series has repeatedly said levels change. The final practical step is to notice when they do. Baobab watches for five signals across every component it runs.
A project is archived. The CNCF archives projects that are no longer active. OpenTracing and Open Service Mesh both appear in the archived list. An archived component in production needs a replacement plan, and Archived does not mean failed covers how to retire one responsibly.
A retirement is announced. Ingress NGINX was a Kubernetes subproject rather than a CNCF project with a level of its own, but its retirement, announced in November 2025 for March 2026, is the clearest recent example of why announcements matter more than levels. Users who noticed on the day had four months to plan. Those who did not are now running an ingress controller with no security fixes.
A level moves up. OpenTelemetry, Kyverno and Kubeflow all graduated during 2026. A move up is a good moment to revisit scorecards where the project lost narrowly.
A project changes foundation. Ray's move into the PyTorch Foundation changed its governance home. That is not a problem, but your assessment should reflect who governs it now.
A provider version ends. Managed Kubernetes services publish end-of-support dates for each version. These arrive on a schedule, and missing them can mean extra charges or an upgrade on the provider's timetable.
The mechanics are simple. Baobab follows CNCF announcements and the release feeds of each component it runs, and a named engineer reviews them weekly. Each component's support ledger, introduced in Part 2, carries its CNCF level and the date it was last checked. A quarterly review re-checks every level against the CNCF project pages, because the landscape itself changes daily.
The series in one paragraph
The CNCF landscape is a map, not a recommendation. Read it after naming the job, and filter to what is actually CNCF-hosted (Part 1). Treat graduation as strong evidence about governance and no evidence about your support (Part 2). Choose with a weighted scorecard set before the debate (Part 3). Decide managed or self-hosted per component, with residency treated as a data flow question (Part 4). Build the minimum platform around Kubernetes in stages (Part 5). And for AI, check where each project lives and whether the hardware exists where you need it.
Back to Part 1, How to read the CNCF landscape without buying a logo wall. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations decide which AI workloads belong on their cloud-native platform and which belong on managed services. We assess candidate projects and their governance, check accelerator and service availability in the regions you can use, and set up a lightweight way to watch for level changes, retirements and support deadlines across your estate. Our guidance is independent and based on public sources checked at the time of the work.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Cloud Native Platform Review or write to us at consult@cloudnala.co.za