The short answer first, then the details that make it useful.

CNCF stands for Cloud Native Computing Foundation. It is a non-profit organization, which means it exists to serve a public mission rather than to earn money for owners or shareholders. Its mission is to host and grow open source software that helps people build and run applications in the cloud.

Let us unpack those words one at a time. Open source means the instructions that make up a program, called its source code, are published so that anyone can read, use, and improve them. The cloud means renting computing power, storage, and networking over the internet instead of buying and looking after your own machines. A foundation is a neutral organization that takes care of shared work, much like a trust takes care of a public park.

The CNCF is part of the Linux Foundation, the larger non-profit that also looks after the Linux operating system. It began in 2015, and its very first project was Kubernetes, a tool for running and managing large numbers of containers. Today the CNCF hosts well over a hundred projects, from tools that collect health data about running software to tools that route network traffic safely.

What the CNCF actually does

• Hosts projects. It gives each project a neutral home, so no single company can quietly take control of it.
• Provides governance. Governance simply means the written rules for how decisions are made, who can approve changes, and how disagreements are settled.
• Handles legal matters. Names, logos, and software licenses can become messy. The foundation holds trademarks and keeps licensing clear, so users can adopt tools with confidence.
• Pays for shared needs. This includes independent security reviews, testing infrastructure, and community events.
• Builds community. It runs the large KubeCon + CloudNativeCon conferences and supports thousands of local meetups and user groups.
• Offers training and certification. Together with the Linux Foundation, it provides exams that prove practical skills.
• Publishes the CNCF Landscape. This is a giant interactive map of cloud native tools, which we explore in a later chapter.

What the CNCF is not

The CNCF is not a cloud provider. You cannot rent servers from it the way you rent them from Amazon Web Services, Google Cloud, or Microsoft Azure. It is also not a software company selling a product, and it is not a government body that makes laws about technology.

It also does not write all the code itself. The code in CNCF projects is written by volunteers and by engineers whose employers pay them to contribute. The foundation provides the structure that lets all those people work together fairly.

To understand why the foundation exists, it helps to see the problem it was built to solve.

In the early 2000s, a handful of giant technology companies faced a problem that most businesses did not yet have: they ran software on thousands of computers at the same time. Looking after that many machines by hand was impossible. Google built an internal system called Borg that decided which program should run on which machine, restarted programs that crashed, and kept the whole fleet busy. Other companies, such as Amazon and Netflix, learned how to break large applications into many small services that could be changed independently.

Everyone else was left behind until 2013, when a company called Docker made containers easy to use. A container is a sealed box that holds a program together with everything it needs to run, so it behaves the same way on a laptop, a test server, and a production server. Suddenly thousands of teams were packing their software into containers, and they all asked the same next question: how do we manage thousands of containers without going mad?

Google answered by taking the lessons learned from Borg and writing a brand new open source system named Kubernetes, announced in 2014. The name comes from a Greek word meaning a ship’s helmsman, the person who steers. Kubernetes 1.0 was released in July 2015. Then Google made a bold choice. Instead of keeping control of its creation, it donated Kubernetes to a new neutral foundation, the CNCF.

The foundation’s name has a key phrase in it. Let us make sure we understand it before going further.

A program is cloud native when it is designed from the very beginning to live in the cloud and to take full advantage of it. Such programs are built from small parts, are managed by automation instead of by hand, can grow or shrink on demand, and can recover from failures without a human waking up at three in the morning.

The CNCF describes cloud native technologies as those that let organizations build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. A public cloud is rented from a provider like AWS. A private cloud is run by a company in its own data center. A hybrid cloud mixes the two. The key point is that cloud native is about how you build, not about where you rent.

Notice that none of these ideas needs a specific brand. They are patterns. The CNCF hosts open source tools that implement each pattern, which is why the foundation and the phrase “cloud native” are so closely linked.

Cloud native is not the same as cloud hosted

Suppose a company has an old program that runs on one big server in its basement. It copies the program onto one big virtual server rented from a cloud provider. The program is now in the cloud, but it is not cloud native. It still cannot grow on demand, and if that one server fails, the program fails with it. People call this approach lift and shift, and it is a fine first step, but it is only the beginning of the journey.

