Kubernetes Interview Questions

Two planes:

• Control plane - API server (front door), etcd (cluster state store), scheduler (picks nodes for pods) and controller manager (reconciliation loops).
• Worker nodes - kubelet (node agent managing pods), kube-proxy (network rules for Services) and the container runtime (containerd, CRI-O) that runs the containers.

A Pod is the smallest unit: one or more containers sharing network and volume. A Deployment is a controller that manages pods - it owns a ReplicaSet, keeps the desired replica count, performs rolling updates and supports rollback.

You almost never create bare pods; you create Deployments that keep pods alive and healthy.

Pod IPs change as pods restart. A Service selects pods via label selectors and exposes a stable virtual IP (and DNS name) in front of them.

Reachable inside the cluster by name (ClusterIP), on every node port (NodePort), via an external load balancer (LoadBalancer), or as a DNS alias (ExternalName). kube-proxy wires the virtual IP to the backing pods; CoreDNS resolves the service name.

Both separate configuration from container images. ConfigMap holds non-sensitive configuration (environment, log levels). Secret holds sensitive data (passwords, tokens, keys).

Secrets are only base64-encoded at rest; you must enable encryption at rest and manage them via tools like sealed-secrets or an external vault for real security. Both are consumed as environment variables or mounted files.

Kubernetes health checks for containers:

• liveness - if it fails, the kubelet restarts the container (a hung app is rescued).
• readiness - while it fails, the pod is removed from Service endpoints so it receives no traffic.

Use readiness during slow startups and liveness only when a restart can fix the problem. Both can be httpGet, tcpSocket or exec probes.

The Horizontal Pod Autoscaler (HPA) watches metrics (default CPU) and adjusts the replica count of a Deployment to meet the target. Formula: desired = ceil(currentReplicas * (currentMetric / desiredMetric)).

You define minReplicas/maxReplicas and the target; the Metrics Server provides the data. Pods must have resource requests for CPU autoscaling, and the Deployment must survive scale-down (no asymmetric scheduling constraints).

A container is the packaged runtime unit (image + isolated processes). A Pod is the smallest deployable unit in Kubernetes - a group of one or more containers that share the same network namespace, IP and storage. Containers in one pod are co-scheduled and share localhost and volumes; most workloads are one container per pod, pods with sidecars add helpers (proxies, log shippers).

Deployment manages stateless replicas: identical pods, ephemeral identities, scaled/replaced freely, best for web/API services. StatefulSet gives pods stable ordered names (pod-0, pod-1...), stable network identities and stable per-pod persistent volumes - for databases, caches and queues where identity and ordering matter.

A Service is a stable network endpoint that load-balances to a set of pods, decoupled from pods that come and go. Types: ClusterIP (internal virtual IP, default), NodePort (exposes on every node:NodePort), LoadBalancer (cloud LB in front of NodePorts), and ExternalName (DNS alias). Services select pods by label selectors.

ConfigMap stores non-sensitive configuration (URLs, toggles, config files) injected as env vars or mounted volumes. Secret stores sensitive data (passwords, tokens, keys), base64-encoded at rest and designed for RBAC-restricted access; it can be mounted as files or env. Both decouple config from the container image so the same image runs everywhere.

A Namespace is a logical partition within a cluster that scopes resources, defaults, quotas and policies - it isolates environments (dev/stage/prod), teams or products sharing one cluster. It does not isolate by security boundary by default (NetworkPolicies do). Special built-ins: default, kube-system, kube-public. Cluster-wide resources (nodes) are not namespaced.

A rolling update changes the pod template (new image/command/env) so the Deployment creates new pods with the new config while old ones drain - controlled by maxUnavailable and maxSurge. A rolling restart keeps the same spec but forces new pods anyway (kubectl rollout restart) - useful to pick up rotated secrets, new configmaps or version re-reads.

Kubernetes terminates all pods of the Deployment: no replicas run, the Deployment and its Service remain defined, and the desired state is just no instances. It is a common pattern to "stop" a workload temporarily without deleting its objects - also the base state that a HorizontalPodAutoscaler or platform can scale back up from.

A HPA automatically adjusts the replica count of a Deployment/ReplicaSet/StatefulSet based on observed metrics (CPU, memory, or custom metrics from Prometheus). It periodically evaluates current vs target utilization and applies a formula (desired = ceil(current/target * replicas)), with minReplicas/maxReplicas limits and a default stabilization delay so it does not thrash.

readinessProbe - is the pod ready to receive traffic? If it fails, the pod is removed from the Service endpoints (not restarted). livenessProbe - is the app alive? On failure the container is killed and restarted. startupProbe - guards slow-starting apps: other probes do not run until it succeeds. All use HTTP, TCP or command checks.

