How do you run Kubernetes in production without it running you?
You run Kubernetes in production successfully by treating it as a platform to operate, not a tool to install. In practice that means starting on a managed control plane, setting resource limits and health checks on every workload, shipping changes through GitOps, and wiring in observability and disaster recovery before your first real traffic — not after your first outage.
Kubernetes is now the default way to run containers at scale, and for good reason: self-healing deployments, horizontal autoscaling, and one consistent API across clouds. But it is also a distributed system in its own right, with its own failure modes. The teams that struggle are almost always the ones who adopted it for the résumé line rather than a concrete need. This guide is written for the founder or CTO deciding whether — and how — to make that bet.
Do you actually need Kubernetes?
Most early-stage products do not. If you run a handful of services, a managed platform-as-a-service or a serverless container runtime will get you to product-market fit faster and cheaper, with a fraction of the operational surface area. Kubernetes earns its complexity only when specific triggers appear.
Reach for it when these are true, not when they might one day be true:
- You run many services. Dozens of deployments that need consistent rollout, scaling, and networking benefit from a shared orchestrator.
- You need portability. Multi-cloud, hybrid, or on-prem-plus-cloud strategies are far easier on a common Kubernetes API than on proprietary primitives.
- You have someone to own it. At least one engineer who can live in cluster operations. Below that headcount, the cluster owns you.
- Your workloads are heterogeneous and bursty. Batch jobs, GPU inference, and web services with different scaling profiles all share capacity well under Kubernetes.
If none of these apply yet, the honest answer is to wait. Adopting Kubernetes too early is one of the most expensive premature optimisations a small engineering team can make.
Should you use managed Kubernetes or self-manage the control plane?
Use managed. Running your own control plane — etcd, the API server, the scheduler, certificate rotation, version upgrades — is a full-time job that adds zero product value. On AWS that means Amazon EKS; the direct equivalents are AKS on Azure and GKE on Google Cloud, and the differences matter more than most teams expect when you weigh them in an AWS vs Azure vs Google Cloud comparison.
The real decision is not which cloud, but how much of the stack you want to operate at all:
| Approach | What you operate | Ops burden | Best for |
|---|---|---|---|
| Self-managed Kubernetes | Control plane, etcd, nodes, upgrades, everything | Very high | Strict data-sovereignty or air-gapped estates with a dedicated platform team |
| Managed Kubernetes (EKS / GKE / AKS) | Worker nodes, workloads, add-ons | Moderate | Teams that want Kubernetes portability without babysitting the control plane |
| Serverless containers (Fargate / Cloud Run) | Just your containers | Low | Smaller estates and teams without a full-time ops owner |
A pragmatic middle path is managed Kubernetes with a serverless data plane — EKS on Fargate, for example — so you keep the Kubernetes API but stop patching individual nodes. Start there and pull node management back in only when cost or control demands it.
What actually breaks Kubernetes in production?
Clusters rarely fall over because of exotic bugs. They fall over because of a short list of predictable mistakes:
- No resource requests or limits. Without them, one memory leak evicts its neighbours and the scheduler makes bad packing decisions. This is the single most common cause of mystery restarts.
- Missing readiness and liveness probes. Kubernetes routes traffic to pods that are running but not ready, and never restarts pods that are wedged. Both show up as intermittent errors that are miserable to debug.
- Single-AZ deployments. Running every replica in one availability zone turns a routine AWS AZ blip into a full outage. Production workloads must spread across at least two.
- Unbounded autoscaling. A misconfigured Horizontal Pod Autoscaler plus an aggressive cluster autoscaler can quietly scale you into a five-figure surprise bill overnight.
- Secrets in plaintext. Base64 is not encryption. Secrets belong in a managed store (AWS Secrets Manager, external-secrets), not in a Git-committed manifest.
- Neglected upgrades. Kubernetes ships a new minor version roughly every four months and support windows are short. Skip upgrades and you eventually face a forced, high-risk jump across several versions at once.
None of these are hard to prevent. They are simply the things teams skip when they treat Kubernetes as fire-and-forget rather than something to operate.
How much does Kubernetes cost to run?
The bill has three layers, and only one of them is obvious. The control plane is a flat fee — EKS charges about $0.10 per hour per cluster, roughly $73 a month, before you run a single workload. The compute is where the money actually goes, and where most teams overspend by carrying idle capacity. The third layer — data transfer, load balancers, and storage — is the one that creeps up unnoticed.
The biggest lever is utilisation. Right-sized requests, the cluster autoscaler, and Spot instances for stateless and batch work routinely cut node cost by half or more, and moving x86 workloads to Graviton (Arm) nodes reduces equivalent compute cost again. These are the same levers that make a broader cloud move pay off; if you are budgeting a migration around a new cluster, our breakdown of AWS migration cost in 2026 shows where Kubernetes spend fits into the total. The mistake to avoid is running dozens of tiny clusters "for isolation" — each one carries that control-plane fee and its own operational overhead. Prefer fewer clusters with strong namespace and network-policy boundaries.
What does a production-ready Kubernetes setup look like?
Before you put customer traffic on a cluster, work down this checklist. It maps directly onto the reliability and operational-excellence pillars covered in the AWS Well-Architected Framework:
- Managed control plane, multi-AZ node groups. No single point of failure at the zone level.
- GitOps deployments. Argo CD or Flux, so the cluster's desired state lives in version control and every change is auditable and reversible.
- Resource requests, limits, and probes on every workload. Non-negotiable defaults enforced by policy.
- Autoscaling with guardrails. HPA plus cluster autoscaler, with maximum node counts and budget alarms so scaling cannot run away.
- Observability from day one. Metrics, logs, and traces (Prometheus, OpenTelemetry) wired in before launch, not bolted on during an incident.
- Secrets, RBAC, and network policies. Least-privilege access and explicit pod-to-pod rules; default-open networking is a liability.
- Backups and a tested restore. etcd and persistent-volume backups mean nothing until you have actually rehearsed recovering from them.
- A standing upgrade cadence. Schedule minor-version upgrades so you are never more than one behind.
Tick every box and Kubernetes becomes boring in the best way — predictable, self-healing, and quiet. That is the goal.
How ILMTEC helps
ILMTEC designs and operates production Kubernetes on AWS as part of our AWS cloud migration service, delivered in fixed six-week cycles. A bounded scope is deliberate: it forces the hard decisions — managed versus self-managed, cluster count, autoscaling guardrails, cost model — to be made up front instead of discovered in production. Our engineers in Pune, Dubai, and Berlin stand up EKS with GitOps, multi-AZ resilience, observability, and right-sized Spot-and-Graviton node pools, then hand you a platform your team can actually run. If you are weighing whether Kubernetes is the right bet — or want an existing cluster reviewed against the checklist above — that first cycle is the fastest way to a straight answer.
