Kubernetes in Depth · The wider CNCF ecosystem around it

The CNCF Project Landscape

Kubernetes did not arrive into an empty room. Google donated it to a brand-new Cloud Native Computing Foundation in 2015; it became the CNCF's first Graduated project in 2018; and every project that has joined since inherited a shared assumption — somewhere underneath, a Kubernetes API server is already running, and the sane way to extend the system is a controller watching it, the exact reconcile loop the controller pattern walked through early in this course. What grew up around that assumption is now a genuinely large ecosystem: delivery engines, service meshes, policy tools, observability pipelines, developer portals, each with its own governance, its own maturity level, and in seven cases, its own CNCF certification. This page doesn't re-derive any single project's mechanics — those live where this course, or a sibling course, already covers them in depth. It orients you in the landscape itself, so a name like Cilium or Kyverno stops being a logo on a slide and becomes a specific project, at a specific maturity level, with a specific page already waiting for it on this platform.

Kubernetes as the anchor tenant, not the whole neighborhood

☺ Like you're 10: A big anchor store draws smaller shops to build around it in the same mall. Kubernetes is the anchor store; everything else on this page is a shop that opened because it was already there.

A shopping mall's anchor tenant doesn't just occupy space — its foot traffic is the reason dozens of smaller stores are viable next door at all. Kubernetes plays exactly that role for the CNCF. Because a Kubernetes API server, an object model, and a CRD extension mechanism are already a safe bet to find running on any cluster, an entire ecosystem of independent projects could be built against that assumption instead of each reinventing its own control plane from scratch. A delivery tool doesn't need its own database of desired state — it watches Git and writes Kubernetes objects. A policy engine doesn't need its own enforcement point — it registers as an admission webhook the API server already calls. A service mesh doesn't need its own service registry — it reads the same Endpoints and Services this course's own Networking & the CNI already covers. The gravity runs one direction: everything below assumes Kubernetes; Kubernetes assumes nothing about any of it.

Three circles, not one: kubernetes-sigs, CNCF-hosted, and vendor product

☺ Like you're 10: Not every robot on the noticeboard belongs to the same club — some are the school's own robots, some joined a separate robotics league, and some are just a toy one company is selling.

A name showing up "in the Kubernetes world" doesn't tell you which of three genuinely different governance circles it sits in, and conflating them is one of the most common mistakes a newcomer to the ecosystem makes. The first circle is kubernetes-sigs: repositories owned by the Kubernetes project's own Special Interest Groups, living under the kubernetes-sigs GitHub organization, released on their own cadence but governed by the same steering committee and SIG process this course's own Control Plane Internals assumes — metrics-server and Cluster Autoscaler, both covered in this course's own Autoscaling page, are exactly this: part of the Kubernetes project itself, not separately CNCF-hosted, and carrying no maturity badge of their own because they don't need one — they inherit Kubernetes'. The second circle is an independently CNCF-hosted project: its own trademark, its own TOC-tracked maturity level, its own release cadence entirely decoupled from Kubernetes' — Argo, Cilium, Istio, Kyverno, Prometheus, OpenTelemetry, and Backstage all live here, each one a separate due-diligence review and, in most cases, a separate certification. The third circle is a vendor or member product: one company's roadmap, possibly proprietary, that may appear as a card on the CNCF's landscape map as a member listing without being CNCF-governed at all — a cloud provider's managed control-plane add-on is the common example. Karpenter is the case that proves the circles aren't fixed for life: it started life squarely in circle three, as AWS's own node-provisioning tool, before AWS donated it to the CNCF Sandbox in 2023 — the same tool, this course's own Autoscaling page covers, moved from circle three into circle two without a single line of its Kubernetes-facing behavior changing.

Sandbox → Incubating → Graduated, applied to the names already in this course

☺ Like you're 10: Three grades, rising in trust: brand-new and unproven, popular and depended-on, or voted Most Dependable by a real committee.

The CNCF sorts every project it hosts into one of three maturity levels, set by an elected Technical Oversight Committee after a due-diligence review — not by GitHub stars or marketing. Sandbox means early and experimental, with no promise the project survives to next year. Incubating means real production adoption by more than one organization and a genuinely multi-org contributor base. Graduated means mature, widely deployed, security-audited, and about as close to a safe default as the ecosystem offers. That's the compressed version; the full methodology — how the TOC actually evaluates a project, a six-lens scorecard for judging one yourself, build vs. buy vs. adopt, and the maintenance-tax math behind every tool you add — lives on Platform Engineering's own Cloud Native Landscape & Choosing Tools, and this page deliberately doesn't re-derive any of it. What this page adds instead is narrower and more useful for where you are right now: exactly where the names that keep appearing throughout this course's own pages currently sit, and exactly which page — here or on a sibling course — already covers each one's mechanics.