Why teams choose this style

Three promises drive most decisions. The first is scalability, the ability to handle more work by adding more copies of a small part. Think of an online shop on its busiest shopping day: instead of buying a bigger computer for the whole year, the shop temporarily starts more copies of the checkout service and removes them when the rush ends.

The second promise is resilience, which means recovering gracefully from trouble. In a cloud native system, a crashed part is simply replaced by a fresh one, often before any customer notices. The third promise is speed of change. Because each service is small, a team can improve and release it many times a day without waiting for the whole company to agree on one giant launch date.

Behind every healthy open source community there is a structure that keeps things fair. Here is the CNCF’s structure in plain terms.

The CNCF is a project of the Linux Foundation, which provides the legal entity, accounting, event planning, and many other behind-the-scenes services. Companies and organizations that want to support the mission become members and pay yearly fees. Membership comes in several levels, including Platinum, Gold, Silver, and End User, plus special arrangements for universities and non-profits. Major cloud providers, large banks, retailers, and start-ups all sit side by side.

Money alone does not buy control over a project. A member company cannot simply order a project to add a feature or remove a competitor. Technical decisions are made by the people who do the work in each project, and the foundation’s own bodies focus on healthy rules, fairness, and quality. Here is how the pieces connect.

graph TD
    LF["Linux Foundation: legal home and support services"]
    MEM["Member companies: Platinum, Gold, Silver, End User"]
    CNCF["CNCF: Cloud Native Computing Foundation"]
    GB["Governing Board: budget and business decisions"]
    TOC["Technical Oversight Committee: technical direction and project votes"]
    EU["End User Community: companies that use the tools"]
    TAG["Technical Advisory Groups: security, observability, runtime, app delivery"]
    PRJ["Hosted projects: Kubernetes, Prometheus, Envoy and more"]
    LF --> CNCF
    MEM -->|fund| CNCF
    CNCF --> GB
    CNCF --> TOC
    CNCF --> EU
    TOC --> TAG
    TOC -->|votes on| PRJ
    TAG -->|reviews| PRJ
    EU -->|feedback| TOC

Read the diagram from the top. The Linux Foundation gives the CNCF its legal home. Members pay fees that fund the work. Inside the CNCF, three groups steer different parts: the Governing Board looks after money and business matters, the Technical Oversight Committee looks after technical direction, and the End User Community makes sure the voice of real users is heard. The Technical Advisory Groups are expert teams that help the committee review projects in specific areas.

Openness is a rule for the foundation itself, not only for the software. Governance documents, meeting notes, and many decisions are published where anyone can read them. A person who disagrees with a decision can raise the question in public, and a company that wants a feature must persuade the maintainers with reasons instead of money. This habit of explaining decisions in the open is a large part of why users, from small start-ups to big banks, are willing to build important systems on top of the projects.

Projects do not arrive fully grown. They move through stages, and the stage tells you how much to trust them.

Every CNCF project belongs to one of three main stages: Sandbox, Incubating, or Graduated. There is also an Archived status for projects that are no longer actively maintained. These stages are a kind of report card that helps users judge how mature a project is before they depend on it.

flowchart LR
    A["Open source project with an idea or early code"] --> B["Apply to the Sandbox"]
    B --> C{"TOC review"}
    C -->|Accepted| D["Sandbox stage"]
    C -->|Not yet| A
    D --> E["Incubating stage"]
    E --> F{"Graduation vote"}
    F -->|Supermajority yes| G["Graduated stage"]
    F -->|Needs more work| E
    D -.-> H["Archived"]
    E -.-> H
    G -.-> H

The diagram shows that the journey is not automatic. A project applies, and the Technical Oversight Committee reviews it. If it is accepted, it enters the Sandbox. Later, after proving itself, it can apply to become Incubating, and later still it can face a graduation vote. A project that does not meet the bar is simply told what to improve and can try again. Dotted lines show that any project can eventually be archived if its community fades away.

