Kubernetes cost glossary

Bin packing is the practice of placing pods onto as few nodes as possible, so each node's capacity is filled by pod requests and fewer nodes need to run.

The Kubernetes scheduler supports bin packing through the MostAllocated and RequestedToCapacityRatio scoring strategies of the NodeResourcesFit plugin, which favor nodes that are already highly allocated. Packing tightly leaves the least-utilized nodes empty so a node autoscaler such as the Cluster Autoscaler or Karpenter can remove them. Bin packing only works on requests, so it fixes scheduling waste (unrequested node capacity) but not overprovisioning (requests far above usage); the two compound.

In Kubeadapt: Kubeadapt's node views separate scheduling waste (capacity no pod requested) from over-provisioning waste (requests above usage), so you can tell whether a bin packing or a rightsizing change will save more.

• Resource efficiency
• Cost monitoring
• Source: Resource Bin Packing (Kubernetes documentation)

Carbon intensity is the amount of greenhouse gas emitted per kilowatt-hour of electricity, expressed in grams of CO₂ equivalent (gCO₂e/kWh); CO₂e converts all greenhouse gases into the warming effect of an equal mass of CO₂.

Ember's Global Electricity Review 2026 reports that the global emissions intensity of electricity fell from 533 gCO₂e/kWh in 2015 to 458 gCO₂e/kWh in 2025. Intensity varies widely by grid, so the same Kubernetes workload emits very different amounts depending on the cloud region it runs in. The Green Software Foundation's Software Carbon Intensity (SCI) specification uses it directly: operational emissions are energy consumed (E) multiplied by regional carbon intensity (I), plus embodied hardware emissions (M), per functional unit (R).

In Kubeadapt: Kubeadapt GreenOps estimates kg CO₂e per workload, namespace and cluster with the Cloud Carbon Footprint methodology, using regional grid intensity from Ember and per-provider PUE.

• GreenOps
• Sustainability methodology
• Source: Global Electricity Review 2026, electricity demand and supply trends (Ember)

Chargeback is the practice of formally posting each team's or business unit's share of cloud cost to that unit's budget in the organization's finance systems, so the profit-and-loss owner bears the cost of the resources it consumes.

The FinOps Foundation describes the difference between chargeback and showback as one of formality: showback reports cost to a team, while chargeback moves the expense into official accounting records. Showback is required in every FinOps practice; chargeback is optional and depends on the organization's accounting policy. In Kubernetes, chargeback needs a defensible way to split shared clusters, which means agreeing how idle and shared cost are distributed before any number reaches finance.

In Kubeadapt: Kubeadapt does not post entries to finance systems; it produces per-team and per-department cost, which you can export grouped by team for your chargeback process.

• Cost attribution
• Trace cost to a team
• Source: Invoicing & Chargeback capability (FinOps Foundation)

Cluster Autoscaler is an open-source Kubernetes component that adds nodes when pods cannot be scheduled for lack of resources and removes nodes that are no longer needed.

Cluster Autoscaler works on top of node groups (such as AWS Auto Scaling groups or GKE node pools) and scales up the group whose template best fits the pending pods. By default it considers a node for removal when the sum of its pods' CPU and memory requests is below 50% of the node's allocatable capacity and those pods can run elsewhere, and it terminates a node after it has been unneeded for 10 minutes. Because every decision is based on requests, not actual usage, inflated requests keep nodes alive that real usage would not need.

• Workload rightsizing
• How costs are computed
• Source: Cluster Autoscaler FAQ (kubernetes/autoscaler)

Committed use discounts (CUDs) are Google Cloud discounts granted in exchange for committing to a minimum level of resource usage or a minimum spend over a fixed term.

Google Cloud offers two kinds: spend-based commitments, a minimum spend on eligible services for one or three years applied at the billing account level, and resource-based commitments, a minimum amount of Compute Engine resources. Discount rates are listed on each product's pricing page. For Kubernetes on GKE, commitments only pay off when the committed baseline is actually used every hour, so rightsizing and bin packing should come before sizing a commitment.

