Learn Cloud Native & CNCF - Core Concepts: Ecosystem, Landscape & 4 Layers

#Introduction

If episode 1 covered history, episode 2 covers the map. The cloud native world is enormous — hundreds of projects and products with varied roles. To avoid getting lost, CNCF organizes all of it into a map called the Cloud Native Landscape, freely accessible at landscape.cncf.io.

This map is not just a list of logos. It groups technologies into categories that reflect real cloud native architecture, from the lowest layer that runs containers to the topmost layer that defines applications. Understanding this map is the key to understanding every episode that follows.

By the end of this episode you will be able to read the landscape, distinguish the four cloud native layers, and explain the role of cross-cutting services such as service mesh, observability, security, and storage.

#The Cloud Native Landscape

#landscape.cncf.io and Its Categories

The Cloud Native Landscape displays hundreds of projects and products grouped into five major categories: App Definition & Development, Orchestration & Management, Runtime, Provisioning, and Observability & Analysis. Every logo on the map has a color that indicates its status: a CNCF project, a non-CNCF project, or a commercial product.

The beauty of the landscape is that it unifies the technical and business views. You can see where a project sits, who its competitors are, and what services are available at each layer. That's why the landscape is often called the map of the cloud native world.

The landscape is also alive and constantly changing. Every quarter, new projects enter, some move up in maturity, and others get archived. Reading the landscape regularly gives you a sense of the industry's direction — which trends are growing and which technologies are being left behind.

#Reading the Landscape

Don't feel overwhelmed by seeing hundreds of logos at once. The key is to read it layer by layer. Each category in the landscape represents one architectural layer, and the technology choices at each layer are independent — you can use Kubernetes for orchestration while using Helm for packaging without conflict.

When you open landscape.cncf.io, try filtering to CNCF projects only. You'll see the projects discussed in episodes 5 and 6: Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Helm, and many more.

#The Four Cloud Native Layers

#The Runtime Layer

The lowest layer is Runtime, which runs containers. Here you'll find container runtimes such as containerd and CRI-O, as well as container network interfaces (CNI) that provide networking between containers. Runtime is the foundation that must stay stable because every layer above depends on it.

Think of the runtime as a car's engine and containers as its passengers. The engine doesn't need to know where passengers are going, but without a reliable engine, no passenger can travel. That's why mature, well-tested runtime projects matter so much.

#The Orchestration Layer

Above the runtime is Orchestration, which manages the container lifecycle. The main player in this layer is Kubernetes, which handles scheduling, scaling, and recovery. Other projects like KubeVirt extend Kubernetes to run virtual machines.

#The App Definition & Development Layer

The App Definition & Development layer is about how applications are built and delivered: image building, CI/CD, and application management. Helm for packaging, Argo for continuous delivery, and a number of development tools live in this layer.

#The Provisioning Layer

The topmost layer is Provisioning, which provides and manages the infrastructure where cloud native runs. Infrastructure as code technologies like Terraform, as well as container registries, live in this layer. The provisioning layer answers the question: where do the compute resources come from?

Without the provisioning layer, the layers above it have nowhere to run. This layer also bridges the cloud native world with infrastructure teams accustomed to manual server management, turning that work into code that can be reviewed and verified.

kubectl get nodes -o wide
kubectl get pods -n kube-system

The kubectl get pods -n kube-system command shows the system components running in the runtime and orchestration layers: kube-apiserver, kube-proxy, and the container runtime. If you have a small cluster like minikube, this command will directly reveal the layered structure we just discussed.

#Services That Fill the Space Between Layers

#Service Mesh and Observability

Not every technology fits into a single layer. Service mesh tools like Istio and Linkerd work at the network layer, managing communication between services across layers. Observability — handled by projects such as Prometheus, Jaeger, and OpenTelemetry — measures the health of the entire system through metrics, tracing, and logs.

#Security and Storage

Security in the cloud native context is not an add-on feature; it's a layer that envelops everything else. Projects like OPA, Kyverno, and Falco handle policy, configuration security, and threat detection across all layers. Meanwhile, storage solutions such as Rook and Longhorn provide the storage stateful applications need.

These four cross-cutting services work horizontally: they touch many layers at once. That's why the CNCF landscape is not a simple pyramid, but a map full of interconnected crossing lines.

#Summary: Placing Technology in Its Layer

Understanding the four layers helps you answer an important question: which technology fits which need? Here's a quick way to remember it from bottom to top:

• Runtime runs containers — for example: containerd, CRI-O.
• Orchestration manages containers — for example: Kubernetes.
• App Definition builds and delivers applications — for example: Helm, Argo.
• Provisioning provides infrastructure — for example: Terraform, registries.

Cross-cutting services such as service mesh, observability, security, and storage envelop all four layers.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
  labels:
    app: demo
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

The apiVersion: v1 manifest above is only an illustrative example. It shows how a Pod declares the desired outcome — the term we called declarative in episode 1 — and how Kubernetes works to make it real in the runtime layer.

#Closing

Episode 2 equipped you with a complete map of the cloud native world: the Cloud Native Landscape with its five categories, the four layers from runtime to provisioning, and the cross-cutting services that connect them. With this map, you can place every project discussed later in its right position.

Key takeaways:

• The landscape at landscape.cncf.io is the official map of hundreds of cloud native technologies.
• The five landscape categories: app definition, orchestration, runtime, provisioning, observability.
• The four core layers from bottom to top: runtime, orchestration, app definition, provisioning.
• Service mesh, observability, security, and storage work across layers.
• Kubernetes occupies the orchestration layer above the container runtime.
• Reading layer by layer makes the hundreds of logos in the landscape feel simple.

In episode 3 we'll turn from the technology map to the people behind it: how CNCF is run — the structure of the Governing Board, the Technical Oversight Committee, the Linux Foundation staff, and the roles of members from platinum to end user.