Common Kubernetes misconfigurations and how to fix them
Most Kubernetes clusters carry the same handful of reliability and security gaps. Here are the ones worth auditing for first, and what to do about each.
Every Kubernetes cluster we look at, regardless of size or industry, tends to carry the same handful of misconfigurations. None of them are exotic. Most come from defaults that were never revisited once a cluster left the "getting it working" phase and moved into production. Here are the ones worth checking first.
Missing resource requests and limits
Pods without resource requests get scheduled wherever the scheduler feels like putting them, which means noisy-neighbor problems show up the first time a workload spikes. Pods without limits can consume an entire node's memory and trigger an OOM kill that takes other pods down with them. Setting requests based on observed usage, and limits with enough headroom to absorb normal spikes, is the single highest-leverage change most clusters can make.
Running containers as root
It's still common to find containers running as root with no security context set, simply because that's the container image's default. A compromised container running as root has a much shorter path to node-level compromise. Setting runAsNonRoot, dropping unnecessary Linux capabilities, and using a read-only root filesystem where possible closes off a lot of that path with very little application-level work.
No PodDisruptionBudgets
Without a PodDisruptionBudget, a routine node drain during a cluster upgrade can take an entire deployment offline at once if the scheduler happens to place all its replicas on the same node being drained. A PDB doesn't cost anything to add and prevents voluntary disruptions from turning into an outage.
RBAC that's wider than it needs to be
cluster-admin bound to a service account "to get something working" is one of the most common findings in an access review, and it's rarely revisited once the immediate problem is solved. Namespaced Roles scoped to the specific verbs and resources a workload actually touches take longer to write than a ClusterRoleBinding, but they're the difference between a compromised pod being an incident and a compromised pod being a cluster-wide event.
Liveness and readiness probes that don't reflect real health
A liveness probe that just checks the process is running, rather than whether it can actually serve traffic, doesn't do much. The result is pods that stay in rotation while unable to serve requests, or get restarted in a loop because the probe is too aggressive relative to the application's real startup time. Probes are worth designing deliberately rather than accepting the first example from a tutorial.
None of these fixes require a re-architecture. They're the kind of changes that get skipped because nothing is on fire yet, and then compound over time until something is. An audit that just asks whether a workload has all five of these things in place is usually enough to find most of the real risk in a cluster.