What does it take to graduate?

The exact checklist is published by the foundation and can change, but the main ideas stay steady. A graduating project needs to show that many different organizations use it in real production work, that it has committers from more than one company, and that it follows the CNCF Code of Conduct. It also needs clear governance documents, a public process for reporting security problems, and an independent security audit. Finally, the Technical Oversight Committee holds a vote, and a strong supermajority must say yes.

Kubernetes became the very first graduated project in 2018. Prometheus and Envoy followed later the same year, and many others have joined them since.

If the CNCF is a neighborhood, the Landscape is the street map.

The CNCF Landscape is a giant, free, interactive chart published on the CNCF website. It lists projects hosted by the foundation and also many commercial and open source products from other organizations that fit the cloud native world. It contains well over a thousand entries, and at first glance it looks like a wall of logos. That is intimidating, but the chart is organized into groups, so you can learn it one group at a time.

The main groups are provisioning, runtime, orchestration and management, application definition and development, and observability and analysis, along with platform tools and serverless tools. You can think of them as the floors of a building. Each floor depends on the one below it.

flowchart TB
    subgraph L5["Application layer"]
        A1["Helm"]
        A2["Argo CD"]
        A3["Backstage"]
    end
    subgraph L4["Observability layer"]
        O1["Prometheus"]
        O2["Fluentd"]
        O3["Jaeger"]
        O4["OpenTelemetry"]
    end
    subgraph L3["Orchestration layer"]
        K1["Kubernetes"]
        K2["CoreDNS"]
        K3["etcd"]
        K4["Envoy"]
    end
    subgraph L2["Runtime layer"]
        R1["containerd"]
        R2["CRI-O"]
        R3["Rook storage"]
        R4["Cilium networking"]
    end
    subgraph L1["Infrastructure layer"]
        I1["Public cloud"]
        I2["Private cloud"]
        I3["Bare metal servers"]
    end
    L5 --> L3
    L4 --> L3
    L3 --> L2
    L2 --> L1

Start at the bottom. The infrastructure layer is the raw computing power: rented cloud servers, servers in your own data center, or plain physical machines. Above it sits the runtime layer, where containers actually run, together with storage and networking tools. Above that is the orchestration layer, where Kubernetes and its helpers decide what runs where. On top, the application layer holds tools for packaging and delivering software, and the observability layer watches everything and reports on its health.

A tour of the tools you will hear about most often, each explained in one breath.

Hosting more than a hundred projects, the CNCF can feel like a crowded school hallway. The good news is that a small group of well-known projects does most of the talking. Learn these first, and the rest of the Landscape becomes much easier to read. Notice also that most of them started life inside one company, solving that company’s own problem, before being shared with everyone.

Kubernetes, Prometheus, Envoy, containerd, etcd, CoreDNS, Helm, and Argo had all reached the graduated stage at the time of writing.

More names worth knowing

• Jaeger follows a single request as it travels through many services. It was created at Uber.
• Fluentd collects and forwards log messages from many sources into one place.
• OpenTelemetry is a shared standard for producing metrics, logs, and traces, so that different tools can understand each other.
• Harbor stores and scans container images. It began at VMware.
• Linkerd and Cilium help services communicate securely and give you control over the network inside a cluster.
• Falco and Open Policy Agent help with security by spotting suspicious behavior and enforcing rules.
• Backstage began at Spotify as a developer portal, one place where engineers find every service, document, and tool.
• Vitess began at YouTube and helps databases grow across many machines.

Individual tools are easy to describe. The real magic appears when you watch them cooperate.

The heart of Kubernetes: desired state

The most important idea in Kubernetes is desired state. You do not give the system a long list of commands. Instead, you write down what you want, such as “keep three copies of my web application running at all times.” Kubernetes then works continuously to make reality match your wish.

flowchart LR
    U["You declare the desired state"] --> API["Kubernetes API server"]
    API --> ETCD[("etcd stores the record")]
    API --> CTL["Controllers compare desired and actual"]
    CTL --> SCH["Scheduler picks a machine"]
    SCH --> KUB["Kubelet starts containers"]
    KUB --> RUN["Running pods"]
    RUN -.->|status report| API

