Cloud Native Principles and the CNCF Ecosystem

The CNCF defines cloud native technologies as those that empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. The definition then names the exemplary techniques: containers, service meshes, microservices, immutable infrastructure, and declarative APIs. These are worth memorizing as a set, because KCNA questions ask you to recognize which practices belong to the cloud native approach and which do not.

The definition also describes the outcome these techniques produce: systems that are loosely coupled, resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. Every phrase there is doing work. Loose coupling means components can change and fail independently. Resilience means the system tolerates failure rather than assuming it away. Observability means you can understand the system from the telemetry it emits. Automation means humans declare intent and machinery carries it out.

Keep the list of five exact, because popular cloud native practices that are not on it make convincing distractors. GitOps, serverless, DevOps, CI/CD pipelines, and observability tooling all belong to the cloud native world, and several are built on the five techniques (GitOps relies on declarative configuration; serverless platforms run containers), but none of them is one of the techniques the definition names. Observability appears in the definition only as an outcome, a property the techniques produce, not as a technique.

Notice what the definition does not say. Cloud native is not the same as running in a public cloud; the definition explicitly includes private and hybrid environments, and you can run thoroughly cloud native systems on-premises. Nor is it a specific product. It is a set of architectural and operational principles, and Kubernetes is the most prominent platform built around them. The CNCF, the Cloud Native Computing Foundation, is the vendor-neutral home under the Linux Foundation that hosts the open source projects implementing these ideas, with Kubernetes as its first project.

A monolith is an application built and deployed as one unit: one codebase, one build artifact, one process to run and scale. Microservices decompose the same functionality into small, independently deployable services, each owning a narrow business capability and communicating with the others over the network, typically through APIs. Cloud native architecture favors microservices because they align with the definition's goals: services are loosely coupled, can be scaled individually, and can be released independently by separate teams.

The exam expects balance, not cheerleading. Microservices buy independent scaling, deployment, and team autonomy at the price of operational complexity: network latency, partial failures, and the need for orchestration and observability tooling. A monolith is simpler to build, run, and debug, and remains a reasonable choice for small teams and early products. The honest statement, and the one KCNA rewards, is that microservices trade development-time simplicity for run-time flexibility, and platforms like Kubernetes exist largely to manage the complexity they introduce.

A service mesh is an infrastructure layer that manages the calls services make to one another, adding mutual TLS, retries, timeouts, traffic shifting, and per-call telemetry without any change to application code. It does this by routing each service's traffic through a proxy that the mesh controls, traditionally an Envoy or Linkerd sidecar injected into every Pod, or in newer designs such as Istio ambient mode a shared per-node proxy (ztunnel) for mutual TLS, plus optional waypoint proxies for L7 features such as retries and traffic shifting. Because the proxies, not the application, handle encryption and retries, every service gets the same behaviour regardless of the language it is written in. That is why the CNCF definition lists service meshes among its five techniques.

The mesh is easy to confuse with components that also sit in the request path. The distinction is the direction of the traffic. North-south traffic enters or leaves the application from outside clients; east-west traffic flows between the application's own services inside the cluster.

An internal call from one service to another never passes through the edge gateway, so the gateway cannot encrypt or retry it. A client library can, but only by modifying and redeploying every service, which is exactly what a mesh avoids. When the requirement is consistent behaviour for internal calls without touching code, the mesh is the fit; when it is controlling how outside traffic gets in, the gateway or Ingress is.

Immutable infrastructure means that once a server, virtual machine, or container is deployed, you never modify it in place. To change anything, you build a new artifact from source, deploy it, and destroy the old one. The alternative, mutable infrastructure, is the traditional model of logging into a running server to apply patches, edit configuration, or hotfix code. Mutable systems drift: after months of manual changes, no two servers are quite alike, and nobody can reproduce exactly what is running. Such hand-maintained, irreplaceable servers are the antithesis of cloud native operations.

Containers make immutability natural. A container image is a read-only, versioned artifact built once and run anywhere. To ship a fix you do not patch a running container; you build a new image, tag it, and roll it out, and Kubernetes replaces the old Pods with new ones. This is why cloud native guidance says to treat workloads as replaceable rather than as unique, carefully nursed systems. Any individual Pod can be killed and recreated from its image at any time with no loss.

