The goal of the CNCF is to help organizations build scalable applications across public, private, and hybrid clouds. Support that takes different forms: from technologies to events, here is what the Cloud Native Computing Foundation does.
It is easy to say “Cloud Native”; adopting this paradigm is far less simple for organizations deciding to innovate their IT ecosystem. The CNCF was established precisely to address this challenge.
When deciding to embrace Cloud Native, several questions naturally arise:
How do you evaluate the reliability and security of a tool? The CNCF Landscape brings together hundreds of projects, and most of them will never reach production anywhere. Before adopting one, look at its CNCF maturity level (sandbox, incubating, graduated), how many active maintainers it has, and how frequently security patches are released: in our experience, these are the three indicators that best predict whether that component will still be maintained two years from now.
How do you understand where Cloud Native is heading? Innovate, yes, but with tools and methodologies already validated in the field, with documented reliability and proven compatibility with interoperability standards.
How do you select the best technology partners, those who truly possess the skills to work with these tools? A vendor that learns Kubernetes on your project makes you pay for it twice: in calendar months and in architectural debt that must be rewritten.
The answer arrived in July 2015, alongside the release of Kubernetes 1.0: the Linux Foundation, the foundation created to standardize Linux and support its growth and adoption, announced the establishment of the CNCF. Google transferred Kubernetes to the new foundation as its founding project: that transfer of ownership launched the growth of the ecosystem we manage every day in production clusters. The idea was as simple as it was effective: create a focal point for the Cloud Native world, a neutral space where projects, vendors, and the people who use those technologies every day could converge.
A meeting point between open source projects and big tech
The project launched by the Linux Foundation takes the name of Cloud Native Computing Foundation, or CNCF for short. Today it is the place where some of the most critical open source technologies (to name a few, Kubernetes and containers) meet the leading players in the tech world. Developers, major tech companies, and enterprises implementing the Cloud Native paradigm: all gravitate around the CNCF.
In practice, as the CNCF explicitly states, the project’s purpose is to “build a sustainable ecosystem for Cloud Native software”.
The history of the Cloud Native Computing Foundation
The Foundation’s history is distinctive. And it could hardly be otherwise, because the CNCF was born within the Linux Foundation through the initiative of Silicon Valley giants. The founding moment dates back to 2015, when Google, which had until then led the internal development of Kubernetes, the open-source container orchestration and management system, decided to hand over its stewardship to the Linux Foundation. The Kubernetes project had reached maturity with version 1.0 and had already proven to be one of the key technologies of global infrastructure: far too important to remain within the boundaries of a single company. Ten years later, in 2025, the Foundation celebrated its tenth anniversary with over 800 members and more than 200 hosted projects, according to official CNCF landscape data.
The Linux Foundation agreed to launch the CNCF project with the goal of “making Cloud Native ubiquitous”, immediately involving many large enterprises. Alongside Google (which led the initial phase before leadership transitioned permanently to the Governing Board and the Technical Oversight Committee, the bodies that still decide on memberships and projects today), other early participants included CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, IBM, Docker, Univa, and VMware.
Today, CNCF members include over 800 companies and organizations worldwide, including us at SparkFabrik. This is a crucial point, as we will see shortly, because participating in the technical working groups where the technology standards for the internet’s core infrastructure are defined is vital for anyone operating in this industry.
CNCF projects
It would be limiting to think of the CNCF as merely a vehicle that contains a single technology, Kubernetes. Even though, given the role Kubernetes plays in developing the Cloud Native ecosystem, that alone would hardly be minor.
Within the CNCF, there are numerous projects organized across three progressive levels of technological maturity: Sandbox, Incubated, and Graduated. The criteria determining a project’s maturity level include its adoption rate, longevity, and whether it has been used to build reliable applications.
What are the main projects? The list is extensive: from Kubernetes (of course) to Prometheus, from etcd to CoreDNS, from Containerd to Envoy and Fluentd, joined along the way by Falco and OpenTelemetry, both of which have achieved Graduated project status. There are also numerous projects actively developing in the CNCF incubator, including: Contour for Envoy, gRPC, KubeEdge, and Litmus.
It is a particularly rich world because some projects originate from the open source community, while others are contributed by companies to the CNCF.
The Technical Advisory Groups clearly reflect where the center of gravity has shifted. On supply chain security, the work is now foundational and has produced concrete artifacts: the TAG Security Software Supply Chain Best Practices White Paper established the common vocabulary, while Sigstore (signing and attestation without having to manage long-lived keys) and in-toto (verifiable attestations on individual pipeline steps) have become standard building blocks in build chains. How these tools combine in a real pipeline, from signing artifacts to verifying attestations during deployment, is covered in our security guide with CNCF tools. Alongside this consolidation work, the two drivers propelling the ecosystem today are AI and platform engineering.
On the AI front, the CNCF published the Cloud Native AI whitepaper in 2024 and welcomed projects like Kubeflow, incubating since 2023, and KServe. In parallel, within Kubernetes, Dynamic Resource Allocation and Kueue have finally made sharing GPUs between training and inference workloads manageable. This is not an academic topic: those who bring models into production almost always do so on existing Kubernetes clusters, not on dedicated stacks.
Platform engineering instead produced the Platforms White Paper and the Platform Engineering Maturity Model. We use them as an evaluation framework when we need to understand, together with a client, whether their internal developer platform is truly a product with users, owners, and a roadmap, or simply a collection of shared scripts that someone gave a name to. In practical terms: assessing across the model’s five axes (investment, adoption, interfaces, operations, measurement) takes us two to three weeks of interviewing application teams and reviewing pipelines and repositories. The profile we encounter most often, in organizations with 5 to 10 development teams served by a platform team of 3 to 4 people, is level 2 (Operational) driven by interfaces and operations, with adoption still at level 1 and measurement virtually absent: the platform works, but onboarding depends on a single person and no one knows how many teams actually use it. That is where the conversation stops being about tools and starts being about platform ownership. Backstage, contributed by Spotify, remains the benchmark project in this category.
Navigating the Cloud Native world: Landscape, Trail Map, and Radar
The CNCF has also developed tools to map the cloud technologies within its scope of activity: the Cloud Native Landscape and the Cloud Native Trail Map. These two maps, together with DevStats on GitHub, provide a comprehensive catalog of Cloud Native technologies and offer guidance on the purpose and uses of each. This is an especially useful resource, as it is easy to feel confused or overwhelmed when deciding which technology to implement in a project.
The CNCF Technology Radar, launched in 2020 as a quarterly guide to emerging technologies selected by foundation experts, is no longer updated at that cadence: the URL now leads to the CNCF reports section, where periodic analyses have replaced the radar. The Trail Map has also taken a back seat, while the interactive Landscape has become the primary reference tool: filters by category, maturity level, and license make it possible to navigate hundreds of projects and commercial solutions without relying on a static map.
FURTHER READING: How to read the Cloud Native Landscape
Events organized by the CNCF
Among the CNCF’s initiatives are two co-located events: KubeCon and CloudNativeCon. They have effectively become the most important gatherings for professionals working in technology and business within the Cloud Native space. Opportunities for discussion among peers, technology updates, and market trends: Cloud Native history is made at KubeCon and CloudNativeCon.
The two events take place on a rotating basis across different regions of the world three times a year. Following the virtual editions of 2020 and 2021, KubeCon + CloudNativeCon has returned in person: the calendar now alternates between North America, Europe, and Asia, with well-established hybrid formats that complement in-person sessions with live streaming and on-demand content.
CNCF certifications: from fundamentals to hands-on cluster exams
The certification program is perhaps the CNCF activity with the most direct impact on the market, as it concerns both companies and individuals working with Cloud Native technologies, starting with Kubernetes. The Certified Kubernetes Conformance Program now counts over a hundred conformant distributions and platforms; on the organizational side, the relevant programs are Kubernetes Training Partner (KTP) and Kubernetes Certified Service Provider (KCSP).
The individual pathway, meanwhile, has expanded across multiple tiers. Those entering the ecosystem today no longer find only CKA and CKAD: the catalog has broadened to cover individual Graduated and Incubating projects, featuring multiple-choice exams dedicated to Prometheus, Argo, Istio, Cilium, OpenTelemetry, and GitOps. This is a sign of the maturity reached by those projects, which now have an adoption base large enough to justify a dedicated training track.
| Level | Acronym | Focus | Exam format |
|---|---|---|---|
| Associate | KCNA | Fundamentals of Kubernetes, containers, cloud native architecture | Multiple choice |
| Associate | KCSA | Threat modeling and cluster security basics | Multiple choice |
| Associate | PCA | Prometheus, PromQL, alerting, and instrumentation | Multiple choice |
| Associate | CAPA | Argo CD, Workflows, Rollouts, Events | Multiple choice |
| Associate | CGOA, OTCA, ICA, CCA | GitOps, OpenTelemetry, Istio, Cilium | Multiple choice |
| Professional | CKA | Cluster administration and troubleshooting | Hands-on on a live cluster |
| Professional | CKAD | Application design, deployment, and debugging | Hands-on on a live cluster |
| Specialist | CKS | Hardening, supply chain, runtime security | Hands-on, requires an active CKA |
The sequence suggested by these tiers is not necessarily the one we always advise following. A developer already working on production clusters can skip directly to the CKAD: the KCNA remains more useful for non-engineering roles, from project managers to those writing requirements and specifications who need a shared technical vocabulary with the team. Vertical associate certifications make sense when the project genuinely uses that tool: a CAPA for a team that does not use Argo CD in its pipelines is time poorly spent.
The fundamental distinction remains between multiple-choice exams and hands-on exams. CKA, CKAD, and CKS are passed by solving problems on a live cluster, within a limited time and with access only to official documentation: this is why, when selecting or vetting a vendor, they carry far more weight than a theoretical certification.
SparkFabrik has earned both the Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) certifications. Furthermore, because our company includes more than 10 certified Cloud Native developers, we have also attained the Kubernetes Certified Service Provider certification. For organizations operating in the digital transformation market through a Cloud Native lens, these credentials prove that the team possesses the technical and strategic expertise needed to plan and deliver projects following Cloud Native principles and best practices. Book an appointment with our experts and tell us about your project.
