Kubernetes Cost Optimization: Requests, Nodes and Schedules

Kubernetes cost optimization is the work of reducing what a cluster costs to run without starving the workloads on it. The bill arrives as ordinary cloud line items: worker nodes, persistent disks, load balancers, and a control plane fee. What makes Kubernetes different is the layer in between, where the resource requests on each pod decide how much node capacity the cluster has to hold.

Why requests drive the bill

The Kubernetes scheduler places a pod on a node only if, for each resource type, the sum of requests of the containers already scheduled there plus the new pod fits within the node’s capacity. It does not look at actual usage. Node autoscalers follow the same logic: the Kubernetes documentation notes that node consolidation considers pod resource requests, not real resource usage, when deciding which nodes can be removed.

The consequence is direct. A deployment that requests four CPUs and uses one still reserves four CPUs of node capacity, and the autoscaler keeps enough nodes to honour that reservation. Lowering inflated requests is what lets bin-packing and consolidation actually shrink the node count. The requests and limits guide covers how to set them.

What the control plane costs

Two practical points follow. Many small EKS or GKE clusters each carry their own hourly fee, so consolidating clusters where isolation allows removes fees outright. And an EKS cluster left on an old Kubernetes version costs six times more per hour in control plane fees than one on a supported version, which makes upgrades a cost item as well as a security one. GKE clusters kept in its extended support period pay an extra $0.50 per hour on top of the $0.10 fee. On AKS the choice is explicit: a Free tier cluster has no management fee, while moving a cluster to Standard for its SLA adds the hourly charge.

The levers, in order

1. Right-size requests. Compare requests with observed usage over a representative period. The Vertical Pod Autoscaler can recommend values, but it is an add-on you install, not part of core Kubernetes.
2. Let the node autoscaler work. With realistic requests, Cluster Autoscaler or Karpenter can consolidate underused nodes. Check that PodDisruptionBudgets do not block every eviction, or nodes can never drain.
3. Match node shapes to workloads. Separate node pools for memory-heavy and CPU-heavy workloads reduce stranded capacity on each node.
4. Know your billing model. On GKE Autopilot, general-purpose workloads are billed on pod resource requests, so inflated requests cost money directly instead of indirectly through nodes.
5. Turn off what nobody uses at night. Development and test namespaces or node pools can be scaled to zero outside working hours. Persistent volumes stay, and so does their storage charge, because disks bill while provisioned.

Where ZopNight helps

ZopNight discovers EKS, GKE, and AKS clusters and their workloads, and supports start and stop for the clusters and, per namespace, for the workloads in them: stopping a namespace scales its Deployments and StatefulSets to zero and suspends its CronJobs, removing HPAs and PDBs on stop and restoring them on start, while system namespaces are skipped. Its Kubernetes workload recommendations flag missing requests and limits, idle workloads, orphaned volumes, and CPU over-provisioning signalled by an HPA that wants to scale below its minimum. The rules themselves are described in Kubernetes workload rules, and namespace scheduling in namespace-level scheduling.