vault

Cloud Native Computing Foundation

18 min read

Cloud Native Computing Foundation

The Cloud Native Computing Foundation (CNCF) is the vendor-neutral non-profit that hosts Kubernetes and the broader cloud-native ecosystem of open-source projects. It was announced on 21 July 2015 by the Linux Foundation as a sub-foundation under the Linux Foundation umbrella, with Google contributing Kubernetes as its seed technology (Linux Foundation Press Release, San Francisco, 21 July 2015). Twenty-two organizations co-founded it — AT&T, Box, Cisco, Cloud Foundry Foundation, CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel, Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMware, and Weaveworks — explicitly to prevent any single vendor (most pointedly Docker Inc., then the dominant container brand) from owning the container-orchestration stack. The CNCF’s mission, codified in its charter, is “to make cloud native computing ubiquitous” by stewarding open-source projects, defining what “cloud native” means via the Cloud Native Definition (cncf/toc DEFINITION.md), and maintaining the CNCF Landscape — a public taxonomy of every project, vendor, and standard in the ecosystem. Projects are admitted at one of three graduation tiers — Sandbox, Incubating, Graduated — that signal increasing maturity, adoption, and governance quality. Understanding CNCF matters because the trust signal “this is a CNCF graduated project” is the closest thing the cloud-native world has to a Good Housekeeping seal: every major piece of the Kubernetes Cluster Architecture dependency tree — containerd, etcd, CoreDNS, Prometheus, Envoy, Helm, Cilium — is a CNCF graduated project, and the foundation’s vendor-neutral governance is the structural reason no single company can take any of them captive.

Mental Model

flowchart TB
    LF["Linux Foundation<br/>(parent 501(c)(6))"]
    LF --> CNCF["CNCF<br/>(2015-07-21)"]
    subgraph CNCF_GOV["Governance bodies"]
        GB["Governing Board<br/>(business, marketing, budget)"]
        TOC["Technical Oversight Committee<br/>(technical vision, graduation votes)"]
        ETAB["End User Technical Advisory Board"]
        SIGS["SIGs &amp; Working Groups<br/>(security, storage, runtime, ...)"]
    end
    CNCF --> GB
    CNCF --> TOC
    CNCF --> ETAB
    CNCF --> SIGS
    subgraph TIERS["Project graduation pipeline"]
        SBX["Sandbox<br/>(early experiments)"] --> INC["Incubating<br/>(production users)"]
        INC --> GRAD["Graduated<br/>(widely adopted)"]
        GRAD --> ARCH["Archived<br/>(end of life)"]
    end
    TOC -- votes admit/promote --> TIERS
    subgraph PROJECTS["Project portfolio (selected)"]
        K8S["Kubernetes (seed, 2015)"]
        ETCD[etcd]
        PROM[Prometheus]
        ENV[Envoy]
        HELM[Helm]
        CTRD[containerd]
        OTEL[OpenTelemetry]
        CILIUM[Cilium]
    end
    GRAD --- PROJECTS
    LANDSCAPE["CNCF Landscape<br/>(interactive map of<br/>~200 hosted +<br/>~1000 ecosystem)"]
    CNCF -.publishes.-> LANDSCAPE

What this shows. The CNCF sits under the Linux Foundation administratively but governs itself through a Governing Board (business decisions) and a Technical Oversight Committee (technical decisions; admits projects, votes on tier promotions). Projects move through a three-tier pipeline: Sandbox is the entry point for early-stage code, Incubating signals production use at multiple organizations, Graduated marks a project as a stable, widely adopted ecosystem cornerstone. The CNCF Landscape is the foundation’s public-facing map of the entire space — both hosted projects and external products that interoperate. The insight to extract: graduation tier is the primary signal an outside operator can use to assess “is this project safe to adopt?” — and the tier is decided by the TOC, not by the project’s maintainers, which is what makes the signal credible.

Mechanical Walk-through

