Docker & Kubernetes Today: Essential Features Product Teams Actually Need

Containers are no longer optional for serious product delivery — but Kubernetes is optional longer than Twitter suggests. This post separates must-use features from resume-driven complexity.

See also: platform engineering

Docker features to use well

Multi-stage builds

Keep runtime images slim. Smaller images = faster deploys and smaller attack surface.

Non-root users & read-only FS where possible

Security baseline. Pair with dependency scanning in CI.

Compose for local parity

One command to run API + DB + redis for developers. Document architecture versions in Compose so “works on my machine” shrinks.

Kubernetes features that matter (when you need K8s)

Probes (liveness/readiness/startup)

Correct probes prevent cascading failures. Wrong probes cause restart storms.

Resource requests/limits

Without them, noisy neighbors and OOMs become mysterious weekly incidents.

HPA / autoscaling

Scale on CPU/RPS/custom metrics once traffic is real. Premature HPA on empty products is theater.

Secrets & config discipline

Use sealed secrets / external secret operators; never bake credentials into images.

When not to use Kubernetes yet

• Single service + managed PaaS meets SLOs
• Team has no platform capacity
• You would be learning K8s during an incident-prone launch

Frequently asked questions

ECS/Fargate vs EKS/GKE?

Managed container services often win until multi-service complexity forces full K8s. Optimize for delivery, not purity.

Do we need a service mesh?

Not until you have enough services that you’ve actually lost track of who’s calling whom. Below that, a mesh adds latency and yaml for a problem you don’t have.

When do we actually need multiple Kubernetes clusters?

When a single cluster becomes a blast-radius problem — one bad deploy taking down every environment — or when compliance forces physical separation. Not because it “feels more production-grade.”

Is Docker Swarm still worth considering?

For a small, static workload, maybe. For anything growing or hiring engineers who’ll expect Kubernetes experience, no — you’ll end up migrating later anyway, just with more baggage.