In Kubeadapt: Kubeadapt prices GCP workloads at on-demand and spot rates; committed use discounts are not reflected in its cost figures.

• How costs are computed
• Source: Committed use discounts (Google Cloud documentation)

Cost allocation is the practice of assigning cloud cost and usage to the teams, products or cost centers responsible for it, using accounts, tags, labels and other metadata.

The FinOps Foundation defines Allocation as defining strategies to assign and share cost and usage using accounts, tags, labels, and other metadata, and tracks the percentage of cost that cannot be allocated as a key measure. In Kubernetes, the cloud bill shows nodes, disks and load balancers rather than the teams whose pods share them, so allocation has to be computed from workload requests and usage and then mapped to owners, usually through labels or namespaces. Allocation feeds showback and chargeback.

In Kubeadapt: Kubeadapt maps each workload to a Team and optional Department by Kubernetes label or manual assignment, and can split one shared workload across up to 10 teams by percentage.

• Cost attribution
• Cost attribution concepts
• Source: Allocation capability (FinOps Foundation)

Cost per workload is the share of cluster cost attributed to a single Deployment, StatefulSet, Job or other controller, computed from the CPU, memory and GPU it reserves or uses multiplied by the price of those resources on its nodes; cost per namespace is the sum of its workloads.

The OpenCost specification counts a workload's CPU and memory at the greater of what it requested and what it actually used, because a request reserves capacity whether or not it is consumed. A workload figure can be reported two ways: with only its own compute, or fully loaded with a proportional share of idle node capacity and cluster overhead such as the control plane fee and system pods. Only the fully loaded figures add up to the cluster bill; the compute-only figure is better for comparing one workload against another.

In Kubeadapt: Kubeadapt computes cost per container, pod, workload and namespace bottom-up as max(request, usage) times per-resource node rates, and reports it in two modes: Fully Loaded (includes idle and overhead, sums to the cluster total) and Workload Only (capped compute only).

• Cost modes
• How costs are computed
• Cost monitoring
• Source: OpenCost Specification

CPU throttling is the Linux kernel pausing a container's threads once it has used its CPU quota for the current scheduling period, which is how Kubernetes enforces CPU limits.

Kubernetes translates a CPU limit into a CFS bandwidth quota; the kernel's default period is 100 ms, and throttled threads cannot run again until the next period begins. A container with a 300m CPU limit can therefore use at most 30 ms of CPU in each 100 ms period, even when the node has idle cores. Throttling shows up as added latency rather than an error, and it does not lower cost, because billing and scheduling follow requests, not limits.

In Kubeadapt: Kubeadapt collects CPU throttling events with usage every 60 seconds and, for very bursty workloads, recommends removing the CPU limit while still rightsizing the request.

• Rightsizing concepts
• Workload rightsizing
• Source: CFS Bandwidth Control (Linux kernel documentation)

Cross-AZ data transfer is network traffic between resources in different availability zones of the same cloud region, which AWS and other providers bill per gigabyte even though it never leaves the region.

As of October 2026, the AWS price list for US East (N. Virginia) charges $0.01 per GB for data transferred in or out between EC2 Availability Zones. Kubernetes makes this traffic easy to create: by default kube-proxy spreads Service traffic across all endpoints regardless of zone, so a cluster spread over three zones for availability sends much of its pod-to-pod traffic across zones. Topology aware routing and trafficDistribution: PreferSameZone keep traffic in-zone when a local endpoint exists, as described in the EKS cost optimization guide.

In Kubeadapt: Kubeadapt Network Intelligence (early access) measures cross-zone traffic and its cost per workload with the optional eBPF agent.

• Network Intelligence
• Source: AWS Price List API, AWS Data Transfer offer for US East (N. Virginia)

eBPF is a Linux kernel technology that runs sandboxed programs inside the kernel without changing kernel source code or loading kernel modules, used for networking, observability and security.

