Karpenter provisions and consolidates nodes. Everything else in a production setup comes from somewhere else: workload rightsizing, cost allocation and reporting, multi-cluster policy, commitment coordination, and observability of what Karpenter decided and why. The ecosystem around it divides into those five layers, and knowing which layer a tool sits in is the fastest way to work out whether two tools you are evaluating actually compete.
Key takeaways
- Karpenter provisions and consolidates nodes. It does not rightsize workloads, allocate costs, manage multi-cluster policy, or purchase commitments.
- The ecosystem around Karpenter divides into five layers: rightsizing, cost visibility, fleet policy, commitment coordination, and observability.
- Knowing which layer a tool lives in tells you instantly whether two tools compete or complement each other.
- 69% of clusters overprovision CPU (Cast AI 2026 State of Kubernetes Optimization Report). Layer 1 tools fix the requests that Karpenter relies on to size nodes.
- Each layer has open-source options and commercial alternatives. You do not need commercial tooling at every layer to get started.
What Karpenter does and where its scope ends
If you have already deployed Karpenter, you know what it handles. It watches for pending pods, selects the right instance type from your NodePool constraints, launches nodes just-in-time, and consolidates underutilized capacity. Karpenter v1.14.0 (July 2026) introduced the Balanced consolidation policy, the CapacityBuffer API for handling pod burst traffic, and DRA (Dynamic Resource Allocation) support. The Balanced policy (added in v1.14.0) weighs the savings from consolidating a node against the cost of disrupting the pods on it. It avoids draining a node when the disruption cost is high relative to the savings, useful for mixed clusters where some workloads tolerate interruption and others do not. For a full introduction to Karpenter, see our foundational post.
However, the official Karpenter FAQ is explicit about what it does not do: “Scaling the pods themselves is outside of its scope. This is the realm of pod autoscalers such as the Vertical Pod Autoscaler or the Horizontal Pod Autoscaler.”
Where Karpenter’s scope formally ends
- Pod rightsizing: Karpenter does not adjust CPU or memory requests. It provisions nodes sized to whatever requests it receives from the scheduler.
- Cost allocation: There is no namespace-level or team-level cost breakdown in Karpenter. You get instance price estimates in metrics, not billing attribution.
- Multi-cluster policy: Karpenter is single-cluster scoped. It has no cross-cluster view or federated management capability.
- Commitment management: Karpenter does not factor Reserved Instances or Savings Plans into node selection. It picks instances purely from NodePool constraints.
- Decision auditability: Karpenter exposes what happened in metrics. It does not explain why each instance type was chosen in human-readable form.
For a deeper treatment of where Karpenter falls short in practice, read the full Karpenter limitations breakdown. These gaps are not bugs. They are deliberate scope boundaries. Each one represents a layer where additional tooling delivers the most value.
The five layers around it
Every tool that works with Karpenter fits into one of five distinct layers. The layers are ordered by where they sit in relation to Karpenter’s provisioning loop.
- Layer 1 – Workload rightsizing: Fixes pod resource requests before Karpenter reads them. Directly determines the node sizes Karpenter provisions.
- Layer 2 – Cost visibility and allocation: Attributes Karpenter-provisioned infrastructure costs to namespaces, teams, and workloads.
- Layer 3 – Multi-cluster and fleet policy: Distributes Karpenter configurations and workloads across clusters. Adds a centralized governance layer above individual Karpenter instances.
- Layer 4 – Commitment and Spot coordination: Blends Reserved Instances and Savings Plans with Karpenter’s dynamic instance selection to maximize effective savings rate.
- Layer 5 – Observability of provisioning decisions: Adds dashboards, alerts, and audit logs on top of Karpenter’s Prometheus metrics endpoint.
Tools in different layers do not compete. Therefore, a team can run VPA (Layer 1), OpenCost (Layer 2), Argo CD (Layer 3), and the kubernetes-autoscaling-mixin (Layer 5) alongside Karpenter without any conflict. Tools within the same layer may compete, and the sections below explain the practical trade-offs.
Layer 1: workload rightsizing
According to the Cast AI 2026 State of Kubernetes Optimization Report, 69% of clusters overprovision CPU. Average CPU utilization on autoscaled clusters sits at just 8%. These numbers exist because Karpenter cannot fix the requests it receives. It provisions nodes based on whatever CPU and memory requests arrive in the scheduler queue.
Over-requested pods cause Karpenter to launch larger nodes than the workload actually needs. As a result, you pay for capacity that sits idle. Rightsizing tools fix the input before provisioning runs. The combination of rightsizing and Karpenter compounds: better requests lead to better bin-packing, which leads to fewer and smaller nodes.
If Karpenter is running and still not reducing your costs, the root cause is often this layer. Rightsizing must happen before or alongside node provisioning to capture the full savings.
Open-source options
Vertical Pod Autoscaler (VPA) is the Kubernetes-native starting point. It operates in Recommendation mode (suggest only) or Auto mode (apply with pod restart). VPA conflicts with HPA when both tools target the same resource dimension, typically CPU. VPA reduces the CPU request while HPA uses CPU utilization to decide replica count. If VPA reduces requests, utilization ratios can spike, triggering HPA scale-out that defeats the rightsizing. Limit VPA to memory requests only on HPA-managed deployments, or use recommend-only mode. Most teams begin with Recommendation mode and apply changes manually. VPA is free and works with any cluster without additional dependencies.
Goldilocks (Fairwinds) builds on top of VPA. It creates VPA objects for each deployment in labelled namespaces, then surfaces the recommendations in a visual dashboard. Critically, it does not enforce changes. This makes it the right starting point for teams that want recommendation visibility before committing to any automation.
Commercial options
StormForge (now part of CloudBolt Software) uses forecast-based ML to generate rightsizing recommendations. Its key advantage is handling bursty or variable workloads where naive VPA Auto mode risks triggering incidents. It also harmonizes HPA and VPA, avoiding the conflict that plagues vanilla VPA Auto mode on deployments with both autoscalers active.
Cast AI PrecisionPack integrates directly into the Karpenter provisioning loop. It continuously observes actual CPU and memory consumption, adjusts requests automatically, and feeds corrected values into Karpenter’s bin-packing before node selection runs. The result is a full pipeline: rightsizing, then bin-packing, then node launch. On top of that, Cast AI’s container live migration enables rightsizing for stateful workloads that standard VPA-based restarts cannot safely handle. Teams that deploy Cast AI PrecisionPack alongside Karpenter typically see CPU requests align to actual p95 usage within two weeks. Cast AI is commercial software, try it for free.
Event-driven scaling: KEDA
Note: KEDA is not a rightsizing tool, it is an event-driven autoscaler that changes pod count, not pod resource requests. It sits adjacent to Layer 1 rather than inside it. KEDA scales pod replicas in response to external event signals (queue depth, lag, custom metrics). It triggers Karpenter indirectly by changing pod count. However, it does not adjust resource requests.
Layer 2: cost visibility and allocation
Karpenter exposes per-instance pricing estimates via Grafana dashboard ID 25116. That shows estimated node costs at the instance level. It does not show which namespace, team, or workload is responsible for those costs. For Kubernetes cost allocation that maps to your organizational structure, you need a dedicated Layer 2 tool.
According to the CNCF 2023 FinOps for Kubernetes report, 63% of organizations struggle to accurately allocate Kubernetes costs to teams, a gap that Layer 2 tools address directly.
Open-source options
OpenCost is a CNCF project that provides real-time cost monitoring by namespace, workload, and team. It requires an existing Prometheus setup. OpenCost works well for one or two clusters with Prometheus already in place. However, it offers no automated optimization. It surfaces cost data only, without recommendations or reduction actions.
Commercial options
Kubecost (now IBM) packages cost allocation into a product with multi-cluster reporting, budget alerts, governance features, and enterprise support. It is the right choice for teams managing many clusters where OpenCost’s per-cluster manual setup would create operational overhead. The IBM acquisition in 2024 introduces some roadmap uncertainty worth factoring into long-term procurement decisions.
AWS Split Cost Allocation Data (SCAD) is worth noting for AWS-only environments. It surfaces Kubernetes cost dimensions (cluster, namespace, node, workload) directly in AWS Cost Explorer and accepts up to 50 custom pod labels as cost allocation tags. SCAD answers finance team questions about Kubernetes spend. OpenCost or Kubecost answer engineering team questions about workload efficiency. They are complementary, not competing.
Cast AI cost reports differ from standalone cost tools in one key way: the cost data connects directly to the optimization actions that reduce those costs. Rather than reporting what you spent in isolation, it surfaces container-level cost attribution for any namespace, team label, or application — showing what changed, why it changed, and the delta versus the pre-optimization baseline.
Layer 3: multi-cluster and fleet policy
Karpenter operates within a single cluster. It has no awareness of other clusters in your fleet. Each Karpenter deployment manages its own NodePools, makes its own provisioning decisions, and shares no state with other Karpenter instances. For fleet-scale operations, Layer 3 tooling fills that gap.
GitOps delivery of Karpenter configs
Argo CD is the most common tool in this category for Karpenter environments. Teams use it to manage Karpenter NodePool configurations as declarative Git-tracked manifests and deliver them consistently across clusters. Argo CD does not provision nodes. Instead, it ensures the configuration that Karpenter reads is version-controlled and drift-free across every cluster in the fleet. Its 18k+ GitHub stars reflect wide adoption across Kubernetes platforms.
In practice, this means versioning both NodePool objects and provider-specific node class objects (EC2NodeClass on AWS, AzureNodeClass on AKS) in your GitOps repository. Both define how nodes are configured, NodePools set workload constraints; node classes set the cloud-level networking, AMI, and storage settings.
Rancher Fleet is the better fit for large fleets of hundreds of clusters or edge scenarios where SUSE/Rancher tooling is already in place. It solves the same config-drift problem at significantly higher scale.
Cross-cluster workload management
Karmada adds intelligent workload distribution across clusters, cross-cluster failover, and a federated API for querying resources across a fleet. It is the right choice when workloads need to move between clusters, not just configurations. However, the operational cost is higher: Karmada requires its own control plane.
Cluster API (CAPI) operates at a different abstraction level. It manages cluster lifecycle itself rather than workloads within clusters. A Karpenter provider for CAPI exists for non-AWS environments, enabling declarative cluster provisioning with Karpenter as the internal node autoscaler.
For teams on the path from Cluster Autoscaler to Karpenter, fleet policy is frequently an afterthought. In practice, it is the layer that determines whether optimization policies stay consistent as the cluster fleet grows past two or three clusters.
Cast AI multi-cluster policy addresses the operational gap directly: one configuration view, one cost report, and unified rightsizing and Spot policies propagated across all Karpenter-managed clusters. It removes the per-cluster configuration drift that open-source fleet tools leave as a manual problem.
Layer 4: commitment and Spot coordination
This is the most underutilized layer. Teams configure Karpenter for Spot and move on. However, Karpenter does not purchase commitments, does not factor existing Reserved Instances into selection, and does not analyze historical usage to forecast optimal Savings Plan coverage.
Karpenter uses the Price Capacity Optimized strategy for Spot selection. Price Capacity Optimized is an AWS EC2 Spot allocation strategy that Karpenter uses via EC2NodeClass when selecting Spot instances — it picks the Spot pools with the most available capacity relative to price, reducing interruption frequency. This improves interruption resilience compared to Cluster Autoscaler. However, it does not replace commitment management. On-demand discounts from Savings Plans and Reserved Instances operate at a separate level: they apply regardless of which specific instances Karpenter selects.
Why this layer matters
Effective savings rates vary significantly — teams that address only node provisioning typically see 10 to 20 percent savings; teams that also address rightsizing and commitment coordination have seen 40 to 50 percent (internal Cast AI analysis, 2026 customer cohort). The gap reflects how much of the bill is node cost versus request accuracy. It comes from Layer 4 tooling operating below Karpenter’s dynamic selection, not from Karpenter configuration alone.
Compute Savings Plans are the best fit for Karpenter environments. They commit to spend rather than to specific instance types, so they remain valid regardless of which instances Karpenter dynamically selects. In contrast, EC2 Reserved Instances lock to specific families and create stranded capacity risk in environments where Karpenter changes the instance mix frequently.
Tools in this layer
nOps Compute Copilot is an AWS APN Partner that integrates directly with Karpenter NodePools. It extends Karpenter with awareness of RI and Savings Plan inventory and real-time EC2 Spot termination risk. It influences instance selection to maximize commitment utilization alongside Karpenter’s dynamic provisioning.
Usage.ai handles the commitment purchasing layer specifically for EKS environments. It sits beneath Karpenter’s dynamic node selection and manages Compute Savings Plan and RI purchasing against actual usage patterns rather than manual forecasts.
Cast AI Savings Plans Automation bridges Karpenter’s dynamic instance selection and commitment purchasing. It analyzes actual Karpenter-managed cluster compute patterns, automates Savings Plan sizing, and purchases commitments aligned to real usage. Furthermore, it makes node selection commitment-aware, so Karpenter maximizes existing commitment utilization before selecting additional On-Demand capacity. The Karpenter free vs enterprise comparison covers how this layer adds up over time.
The commercial tools above (nOps, Usage.ai, Cast AI Savings Plans Automation) are AWS-specific. For GKE clusters, Google Cloud Recommender provides commitment recommendations via the Cloud Billing console. For AKS, Azure Advisor generates reservation recommendations. Neither offers the automation layer that commercial tools provide for AWS.
Layer 5: observability of provisioning decisions
Karpenter ships with Prometheus metrics on its controller endpoint by default. The key metrics cover node provisioning and deprovisioning events, pod scheduling latency, consolidation attempts, and (on AWS) interruption queue depth via karpenter_interruption_received_messages_total (AWS SQS-specific), confirms Karpenter is receiving Spot interruption notices. These metrics tell you what happened. Additional tooling tells you why it happened and what it cost.
Open-source dashboard stack
The kubernetes-autoscaling-mixin project (github.com/adinhodovic/kubernetes-autoscaling-mixin) is the go-to open-source solution. It provides three production-ready Grafana dashboards for Karpenter:
- ID 22171 – Overview: cluster-level provisioning summary and node count trends
- ID 22172 – Activity: node lifecycle events and disruption history
- ID 25116 – Costs: estimated node pricing from Karpenter’s cloud provider metrics
The mixin also ships five production Prometheus alert rules covering provisioning latency thresholds and interruption queue depth. For teams already running Prometheus and Grafana, this represents the fastest path to Karpenter observability. Beyond node selection, Grafana dashboard ID 18862 is a simpler single-dashboard alternative for teams that want something importable in minutes.
Commercial options
Datadog adds enterprise-grade metrics collection, log ingestion, and APM correlation. It is the right choice for teams already on Datadog who want Karpenter events correlated with application performance metrics and anomaly detection across the full observability stack. The cost is significantly higher than the Prometheus/Grafana approach.
Cast AI Console addresses the gap that no open-source tool covers well: the provisioning decision audit log. It shows why Karpenter selected each instance type in human-readable form, provides the reporting layer that connects Karpenter’s node-level decisions to team-level cost accountability, and surfaces realized savings versus the pre-optimization baseline.
The ecosystem map
The table below maps 23 tools to their layers. Use it to identify gaps in your current stack and to check whether tools you are evaluating actually compete.
| Tool | Layer | Open source or commercial | What it adds |
|---|---|---|---|
| Karpenter (core) | Foundation | Open source (CNCF/AWS) | Just-in-time node provisioning, consolidation, Spot/On-Demand selection |
| VPA | Layer 1 – Rightsizing | Open source | Pod resource recommendations and auto-adjustment (with restart) |
| Goldilocks | Layer 1 – Rightsizing | Open source (Fairwinds) | Visual VPA recommendation dashboard, no enforcement |
| KEDA | Adjacent to Layer 1 – Workload scaling (event-driven) | Open source (CNCF) | Event-driven horizontal scaling; triggers Karpenter indirectly via pod count changes |
| StormForge (CloudBolt Software) | Layer 1 – Rightsizing | Commercial | ML-based rightsizing, HPA+VPA harmonization, fleet-wide automation |
| Cast AI PrecisionPack | Layer 1 – Rightsizing | Commercial | Zero-downtime automated rightsizing, live migration for stateful workloads, integrated with Karpenter bin-packing |
| OpenCost | Layer 2 – Cost visibility | Open source (CNCF) | Real-time cost allocation by namespace, workload, team; requires Prometheus |
| Kubecost | Layer 2 – Cost visibility | Commercial (IBM) | Multi-cluster cost reporting, budget alerts, governance, enterprise support |
| AWS SCAD | Layer 2 – Cost visibility | AWS native (free) | Pod-level cost in AWS billing; up to 50 custom label dimensions in Cost Explorer |
| Cast AI Cost Reports | Layer 2 – Cost visibility | Commercial | Real-time cost by cluster/namespace/workload, tied directly to optimization actions |
| Argo CD | Layer 3 – Fleet policy | Open source (CNCF) | GitOps delivery of Karpenter NodePool configs across clusters; drift prevention |
| Rancher Fleet | Layer 3 – Fleet policy | Open source (SUSE) | GitOps for large fleets (100s of clusters), edge scenarios |
| Cluster API (CAPI) | Layer 3 – Cluster provisioning | Open source (CNCF) | Declarative cluster lifecycle management; Karpenter provider for non-AWS |
| Karmada | Layer 3 – Fleet policy | Open source (CNCF) | Cross-cluster workload distribution, failover, federated API |
| Cast AI Multi-Cluster Policy | Layer 3 – Fleet policy | Commercial | Unified optimization policy and cost reporting across all Karpenter clusters |
| AWS Savings Plans | Layer 4 – Commitment | AWS native | Compute discount via spend commitment; flexible across instance types Karpenter selects |
| nOps Compute Copilot | Layer 4 – Commitment | Commercial | (AWS/EKS only) Karpenter-aware RI/Savings Plan management, real-time Spot termination risk integration |
| Usage.ai | Layer 4 – Commitment | Commercial | (AWS/EKS only) Commitment purchasing automation (Savings Plans, RIs) for EKS environments |
| Cast AI Savings Plans Automation | Layer 4 – Commitment | Commercial | Automated commitment sizing and purchasing; commitment-aware node selection |
| Prometheus + Karpenter metrics | Layer 5 – Observability | Open source | Metric scraping from Karpenter controller; foundation for all dashboards and alerts |
| kubernetes-autoscaling-mixin | Layer 5 – Observability | Open source | Production Grafana dashboards (22171, 22172, 25116) and Prometheus alert rules for Karpenter |
| Datadog | Layer 5 – Observability | Commercial | Enterprise metrics, log ingestion, APM correlation with Karpenter events |
| Cast AI Console | Layer 5 – Observability | Commercial | Provisioning decision audit log with human-readable reasoning and cost impact dashboard |
How to assemble a stack
Start with the layer that costs you the most. For most teams, that is Layer 1. Karpenter is already provisioning nodes. The problem is that those nodes are sized to overprovisioned requests. Fix Layer 1 first, then measure the savings before adding complexity at other layers.
A practical build order looks like this:
- Layer 1 first: Deploy Goldilocks to get VPA recommendations visible in a dashboard. Review them for one sprint. After one sprint (two weeks), look for workloads where VPA recommends CPU more than 40% below the current request — a threshold Cast AI SEs use as a rule of thumb based on customer data; it is not a VPA standard or industry benchmark. Those are your high-confidence automation candidates. Start there before enabling VPA Auto mode cluster-wide. Then decide whether to automate with VPA Auto mode, StormForge, or Cast AI PrecisionPack depending on your risk tolerance for automated pod adjustments.
- Layer 2 second: Add OpenCost if you already have Prometheus and run one or two clusters. Add Kubecost Business if you run multiple clusters or need budget alerts and multi-team governance.
- Layer 5 third: The kubernetes-autoscaling-mixin gives you dashboards 22171, 22172, and 25116 in an afternoon. (Prerequisite: an existing Prometheus stack is required. If you don’t have one, deploy the kube-prometheus-stack Helm chart first — it takes about 10 minutes and provides both Prometheus and Grafana.) These should run alongside any production Karpenter deployment from day one.
- Layer 3 when you hit two clusters: Introduce Argo CD or Rancher Fleet at the first sign of NodePool config drift. Do not wait until you manage ten clusters with diverging configurations.
- Layer 4 when Spot is stable: Once Karpenter’s Spot selection is tuned and interruption rates are acceptable, introduce Compute Savings Plans. Automate commitment purchasing with nOps, Usage.ai, or Cast AI rather than forecasting manually from usage history.
Additionally, if you want a single platform that covers all five layers in one install, Cast AI for Karpenter does exactly that. It extends Karpenter through a CRD-first approach, does not replace it, and adds all five layers through lightweight agents. The Karpenter optimization page shows what the full stack looks like in production.
Conclusion
A Karpenter cluster without rightsizing, cost allocation, and observability is like a fast network router handling packets efficiently, but with no QoS policy, no traffic monitoring, and no billing breakdown. The routing is excellent. The picture of what it costs and why is missing. The five layers fill that gap.
The five-layer framework makes evaluation fast. First, determine which layer a tool addresses. Then assess whether your current stack has a gap at that layer. Two tools in the same layer may compete with each other. Two tools in different layers almost certainly complement each other instead.
For most teams, Layer 1 (rightsizing) delivers the fastest return because it directly corrects the input Karpenter uses to size nodes. Start there, build outward, and add layers as the cluster fleet grows in size and complexity.
Frequently Asked Questions
Karpenter works alongside tools in five distinct layers. For workload rightsizing: VPA, Goldilocks, StormForge, and Cast AI PrecisionPack all work alongside it and correct the pod requests that Karpenter uses to size nodes. For cost visibility: OpenCost, Kubecost, and AWS SCAD provide the allocation breakdown that Karpenter does not. Cost visibility comes from OpenCost, Kubecost, and AWS SCAD, which provide the allocation breakdown that Karpenter does not. For fleet policy, Argo CD, Rancher Fleet, and Karmada distribute Karpenter configurations and workloads across clusters.
Commitment management relies on nOps Compute Copilot, Usage.ai, and Cast AI Savings Plans Automation to automate the purchasing layer that Karpenter ignores. For observability: Prometheus with the kubernetes-autoscaling-mixin dashboards, Datadog, and Cast AI Console add audit logs and alerting. None of these tools replace Karpenter. They extend it at the layers where its scope formally ends.
No. Karpenter has no dependency on any cost tool. They are complementary, not bundled. Kubecost (and its open-source alternative, OpenCost) sits in Layer 2 and provides the cost allocation visibility that Karpenter does not offer. Karpenter exposes per-instance estimated pricing in its Prometheus metrics, but it does not attribute those costs to namespaces, teams, or individual workloads. If you need chargeback, budget alerts, or multi-cluster cost governance, you need a Layer 2 tool running alongside Karpenter. You do not need Kubecost specifically: OpenCost is a free CNCF alternative for smaller deployments.
Yes, and you should. Karpenter’s provisioning decisions are only as accurate as the pod resource requests it receives. According to the Cast AI 2026 State of Kubernetes Optimization Report, 69% of clusters overprovision CPU. Over-requested pods cause Karpenter to launch larger nodes than workloads actually need. VPA, Goldilocks, StormForge, and Cast AI PrecisionPack all work alongside Karpenter without conflict. They correct the requests before provisioning runs, so Karpenter makes better bin-packing and node-sizing decisions. Rightsizing and Karpenter are fully complementary and produce compounding savings when used together in the same provisioning pipeline.
Karpenter exposes Prometheus metrics from its controller endpoint by default. The fastest open-source setup uses the kubernetes-autoscaling-mixin project (github.com/adinhodovic/kubernetes-autoscaling-mixin), which ships three production-ready Grafana dashboards (IDs 22171, 22172, 25116) and five Prometheus alert rules for Karpenter. For teams already running Prometheus and Grafana, this adds meaningful Karpenter observability in an afternoon. For enterprise environments, Datadog provides integrated metrics, log ingestion, and APM correlation. Cast AI Console adds a human-readable provisioning audit log that explains why each instance type was selected and shows the cost impact per event, without requiring a separate Prometheus or Grafana setup.
Karpenter itself is single-cluster scoped. Each Karpenter deployment manages nodes within one cluster and has no cross-cluster awareness or shared state. To apply consistent NodePool policies across multiple clusters, teams use Argo CD or Rancher Fleet to deliver Karpenter configurations from a central Git repository. For cross-cluster workload federation and automated failover, Karmada adds that capability at the cost of additional operational complexity. Cast AI multi-cluster policy provides centralized optimization management, unified cost reporting, and consistent rightsizing and Spot policies across all Karpenter-managed clusters from a single management interface.
Five things are formally outside Karpenter’s scope. First, workload rightsizing: pod CPU and memory requests are untouched by Karpenter. Second, cost allocation: there is no namespace-level or team-level billing breakdown. Third, multi-cluster policy: Karpenter manages one cluster and has no fleet view or cross-cluster governance. Fourth, commitment management: Karpenter does not factor Reserved Instances or Savings Plans into selection and does not purchase or size commitments. Fifth, decision auditability: Karpenter surfaces what provisioning events occurred but does not explain in human-readable form why each instance type was chosen. Each of these gaps maps to a specific layer in the ecosystem, and tools exist to address every one of them.
