30 Kubernetes Best Practices
Kubernetes Best Practices offer proven strategies to optimize deployment, scalability, and reliability in containerized environments.
Kubernetes Best Practices is the accumulated body of operational guidance for designing, deploying, and running workloads on Kubernetes in a way that is resilient, secure, and maintainable, synthesizing lessons learned from operating the platform at scale across a wide range of organizations.
Application Design
Design for Disposability
Applications should be designed with the expectation that any individual Pod may be terminated and replaced at any time, whether due to scaling, rescheduling, or failure, meaning state that must survive should be externalized rather than held only in a container's local filesystem or memory.
Expose Accurate Health Signals
Liveness and readiness probes should reflect the actual internal health of an application rather than trivial checks, since inaccurate health signals cause the platform to make incorrect decisions about restarting containers or routing traffic to them.
Resource Specification
Always Set Requests and Limits
Omitting resource requests and limits leaves the scheduler without the information it needs to place Pods appropriately and leaves workloads vulnerable to being starved or evicted under contention; explicit requests and limits should be set based on observed or tested application behavior.
Avoid Overly Tight Limits
Setting resource limits too close to typical usage risks frequent throttling or termination during normal variation in load, so limits should account for realistic peak usage rather than only average conditions.
Security Hardening
Principle of Least Privilege
Containers should run as non-root users wherever possible, with minimal Linux capabilities and read-only root filesystems where the application allows it, reducing the potential impact of a compromised container.
Namespace and RBAC Scoping
Access should be scoped as narrowly as possible using namespaces and Role-Based Access Control, avoiding broad cluster-wide permissions for users or service accounts that only need access to a specific subset of resources.
Deployment Practices
Use Declarative Configuration and Version Control
Manifests should be stored in version control and applied declaratively rather than modified imperatively in a running cluster, preserving a reviewable history of configuration changes and reducing configuration drift.
Roll Out Changes Gradually
Rolling update strategies, combined with appropriate readiness probes and disruption budgets, should be used to ensure changes are applied incrementally, allowing issues to be caught before they affect the entire fleet of replicas.
Observability and Operations
Instrument Before You Need It
Metrics, structured logs, and health signals should be built into applications from the start, since retrofitting observability during an active incident is far more difficult than having it available beforehand.
Plan for Node and Zone Failures
Workloads intended to be highly available should be explicitly spread across nodes and availability zones using anti-affinity or topology spread constraints, rather than relying on the scheduler's default behavior alone.
Namespace and Multi-Tenancy Hygiene
Apply Resource Quotas
Namespaces shared by multiple teams should have ResourceQuotas and LimitRanges applied, preventing a single team's workloads from consuming a disproportionate share of shared cluster capacity.