Before an eBPF program is attached, the kernel's verifier checks that it is safe to run: that it terminates, stays within memory bounds and stays within size and complexity limits. Because eBPF programs see every packet and system call on a node, they can count network bytes per pod without sidecars or application changes. For Kubernetes cost, this is how traffic that the cloud bill only reports per account or per network interface can be attributed to the workloads that generated it.

In Kubeadapt: Kubeadapt's optional eBPF agent runs as a privileged DaemonSet on Linux kernel 5.10 or newer and counts cross-zone and internet egress traffic per workload; it is off by default and does not record request or response bodies.

• eBPF agent configuration
• Network Intelligence
• Source: What is eBPF? (ebpf.io)

Egress is network traffic that leaves a cloud provider's network, most commonly data sent from your cluster to the internet, which is billed per gigabyte while inbound traffic is free.

As of October 2026, the AWS price list for US East (N. Virginia) charges $0.09 per GB for the first 10 TB a month of data transferred out to the internet, falling to $0.05 per GB above 150 TB, after the 100 GB monthly free allowance. In Kubernetes, egress comes from calls to third-party APIs, public container registry pulls, backups and responses to users, and pods in private subnets usually reach the internet through a NAT gateway, which adds its own per-GB charge. The bill shows egress per account or resource, not per workload, so attributing it needs network-level measurement.

In Kubeadapt: Kubeadapt Network Intelligence (early access) shows internet egress traffic and its cost per workload, measured by the optional eBPF agent.

• Network Intelligence
• Source: AWS Price List API, AWS Data Transfer offer for US East (N. Virginia)

FinOps is an operational framework and cultural practice that maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.

The definition is maintained by the FinOps Foundation, whose framework groups the work into capabilities such as cost allocation, unit economics, usage optimization and rate optimization (Reserved Instances, Savings Plans, committed use discounts). Kubernetes is a common FinOps blind spot because many teams share the same nodes, so the cloud bill cannot say which team caused which cost without workload-level allocation.

• Cost monitoring
• Cost attribution
• Source: What is FinOps? (FinOps Foundation)

FOCUS is an open specification that normalizes billing datasets across AI, cloud, SaaS, data center and other technology vendors into one common set of columns and definitions.

As of October 2026 the latest version is FOCUS 1.4. A FOCUS Cost and Usage dataset defines columns such as BilledCost, EffectiveCost and ListCost, so that cost from different providers can be queried together without per-vendor translation. Providers including AWS, Microsoft Azure, Google Cloud and Oracle publish FOCUS-format billing data. Kubernetes cost has to be computed per workload before it can be expressed in FOCUS, because the cloud bill itself only lists nodes and other infrastructure.

In Kubeadapt: Kubeadapt exports Kubernetes cost as a FOCUS 1.4 Cost and Usage file in CSV, JSON Lines or Parquet.

• FOCUS export API
• Cost monitoring
• Source: FOCUS (FinOps Open Cost and Usage Specification)

GPU cost in Kubernetes is the price of the GPUs a container is allocated, which is charged whether or not the GPU is busy; GPU utilization is the share of that allocated GPU capacity actually used.

Kubernetes exposes GPUs as extended resources such as nvidia.com/gpu that are specified in limits, and if a GPU request is also set it must equal the limit. A GPU allocated to a container is therefore paid for in full even when utilization is low, so low utilization on an expensive GPU node translates directly into paid-for idle capacity. Per-GPU utilization comes from vendor tooling, typically NVIDIA's DCGM Exporter.

In Kubeadapt: Kubeadapt prices GPU by request at the published per-GPU rate and collects NVIDIA GPU utilization and memory from DCGM Exporter when it runs in the cluster.

• GPU monitoring
• How costs are computed
• Source: Schedule GPUs (Kubernetes documentation)

The Horizontal Pod Autoscaler (HPA) is a Kubernetes controller that changes the number of replicas of a Deployment, StatefulSet or similar workload so capacity follows demand.

