Roughly 84% of organizations now run Kubernetes in production, according to the Cloud Native Computing Foundation’s annual survey. Yet the same survey finds that complexity and security remain the top two operational headaches. That gap tells a story: most teams get Kubernetes running, but plenty of them quietly get it wrong in ways that don’t surface until 3 a.m. on a Saturday.
This guide walks through the mistakes that show up again and again in real clusters. Not the exotic edge cases, but the boring, expensive ones that cost teams sleep, uptime, and money.
Skipping Resource Requests and Limits
The single most common mistake is deploying pods with no CPU or memory requests. Kubernetes then has no idea what the pod needs, so the scheduler makes guesses. Under memory pressure, those pods are the first to get evicted. On a busy node, they can also starve their neighbors.
The fix is unglamorous but essential: set requests to what the container typically uses and limits to a reasonable ceiling. Watch actual usage for a week with a metrics tool, then tune. Teams that skip this step often discover the problem the hard way, when a single memory-hungry pod takes down an entire node.
A related trap is setting limits equal to requests everywhere. That guarantees predictable performance but wastes capacity. Most production workloads benefit from a small buffer between the two.
Using the `latest` Image Tag
Deploying `image: myapp:latest` feels convenient. It is also a reproducibility disaster. Two nodes can pull different images from the same tag, rollbacks become meaningless, and nobody can answer the question “what code is actually running?” during an incident.
Pin images to a specific version or, better, a digest. If a rollback is needed, the exact artifact is guaranteed to exist. Teams that adopt this habit early avoid a whole category of “it worked yesterday” debugging sessions.
The discipline of pinning artifacts pays off far beyond Kubernetes — it’s the same principle behind reproducible builds and immutable infrastructure.
Forgetting Probes, or Misconfiguring Them
Readiness probes control whether a pod receives traffic. Liveness probes decide whether a container gets restarted. Startup probes give slow-booting apps time to initialize. Teams frequently ship with none of them, then wonder why traffic hits pods before they’re ready.
The opposite mistake is just as common: a liveness probe that’s too aggressive. A container under heavy load may take longer than the probe timeout to respond, gets killed, restarts, and enters a crash loop. A good rule is to make liveness probes generous and readiness probes strict. If an app is temporarily slow, the readiness probe should pull it from the load balancer — not trigger a restart. (How to take a screenshot on a mac)
Running Everything as Root
Containers running as root inside the pod are a classic default that most teams never revisit. If an attacker breaks out of the container, root privileges make lateral movement far easier. Pod Security Standards exist precisely to prevent this, and they’ve been stable since Kubernetes 1.25 replaced the older PodSecurityPolicy mechanism. (Kubernetes)
The practical path is incremental. Start with the `baseline` profile in audit mode, see what breaks, fix it, then move to `restricted` for new workloads. Setting `runAsNonRoot: true` and dropping Linux capabilities in the pod spec catches most of the low-hanging fruit.
Leaving the Network Wide Open
By default, every pod in a Kubernetes cluster can talk to every other pod. That flat network is convenient for development and dangerous in production. A compromised frontend pod can reach the database directly.
NetworkPolicies are opt-in and require a CNI plugin that supports them, which trips up teams that assume the feature is built in. The common mistake is writing a policy, assuming it’s working, and never verifying enforcement. Always test with a deliberate connection attempt from a pod that should be blocked.
A sensible starting point: deny all ingress by default in each namespace, then explicitly allow the traffic each service actually needs. It takes an afternoon and prevents a whole class of breach scenarios.
Storing Secrets in Plain YAML
Base64 is not encryption. Yet secrets committed to Git as base64-encoded YAML remain one of the most frequent audit findings. Anyone with repository access has the credentials.
Two fixes matter here. First, enable encryption at rest for etcd — it’s opt-in and off by default on many distributions. Second, use a dedicated secrets manager (Sealed Secrets, External Secrets Operator, or a cloud provider’s offering) so plaintext never lands in version control. Rotating credentials after a leak is painful; preventing the leak is cheap.
No PodDisruptionBudgets
Node drains happen constantly: upgrades, autoscaling, hardware maintenance. Without a PodDisruptionBudget, Kubernetes is free to evict every replica of a service at once. A rolling upgrade that should be invisible becomes a full outage.
The fix is a two-line manifest. Set `minAvailable` or `maxUnavailable` so at least one replica always survives voluntary disruptions. Pair it with topology spread constraints or pod anti-affinity so replicas don’t all land on the same node in the first place.
Single-Replica Deployments
Running one replica of anything important is a bet that the node never fails. It will. Rolling updates also require downtime with a single replica, because the old pod must terminate before the new one starts.
The counterargument is cost, and it’s fair for internal tools. But for anything customer-facing, two replicas with anti-affinity is the minimum. Three is better if the budget allows.
Ignoring API Deprecations
Kubernetes removes deprecated APIs on a published schedule. The `extensions/v1beta1` Ingress API, for example, was removed in version 1.22. Teams that upgrade without checking discover their manifests no longer apply — usually mid-upgrade, usually under pressure.
The habit that prevents this: run `kubectl deprecations` or the `pluto` tool in CI, and read the release notes before every minor version bump. Cluster upgrades deserve a planned runbook rather than an afternoon scramble; a structured checklist for something like an EKS cluster upgrade to Kubernetes 1.37 in 13 steps is worth keeping on hand rather than improvising. (Kubernetes Documentation: Overview)
Over-Privileged RBAC
Handing CI pipelines `cluster-admin` because “it just works” is a shortcut that eventually becomes an incident. The principle of least privilege applies to service accounts exactly as it does to humans.
Audit service account permissions quarterly. Most CI jobs need to create and update resources in a single namespace — not delete nodes. Tools like `kubectl auth can-i –list` and RBAC audit scanners make the review quick. The `system:masters` group in particular bypasses authorization entirely, so no workload should ever be bound to it.
Treating the Control Plane as an Afterthought
A cluster is only as healthy as its control plane. Backups of etcd are frequently configured and rarely tested. Teams discover their backup was incomplete only when they need to restore.
Test a restore in a staging environment at least twice a year. Also monitor control plane component health, API server latency, and certificate expiry. Expired certificates have taken down more clusters than most people realize.
The Cost of Doing Nothing
None of these mistakes is exotic. Each one is a default that nobody revisited. The pattern is consistent: teams move fast to get workloads running, then never circle back to harden the setup.
| Mistake | Typical symptom | Quick fix |
|---|---|---|
| No resource requests | Evictions, noisy neighbors | Set requests from observed usage |
| `latest` image tags | Unreproducible rollouts | Pin versions or digests |
| Missing probes | Traffic to unready pods | Add readiness and startup probes |
| Root containers | Security audit failures | `runAsNonRoot`, drop capabilities |
| No NetworkPolicies | Flat, open pod network | Default-deny per namespace |
| Plain YAML secrets | Credentials in Git | Encryption at rest plus a manager |
| No PDBs | Outages during drains | Set `minAvailable` |
| Ignored deprecations | Failed upgrades | Scan manifests in CI |
The good news is that most of these fixes take minutes, not sprints. The hard part is building the habit of reviewing them.
Building a Review Habit
A quarterly cluster review catches most of these issues before they bite. The checklist is short: are all workloads pinned and probed, are resources set, is the network segmented, are secrets encrypted, and are backups tested?
There’s a broader lesson here that shows up in other domains too. When new tools promise to reduce work, they often create a different kind of work — review, governance, and cleanup. Research on how AI tools shift rather than eliminate workload, such as this look at AI creating more work across Uber, ChatGPT, and Anthropic studies, makes the same point about platforms generally: adoption is the easy part, maintenance is where discipline matters.
Conclusion
Kubernetes rewards teams that treat configuration as a product rather than a one-time setup task. The mistakes above share a common root: defaults that were never questioned. Resource requests, image pinning, probes, network policies, secrets handling, disruption budgets, RBAC, and deprecation tracking are all solvable with small, well-understood changes.
Start with the two that carry the most risk — resource requests and secrets handling — and expand from there. A cluster that’s reviewed quarterly will outperform one that’s merely running. The teams that get this right aren’t the ones with the most tooling; they’re the ones that built the habit of asking “what did we skip?” before the pager goes off.
FAQ
What is the most common Kubernetes mistake?
Missing resource requests and limits tops the list. Without them, the scheduler can’t place pods intelligently, and workloads become vulnerable to eviction and noisy-neighbor problems. It’s a five-minute fix that most teams postpone indefinitely.
Why is using the `latest` image tag a problem?
Because the tag can point to different images over time. Rollouts become non-reproducible, rollbacks are unreliable, and incident responders can’t tell which code is running. Pinning to a version or digest solves it.
Do I really need NetworkPolicies if my cluster is internal?
Yes, if the cluster handles sensitive data. The default network is flat, meaning any compromised pod can reach any other pod. NetworkPolicies are opt-in and need CNI support, so verify enforcement with a real test.
How many replicas should a production service run?
At least two, with anti-affinity or topology spread so they land on different nodes. Three is preferable for critical services. A single replica means every node drain or rolling update causes downtime.
What happens if I ignore API deprecations?
Manifests stop applying during upgrades. Deprecated APIs are removed on a published schedule, so a routine version bump can break deployments unexpectedly. Scan manifests in CI and read release notes before every minor upgrade.
How often should I test etcd backups?
At least twice a year, and ideally after any significant cluster change. An untested backup is a guess, not a recovery plan. Restore into a staging cluster to confirm the process actually works end to end.
One final habit ties these together: instrument before you tune. Enable audit logging and metrics-server early, then let real data — eviction counts, probe failure rates, API deprecation warnings — drive which fixes come first. Teams that guess at priorities tend to polish what’s already fine while the actual risk sits untouched. Track a small set of signals on a dashboard everyone can see: pods without resource requests, images not pinned to digests, namespaces lacking a default-deny policy. When those numbers trend toward zero, the cluster is getting safer, not merely quieter. Pair that with a short blameless review after every near-miss, and the checklist stops being a document nobody reads and becomes part of how the team ships. None of this requires new tooling or a platform team of ten. It requires someone to own the question, a recurring slot on the calendar, and the willingness to fix the boring defaults first.
