Plain-English explanations of 53 Kubernetes components — etcd, kube-scheduler, kubelet, Ingress, PersistentVolumes, RBAC, CRDs and more — each with an analogy and a link to the official docs.
How humans and tools talk to the cluster
The command-line tool for talking to your cluster
kubectl sends your commands (like `kubectl apply` or `kubectl get pods`) to the API server as HTTP requests. It doesn't run inside the cluster — it's the remote control you use from your laptop.
Think of it like: Like a remote control for your TV — you press buttons, it sends signals to the brain (API server), not to the screen directly.
kubectl uses the exact same REST API every other tool and controller uses — nothing gets special access.
Official kubectl docs on kubernetes.io
A web-based UI for viewing and managing the cluster
An optional add-on that gives you a visual, browser-based way to see workloads, logs and resource usage instead of typing kubectl commands.
Think of it like: Like a car's dashboard display versus popping the hood — same information, friendlier view.
As of the official docs, Kubernetes Dashboard is deprecated and unmaintained — the project itself now points people toward newer web UIs like Headlamp instead.
Official Kubernetes Dashboard docs on kubernetes.io
Automation that deploys your code to the cluster
Tools like GitHub Actions, Jenkins or ArgoCD call the Kubernetes API (often via kubectl) to roll out new versions automatically whenever you push code.
Think of it like: A robot arm on an assembly line — it performs the same actions a human would, just automatically on every commit.
The cluster's brain — decides and remembers everything
The front door to the cluster — every request goes through it
Exposes the Kubernetes REST API. Every read and write — from kubectl, controllers, kubelets, everything — goes through it. It validates requests and is the only component that talks directly to etcd.
Think of it like: The receptionist of the cluster: everyone, including other control-plane components, must check in through them before anything happens.
Kubernetes is fundamentally an API — almost nothing talks to anything else directly, it all flows through the API server.
Official kube-apiserver docs on kubernetes.io
The cluster's single source of truth
A distributed, consistent key-value store that holds the entire state of the cluster — every object's spec and status. If etcd is lost, the cluster's memory is lost.
Think of it like: The cluster's filing cabinet — nothing is officially 'true' unless it's written here.
Official etcd docs on kubernetes.io
Decides which node a new pod should run on
Watches for newly created pods with no node assigned, then picks the best node based on resource needs, constraints, affinity rules and available capacity.
Think of it like: Like a maître d' seating guests at the best available table based on party size and preferences.
Official kube-scheduler docs on kubernetes.io
Runs the control loops that enforce your desired state
Bundles many controllers (Node, ReplicaSet, Job, Endpoints...) that continuously watch the cluster and take action to move the actual state toward the desired state you declared.
Think of it like: A team of thermostats — each one watches one thing and nudges it back toward the target whenever it drifts.
This 'reconciliation loop' pattern is the core idea behind almost everything in Kubernetes.
Official kube-controller-manager docs on kubernetes.io
Connects the cluster to your cloud provider's infrastructure
Runs cloud-specific controllers — provisioning load balancers, attaching storage volumes, and labeling nodes according to the underlying cloud (AWS, GCP, Azure...).
Think of it like: A translator between Kubernetes' generic requests and your cloud provider's specific APIs.
Official cloud-controller-manager docs on kubernetes.io
What you actually deploy and run
The smallest deployable unit in Kubernetes
Wraps one or more containers that share networking and storage, and are always scheduled together on the same node. You almost never create bare Pods directly — controllers do it for you.
Think of it like: A shipping container holding one or a few tightly-related boxes that always travel together.
Official Pod docs on kubernetes.io
Keeps a fixed number of identical pod replicas running
Watches its pods and creates or deletes them to always match the desired replica count. You rarely manage these directly — a Deployment manages them for you.
Think of it like: A staffing agency that always keeps exactly N shifts covered, replacing anyone who calls in sick.
Official ReplicaSet docs on kubernetes.io
Manages rolling updates and rollbacks of stateless apps
The most common way to run apps in Kubernetes. It manages ReplicaSets underneath, so you can declare "run version 2" and it handles the rolling update — or rolls back if something breaks.
Think of it like: A stage manager swapping actors in and out for a new show, one at a time, without ever stopping the performance.
Official Deployment docs on kubernetes.io
Runs pods that need stable identity and storage
Like a Deployment, but each pod gets a stable, unique name and its own persistent storage that follows it across restarts — essential for databases and other stateful apps.
Think of it like: Assigned parking spots instead of a free-for-all lot — pod-0 always gets its own spot and its own stuff.
Official StatefulSet docs on kubernetes.io
Runs exactly one copy of a pod on every node
Ensures a copy of a pod runs on (or a chosen subset of) every node — commonly used for log collectors, monitoring agents, or network plugins.
Think of it like: A smoke detector installed in every single room of a building — no room gets skipped.
Official DaemonSet docs on kubernetes.io
Runs a pod to completion, once
Creates one or more pods and makes sure they run until they successfully finish, then stops — for batch work, unlike a Deployment which keeps pods running forever.
Think of it like: A to-do list item, not a recurring chore — once it's done, it's done.
Official Job docs on kubernetes.io
Runs a Job on a repeating schedule
Creates Jobs on a cron-style time schedule (e.g. "every night at 2am") — perfect for backups, report generation, or cleanup tasks.
Think of it like: An alarm clock that kicks off the same to-do item every day at the same time.
Official CronJob docs on kubernetes.io
How traffic finds your workloads
A stable network address for a set of pods
Pods are mortal and get new IPs when recreated. A Service gives them one stable virtual IP and DNS name, and load-balances traffic across whichever pods currently match its label selector.
Think of it like: A single phone number for a whole call center — you don't need to know which agent picks up.
Official Service docs on kubernetes.io
HTTP(S) routing rules from outside the cluster to Services
Declares rules like "requests to /api go to the api Service, requests to /web go to the web Service" — a single entry point for many services, with hostnames, paths and TLS.
Think of it like: The directory board in an office lobby telling visitors which floor to go to.
Official Ingress docs on kubernetes.io
The actual software that implements Ingress rules
An Ingress object is just a set of rules — an Ingress Controller (like NGINX or Traefik) is the running proxy that reads those rules and actually routes the traffic.
Think of it like: Ingress is the blueprint; the Ingress Controller is the security guard actually directing people at the door.
Official Ingress Controller docs on kubernetes.io
Cluster-internal DNS so pods can find Services by name
Runs as pods inside the cluster and answers DNS queries like `my-service.my-namespace.svc.cluster.local`, so workloads can reach each other by name instead of hardcoded IPs.
Think of it like: The cluster's phone book — look up a name, get the current address.
Official CoreDNS docs on kubernetes.io
A firewall for which pods can talk to which
Without one, all pods can reach all other pods by default. A NetworkPolicy restricts that — e.g. "only frontend pods may talk to database pods on port 5432".
Think of it like: A guest list at a private party — only approved connections get in.
Official NetworkPolicy docs on kubernetes.io
The worker machines, and the software on them that runs your containers
A worker machine — physical or virtual — in the cluster
Every pod runs on some Node. A Node provides the CPU, memory and disk the containers actually consume, and runs the agents that make it part of the cluster.
Think of it like: A single physical rack server, or one VM, added to the cluster's pool of muscle.
Official Node docs on kubernetes.io
The agent on every node that keeps pods running
Watches the API server for pods assigned to its node, tells the container runtime to start/stop containers accordingly, and reports status back — the node's local enforcer of the control plane's decisions.
Think of it like: A site foreman who receives blueprints (pod specs) from head office and makes sure the crew actually builds them.
Official kubelet docs on kubernetes.io
Implements Service networking rules on each node
Runs on every node and maintains the network rules that let traffic to a Service's virtual IP actually reach one of the correct backend pods, wherever they are.
Think of it like: A local call-router that forwards a call from a Service's phone number to whichever agent is free.
Official kube-proxy docs on kubernetes.io
The engine that actually runs containers (e.g. containerd)
kubelet doesn't start containers itself — it delegates to a container runtime like containerd or CRI-O, which pulls images and creates the actual isolated processes.
Think of it like: The engine under the hood — kubelet is the driver pressing pedals, the runtime is what actually makes the car move.
Official Container Runtime docs on kubernetes.io
Config and secrets you declare, storage you claim, and how it gets provisioned
Non-secret configuration data, decoupled from your image
Stores key-value configuration (URLs, feature flags, config files) that pods can consume as environment variables or mounted files, without baking it into the container image.
Think of it like: A sticky note of settings on the fridge instead of hard-coding them into the recipe.
Official ConfigMap docs on kubernetes.io
Sensitive data like passwords, tokens and keys
Similar to a ConfigMap but for sensitive values. Stored base64-encoded (and encrypted at rest if configured), with tighter access controls via RBAC.
Think of it like: The locked-drawer version of a ConfigMap's sticky note.
Official Secret docs on kubernetes.io
A piece of real storage in the cluster, provisioned in advance
Represents actual storage — a cloud disk, NFS share, etc. — provisioned by an admin or dynamically via a StorageClass, independent of any one pod's lifecycle.
Think of it like: An actual storage unit at a facility — it exists whether or not anyone's renting it.
Official PersistentVolume (PV) docs on kubernetes.io
A pod's request to 'rent' some persistent storage
A pod never uses a PersistentVolume directly — it creates a PVC asking for e.g. "10Gi, read-write-once", and Kubernetes binds it to a matching PV.
Think of it like: The rental receipt for that storage unit — you file a claim, you don't grab it yourself.
Official PersistentVolumeClaim (PVC) docs on kubernetes.io
A template for dynamically provisioning storage on demand
Defines "what kind" of storage to create on the fly (SSD vs HDD, which cloud disk type) when a PVC asks for storage and no matching PV already exists.
Think of it like: A menu of storage tiers — "fast SSD" vs "cheap HDD" — the cloud provisions a fresh unit matching your order.
Official StorageClass docs on kubernetes.io
The foundation: boundaries, permissions and limits
A virtual cluster-within-a-cluster for organizing resources
Lets you split one physical cluster into isolated groups of names (e.g. dev, staging, prod) so teams and resource quotas don't collide, without needing separate clusters.
Think of it like: Separate folders on the same hard drive — same disk, cleanly separated contents.
Official Namespace docs on kubernetes.io
Who is allowed to do what, on which resources
Role-Based Access Control defines permissions (Roles/ClusterRoles list allowed verbs like get/list/create) and grants them via RoleBindings/ClusterRoleBindings.
Think of it like: Keycard access levels in an office — this badge opens the lab, that one only opens the lobby.
Official RBAC (Roles & Bindings) docs on kubernetes.io
Caps total resource usage within a namespace
Limits the total CPU, memory, or object count (e.g. max 10 pods) a namespace can consume, so one team can't accidentally starve the whole cluster.
Think of it like: A household budget for one department — spend freely, but only up to the agreed total.
Official ResourceQuota docs on kubernetes.io
An identity for pods and processes, not humans
When a pod needs to call the Kubernetes API itself (e.g. a controller running in-cluster), it authenticates as a ServiceAccount rather than a human user — RBAC controls what it can do.
Think of it like: A badge issued to a robot employee, not a person — same access system, non-human identity.
Official ServiceAccount docs on kubernetes.io
Where pods land, how they stay apart, and what protects them under pressure
Rules that attract (or repel) pods toward certain nodes
Lets you say "this pod prefers, or requires, nodes labeled ssd=true" — a more expressive version of the older nodeSelector field, with both hard (required) and soft (preferred) rules.
Think of it like: Like a job posting that says "must have 5 years experience" (required) vs "bilingual preferred" (preferred) — hard vs soft requirements for where a pod can work.
Official Node Affinity docs on kubernetes.io
Rules about which pods should — or should not — run near each other
Unlike Node Affinity (which looks at node labels), this looks at OTHER PODS already running: "schedule me near my cache" (affinity), or "never put two replicas of me on the same node" (anti-affinity) for resilience.
Think of it like: Seating-chart rules at a wedding: "seat the groomsmen together" (affinity) vs "keep the exes at separate tables" (anti-affinity).
Official Pod Affinity & Anti-Affinity docs on kubernetes.io
Nodes that repel pods — unless the pod says it is okay
A taint on a node says "don't schedule here unless you tolerate this" (e.g. GPU-only nodes, or nodes under maintenance). It's the opposite mechanism from affinity: the NODE does the rejecting, not the pod doing the choosing.
Think of it like: A 'staff only' door — most people are turned away, but anyone holding the right keycard (toleration) can walk through.
Official Taints & Tolerations docs on kubernetes.io
Evenly spreads pods across zones, nodes, or racks
Prevents all your replicas from accidentally landing in the same availability zone or on the same node — so a single zone outage or node failure doesn't take down the whole app.
Think of it like: Not keeping all your eggs in one basket — literally spreading them across baskets (zones/nodes) on purpose.
Official Topology Spread Constraints docs on kubernetes.io
Lets critical pods evict less important ones when resources are tight
Pods get a PriorityClass. When the cluster is full, the scheduler can evict (preempt) lower-priority pods to make room for a pending higher-priority one — so your payment service doesn't starve because of a batch job.
Think of it like: A VIP line at a packed venue — if it is full, security asks a regular guest to step outside so the VIP can get in.
Official Pod Priority & Preemption docs on kubernetes.io
Guarantees a minimum number of pods stay up during voluntary disruptions
Protects your app during node drains, upgrades, or cluster-autoscaler scale-downs by telling Kubernetes "never take down more than N (or fewer than M) of my pods at once" — it doesn't stop hardware failures, only voluntary actions.
Think of it like: A restaurant's rule that at least half the kitchen staff must stay on shift during any scheduled break rotation — service never fully stops.
Official Pod Disruption Budget (PDB) docs on kubernetes.io
Growing, shrinking and right-sizing your workloads and cluster automatically
Automatically adds or removes pod replicas based on load
Watches metrics like CPU or memory (or custom/external metrics) and adjusts a Deployment's or StatefulSet's replica COUNT up or down to match demand, without a human touching kubectl.
Think of it like: A call center automatically opening more phone lines when hold times spike, and closing them again when it is quiet.
Official Horizontal Pod Autoscaler (HPA) docs on kubernetes.io
Automatically right-sizes a container's CPU/memory requests
Instead of changing how MANY replicas run (that's HPA's job), VPA adjusts how big each container's resource requests/limits are, based on its actual historical usage — so you stop guessing at the numbers in your YAML.
Think of it like: Alterations on a suit instead of buying more suits — VPA resizes the one you have to fit better.
Official Vertical Pod Autoscaler (VPA) docs on kubernetes.io
Automatically adds or removes entire Nodes from the cluster
When pods can't be scheduled because the cluster is out of capacity, Cluster Autoscaler asks the cloud provider for more Nodes. When nodes sit mostly idle, it removes them — scaling the cluster itself, not just what's on it.
Think of it like: Renting extra warehouse space during the holiday rush, and giving it back in January.
Official Cluster Autoscaler docs on kubernetes.io
Collects CPU/memory usage from every node and pod, cluster-wide
A lightweight, in-cluster addon that scrapes resource usage from each kubelet and exposes it through the Metrics API — the data source that `kubectl top` and both autoscalers depend on.
Think of it like: The cluster's utility meter — without it, nothing downstream knows how much CPU or memory is actually being used.
Official Metrics Server docs on kubernetes.io
Teaching the cluster new tricks
Lets you define your own Kubernetes object types
The Kubernetes API only ships with built-in types like Pod and Service — a CRD lets you add a brand-new kind (e.g. `Database` or `Certificate`) that behaves just like a native object: kubectl, RBAC, and controllers all just work with it.
Think of it like: Adding a new page type to a form-builder app — once defined, it behaves exactly like the built-in ones.
Official Custom Resource Definition (CRD) docs on kubernetes.io
A controller that automates operating a specific application
Combines a CRD with a custom controller that encodes human operational knowledge — e.g. a Postgres operator that knows how to fail over, back up, and upgrade Postgres automatically, the way a skilled DBA would.
Think of it like: A self-driving car for a specific application: it doesn't just run it, it knows how to react when something goes wrong.
Official Operator Pattern docs on kubernetes.io
An external gatekeeper the API server calls before saving any object
Before an object is persisted to etcd, the API server can call out to a webhook to validate it (reject bad configs) or mutate it (inject defaults, sidecars, labels) — this is how tools like Istio auto-inject proxies and policy engines enforce rules.
Think of it like: A bouncer who checks IDs (validating) and sometimes hands out a wristband (mutating) before anyone gets past the door.
Official Admission Webhook docs on kubernetes.io
The pluggable software that actually wires up pod networking
Kubernetes itself does not implement pod networking — it delegates to a Container Network Interface plugin (like Calico, Cilium, or Flannel) that assigns pod IPs and routes traffic between nodes.
Think of it like: The electrician who actually runs the wiring — the building plans (Kubernetes networking model) mean nothing until someone wires it up.
Official CNI Plugin docs on kubernetes.io
The pluggable software that connects Kubernetes to a specific storage backend
Like CNI for networking, the Container Storage Interface lets any storage vendor (AWS EBS, Ceph, Portworx...) write a plugin so Kubernetes can provision and attach their volumes without vendor-specific code baked into core Kubernetes.
Think of it like: A universal power adapter — one standard socket (CSI) that any storage vendor's plug can fit into.
Official CSI Plugin docs on kubernetes.io
Locking it down and watching it closely
Cluster-wide enforcement of baseline pod security rules
A built-in admission controller that labels namespaces with a security level (privileged, baseline, or restricted) and rejects any pod spec that violates it — e.g. blocking containers that try to run as root in a "restricted" namespace.
Think of it like: A dress code enforced at the door of every room in a building, not just the front entrance.
Official Pod Security Admission docs on kubernetes.io
A tamper-evident record of every request made to the API server
Logs who did what, to which object, and when — every kubectl command, every controller action. Essential for security forensics and compliance ("who deleted that Secret at 2am?").
Think of it like: The security camera footage for your cluster — you hope you never need it, but you really want it when you do.
Official Audit Logging docs on kubernetes.io
Encrypts Secret data inside etcd itself, not just base64
By default, Secrets are only base64-encoded in etcd — trivially reversible, not encryption. This feature configures the API server to actually encrypt that data at rest, so a raw etcd backup or disk snapshot doesn't leak plaintext credentials.
Think of it like: The difference between writing a password in plain sight vs. locking it in a safe — base64 is neither, it is just writing it upside down.
Official Secrets Encryption at Rest docs on kubernetes.io
A stream of what is happening to your objects, in plain language
Every time something notable happens — an image pull fails, a pod gets scheduled, a probe fails — Kubernetes records an Event. `kubectl describe` shows them, and they are usually the fastest way to find out why something is not working.
Think of it like: The play-by-play commentary running underneath a game — the score (object status) tells you what happened, the commentary (Events) tells you why.
Official Kubernetes Events docs on kubernetes.io
Kubelet's last resort to protect a node running low on resources
When a node starts running critically low on memory, disk, or PIDs, the kubelet proactively evicts lower-priority pods itself — before the Linux OOM killer starts killing things more randomly and destructively.
Think of it like: A ship's crew throwing cargo overboard in a controlled way before the ship takes on so much water it capsizes.