By default the HPA controller runs every 15 seconds and computes desiredReplicas = ceil(currentReplicas × currentMetricValue / desiredMetricValue). For CPU and memory targets, utilization is measured as a percentage of each container's resource request, and if a container has no request the HPA takes no action for that metric. Inflated requests make HPA scale out late; every added replica also adds its full request to the cluster, so replica count and request size together set the cost.

• Workload rightsizing
• Rightsizing concepts
• Source: Horizontal Pod Autoscaling (Kubernetes documentation)

Idle cost is the cost of node capacity that is paid for but not allocated to any workload, the difference between what the nodes cost and what the pods on them account for.

The OpenCost specification defines cluster idle costs as the portion of resource allocation costs not allocated to any workload, and gives total cluster cost as workload costs plus idle costs plus cluster overhead. For example, a node that costs $50 a day hosting pods that account for $35 a day has $15 a day of idle cost. Idle is reduced by bin packing, node consolidation and smaller nodes, and it can be either reported on its own or distributed across workloads.

In Kubeadapt: Kubeadapt's Fully Loaded cost mode distributes node idle across the workloads on each node in proportion to their compute share; the Fully Loaded total minus the Workload Only total is your idle plus overhead.

• How costs are computed
• Cost modes
• Source: OpenCost Specification

Karpenter is an open-source Kubernetes node lifecycle manager that launches right-sized nodes directly for unschedulable pods and removes or replaces nodes that are no longer needed.

Karpenter watches for pods the scheduler has marked unschedulable, evaluates their scheduling constraints (resource requests, node selectors, affinities, tolerations and topology spread), provisions nodes that satisfy them, and disrupts nodes that are empty or can be consolidated. The Cluster Autoscaler resizes predefined node groups, while Karpenter creates nodes chosen to fit the pending pods; both are sponsored by Kubernetes SIG Autoscaling. Like every node autoscaler, Karpenter sizes nodes from pod requests, so it cannot remove capacity that oversized requests are still reserving.

• Workload rightsizing
• Resource efficiency
• Source: Karpenter documentation

Kubernetes labels for cost attribution are key/value pairs, such as team: payments, set on workloads, namespaces or nodes so that cost tools can group spend by owner, product, environment or cost center.

Kubernetes defines labels as key/value pairs attached to objects that carry identifying attributes meaningful to users; a key has an optional DNS-subdomain prefix and a name of at most 63 characters. Labels set on a Deployment's pod template flow to every replica, so labeling controllers rather than individual pods keeps attribution stable through rollouts. Missing or inconsistent labels are the most common reason Kubernetes cost ends up unallocated.

In Kubeadapt: Kubeadapt reads configurable team, department, owner and environment label keys on every cluster snapshot to keep team assignments in sync, and a manual assignment always overrides the label.

• Label-based attribution
• Cost attribution
• Source: Labels and Selectors (Kubernetes documentation)

A NAT gateway is a managed network address translation service that lets resources in private subnets, such as Kubernetes nodes and pods, open connections to the internet or to public service endpoints while staying unreachable from outside.

As of October 2026, AWS's own pricing example for US East (Ohio) charges $0.045 per NAT gateway-hour plus $0.045 per GB processed, and the processing charge applies to every gigabyte regardless of source or destination. Traffic between a node and a NAT gateway in a different Availability Zone adds cross-AZ data transfer charges, and traffic to the internet adds egress charges. Traffic to S3 or DynamoDB can bypass the NAT gateway through a gateway VPC endpoint, which has no hourly or data processing charge.

• Network Intelligence
• eBPF agent configuration
• Source: Amazon VPC pricing

A node group (called a node pool on GKE and AKS) is a set of Kubernetes nodes in one cluster that share the same configuration, such as instance type, image, labels and on-demand or spot capacity type.

On Amazon EKS, every managed node is part of an EC2 Auto Scaling group managed by EKS, and a managed node group uses either On-Demand or Spot capacity, labeled eks.amazonaws.com/capacityType. On GKE, a node pool is a group of nodes within a cluster that all have the same configuration. Node groups are the unit the Cluster Autoscaler scales and the usual place to separate spot, GPU and general-purpose capacity, so cost per node group shows which capacity type and instance family is driving the bill.

