Container Orchestration for the KCNA Exam: Runtimes, Networking, Service Mesh, Storage & Container Security

Introduction

Most KCNA candidates spend the bulk of their study time on the Kubernetes Fundamentals domain — Pods, Deployments, the control plane — because it carries the most weight at roughly 46% of the exam. That’s the right instinct, but it leaves a large blind spot. The Container Orchestration domain is the second-largest section of the Kubernetes and Cloud Native Associate (KCNA) exam at about 22%, and it is where many candidates lose easy points because the material sits one layer below Kubernetes itself.

Container orchestration is about the machinery that makes containers actually run, talk to each other, persist data, and stay secure — the runtime that starts the container, the networking plane that gives Pods IP addresses, the storage plane that attaches volumes, and the security boundaries that keep workloads isolated. Kubernetes does not implement most of this directly. Instead it defines interfaces — CRI, CNI, CSI — and lets pluggable components do the work. Understanding that pattern is the single most useful thing you can take into this domain.

This guide walks the Container Orchestration domain the way the KCNA blueprint frames it: the container runtime and CRI, networking and CNI, service mesh, storage and CSI, and container security fundamentals. If you want the full lay of the land first, start with the KCNA Exam Guide 2026 and the KCNA Study Guide, then come back here to go deep.

What the Container Orchestration Domain Covers

The KCNA blueprint lists Container Orchestration with several sub-areas. It helps to keep the whole map in view before diving in:

Sub-topic	What the exam expects you to know
Container Runtime	What a runtime does, the CRI, high-level vs low-level runtimes (containerd, CRI-O, runc)
Container Networking	The Kubernetes network model, CNI, how Pods get IPs, Services
Container Storage	Ephemeral vs persistent storage, the CSI, volumes, PV/PVC at a conceptual level
Service Mesh	What a mesh adds (mTLS, traffic control, observability) and the sidecar pattern
Container Security	Image provenance, least privilege, isolation, the shared-responsibility mindset
Container Orchestration Fundamentals	Why orchestration exists: scheduling, scaling, self-healing, declarative config

You are not expected to configure any of these from scratch. KCNA is a multiple-choice, conceptual exam (see the KCNA Exam Format breakdown). The questions test whether you understand what each component does and where the boundaries lie. Keep that altitude in mind as we go.

Why Orchestration Exists at All

Start with the “why.” A single container is easy to run with docker run or nerdctl run. The trouble starts at scale: dozens or hundreds of containers across many machines, each needing to be scheduled onto a node with capacity, restarted when it crashes, scaled up under load, discovered by other services, and rolled out without downtime.

A container orchestrator automates exactly that. Kubernetes, the orchestrator the KCNA centers on, gives you:

• Scheduling — placing Pods onto nodes based on resource requests, affinity, and taints.
• Self-healing — restarting failed containers and rescheduling Pods off dead nodes.
• Horizontal scaling — adding or removing replicas to match demand.
• Service discovery & load balancing — stable virtual IPs and DNS names for groups of Pods.
• Declarative configuration — you describe desired state in YAML; controllers reconcile reality toward it.

That last point is the heart of the cloud native model. You do not script “start three copies”; you declare replicas: 3 and a controller continuously makes it true. Expect at least one KCNA question that rewards recognizing declarative, desired-state management as the defining trait of Kubernetes.

The Container Runtime and the CRI

A container runtime is the software that actually pulls images, unpacks them, and starts the container processes with the right namespaces and cgroups. Kubernetes does not include a runtime. Instead, the kubelet on each node talks to a runtime through the Container Runtime Interface (CRI) — a gRPC API that decouples Kubernetes from any specific runtime implementation.

This is the interface pattern in its purest form. Because the kubelet speaks CRI, you can swap the runtime underneath without changing Kubernetes:

Runtime	Type	Notes
containerd	High-level (CRI-compatible)	Graduated CNCF project; the most common default in managed clusters
CRI-O	High-level (CRI-compatible)	Lightweight runtime built specifically for Kubernetes
runc	Low-level (OCI)	Actually creates the container via Linux namespaces/cgroups; called by containerd/CRI-O

The distinction the exam likes: high-level runtimes (containerd, CRI-O) manage images, networking handoff, and the container lifecycle, then delegate the actual process creation to a low-level runtime like runc, which implements the OCI runtime spec.

You may also see Docker come up. Since Kubernetes 1.24, the dockershim adapter was removed, so Docker is no longer used as a runtime directly — but containerd, which Docker itself is built on, remains a first-class CRI runtime. Images you build with Docker still run fine because they follow the OCI image spec. A common exam trap is implying “Kubernetes removed Docker support so your images won’t run” — that’s false; only the runtime shim was removed.

Two CNCF standards bodies underpin all of this and are worth memorizing:

• OCI (Open Container Initiative) — defines the image format and runtime specs.
• CRI (Container Runtime Interface) — defines how the kubelet talks to a runtime.

Container Networking and the CNI

Kubernetes has a deliberately simple network model with a few non-negotiable rules:

1. Every Pod gets its own unique IP address.
2. Pods can communicate with all other Pods across nodes without NAT.
3. Agents on a node (like the kubelet) can reach all Pods on that node.

Kubernetes does not implement this model itself. It delegates to a plugin via the Container Network Interface (CNI) — another CNCF-hosted spec. When a Pod is scheduled, the kubelet calls the CNI plugin to attach the Pod to the network and assign it an IP.

Common CNI plugins you might see referenced: Cilium (eBPF-based, a graduated CNCF project), Calico, and Flannel. You do not need to configure them for KCNA, but you should know that the CNI is where Pod networking comes from and that swapping CNI plugins is how clusters change networking behavior (for example, adding NetworkPolicy enforcement).

On top of Pod-to-Pod connectivity, Kubernetes layers Services for stable access to a group of Pods:

Service type	What it does
ClusterIP	Default. A stable internal virtual IP, reachable only inside the cluster
NodePort	Exposes the Service on a static port on every node
LoadBalancer	Provisions an external load balancer (typically via a cloud provider)
ExternalName	Maps the Service to an external DNS name via a CNAME

And for HTTP routing, Ingress (and increasingly the newer Gateway API) sits in front of Services to route by host and path. KCNA expects you to recognize the purpose of each, not write the YAML. A useful mental rule: ClusterIP for internal, NodePort/LoadBalancer for external, Ingress for HTTP layer-7 routing.

# Conceptually, a Service gives a stable name + IP in front of changing Pods
kubectl get svc            # see ClusterIP / NodePort / LoadBalancer types
kubectl get endpoints      # the actual Pod IPs behind a Service

Service Mesh

A service mesh is an infrastructure layer that handles service-to-service communication without changing application code. It typically injects a sidecar proxy (historically Envoy) next to each application container in the Pod, and all traffic flows through these proxies. Newer meshes also offer sidecar-less, node-level data planes, but the sidecar model is the one KCNA most often frames.

What a mesh adds on top of basic Kubernetes networking:

• Mutual TLS (mTLS) — automatic encryption and identity between services.
• Traffic management — canary releases, retries, timeouts, traffic splitting.
• Observability — uniform metrics, traces, and logs for every call.

The CNCF mesh project most often referenced is Istio (graduated), along with Linkerd. For the exam, the key idea is the separation of concerns: the mesh’s data plane (the proxies) moves traffic, while the control plane configures policy. You are offloading cross-cutting concerns — security, reliability, observability — out of the app and into the platform. If a question asks “how do you get mTLS and traffic splitting between microservices without editing application code?”, the answer is a service mesh.

Container Storage and the CSI

Containers are ephemeral by default: when a container restarts, anything written to its writable layer is gone. For stateful workloads — databases, queues, anything that must outlive a Pod — Kubernetes provides volumes, and durable volumes are provisioned through the Container Storage Interface (CSI).

CSI is the third major interface (after CRI and CNI) and follows the same plug-in philosophy: storage vendors write a CSI driver, and Kubernetes can attach and mount their volumes without baking vendor code into Kubernetes itself.

The conceptual storage objects KCNA expects you to recognize:

Object	Role
Volume	Storage attached to a Pod; lifetime depends on the volume type
emptyDir	Ephemeral scratch space tied to the Pod’s lifetime
PersistentVolume (PV)	A cluster resource representing real storage
PersistentVolumeClaim (PVC)	A user’s request for storage that binds to a PV
StorageClass	Defines how storage is dynamically provisioned (the “type” of storage)

The pattern to remember: an application requests storage with a PVC, which binds to a PV; a StorageClass enables dynamic provisioning so a PV is created on demand instead of pre-provisioned by an admin. The CSI driver is the machinery underneath that actually talks to the storage backend (EBS, a SAN, NFS, etc.).

# The conceptual storage chain you should be able to read
kubectl get storageclass   # available "types" of storage
kubectl get pv             # provisioned volumes
kubectl get pvc            # claims (requests) bound to PVs

If you want a deeper, CKA-level treatment of these objects, the Kubernetes Storage for the CKA Exam guide goes further — but for KCNA, conceptual recognition is enough.

Container Security Fundamentals

Container security on KCNA is introductory, but it connects directly to the deeper Cloud Native Security topics you’d meet on the KCSA exam. The framing to internalize is the 4Cs of Cloud Native Security — Cloud, Cluster, Container, Code — covered in detail in our 4Cs of Cloud Native Security guide. The “Container” layer is the one this domain emphasizes.

Core container security ideas for KCNA:

• Image provenance — use trusted base images, scan for vulnerabilities, and prefer minimal images to shrink the attack surface.
• Least privilege — avoid running containers as root; drop unnecessary Linux capabilities.
• Isolation — containers share the host kernel, so isolation comes from namespaces, cgroups, and policies — it is not the same as a VM boundary.
• Supply chain awareness — know where your images come from and sign/verify them where possible.
• Runtime restrictions — read-only root filesystems and SecurityContext settings reduce blast radius.

The single most testable concept: containers are not a hard security boundary by themselves because they share the host kernel. That’s why isolation, least privilege, and defense-in-depth matter. If a question contrasts containers and virtual machines, the distinction is the shared kernel versus a hypervisor-enforced boundary.

How These Pieces Fit Together

Step back and the domain forms a clean picture. When you run a workload on Kubernetes:

1. The scheduler places the Pod on a node (orchestration).
2. The kubelet calls the runtime via CRI to start the containers.
3. The runtime delegates process creation to a low-level runtime (runc) using OCI.
4. The CNI plugin gives the Pod an IP so it can talk to other Pods.
5. Services and optionally a service mesh provide stable discovery, load balancing, and secure traffic.
6. The CSI driver attaches any persistent volumes the Pod claims.
7. Container security controls — image hygiene, least privilege, isolation — wrap the whole thing.

Notice the recurring theme: Kubernetes defines interfaces (CRI, CNI, CSI) and delegates to pluggable implementations. If you remember nothing else from this domain, remember that pattern. It answers a surprising share of the questions.

Study Strategy for This Domain

Because Container Orchestration is conceptual, the most efficient prep is repeated exposure to the vocabulary and the boundaries between components, then practice questions to surface gaps:

• Map the three interfaces (CRI/CNI/CSI) to runtime/network/storage until it’s automatic.
• Know the CNCF project landscape at a recognition level — containerd, Cilium, Istio, runc — without memorizing internals.
• Drill the Service types and when each is used.
• Internalize the “containers share the kernel” security point.

Reading explains the concepts, but the KCNA rewards pattern recognition under time pressure — 60 questions in 90 minutes. The most reliable way to find your weak spots is to answer realistic, exam-style questions and review the explanations. Our free KCNA practice questions are a good warm-up, and when you’re ready for full-length, timed conditions across every domain, the KCNA Certification Ready Mock Exam Bundle gives you five mock exams with detailed explanations so you walk in knowing exactly where you stand.

Pair this with the broader Kubernetes Certification Path Guide 2026 if you’re planning to continue toward CKA or CKAD after KCNA.

Conclusion

The Container Orchestration domain rewards a clear mental model over memorization. Kubernetes is an orchestrator that automates scheduling, self-healing, and scaling, but it deliberately stays out of the runtime, networking, and storage business — delegating each to a pluggable interface (CRI, CNI, CSI). Layer on Services and an optional service mesh for communication, and wrap it all in container-security fundamentals grounded in the reality that containers share a host kernel.

Get those boundaries straight and roughly a fifth of the KCNA becomes points you can answer with confidence. Combine this conceptual map with timed practice, and you’ll handle the orchestration questions quickly — leaving more of your 90 minutes for the trickier fundamentals and architecture items.

FAQ

How much of the KCNA exam is Container Orchestration?

Container Orchestration is the second-largest domain at roughly 22% of the exam, behind Kubernetes Fundamentals (about 46%). With 60 questions total, expect somewhere around 13 questions drawn from this domain.

Do I need to configure runtimes, CNI, or CSI for the KCNA?

No. KCNA is a multiple-choice, conceptual exam. You need to understand what each component does and where the boundaries are — not how to install or configure them. Hands-on configuration shows up later on CKA and CKAD.

What is the difference between CRI, CNI, and CSI?

They are three Kubernetes interfaces that decouple Kubernetes from implementations: CRI (Container Runtime Interface) is how the kubelet talks to a container runtime, CNI (Container Network Interface) is how Pods get networking, and CSI (Container Storage Interface) is how external storage is attached. All three let you plug in different vendors without changing Kubernetes.

Is Docker still supported in Kubernetes?

Docker as a runtime shim (dockershim) was removed in Kubernetes 1.24, but the underlying containerd runtime is fully supported, and images built with Docker still run because they follow the OCI image spec. The removal affected the runtime adapter, not your images.

What does a service mesh add over plain Kubernetes networking?

A service mesh adds automatic mutual TLS (mTLS), advanced traffic management (canaries, retries, timeouts), and uniform observability across services — typically via sidecar proxies — all without changing application code.

Are containers as isolated as virtual machines?

No. Containers share the host’s Linux kernel and are isolated by namespaces, cgroups, and policies, whereas VMs are separated by a hypervisor. This is why container security emphasizes least privilege, trusted images, and defense-in-depth — the shared kernel means a container is not a hard security boundary on its own.