121 Kubernetes Interview Questions and Answers (2026)

A Pod is a group of one or more containers that share the same network and storage context, so Kubernetes can schedule and manage tightly-coupled containers as a single atomic unit rather than juggling containers individually.

• Co-located containers need shared context: Containers in a Pod share the same network namespace (one IP, localhost) and can share volumes, enabling helper patterns like sidecars.

• Scheduling atomicity: All containers in a Pod are placed on the same node and scheduled together, which is impossible if each container were scheduled independently.

• A consistent abstraction for controllers: Higher-level objects (Deployment, ReplicaSet) operate on Pods, giving one uniform unit to replicate, roll out, and heal.

• Common patterns enabled: Sidecars (logging, proxies), init containers, and adapters live beside the main container while sharing its lifecycle.

• Rule of thumb: one main container per Pod; add extra containers only when they must share the Pod's lifecycle and resources.

A container is a single packaged, running process (image + runtime); a Pod is the Kubernetes wrapper around one or more containers that gives them a shared identity, network, and lifecycle.

• Container:

  • A runtime instance of an image, isolated via namespaces and cgroups; the unit you build and push.

  • Not a Kubernetes API object on its own: Kubernetes never schedules a bare container.

• Pod:

  • The smallest deployable Kubernetes object; has its own name, IP, and lifecycle.

  • Wraps its container(s) with shared network namespace and volumes.

• Relationship: Kubernetes manages Pods; the container runtime (via kubelet) runs the containers inside them.

VMs virtualize hardware and run a full guest OS each, while containers virtualize the OS and share the host kernel, making them lighter and faster to start. Kubernetes orchestrates containers because their density, speed, and immutability make large-scale automated scheduling practical.

• Virtual machines: Run on a hypervisor; each VM includes its own kernel and OS, giving strong isolation but heavy footprint (GBs, slow boot).

• Containers:

  • Share the host kernel and isolate via namespaces/cgroups; start in seconds and are measured in MBs.

  • Isolation is weaker than a VM (shared kernel is the boundary).

• Why Kubernetes orchestrates containers:

  • Fast startup and high density let the scheduler pack, move, and restart workloads dynamically.

  • Immutable images make replicas identical and rollouts/rollbacks predictable.

  • They are not mutually exclusive: Kubernetes nodes are often VMs, running containers on top.

Self-healing means Kubernetes continuously compares actual cluster state to the declared desired state and automatically corrects drift: it restarts, reschedules, or replaces failed Pods without human intervention.

• Controller reconciliation: A ReplicaSet recreates Pods to keep the declared replica count; a Deployment manages this over rollouts.

• Node failure recovery: If a node dies, its Pods are rescheduled onto healthy nodes.

• Restart policies: The kubelet restarts crashed containers according to restartPolicy.

• Health probes: A failing livenessProbe triggers a restart; a failing readinessProbe removes the Pod from Service endpoints until healthy.