In Kubeadapt: Kubeadapt reports cost per node and per node group alongside cost per cluster, namespace and workload.

• Cost monitoring
• Spot migration
• Source: Simplify node lifecycle with managed node groups (Amazon EKS User Guide)

OOMKilled is the termination reason Kubernetes reports when a container is killed for using more memory than its memory limit, typically with exit code 137.

Memory is not compressible, so unlike CPU it cannot be throttled: a container that keeps allocating beyond its limit is terminated, and the kubelet restarts it if its restart policy allows, which can produce a crash loop. Memory limits are enforced reactively, when the kernel detects memory pressure, so a container may briefly exceed its limit before being killed. OOM kills are the main risk of cutting memory requests and limits too aggressively, which is why memory is usually sized from a higher percentile or the observed peak.

In Kubeadapt: Kubeadapt records OOM kill events and bases its memory limit recommendation on the maximum observed memory, not a percentile.

• Rightsizing concepts
• Workload rightsizing
• Source: Assign Memory Resources to Containers and Pods (Kubernetes documentation)

Overprovisioning is reserving more CPU, memory or nodes than a workload uses, so the cluster pays for capacity that sits idle.

Cast AI's 2025 Kubernetes Cost Benchmark Report, based on 2024 data from more than 2,100 organizations on AWS, Google Cloud and Azure, found average CPU utilization of 10% and memory utilization of 23%. In Kubernetes, overprovisioning happens at two layers: pod requests set far above usage, and nodes left partly unrequested. The first is fixed by rightsizing, the second by bin packing and node autoscaling.

In Kubeadapt: Kubeadapt measures resource efficiency as usage divided by requests for CPU and memory and rolls it up from pod to workload, namespace and cluster.

• Resource efficiency
• Workload rightsizing
• Source: Cast AI 2025 Kubernetes Cost Benchmark Report press release

Percentile-based sizing sets a container's resource request from a high percentile of its observed usage, such as P95 (the value usage stays at or below 95% of the time), instead of from the average or the absolute peak.

Averages hide spikes and peaks are set by rare outliers, so a percentile plus a safety margin is the common middle ground. The Kubernetes Vertical Pod Autoscaler recommender, for example, defaults to the 90th percentile of usage for both CPU and memory targets and adds a 15% safety margin. Higher percentiles suit memory, where running short causes an OOM kill, while CPU can tolerate a lower percentile because exceeding it only causes throttling.

In Kubeadapt: Kubeadapt's production profile sizes requests from P95 CPU and P99 memory over a 7-day lookback, plus growth and spike buffers; the non-production profile uses P50.

• Rightsizing concepts
• Workload rightsizing
• Source: Vertical Pod Autoscaler flags (kubernetes/autoscaler)

Persistent volume cost is what a cloud provider charges for the block or file storage behind a Kubernetes PersistentVolume, billed on provisioned size whether or not it holds data; an orphaned volume is one that no workload claims but that still exists and is still billed.

Block storage is billed per provisioned GB-month until it is released; AWS's EBS pricing example uses $0.08 per GB-month for gp3, so a forgotten 500 GB gp3 volume costs $40 a month (prices as of October 2026). Orphans usually come from the Retain reclaim policy: when the claim is deleted, the PersistentVolume is only released, and the Kubernetes documentation notes that the storage asset in external infrastructure still exists until someone deletes it manually. Dynamically provisioned volumes inherit their StorageClass reclaim policy, which defaults to Delete, so orphans typically come from StorageClasses or volumes set to Retain.

In Kubeadapt: Kubeadapt lists PersistentVolumes with no bound claim, with their monthly cost and a cleanup-safety rating; it does not delete them for you.

• Orphaned resources
• Recommendations
• Source: Amazon EBS pricing

