The CNCF Landscape and Project Maturity

Cloud Native Architecture / Guide 35 of 46 / Beginner

• Kubernetes1.36.4
• containerd2.2.6
• etcd3.6.8
• TimeAbout 17 min
• Reviewed22 August 2026

Written against the versions above. Project versions are whatever this cluster happens to run. The point is the method, which does not change: ask the cluster instead of the poster.

Before you start

• Any cluster with a CNI plugin and at least one operator installed. A bare kubeadm cluster shows the built-in half only.

1. 1

   How much of the API is not Kubernetes

   api-resources lists every kind the API server currently serves. get crd lists the ones that were added by something you installed.

   161 resources, 71 of them custom. Nearly half of this cluster's API surface was installed rather than shipped, and grouping the CRDs by their API group names the projects responsible: Calico brought 22, the Prometheus operator 10, Tigera's operator 9, MetalLB 8, two Gateway implementations 6 each, the CSI snapshot controller 6, Argo 3.

   This is what the CNCF landscape looks like from inside a cluster. Not a wall of logos - a list of API groups, each one traceable to the thing that installed it.

   $kubectl --context cka1001 api-resources --no-headers | wc -l161$kubectl --context cka1001 get crd --no-headers | wc -l71$kubectl --context cka1001 get crd --no-headers | awk '{print $1}' | sed 's/^[^.]*\.//' | sort | uniq -c | sort -rn     22 crd.projectcalico.org     10 monitoring.coreos.com      9 operator.tigera.io      8 metallb.io      6 gateway.nginx.org      6 gateway.networking.k8s.io      3 snapshot.storage.k8s.io      3 groupsnapshot.storage.k8s.io      3 argoproj.io      1 policy.networking.k8s.io

   Expected resultA total resource count, a CRD count, and CRDs grouped by API group with counts.

   Success conditionYou can say how much of your API surface came from outside Kubernetes.

2. 2

   The graduated projects you are already running

   KCNA asks about CNCF graduated projects. Five of them are running here right now, and each will tell you its own version.

   containerd is the runtime on every node, reported by the kubelet itself. etcd is the datastore, running as a static Pod. Helm is a client binary, so it answers locally. Prometheus and Argo CD report through their workload images. Calico appears too - CNI is the CNCF-hosted specification, while Calico itself is the implementation.

   Reading versions off running workloads is worth the habit for its own sake. It is how you answer "what is actually deployed" without trusting a wiki page.

   $kubectl --context cka1001 get nodes -o custom-columns=NAME:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersionNAME             RUNTIMEcka1001          containerd://2.2.6cka1001-node01   containerd://2.2.6cka1001-node02   containerd://2.2.6cka1001-node03   containerd://2.2.6$kubectl --context cka1001 -n kube-system get pod -l component=etcd -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.spec.containers[0].image}{"\n"}{end}'etcd-cka1001  registry.k8s.io/etcd:3.6.8-0$helm version --shortv4.1.3+gc94d381$kubectl --context cka1001 -n argocd get deploy argocd-server -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'quay.io/argoproj/argocd:v3.5.1$kubectl --context cka1001 -n monitoring get statefulset -o custom-columns=NAME:.metadata.name,IMAGE:.spec.template.spec.containers[0].image --no-headersalertmanager-kps-kube-prometheus-stack-alertmanager   quay.io/prometheus/alertmanager:v0.34.0prometheus-kps-kube-prometheus-stack-prometheus       quay.io/prometheus/prometheus:v3.14.0-distroless$kubectl --context cka1001 -n calico-system get daemonset calico-node -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'quay.io/calico/node:v3.32.1

   Expected resultA version string for each project, taken from the cluster rather than from documentation.

   Success conditionFive graduated projects identified by their own reported versions.

3. 3

   Why the count is the useful part

   47 controllers and 91 Pods to run four nodes' worth of platform.

   That ratio is the honest summary of cloud native architecture, and it is what the exam is really testing when it asks about the landscape. Every project you adopt arrives as controllers, CRDs and Pods that you now operate. Calico's 22 CRDs are not free; neither are the Prometheus operator's 10.

   So the useful question about any landscape entry is not "what does it do" but "what does it add to this list". A cluster is a budget of operational surface, and installing a project spends some of it.

   $kubectl --context cka1001 get deploy,daemonset,statefulset -A --no-headers | wc -l47$kubectl --context cka1001 get pods -A --no-headers | wc -l91

   Expected resultA controller count and a Pod count for the whole cluster.

   Success conditionYou can state the operational cost of the platform in objects rather than in adjectives.