• Caveat: self-healing restores declared state, it does not fix a bad image or crashing app logic (you'll just get CrashLoopBackOff).

Imperative usage tells Kubernetes exactly what action to perform now, while declarative usage describes the desired end state in manifests and lets Kubernetes figure out how to get there. Declarative is preferred because it is repeatable, version-controllable, and idempotent.

• Imperative:

  • Direct commands: kubectl create, kubectl run, kubectl scale.

  • Fast for one-off tasks and debugging, but state lives only in your shell history, not in source control.

• Declarative:

  • You write YAML and run kubectl apply -f; Kubernetes diffs desired vs. current and reconciles.

  • Idempotent: applying the same file repeatedly converges to the same state.

• Why declarative wins:

  • Manifests live in Git (GitOps), enabling review, audit, and rollback.

  • Matches Kubernetes' own reconciliation model, so drift is corrected automatically.

etcd is the distributed key-value store that persists the entire desired and observed state of the cluster: every object, config, and status. It is the single source of truth because the API server stores nothing itself and reads/writes all cluster state through etcd.

• What it stores: All API objects (Pods, Deployments, Secrets, ConfigMaps) and their current status.

• Only the API server talks to it: Every component reads and writes state through kube-apiserver, which is the sole client of etcd.

• Why it's authoritative: Controllers reconcile against what etcd reports; if it's not in etcd, it effectively doesn't exist in the cluster.

• Consistency and availability: Uses the Raft consensus algorithm and runs in odd-numbered clusters (3, 5) for quorum-based HA.

• Operational note: back up etcd regularly, since losing it means losing the cluster's entire state.

The kube-scheduler decides where a Pod runs (placement), while the kube-controller-manager runs the control loops that decide what should exist and keep reality matching desired state.

• kube-scheduler:

  • Single concern: assign unscheduled Pods to nodes via filtering and scoring, then create the binding.

  • It does not create Pods or start containers; it only sets nodeName.

• kube-controller-manager: A bundle of many reconciliation loops: the ReplicaSet controller creates Pods to meet replica counts, the Deployment controller manages rollouts, the Node controller marks nodes unhealthy, etc.

• How they interact: A controller creates a Pod object (no node yet), the scheduler assigns it a node, and the kubelet runs it: division of labor across the reconcile chain.

The image pull policy (imagePullPolicy) tells the kubelet when to fetch an image from the registry versus reuse the node's local cache. The main tradeoff is freshness versus speed/reliability.

• Always:

  • Checks the registry on every Pod start and pulls if the digest differs.

  • Guarantees you get the latest image behind a mutable tag, but adds registry dependency and startup latency.

• IfNotPresent:

  • Uses the local image if present, only pulling when it's missing.

  • Faster and resilient to registry outages, but can silently run a stale image if a tag was overwritten.

• Never: Only uses a preloaded local image; fails if absent. Useful for air-gapped setups.

• Defaults and best practice:

  • Default is Always when the tag is :latest (or no tag), otherwise IfNotPresent.

  • Prefer immutable tags or digests (@sha256:...) so caching is safe and deployments are reproducible.

Use a DaemonSet when you need exactly one copy of a Pod running on every node (or a subset), which is the classic pattern for node-level monitoring and logging agents.

• Why not a Deployment here:

  • A Deployment schedules N replicas wherever the scheduler fits them, with no guarantee of one-per-node.

  • A DaemonSet ties Pod placement to node membership: add a node, it gets the Pod automatically.

• Monitoring/logging example:

  • A log collector like Fluent Bit runs on each node to tail that node's container logs.

  • A metrics agent like node-exporter runs per node to expose host-level CPU/memory/disk metrics.

• Other typical DaemonSet uses: CNI networking plugins and kube-proxy-style components that must exist on every node.

A ReplicaSet maintains a fixed number of identical Pods placed anywhere in the cluster, while a DaemonSet ensures one Pod per node. The difference is what drives the replica count: a number versus the node set.

• ReplicaSet:

  • You declare replicas: N; the scheduler decides which nodes host them (multiple can land on one node).

  • Usually managed indirectly by a Deployment, not created directly.

• DaemonSet:

  • No replica count: the desired count equals the number of matching nodes.

  • Scales automatically as nodes join or leave; can target a subset via nodeSelector or tolerations.

• Typical DaemonSet use cases: Node-level agents: log collectors, metrics exporters, CNI plugins, storage daemons, security agents.

restartPolicy is a Pod-level field that tells the kubelet whether to restart a container after it exits. The three values behave differently based on whether the container succeeds or fails, and which values are legal depends on the workload type.

• Always (default):

  • Restarts the container regardless of exit code, with exponential backoff.

  • Required for Deployments, ReplicaSets, and long-running services.

• OnFailure:

  • Restarts only if the container exits non-zero; a clean exit (0) is left alone.

  • Common for Jobs that should retry until they succeed.

• Never: Never restarts; the Pod moves to Succeeded or Failed based on exit code.

• Workload constraints:

  • Deployments require Always; Jobs and CronJobs allow only OnFailure or Never.

  • The policy applies to all containers in the Pod and only governs local kubelet restarts, not rescheduling to another node.

A Pod's status.phase is a high-level summary of where it is in its lifecycle. It progresses from Pending through Running to a terminal Succeeded or Failed, with Unknown indicating lost node contact.

• Pending: Accepted by the API server but not yet running: waiting on scheduling, image pulls, or volume mounts.

• Running: Bound to a node with at least one container started (or still starting/restarting).

• Succeeded: All containers terminated with exit code 0 and will not be restarted.

• Failed: All containers have terminated and at least one exited non-zero (or was killed) with no further restarts.

• Unknown: The node's kubelet stopped reporting status, usually a node or network failure.

• What triggers Failed: A container exiting non-zero under restartPolicy: Never, exhausted OnFailure retries in a Job, being OOMKilled, or eviction/deadline exceeded.

initContainers run to completion sequentially before any regular (app) container starts, and are used for setup tasks that must finish first. Regular containers are the long-running workload and start only once all init containers have succeeded.

• Execution model:

  • Init containers run one at a time, in order; each must exit 0 before the next runs.

  • Regular containers all start together after init containers complete.

• Failure handling: A failing init container is retried per the Pod's restartPolicy, blocking app startup until it succeeds.

• Common use cases:

  • Waiting for a dependency (DB or service) to be reachable.

  • Running schema migrations or fetching config/secrets into a shared emptyDir volume.

  • Setting permissions or performing one-time setup with tools you don't want in the app image.

A sidecar is a helper container that runs alongside the main application container in the same Pod, sharing its network and volumes to extend or support the app without changing its code. It is a core pattern for offloading cross-cutting concerns.

• Why it works: Containers in a Pod share the same network namespace (localhost) and can share volumes, so the sidecar can proxy traffic or read/write the same files.

• Common use cases:

  • Service mesh proxy (e.g. Envoy) handling mTLS, routing, and telemetry.

  • Log shippers tailing a shared volume and forwarding to a log backend.

  • Config or secret reloaders and metrics exporters/adapters.

• Benefit: Keeps the app image focused while adding capabilities in a reusable, language-agnostic container.

CrashLoopBackOff means a container keeps starting then exiting, so the kubelet is backing off between restarts. The goal is to find why the container exits, so I start with logs, events, and configuration.

• 1. Container logs: kubectl logs <pod> --previous shows output from the crashed instance, often revealing a stack trace or missing config.

• 2. Pod events and state: kubectl describe pod <pod> surfaces the last exit code, OOMKilled, failing probes, or image pull errors.

• 3. Configuration and dependencies:

  • Check the command/args, required env vars, mounted ConfigMap/Secret, and whether the app's dependencies (DB, endpoints) are reachable.

  • Also verify a too-aggressive livenessProbe isn't killing a healthy but slow-starting container.

A Namespace is a virtual cluster inside a physical cluster: it scopes and isolates a group of resources, enabling multi-tenancy, quotas, and name reuse. Most workload resources are namespaced, while infrastructure-level resources are cluster-scoped and exist once for the whole cluster.

• What a Namespace gives you:

  • A naming boundary: two Pods named the same can coexist in different namespaces.

  • An attachment point for ResourceQuota, LimitRange, RBAC, and network policies.

  • DNS reflects it: services resolve as svc.namespace.svc.cluster.local.

• Namespaced resources: Pod, Deployment, Service, ConfigMap, Secret, PVC, Role/RoleBinding.

• Cluster-scoped resources: Node, PersistentVolume, Namespace itself, StorageClass, ClusterRole/ClusterRoleBinding.

• Check with: kubectl api-resources --namespaced=true/false.

Every Kubernetes object manifest shares a common structure: apiVersion and kind identify the type, metadata identifies the instance, spec declares your desired state, and status (managed by the system) reports the observed state.

• apiVersion: The API group and version (e.g. apps/v1, v1) that defines the schema.

• kind: The type of object (Pod, Deployment, Service).

• metadata: Identity and organization: name, namespace, labels, annotations, uid.

• spec: The desired state you author; controllers work to make reality match it.

• status: The actual observed state, written and continuously reconciled by the control plane; you don't set it.

A kubeconfig is a YAML file (default ~/.kube/config) that tells kubectl how to reach clusters and authenticate; a context bundles a cluster, a user, and a namespace so you can switch between environments with one command.

• Three main sections:

  • clusters: API server URL and its CA certificate.

  • users: credentials (client certs, tokens, or an exec/auth plugin).

  • contexts: a named pairing of one cluster + one user + a default namespace.

• Contexts enable multi-cluster work:

  • kubectl config get-contexts lists them; kubectl config use-context <name> switches the active one.

  • The current-context field marks which one commands target by default.

• Overriding without switching: Use flags like --context or the KUBECONFIG env var to merge/select files per shell.

Both are key-value metadata, but labels are identifying data used for selection and grouping, while annotations are non-identifying data for arbitrary information that tools and humans read but selectors ignore.

• Labels: selectable identity:

  • Used by selectors: Services find Pods, Deployments find their ReplicaSets, etc.

  • Constrained: short keys/values, limited characters, meant to be queryable.

  • Example: app=nginx, env=prod.

• Annotations: descriptive metadata:

  • Cannot be used in selectors.

  • Hold larger, arbitrary data: build IDs, commit hashes, config for controllers/ingress, kubectl.kubernetes.io/last-applied-configuration.

• Rule of thumb: if something needs to select or group objects, use a label; if it is just information or tool config, use an annotation.

An emptyDir is a scratch volume created empty when a Pod is assigned to a node and tied to that Pod's lifetime. It survives container crashes but is deleted permanently when the Pod is removed.

• Container crash or restart: Data persists: the kubelet restarts the container in the same Pod and remounts the same directory.

• Pod deletion (or reschedule): Data is lost: the directory is destroyed when the Pod leaves the node. Not durable storage.

• Common uses: Scratch space, caches, or sharing files between containers in the same Pod (e.g. a sidecar).

• Backing medium: Defaults to node disk; setting medium: Memory backs it with a tmpfs RAM disk (fast but counts against memory).

Both are node-local volumes, but emptyDir is Kubernetes-managed scratch space tied to the Pod, while hostPath mounts an existing path from the node's own filesystem, coupling the Pod to that node and its files.

• emptyDir:

  • Created empty by Kubernetes when the Pod starts; lives and dies with the Pod.

  • Isolated per Pod, so it's safe: no access to the node's real files.

• hostPath:

  • Mounts a specific file or directory from the host node into the Pod; data outlives the Pod on that node.

  • Ties the Pod to one node's data and is a security risk (can expose or modify host files), so it's discouraged for apps.

• When each fits: emptyDir for temporary/shared scratch; hostPath mainly for node-level agents (log collectors, monitoring) that genuinely need host access.

Skip Kubernetes when its operational complexity outweighs its benefits: small, simple, or low-scale workloads rarely need distributed scheduling, and the cost is real expertise, infrastructure, and maintenance.

• Small or simple apps: A single service or a few containers is better served by a PaaS, serverless, or plain Docker Compose.

• Limited team capacity: Kubernetes demands ongoing expertise (networking, RBAC, upgrades); without it, you inherit fragility rather than reliability.

• Low or predictable scale: If you don't need elastic scaling, self-healing across nodes, or rolling deploys, the overhead buys little.

• The tradeoffs:

  • Gains: portability, self-healing, declarative scaling, a rich ecosystem.

  • Costs: steep learning curve, cluster maintenance, more moving parts to debug.

• Rule of thumb: adopt Kubernetes when you have many services, real scaling needs, and a team able to operate it.

A controller is a loop that continuously observes the actual state of a resource, compares it to the declared desired state, and takes action to close the gap. This reconciliation loop is the core engine that makes Kubernetes declarative and self-healing.

• The loop steps:

  1. Observe: read the desired state (spec) and current state (status) from the API server.

  2. Diff: compute the difference between them.

  3. Act: make API calls to move current state toward desired (create/delete Pods, etc.).

• Desired vs. current: Desired lives in the object's spec; observed lives in its status; the controller drives one toward the other.

• Example: A ReplicaSet controller wanting 3 replicas but seeing 2 creates one more Pod, then loops again.

• Level-triggered, not edge-triggered: It reacts to the current state, not to one-time events, so it self-corrects even after missed events or crashes.

• Extensible: custom controllers/operators apply the same pattern to CRDs.

When you run kubectl apply -f, the CLI builds a desired-state object and sends it to the API server, which authenticates, authorizes, mutates, and validates it before persisting it to etcd; controllers and the scheduler then act on the stored state.

1. kubectl builds the request: It reads the manifest, computes a three-way merge patch (using the last-applied-configuration annotation), and issues an HTTP PATCH/POST to the API server using config from ~/.kube/config.

2. API server admission pipeline: Authentication (who are you), authorization (RBAC), then mutating admission webhooks, schema validation, and validating admission webhooks.

3. Persistence to etcd: The validated object is written to etcd, the single source of truth; a resource version is assigned.

4. Watchers react: Controllers and the scheduler watch the API server, observe the new/changed object, and reconcile actual state toward desired (e.g. scheduler binds a Pod, kubelet starts containers).

Key point: kubectl apply only records intent in etcd; the actual work is done asynchronously by controllers reconciling that state.

The control plane is the set of components that make global decisions about the cluster and detect/respond to events; it stores desired state and drives the cluster toward it.

• kube-apiserver: The front door: the only component that talks to etcd; serves the REST API, handles auth and admission, and is stateless (horizontally scalable).

• etcd: A consistent, distributed key-value store holding all cluster state; the single source of truth.

• kube-scheduler: Watches for unscheduled Pods and assigns each to a suitable node via filtering and scoring.

• kube-controller-manager: Runs the built-in control loops (Node, ReplicaSet, Deployment, Job, endpoints, etc.) that reconcile actual state to desired.

• cloud-controller-manager: Isolates cloud-provider-specific logic: load balancers, node lifecycle, and routes.

Node-level components (kubelet, kube-proxy) run on every worker but are not part of the control plane.

The kube-scheduler is a control plane component that decides which node a Pod belongs on, while the kubelet is the node agent that actually starts the containers; the kubelet (via the container runtime) does the starting.

• kube-scheduler: Runs once per cluster (with leader election); watches for Pods with no nodeName and binds each to a node. It never contacts the container runtime.

• kubelet: Runs on every node; watches the API server for Pods assigned to its node and reconciles them into running containers.

• Who starts the container: The kubelet calls the container runtime through the CRI (e.g. containerd), which pulls images and starts the containers, then reports status back.

• The handoff: Scheduler sets spec.nodeName → kubelet on that node picks it up → runtime runs it. Placement and execution are cleanly separated.

Communication is centered on the kube-apiserver: the control plane pushes work through the API server, and each node's kubelet pulls its assigned work by watching the API server. Node-to-control-plane traffic is the primary and most trusted direction.

• Node to control plane (primary path):

  • The kubelet opens a secured connection to the apiserver and watches for Pods scheduled to its node, then reports status back.

  • All components (controllers, scheduler, kubelets) talk only to the API server, never directly to each other: it is the single source of truth backed by etcd.

• Control plane to node (secondary paths):

  • The API server reaches back to nodes for kubectl logs, kubectl exec, and port-forwarding by connecting to the kubelet's port.

  • These connections default to HTTP without cert verification unless secured, so the Konnectivity service or an SSH tunnel is often used to harden them.

• Scheduler and controllers don't push to nodes: They write desired state (e.g. bind a Pod to a node) to the API server; the node's kubelet then acts on it. This decoupling is what makes the model level-triggered and self-healing.

The Container Runtime Interface (CRI) is a gRPC API contract that lets the kubelet talk to any container runtime in a standard way. Docker predated CRI and didn't speak it, so the kubelet carried a special adapter called dockershim; that adapter was deprecated and removed to eliminate the maintenance burden.

• What CRI provides: A pluggable, versioned interface (RuntimeService and ImageService) so runtimes like containerd and CRI-O work without kubelet code changes.

• Why dockershim existed: Docker isn't CRI-compliant, so the kubelet embedded dockershim to translate CRI calls into Docker's API.

• Why it was removed:

  • Maintaining a special-case shim in-tree for one runtime was extra burden, and Docker itself layers on top of containerd anyway (redundant plumbing).

  • Removed in Kubernetes v1.24; clusters moved to containerd or CRI-O.

• Common misconception: Images are unaffected: they follow the OCI standard, so images built with Docker still run fine under containerd. Only the node's runtime component changed.

A container runtime is the low-level software on each node that actually pulls images and runs containers; containerd and CRI-O are the common ones, and they plug into the kubelet through the standardized Container Runtime Interface (CRI).

• What the runtime does:

  • Pulls/unpacks OCI images, sets up namespaces and cgroups, and starts/stops container processes.

  • Often delegates the final low-level step to runc (an OCI runtime) to spawn the actual process.

• How it plugs into a node:

  • The kubelet talks to the runtime over the CRI gRPC API, so Kubernetes doesn't hardcode any one runtime.

  • Any CRI-compliant runtime is swappable without changing Kubernetes.

• containerd vs CRI-O:

  • containerd: general-purpose runtime (also used by Docker) with a CRI plugin.

  • CRI-O: minimal runtime built specifically for Kubernetes and the CRI.

• Historical note: Docker itself was removed as a direct runtime (dockershim deprecation), but containerd (which Docker uses under the hood) remains fully supported.

Containers in a Pod share the same network namespace because Kubernetes treats the Pod, not the container, as the smallest deployable unit: they get one shared IP and port space, so they reach each other over localhost.

• The Pod is the network boundary:

  • All containers in a Pod join one network namespace, sharing a single IP address and interface.

  • They communicate via localhost and must avoid colliding on the same port.

• How it's set up:

  • A pause (infra) container holds the namespace; app containers join it.

  • The namespace outlives individual container restarts, keeping the IP stable within the Pod's life.

• Why it's designed this way:

  • Enables tight sidecar patterns (proxy, logging agent) that talk to the main container locally.

  • Note: the network namespace is shared by default, but each container has its own filesystem unless you add shared volumes.

An OCI image is a container image built to the Open Container Initiative specification: a standard format of layered filesystem tarballs plus a JSON config/manifest. Kubernetes relies on this standard conceptually so it can run images from any tool or registry without caring who built them.

• What an OCI image contains:

  • A manifest listing layers, a config (entrypoint, env, architecture), and content-addressed layer blobs.

  • Layers are stacked to form the container's root filesystem.

• The OCI specs involved:

  • Image spec: the on-disk/registry image format.

  • Distribution spec: how images are pushed/pulled from registries.

  • Runtime spec: how an unpacked image is executed as a container.

• How Kubernetes leans on it:

  • The CRI runtime pulls and runs OCI images, so Kubernetes stays build-tool agnostic (Docker, Buildah, Kaniko all produce OCI images).

  • Standardization means an image runs the same across containerd, CRI-O, or any conformant runtime.

A Deployment manages stateless, interchangeable Pods; a StatefulSet manages stateful Pods that need stable identity and storage. Choose StatefulSet only when each replica must be uniquely and persistently addressable.

• Deployment (stateless):

  • Pods are identical and fungible with random names; any replica can serve any request.

  • Scaling and rollouts happen in parallel; storage (if any) is typically shared or ephemeral.

• StatefulSet (stateful):

  • Stable, ordinal Pod names (web-0, web-1) and stable DNS via a headless Service.

  • Each Pod gets its own persistent volume via volumeClaimTemplates that survives rescheduling.

  • Ordered, sequential creation, scaling, and updates.

• When to choose which:

  • Deployment: web servers, APIs, workers, anything stateless.

  • StatefulSet: databases, Kafka, ZooKeeper, clustered systems needing per-instance identity and disks.

A Job runs Pods to completion for a one-off task; a CronJob creates Jobs on a repeating schedule. Kubernetes handles failures by retrying Pods up to a configurable limit before marking the Job failed.

• Job:

  • Runs one or more Pods until a target number succeed, then stops (completions, parallelism).

  • Good for batch processing, migrations, one-time computations.

• CronJob:

  • Wraps a Job template with a cron schedule; each fire creates a new Job.

  • Controls history and overlap via concurrencyPolicy and successfulJobsHistoryLimit.

• How failures are handled:

  • A failed Pod is retried; backoffLimit caps retries (with exponential backoff) before the Job is marked Failed.

  • restartPolicy must be Never or OnFailure (not Always).

  • activeDeadlineSeconds can force a timeout on the whole Job.

A Deployment is a higher-level controller that manages ReplicaSets, and each ReplicaSet manages a set of identical Pods. The Deployment adds rollout and rollback logic on top by creating a new ReplicaSet per revision.

• Layered ownership: Deployment owns one or more ReplicaSets; each ReplicaSet owns the Pods matching its selector via ownerReferences.

• A ReplicaSet keeps replica count: Its only job is to ensure the desired number of Pods exist; it does not understand rollouts.

• Revisions map to ReplicaSets:

  • Changing the Pod template (e.g. a new image) makes the Deployment create a brand-new ReplicaSet and scale it up while scaling the old one down.

  • Old ReplicaSets are kept (scaled to 0) so kubectl rollout undo can scale a previous one back up.

• History limit: revisionHistoryLimit controls how many old ReplicaSets are retained for rollback.

Native sidecar containers (stable in Kubernetes 1.29+) are init containers declared with restartPolicy: Always. This gives them proper lifecycle guarantees the traditional multi-container pattern lacked: they start before app containers and shut down after them.

• Traditional pattern limitations:

  • A regular sidecar starts in parallel with the app, so the app may run before the proxy is ready.

  • In a Job, a sidecar that never exits keeps the Pod from completing.

• How native sidecars fix it:

  • Declared in initContainers with restartPolicy: Always, they start and become ready before main containers start.

  • They keep running throughout the Pod's life but are terminated after the main containers, and don't block Job completion.

Init containers run before regular containers, sequentially and to completion, and are meant for setup rather than serving the workload. Their ordering is strict and their resource accounting is treated specially by the scheduler.

• Execution order:

  1. Each init container runs in the order listed, one after another.

  2. The next starts only after the previous exits successfully (0).

  3. Regular containers start only after all init containers succeed.

• Retries on failure: A failed init container is restarted per the Pod restartPolicy (except Never, which fails the Pod).

• Resource limits:

  • Because init containers run one at a time, the Pod's effective init request is the max of any single init container.

  • The scheduler uses the higher of that init max and the sum of regular container requests.

Init containers run to completion before the app containers start and are for one-time setup; sidecars run alongside the main container for the life of the Pod, providing continuous supporting behavior.

• Init containers: sequential, run-once setup:

  • Run in order, each must succeed before the next starts, and all must finish before app containers launch.

  • Use cases: wait for a dependency (DB, service), clone git config, run schema migrations, set file permissions, populate a shared volume.

  • Can use a different image with tools the main app doesn't need (e.g. git, kubectl).

• Sidecar containers: long-running companions:

  • Share the Pod's network and volumes with the main container and run for its whole lifetime.

  • Use cases: log shippers, service-mesh proxies (Envoy), metrics exporters, config/secret reloaders.

  • Since 1.28+, native sidecars are declared as initContainers with restartPolicy: Always, so they start before app containers and shut down after them.

• Rule of thumb: setup that must complete first, use an init container; a helper that runs continuously, use a sidecar.

Both inject configuration into Pods, but ConfigMaps hold non-sensitive plain-text data while Secrets hold sensitive data; however, Secrets are only base64-encoded, not encrypted, so they are not truly secure by default.

• ConfigMap: non-sensitive config:

  • Stored as plain text (log levels, URLs, feature flags).

  • Consumed as env vars, command args, or mounted files.

• Secret: sensitive config:

  • Passwords, tokens, TLS keys; typed (e.g. kubernetes.io/tls, Opaque).

  • Same API shape as a ConfigMap but with security-oriented handling.

• Are Secrets secure by default? Not really:

  • Values are base64-encoded, which is trivially reversible, not encryption.

  • By default they are stored in etcd unencrypted, so anyone with etcd or API read access can read them.

  • Harden with encryption-at-rest, RBAC restrictions, and an external secret store (Vault).

Environment variables are read once at container startup and are static thereafter, while volume-mounted ConfigMaps are updated live in the running Pod: so an env-var config needs a restart to change, but a mounted file eventually reflects updates without one.

• As environment variables:

  • Injected when the container process starts; the running process keeps the old values.

  • Updating the ConfigMap does not change existing Pods; you must restart/roll the Pod to pick up new values.

  • Simple and app-friendly, but not dynamic.

• As a mounted volume:

  • Each key becomes a file; the kubelet periodically syncs updates (via symlink swap), so files change without a restart.

  • Propagation is not instant (sync period plus cache delay).

  • Caveat: the app must actually re-read the file (watch/reload); otherwise the update is invisible to it.

• Note: subPath mounts do NOT receive live updates.

Secrets are insecure by default because they are merely base64-encoded (not encrypted) and stored in plaintext in etcd, so anyone with etcd access or broad API permissions can read them; you improve this with encryption at rest, strict RBAC, and external secret managers.

• Why they're weak by default:

  • base64 is encoding, not encryption: anyone can decode it.

  • Stored unencrypted in etcd unless you configure otherwise.

  • Readable by any subject with get/list on Secrets in the namespace.

• How to harden them:

  1. Enable EncryptionConfiguration for encryption-at-rest, ideally backed by a KMS provider.

  2. Lock down RBAC so only the workloads/users that need a Secret can read it.

  3. Use an external store (HashiCorp Vault, cloud secret managers) via CSI driver or External Secrets Operator.

  4. Enable audit logging, rotate secrets, and avoid baking them into images or env dumps.

Mount the ConfigMap as a volume (not env vars): the kubelet periodically syncs the updated data into the mounted files while the Pod keeps running, so no restart is needed, provided the app re-reads the files.

• Mount as a volume:

  • Edit the ConfigMap (kubectl apply or kubectl edit); the kubelet propagates the change to the mounted files within a sync period (up to ~1 minute).

  • The app must watch or re-read the file for the change to take effect.

• What does NOT auto-update: Env-var references and subPath mounts stay frozen at startup values, requiring a Pod restart.

• Trigger a controlled reload:

  • If the app can't hot-reload, do a rollout: kubectl rollout restart deployment.

  • A common pattern is a checksum annotation on the Pod template so changing the ConfigMap triggers a new rollout automatically.

The spec is the desired state you declare, and the status is the observed state the system reports; controllers work to make status match spec.

• spec: desired state:

  • Written by the user (or a higher-level controller) via kubectl apply or the API.

  • Declares intent: how many replicas, which image, which ports.

• status: observed state:

  • Written by the controller/kubelet, not by you.

  • Reports reality: current replicas, conditions, pod IPs, phase.

• The reconciliation loop is the link: A controller continuously compares spec to status and takes action to close the gap.

• Practical rule: edit spec, read status. Manually editing status is almost never correct.

Label selectors filter objects by their labels; equality-based selectors match exact values, while set-based selectors match against a set of values with in, notin, and existence operators.

• Equality-based:

  • Operators: =, ==, !=.

  • Comma-separated terms are AND-ed: env=prod,tier=frontend.

• Set-based:

  • Operators: in, notin, and existence (key present / !key).

  • Example: env in (prod, staging).

• Where they appear:

  • Older resources (like older Services/RCs) use the equality-based selector map only.

  • Newer resources (Deployments, ReplicaSets) use matchLabels (equality) plus matchExpressions (set-based).

These are Service types that expose Pods at increasing scope: ClusterIP is internal only, NodePort opens a port on every node, and LoadBalancer provisions an external load balancer; a Headless Service skips load balancing entirely to expose individual Pod IPs.

• ClusterIP (default):

  • Stable virtual IP reachable only inside the cluster.

  • Use for internal service-to-service traffic.

• NodePort:

  • Opens a static port (30000-32767) on every node that forwards to the Service.

  • Use for basic external access or as a building block behind an external LB.

• LoadBalancer:

  • Asks the cloud provider for an external load balancer; builds on NodePort.

  • Use for production external exposure of a single service.

• Headless Service (clusterIP: None):

  • No virtual IP or proxying; DNS returns the individual Pod IPs.

  • Use when clients need direct Pod addressing: StatefulSets, databases, custom load balancing.

kube-proxy runs on every node and implements Service networking: it watches Services and Endpoints and programs rules so that traffic to a Service's virtual IP is load-balanced to backing Pods. Its iptables mode scales linearly, while IPVS mode uses hash tables for better performance at large scale.

• Role of kube-proxy:

  • Translates the virtual ClusterIP into real Pod endpoints and load-balances across them.

  • Reconciles rules as endpoints change; it does not proxy packets itself in these modes (the kernel does).

• iptables mode:

  • Uses sequential chains of rules; rule lookup and updates are O(n) in the number of Services/endpoints.

  • Fine at modest scale but slows down with thousands of services.

• IPVS mode:

  • Uses in-kernel hash tables, so lookups and updates are roughly O(1) and scale to many services.

  • Offers multiple LB algorithms (round-robin, least-connection, etc.).

• Trend: newer setups increasingly replace kube-proxy with eBPF-based dataplanes (e.g. Cilium) for further gains.

CoreDNS is the cluster DNS server that maps Service and Pod names to their cluster IPs, letting workloads reach each other by stable name instead of ephemeral IP.

• Runs as a Deployment behind a Service: Exposed at a well-known ClusterIP (the kube-dns Service), and every Pod's /etc/resolv.conf points at it via the kubelet.

• Watches the API server: The kubernetes plugin builds DNS records live from Service and Endpoint objects, so records update as Pods come and go.

• Naming convention: A Service resolves as <service>.<namespace>.svc.cluster.local; search domains let same-namespace lookups use just <service>.

• Record types: Normal Services get an A/AAAA record to the ClusterIP; headless Services return one record per Pod IP.

A NetworkPolicy is a namespaced resource that defines allowed ingress/egress traffic for Pods selected by labels; it enables zero-trust because once any policy selects a Pod, everything not explicitly allowed is denied.

• Selects Pods by label: podSelector chooses which Pods the rules apply to; an empty selector matches all Pods in the namespace.

• Default-deny is the key to zero-trust: Pods are open by default, but as soon as one policy selects a Pod, only explicitly permitted traffic is allowed (implicit deny for the rest).

• Allow rules by identity, not IP: Peers are chosen via podSelector, namespaceSelector, or ipBlock, so rules follow workload identity as Pods reschedule.

• Enforced by the CNI: Requires a policy-capable plugin (Calico, Cilium); without one the API object is ignored.

A headless Service is a Service with clusterIP: None: instead of load-balancing through a single virtual IP, DNS returns the individual Pod IPs, giving clients stable per-Pod addressing.

• No ClusterIP, no proxying: DNS returns one A record per ready Pod rather than a single load-balanced IP, so the client picks the endpoint.

• Stable per-Pod DNS with StatefulSets: Each Pod gets <pod>.<service>.<namespace>.svc.cluster.local, giving predictable identity that survives restarts.

• Why databases need it: Replicas aren't interchangeable: clients must reach a specific primary or replica for replication, quorum, or sharding, which a random load-balanced IP can't guarantee.

A CNI (Container Network Interface) plugin is the component that wires up Pod networking: it assigns IPs and sets up the routes so Pods can talk to each other across nodes. Kubernetes defines the interface but delegates the implementation so operators can pick the networking model that fits their environment.

• What it does: On Pod creation the kubelet calls the plugin to attach a network interface, assign an IP from the cluster CIDR, and program routes/iptables so the flat Pod network works.

• Why it's pluggable:

  • Kubernetes only mandates the model (every Pod gets an IP, all Pods reach each other without NAT); it doesn't dictate how.

  • Networking varies wildly (cloud VPCs, on-prem, overlays), so a fixed built-in implementation would be limiting.

• Different plugins, different tradeoffs:

  • Flannel: simple overlay (VXLAN), easy but no policy.

  • Calico/Cilium: BGP or eBPF routing plus NetworkPolicy enforcement and richer features.

A Service uses a label selector to continuously match Pods; the matching Pod IPs are recorded in Endpoints/EndpointSlice objects, which kube-proxy turns into the routing rules behind the Service's ClusterIP.

• Labels and selectors: Pods carry labels (e.g. app: web); the Service's selector declares which labels to match. Membership is dynamic, not a fixed list.

• The endpoints controller: Watches Pods matching the selector and writes their IP:port into Endpoints/EndpointSlice objects, keeping only ready Pods.

• Endpoints vs EndpointSlice: EndpointSlice is the modern, scalable form: it splits large backend sets across multiple objects instead of one giant Endpoints blob.

• kube-proxy closes the loop: It reads the slices and programs iptables/IPVS rules so traffic to the ClusterIP is DNAT'd to a real backend Pod.

A NetworkPolicy is a Kubernetes resource that controls Pod-to-Pod traffic using label-based identity; unlike a traditional firewall that filters on static IPs and ports at the network edge, it enforces identity-aware rules that follow workloads as they move.

• Identity vs address: Rules target Pods by labels and namespaces (podSelector, namespaceSelector), so they stay valid even as Pod IPs churn. A classic firewall pins to IP/CIDR that go stale.

• Distributed, not perimeter: Enforced by the CNI at each Pod (east-west), giving micro-segmentation inside the cluster rather than only guarding the edge.

• Declarative and namespaced: Defined as versioned YAML alongside apps and reconciled continuously, versus manually managed firewall appliances.

• Default-allow until selected: Pods accept all traffic until a policy selects them, then it becomes deny-by-default for that Pod.

An ExternalName Service maps a cluster DNS name to an external DNS name via a CNAME record; it has no selector, no ClusterIP, and no proxying, it just aliases an outside host.

• How it works: CoreDNS returns a CNAME to the value of spec.externalName (e.g. db.example.com); no endpoints or load balancing are involved.

• When to use it:

  • Reference an external managed service (a cloud database, a third-party API) through an in-cluster name so apps use a stable internal alias.

  • Lets you later swap the target to an in-cluster Service without changing app config.

• Caveats: Works at DNS level only, so it doesn't handle ports or TLS SNI rewriting; the client must connect to the resolved host correctly.

Session affinity makes a Service route all requests from the same client IP to the same backend Pod, instead of load-balancing each connection independently.

• Default behavior: With sessionAffinity: None (the default), kube-proxy spreads connections randomly across ready endpoints.

• Client-IP affinity:

  • Set sessionAffinity: ClientIP to pin a source IP to one Pod based on a hash of the client address.

  • A timeout controls how long the mapping lasts via sessionAffinityConfig.clientIP.timeoutSeconds (default 10800s).

• Limitations:

  • It is L3/L4 only (IP-based), not cookie-based; clients behind the same NAT all land on one Pod.

  • For true sticky sessions with cookies, use an Ingress/L7 load balancer instead.

A request is what the scheduler reserves for a container (used for placement); a limit is the hard ceiling the runtime enforces. Exceeding the CPU limit throttles the container, but exceeding the memory limit kills it.

• requests = guaranteed minimum:

  • The scheduler only places a Pod on a node with enough allocatable capacity to satisfy the sum of requests.

  • It reflects what the container is expected to use, not a cap.

• limits = enforced maximum: The container runtime (via cgroups) prevents the container from exceeding it.

• CPU limit exceeded: throttling: CPU is a compressible resource, so the container is CPU-throttled (slowed), never killed.

• Memory limit exceeded: OOMKill: Memory is incompressible; the kernel OOM-killer terminates the container and kubelet reports OOMKilled, then restarts it per its restart policy.

Kubernetes assigns a QoS class automatically based on how a Pod sets requests and limits across its containers. The class (Guaranteed, Burstable, BestEffort) determines how likely the Pod is to be evicted under node pressure.

• Guaranteed:

  • Every container sets both CPU and memory limits, and requests equal limits.

  • Highest priority: evicted last.

• Burstable:

  • At least one container has a request or limit set, but it doesn't meet the Guaranteed criteria.

  • Middle priority: evicted after BestEffort but before Guaranteed.

• BestEffort:

  • No container sets any requests or limits.

  • Lowest priority: evicted first under resource pressure.

• Eviction ordering: Under memory pressure the kubelet evicts BestEffort first, then Burstable pods exceeding their requests, and reclaims from Guaranteed last.

Pod anti-affinity tells the scheduler to keep certain Pods apart, so replicas of the same app don't all land on one node or zone. This spreads failure domains, which is central to high availability.

• How it works: Rules match other Pods by label selector and repel from them across a topologyKey (e.g. kubernetes.io/hostname for per-node, topology.kubernetes.io/zone for per-zone).

• Hard vs soft:

  • requiredDuringSchedulingIgnoredDuringExecution: mandatory; the Pod stays Pending if the rule can't be met.

  • preferredDuringSchedulingIgnoredDuringExecution: best-effort; the scheduler tries but will co-locate if needed.

• Why it matters for HA:

  • If all replicas share a node and that node fails, the whole service goes down; spreading them survives node/zone loss.

  • Note: topologySpreadConstraints is often a more flexible modern alternative for even distribution.

Taints are applied to nodes to repel Pods, and tolerations are applied to Pods to allow (but not force) them onto tainted nodes. Together they let you reserve nodes for specific workloads.

• Taint on a node:

  • Format key=value:effect; applied with kubectl taint nodes.

  • Effects: NoSchedule (won't schedule new Pods), PreferNoSchedule (soft avoid), NoExecute (also evicts running Pods lacking a toleration).

• Toleration on a Pod:

  • Matches a taint's key, value, and effect so the Pod is allowed onto that node.

  • A toleration only permits scheduling; it does not attract the Pod to that node.

• Common uses:

  • Dedicated nodes (GPU, licensed software), and control-plane node protection.

  • Kubernetes itself uses NoExecute taints like node.kubernetes.io/not-ready to evict Pods off unhealthy nodes.

The Horizontal Pod Autoscaler (HPA) periodically compares an observed metric against a target and adjusts a workload's replica count using a ratio formula. It reads metrics from the metrics APIs, not directly from Pods.

• The scaling formula:

  • desiredReplicas = ceil(currentReplicas * currentMetric / desiredMetric).

  • A tolerance (default 10%) prevents scaling on tiny fluctuations.

• Metrics it can use:

  • Resource metrics: CPU and memory utilization vs the Pod's requests.

  • Custom metrics (per-Pod, e.g. requests/sec) and external metrics (queue depth from outside the cluster).

• Where the metrics come from:

  • Resource metrics via metrics.k8s.io, served by the metrics-server.

  • Custom/external via custom.metrics.k8s.io / external.metrics.k8s.io adapters (e.g. Prometheus adapter).

• Behavior details:

  • Runs on a control loop (default every 15s), and stabilization windows plus scaling policies dampen flapping, especially on scale-down.

  • Requires the target workload to define resource requests for utilization-based scaling to work.

Taints/tolerations and node affinity both influence Pod placement, but they work in opposite directions: taints repel Pods from nodes unless tolerated, while node affinity attracts Pods to nodes matching labels. One is a node saying "stay away," the other is a Pod saying "I want to go there."

• Taints and tolerations (repulsion):

  • Taint on the node (key=value:effect) repels all Pods that lack a matching toleration.

  • Toleration only grants permission to land on a tainted node; it does not guarantee placement there.

• Node affinity (attraction):

  • Set on the Pod; matches node labels to prefer or require specific nodes.

  • Supports requiredDuringSchedulingIgnoredDuringExecution (hard) and preferredDuringSchedulingIgnoredDuringExecution (soft).

• Key difference:

  • Affinity pulls Pods toward nodes; taints push Pods away unless tolerated.

  • They're complementary: use taints to reserve a node, and node affinity/toleration together to steer the right Pods onto it exclusively.

NodeAffinity attracts Pods to nodes based on node labels, while PodAntiAffinity repels Pods away from other Pods based on Pod labels: one targets node characteristics, the other governs Pod-to-Pod co-location.

• NodeAffinity:

  • Matches node labels (e.g. disktype=ssd, zone, instance type) to place Pods on suitable hardware.

  • The modern, expressive replacement for nodeSelector.

• PodAntiAffinity:

  • Matches labels on other Pods and keeps the new Pod away from nodes (or topology domains) already running matching Pods.

  • Uses a topologyKey (e.g. kubernetes.io/hostname) to define the domain of separation.

  • Common use: spread replicas across nodes/zones so one failure doesn't take down all replicas.

• Key contrast: NodeAffinity answers "which nodes can I run on?"; PodAntiAffinity answers "which Pods should I avoid sharing a domain with?"

Required rules are hard constraints the scheduler must satisfy or the Pod stays Pending; preferred rules are soft weights the scheduler tries to honor but will ignore if needed to place the Pod.

• requiredDuringSchedulingIgnoredDuringExecution:

  • Must be met at scheduling time; if no node qualifies, the Pod remains unscheduled.

  • IgnoredDuringExecution means once running, later label changes won't evict the Pod.

• preferredDuringSchedulingIgnoredDuringExecution: A list of preferences, each with a weight (1-100); the scheduler scores nodes and picks the best but never refuses to schedule.

• Practical rule: Use required for correctness/hard placement needs; use preferred for best-effort spreading or optimization where availability matters more than perfect placement.

Both constrain resources in a namespace, but ResourceQuota caps the aggregate consumption across the whole namespace, while LimitRange sets per-object (per-Pod/container) defaults and bounds.

• ResourceQuota:

  • Limits totals: sum of CPU/memory requests and limits, plus object counts (Pods, Services, PVCs).

  • If a namespace uses quotas for compute, every Pod must declare requests/limits or creation is rejected.

• LimitRange:

  • Operates per container/Pod: sets default and defaultRequest values, plus min/max bounds.

  • Auto-injects defaults so Pods without explicit requests still get sensible values (and satisfy quotas).

• The two combine: LimitRange ensures each Pod is reasonably sized; ResourceQuota ensures the namespace as a whole doesn't exceed its share.

The VerticalPodAutoscaler (VPA) adjusts a Pod's CPU/memory requests and limits to match observed usage (scaling up/down), whereas the HorizontalPodAutoscaler (HPA) changes the number of replicas.

• VPA (scale in size):

  • Recommends and can apply right-sized requests/limits per container based on historical usage.

  • Modes: Off (recommendations only), Initial, and Auto (evicts and recreates Pods to apply new sizes).

• HPA (scale in count): Adds/removes replicas based on metrics like CPU utilization or custom metrics.

• Key differences:

  • VPA fits workloads that can't easily be replicated (single-instance, stateful); HPA fits stateless, horizontally scalable services.

  • Combining VPA and HPA on the same CPU/memory metric conflicts; use HPA on custom metrics or restrict VPA to memory to coexist.

The metrics-server is a lightweight cluster add-on that collects real-time CPU and memory usage from kubelets and exposes it via the Metrics API, which the HPA and kubectl top consume for scaling decisions.

• How it works:

  • Scrapes resource usage from each node's kubelet (Summary API) at a short interval.

  • Serves aggregated Pod/node metrics through the metrics.k8s.io API (registered via the aggregation layer).

• Feeding autoscaling:

  • The HPA queries the Metrics API, compares current utilization to the target, and computes the desired replica count.

  • VPA recommendations also draw on this usage data.

• Important scope:

  • It holds only recent, in-memory metrics (not historical storage): it's for autoscaling, not monitoring (use Prometheus for history).

  • Custom/external metrics require a separate adapter (e.g. Prometheus Adapter), not the metrics-server.

The Cluster Autoscaler (CA) adjusts the number of nodes in a cluster based on Pod scheduling pressure: it adds nodes when Pods can't be scheduled and removes nodes that are underutilized.

• Scale up trigger:

  • When Pods are Pending because no node has sufficient CPU/memory (or matching affinity/taints), CA provisions a new node from a node group.

  • It simulates whether adding a node from a group would let the pending Pods schedule before acting.

• Scale down trigger:

  • A node is removed when it's underutilized for a period and all its Pods can be rescheduled elsewhere.

  • Blocked by Pods that can't move: those without a controller, using local storage, or restricted by PodDisruptionBudget.

• Works on node groups: CA operates via cloud node groups (e.g. AWS ASGs, GKE node pools), changing the desired count rather than launching VMs directly.

• Distinct from HPA: HPA scales Pod replicas; CA scales nodes. They complement each other: HPA adds Pods, CA adds nodes to fit them.

A PersistentVolume (PV) is a piece of storage in the cluster; a PersistentVolumeClaim (PVC) is a user's request to consume it. A StorageClass automates creating the PV on demand so admins don't pre-provision storage manually.

• PersistentVolume (PV):

  • A cluster resource representing real storage (EBS volume, NFS share), with a capacity, access modes, and reclaim policy.

  • Its lifecycle is independent of any Pod.

• PersistentVolumeClaim (PVC):

  • A namespaced request specifying size and access mode; Kubernetes binds it to a suitable PV.

  • Pods mount the PVC, not the PV directly, keeping workloads decoupled from storage details.

• StorageClass enables dynamic provisioning:

  • When a PVC references a storageClassName, its provisioner creates a matching PV automatically instead of requiring a pre-made one.

  • Without a StorageClass, binding is static: an admin must create PVs manually beforehand.

Dynamic provisioning means storage volumes are created on demand when a PVC is submitted, rather than being manually pre-provisioned by an administrator. StorageClasses are the mechanism that makes this possible.

• The problem it solves: Static provisioning requires admins to create PVs ahead of time, which doesn't scale and wastes capacity.

• How StorageClass drives it:

  • Each StorageClass names a provisioner (a CSI driver) plus parameters like disk type or IOPS.

  • When a PVC requests that class, the provisioner creates real backend storage and a bound PV automatically.

• Useful controls:

  • A default StorageClass is used when a PVC omits storageClassName.

  • volumeBindingMode: WaitForFirstConsumer delays creation until a Pod is scheduled, so the volume lands in the right zone.

Access modes declare how many nodes can mount a volume and whether they can write. They matter because they must match what the underlying storage actually supports, or the Pod won't schedule or the data model will break.

• ReadWriteOnce (RWO): Mounted read-write by a single node (multiple Pods on that node can share it). Typical for block storage like EBS.

• ReadWriteMany (RWX): Mounted read-write by many nodes at once. Requires a shared filesystem (NFS, CephFS); block volumes can't do this.

• ReadOnlyMany (ROX): Mounted read-only by many nodes: good for distributing static, immutable data.

• Why it matters:

  • A PVC requesting RWX only binds a PV that supports it, so choosing wrong causes unschedulable Pods.

  • RWO is why block-backed StatefulSets pin Pods and can't spread writers across nodes.

  • Note: newer clusters also have ReadWriteOncePod, restricting access to a single Pod.

The reclaim policy decides what happens to a PV's underlying storage after its bound PVC is deleted: Retain keeps it, Delete destroys it, and Recycle (deprecated) wipes and reuses it.

• Retain:

  • PV and its data are kept; the PV moves to Released state and is not reused automatically.

  • An admin must manually reclaim or clean up the data: safest for important data.

• Delete:

  • Deleting the PVC also deletes the PV and the backend storage (e.g. the cloud disk).

  • The default for dynamically provisioned volumes: convenient but destructive.

• Recycle: Performs a basic scrub (rm -rf) and makes the PV available again. Deprecated in favor of dynamic provisioning.

• Set it via: persistentVolumeReclaimPolicy on the PV, or reclaimPolicy on a StorageClass for dynamically created PVs.

The Downward API lets a Pod expose information about itself and its environment to the containers inside it, without the app needing to query the Kubernetes API. It surfaces metadata as environment variables or as files in a volume.

• Two delivery mechanisms:

  • Environment variables via fieldRef / resourceFieldRef.

  • A downwardAPI volume that mounts each item as a file (good for values that change, like labels).

• Pod-level fields (fieldRef):

  • metadata.name, metadata.namespace, metadata.uid, metadata.labels, metadata.annotations.

  • status.podIP, spec.nodeName, spec.serviceAccountName, status.hostIP.

• Container resource fields (resourceFieldRef): The container's CPU/memory requests and limits, useful for tuning app behavior (e.g. GC or thread pools) to its allocation.

• What it does NOT give: It only exposes the Pod's own metadata, not arbitrary cluster objects; for that you query the API server with a service account.

Ephemeral storage is the local, node-backed scratch space a container uses that doesn't survive the Pod: the writable container layer, emptyDir volumes, and logs. You can set requests and limits on ephemeral-storage just like CPU and memory.

• What counts as ephemeral storage:

  • The container's writable layer, emptyDir volumes, and container/log output on the node's filesystem.

  • It does NOT include persistent volumes or read-only image layers.

• How requests and limits behave:

  • requests.ephemeral-storage is used by the scheduler to place the Pod on a node with enough capacity.

  • limits.ephemeral-storage caps usage; exceeding it causes the kubelet to evict the Pod.

• Why it matters: Without limits, a Pod writing runaway logs or temp files can fill the node disk and trigger node-wide disk-pressure evictions affecting other Pods.

Both grant permissions to Kubernetes resources, but a Role is namespaced (its rules apply only within one namespace) while a ClusterRole is cluster-scoped and can grant access across all namespaces or to cluster-wide resources.

• Role:

  • Defines permissions on namespaced resources (Pods, Services, Deployments) within a single namespace.

  • Bound with a RoleBinding in that same namespace.

• ClusterRole:

  • Can cover cluster-scoped resources (nodes, persistentvolumes, namespaces) and non-resource URLs (/healthz).

  • Also reusable: define once and apply broadly.

• How binding decides the scope:

  • A ClusterRoleBinding grants a ClusterRole's permissions cluster-wide.

  • A RoleBinding can also reference a ClusterRole, applying its rules only within that one namespace (a common reuse pattern).

RBAC (Role-Based Access Control) governs who can perform which actions on which Kubernetes resources by binding subjects (users, groups, ServiceAccounts) to sets of permissions. The scope difference is simple: a RoleBinding grants access within a single namespace, while a ClusterRoleBinding grants access cluster-wide.

• Two permission objects:

  • Role: a namespaced set of rules (verbs on resources) that only applies inside one namespace.

  • ClusterRole: a cluster-scoped rule set, usable for cluster-wide resources (nodes, PVs) or as a reusable template across namespaces.

• Two binding objects:

  • RoleBinding: attaches a Role (or a ClusterRole) to subjects, but grants only within its own namespace.

  • ClusterRoleBinding: attaches a ClusterRole to subjects across every namespace and cluster-scoped resources.

• Useful combination: A RoleBinding can reference a ClusterRole: you define permissions once cluster-wide, then grant them namespace by namespace.

• Additive only: RBAC has no deny rules, permissions only accumulate, and access is denied by default.

A ServiceAccount is an identity for processes running in Pods (as opposed to human users), used to authenticate to the API server and to be the subject of RBAC bindings. Create a custom one whenever an app needs to call the Kubernetes API or requires permissions distinct from other workloads, so you can scope access tightly instead of relying on the shared default account.

• What it is:

  • A namespaced object; every namespace has a default ServiceAccount that Pods use if none is specified.

  • Kubernetes projects a short-lived token into the Pod so it can authenticate to the API server.

• When to create your own:

  • The app talks to the API (controllers, operators, CI agents) and needs specific verbs on specific resources.

  • You want least privilege: a dedicated identity per workload so a compromise is contained.

  • You need to bind cloud IAM roles (e.g. IRSA, Workload Identity) to a specific SA.

• If the Pod never calls the API, disable token mounting with automountServiceAccountToken: false.

A SecurityContext defines privilege and access-control settings for a Pod or an individual container, controlling how the container process runs at the kernel and filesystem level. It is the primary mechanism for hardening workloads (dropping root, restricting capabilities, making filesystems read-only).

• Two levels:

  • Pod-level (spec.securityContext): applies to all containers, e.g. fsGroup for volume ownership.

  • Container-level (containers[].securityContext): overrides Pod-level for that container.

• Common restrictions:

  • runAsNonRoot: true and runAsUser/runAsGroup: force a non-root UID.

  • allowPrivilegeEscalation: false: block gaining more privileges than the parent process.

  • readOnlyRootFilesystem: true: make the container filesystem immutable.

  • capabilities: drop ALL and add back only what is needed.

  • privileged: true, seccompProfile, and SELinux/AppArmor options for finer kernel control.

The Pod Security Standards are three cumulative security profiles defined by Kubernetes that describe how restrictive a Pod's configuration must be. They are policy-agnostic definitions; Pod Security Admission (or a third-party tool) actually enforces them via the enforce, audit, and warn modes.

• Privileged: Unrestricted, allows known privilege escalations. Intended for trusted, system-level workloads (CNI, storage drivers).

• Baseline: Minimally restrictive: prevents known privilege escalations (no privileged, no host namespaces, limited capabilities) while staying easy to adopt for most apps.

• Restricted: Heavily hardened, follows current best practices: requires runAsNonRoot, dropping ALL capabilities, allowPrivilegeEscalation: false, and a restricted seccomp profile.

• Mapping to enforcement: Each standard is a level you attach to a mode via namespace labels, e.g. enforce baseline while you warn on restricted to plan a migration.

A Pod Disruption Budget (PDB) limits how many Pods of an application can be voluntarily disrupted at once, guaranteeing a minimum level of availability during operations like node drains and cluster upgrades. It ensures maintenance doesn't take down more replicas than your app can tolerate.

• Voluntary vs involuntary disruptions:

  • A PDB only guards voluntary disruptions (kubectl drain, node autoscaler scale-down, upgrades).

  • It cannot protect against involuntary events (hardware failure, kernel panic, node crash).

• How you configure it:

  • minAvailable: minimum number/percentage of Pods that must stay running.

  • maxUnavailable: maximum that can be down at once; set one or the other, not both.

  • A selector matches the Pods it governs.

• How it works in practice:

  • The eviction API respects the PDB: a drain blocks (waits) rather than evicting a Pod that would violate the budget.

  • Needs enough replicas to make sense: a single-replica app with minAvailable: 1 will block drains entirely.

An owner reference is a field in an object's metadata pointing to a parent object; it tells the garbage collector that this object is a dependent and should be deleted when its owner is gone.

• Where it lives: Set in metadata.ownerReferences with the owner's apiVersion, kind, name, and uid.

• Who sets it: Controllers set it automatically: a Deployment owns its ReplicaSet, which owns its Pods.

• How it drives GC:

  • The garbage-collector controller watches objects; when an owner is deleted, it deletes dependents that reference it.

  • An object with no remaining owners (that once had a blockOwnerDeletion chain) becomes eligible for cleanup.

• Scope rule: Cross-namespace ownership is not allowed; a namespaced dependent must have an owner in the same namespace (or a cluster-scoped owner).

Cordon marks a node unschedulable so no new pods land on it; drain builds on that by also evicting existing pods so you can safely take the node down for maintenance.

• cordon: Sets spec.unschedulable: true; the scheduler stops placing new pods there but running pods stay untouched.

• drain:

  • Cordons first, then evicts pods respecting PodDisruptionBudgets so availability minimums are honored.

  • Controllers reschedule the evicted pods onto other nodes.

• Common flags: --ignore-daemonsets (DaemonSet pods are managed per-node), --delete-emptydir-data (accept loss of ephemeral data).

• Recovery: After maintenance, kubectl uncordon makes the node schedulable again.

All three are health checks run by the kubelet, but they answer different questions: startup asks "has it booted?", readiness asks "can it serve traffic?", and liveness asks "is it still healthy or stuck?"

• Liveness: Detects a deadlocked or broken container; on failure the kubelet kills and restarts it.

• Readiness: Signals whether the pod should receive traffic; on failure the pod is removed from Service Endpoints but is NOT restarted.

• Startup: Guards slow-booting apps; while it runs, liveness and readiness are disabled. On failure (past failureThreshold × periodSeconds), the container is killed and restarted.

• Failure summary: Liveness fails: restart. Readiness fails: no traffic. Startup fails: restart (never marked started).

RollingUpdate replaces old pods with new ones incrementally so the app stays available; maxSurge and maxUnavailable bound how many extra pods can be created and how many can be missing at any moment.

• How it proceeds: The Deployment scales up a new ReplicaSet and scales down the old one in steps, waiting for new pods to become Ready before continuing.

• maxSurge: How many pods above the desired count may exist during the rollout (absolute number or %); higher = faster but more resource use.

• maxUnavailable: How many pods below the desired count may be unavailable; 0 means never drop capacity (requires surge headroom).

• Defaults: Both default to 25%; they cannot both be 0.

• Readiness matters: A rollout only advances when new pods pass their readiness probe, so bad configs stall rather than take down the service.

RollingUpdate favors zero-downtime by overlapping old and new versions; Recreate favors simplicity and clean version separation by terminating all old pods before starting new ones, at the cost of downtime.

• RollingUpdate:

  • Pro: no downtime, gradual exposure, easy to pause/rollback mid-flight.

  • Con: two versions run simultaneously, so the app and its schema/API must be backward compatible.

• Recreate:

  • Pro: only one version runs at a time, avoiding compatibility conflicts (useful for incompatible DB migrations or ReadWriteOnce volumes).

  • Con: full downtime between shutdown and startup.

• Choosing: Use RollingUpdate for stateless services needing availability; use Recreate when concurrent versions would corrupt data or clash on a shared resource.

A startup probe protects a slow-booting legacy app from being killed by its liveness probe before it finishes initializing, while still allowing tight liveness timing once it's up.

• The problem without it: To tolerate a long boot you'd need a large initialDelaySeconds or failureThreshold on liveness, which then makes crash detection slow forever after.

• What the startup probe does: While it runs, the liveness probe is suspended, so the app gets a generous window (failureThreshold × periodSeconds) to come up without being restarted.

• After startup succeeds: Liveness takes over with short, aggressive intervals for fast detection of real hangs.

• Net benefit: You decouple "give it time to boot" from "react quickly when it breaks" instead of compromising both into one liveness config.

You roll back with kubectl rollout undo, which reapplies a previous ReplicaSet. This works because a Deployment keeps a history of past ReplicaSets, each representing one revision of the Pod template.

• Revisions map to ReplicaSets: Each change to the Pod template (image, env, etc.) creates a new ReplicaSet; the Deployment scales the new one up and the old one down but keeps the old around.

• Inspecting history: kubectl rollout history deployment/<name> lists revisions; add --revision=N to see a specific one.

• Rolling back:

  • kubectl rollout undo deployment/<name> reverts to the previous revision; --to-revision=N targets a specific one.

  • The rollback itself is a rolling update: it scales the old ReplicaSet back up gradually.

• History depth is bounded: revisionHistoryLimit (default 10) controls how many old ReplicaSets are retained; set to 0 to keep none, which disables rollback.

• Caveat: History only tracks the Pod template. Config in external ConfigMaps or Secrets isn't versioned unless you name them by hash.

Pausing a rollout tells the Deployment controller to stop reconciling changes toward the desired state, freezing the rollout mid-flight. You do it to inspect or bake a partially updated set of Pods (an ad hoc canary) before committing to the rest.

• What pause does:

  • kubectl rollout pause deployment/<name> halts progression; further spec edits are recorded but not rolled out.

  • Any Pods already updated stay running, so you have a mix of old and new.

• Why pause mid-deployment:

  • Verify the new version under real traffic before rolling it out fully (manual canary).

  • Batch multiple changes (image + env + resources) into a single rollout instead of triggering several.

• Resuming: kubectl rollout resume deployment/<name> continues the rollout with all accumulated changes applied at once.

A CRD is an object that registers a new resource type with the Kubernetes API server, letting you create and manage your own kinds (like kind: Database) using the same tooling as built-in resources. It extends the API declaratively, without recompiling or modifying Kubernetes itself.

• What it registers:

  • A new group/version/kind and its schema (via OpenAPI validation), so the API server accepts and validates instances of it.

  • Instances (Custom Resources) are then stored in etcd and served by the API just like Pods or Services.

• What you get for free: kubectl support, RBAC, labels/annotations, watch, and the standard REST endpoints, all without custom API code.

• A CRD is only data by itself: It stores desired state but does nothing until a controller/operator watches it and acts.

• Alternative: For deeper integration you can use an aggregated API server, but CRDs cover the vast majority of extension needs with far less effort.

Helm is a package manager that renders parameterized templates into manifests, while Kustomize patches a base set of plain YAML with environment-specific overlays. Prefer templating (Helm) when you're packaging and distributing an app with many configurable knobs; prefer overlays (Kustomize) when you own the manifests and just need per-environment variations without templating logic.

• Helm: template-based:

  • Uses Go templates with a values.yaml to fill placeholders, plus packaging, versioning, and rollback.

  • Strong for reusable, shareable charts and complex conditional logic; cost is templated YAML that's harder to read.

• Kustomize: overlay-based:

  • Keeps a base of real YAML and applies overlays (strategic-merge or JSON patches) per environment; built into kubectl -k.

  • No templating language, so manifests stay valid YAML; less powerful for heavy parameterization.

• When to choose which:

  • Templating: distributing software to others, many variables, need release lifecycle and a registry.

  • Overlays: internal apps you control, want plain YAML and simple dev/staging/prod deltas.

  • They compose: you can render a Helm chart and post-process it with Kustomize.

Helm is the package manager for Kubernetes: it bundles all the manifests an application needs into a versioned, parameterized unit called a chart, and manages installing, upgrading, and rolling back that app as a single release. This turns a sprawling set of YAML files into one manageable, repeatable deployment.

• Charts package the app: A chart contains templated manifests, a values.yaml of defaults, metadata (Chart.yaml), and can declare dependencies on other charts (subcharts).

• Parameterization: Override values per environment with --set or -f values.yaml, so one chart serves dev, staging, and prod.

• Lifecycle management:

  • helm install, helm upgrade, and helm rollback treat the whole app atomically; Helm records each revision so you can revert.

  • Hooks let you run jobs at points in the lifecycle (e.g. a DB migration before upgrade).

• Distribution: Charts are shared via repositories (including OCI registries), making complex apps installable in one command.

• Helm 3 is client-only: No Tiller; release state is stored as Secrets in the cluster, improving security.

Helm fights configuration drift by making the desired state declarative and versioned: every release is rendered from a chart plus values, so re-running an upgrade reconverges the cluster to that known state. A chart is the reusable package (the template); a release is one specific installation of that chart into a cluster with a name and its own revision history.

• Chart vs release:

  • Chart: the packaged, versioned templates and defaults, reusable across many installs.

  • Release: a named instance of a chart running in the cluster; installing the same chart twice gives two releases (e.g. redis-cache and redis-session).

• How it addresses drift:

  • The chart + supplied values are the single source of truth; helm upgrade reapplies them and corrects manual changes.

  • Each release keeps a revision history so you can helm rollback to a prior known-good state.

  • helm diff (plugin) shows what would change before applying, surfacing drift.

• Caveat: Helm reconciles only when you run it; it isn't continuously enforcing state like a GitOps controller (Argo CD, Flux) would.