Reserved Instances (RIs) are an AWS billing discount on EC2 usage in exchange for a one-year or three-year commitment to a specific instance configuration.

AWS lists discounts of up to 72% off On-Demand for Standard RIs and up to 66% for Convertible RIs, which can be exchanged for a different instance family, operating system or tenancy. If an Availability Zone is specified, the RI also reserves capacity there; otherwise the discount applies across zones in the region. For Kubernetes, an RI only saves money while nodes of the reserved type keep running, so node autoscalers that change instance types can leave reservations unused.

In Kubeadapt: Kubeadapt reads Reserved Instance and Savings Plans rates from a connected AWS account and prices workloads with them, except GPU, which is priced at the published rate.

• How costs are computed
• AWS integration
• Source: Amazon EC2 Reserved Instances pricing

A resource limit is the maximum amount of CPU or memory a container is allowed to use, enforced on the node by the kubelet and the Linux kernel.

CPU limits are enforced by throttling and memory limits by out-of-memory kills (OOMKilled). Limits do not affect scheduling or what capacity is reserved, so tightening them does not reduce cost; only requests do. Setting limits equal to requests for every container gives a pod the Guaranteed QoS class, while requests below limits give the Burstable class, which can use spare node capacity but is evicted before Guaranteed pods under node pressure.

In Kubeadapt: Kubeadapt treats limits as anomaly protection: its recommendations set CPU limits at 1.2x the recommended request and memory limits from peak observed usage with a 1.3x buffer.

• Rightsizing concepts
• Best practices checks
• Source: Resource Management for Pods and Containers (Kubernetes documentation)

A resource request is the amount of CPU or memory a container declares it needs; the Kubernetes scheduler uses it to place the pod and the kubelet reserves at least that amount on the node.

Because requested capacity is reserved whether or not it is used, requests, not actual usage, determine how many nodes a cluster needs and therefore most of its cost. A container may use more than its request if the node has spare capacity, up to its limit. The Horizontal Pod Autoscaler, the Cluster Autoscaler and Karpenter all make decisions from requests, which is why oversized requests are the main source of Kubernetes overprovisioning.

In Kubeadapt: Kubeadapt charges each container the greater of its request and its usage, and its rightsizing recommendations change requests, which is where the savings come from.

• How costs are computed
• Workload rightsizing
• Source: Resource Management for Pods and Containers (Kubernetes documentation)

Rightsizing is adjusting the resources allocated to a workload, in Kubernetes mainly its CPU and memory requests and limits, so they match observed usage with a safety margin.

The FinOps Foundation lists rightsizing under Usage Optimization, the capability of analyzing resources to match actual usage patterns. In Kubernetes, lowering an oversized request frees schedulable capacity, which lets bin packing and node autoscalers run fewer nodes; lowering a memory request too far risks OOM kills. Rightsizing is usually based on a percentile of several days of usage rather than a single snapshot.

In Kubeadapt: Kubeadapt recommends CPU and memory request and limit changes as YAML from about 7 days of usage; you review them and apply them through your own deployment process, because Kubeadapt does not change workloads.

• Workload rightsizing
• Rightsizing guide
• Rightsizing concepts
• Source: Usage Optimization capability (FinOps Foundation)

Savings Plans are an AWS pricing model that gives lower prices than On-Demand in exchange for a commitment to a fixed amount of compute spend, measured in dollars per hour, for one or three years.

AWS lists Compute Savings Plans at up to 66% off, applying across Amazon EC2, AWS Lambda and AWS Fargate, and EC2 Instance Savings Plans at up to 72% off for a chosen instance family in a region. Spend on Spot Instances does not count toward a Savings Plans commitment. Because Compute Savings Plans follow spend rather than instance type, they suit Kubernetes clusters whose node types change under autoscaling better than instance-specific reservations.

In Kubeadapt: Kubeadapt reads Savings Plans and Reserved Instance rates from a connected AWS account and uses them to price AWS workloads, except GPU.

• How costs are computed
• AWS integration
• Source: Savings Plans FAQ (AWS)