4. 4

   Who governs the things you just counted

   The projects are named. The last question KCNA asks is who decides what happens to them - and the answer is different for each of the five in this list.

   Argo CD (applications, applicationsets, appprojects) is a CNCF graduated project. Graduated is the top of three maturity levels - sandbox, incubating, graduated - and it means the CNCF's Technical Oversight Committee has signed off on adoption, governance, security review and a committer base spread across multiple employers. containerd, etcd, Helm and Prometheus from the previous step are all graduated too.

   Prometheus Operator (prometheuses, servicemonitors, alertmanagers, and seven more) is not the same thing as Prometheus. Prometheus is graduated; the operator is a separate project in the same organisation. A CRD group tells you which codebase to file an issue against, not which project graduated.

   MetalLB (ipaddresspools, l2advertisements, bgppeers) is CNCF sandbox - accepted, early, and explicitly not a recommendation. Sandbox is where a project goes to be seen, not to be trusted.

   Gateway API (gateways, gatewayclasses, httproutes, grpcroutes) is not a separate project at all. It is developed by SIG-Network, one of the Kubernetes project's own Special Interest Groups, which is why its group is gateway.networking.k8s.io and not a vendor domain. SIGs are how Kubernetes itself is governed: each owns an area, holds public meetings, and its decisions land in KEPs - Kubernetes Enhancement Proposals.

   Calico (ippools, felixconfigurations, globalnetworkpolicies and nineteen more) is the interesting one: it is not a CNCF project. It is open source, maintained by Tigera, and it implements CNI - which *is* a CNCF project. The CNCF-hosted CNI implementation is Cilium. So the largest single contributor of CRDs to this cluster sits outside the foundation entirely.

   That distinction is the practical content of this competency. "Cloud native" is not a synonym for "CNCF-hosted", a CRD group is a domain name and not a badge of governance, and the only way to know which you are adopting is to look it up in the CNCF landscape rather than infer it from the API.

   $kubectl --context cka1001 get crd -o custom-columns=NAME:.metadata.name --no-headers | grep -E 'argoproj|monitoring.coreos|projectcalico|gateway.networking|metallb' | sed 's/\..*//' | sort | uniq -c      1 applications      1 applicationsets      1 appprojects      1 felixconfigurations      1 gatewayclasses      1 gateways      1 globalnetworkpolicies      1 httproutes      1 ipaddresspools      1 ippools      1 l2advertisements      1 prometheuses      1 servicemonitors

   Expected resultThe CRD names of five projects, flattened out of their API groups.

   Success conditionYou can say which of the five is graduated, which is sandbox, which is a Kubernetes SIG, and which is not CNCF at all.

Troubleshooting

• get crd returns nothing.

  Why: A cluster with no operators or CNI CRDs installed - a fresh kubeadm control plane with no add-ons.

  Fix:Nothing to fix. Install a CNI plugin or an operator and run it again; the built-in resource count from step 1 is still meaningful on its own.

• The API group in a CRD name does not obviously identify a project.

  Why: Vendor groups do not always match project names. operator.tigera.io is Calico's operator; monitoring.coreos.com is the Prometheus operator.

  Fix:kubectl get crd <name> -o jsonpath='{.spec.group}' then look at which Deployment owns the controller for it.

• You need to know whether a project is CNCF-hosted, and at what maturity.

  Why: Nothing in the cluster reports it. A CRD's API group is a DNS name its authors chose - projectcalico.org and argoproj.io look equally official from inside Kubernetes.

  Fix:Look it up in the CNCF landscape (landscape.cncf.io) or the graduated/incubating list. Sandbox, incubating and graduated are the three levels, and only graduated implies the TOC's due diligence on governance and security.

Official sources

• CNCF graduated and incubating projects
• Custom resources
• Container runtimes
• CNCF - Graduation criteria and maturity levels
• Kubernetes community - Special Interest Groups