I am preparing for my CKAD (Certified Kubernetes Application Developer) exam. Below is the mental model of K8S concepts that helps me understand Kubernetes. Hope it helps you too.

The Big Picture: Kubernetes as an Orchestrator

What is Kubernetes?
Kubernetes is an automation system for deploying and managing containerized applications at scale. Rather than manually handling each container, you define your desired state—like “I want three replicas of my service running.” Kubernetes ensures this state remains true even if servers fail or traffic surges.

Why use Kubernetes?

  1. Scalability: Effortlessly scale applications up or down.
  2. Resilience: Automatically restarts or replaces failed containers (self-healing).
  3. Portability: Run the same configuration across diverse environments—on-prem, in the cloud, or in hybrid setups.

The Cluster: Nodes and the Control Plane

A Kubernetes cluster comprises multiple machines (physical or virtual). Conceptually, we divide the cluster into two halves:

  1. Control Plane – the “brain” of the operation.
  2. Worker Nodes – where your actual workloads (containers) run.

Control Plane Components

  • kube-apiserver
    The front door for your cluster. Every command you send (like kubectl apply) goes through this API server, which handles authentication and authorization.

  • etcd
    A key-value store holding the entire cluster’s configuration and state. It’s the single source of truth for Kubernetes.

  • kube-scheduler
    Watches for new Pods that aren’t yet assigned to any node, then decides where they should run based on available resources and constraints.

  • kube-controller-manager
    Runs a collection of “controllers,” each responsible for watching the cluster state and taking action to match the desired configuration. Examples include:

    • ReplicaSet controller: Ensures the correct number of Pods are running for an application.
    • Node controller: Monitors node health and handles node failures.

Worker Node Components

  • kubelet
    The on-node agent communicating with the control plane. Receives instructions from the API server and manages Pods on that node.

  • Container Runtime
    E.g., Docker, containerd, or CRI-O—this is what actually runs the containers.

  • kube-proxy
    Manages network rules and ensures Pods can communicate with each other. It also helps route external traffic to the right Pod.

Pods: The Smallest Deployable Unit

A Pod is the foundational runtime unit in Kubernetes. It usually contains a single main container (like your application) plus any helper “sidecar” containers. Since containers in the same Pod share the same network namespace (IP address) and storage volumes, you can think of a Pod as a logical host for those containers.

Analogy: A Pod is like a small apartment where all the containers live together, sharing certain utilities (network, storage) but doing separate tasks.

Workload Abstractions: Controllers & Higher-Level Objects

You rarely create Pods directly. Kubernetes provides “controllers”—higher-level abstractions that define your desired state (for instance, “I want three replicas”) and then handle the details of starting, stopping, and updating Pods.

  1. Deployment

    • The go-to mechanism for running stateless apps.
    • Manages a ReplicaSet, which in turn manages Pods.
    • Supports rolling updates, rollbacks, and easy scaling.

  2. ReplicaSet

    • Ensures a specific number of identical Pods are always running.
    • Usually managed automatically by a Deployment.

  3. StatefulSet

    • Ideal for stateful apps like databases. Though, K8S isn’t a good fit for stateful apps. It’s better to use a managed database service like AWS RDS or similar.
    • Gives each Pod a stable identity (e.g., database-0, database-1), plus persistent storage.

  4. DaemonSet

    • Ensures exactly one Pod runs on every node (or a subset of nodes).
    • Common for logging/monitoring agents.

  5. Job & CronJob

    • Job: Manages one-off tasks that run to completion (like batch jobs).
    • CronJob: Schedules tasks to run periodically (e.g., nightly reports).

Services: Stable Networking & Load Balancing

Pods come and go, but you need a consistent way to reach them. That’s where Services step in.

  • Service
    A stable network endpoint (with its own IP address and DNS name) that routes traffic to the right set of Pods.
    • ClusterIP (default): Accessible only within the cluster.
    • NodePort: Exposes the service on a fixed port across each node.
    • LoadBalancer: Integrates with a cloud provider’s load balancer to route external traffic to your cluster.

Analogy: A Service is like a company’s main phone number: even if employees change offices (Pods get replaced), the number (Service IP) stays the same and routes calls appropriately.

Configuration & Secrets

When deploying your application, you’ll often need configuration data or sensitive information (like passwords):

  • ConfigMaps
    Store non-sensitive configuration data, which can then be consumed by Pods.
    Great for environment variables or config files that don’t need encryption.

  • Secrets
    Similar to ConfigMaps but intended for sensitive data (passwords, API keys).
    They’re base64-encoded by default, so additional secure storage practices are often required.

Volumes & Persistent Storage

Containers are ephemeral by nature. If a container is removed, its data is lost unless you’re using external storage.

  • Volumes
    Provide a way for a Pod’s containers to share and persist data within the Pod’s lifespan.

  • Persistent Volumes (PVs) & Persistent Volume Claims (PVCs)

    • Persistent Volume (PV): A piece of storage in the cluster (e.g., on a cloud or an NFS server) made available by an admin.
    • Persistent Volume Claim (PVC): A request for storage by a user/application. It asks for a certain size and access mode.
    • This decouples the storage details from the application, so you say “I need 10GB,” and the cluster finds a matching PV.

Ingress: Managing External HTTP/HTTPS Traffic

Ingress is an API object that provides rules for how incoming HTTP/HTTPS requests should be routed inside the cluster. An Ingress Controller (like the NGINX Ingress Controller) implements these rules, handling the nitty-gritty of load balancing, path mapping, and SSL termination.

Tip: Use Ingress to handle complex routing needs, like directing api.example.com to one service and dashboard.example.com to another.

Security Fundamentals

Kubernetes includes several layers of security controls:

  • RBAC (Role-Based Access Control)
    Defines user and service account permissions. You set roles, and you bind them to specific users or groups.

  • Network Policies
    Control pod-to-pod communication. You can explicitly allow or deny traffic between groups of Pods.

  • Pod Security
    Use Pod Security Admission (or legacy Pod Security Policies) to limit what Pods can do, such as restricting privileges or kernel capabilities.

The Control Loop: Putting It All Together

Kubernetes is built around a “control loop” approach:

  1. You submit a YAML manifest (e.g., a Deployment and Service) to the kube-apiserver.
  2. The kube-apiserver stores this desired state in etcd.
  3. Controllers (in the kube-controller-manager) spot differences between the desired state and the actual state. If you say you want 3 replicas but only have 2, it creates another Pod.
  4. The kube-scheduler assigns any new, unassigned Pod to a suitable node based on resource availability.
  5. The kubelet on that node triggers the container runtime to download images and launch containers.
  6. The Service ensures stable network endpoints, and Ingress (if configured) routes external traffic appropriately.
  7. All the while, Kubernetes keeps reconciling any state drift—if Pods crash, the system recreates them.

Summary

  1. Pods are ephemeral, so you usually manage them with higher-level controllers (like Deployments) to ensure the right number run.
  2. Controllers operate on a declared desired state: you say what you want, and Kubernetes does the heavy lifting to maintain it.
  3. Services keep network endpoints stable, even though Pods might be replaced.
  4. ConfigMaps and Secrets decouple configuration from code, while Persistent Volumes and Claims handle storage in a flexible, abstraction-friendly way.
  5. Security is baked in at multiple levels—RBAC for access control, network policies for cluster traffic, and Pod security for container privileges.
  6. Continuous Reconciliation: Kubernetes is always adjusting your cluster so that it aligns with the desired state you’ve defined.