Through label selectors. The Service spec has a selector (e.g. app: myapp); the controller tracks all pods matching it and updates the Service endpoint list (and EndpointSlices) when pods appear or disappear. Traffic is load-balanced (with IPVS/iptables) across the ready endpoints of those selected pods.

PV (PersistentVolume) is cluster storage provisioned by an admin or dynamically by the provider (EBS, GCE PD, NFS). PVC (PersistentVolumeClaim) is a request for storage by a workload - it binds to a PV that matches its size/access mode. StorageClass describes the class of storage (SSD vs HDD) so PVs can be created on demand when a PVC is made; it makes storage dynamic.

emptyDir - temporary directory tied to the pod, created empty, used to share files between the pod's containers; wiped when the pod is deleted. hostPath - a directory on the node filesystem, good for node-level tools but not durable across nodes and a security consideration. PV/PVC - durable, external storage that survives pod rescheduling.

kubectl create creates a resource and errors if it exists (non-declarative). kubectl replace replaces the existing object with the submitted one. kubectl apply is the declarative recommended mode: it merges the submitted spec with the live object while keeping a last-applied annotation, so it supports updates and partial changes idempotently - the CI/CD-friendly way to manage YAML.

Deployments keep a revision history. Roll back with kubectl rollout undo deployment/myapp (optionally --to-revision=N). To inspect: kubectl rollout status, kubectl rollout history, and kubectl rollout pause/resume to control the pace of a release. Set managedFields/history limits (revisionHistoryLimit) so very old revisions can be dropped.

A DaemonSet ensures every (selected) node runs exactly one copy of a pod - new nodes get it automatically. Typical uses: node monitoring agents (node-exporter, Datadog), log collection (fluentd/filebeat), CNI networking components (calico, weave) and storage daemons. Contrast with Deployment, which spreads a desired number of replicas anywhere in the cluster.

requests declare the guaranteed CPU/memory the scheduler reserves for the pod; limits cap what a container may use (memory over the limit causes OOM kill, CPU is throttled). Define both on every container. Cluster-level control: LimitRange and ResourceQuota per namespace, and Quality of Service classes (Guaranteed if request==limit, otherwise Burstable or BestEffort).

A LoadBalancer Service configures each exposed service with its own cloud load balancer - one external IP per service, easy but costly at scale. Ingress is a single entry point with routing rules (host/path → service), TLS termination, and shared ingress controller (nginx, traefik) - one load balancer fronting many services. Ingress is the scalable way to expose HTTP apps.

A Service defines how to reach pods (an endpoint). A NetworkPolicy defines who may reach pods - it filters traffic between pods or from external sources using selectors and ports. By default all traffic is allowed; a NetworkPolicy pings out and restricts. Note: enforcing NetworkPolicies requires a CNI that supports them (Calico, Cilium); plain kube-proxy does not.

A Job runs one or more pods to completion (batch work - report generation, DB migration); it tracks successful completions and you control retries/backoff and parallelism. A CronJob schedules Jobs on a cron schedule (hourly cleanup, nightly backups) and records job history with concurrency policy (Allow/Forbid/Replace).

The scheduler finds nodes in two phases: filtering - remove nodes that violate hard constraints (unschedulable taints, insufficient requests, affinity rules, ports), then scoring - rank the remaining nodes by soft preferences (spread across zones, resource fit, anti-affinity, node affinity weights). The top-scoring node gets the pod via binding. You can customize with custom schedulers or affinities.

etcd is the distributed key-value store holding the entire cluster state - all objects, their specs, statuses and config. The API server is the only component that talks to etcd; everything else reads/writes through the API server. Because it must be consistent and durable, back it up (etcdctl snapshot) and run it with TLS; etcd loss means losing cluster state.

Each Service gets a DNS name within the cluster (my-service.namespace.svc.cluster.local). The CoreDNS add-on resolves those names to the Service virtual IPs, and kubelet inserts resolv.conf search domains into every pod. So one pod reaches another service by name regardless of where the pods run - that is the built-in service discovery mechanism.

Helm packages Kubernetes YAML into reusable, parameterized charts (templates + values.yaml). Benefits: install/upgrade/rollback whole apps with one command, reuse community charts (nginx-ingress, prometheus), inject environment-specific values, and avoid copy-pasting hundreds of YAML lines. Charts have linting, dependencies and versioning.

A cluster is the whole Kubernetes system. Its control plane runs the brain: kube-apiserver, etcd, kube-scheduler and kube-controller-manager (in managed clouds this is hidden). Nodes run the workload: each has kubelet (talks to the API server), kube-proxy (networking rules) and a container runtime (containerd). Workload pods live on nodes; control-plane components decide and orchestrate.