Kubernetes does not make a system reliable on its own: you declare the desired state, but it is you who defines what “healthy” means. Before every production release I go through these points.

Requests and limits

Every container must have CPU and memory requests and limits. Without them the scheduler does not know where to place it, and a single runaway pod can take down the node.

Health probes

readiness so it does not receive traffic before it is ready, liveness so it gets restarted if it hangs. Getting them wrong is worse than not having them: a too-aggressive liveness restarts in a loop.

Resilience and updates

• At least 2 replicas + a PodDisruptionBudget, to survive node maintenance and restarts.
• Rolling updates with a low maxUnavailable: no downtime on deploy.
• A HorizontalPodAutoscaler to handle spikes without over-provisioning at rest.

Basic security

• Non-root containers, read-only filesystem, dropped capabilities.
• Default-deny NetworkPolicy: you only open what is needed.
• Secrets out of the code (a secret manager), never in the images.

None of these points is exotic: they are the foundations. It is their sum that makes the difference between a cluster that holds and one that wakes you up at night.