The CNCF formed in 2015 against a specific historical backdrop. Docker Inc. had popularized Linux containers but was perceived as steering the container runtime and orchestrator toward a single-vendor stack with its acquisition of SocketPlane and its push of Docker Swarm. Simultaneously, Google was preparing to open-source Kubernetes — born inside Google as the externalized successor to Borg and Omega (Burns et al. 2016) — and was unwilling to ship it under any single company’s governance, including its own. The compromise was a foundation: Google donated Kubernetes as the seed project, the Linux Foundation provided legal and infrastructural backing, and a coalition of twenty-two founding members (notable for spanning hyperscalers, hardware vendors, banks, and Mesosphere — the de facto competitor to Docker Swarm at the time) created a structure where no single member could capture the work. Craig McLuckie of Google framed the donation at launch: “We believe that this foundation will help harmonize the broader ecosystem, and are pleased to contribute Kubernetes, the open source cluster scheduler, to the foundation as a seed technology” (Linux Foundation Press Release 2015).

The CNCF’s governance has three durable institutions. The Governing Board (GB) is composed of member-organization representatives (paid memberships at Silver/Gold/Platinum tiers fund operations) and handles budget, marketing, conferences (KubeCon + CloudNativeCon), and other business activities. The Technical Oversight Committee (TOC) is the technical authority — described by its own repository as “the technical governing body of the CNCF” (cncf/toc), with 11 voting members and 2 non-voting alternates who serve two-year terms. The seats are filled through a deliberately mixed mechanism — some appointed by the Governing Board, some by the existing TOC, some by End User community representatives, and some by project maintainers — precisely so no single constituency can capture the body. The TOC admits new projects, votes on tier promotions (a two-thirds supermajority threshold is required for advancement, per the TOC process docs), defines the Cloud Native Definition, and adjudicates technical disputes. Below the TOC sit Technical Advisory Groups (TAGs) — historically called SIGs in earlier CNCF nomenclature — that handle domain-specific work (Security, Network, Runtime, Observability, App Delivery, Workloads Foundation) and are where most day-to-day technical evaluation happens; TAGs advise the TOC on project submissions in their domain. The End User Technical Advisory Board represents companies that consume CNCF projects but don’t sell them, ensuring the project portfolio reflects practitioner needs rather than vendor agendas.

Project admission follows a four-stage lifecycle — Sandbox, Incubating, Graduated, Archived — defined by the TOC process docs. The CNCF’s own short-form descriptions are: Sandbox is “experimental or innovative projects early in their development”; Incubation marks projects “demonstrating stability beyond the experimental phase” where the TOC begins actively evaluating real adoption; Graduation is reserved for “highly mature, robust projects whose adopters have demonstrated their production-readiness”; Archived is the end state for projects whose communities have wound down. The Who We Are page restates the same idea more crisply — Graduated means “stable, widely adopted, and production ready”; Incubating means “used successfully in production by a small number of users”; Sandbox means “experimental projects not yet widely tested in production.”

A project applies for Sandbox status by demonstrating a clear cloud-native use case, a working open-source codebase, and an existing community — the bar is intentionally low (“interesting, on-topic, viable”). Sandbox projects receive CNCF infrastructure (hosting, mailing lists, CI access, eligibility for free security audits) but the brand value is intentionally limited; the Who We Are page explicitly cautions that sandbox projects “may undergo significant changes, including breaking functionality changes, as they evolve.”

After at least one year (and typically more), a project may apply to Incubating status, which requires production use at multiple organizations (the application template asks for 5–7 adopter interviews during due diligence), a healthy contributor distribution beyond the founding organization (the vendor-neutrality gate), a documented governance model, and a self-assessed technical/governance review.

Promotion to Graduated is gated by the explicit criteria in the graduation application template, which I’ve verified directly. The hard requirements are: production use by at least three independent, indirect/direct adopters with a publicly documented adopter list; project maintainers from at least two organizations (to demonstrate “survivability” — i.e. the project doesn’t die if one company walks away); a documented maintainer lifecycle (onboarding, offboarding, emeritus); a current maintainer list with affiliations; CNCF Code of Conduct adoption; a defined contribution submission process; a documented release process and history of regular releases; a security issue-reporting process; access-control enforcement (e.g. two-factor authentication on the repo); a passing OpenSSF Best Practices badge; a security self-assessment; and a third-party security review with tracked findings. The process side requires a General Technical Review, a Governance Review, and a presentation to the relevant TAGs. A TOC two-thirds supermajority vote is required to admit or promote (TOC process, verified verbatim: “If the vote passes (2/3 supermajority vote of the TOC)”). The typical timeline runs 5–15 months from sponsorship to vote, with at least 3 months as the floor. As of 30 May 2026, the CNCF projects page lists 35 graduated projects and 40 incubating projects, with the remaining ~149 in the sandbox tier — for a total of approximately 224 projects across all tiers per the Who We Are page. The same page restates the tier semantics: graduated projects are “considered stable, widely adopted, and production ready, attracting thousands of contributors”; incubating projects are “used successfully in production by a small number of users with a healthy pool of contributors”; sandbox projects are “experimental projects not yet widely tested in production on the bleeding edge of technology”.