The payoffs are concrete. Deployments become reproducible, because the image is the single source of what runs. Rollbacks become trivial, because the previous image version still exists and can be redeployed. Configuration drift disappears, because every replica starts from the same artifact. And security improves, because unexpected changes to a running container are a red flag rather than routine maintenance. On the exam, phrases like patching a live server in place signal the anti-pattern, while rebuild and redeploy signals the cloud native answer.

An imperative approach tells a system what to do, step by step: start three containers, then attach them to this network, then open this port. A declarative approach tells the system what you want to be true, and leaves the how to the platform: there should be three replicas of this application, reachable on this port. Kubernetes is built on the declarative model. You submit manifests, typically YAML, that describe the desired state of your objects, and the cluster works out the actions needed to make reality match.

The machinery behind this is the reconciliation loop, also called the control loop. Controllers continuously compare the desired state stored in the cluster against the observed state of the world and act to close any gap. Declare three replicas and a controller creates three Pods. If a node dies and one Pod vanishes, observed state no longer matches desired state, so a replacement is created automatically, with no human involved. This is self-healing, and it falls straight out of the declarative design: because you stated an outcome rather than a procedure, the system can re-achieve that outcome whenever conditions change.

Follow a node failure through to see the timing and which component does what. When a node stops reporting, the node controller marks it not ready or unreachable after a grace period and taints it. Pods carry a default toleration of 300 seconds for that taint, so only after about five minutes are the Pods on the dead node evicted. The ReplicaSet controller then sees fewer running Pods than the desired count and creates replacement Pod objects; the scheduler assigns those new, unbound Pods to healthy nodes, and the kubelet on each node starts their containers. Replacements therefore appear a few minutes after the failure, not instantly. The scheduler never moves a Pod that is already bound to a node: Pods are not migrated, they are replaced.

Declarative configuration has a second benefit: the manifests are plain files, so they can live in version control, be reviewed like code, and serve as the audited source of truth for what should be running, an idea that underpins GitOps-style delivery. For KCNA, anchor the pairing in your mind: declarative APIs express desired state, and reconciliation loops continuously drive actual state toward it. A question that describes issuing step-by-step commands is describing the imperative model, not the cloud native default.

Elasticity, using just enough resources and scaling with demand, is a core cloud native promise, and Kubernetes offers several autoscalers that are easy to confuse because each one scales a different thing. The Horizontal Pod Autoscaler, HPA, changes the number of Pod replicas, adding Pods when a metric such as CPU utilization is high and removing them when it falls. The Vertical Pod Autoscaler, VPA, keeps the replica count alone and instead right-sizes each Pod, adjusting its CPU and memory requests to match observed usage. The Cluster Autoscaler works at the infrastructure layer: it adds nodes when Pods are pending because no node has room, and removes underused nodes.

Two limits of the standard HPA matter. First, it keeps at least one replica by default: minReplicas defaults to 1. An HPA can only go to zero (the HPAScaleToZero feature, beta and on by default from Kubernetes v1.37) when it scales on an object or external metric, never on CPU or memory alone, because with zero Pods there is nothing reporting CPU to scale back up from. KEDA supplies those external event metrics and handles activation from zero, which is why it remains the usual choice for queue workers. Second, the HPA and the VPA should not both act on the same CPU or memory metric for the same workload: the VPA would change the requests that the HPA's utilization percentage is measured against, and the two would fight. They can run together when the VPA is limited to a different resource, using its controlledResources setting (for example, memory only) while the HPA scales on CPU, or when the HPA scales on a custom or external metric.

KEDA, Kubernetes Event-driven Autoscaling, is the CNCF graduated project that extends horizontal scaling to external event sources. Instead of watching CPU, KEDA can scale a workload on the length of a message queue or similar signals, and unlike a CPU-based HPA it can scale a workload all the way to zero replicas when there is no work. The layers also cooperate: when HPA or KEDA adds Pods and the nodes are full, the Cluster Autoscaler provisions more nodes. Exam mnemonic: HPA is more Pods, VPA is bigger or smaller Pods, Cluster Autoscaler is more nodes, KEDA is Pods on events with scale to zero.

To choose an autoscaler, identify which layer is actually short: replica count, per-Pod size, node capacity, or an event backlog. The same complaint, the service is struggling, can come from any of them, and adding capacity at the wrong layer changes nothing.

Pending Pods with an insufficient cpu or insufficient memory event mean the scheduler found no node with room for the Pod's requests. Resizing a node group by hand before each expected peak also works, but it is a manual, recurring task that misses unplanned spikes and leaves nodes idle afterwards; the Cluster Autoscaler watches for unschedulable Pods and adds nodes automatically, then removes underused ones. An OOMKilled container, by contrast, was stopped because it exceeded its own memory limit. That is a per-Pod sizing problem, so the fix is vertical: if a CPU-based HPA must stay in place, a VPA limited to memory resolves it without competing with the HPA.

