Common Docker & Kubernetes Pitfalls

Most Docker and Kubernetes incidents trace back to a small set of well-known gotchas: missing resource limits, forgotten health checks, latest tags, or a misunderstanding of how networking and storage actually behave. Knowing these pitfalls in advance — and why they happen — is often more valuable in an interview or on-call rotation than memorizing commands, because it demonstrates operational judgment. Each item below describes the mistake, why it causes trouble, and the fix.

Tagging images as latest (or relying on it implicitly by omitting a tag) means the same reference can point to different actual image content over time, so a Pod restart or node reschedule can silently pull a newer, untested build. This breaks reproducibility and makes rollbacks unreliable, because you cannot pin latest to a known-good state. Always build and deploy with immutable, specific tags — ideally the Git commit SHA or a semantic version — so the exact same bytes are guaranteed to run wherever that tag is used.

By default, a container process runs as root inside the container's user namespace unless the image specifies otherwise, which means a container-escape vulnerability has a much larger blast radius. The fix is to add a USER instruction in the Dockerfile pointing to a non-root UID, and in Kubernetes, to set securityContext.runAsNonRoot: true (and ideally runAsUser) on the Pod or container spec so the cluster actively rejects Pods that try to run as root. This is a standard finding in security reviews and a common interview topic.

Without requests, the scheduler has no idea how much capacity a Pod actually needs, which can lead to overcommitted nodes and noisy-neighbor problems; without limits, a single misbehaving container can consume all available memory on a node and get OOM-killed unpredictably, sometimes taking other Pods down with it via node pressure. Setting sensible requests (based on observed steady-state usage) and limits (with headroom for spikes) lets the scheduler place Pods intelligently and lets the kubelet evict or throttle predictably instead of destabilizing the node.

A liveness probe failing causes Kubernetes to kill and restart the container, while a readiness probe failing only removes the Pod from Service endpoints without restarting it. A very common mistake is pointing a liveness probe at a check that depends on a downstream dependency (like a database connection); if that dependency has a temporary outage, Kubernetes will restart every affected Pod in a loop even though restarting does nothing to fix the actual problem. Downstream-dependent checks belong on the readiness probe, so Kubernetes stops routing traffic without needlessly killing healthy processes.

Hardcoding credentials in a Dockerfile or plain env vars means they end up in image layers (recoverable even after later 'removal' since layers persist) and are visible to anyone who can run docker inspect or kubectl get pod -o yaml. Kubernetes Secrets are base64-encoded, not encrypted, by default, so they should be paired with encryption at rest and RBAC restrictions, or better, an external secret manager (e.g. Vault, cloud KMS-backed secret stores) synced in via an operator. The core rule: never bake credentials into image layers, and treat Secrets objects as sensitive even though Kubernetes stores them accessibly by default.

A rolling update by itself does not guarantee zero-downtime unless the application also cooperates: the Pod needs an accurate readiness probe so traffic isn't sent to it before it's ready, and it needs to handle SIGTERM gracefully (finishing in-flight requests) during the terminationGracePeriodSeconds window before being force-killed with SIGKILL. Many teams see dropped requests during deploys because the old Pod is killed before in-flight connections drain, or the new Pod receives traffic before its initialization is actually complete. A preStop hook that sleeps briefly before shutdown can help align in-flight connection draining with load balancer deregistration.