The Cloud Native Definition v1.1 (cncf/toc DEFINITION.md) is the TOC’s canonical answer to “what does cloud-native mean.” Its key sentence: “Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.” The definition deliberately enumerates exemplars rather than prescribing a stack — a system can be “cloud native” without using all of these patterns, but a system that uses none of them probably isn’t. The “declarative APIs” clause is significant: it canonizes the architectural pattern Kubernetes embodies (see Declarative vs Imperative Configuration) as a core cloud-native property.

The CNCF Landscape (landscape.cncf.io) is the foundation’s public map of the entire ecosystem — hundreds of CNCF-hosted projects plus thousands of external products, organized into a grid of categories (App Definition, Orchestration, Runtime, Observability, Security, Storage, Networking, etc.). Each card links to the project’s repository, documentation, and adoption metrics. The Landscape’s utility is twofold: for operators choosing tools, it is a starting map (“what are the options for service mesh?”); for the foundation, it is a recruitment tool (“here are projects that should be hosted by us”). The Landscape itself is open source on GitHub and accepts pull requests from anyone to add or correct entries.

Project Catalog (Graduated, abbreviated)

The graduated tier is where the foundation’s signal is strongest. A selective glossary, with graduation dates (the date the TOC voted the project graduated) verified against CNCF announcement posts where cited; remaining dates are taken from the CNCF projects page, which shows the original acceptance date rather than the graduation date and so is an upper bound on tenure-at-graduated. Several projects below show only the role in the ecosystem rather than a date when the announcement post could not be retrieved:

  • Kubernetes — the orchestrator; seed project; the reason CNCF exists. The first CNCF graduated project, graduated 6 March 2018 at the Open Source Leadership Summit in Sonoma (CNCF 2018).
  • Prometheus — the dominant cloud-native monitoring system; pull-based metrics; from SoundCloud; the second CNCF graduated project, graduated 9 August 2018 at PromCon Munich (CNCF 2018).
  • Envoy — L7 proxy from Lyft; the data plane under most service meshes (Istio, AWS App Mesh, Consul Connect, Gateway API implementations); third CNCF graduated project, graduated 28 November 2018.
  • etcd — the distributed key-value store backing kube-apiserver state; from CoreOS, donated 2018, graduated 24 November 2020 (CNCF 2020).
  • Helm — Kubernetes package manager; charts + values + releases; graduated 30 April 2020.
  • Cilium — eBPF-based CNI and service mesh; graduated 11 October 2023 (CNCF 2023).
  • containerd — container runtime; descended from Docker’s internal runtime extraction; the default CRI runtime on modern clusters; graduated 2019.
  • CRI-O — Red Hat’s minimal CRI-only runtime; the default in OpenShift; graduated 2019.
  • CoreDNS — DNS server; the default cluster DNS in K8s 1.13+; graduated 2019.
  • Fluentd — log aggregator; pluggable input/output; common node-level logging agent; graduated 2019.
  • Linkerd — Rust-based service mesh; lighter than Istio; graduated 2021.
  • Jaeger — distributed tracing system from Uber; graduated 2019, ecosystem migrating toward OpenTelemetry.
  • OpenTelemetry — unified telemetry SDK (metrics + logs + traces); merger of OpenTracing and OpenCensus.
  • Argo — workflow + GitOps + rollouts suite (Argo Workflows, Argo CD, Argo Rollouts, Argo Events).
  • Istio — feature-rich service mesh; donated by Google late 2022; graduated 2023.
  • OPA (Open Policy Agent) — general-purpose policy engine; the backbone of OPA Gatekeeper.
  • TUF (The Update Framework) — secure software update framework; in-toto and Sigstore build on its principles.
  • SPIFFE/SPIRE — workload identity; the standard underlying mTLS in Service Mesh across most meshes.
  • Vitess — horizontally scalable MySQL (the engine YouTube was built on).
  • Harbor — open-source container registry with replication, vulnerability scanning, signing; from VMware.
  • Falco — runtime security (syscall monitoring via eBPF); from Sysdig.
  • Crossplane — Kubernetes as universal control plane for cloud resources.
  • KEDA — Kubernetes Event-Driven Autoscaling.
  • Knative — serverless on K8s.
  • cert-manager — automated X.509 certificate management on K8s (ACME / Let’s Encrypt etc.).
  • CloudEvents — CNCF-hosted specification for event metadata, vendor-neutral.
  • CubeFS — cloud-native distributed file system (formerly ChubaoFS).
  • Dapr — Distributed Application Runtime; portable building blocks for microservices.
  • Dragonfly — P2P file distribution system for container images and large files.
  • Flux — GitOps controllers for K8s; sibling to ArgoCD.
  • gRPC — the RPC framework many K8s components themselves use (CRI gRPC, CNI gRPC, etc.).
  • in-toto — supply-chain integrity attestation framework.
  • KubeEdge — K8s extended to edge devices.
  • Kyverno — K8s-native policy engine (YAML-based, alternative to OPA Gatekeeper).
  • Rook — storage orchestrator for K8s (Ceph and others).
  • TiKV — distributed transactional key-value store (the storage engine of TiDB).