Here is what each box does. The API server is the front desk where every request is received and checked. etcd records your wishes safely. Controllers are tireless inspectors that compare what you asked for with what is really happening. The scheduler chooses which machine should host a new piece of work, and the kubelet, an agent on each machine, starts the containers. A pod is the smallest unit Kubernetes runs, usually one container or a few that work as a team. The dotted line shows the loop closing, because each machine keeps reporting what it sees.

The journey of one user request

Now imagine a shopper opens an online store. Several CNCF tools cooperate within a fraction of a second to deliver the page.

sequenceDiagram
    participant U as Shopper Browser
    participant E as Envoy Gateway
    participant S as Store Service Pod
    participant D as CoreDNS
    participant DB as Database Service
    participant P as Prometheus
    U->>E: 1. Request arrives
    E->>S: 2. Route to a healthy pod
    S->>D: 3. Look up the database name
    D-->>S: 4. Return the address
    S->>DB: 5. Read or write data
    DB-->>S: 6. Return the result
    S-->>E: 7. Build the response
    E-->>U: 8. Send the page
    P->>S: 9. Collect metrics

In step one the shopper’s request reaches the gateway, a front door often built on Envoy. In step two the gateway forwards it to a healthy copy of the store service. That service needs data, so it asks CoreDNS for the database’s address in steps three and four. It then reads or writes data in steps five and six, and sends the result back through the gateway in steps seven and eight. All the while, in step nine, Prometheus quietly collects numbers about how the service behaved.

Scaling and self-healing in action

Suppose the store service is running three copies and a sudden sale triples the traffic. Kubernetes notices that the existing pods are overloaded, because a rule written by the team says to add copies when the load climbs above a chosen level. New pods start within moments, and the gateway begins sharing requests among all of them. When the sale ends, the extra copies are removed, and the company stops paying for computing power it no longer needs.

Now suppose one machine in the cluster loses power. The controllers see that three pods were wanted but only two exist, so they ask the scheduler to start a replacement on a healthy machine. Updates follow the same gentle style, called a rolling update: new copies are started first, old ones are retired one by one, and if the new version misbehaves, the change can be reversed. Nobody has to stay awake pressing buttons.

From code to running application

Many small moving parts mean many doors to lock. Here is how the ecosystem approaches the problem.

In an older style of computing, a company built one strong wall around its data center and trusted everything inside. Cloud native systems are different. They have hundreds of small services talking to each other, software arriving from many sources, and machines starting and stopping all day. Security therefore has to be built in at every layer instead of added at the edge.

Protecting the supply chain

A software supply chain is the whole path code takes from a developer’s keyboard to a running server, including the libraries, tools, and images used along the way. Attackers know that tampering with one link can poison many users at once. CNCF projects help by scanning images for known flaws, signing images so that tampering can be detected, and recording exactly what went into each build. The foundation’s security advisory group has also published best-practice guides on this topic.

Protecting running software

Even a carefully built container can behave badly if something goes wrong. Runtime tools such as Falco watch what containers are actually doing and raise an alert when something unusual happens, like a web server suddenly opening a hidden command window. Policy tools such as Open Policy Agent apply written rules, for example “no container may run with full administrator powers.”

Protecting identity and conversations

When service A calls service B, how does B know that A is really A? Projects such as SPIFFE and SPIRE give every piece of software a verified identity. Service meshes then use mutual TLS, a method where both sides prove who they are and encrypt their conversation, so that eavesdroppers learn nothing.

What the foundation itself does

The CNCF supports independent security audits of its projects, and graduation requires one. It also expects every project to publish a clear way for people to report vulnerabilities privately, so a fix can arrive before attackers learn of the flaw. A Technical Advisory Group focused on security produces reference documents and reviews that any team can read for free.

You cannot fix what you cannot see. Observability is the ability to understand what is happening inside your software from the outside.