Seven projects, seven associate certifications

☺ Like you're 10: Seven of the projects above are popular enough that the CNCF built a whole exam just about that one tool, instead of folding it into a bigger test.

Most of the CNCF's catalogue tests broad knowledge — KCNA across the whole ecosystem, CNPA across the whole platform-engineering discipline. Seven certifications go the opposite direction: one project, examined properly. All seven sit at the associate tier — remote-proctored, multiple choice, no terminal — except ICA, which the Linux Foundation itself describes as a mix of hands-on and multiple-choice items, badged and priced like an associate but graded like something closer to CKA. Each one lives on Platform Engineering's certifications hub, where the full domain breakdown, weights, and a study plan already exist — this page only orients you toward the right one.

Kubestronaut vs. Golden Kubestronaut: two different finish lines

☺ Like you're 10: One badge is for collecting the five Kubernetes exams this course covers. The other badge wants sixteen, from every corner of the map, and it never expires.

This course's own certification ladder — KCNA, KCSA, CKA, CKAD, CKS — is exactly the five exams the CNCF recognizes as Kubestronaut: hold all five active at the same time and the CNCF awards a title, a digital badge, and the well-known jacket. It's a real finish line, and this course is built to get you there without ever leaving Kubernetes' own certifications. Golden Kubestronaut is a different, much larger finish line: every one of the CNCF's fifteen certifications — the five above, plus CNPA, CNPE, CGOA, and the seven project associates from the table further up — together with the Linux Foundation's own LFCS, sixteen exams in total, none of them a substitute for another. Everything past the five Kubestronaut exams — the project-specific associates, the platform-engineering pair, LFCS, and the full renewal mechanics that make Kubestronaut a subscription while Golden Kubestronaut is kept for life — is covered in full on the sibling Golden Astronaut course and on Platform Engineering's own certification landscape page; this page only shows where the two ladders meet.

Everything past this point is one project's own mechanics rather than the landscape they sit in — each project named above already has a full tool guide on Platform Engineering (linked throughout the table), and this course's own GitOps on Kubernetes, Networking & the CNI, Service Mesh Fundamentals, and Observability on Kubernetes cover the mechanism each one builds on top of. For the discipline of choosing between candidates in the same category, weighing build vs. buy vs. adopt, and not letting a curated stack turn into sprawl, Platform Engineering's Cloud Native Landscape & Choosing Tools is the page to read next. And if the goal really is every badge on the shelf, the sibling Golden Astronaut course is where the other nine CNCF certifications and LFCS live, in the same depth this course gives Kubernetes' own five.

Check your answers

1. Kubernetes is the CNCF's first and founding project, and every project built after it assumes a Kubernetes API server is already running — specifically, that the sane way to extend the system is a controller watching the API and reconciling, the same loop this course's controller-pattern page covers.
2. kubernetes-sigs (e.g. metrics-server, Cluster Autoscaler — governed by Kubernetes' own SIGs, no separate maturity badge); independently CNCF-hosted (e.g. Argo, Cilium, Kyverno — own TOC-reviewed maturity ladder); vendor/member product (e.g. a cloud provider's managed add-on, or pre-2023 Karpenter — one company's roadmap, no CNCF governance at all).
3. Sandbox (early, experimental, no adoption guarantee) → Incubating (real production use by multiple organizations) → Graduated (mature, widely adopted, security-audited). The CNCF's elected Technical Oversight Committee (TOC) decides, after a due-diligence review — not popularity or marketing.
4. Cilium's mechanism is covered in Networking & the CNI and Service Mesh Fundamentals; Kyverno is named across Best Practices, Anti-Patterns, and Cost & FinOps, with the underlying admission mechanism it builds on covered in RBAC & Admission Control.
5. Kubestronaut is 5 exams (KCNA, KCSA, CKA, CKAD, CKS); Golden Kubestronaut is 16 (all 15 CNCF certifications plus the Linux Foundation's LFCS). Kubestronaut has to be actively renewed — the title lapses at the end of the calendar year the first of the five expires. Golden Kubestronaut, once earned, is kept for life.
6. On Platform Engineering's Cloud Native Landscape & Choosing Tools page, which covers the TOC's evaluation process, a six-lens scorecard for judging a project yourself, build vs. buy vs. adopt, and the compounding maintenance tax of every tool you adopt — deliberately not re-derived on this page.