Kubernetes is the standard platform for running containers in production. These Kubernetes interview questions cover pods, deployments and services for freshers, then architecture, ConfigMaps and Secrets, probes, autoscaling, ingress, storage, Helm, security and troubleshooting for experienced DevOps engineers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Kubernetes (K8s) is an open-source platform that automates deploying, scaling and managing containerised applications across a cluster of machines. It handles scheduling, self-healing by restarting failed containers, rolling updates and rollbacks, service discovery, load balancing and autoscaling, so teams can run many services reliably.
A pod is the smallest deployable unit in Kubernetes.
It contains one or more containers that share the same network namespace (IP address and ports) and storage volumes and are scheduled together on one node.
Usually a pod runs one main container, sometimes with sidecar containers for logging or proxies.
Pods are temporary and replaced rather than repaired.
A Deployment manages stateless pods through ReplicaSets, with rolling updates and rollbacks.
A StatefulSet gives pods stable names, ordered startup and their own persistent storage, which suits databases and Kafka.
A DaemonSet runs one pod on every node (or selected nodes), which suits log collectors and monitoring agents.
kubectl get pods (and deployments, services, nodes), kubectl describe pod name for details and events, kubectl logs name (-f to follow, --previous for a crashed container), kubectl exec -it name -- sh, kubectl apply -f file.yaml to create or update resources, kubectl delete, kubectl rollout status and undo, kubectl port-forward for local access and kubectl top for resource use.
Namespaces divide one cluster into virtual groups, for example per team or environment such as dev and staging.
Resource names must be unique within a namespace, and RBAC rules, resource quotas and network policies can be applied per namespace.
Some resources, such as nodes and persistent volumes, are cluster-wide. kubectl -n name targets a namespace.
Labels are key-value pairs attached to objects, such as app: checkout and env: prod.
Selectors find objects by their labels: a Service sends traffic to pods matching its selector, and a Deployment manages pods matching its selector.
Labels are also used for filtering with kubectl get pods -l app=checkout.
Annotations store non-identifying metadata.
A ReplicaSet makes sure a specified number of identical pods is running at all times, creating new pods if some fail or are deleted. You rarely create ReplicaSets directly; a Deployment manages them, creating a new ReplicaSet for each new version during rolling updates and keeping old ones for rollback.
A Job runs pods until a task completes successfully, such as a database migration or a batch import, with settings for retries, parallelism and completions.
A CronJob creates Jobs on a schedule using cron syntax, such as nightly reports or cleanup.
Settings such as concurrencyPolicy and startingDeadlineSeconds control overlapping and missed runs.
A request is the CPU and memory a container is guaranteed; the scheduler uses requests to decide which node has room.
A limit is the maximum it may use: exceeding the CPU limit causes throttling, and exceeding the memory limit kills the container (OOMKilled).
Setting realistic requests is essential for stable scheduling and autoscaling.
Update the image in the Deployment, with kubectl apply or kubectl set image, and Kubernetes performs a rolling update, replacing pods gradually based on maxSurge and maxUnavailable while readiness probes confirm new pods are ready. kubectl rollout status watches progress, kubectl rollout history lists revisions, and kubectl rollout undo returns to the previous version.
Every manifest has apiVersion (such as apps/v1), kind (such as Deployment), metadata (name, namespace, labels and annotations) and spec, which describes the desired state, such as replicas, the pod template, containers, images, ports and environment variables.
Kubernetes adds a status section showing the actual state.
Several resources can be in one file separated by ---.
Applied problems, trade-offs and questions about your own projects.
A Service gives a stable IP and DNS name to a set of pods selected by labels.
ClusterIP (default) exposes it only inside the cluster, NodePort exposes it on a port on every node, LoadBalancer provisions a cloud load balancer, and ExternalName maps to an external DNS name.
Headless services give direct pod DNS records for StatefulSets.
Both inject configuration into pods as environment variables or mounted files.
ConfigMaps hold non-sensitive configuration.
Secrets hold sensitive data such as passwords and tokens; they are only base64-encoded by default, so encryption at rest, strict RBAC, and often an external secrets manager such as Vault or AWS Secrets Manager are needed.
A liveness probe checks whether the container is healthy; if it fails, Kubernetes restarts the container.
A readiness probe checks whether the container can serve traffic; if it fails, the pod is removed from Service endpoints but not restarted.
A startup probe gives slow-starting apps time before the other probes begin.
Badly configured probes can cause restart loops.
An Ingress defines HTTP and HTTPS routing rules from outside the cluster to Services, based on hostnames and paths, with TLS termination.
It needs an ingress controller such as NGINX Ingress or a cloud load balancer controller to work.
The newer Gateway API is the more expressive successor.
A PersistentVolume is a piece of storage in the cluster, such as a cloud disk.
A PersistentVolumeClaim is a pod's request for storage of a certain size and access mode.
A StorageClass describes a type of storage, such as fast SSD, and lets claims create volumes dynamically.
Data survives pod restarts, and StatefulSets create one claim per pod.
Helm is a package manager for Kubernetes.
A chart is a package of templated manifests with default values in values.yaml, which can be overridden per environment. helm install, upgrade and rollback manage releases, and public charts make it easy to install software such as ingress controllers, Prometheus and databases.
Kustomize is a template-free alternative using overlays.
A taint on a node repels pods, unless a pod has a matching toleration, which is used to reserve nodes for special workloads such as GPU jobs.
Node affinity attracts pods to nodes with certain labels, such as a zone or instance type, as a requirement or a preference.
Pod affinity and anti-affinity place pods near or away from other pods, for example spreading replicas across zones.
A PodDisruptionBudget limits how many pods of an application can be down at once during voluntary disruptions, such as node upgrades or cluster scaling down, with minAvailable or maxUnavailable.
It keeps enough replicas serving traffic while nodes are drained.
It does not protect against involuntary failures such as a node crashing.
Role-based access control grants permissions with Roles (within one namespace) and ClusterRoles (cluster-wide), which list allowed verbs such as get, list, create and delete on resources.
RoleBindings and ClusterRoleBindings give those permissions to users, groups or service accounts.
Pods use service accounts to talk to the API, and each should have the least privilege it needs.
By default, every pod can talk to every other pod.
NetworkPolicies act as firewall rules that allow only certain traffic, selecting pods by labels and allowing ingress or egress from specific pods, namespaces or IP ranges.
A common pattern is a default-deny policy followed by explicit allow rules.
They need a network plugin that supports them, such as Calico or Cilium.
Init containers run to completion, one after another, before the main containers start, for tasks such as waiting for a database, running migrations or downloading configuration. Sidecar containers run alongside the main container for its whole life, providing helpers such as log shipping, proxies or certificate renewal; Kubernetes now supports native sidecars as init containers with restartPolicy: Always.
System design, deep internals, leadership and tough follow-ups.
The control plane includes the API server (the entry point for all operations), etcd (the key-value store holding cluster state), the scheduler (assigns pods to nodes) and the controller manager (runs control loops that move actual state towards desired state). Each worker node runs the kubelet (manages pods on the node), a container runtime such as containerd, and kube-proxy (handles Service networking).
The Horizontal Pod Autoscaler adds or removes pod replicas based on CPU, memory or custom metrics.
The Vertical Pod Autoscaler adjusts the resource requests of pods.
The Cluster Autoscaler or Karpenter adds nodes when pods cannot be scheduled and removes idle ones.
KEDA scales on events such as queue length.
Accurate resource requests are essential for all of them.
I run kubectl describe pod to see events and the last state, and kubectl logs --previous to see the logs from the crashed container.
Common causes are application errors, missing ConfigMaps or Secrets, wrong environment variables, a failing liveness probe, the wrong command, or being OOMKilled because the memory limit is too low.
I fix the cause and redeploy, and use kubectl exec or a debug container if needed.
Blue-green runs the new version beside the old one and switches all traffic at once, by changing a Service selector or ingress, with instant rollback.
Canary sends a small percentage of traffic to the new version first and increases it while metrics stay healthy.
Tools such as Argo Rollouts and Flagger automate canaries using ingress controllers or a service mesh and analyse metrics to promote or roll back.
GitOps uses a Git repository as the single source of truth for the desired state of the cluster.
A controller such as Argo CD or Flux runs inside the cluster, compares the live state with Git and applies changes automatically, reverting manual drift.
Deployments happen through pull requests, which gives review, history, easy rollback and no need for CI to hold cluster credentials.
A service mesh such as Istio or Linkerd adds a layer, using sidecar proxies or an ambient node-level design, that handles service-to-service traffic: mutual TLS encryption and identity, retries, timeouts, traffic splitting for canaries, and detailed metrics and tracing, without changing application code. It adds complexity and resource overhead, so it suits larger microservice systems.
A Custom Resource Definition adds a new resource type to the Kubernetes API, such as PostgresCluster or Certificate.
An Operator is a controller that watches those resources and automates operational knowledge, such as provisioning a database cluster, taking backups, handling failover and upgrades, the way a human operator would.
Examples include cert-manager and database operators.
Keep the control plane private and up to date, use RBAC with least privilege, enforce Pod Security Standards so pods run as non-root without privileged access, apply NetworkPolicies, encrypt secrets at rest or use an external secrets manager, scan and sign images and allow only trusted registries with admission policies (Kyverno or OPA Gatekeeper), enable audit logs and runtime threat detection such as Falco.
See all DevOps Engineer interview questions, covering Linux, Git, Docker, Kubernetes, CI/CD (GitHub Actions, Jenkins) and more.