When an application runs as dozens of small services on many machines, there is no single place to look when something breaks. A customer says the checkout is slow, but which of the thirty services is the culprit? Cloud native teams solve this with observability, and it rests on three kinds of information.

How Prometheus collects data

Prometheus uses a pull model. Instead of every service pushing numbers to a central server, Prometheus visits each service at regular intervals and reads the numbers it publishes. This makes it easy to notice when a service has gone silent, because a missing visit is itself a warning sign. A companion piece called Alertmanager groups alerts and sends them to the right people, so one outage does not create a thousand separate messages.

Why OpenTelemetry matters

Before OpenTelemetry, every monitoring product had its own way of collecting data. Switching products meant rewriting a lot of code. OpenTelemetry, formed in 2019 by merging two earlier projects called OpenTracing and OpenCensus, offers one common standard. You instrument your software once, and you can send the data to almost any compatible tool.

The four golden signals

Site reliability engineers, who are specialists in keeping large systems healthy, often recommend watching four signals for every service. Latency is how long requests take. Traffic is how much demand the service receives. Errors is how many requests fail. Saturation is how full the service’s resources are, such as memory and processing power. If you watch only these four, you will catch a large share of real problems.

Every good idea has a price. An honest picture helps you decide when the CNCF way is right for you.

Common trade-offs in plain language

Patterns are tried-and-true recipes. Habits are the small routines that keep a team out of trouble.

Cloud native engineers have repeated certain solutions so often that they now have names. Knowing these names lets you read architecture diagrams and talk to colleagues with confidence.

Many of these habits trace back to a set of guidelines known as the twelve-factor app, a checklist for building software that suits the cloud. It encourages keeping settings outside the code, treating logs as a stream of events, and making programs start and stop quickly. You do not need to memorize the list, but its spirit runs through nearly every CNCF project: keep parts small, keep them replaceable, and let automation do the repetitive work.

Habits that pay off

• Start with the problem, not the logo. Write down what you need first, and only then browse the Landscape for tools that fit.
• Prefer mature projects for core jobs. Use graduated projects for things that can hurt you badly if they fail, such as networking and security.
• Check community health. Look at how many companies contribute, how recently code changed, and how quickly security issues are fixed.
• Keep the toolbox small. Every extra tool needs upgrades, training, and monitoring. Fewer, well-understood tools beat a long, shaky list.
• Automate and write things down. If a step is done by hand more than twice, make a script or pipeline for it.
• Practice failure. Deliberately stop a service in a safe test environment and watch how the system recovers.
• Give back. Reporting a bug, fixing a typo in the guide, or sharing your story helps the tools you rely on.

Learning from other people’s mistakes is much cheaper than making your own.

An anti-pattern is a habit that looks sensible at first but causes trouble later. Cloud native projects collect them quickly, because the tools are exciting and the temptation to use them everywhere is strong. Here are four that appear again and again.

Myths and realities

Real companies, real problems, and the tools that grew out of them.

The best way to understand the CNCF is to see where its tools come from. Almost every famous project began as a private fix for a painful problem inside one company. When that company shared the fix, other organizations discovered they had the same pain, and the foundation gave everyone a fair place to improve it together.

The foundation also publishes end-user case studies in which organizations from banks to research laboratories describe how they adopted these tools. Reading a few of them is an excellent way to see the same ideas applied in very different industries.

Ready to go from reading about the CNCF to joining in? Here is a gentle path.

A beginner’s learning path

Certifications

The Linux Foundation and the CNCF jointly offer exams that test practical skill. The advanced ones place you in a live terminal and ask you to solve real tasks within a time limit, which makes them more convincing than a simple quiz.

Exam details, prices, and requirements change from time to time, so always check the official Linux Foundation training pages before you plan.

Events and community

The flagship events are KubeCon + CloudNativeCon, held several times a year in different parts of the world, where maintainers, users, and vendors meet to share talks and swap stories. Smaller Kubernetes Community Days and local CNCF community groups run meetups in cities everywhere. The foundation also has an Ambassador program that recognizes people who teach and support others. Most talks are recorded and shared online for free.

The whole story in a few simple ideas you can carry with you.