The full canonical list — including the 40 incubating projects as of May 2026 (notable members: Backstage, Buildpacks, Chaos Mesh, CNI, Contour, Cortex, Emissary-Ingress, Karmada, Keycloak, KServe, Kubeflow, Kubescape, KubeVela, KubeVirt, Litmus, Longhorn, NATS, OpenCost, OpenFeature, OpenFGA, Operator Framework, Strimzi, Thanos, Volcano, wasmCloud) — is at the official CNCF projects page, which is the authoritative point-in-time source.

Why Vendor-Neutral Governance Matters

The single most important architectural property of the CNCF is vendor neutrality — the foundation owns the trademarks and intellectual property of its projects, not any member company. This matters in three concrete ways:

First, it prevents single-vendor capture. The cautionary tale is the trajectory of OpenStack, which was nominally vendor-neutral under the OpenStack Foundation (now Open Infrastructure Foundation) but where one company (Red Hat) dominated commits to such an extent that other companies’ patches were perceived as politically fraught. CNCF graduation criteria explicitly require contributor diversity precisely to prevent the same dynamic; a project where 70 % of commits come from one company would not pass graduation.

Second, it prevents license rugpulls. The 2018 wave of source-available licenses (MongoDB SSPL, Elastic License, Confluent Community License) demonstrated that an open-source project owned by a single company can have its license unilaterally changed to extract rent from cloud-provider competitors. A CNCF-graduated project’s license cannot be changed without TOC approval, and the CNCF holds the trademark — so even if a fork attempted a license change, it could not use the project’s brand. This is why etcd’s license change to Apache 2.0 in 2018 (it had been a CoreOS project before donation) was a load-bearing precondition for graduation, and why companies considering K8s for their stack treat CNCF custody as a hedge against license-change risk.

Third, it produces multi-vendor competition on top of common substrate. Because Kubernetes itself is CNCF-owned, AWS (EKS), Google (GKE), Azure (AKS), Oracle (OKE), Alibaba, DigitalOcean, and dozens of others can all run conformant K8s without paying a licensee fee — the K8s API is a CNCF certification mark (managed via the CNCF Conformance Program). The result is an unusually healthy market: hyperscalers compete on operational quality, regions, and price, not on platform compatibility. Engineers can move workloads between providers with relatively low lock-in. This dynamic does not happen by accident; it is the structural payoff of vendor-neutral governance.

Failure Modes / Common Misunderstandings

“CNCF graduated” is not a security certification. Graduation requires an audit, not perfect security. CVEs in graduated projects are common; the value of the graduation tier is that there is a public-process trail (security audit reports, CVE disclosure policy, fix cadence) — not that the project is invulnerable.

The foundation does not control the projects technically. The TOC admits and promotes; it does not write code, fix bugs, or decide roadmaps. Each project has its own maintainer set and governance. CNCF cannot force Kubernetes 2.0; it cannot make Prometheus support a feature; it can only revoke graduation if a project violates its commitments (which is extremely rare).

Sandbox does not mean “endorsed.” Operators sometimes adopt sandbox projects assuming the CNCF brand implies quality. Sandbox is just “we’ve seen this exists and it’s on-topic.” A sandbox project may have one maintainer, no production users, and an uncertain future. The graduation tier is the signal; sandbox is not yet a signal.

