Containers & Kubernetes Fundamentals

Build small immutable images

A container is an immutable OCI image: your app plus its exact dependencies, built once and run everywhere. The senior habit is to build small and clean. A multi-stage build compiles in a fat builder image and copies only the artifact into a distroless or Alpine base, so the shipped image is 20 to 80 MB instead of 800 MB, pulls fast, and has almost no OS packages for a CVE scanner to flag. The image is immutable: you never ssh in and patch a running container, you build a new image and replace the old one.

The core Kubernetes objects

Kubernetes schedules those images onto nodes and keeps the declared state true:

• Pod: the smallest unit, one or more co-located containers sharing a network namespace. You rarely create Pods directly.
• Deployment: manages a ReplicaSet of identical, interchangeable stateless Pods. The default for a web API.
• StatefulSet: stable network identity and stable per-Pod storage for stateful workloads (each Pod gets pod-0, pod-1 and keeps its own PersistentVolume across restarts).
• DaemonSet: one Pod per node, for agents like log shippers or a CNI.
• Service: a stable virtual IP and DNS name load-balancing across a set of Pods.
• Ingress / Gateway API: L7 north-south routing into the cluster.
• ConfigMap / Secret: non-secret and secret config injected as env vars or files, kept out of the image.

Scheduling controls

Every container should set resource requests (what the scheduler reserves) and limits (the hard ceiling). Requests plus limits determine the QoS class: Guaranteed (requests == limits) is evicted last, BestEffort (nothing set) is evicted first under node pressure. Use affinity/anti-affinity and taints/tolerations to spread replicas across zones, and a PodDisruptionBudget so a voluntary drain never takes more than N Pods down at once.

Probes drive safe rollouts

• startupProbe: gates the other two until a slow-booting app is up, so a cold JVM is not killed prematurely.
• readinessProbe: decides whether the Pod receives traffic. A failing readiness probe pulls the Pod out of the Service endpoints without killing it.
• livenessProbe: decides whether to restart the Pod. A failing liveness probe triggers a kill and restart.

A rolling update stays zero-downtime because new Pods must pass readiness before old Pods are terminated. Set maxUnavailable: 0 and maxSurge: 1 and Kubernetes brings up a new ready Pod before removing an old one, so capacity never dips.

Interview nuance: the tell of a weak answer is treating K8s as "a magic scaling button." The strong answer says the app must be stateless (no local session, no local disk) for a Deployment to work, and that readiness probes, not liveness probes, are what make a rollout safe.

Recap: build small immutable images, use Deployments for stateless and StatefulSets for stateful, set requests/limits and a PodDisruptionBudget, and let readiness probes gate a maxUnavailable: 0 rolling update to stay zero-downtime.