CloudCostCompareContainers and Kubernetes: what a cluster really costs
Containers package an application with what it needs to run. Kubernetes schedules those containers across a group of machines. The result is flexible, and it adds layers of cost that a single server does not have.
The layers
The control plane. The part of Kubernetes that makes decisions. Some clouds charge an hourly fee per cluster for it, some offer a free tier and a paid tier with a stronger availability promise, and some include it. This varies between vendors and between tiers, so read the current page for your cloud: Amazon EKS, Azure AKS, Google GKE and Oracle OKE.
The nodes. The virtual machines your containers run on, billed like any other VM. This is usually the largest part. Node cost is the sum of the machines in the cluster, not of the containers.
Overhead on each node. Part of every node’s CPU and memory is reserved for the operating system and Kubernetes itself, so usable capacity is lower than the size on the price list. Small nodes lose a larger share.
Networking. Load balancers for services, NAT gateways for private nodes, and data transfer. See load balancer costs and NAT gateways.
Storage. Persistent volumes are block storage, billed by provisioned size. See block storage volume types.
Add-ons. Monitoring, logging, service meshes and ingress controllers use CPU and memory, and often send data to a paid service.
Why small clusters cost more than expected
A cluster has a floor. You want at least two or three nodes for resilience, even if the workload would fit on one. Add the control plane fee, a load balancer and a NAT gateway, and the minimum cost is well above a single well-sized server.
Kubernetes pays off when you run many services, need rolling deployments and automatic recovery, or have a team that already knows it. For one or two services, a plain server group or a serverless container service is often cheaper and simpler. See serverless or servers.
Ways to keep it lean
- Right-size node pools to the work, and use fewer, larger nodes where the overhead is a big share.
- Set resource requests and limits accurately. Requests that are too high leave capacity reserved and idle.
- Use autoscaling for nodes and for pods, with sensible minimums.
- Use spot nodes for interruptible workloads. See spot and preemptible instances.
- Share clusters between teams and environments with namespaces, where isolation needs allow it.
- Look at autopilot and serverless modes, where the vendor bills per pod resources instead of per node, which can suit uneven workloads.
- Delete idle clusters. A forgotten development cluster bills every hour.
- Review logs and metrics that the cluster ships out.
Measuring
Use a cost allocation tool or the cloud’s own breakdown by namespace or label to see which team or service uses what. Without it, the node bill is one lump that nobody feels responsible for. See tags and labels.
What we price
Our estimators do not model Kubernetes clusters, because the cost depends on how you pack workloads onto nodes. You can price the nodes with the virtual machines catalog, then add the control plane and networking from the vendor’s pages. Sizing advice is in choosing a cloud VM size.