Best practices · Cloud and DevOps
Kubernetes Best Practices
Opens with creditsA practical guide to Kubernetes best practices for people who deploy and run applications on a cluster. It covers writing manifests that stay manageable, setting resource requests and limits, health probes and graceful shutdown, staying available through node drains, Pod Security and secrets, and RBAC and network policies.
Written by Tauseef Fayyaz6 chapters, 27 practicesAbout 24 min23 quiz questionsReviewed 13 October 2026What you will learn
6 chapters · about 24 min
1Workloads and manifestsHow to describe an application so the cluster can manage it: controllers instead of bare Pods, consistent labels, exact image references and manifests kept in version control.5 practices · 5 min
- 1Run Pods through a controller, never as bare Pods
- 2Label every object with the recommended app labels
- 3Reference images by an exact version or digest, never latest
- 4Keep manifests in version control and apply them declaratively
- 5Use namespaces to separate teams, apps and trust levels
5 in this chapterOpen this chapter2Resource requests, limits and scalingHow to tell the scheduler what each container needs, which limits help and which hurt, and how requests feed autoscaling.5 practices · 5 min
- Health probes and graceful shutdownHow the kubelet decides a container is started, alive and ready, and how to stop a Pod without dropping requests.5 practices · 5 minOpens with credits
- Availability through rollouts and disruptionsHow to keep enough replicas serving while nodes are drained, upgraded or lost, and while new versions roll out.4 practices · 3 minOpens with credits
- Pod security and secretsHow to make a compromised container less useful to an attacker: Pod Security Standards, a tight security context, fewer service account tokens and careful handling of Secrets.4 practices · 3 minOpens with credits
- RBAC and network policiesWho can change what in the cluster, and which Pods can talk to which. Least privilege applies to people, service accounts and packets alike.4 practices · 3 minOpens with credits
About this guide
Kubernetes best practices are mostly about telling the cluster the truth about your application. The scheduler only knows how much CPU and memory a Pod needs if you set requests. The kubelet only knows when a container is stuck or not ready if you give it probes. A node drain only waits for your app if you describe how many replicas must stay up. When this information is missing, Kubernetes still runs your workload, but it makes guesses, and those guesses show up as evicted Pods, dropped requests during deploys and noisy neighbours.
This guide follows the order you meet these problems. The first chapters cover the manifests themselves (controllers, labels, image references), then resource requests and limits, then probes and graceful shutdown. Later chapters cover staying available through voluntary disruptions with PodDisruptionBudgets and spreading, hardening Pods with the Pod Security Standards and careful secret handling, and limiting who and what can talk to what with RBAC and NetworkPolicies.
Every practice was checked against the official Kubernetes documentation for the current supported releases, including the configuration overview, the resource management and probe pages, the disruptions guide, the Pod Security Standards, the security checklist and the RBAC good practices page. Each practice says what to do, what to avoid and how to check that you got it right, with a manifest you can adapt.
You do not need to run your own cluster to use this guide. Everything here applies the same way on a managed service such as EKS, GKE or AKS, because it is about the workloads you deploy rather than the control plane.
Common questions
Should I set CPU limits in Kubernetes?
Always set CPU requests, because the scheduler and autoscaler use them. CPU limits throttle a container even when the node has idle CPU, so the Kubernetes security checklist frames them as something you might set on sensitive workloads rather than everywhere. Many teams skip them for latency-sensitive services and use them for batch work or untrusted tenants.
What is the difference between liveness and readiness probes?
A failing readiness probe removes the Pod from Service endpoints but leaves it running. A failing liveness probe makes the kubelet restart the container. Readiness can check dependencies; liveness should check only the process, or a shared outage restarts every replica at once.
Does a PodDisruptionBudget protect against node failures?
No. A PDB only limits voluntary disruptions that go through the Eviction API, such as kubectl drain. Hardware failures and kernel panics still happen, though they count against the budget. Spreading replicas across nodes and zones is what protects you from those.
Are Kubernetes Secrets encrypted?
Not by default in etcd: they are base64 encoded, which is not encryption. Enable encryption at rest for the Secret API (managed services often have a setting for it), restrict who can read Secrets, and consider an external store with the Secrets Store CSI Driver.
Which Pod Security Standard should I use?
Use restricted for application namespaces where you can, baseline where an app cannot meet restricted yet, and privileged only for system components that need host access. Roll out with warn and audit first, then turn on enforce.
Why does my Pod take 30 seconds to stop?
The default termination grace period is 30 seconds. If your process does not handle SIGTERM, often because a shell wrapper is PID 1 and swallows it, Kubernetes waits the full period and then sends SIGKILL. Handle SIGTERM in the app and use the exec form for the container command.
Sources (8)
Checked against these, last on 13 October 2026.
- Configuration Best Practices, Kubernetes docskubernetes.io/docs/concepts/configuration/overview/
- Resource Management for Pods and Containers, Kubernetes docskubernetes.io/docs/concepts/configuration/manage-resources-containers/
- Liveness, Readiness, and Startup Probes, Kubernetes docskubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/
- Pod Lifecycle, Kubernetes docskubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
- Disruptions, Kubernetes docskubernetes.io/docs/concepts/workloads/pods/disruptions/
- Pod Security Standards, Kubernetes docskubernetes.io/docs/concepts/security/pod-security-standards/
- Security Checklist, Kubernetes docskubernetes.io/docs/concepts/security/security-checklist/
- Role Based Access Control Good Practices, Kubernetes docskubernetes.io/docs/concepts/security/rbac-good-practices/
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
- Observability Best PracticesKnow when production is hurting users and why: SLOs, golden signals, metric naming and cardinality, structured logs, OpenTelemetry traces and burn-rate alerts.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Production Readiness ChecklistCheck a service before it takes real traffic: ownership, SLOs, capacity, timeouts and retries, alerts, rollout and rollback, backups, security and on-call.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Spring Boot project structureA REST API in Java with Spring Boot 4, PostgreSQL, Flyway and Testcontainers, organised by feature the way the Spring docs suggest. It grows from the Initializr scaffold to a service with JWT security, problem-detail errors, MapStruct DTOs, slice and integration tests, CI, containers and observability, and finally Modulith boundaries, contract and load tests. For students who know some Java and want to see how a real service is organised.
Career questions
See all- Do I need Docker and Kubernetes as a junior developer?Docker, yes: learn the basics, because nearly every team uses containers and you will be expected to run the project locally and read a Dockerfile. Kubernetes, mostly no: understand what it does and a few core terms, but deep Kubernetes can wait until your job or a DevOps direction needs it.
- What is platform engineering, and how is it different from DevOps?DevOps is a culture and set of practices: developers and operations sharing responsibility for shipping and running software. Platform engineering is one way to put that into practice at scale: a team builds an internal platform, a paved road of tools and templates, so product teams can ship without becoming infrastructure experts.
- Can I become an SRE or platform engineer straight after graduating?Sometimes, but it is rare, because these roles expect you to have run production systems. The more reliable path is a first job in backend, DevOps or cloud support, where you learn production, then a move into SRE or platform work within a couple of years.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com