Serverless does not mean there are no servers; it means developers stop managing them. In a serverless model you supply code or a container, and the platform handles provisioning, scaling, and availability, spinning capacity up when requests arrive and back down when they stop. Its defining economic feature is scale-to-zero: when there is no traffic, no instances run and, on managed platforms, nothing is billed. Compare that with a conventional Deployment, which keeps its replicas running, and costing, around the clock regardless of demand.

Function as a Service, FaaS, is the most granular serverless form: you deploy individual functions that run in response to events, an HTTP request, a queue message, a file upload, and disappear afterwards. Public cloud FaaS offerings popularized the model, but the pattern is platform-independent, and the cloud native ecosystem brings it to Kubernetes. Knative is the CNCF-hosted project to know here: its Serving component runs request-driven container workloads that autoscale with traffic, including down to zero, and its Eventing component wires event producers to consumers for event-driven architectures.

Serverless has trade-offs worth recognizing. Cold starts, the delay while an instance spins up from zero for the first request, add latency. Workloads must generally be stateless and short-lived, since instances come and go. In exchange you get minimal operational burden and cost that tracks actual usage, which suits spiky, event-driven, or infrequently used workloads especially well. On the exam, scale to zero, event-driven functions, and no server management are the trigger phrases pointing at serverless, and Knative is the Kubernetes-based answer among the options.

The CNCF landscape organizes the foundation's open source projects, along with the wider ecosystem of products, into categories so you can find the right tool for a job. You do not memorize the landscape for KCNA, but you should be able to place a well-known project by the job it does, and tell apart projects whose jobs sound alike.

Four projects are often confused because all of them watch or judge what happens in a system. Open Policy Agent is a general-purpose policy engine: you write rules in its declarative language, Rego, and any service can ask OPA for an allow or deny decision. That one engine serves Kubernetes admission control (through Gatekeeper), API gateways and microservice authorization, and checks in CI pipelines. Falco does something different: it watches running containers and hosts, typically through kernel system calls, and raises alerts on suspicious runtime behaviour such as a shell spawned inside a container. Alertmanager does not detect anything itself; it receives alerts fired by Prometheus and deduplicates, groups, silences, and routes them to destinations such as chat or paging. The OpenTelemetry Collector is a telemetry pipeline that receives, processes, and exports metrics, logs, and traces; it makes no policy or security decisions. In short: OPA decides whether something is allowed, Falco detects suspicious runtime activity, Alertmanager delivers alerts, and the Collector moves telemetry.

CNCF projects also carry a maturity level (sandbox, incubating, or graduated) that organizations use to judge adoption risk; Kubernetes was the first project to join and to graduate. Maturity levels, the Technical Oversight Committee and CNCF governance are covered in the Cloud Native Community and Collaboration lesson.

Tie the principles together with a concrete case. A retailer runs its store as a monolith on a handful of hand-maintained virtual machines. Every release redeploys the entire application, so releases are rare and risky. During flash sales only the checkout code path is overloaded, but the team must scale the whole monolith, paying for capacity the catalog and search features do not need. Patches are applied to live servers over SSH, and after years of this no two servers are identical, so failures are hard to reproduce.

A cloud native redesign applies each principle you have seen. The monolith is decomposed so that checkout, catalog, and search become separate microservices, each packaged as an immutable container image built by an automated pipeline; nobody patches a running server again, they rebuild and redeploy. The services are described declaratively in versioned manifests, and Kubernetes reconciliation keeps the running state matching them, replacing any Pod that dies. A service mesh gives the calls between checkout, catalog, and search mutual TLS and retries without code changes, while an Ingress controller handles customer traffic entering the store. During a flash sale, the HPA scales only the checkout service's replicas, and the Cluster Autoscaler adds nodes when the existing ones fill; overnight, an event-driven image-processing job scaled by KEDA sits at zero replicas until work arrives in its queue.

The outcomes map straight back to the CNCF definition: loosely coupled services that scale independently, resilience through self-healing and failure isolation, manageability through declarative automation, and frequent, predictable, low-toil change. No single tool delivered this; it is the combination of containers, microservices, immutable artifacts, declarative APIs, and automation, which is precisely the point the KCNA wants you to internalize.