Interview Questions
Kubernetes Interview Questions and Answers
Kubernetes interviews often start conceptual (what's a pod vs. a deployment) and move into troubleshooting scenarios -- being able to reason about why a pod won't start matters as much as reciting definitions.
Example: A Deployment and Service for a simple app
YAMLapiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: myregistry/web-app:1.4.2
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: web-app-service
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080
type: LoadBalancerFrequently Asked Questions
A Pod is the smallest deployable unit -- usually one running container. A Deployment manages a set of identical Pods (via a ReplicaSet underneath), handling scaling and rolling updates -- you rarely create bare Pods directly in a real app. A Service gives that changing set of Pods a stable network name/address, since individual Pod IPs change every time a Pod restarts.
When you update a Deployment's container image, Kubernetes gradually replaces old Pods with new ones -- starting a few new Pods, waiting for them to become ready, then terminating an equivalent number of old ones, repeating until all Pods run the new version. This keeps the application available throughout the update, unlike stopping everything and starting it back up.
A liveness probe checks whether a container is still functioning -- if it fails repeatedly, Kubernetes restarts the container. A readiness probe checks whether a container is ready to receive traffic -- if it fails, the Pod is removed from a Service's load-balancing rotation (but not restarted) until it passes again. A container can be alive but not yet ready (e.g. still warming up a cache).
A HorizontalPodAutoscaler watches a metric (commonly CPU utilization, or a custom metric) against a target you set, and automatically adjusts a Deployment's replica count up or down to try to keep the metric near that target -- scaling out under load, scaling back in when load drops.
Both store configuration data separately from your container image, injected as environment variables or mounted files. ConfigMap is for non-sensitive configuration. Secret is intended for sensitive values (passwords, tokens) -- by default it's only base64-encoded (not encrypted) at rest unless you enable encryption at the cluster level, so it's not a substitute for a real secrets-management system on its own.
Commonly: no node in the cluster has enough available CPU/memory to satisfy the Pod's resource requests, a required PersistentVolumeClaim couldn't be bound, or a node selector/affinity rule can't be satisfied by any current node. kubectl describe pod <name> is the first troubleshooting step -- it shows scheduling events explaining exactly why.
A way to partition a single cluster's resources logically -- separating different teams, environments (dev/staging/prod), or applications, so resource names don't collide and RBAC permissions/resource quotas can be scoped per namespace rather than cluster-wide.