Kubernetes — Frequently Asked Questions
Practical answers on running Kubernetes — whether you need it at all, managed versus self-hosted, probes, requests and limits, why pods get evicted or restart-loop, ingress, and what makes clusters expensive.
Whether to use it#
Do we actually need Kubernetes?#
Probably not for three services on one host. Kubernetes solves scheduling, self-healing, rolling updates and service discovery across many machines. If you do not have many machines or many services, you are buying the operational cost without the benefit.
Reasonable signals that it is time: you are running enough services that manual placement is a chore, you need rolling updates without downtime as routine, you want a workload to survive a node dying without anyone being paged, or your organisation already runs it and the marginal cost for you is near zero.
That last one is the most underrated reason. The cost of Kubernetes is mostly the first cluster.
Managed or self-hosted?#
Managed, unless you have a specific requirement that rules it out and a team that wants to own control-plane upgrades, etcd backups and certificate rotation.
The control plane is the part that is genuinely difficult and completely undifferentiated. Paying someone else to run it is one of the clearer value-for-money decisions in infrastructure.
Is it too complex for a small team?#
The honest answer is that it moves complexity rather than removing it. You stop writing deploy scripts and start writing manifests; you stop worrying about which host runs what and start worrying about resource requests and probe semantics.
For a small team the deciding question is whether anyone will own the platform. Kubernetes with no owner degrades into a cluster where nobody knows why anything is configured as it is, which is worse than the scripts it replaced.
Configuration that bites#
What is the difference between liveness and readiness probes?#
Liveness answers "should this container be restarted". Readiness answers "should this pod receive traffic". They are not interchangeable and the difference matters enormously.
The classic outage: liveness is pointed at a health endpoint that checks the database. The database is briefly slow, every pod fails liveness, every pod restarts simultaneously, and the database now faces a reconnect storm. Liveness should check the process; readiness may check dependencies.
Add a startup probe for anything slow to boot, or the liveness probe will kill it before it finishes starting.
How do I set requests and limits?#
From measurement, after running under realistic load. Guessed values are the most common cause of both wasted cluster capacity and mysterious restarts.
Understand the asymmetry: exceeding a CPU limit throttles the container, which shows up as latency; exceeding a memory limit kills it, which shows up as a restart with no application-level error. Also check that your runtime knows the container limit — several language runtimes size their heap against the host unless told otherwise, then reliably exceed a limit they cannot see.
Why does my pod keep restarting?#
In rough order of frequency: it exceeded its memory limit; the liveness probe is failing because it checks too much or its timing is too aggressive for a slow start; the application crashes on a condition present only in this environment, such as a missing config value; or a dependency is unreachable and the process exits rather than retrying.
The events for the pod and the previous container's logs will usually distinguish these in under a minute. Check both before changing anything.
Why was my pod evicted?#
The node ran out of a resource — usually memory or disk. Pods whose usage exceeds their requests are evicted first, which is another reason requests should reflect reality.
Disk pressure from accumulated logs or images on the node is a frequent and easily-missed cause, and it evicts pods that did nothing wrong.
Why do we drop requests during a rolling update?#
Two causes, often together. The application does not handle SIGTERM, so it is killed with requests in flight. And endpoint removal is asynchronous, so a pod can receive a request slightly after it has begun terminating.
Handle SIGTERM properly, set a grace period long enough for in-flight work, and add a short preStop delay so the pod stops receiving traffic before it stops serving it.
Networking and access#
How does traffic get in?#
Through a service, then usually an ingress controller or gateway that terminates TLS and routes by host and path. The controller is a real piece of infrastructure with its own configuration, timeouts and failure modes — it deserves the same care as the workloads behind it.
Do we need network policies?#
Yes, and their absence is one of the most common findings in a cluster review. By default every pod can reach every other pod, so a compromised container in one namespace has a flat network to explore.
Start with default-deny in the namespaces that matter and allow what is required. It takes an afternoon and removes an entire category of lateral movement.
Should we run a service mesh?#
Only for a problem you can name: mutual TLS everywhere as a compliance requirement, fine-grained traffic shifting, or consistent telemetry across many services you do not control.
A mesh adds a proxy to every pod, a control plane to operate, and a new place for traffic to fail in ways that are hard to attribute. For most clusters, network policies and good instrumentation cover the real need.
Data and cost#
Should we run databases in Kubernetes?#
You can, and operators have made it far more reasonable than it used to be. The question is whether you want to. The hard parts of running a database — backup, restore, failover, upgrades, performance tuning — are not made easier by the scheduler, and are handed to you free with a managed database.
If regulation, cost or portability requires it, use a mature operator, test restores regularly, and be clear that you have taken on a specialist responsibility.
Why is our cluster so expensive?#
Usually over-requested resources: every workload asks for far more than it uses, so nodes fill up on paper while running at low actual utilisation. Then: non-production clusters running at production size around the clock, load balancers per service, retained logs, and nodes that never scale down because one unmovable pod sits on each.
Look at requests versus actual usage before adding nodes. The gap is usually large and free to close.
How do we handle cluster upgrades?#
Regularly and in small steps, because Kubernetes moves quickly and versions fall out of support faster than most organisations expect. Read the deprecation notes for the API versions your manifests use, upgrade non-production first, and make sure disruption budgets actually permit nodes to be drained.
The team that upgrades every few months has a routine. The team that upgrades every two years has a project, and a migration of deprecated APIs on top of it.