KCNA — Kubernetes and Cloud Native Associate
Reading the CNCF Map — Maturity, Delivery, Service Mesh
One-line summary
The hundreds of logos on the CNCF landscape are not something to memorize. If you group them by what problem each one solves, you can find a place for a new project when it appears. The maturity level is the community's signal about whether a project can be used in production now.
Why this was needed
Kubernetes is intentionally unfinished. Networking was pulled out to the CNI, the runtime to the CRI, and storage to the CSI. If the core did everything, it would be impossible to maintain and would be tied to particular implementations.
The price is the burden of choice. There is a lot to decide, from "which CNI should we use" to "which policy engine should we use." The CNCF is the foundation that provides neutral stewardship and maturity signals to this ecosystem.
How it works
The three project maturity levels
| Level | Meaning | Examples |
|---|---|---|
| Sandbox | Experimental. For early adopters. The API may break | New projects |
| Incubating | Has several production use cases and more varied committers | (varies over time) |
| Graduated | Mature. Has security audits, governance, and diverse contributors | Kubernetes, Prometheus, Envoy, containerd, etcd, Argo, OPA |
The level means the maturity of governance and adoption, not superiority of features. Sandbox does not mean poor performance, and Graduated does not mean it fits our situation. But it is useful as a risk signal for "will this project disappear while we are using it?"
Extension interfaces: how Kubernetes calls on others
- CRI: The container runtime (containerd, CRI-O)
- CNI: Networking (Cilium, Calico, Flannel)
- CSI: Storage (various drivers)
- CRD + controller: The way users extend the API itself
The last one is especially important. The Operator pattern is "defining a new resource kind with a CRD and attaching a controller that watches that resource, turning domain knowledge into code." It is a way of reusing Kubernetes' reconciliation loop for your own problem.
Delivery: CI and CD, and GitOps
CI is "build and test on every commit," and CD is "deploy the result automatically." GitOps flips CD once more.
- Instead of a pipeline pushing into the cluster,
- an agent inside the cluster keeps watching the Git repository and narrows the difference by itself (pull).
The Git repository is the desired state, and the agent reconciles like a controller. It is accurate to see it as extending Kubernetes' declarative model to organizational process. What you get is auditability (the commit log shows who changed what and when), drift detection (even if someone edits by hand, it returns to the original), and rollback (reverting a commit). Argo CD and Flux are the representative implementations.
Service mesh
It started from the demand to add retries, timeouts, mTLS, traffic splitting, and per-request observability without changing application code. The traditional implementation attaches a proxy (sidecar) to every Pod and passes all traffic through it.
The cost is clear: with one proxy per Pod, memory and latency grow, and there is one more component to operate. That is why a trend has recently emerged to do the same job without sidecars, using node-level proxies or eBPF (ambient mode and the like).
Open standards
- OpenTelemetry (OTel): A vendor-neutral specification and SDK for collecting and sending traces, metrics, and logs. Once you instrument, you do not change code when you swap backends.
- OpenMetrics: A standardization of the Prometheus exposition format.
- SPIFFE/SPIRE: A specification for issuing workloads a cryptographic identity (SVID). It replaces the outdated assumption that "the IP address is the identity." It is also the foundation that a service mesh's mTLS relies on.
What it looks like in practice
The author's homelab platform stack shows this map as a real thing. Networking is Cilium 1.20 (eBPF, no kube-proxy), the L4 load balancer is MetalLB (pool 10.0.0.200-215), storage is csi-driver-nfs + NAS, GitOps is ArgoCD, the registry is Harbor, observability is kube-prometheus-stack, the database is CloudNativePG (PostgreSQL 18, 2-instance streaming replication), and virtualization is KubeVirt v1.9.0. The point is that there is one plugged into each slot; reading the landscape slot by slot organizes it like this.
A place where version compatibility bites also came up for real. To use the Cilium Gateway API, Gateway API CRD v1.6.1 was needed. With v1.2, tlsroutes and referencegrants were not at v1, so the controller refused to start at all. "CRDs have API versions too, and if they do not match, the controller does not come up" is the reality of the extension model.
The most striking lesson came from KubeVirt. The status of every component was AllComponentsReady, yet the VM did not start. When they tore open the virt-launcher Pod spec, the volume mount holding the binary the init container was supposed to run was missing. To put the author's words as they are: "the status is Ready" and "it actually works" are different propositions, and it was a fact confirmed for the third time in that cluster alone. It is the shortest explanation of why observability does not end with a single status field.
What to read next
This module has no lab. In the reading that follows, you organize the signals of observability, and you finish the course with the final quiz.