Showback is reporting each team's or business unit's cloud cost back to it for visibility and accountability, without formally charging that cost to the team's budget.

The FinOps Foundation states that showback is always required in a FinOps practice, while chargeback, which posts the cost to finance systems, is optional; neither is considered more mature than the other. For Kubernetes, showback needs cost allocation down to namespaces or workloads and a clear owner for each, because many teams share the same nodes. It is often the first step that gets teams to act on rightsizing recommendations.

In Kubeadapt: Kubeadapt shows cost per team and department under Cost Attribution, using the same cost numbers as Cost Explorer and Reports.

• Cost attribution
• Teams and departments
• Source: Invoicing & Chargeback capability (FinOps Foundation)

Spot instances are spare cloud compute capacity sold below the on-demand price that the provider can reclaim at short notice; Google Cloud calls them Spot VMs and Azure calls them Spot Virtual Machines.

On AWS, the Spot price is set per instance type and Availability Zone, and EC2 gives a two-minute interruption notice before reclaiming an instance. Google Cloud lists Spot VMs at up to 91% off the on-demand price and describes them as the latest version of preemptible VMs. In Kubernetes, spot nodes suit stateless, replicated workloads with PodDisruptionBudgets; single-replica workloads and pods with zone-bound persistent volumes are risky to move.

In Kubeadapt: Kubeadapt's Spot Migration view scores each workload's risk of running on spot, using factors such as replicas, PodDisruptionBudgets and persistent storage, and estimates the monthly savings.

• Spot migration
• Plan a safe spot migration
• Recommendations
• Source: Spot Instances (Amazon EC2 User Guide)

Unallocated cost is spend that cannot be attributed to any team or owner; shared cost is spend that serves many teams, such as the control plane, system pods and DaemonSets, and must be split among them by an agreed rule.

The FinOps Foundation tracks the percentage of costs that cannot be categorized and allocated directly as a core allocation metric. The OpenCost specification treats shared costs as costs organizations can optionally distribute among tenants, either evenly, in proportion to each tenant's share of cluster asset costs, or by a custom metric. In Kubernetes, unallocated cost usually comes from unlabeled workloads, and shared cost comes from cluster overhead and idle capacity.

In Kubeadapt: In Kubeadapt, workloads with no label or assignment roll up to Unassigned in attribution views, and the Fully Loaded cost mode distributes cluster overhead and idle across workloads by compute share.

• Cost modes
• Cost attribution
• Source: Allocation capability (FinOps Foundation)

Unit economics in cloud cost management is expressing technology spend per unit of business or technical output, such as cost per customer, per transaction or per API request.

The FinOps Foundation defines Unit Economics as developing and tracking metrics that connect what an organization spends on technology with the value that spending creates, and lists examples such as cost per customer, cost per transaction, cost per GB transferred and cost per API call. Cost per request divides a workload's cost by the requests it served in the same period; for example, a service that costs $1,200 a month and serves 60 million requests costs $20 per million requests. Unit cost separates growth from waste: total spend can rise while cost per request falls.

• Cost monitoring
• Cost modes
• Source: Unit Economics capability (FinOps Foundation)

The Vertical Pod Autoscaler (VPA) is a Kubernetes autoscaler that recommends, and optionally applies, CPU and memory requests and limits for a workload based on its observed usage.

VPA has three components: a recommender that analyzes usage, an updater that evicts pods or resizes them in place when the cluster supports it, and an admission controller that sets resources on new pods. In Off mode it only produces recommendations; Initial, Recreate and InPlaceOrRecreate apply them at different points. To avoid conflicts with the Horizontal Pod Autoscaler, the VPA FAQ shows restricting VPA to memory while HPA scales on CPU.

In Kubeadapt: Kubeadapt does not run in the update path: it produces request recommendations from observed usage that you review and apply through your own deployment process.

• Workload rightsizing
• Rightsizing concepts
• Source: Vertical Pod Autoscaling (Kubernetes documentation)