Kubernetes shared costs are the lines of a cluster that serve every team and belong to none: the system pods in kube-system, the add-ons, the logging and monitoring agents on every node, ingress controllers and the sidecars of a service mesh, and the fee for the control plane. They arise before the first workload runs, grow with the number of nodes rather than with one team's load, and reach the team numbers only through a distribution key. This page names the items, shows where they sit in the data, and works the usual keys through on one cluster. The general rule for shared cost holds here too; the nodes' idle is a remainder of its own (idle and unallocated cluster cost).

How it works

The items sort by their shape, because the shape decides how they grow.

The control plane fee is a fixed amount per cluster and hour, independent of nodes and load: on Amazon EKS USD 0.10 per hour in standard support and USD 0.60 in extended support, on AKS in the Standard tier USD 0.10 per hour, on GKE USD 0.10 per hour for every cluster, with a credit for one zonal or Autopilot cluster per billing account (EKS, AKS and GKE fees compared). It sits as a line of its own under the provider's Kubernetes service and is the only shared item that already carries that name on the bill.

DaemonSets grow with the nodes: a logging agent, a metrics exporter, the network agent and a cost agent run as one copy per node, and every copy occupies requests the node price pays for. On top comes the reservation every node holds back for the kubelet, the container runtime and the operating system, which never becomes allocatable. These costs arise in every node pool and on every node the autoscaler adds; they are why small nodes carry a larger fixed share (node pools and instance selection).

Deployments in kube-system and the add-on namespaces grow with the cluster, not with the nodes: CoreDNS, the metrics server, the Cluster Autoscaler or Karpenter, cert-manager, the ingress controller, the control plane of a service mesh. They have requests like any workload and appear in the allocation as pods with a namespace of their own. The sidecars of a service mesh are the special case: they run in the team's namespace, in every pod of the team, with requests of their own; their cost lands with the team although the mesh was a platform decision.

Then the items outside the nodes a cluster runs for everyone: one load balancer per ingress controller, the NAT gateways, the disks of the system components, the control plane logs the provider writes into its logging service and bills per gigabyte (services, load balancers and egress). They sit under services other than the cluster and are tied to it only through tags.

The tools name these remainders differently: OpenCost lists the system workloads as shared costs and the cluster fee as overhead; AWS split cost allocation data spreads instance costs over pods while the cluster fee stays a line beside them; AKS cost analysis shows system charges and service charges separately; GKE cost allocation writes the nodes' reservation under kube:system-overhead and lists kube-system as an ordinary namespace.

noyesthe nodesthe clusterA shared item of the clusterInside the nodes?The control plane fee, fixed percluster and hour; or the itemsoutside: load balancers, NAT gateways,system disks, control plane logs,under other services, tied in by tagsGrows with?DaemonSets and the node'sreservation: one copy andone share per nodeAdd-ons in kube-system: podswith a namespace of their own;mesh sidecars in the team's
Shared items sort by their shape: a fee per cluster, agents that grow with the nodes, add-ons that grow with the cluster, and items outside the nodes tied in only by tags

What it means for your cost

Three keys are common, and the OpenCost specification names them: evenly across tenants, proportionally to their share of asset costs, or by a custom metric. Even is simple and penalises small teams. Proportional follows consumption and lets a team influence its number through requests; it is the default for items that grow with the nodes, because the DaemonSets run where the workloads are. A custom metric fits where an item has a measurable driver: ingress cost by requests or bytes per team, logging by gigabytes ingested per namespace, the mesh sidecars per pod anyway. The cluster fee has no driver and is therefore distributed evenly or proportionally, or stays with the operator.

yesnoyes: requests, bytes,gigabytes, podsno: the cluster feeA shared itemGrows with the nodes?Proportional to the teams' assetcosts: the agents run wherethe workloads areA measurable driver?A custom metric: ingress byrequests, logging by gigabytes,sidecars per podEvenly, or kept as a linewith the operator
Items that grow with the nodes take the proportional key, items with a measurable driver a custom metric, and only what has neither is spread evenly

Which key applies is an allocation rule with a date, set per item and not decided afresh each month. Before distribution the items stay visible as lines of their own, per cluster, because only then can anyone see whether a cluster runs too many agents, a too expensive ingress or a control plane in extended support; distributed, they are part of every team number and a lever for nobody. One cluster per environment multiplies every fixed item (non-production clusters).

Where it goes wrong

  • Agents without requests. Symptom: a cluster's shared costs look small, its idle large. Cause: DaemonSets without requests are valued at zero by requests; their usage falls into the node's idle.
  • Sidecars charged to the team. Symptom: a team sees higher cost at the same load after the service mesh was introduced. Cause: the sidecar per pod carries its own requests in the team's namespace; the platform decision is charged to the team.
  • Extended support inside shared costs. Symptom: the cluster fee multiplies by six. Cause: the Kubernetes version left standard support; the item sits inside shared costs and nobody noticed.
  • One load balancer per cluster, one per service. Symptom: shared costs hold dozens of load balancers. Cause: Services of type LoadBalancer instead of one ingress; the items are not shared but belong to the services.
  • Key changed. Symptom: a team suddenly pays more shared cost with no change to its workloads. Cause: the distribution key changed, or another team left the cluster.
  • Control plane logs unseen. Symptom: the provider's logging service shows a cluster item nobody expected. Cause: audit and API server logs are switched on and billed per gigabyte, outside the cluster.

Example

List prices read on 2026-10-21: Amazon EKS USD 0.10 per cluster and hour in standard support; in Frankfurt (eu-central-1) an m6i.large (2 vCPU, 8 GiB) costs USD 0.115 per hour, which with the 9:1 ratio gives USD 0.0398 per vCPU-hour and USD 0.00442 per GiB-hour (what a pod costs); an Application Load Balancer costs USD 0.027 per hour before capacity units.

A cluster with ten nodes carries three DaemonSets requesting together 300 millicores and 384 MiB per node: 10 × (0.3 × 0.0398 + 0.375 × 0.00442) = 10 × 0.0136 = USD 0.136 per hour, USD 99.28 in a 730-hour month. CoreDNS, the metrics server and an ingress controller requesting together 1.5 vCPU and 2 GiB cost 1.5 × 0.0398 + 2 × 0.00442 = USD 0.0685 per hour, USD 50.01 a month. The cluster fee is USD 73.00, the ingress load balancer USD 19.71. Shared costs for the month: USD 242.00. With three teams, each pays USD 80.67 evenly. Proportionally, if team A carries 57 percent of the workload cost, it pays USD 137.94 and each of the other two USD 52.03. With a custom metric for the ingress, say 80 percent of requests from team A, A carries USD 15.77 of its USD 19.71 and the remaining USD 222.29 follow the key of the other items.

Sources

Read on 2026-10-21. OpenCost specification, Amazon EKS pricing, AWS Price List bulk API, offers AmazonEC2 and AWSELB, eu-central-1, AWS split cost allocation data, Microsoft AKS cost analysis, Google Cloud GKE cost allocation and GKE pricing, Kubernetes DaemonSet and reserving compute resources for system daemons.