Kubernetes Architecture for Developers

The CKAD exam allocates 20% of its total score to Core Concepts — the foundational domain that tests whether you can create, inspect, and manage the resources every Kubernetes application depends on. Pods, Namespaces, Labels, Selectors, and the declarative workflow that ties them together. Lose points here and you are digging yourself out of a hole for the remaining 80%.

Most developers interact with Kubernetes through kubectl apply and a CI/CD pipeline. The manifest goes in, the application comes out, and whatever happens in between is someone else’s problem. That mental model works until it doesn’t — until a Pod is stuck in Pending and you need to know that the scheduler couldn’t find a node with enough memory, or until a Deployment rollout stalls because the controller manager is still reconciling the previous ReplicaSet.

Why Architecture Matters on the Exam

The CKAD does not ask you to install etcd or configure TLS certificates for the API server. That is CKA territory. What the CKAD does test is whether you understand the system well enough to work with it efficiently under time pressure.

Consider these scenarios that appear regularly in exam tasks:

• A task says “create a Pod in the finance namespace.” You need to know that namespaces are a first-class resource, that the default namespace is not always what you want, and that forgetting --namespace=finance costs you the entire question.
• A task says “ensure the Pod restarts if it crashes.” You need to understand that the kubelet on the worker node manages Pod lifecycle and that restartPolicy: Always is the default for Pods managed by Deployments — but not for bare Pods.
• A task gives you a broken manifest. You need kubectl explain to verify field names and nesting without leaving the terminal to search documentation.

Each of these requires architectural awareness — not deep infrastructure knowledge, but enough understanding to reason about where things happen and why they behave the way they do.

The Declarative Model

Kubernetes operates on a declarative paradigm. You do not tell the cluster how to achieve a state — you describe what state you want, and the system’s controllers work continuously to make reality match your declaration.

This is fundamentally different from imperative scripting. An imperative script says “run three replicas of nginx.” If one crashes, nothing happens — the script already executed. A Kubernetes Deployment says “the desired state is three replicas of nginx.” If one crashes, the ReplicaSet controller detects the drift between desired state (3) and actual state (2) and launches a replacement.

This reconciliation loop — observe, diff, act — is the engine that powers every Kubernetes controller. Understanding it transforms Kubernetes from an opaque deployment target into a predictable system you can reason about.

What This Chapter Covers

The sections that follow break Core Concepts into two focused areas:

1. The Declarative Model and Core Resources — the control plane architecture, the reconciliation loop, Pods as the atomic unit, and the imperative vs. declarative kubectl workflows you will use on every exam task.
2. Namespaces, Labels, Selectors, and kubectl explain — the organizational primitives that structure every Kubernetes cluster, the filtering mechanisms that let you target specific resources, and the built-in documentation tool that replaces web browsing during the exam.

Master these and you lock in that 20%. More importantly, every chapter that follows builds on the patterns introduced here — Deployments extend Pods, Services target Pods via labels, NetworkPolicies select Pods via selectors. Core Concepts is not a warmup chapter. It is the foundation.