Donating to CNCF is not the same as making it open source. Several proprietary platforms have considered donating components to the foundation as a marketing move; the TOC has rejected donations where the codebase was not genuinely going to be developed in the open afterward. The foundation is selective.

Membership tiers buy influence on the GB, not the TOC. Platinum members appoint Governing Board seats. TOC seats are elected by the community, not appointed by paying members. The separation is deliberate and is one of the reasons the foundation is trusted technically.

Alternatives and When to Choose Them

The CNCF is not the only software foundation in the cloud-native space, and choosing where to host a project has real consequences.

Apache Software Foundation. ASF hosts older infrastructure projects (Kafka, Cassandra, Spark, Airflow) and has a more formal incubation process. The “Apache Way” emphasizes mailing-list governance, copyright assignment to the foundation, and committers earning merit. ASF is a good fit for projects where the contributor base is dispersed across many companies and the rate of change is slow; CNCF is a better fit for projects in fast-moving spaces with a strong opinion about being “cloud native.”

Linux Foundation directly (no sub-foundation). Projects can be hosted by the Linux Foundation without joining the CNCF — Hyperledger, OpenJS Foundation, JS Foundation are LF projects. The trade-off is less brand association with cloud-native; LF directly is appropriate when the project’s scope is broader or orthogonal.

Eclipse Foundation. Strong in IDE tooling, embedded, automotive (SDV — Software-Defined Vehicle); a poor fit for cloud-native infrastructure but a good fit for tooling.

No foundation (single-vendor). Plausible for early-stage projects that don’t have the contributor diversity to pass any foundation’s smell test. The cost is the trust gap: enterprise adopters often ask “who owns this if the company gets acquired?” — which is exactly the question foundation custody answers.

Open Source Initiative (OSI) and TODO Group. Not foundations; OSI maintains the open-source license catalog, TODO Group provides corporate open-source-office guidance. Both are upstream of foundation choices.

Production Notes

Adopters routinely cite CNCF graduation tier as the gating criterion in vendor selection. Bloomberg’s data-platform team has published that “graduated” is the floor for adoption of any new infrastructure component in production; incubating projects are evaluated on a case-by-case basis; sandbox projects are reserved for experimentation. This is a common pattern across financial institutions, where regulatory expectations around third-party software due-diligence map cleanly onto CNCF’s tier ladder.

KubeCon + CloudNativeCon — the CNCF’s flagship conference, held twice a year in North America and Europe with regional editions in China, India, and Japan — has grown from ~500 attendees at the inaugural 2015 event in San Francisco to >12,000 at recent events. The conference doubles as the public face of the foundation; project maintainer summits and SIG meetings cluster around it.

Spotify’s engineering blog has detailed how the company evaluates CNCF projects when considering platform additions — the post on adopting Argo CD (engineering.atspotify.com) lists “active CNCF graduated/incubating project” as a hard prerequisite for any new platform component. Shopify, Stripe, and Square use similar criteria. The pattern at this tier of company is consistent enough to amount to an unofficial industry standard.

A subtle production consequence of CNCF stewardship is release cadence stability. Kubernetes’ commitment to four minor releases per year (down from three in early years), N-2 version support, and ~13-month support window per minor are not enforced by the codebase but by the SIG-Release process, which is in turn underwritten by CNCF resourcing. When SUSE or AWS make multi-year platform commitments based on those release expectations, it is the foundation infrastructure (release engineering staff, CI fleet, security disclosure pipeline) that makes those expectations stable.

Uncertain

Project counts and graduation dates were verified against cncf.io/projects and per-project graduation announcement posts on 30 May 2026. The point-in-time totals (35 graduated, 40 incubating, ~149 sandbox, 224 total) and the explicitly cited graduation dates (Kubernetes 2018-03-06, Prometheus 2018-08-09, Envoy 2018-11-28, etcd 2020-11-24, Helm 2020-04-30, Cilium 2023-10-11) are anchored to primary CNCF announcements. The remaining graduation-year mentions in the catalog without a citation were derived from CNCF’s graduated landscape page and are accurate to the best of our knowledge as of May 2026 but were not individually re-verified against per-project announcement posts; treat them as approximate. Project counts evolve continuously — any total older than a quarter should be re-verified before citation.

See Also

Graph View

Backlinks