Cost Attribution

Cost attribution is the process of determining:

1. How much each resource costs
2. Who is responsible for that cost
3. Why costs are what they are

Kubeadapt uses a bottom-up attribution model that traces costs from cloud provider bills down to individual pods.

---

Costs flow through four layers:

text
Copy
1Cloud Provider Bill (AWS/GCP/Azure/Custom)
2        ↓
3Node Costs (EC2/GCE/VM instances)
4        ↓
5Namespace/Team Allocation
6        ↓
7Workload/Pod Costs

Each layer is detailed below.

---

Where Costs Come From

Kubeadapt tracks four main cost sources:

1. Compute (Nodes)

• EC2 instances (AWS)
• Google Compute Engine (GCP)
• Virtual Machines (Azure)
• Bare metal servers (on-prem)

2. Storage (Volumes)

• EBS volumes (AWS)
• Persistent Disks (GCP)
• Azure Disks
• Network-attached storage

3. Network

• Data transfer (egress)

4. Control Plane

• EKS/GKE/AKS management fees

How Pricing Data is Obtained

For cloud providers (AWS/GCP/Azure):

Kubeadapt retrieves cloud provider pricing data automatically to calculate accurate costs for nodes and storage. Pricing is updated regularly and includes spot/reserved instance discounts when applicable.

For custom (non-cloud) environments:

Pricing can be configured via Kubernetes ConfigMap with resource-based pricing (CPU, RAM, GPU, storage rates) for on-premises datacenter or custom Kubernetes environments.

---

How Node Costs Are Determined

Kubeadapt determines node costs by matching instance types to cloud provider pricing data. Node costs are calculated hourly and converted to monthly estimates.

See Metrics Glossary for detailed cost calculation formulas.

Node Cost Components

Total node cost breaks down to:

1. Compute Cost (CPU + Memory)

• Cloud providers charge for instances as a bundled hourly rate (e.g., m5.2xlarge at $0.384/hour)

2. Attached Storage

• EBS volumes (AWS), Persistent Disks (GCP), Azure Disks attached to nodes
• Calculated separately from pod PVCs(EBS)
• Billed per GB-hour based on volume type and size

---

How Costs Are Allocated

Costs are attributed to namespaces/teams based on resource usage:

text
Copy
1Namespace Cost = Σ (All Pod Costs in Namespace)

Example:

text
Copy
1Namespace: production
2
3Pods:
4- api-server (4 replicas): 50% of namespace cost
5- postgres (1 replica): 31% of namespace cost
6- redis (3 replicas): 19% of namespace cost
7
8Total: 100% namespace allocation

---

The Core Attribution Algorithm

Pod costs are attributed proportionally based on what each pod requests relative to node capacity.

See Metrics Glossary for detailed cost calculation formulas.

Why Requests, Not Usage

Billing is based on requests, not actual usage:

• Requests = guaranteed resources (what you pay for)
• Usage = what's actually consumed (varies over time)
• Efficiency = Usage / Requests (tracked separately)

Usage data is still tracked for:

• Efficiency calculations
• Rightsizing recommendations
• Identifying waste when usage < requests

Storage Cost Attribution

For pods using Persistent Volume Claims (PVCs):

Storage costs are calculated separately from compute costs based on:

• Volume size
• Storage class (SSD, HDD, provisioned IOPS)
• Cloud provider and region

Storage is independent from compute:

• Persistent volumes exist separately from nodes
• Billed directly by cloud provider
• Attributed to the pod that claims the volume

How Costs Are Attributed

For each pod:

1. Calculate compute cost based on CPU and memory requests
2. Add storage costs from any attached PVCs
3. Attribute to namespace, team, and other configured dimensions (can be team, department, product, owner) based on labels

For deployments with multiple replicas:

• Compute costs scale linearly with replica count
• Storage costs may be shared (depending on PVC configuration)
• Total workload cost = sum of all pod costs

---

Handling Unattributed Costs

Some costs cannot be directly attributed to workload pods:

1. Kubelet & System Processes

• Kubelet, kube-proxy, and systemd processes running on each node
• These processes consume node resources but are not tracked as pods
• Allocation: Not distributed to workloads; appears as unattributed node overhead
• Example: On a node with 8 vCPU, workload pods may show 7.5-7.7 vCPU total usage, with the remaining ~0.3-0.5 vCPU used by kubelet and system processes

2. Idle Node Capacity

• Unused CPU/memory on nodes after accounting for all pod requests and system processes
• Allocation: Shown separately as "idle" capacity, not distributed to workloads

3. Control Plane Costs (EKS/GKE/AKS only)

• EKS/GKE/AKS management fees charged by cloud providers
• Allocation: Added as an additional cost on top of total cluster cost
• Not applicable to self-managed Kubernetes clusters

---

Now that you understand how costs are attributed:

• Resource Efficiency - Learn how to measure how efficiently your workloads use their allocated resources
• Right-Sizing - Optimize your pod requests to reduce waste and lower costs