Glossary — Speak the Language
The five friends may use restaurant words, but in job interviews and documentation people use these. This page has everything you need to talk about Kubernetes with confidence: a quick-reference table, a set of interview-ready answers, and a Classic Interview Q&A section.
Quick Reference
| Term | Restaurant meaning | Plain meaning |
|---|---|---|
| Kubernetes (k8s) | The restaurant manager system | An open-source container orchestration platform that automates deployment, scaling, and management of containerized applications |
| Cluster | The entire restaurant | A set of machines (nodes) managed by Kubernetes that run containerized applications |
| Node | A kitchen station | A single machine in the cluster that runs Pods |
| Control Plane | The manager's office | The set of components that make global decisions (API server, scheduler, controller manager, etcd) |
| Pod | An individual chef | The smallest deployable unit — one or more containers sharing network and storage |
| Deployment | The hiring plan | A declarative update for Pods — manages replica count, rolling updates, and rollbacks |
| ReplicaSet | The headcount counter | Ensures a specified number of Pod replicas are running at any time |
| Service | The order window | A stable network endpoint that routes traffic to a set of Pods |
| ClusterIP | Internal kitchen window | A Service accessible only within the cluster (default type) |
| NodePort | Takeout window | A Service exposed on a static port on every node |
| LoadBalancer | Drive-through | A Service exposed via the cloud provider's load balancer |
| Ingress | The front entrance | An API object that manages external HTTP/HTTPS access to Services |
| Namespace | Different kitchen sections | A virtual cluster within a cluster — used to partition resources by team or environment |
| ConfigMap | The recipe book | A store of non-sensitive configuration data as key-value pairs |
| Secret | The safe | A store of sensitive data (passwords, tokens) — base64-encoded by default |
| PersistentVolume (PV) | The walk-in freezer | A piece of storage in the cluster provisioned by an admin or dynamically |
| PersistentVolumeClaim (PVC) | The chef's storage request | A request for storage by a Pod — bound to a PV by the cluster |
| Container | The actual dish being cooked | A runnable instance of an image — shares the Pod's network and storage |
| kubectl | The walkie-talkie | The command-line tool for talking to the Kubernetes API server |
| Manifest | The blueprint | A YAML or JSON file describing the desired state of Kubernetes resources |
| Label | The name tag on a chef | Key-value pairs attached to Pods and other objects for selection and organization |
| Selector | The manager's filter | A query that matches labels to find Pods (used by Services and Deployments) |
| Rolling Update | Replacing chefs one at a time | A strategy that gradually replaces old Pods with new ones — zero downtime |
| Rollback | Undo the last hiring decision | Reverting a Deployment to a previous revision |
| Horizontal Pod Autoscaler (HPA) | The automatic hiring manager | Automatically scales the number of Pods based on CPU, memory, or custom metrics |
| Liveness Probe | "Are you alive?" check | A periodic check that restarts the container if it's unresponsive |
| Readiness Probe | "Are you ready to serve?" check | A periodic check that removes the Pod from the Service if it's not ready |
| Startup Probe | "Are you awake yet?" check | A one-time check that delays liveness/readiness until the app finishes starting |
| Resource Request | Guaranteed minimum ingredients | The minimum CPU/memory a Pod is guaranteed — used for scheduling |
| Resource Limit | Maximum allowed ingredients | The maximum CPU/memory a Pod can use — exceeded = OOM kill |
| etcd | The manager's filing cabinet | A consistent, distributed key-value store that holds all cluster state |
Interview-Ready Answers
Core Concepts
Pod A Pod is the smallest unit Kubernetes manages. It's a wrapper around one or more containers that share the same network namespace (same IP address), storage volumes, and lifecycle. In practice, most Pods run a single container. The gotcha: Pods are ephemeral. They can be replaced at any time — never assume a Pod's IP or name will persist.
Deployment A Deployment declaratively manages a set of identical Pods. You specify the desired state (3 replicas of image X), and Kubernetes ensures that state is maintained. Deployments handle scaling, rolling updates, and rollbacks automatically. The gotcha: deleting a Deployment deletes all its Pods. Deleting a Pod causes the Deployment to recreate it.
Service A Service provides a stable IP address and DNS name for a set of Pods. Without Services, Pod IPs are ephemeral and unreliable. Services also load-balance traffic across all matching Pods. The gotcha: the Service's selector must exactly match the Pod labels. If even one character is wrong, no traffic reaches the Pods.
Namespace A Namespace is a virtual cluster within a physical cluster. It partitions resources by team, environment, or project. Namespaces help organize resources and can have resource quotas. The gotcha: Namespaces are organizational, not security boundaries. Pods in different namespaces can communicate by default.
Architecture
Control Plane The control plane consists of the API server (receives all commands), the scheduler (decides which node runs each Pod), the controller manager (ensures desired state matches actual state), and etcd (stores all cluster state). The gotcha: the control plane doesn't run your application — that's what worker nodes are for.
etcd etcd is a distributed key-value store that holds the entire cluster state — all resources, configurations, and metadata. If etcd is lost, the cluster is lost. The gotcha: always back up etcd. It's the single source of truth for the entire cluster.
kubectl
kubectl is the command-line tool for communicating with the Kubernetes API server. Every kubectl command translates to an API call. kubectl apply -f manifest.yaml tells the API server "make reality match this file." The gotcha: kubectl doesn't talk to nodes or Pods directly — it always goes through the API server.
Operations
Rolling Update A rolling update gradually replaces old Pods with new ones. It creates one new Pod, waits for it to be Ready, removes one old Pod, and repeats. This ensures zero downtime. The gotcha: if the new Pod fails readiness checks, the rollout stops. Kubernetes keeps old Pods running until the new ones are confirmed healthy.
Horizontal Pod Autoscaler (HPA) HPA automatically adjusts the replica count based on observed metrics (CPU, memory, or custom). When load increases, HPA adds Pods. When load decreases, HPA removes them. The gotcha: HPA requires resource requests to be set on all Pods — without them, it can't calculate utilization.
Health Checks (Probes) Kubernetes uses three types of probes: liveness (restart if unresponsive), readiness (stop sending traffic if not ready), and startup (delay checks until the app finishes starting). The gotcha: without probes, Kubernetes sends traffic to Pods that aren't ready yet, and keeps running Pods that are stuck.
Classic Interview Q&A
Q1: What is the difference between a Pod and a container?
Answer: A container is a running instance of a Docker image. A Pod is a wrapper around one or more containers that share the same network and storage. In practice, most Pods contain a single container. The Pod adds Kubernetes management features like labels, scheduling, and health checks. The gotcha interviewers listen for: you can't talk about Kubernetes without mentioning Pods — containers are Docker concepts, Pods are Kubernetes concepts.
Q2: Explain the difference between a Deployment and a ReplicaSet.
Answer: A ReplicaSet ensures a specified number of Pod replicas are running. A Deployment manages ReplicaSets and provides declarative updates, rolling updates, and rollbacks. In practice, you always use Deployments — you never create ReplicaSets directly. The Deployment creates ReplicaSets behind the scenes. Think of it this way: Deployment = the hiring plan, ReplicaSet = the headcount counter.
Q3: What happens when you delete a Pod managed by a Deployment?
Answer: The Deployment controller detects that the current replica count is less than the desired count. It immediately creates a new Pod to replace it. This is self-healing — the Deployment ensures the desired state is always maintained. To truly remove Pods, you must delete the Deployment itself.
Q4: What is the difference between ClusterIP, NodePort, and LoadBalancer?
Answer: ClusterIP is the default — it gives the Service an internal IP only reachable within the cluster. NodePort exposes the Service on a static port on every node, making it reachable from outside via nodeIP:port. LoadBalancer provisions a cloud provider's external load balancer and assigns it a public IP. In production, you typically use Ingress (which sits in front of Services) rather than NodePort or LoadBalancer directly.
Q5: How does Kubernetes handle zero-downtime deployments?
Answer: Through rolling updates. The Deployment creates new Pods with the updated image one at a time. Each new Pod must pass its readiness probe before Kubernetes removes an old Pod. If the new Pod fails health checks, the rollout stops and old Pods continue serving traffic. Combined with Services (which only route to Ready Pods), this ensures zero downtime during updates.
Q6: What is the purpose of a readiness probe vs a liveness probe?
Answer: A readiness probe determines whether a Pod should receive traffic from Services. If it fails, the Pod is removed from the Service's endpoints. A liveness probe determines whether the container is still alive. If it fails, Kubernetes restarts the container. Together they ensure: dead containers are restarted (liveness), and starting containers don't receive premature traffic (readiness).
Q7: What is etcd and why is it critical?
Answer: etcd is a consistent, distributed key-value store that holds the entire cluster state — all resources, configurations, secrets, and metadata. Every component reads from and writes to etcd. If etcd is lost or corrupted, the cluster loses its state of truth. Always back up etcd regularly, and in production, run an etcd cluster (typically 3 or 5 nodes) for high availability.