Kubernetes interview questions covering pods, deployments, services, ingress, config, secrets, scaling, observability, and production operations.
Kubernetes is an open-source container orchestration platform. It schedules containers across nodes, keeps desired state, performs rolling updates, restarts failed workloads, provides service discovery, manages configuration and secrets, and supports scaling and self-healing. In interviews, explain that Docker packages applications, while Kubernetes operates many containers across a cluster.
The control plane includes the API server, etcd, scheduler, controller manager, and often cloud controller manager. The API server is the front door for cluster state changes, etcd stores cluster state, the scheduler assigns Pods to nodes, and controllers continuously reconcile actual state toward desired state.
A Node is a worker machine, physical or virtual, that runs workloads. It usually runs kubelet, kube-proxy, and a container runtime. The kubelet talks to the API server and ensures assigned Pods are running on the node.
A Pod is the smallest deployable unit in Kubernetes. It can contain one or more containers that share the same network namespace, IP address, and volumes. Most application Pods contain one main container, while sidecars are added for tightly coupled helper behavior.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80Direct Pods are not self-healing if deleted or if a node fails. Use higher-level controllers such as Deployments, StatefulSets, DaemonSets, Jobs, or CronJobs. These controllers recreate Pods and manage lifecycle behavior.
A ReplicaSet ensures that a specified number of matching Pods are running. In most real applications, you do not create ReplicaSets directly because Deployments manage ReplicaSets during rollouts and rollbacks.
A Deployment manages stateless application Pods and ReplicaSets. It supports declarative updates, rolling deployments, scaling, and rollback history. It is the common choice for web APIs, workers, and stateless services.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: registry.example.com/api:1.0
ports:
- containerPort: 3000A StatefulSet manages stateful applications that need stable network identities, ordered startup or shutdown, and stable persistent storage. It is used for workloads such as databases, queues, and clustered systems. It is more operationally sensitive than a Deployment because data and identity matter.
A DaemonSet runs a Pod on every matching node, or on selected nodes. It is commonly used for log collectors, monitoring agents, node-local networking components, and security agents.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: log-agent
spec:
selector:
matchLabels:
app: log-agent
template:
metadata:
labels:
app: log-agent
spec:
containers:
- name: agent
image: fluent/fluent-bit:latestA Job runs Pods until a task completes successfully. It is useful for migrations, batch processing, reports, and one-time maintenance tasks. Configure retries, backoff limits, and idempotency because a Job may run more than once after failures.
A CronJob creates Jobs on a schedule. It is useful for backups, cleanup, synchronization, reports, and periodic checks. Important settings include schedule, concurrencyPolicy, startingDeadlineSeconds, and successful/failed job history limits.
apiVersion: batch/v1
kind: CronJob
metadata:
name: daily-report
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: report
image: registry.example.com/report:1.0A Service provides a stable virtual IP or DNS name for a set of Pods. Because Pods are ephemeral and their IPs change, Services route traffic to matching Pods through labels and selectors.
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 3000Labels are key-value metadata attached to objects such as Pods, Services, and Deployments. Selectors find objects matching labels. They are critical because Services route to Pods through selectors, Deployments manage Pods through selectors, and many operational commands filter resources by labels.
metadata:
labels:
app: api
tier: backend
selector:
matchLabels:
app: apiClusterIP exposes a Service only inside the cluster. NodePort exposes a port on every node. LoadBalancer asks the cloud or infrastructure provider for an external load balancer. Most production HTTP apps use ClusterIP behind Ingress or LoadBalancer depending on platform design.
kube-proxy runs on nodes and helps implement Kubernetes Service networking. It watches Services and endpoints, then configures networking rules so traffic to a Service reaches healthy backend Pods. Depending on mode and platform, this may use iptables, IPVS, or be replaced by eBPF-based networking.
CoreDNS provides DNS service discovery inside the cluster. It lets Pods resolve names such as api.default.svc.cluster.local or simply api within the same namespace. DNS issues can break service-to-service communication even when Pods and Services are otherwise healthy.
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl exec -it deploy/api -- nslookup api.default.svc.cluster.localIngress defines HTTP and HTTPS routing rules from outside the cluster to Services inside the cluster. It requires an Ingress controller such as NGINX Ingress, Traefik, HAProxy, or a cloud provider controller. Ingress commonly handles host routing, path routing, TLS, and annotations for controller-specific behavior.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api
spec:
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api
port:
number: 80A ConfigMap stores non-sensitive configuration such as feature flags, app settings, file content, and environment-specific values. ConfigMaps can be mounted as files or exposed as environment variables. Updating a ConfigMap does not always restart Pods automatically, so rollout behavior must be planned.
A Secret stores sensitive values such as tokens, passwords, and certificates. By default, Kubernetes Secrets are base64 encoded, not magically encrypted for every use case. Production clusters should enable encryption at rest, restrict RBAC access, and prefer external secret managers for stronger controls.
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
stringData:
username: app
password: change-meA liveness probe tells Kubernetes whether a container should be restarted. A readiness probe tells Kubernetes whether a Pod should receive traffic. A failing readiness probe removes the Pod from Service endpoints, while a failing liveness probe restarts the container.
A startup probe protects slow-starting applications from being killed by liveness checks too early. Until the startup probe succeeds, liveness and readiness probes are not evaluated in the usual way. It is useful for apps with long migrations, warmups, or model loading.
startupProbe:
httpGet:
path: /health/startup
port: 3000
failureThreshold: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready
port: 3000
livenessProbe:
httpGet:
path: /health/live
port: 3000Requests tell Kubernetes how much CPU and memory a container needs for scheduling. Limits cap how much it can use. Requests influence placement and cluster capacity planning; limits protect the node but can cause CPU throttling or memory OOM kills if set incorrectly.
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"If a container exceeds its memory limit, it can be killed with OOMKilled status and restarted according to the Pod restart policy. Repeated OOM kills are a signal to inspect memory usage, leaks, traffic patterns, and whether limits are realistic.
The Horizontal Pod Autoscaler, or HPA, adjusts the number of Pod replicas based on metrics such as CPU, memory, or custom metrics. It requires metrics availability and sensible resource requests. HPA cannot fix a slow app by itself if bottlenecks are database, network, or lock contention.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70A rolling update gradually replaces old Pods with new Pods. It helps deploy without full downtime when readiness probes and capacity are correct. Important Deployment settings include maxSurge, maxUnavailable, readiness probes, and terminationGracePeriodSeconds.
Deployments keep rollout history through ReplicaSets. If a rollout fails, kubectl rollout undo can restore a previous ReplicaSet. Rollbacks should still be tested with database migrations and backward compatibility because Kubernetes can roll back Pods, not external state changes.
kubectl rollout status deployment/api
kubectl rollout undo deployment/apiA Namespace partitions cluster resources logically. Namespaces are useful for environments, teams, applications, and access boundaries. They are not a hard multi-tenant security boundary by themselves; RBAC, quotas, network policies, and admission controls are also needed.
A ServiceAccount gives Pods an identity inside the Kubernetes API. Workloads use service accounts to access cluster resources according to RBAC permissions. Use separate service accounts per workload and grant the least privileges needed.
RBAC controls who can perform actions on Kubernetes resources. Roles and ClusterRoles define permissions, while RoleBindings and ClusterRoleBindings assign those permissions to users, groups, or service accounts. The safest approach is least privilege.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: app
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]A NetworkPolicy controls allowed traffic between Pods and network endpoints. It is used for segmentation, zero-trust networking, and limiting lateral movement. Network policies require a CNI plugin that enforces them; otherwise the manifest may exist without effect.
A PersistentVolume, or PV, is cluster storage. A PersistentVolumeClaim, or PVC, is a request for storage by a workload. Pods mount PVCs, and Kubernetes binds them to suitable PVs or dynamically provisions storage through a StorageClass.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10GiA StorageClass defines how dynamic storage is provisioned, including provisioner, disk type, reclaim policy, expansion support, and binding mode. It lets teams request storage through PVCs without manually creating every PV.
An init container runs before application containers in a Pod. Init containers are useful for setup tasks such as waiting for dependencies, preparing files, running checks, or fetching configuration. They must complete successfully before the main containers start.
A sidecar is a helper container that runs alongside the main container in the same Pod. Common sidecars handle logging, proxying, service mesh behavior, config reloads, or file synchronization. Sidecars should be tightly coupled to the main container lifecycle.
Taints repel Pods from nodes unless the Pods have matching tolerations. They are useful for dedicated nodes, GPU nodes, spot nodes, control-plane protection, or isolating special workloads. Tolerations allow scheduling but do not force it; use affinity for preference or requirement.
Node affinity constrains or prefers Pods to run on nodes with specific labels. Required affinity is a hard rule; preferred affinity is a soft preference. It is useful for zones, hardware types, compliance boundaries, or workload placement.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk
operator: In
values: ["ssd"]A PodDisruptionBudget, or PDB, limits voluntary disruptions so too many Pods for an application are not evicted at the same time. It is important during node drains, upgrades, and autoscaler actions. PDBs work best when the app has multiple replicas and readiness probes.
Helm is a Kubernetes package manager. A Helm chart templates Kubernetes manifests and packages values, defaults, and dependencies. Helm is useful for reusable deployments, but chart values must be reviewed carefully because a small values change can alter many resources.
helm install api ./chart -f values-prod.yaml
helm upgrade api ./chart --set image.tag=1.2.0kubectl create creates a resource and fails if it already exists. kubectl apply declaratively creates or updates resources based on the manifest. apply is usually preferred for Git-managed Kubernetes manifests because it supports repeated reconciliation.
A Pending Pod usually means Kubernetes cannot schedule it. Check kubectl describe pod events for insufficient CPU or memory, missing PVCs, node selectors, taints without tolerations, affinity rules, image pull secrets, or quota limits.
kubectl describe pod api-123
kubectl get events --sort-by=.metadata.creationTimestampCrashLoopBackOff means a container starts, exits, and Kubernetes keeps restarting it with backoff. Check logs, previous logs, command and args, environment variables, mounted config, permissions, missing dependencies, and whether probes are killing the app too early.
kubectl logs pod/api-123
kubectl logs pod/api-123 --previous
kubectl describe pod api-123ImagePullBackOff means Kubernetes cannot pull the container image. Common causes include wrong image name or tag, private registry authentication failure, missing imagePullSecrets, network issues, rate limits, or the image not existing for the node architecture.
Check that the Service selector matches Pod labels, endpoints exist, Pods are Ready, targetPort matches the container port, NetworkPolicies allow traffic, DNS resolves, and the application listens on the expected address and port.
kubectl get service api
kubectl get endpoints api
kubectl get pods -l app=api --show-labelsLogs explain events and errors from applications or components. Metrics show numeric behavior over time, such as CPU, memory, request rate, latency, restarts, and saturation. Production clusters need both, plus traces for complex distributed systems.
securityContext defines security settings for Pods or containers, such as running as non-root, dropping Linux capabilities, read-only root filesystem, seccomp profile, and user/group IDs. It reduces risk when a container is compromised.
securityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]Admission controllers intercept requests to the Kubernetes API after authentication and authorization. They can validate, mutate, or reject resources. Examples include policies that require labels, block privileged containers, inject sidecars, or enforce image registry rules.
GitOps manages Kubernetes desired state from Git. Tools such as Argo CD or Flux watch repositories and reconcile cluster state to match manifests. Git becomes the audit trail, review point, and rollback source for cluster changes.
Common mistakes include giving broad RBAC permissions, running privileged containers, running as root unnecessarily, exposing dashboards publicly, storing secrets without encryption at rest, missing network policies, trusting every namespace equally, and deploying images without scanning or provenance controls.
Common anti-patterns include using latest image tags, missing requests and limits, no readiness probes, treating ConfigMaps as automatic restarters, using one huge namespace for everything, running stateful systems without storage planning, ignoring PDBs, and making manual kubectl changes that bypass Git or CI.
A strong demo creates a Deployment, Service, resource requests, probes, and a clear rollout command. Then show how to inspect Pods, view logs, scale replicas, and perform a rolling image update.
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get pods
kubectl logs deployment/api
kubectl set image deployment/api api=registry.example.com/api:1.1Explore 500+ free tutorials across 20+ languages and frameworks.