Kubernetes Cost Review
Overview
Cost analysis framework for Kubernetes workloads. Reviews resource requests and limits, scaling configuration, storage provisioning, and environment-specific sizing. Every workload should be right-sized for its actual needs, with scaling policies that prevent both waste and outages.
Only triggers when there is clear evidence of Kubernetes usage. When ambiguous, ask the user before proceeding.
When to Use
- When reviewing K8s manifests for resource requests/limits optimization
- When auditing HPA/VPA configuration for scaling efficiency
- When checking storage provisioning (PVCs, storage classes)
- When evaluating workload sizing across environments (dev/staging/prod)
- When reviewing EKS-specific cost factors (Fargate, Spot, Karpenter)
When NOT to Use
- For Terraform cost review — use
terraform-cost-review instead
- For application performance tuning — this is resource cost, not performance
- When no K8s evidence is detected and user hasn't mentioned K8s
- For cluster-level cost (node sizing, reserved instances) without manifest context
Cost Analysis Process
Step 1: Resource Inventory
Scan all K8s manifests and inventory every workload. Categorize by:
- Compute: Deployments, StatefulSets, DaemonSets, Jobs, CronJobs
- Storage: PersistentVolumeClaims, StorageClasses
- Scaling: HPA, VPA, KEDA ScaledObjects
- Networking: Services (LoadBalancer type costs money), Ingress
See sizing-reference.md for workload sizing guidelines.
Step 2: Configuration Analysis
For each workload, check:
- Requests vs Limits — Are requests set? Are limits set? Is the gap reasonable?
- Over-provisioning — Requests significantly higher than actual usage indicators
- Under-provisioning — Missing requests (scheduler can't bin-pack efficiently)
- Scaling — HPA/VPA configured for variable-load workloads?
- Replica count — Appropriate for the workload type and environment?
- Storage sizing — PVC sizes reasonable? Storage class appropriate?
- Resource quotas — Namespace quotas and limit ranges in place?
Step 3: Environment-Specific Recommendations
For each workload, recommend resource values for dev, staging, and production. See sizing-reference.md for common sizing patterns.
Step 4: Deprecation Flag
If deprecated APIs with cost implications are found (e.g., deprecated autoscaling/v2beta1 HPA that affects scaling behavior, deprecated policy/v1beta1 PDB), flag them in findings and recommend running deprecation-check-and-upgrade for full migration guidance.
Common Cost Traps
| Trap |
Typical Impact |
Fix |
| No resource requests set |
Scheduler can't bin-pack, nodes under-utilized |
Set requests based on actual usage patterns |
| Requests == Limits for all containers |
No burst headroom, over-provisioned for steady state |
Set requests to P50, limits to P99 of actual usage |
| No HPA on variable-load workloads |
Paying for peak capacity 24/7 |
Add HPA with CPU/memory or custom metrics |
| LoadBalancer Service per microservice |
Cloud LB costs $15-25/month each |
Use Ingress controller with single LB, or ClusterIP + Ingress |
| Over-sized PVCs |
Paying for unused storage |
Right-size PVCs, use volume expansion if supported |
| High replica count in dev/staging |
Paying for prod-scale in non-prod |
Use Kustomize overlays to reduce replicas per environment |
| CronJobs with large resource requests |
Resources allocated for burst but idle most of the time |
Right-size to actual job needs, consider spot/preemptible |
EKS-Specific Cost Checks
Only apply when EKS is detected:
| Check |
Impact |
Recommendation |
| Fargate vs managed nodes |
Fargate premium ~20% over EC2 |
Use Fargate for bursty/small workloads, managed nodes for steady-state |
| No Spot instances for fault-tolerant workloads |
Paying full on-demand price |
Add karpenter.sh/capacity-type: spot or node group Spot config |
| Karpenter consolidation not enabled |
Nodes not bin-packed after scale-down |
Enable consolidation policy in Karpenter provisioner |
| GP2 volumes instead of GP3 |
GP2 is 20% more expensive with worse baseline |
Use GP3 storage class |
| No cluster autoscaler or Karpenter |
Nodes not scaling down when empty |
Configure node scaling for non-prod environments |
Related Skills
If you find issues outside the cost domain during the review, recommend the relevant K8s skill:
- RBAC misconfigurations, missing securityContext, secrets in env vars → recommend
kubernetes-security-audit
- Missing probes, no PDB, no graceful shutdown → recommend
kubernetes-operational-review
- Helm chart structural issues → recommend
kubernetes-helm-review
Supporting Files
sizing-reference.md — Resource sizing guidelines by workload type, common patternsreport-template.md — Full output format template for cost review reports
Source: infraspecdev/tesseract — distributed by TomeVault.
1---2name: kubernetes-cost-review3description: Use when reviewing Kubernetes manifests for cost optimization, resource right-sizing, or identifying over-provisioned workloads. Only triggers when K8s manifests are detected.4---56# Kubernetes Cost Review78## Overview910Cost analysis framework for Kubernetes workloads. Reviews resource requests and limits, scaling configuration, storage provisioning, and environment-specific sizing. Every workload should be right-sized for its actual needs, with scaling policies that prevent both waste and outages.1112Only triggers when there is clear evidence of Kubernetes usage. When ambiguous, ask the user before proceeding.1314## When to Use1516- When reviewing K8s manifests for resource requests/limits optimization17- When auditing HPA/VPA configuration for scaling efficiency18- When checking storage provisioning (PVCs, storage classes)19- When evaluating workload sizing across environments (dev/staging/prod)20- When reviewing EKS-specific cost factors (Fargate, Spot, Karpenter)2122## When NOT to Use2324- For Terraform cost review — use `terraform-cost-review` instead25- For application performance tuning — this is resource cost, not performance26- When no K8s evidence is detected and user hasn't mentioned K8s27- For cluster-level cost (node sizing, reserved instances) without manifest context2829## Cost Analysis Process3031### Step 1: Resource Inventory3233Scan all K8s manifests and inventory every workload. Categorize by:34- **Compute**: Deployments, StatefulSets, DaemonSets, Jobs, CronJobs35- **Storage**: PersistentVolumeClaims, StorageClasses36- **Scaling**: HPA, VPA, KEDA ScaledObjects37- **Networking**: Services (LoadBalancer type costs money), Ingress3839See `sizing-reference.md` for workload sizing guidelines.4041### Step 2: Configuration Analysis4243For each workload, check:4445- **Requests vs Limits** — Are requests set? Are limits set? Is the gap reasonable?46- **Over-provisioning** — Requests significantly higher than actual usage indicators47- **Under-provisioning** — Missing requests (scheduler can't bin-pack efficiently)48- **Scaling** — HPA/VPA configured for variable-load workloads?49- **Replica count** — Appropriate for the workload type and environment?50- **Storage sizing** — PVC sizes reasonable? Storage class appropriate?51- **Resource quotas** — Namespace quotas and limit ranges in place?5253### Step 3: Environment-Specific Recommendations5455For each workload, recommend resource values for dev, staging, and production. See `sizing-reference.md` for common sizing patterns.5657### Step 4: Deprecation Flag5859If deprecated APIs with cost implications are found (e.g., deprecated `autoscaling/v2beta1` HPA that affects scaling behavior, deprecated `policy/v1beta1` PDB), flag them in findings and recommend running `deprecation-check-and-upgrade` for full migration guidance.6061## Common Cost Traps6263| Trap | Typical Impact | Fix |64|------|---------------|-----|65| No resource requests set | Scheduler can't bin-pack, nodes under-utilized | Set requests based on actual usage patterns |66| Requests == Limits for all containers | No burst headroom, over-provisioned for steady state | Set requests to P50, limits to P99 of actual usage |67| No HPA on variable-load workloads | Paying for peak capacity 24/7 | Add HPA with CPU/memory or custom metrics |68| LoadBalancer Service per microservice | Cloud LB costs $15-25/month each | Use Ingress controller with single LB, or ClusterIP + Ingress |69| Over-sized PVCs | Paying for unused storage | Right-size PVCs, use volume expansion if supported |70| High replica count in dev/staging | Paying for prod-scale in non-prod | Use Kustomize overlays to reduce replicas per environment |71| CronJobs with large resource requests | Resources allocated for burst but idle most of the time | Right-size to actual job needs, consider spot/preemptible |7273## EKS-Specific Cost Checks7475Only apply when EKS is detected:7677| Check | Impact | Recommendation |78|-------|--------|---------------|79| Fargate vs managed nodes | Fargate premium ~20% over EC2 | Use Fargate for bursty/small workloads, managed nodes for steady-state |80| No Spot instances for fault-tolerant workloads | Paying full on-demand price | Add `karpenter.sh/capacity-type: spot` or node group Spot config |81| Karpenter consolidation not enabled | Nodes not bin-packed after scale-down | Enable consolidation policy in Karpenter provisioner |82| GP2 volumes instead of GP3 | GP2 is 20% more expensive with worse baseline | Use GP3 storage class |83| No cluster autoscaler or Karpenter | Nodes not scaling down when empty | Configure node scaling for non-prod environments |8485## Related Skills8687If you find issues outside the cost domain during the review, recommend the relevant K8s skill:88- RBAC misconfigurations, missing securityContext, secrets in env vars → recommend `kubernetes-security-audit`89- Missing probes, no PDB, no graceful shutdown → recommend `kubernetes-operational-review`90- Helm chart structural issues → recommend `kubernetes-helm-review`9192## Supporting Files9394- **`sizing-reference.md`** — Resource sizing guidelines by workload type, common patterns95- **`report-template.md`** — Full output format template for cost review reports9697---98> Source: [infraspecdev/tesseract](https://github.com/infraspecdev/tesseract) — distributed by [TomeVault](https://tomevault.io).99<!-- tomevault:4.0:skill_md:2026-06-15 -->
tomevault-io