Kubernetes has won the container orchestration debate, and getting a cluster running has never been easier. What remains hard is everything the getting-started guides skip: resource governance, failure behavior, security posture, and upgrades. Most production incidents on Kubernetes trace back to a handful of well-known omissions — which means most of them are preventable.
Resource management is not optional
The single most common source of instability is workloads without resource requests and limits. Without requests, the scheduler places pods blindly and nodes overcommit; without memory limits, one leaking process can take down every neighbor on the node. Set requests based on observed usage rather than guesswork, treat memory limits as mandatory, and be deliberate about CPU limits, which can throttle latency-sensitive services in unintuitive ways. Namespace-level quotas keep one team's enthusiasm from starving another's production.
Design for disruption, because disruption is routine
Nodes drain for upgrades, autoscalers evict pods, spot instances disappear — disruption is a normal operating condition, not an anomaly. Reliable services declare it: multiple replicas spread across nodes and zones via topology constraints, PodDisruptionBudgets so voluntary maintenance never removes the last healthy instance, and graceful shutdown that finishes in-flight requests when the termination signal arrives.
Health probes deserve real thought rather than copy-paste. A liveness probe that checks a dependency can restart perfectly healthy pods in a storm when that dependency blips — the cascade failure classic. Liveness should test only whether the process itself is beyond recovery; readiness handles everything about whether the pod should receive traffic right now.
Security defaults are your problem, not Kubernetes'
Out of the box, any pod can talk to any other pod, and containers often run as root without anyone deciding they should. Production posture means reversing the defaults: NetworkPolicies that deny by default and allow declared flows, non-root containers with read-only filesystems and dropped capabilities, RBAC scoped to actual need, secrets in a proper manager rather than base64-encoded manifests in git, and image scanning with admission policies so that only signed, known-provenance images reach the cluster.
GitOps and the discipline of upgrades
Clusters modified by hand drift until nobody can say what is running or why. The GitOps model — desired state in git, applied by a reconciliation tool such as Argo CD or Flux — makes every change reviewed, audited, and reversible, and turns disaster recovery into re-applying a repository. It also imposes healthy friction: the temptation of the quick manual fix that becomes permanent is structurally removed.
Upgrades are the other recurring discipline. Kubernetes releases move quickly and APIs get deprecated on schedule; clusters left behind become risky to upgrade precisely because they were not upgraded. Budget for regular version bumps, rehearse them on a staging cluster, and read deprecation notices before they read you.
Managed offerings and the honest checklist
For most organizations, managed Kubernetes — EKS, GKE, AKS — is the right call; running control planes is undifferentiated heavy lifting, and the sensible choice usually follows your existing cloud footprint. Before calling any cluster production-ready, verify the short list: resource requests and limits everywhere, PDBs and topology spread on critical services, deny-by-default network policies, GitOps-managed configuration, tested backups, and a rehearsed upgrade path. None of it is glamorous; all of it is the difference between quiet operations and a recurring incident channel.
KubernetesDevOpsProductionCloud
About the author
JDC
José DA COSTA
Founder & President, ACCENSEO
Founder and president of ACCENSEO, software engineer. He works directly with clients on software architecture, cloud infrastructure, and custom development.
