September 2026 Summaries

SkyPilot and Cast AI address GPU capacity and cost challenges through different operating models: SkyPilot is an Apache 2.0 open-source, job-oriented framework that provisions workloads across more than 20 clouds, including neocloud providers, selects available lower-cost GPUs, and supports automated regional failover, distributed training, checkpoint-based recovery, batch processing, and, since its 2026 SkyServe release, production inference endpoints. Cast AI is a fully managed Kubernetes platform focused on long-running services in EKS, GKE, and AKS, using its OMNI Compute capability to source GPU capacity across AWS, GCP, and OCI while continuously optimizing node sizing, Spot usage, bin-packing, GPU sharing, and cost attribution without requiring application changes. SkyPilot is positioned as a stronger fit for discrete training runs, hyperparameter sweeps, batch jobs, and teams seeking access to providers such as CoreWeave or RunPod without Kubernetes overhead, whereas Cast AI is better suited to sustained Kubernetes inference services requiring ongoing resource management, automated GPU partitioning or time-slicing, and operational cost controls. The platforms can also be complementary, with SkyPilot managing model training and Cast AI optimizing Kubernetes-based deployment and serving infrastructure.

Kubernetes configuration drift arises when a cluster’s live state diverges from the desired configuration defined in Git, Helm charts, or manifests, often through manual incident-response edits, untracked Helm overrides, inconsistent multi-cluster changes, operator fatigue, or gaps in GitOps reconciliation. Beyond reliability, security, and debugging challenges, drift can increase costs when inflated resource requests, replica counts, node labels, or taints persist and reduce scheduling efficiency, causing autoscalers to maintain excess capacity. Detection options range from manual comparisons with kubectl diff to continuous reconciliation through ArgoCD or Flux, admission and audit policies using OPA/Gatekeeper or Kyverno, and commercial monitoring platforms that provide broader change attribution. Because live changes may be legitimate, remediation should be cautious, using incremental resource reductions, monitoring, or blue/green rollbacks rather than indiscriminate reversions. Combining GitOps self-healing, policy enforcement, governance for non-GitOps resources, and continuous workload rightsizing can reduce both drift and the operational incentives that create it.

Kueue is a Kubernetes-native admission controller that queues GPU batch workloads until sufficient quota and capacity are available, aiming to prevent indefinitely pending pods, improve visibility, enforce multi-team fairness, and support coordinated admission for distributed jobs. It uses ResourceFlavors to represent hardware pools, ClusterQueues to define guaranteed quotas and borrowing or lending limits, LocalQueues as namespace-level submission points, and Workloads as the units evaluated for admission; cohorts and preemption policies allow unused GPU capacity to be shared while preserving each team’s allocation. Dynamic Resource Allocation, generally available in Kubernetes 1.34, replaces simple GPU-count requests with attribute-based ResourceClaims that can specify requirements such as memory, architecture, compute capability, or MIG partition profiles, allowing more precise device matching and potentially reducing wasted capacity. The text recommends MIG for isolated single-GPU workloads, full GPUs for NVLink-dependent distributed training, and MPS for some shared inference scenarios, while noting that Kueue and DRA require integration and may need retry mechanisms when device availability changes after admission. It contrasts Kueue’s Kubernetes-native approach with Volcano’s separate scheduler and stronger pod-placement gang semantics, and cites Cast AI fleet data and customer-oriented estimates suggesting low average GPU utilization and potential savings from combining queuing, device partitioning, and attribute-aware autoscaling.

Kubernetes autoscaling can function as designed while clusters remain inefficient because controllers base decisions on declared resource requests, scheduling rules, and policies rather than actual application consumption. Cast AI’s 2026 report, covering an analyzed 2025 sample rather than all clusters, found average CPU and memory utilization of 8% and 20%, alongside reported CPU and memory overprovisioning of 69% and 79%, indicating frequent gaps between reserved and observed capacity but not directly equivalent bill savings. Oversized pod requests can cause extra nodes to be provisioned, while consolidation may be blocked by Pod Disruption Budgets, affinity and topology constraints, storage requirements, resource fragmentation, minimum node settings, controller policies, or long termination periods. Effective diagnosis requires tracing four layers—application consumption, resource requests, resource limits, and provisioned node capacity—and distinguishing overprovisioning from CPU throttling, since low average usage can conceal legitimate burst demand. Request changes must also be coordinated with Horizontal Pod Autoscaler settings because utilization-based HPA calculations divide consumption by requests, meaning reduced requests can trigger replica scale-outs. A cautious optimization process establishes baseline performance and cost-per-unit-of-work metrics, compares requests with usage, investigates scale-up and consolidation events, pilots coordinated workload and node changes, and verifies application reliability, capacity reductions, and billing effects, including the influence of committed cloud-spend arrangements.

Kubecost is presented as a Kubernetes cost-visibility platform that allocates spending across namespaces, labels, teams, and workloads, while Cast AI is positioned as an automation platform that can act on rightsizing and infrastructure optimization opportunities. The proposed migration preserves Kubernetes label taxonomies, cost-center structures, and allocation models because they reside in cluster manifests and workflows rather than Kubecost itself, but it requires rebuilding dashboards, alerts, scheduled reports, and Allocation Groups in Cast AI. Historical Kubecost data cannot be imported automatically, so the guidance recommends exporting at least 90 days of allocation data and retaining Prometheus snapshots where applicable. A phased transition of roughly 6–14 weeks is advised, including 2–4 weeks for setup and 30–90 days of parallel operation to compare allocation results, address label gaps, and obtain finance or FinOps approval before decommissioning Kubecost. Cast AI should initially run in read-only mode, with rightsizing automation introduced gradually in non-production environments and governed by resource bounds, disruption budgets, workload exclusions, and consideration of Reserved Instances or Savings Plans. The central argument is that the change shifts teams from manual cost reporting and remediation workflows toward continuous, automated resource optimization while retaining cost allocation and reporting capabilities.

Kubernetes toil consists of manual, repetitive operational tasks that grow with cluster scale without creating lasting system improvements, and the text identifies resource request tuning, node lifecycle management, instance and capacity selection, cost reporting, and incident triage as its main sources. It ranks resource rightsizing as the highest-priority automation target because CPU and memory are frequently overprovisioned, the work is mechanical, and its operational risk is comparatively low; node upgrades rank next, followed by capacity and instance optimization, cost allocation, and incident triage, which has the greatest risk because incorrect remediation can worsen outages. The recommended approach evaluates each category by engineer-hours saved, implementation effort, and blast radius, begins with recommendation or approval-gated workflows, and expands toward autonomous operation only after validating reliable outcomes. It stresses safeguards such as PodDisruptionBudgets for node draining, careful coordination between Vertical and Horizontal Pod Autoscalers, selective use of Spot capacity, and retaining human judgment for novel incidents, architecture choices, and security exceptions. Success should be measured through changes in monthly toil hours, request-to-usage ratios, upgrade completion times, costs, and OOM or throttling rates, with the broader goal of freeing engineering teams for work that improves systems rather than merely maintaining them.

AI SRE is presented as a distinct post-alert operational discipline in which autonomous agents investigate incidents by correlating telemetry, diagnosing likely root causes, and, within tightly defined limits, recommending or executing remediation. Unlike observability, which supplies data, and AIOps, which primarily reduces event noise before alerts reach responders, AI SRE focuses on the manual investigative work traditionally performed by on-call engineers. Current autonomous capabilities remain narrow: IBM Research’s ITBench benchmark reportedly found that leading agents resolved 13.8% of tested SRE scenarios without human intervention, making advisory workflows, guardrails, confidence thresholds, circuit breakers, and kill switches important for production use. Effective systems depend on current infrastructure topology, comprehensive logs, metrics and traces, and RAG-based access to organization-specific runbooks and postmortems, while weak context can produce unreliable generic recommendations. Cost automation is characterized as a related but separate field that continuously optimizes capacity, rightsizing, and infrastructure spending rather than responding to incidents, although both domains rely on similar topology data, permissions, trust models, and staged autonomy. The discussion recommends beginning with low-blast-radius actions, auditing RBAC and data-egress risks, testing vendors through dry runs and phased pilots, and retaining human oversight for novel, complex, or high-impact failures.

Automated, autonomous, and agentic Kubernetes operations represent distinct levels of decision ownership: automated systems execute human-written rules, autonomous systems continuously optimize against human-defined objectives and guardrails, and agentic systems plan multi-step actions across tools to achieve scoped goals. The framework describes four levels, from fully manual operations through rule-based automation such as HPA and Cluster Autoscaler, objective-driven functions such as rightsizing and adaptive node provisioning, and bounded agentic remediation for known incident types. It argues that much tooling marketed as autonomous remains Level 1 automation, which can preserve outdated or flawed configuration, particularly when autoscalers respond to inflated resource requests rather than actual usage; it cites Cast AI’s 2026 fleet dataset reporting 69% average CPU overprovisioning and 8% average utilization. Higher autonomy shifts rather than removes human responsibility, requiring teams to define objectives, guardrails, rollback processes, and decision audit evidence. The text recommends evaluating vendors by asking who defines rules, how systems adapt to changing conditions, how exceptions and rollback are handled, what decision evidence is available, and which actions still require human approval, while positioning Cast AI primarily as Level 2 infrastructure automation with limited Level 3 capabilities for predefined incident classes.

Cast AI presents its Kubernetes optimization platform as policy-driven automation designed to reduce overprovisioning while preserving operator control through configurable workload scope, instance constraints, disruption limits, and resource headroom. It says its Workload Autoscaler evaluates utilization alongside application-health signals such as error rates, p99 latency, OOMKills, Pressure Stall Information, HPA state, and Spot-market forecasts, using bidirectional rightsizing to lower excess requests or add capacity to constrained workloads. Key safeguards include node-template limits, minimum and maximum node counts, PodDisruptionBudget-aware draining with reversion on failure, savings-threshold checks before rebalancing, workload exclusions or opt-in whitelisting, emergency automation pauses, and incremental onboarding through recommend-only mode. The platform records actions in exportable audit logs and supports Prometheus, Grafana, cost attribution, Slack, and PagerDuty integrations for monitoring and accountability. Cast AI contrasts its governance, HPA coordination, cost-aware rebalancing, and interruption prediction features with Karpenter and native Vertical Pod Autoscaler, while acknowledging that infrastructure automation carries risk and emphasizing reversible controls, previews, and human approval for changes outside established policies.

Kubernetes capacity planning should distinguish actual resource use, pod requests, and provisioned node capacity because autoscalers respond primarily to requests rather than real consumption, allowing inflated requests to drive unnecessary node growth and low utilization. Citing Cast AI’s 2026 report, the guidance says requested CPU averages 69% above actual usage and recommends rightsizing workloads before calculating capacity, then maintaining roughly 15–30% headroom above peak corrected demand, adjusted for autoscaler response times and traffic-spike patterns. It differentiates short-term spike planning from longer-term growth and commitment planning, advises reserving 60–70% of a stable rightsized baseline through flexible spend-based cloud commitments while using Spot capacity for variable demand, and calls for separate treatment of stateful workloads because availability-zone-bound storage restricts pod mobility and requires dedicated pools and greater headroom. Non-production environments should be independently rightsized and scheduled down during idle periods, while plans should be checked regularly and revisited after major deployments, persistent autoscaler limits, rising OOM events, or changes in workload types. The text also presents automation, including Cast AI’s rightsizing, consolidation, and commitment-management tools, as a way to continuously reduce request inflation and improve utilization.

Kubernetes optimization platforms are offered as SaaS, self-hosted, or air-gapped deployments, with progressively stronger data containment accompanied by reduced vendor-managed capabilities and greater operational responsibility. SaaS places the control plane in the vendor’s cloud, sending cluster metadata such as workload identifiers, resource settings, and node information outward in exchange for automated upgrades, low operational burden, and potentially cross-customer intelligence; it is generally suitable for commercial environments that permit egress and accept applicable vendor security and data-processing terms. Self-hosted deployments keep operational telemetry within a customer VPC or data center but commonly still need limited outbound access for licensing or updates, while requiring customers to manage infrastructure, scaling, certificates, availability, and upgrades. Air-gapped deployments allow no external connectivity and are often necessary for classified, ITAR-controlled, or zero-egress environments, but require manual software transfer, lack real-time external intelligence and updates, and may provide fewer features. Regulatory requirements including FedRAMP, GDPR transfer restrictions, ITAR, DoD IL5/IL6, PCI-DSS, HIPAA, and DORA can determine the permissible architecture, so organizations should establish compliance constraints before comparing product features. The discussion recommends requesting detailed vendor data dictionaries, network endpoint requirements, retention policies, role permissions, feature-parity evidence, and release-cadence information, while accounting for total cost of ownership and recognizing that open-source options can support isolated environments but typically offer visibility and recommendations rather than autonomous optimization.

Kubernetes showback provides teams with visibility into their costs while chargeback transfers those costs to team or department budgets, but both depend on resolving the difficulty of allocating shared cluster expenses such as control planes, system services, network transfer, and idle capacity. The recommended approach is to establish accurate labels and direct workload allocation, run showback for at least 90 days, reduce unallocated spend below 5%, and secure executive agreement on allocation policies before introducing chargeback, since disputed first invoices can undermine trust. Requests-based allocation reflects reserved capacity but can overcharge teams in overprovisioned clusters, while usage-based billing may encourage under-requesting; a maximum-of-request-or-usage model and automated right-sizing can balance these incentives. The source argues that platform teams should generally own idle capacity because they control provisioning and autoscaling decisions, while a hybrid model can charge teams for direct workloads and report shared overhead centrally. Reliable reporting requires weekly operational visibility, monthly settlement, durable ownership labels, and enforcement tools such as Kyverno or OPA. AI inference costs require separate attribution because token-based model billing does not naturally align with Kubernetes namespaces, requiring metrics, gateways, API keys, or team metadata to connect spending to responsible teams.

FOCUS, the FinOps Open Cost and Usage Specification maintained by the FinOps Foundation, is an open standard that standardizes cloud billing exports across providers through common fields for costs, usage, timestamps, regions, resources, pricing, and commitments, reducing the need for provider-specific translation layers in multi-cloud analysis. The current version, FOCUS 1.4, was ratified on June 4, 2026 and adds invoice-reconciliation datasets and an “AI and Machine Learning” service category, while earlier releases introduced features such as split-cost allocation data and virtual-currency handling. AWS and Azure natively support FOCUS 1.2 exports, while GCP provides a stable 1.0 mapping view and a 1.2 preview export; several other cloud and SaaS vendors offer varying levels of support. For Kubernetes, FOCUS improves normalized node-level billing data and can support AWS EKS attribution when optional split-cost allocation is enabled, but it does not allocate shared node expenses to pods, namespaces, teams, or workloads, identify idle capacity, or connect Kubernetes infrastructure costs with external AI API token spending. These functions require Kubernetes-aware allocation tools and application-level instrumentation, while native token and unit-economics capabilities are planned for FOCUS 1.5.

Karpenter is presented as a strong AWS-focused Kubernetes node provisioning tool that improves on Cluster Autoscaler through fast per-pod bin-packing, real-time EC2 capacity selection, Spot diversification, and continuous consolidation of underutilized nodes. Its stated enterprise-scale limitations are largely scope boundaries: it provisions from declared pod resource requests rather than actual utilization, operates primarily on AWS, manages only one cluster per installation, lacks Reserved Instance and Savings Plan awareness, does not provide cost allocation reporting, and can create configuration and upgrade overhead across large fleets. Citing a Cast AI report, the text argues that CPU requests average 69% above usage, meaning clusters can remain inefficient despite effective node consolidation because Karpenter cannot correct oversized workload requests. It recommends complementary tools such as Vertical Pod Autoscaler or automated rightsizing, fleet-management systems, commitment-aware optimization layers, and cost-allocation platforms for organizations that need multi-cloud coordination, centralized governance, FinOps reporting, or improved use of committed cloud capacity. Karpenter is characterized as sufficient for smaller AWS-primary environments with accurate resource requests and limited cluster counts, while larger organizations may need additional layers to address these operational and cost-management needs.

Karpenter is a Kubernetes node provisioner that launches capacity for pending pods and consolidates underused nodes, but it does not adjust workload resource requests, allocate costs, govern multiple clusters, manage cloud commitments, or provide human-readable explanations for provisioning decisions. The surrounding ecosystem can be organized into five complementary layers: workload rightsizing, cost visibility and allocation, multi-cluster fleet policy, Reserved Instance and Savings Plan coordination, and provisioning observability. Open-source options include VPA and Goldilocks for rightsizing, OpenCost for cost allocation, Argo CD and Rancher Fleet for configuration management, and Prometheus with Grafana dashboards for monitoring, while commercial products add automation, multi-cluster controls, commitment optimization, and audit features. The text argues that rightsizing is often the highest-priority addition because Karpenter bases node choices on pod CPU and memory requests, meaning inaccurate requests can lead to excess capacity, and recommends expanding to other layers as operational scale and requirements grow.

Karpenter is an open-source Kubernetes node provisioning tool for AWS/EKS that rapidly creates and consolidates nodes based on unschedulable pods and declared resource requests, but the passage argues that its zero license cost does not capture the operational and financial costs of managing it at scale. It identifies engineering effort for NodePool configuration, Spot interruption handling, upgrades, and configuration drift; unaddressed CPU overprovisioning because requests can substantially exceed real usage; and missing functions such as cost allocation, Reserved Instance or Savings Plan coordination, and cross-cluster governance. The proposed total-cost-of-ownership model suggests that open-source Karpenter is often appropriate for one to three clusters or lower cloud spending, while fleets beyond roughly 10 clusters may find commercial management layers economical if they reduce operational workload and recover savings through rightsizing, rebalancing, commitment management, and cost visibility. Cast AI is presented as one such overlay that operates alongside rather than replacing Karpenter, though several performance and savings figures cited are based on vendor data or a vendor-referenced benchmark.

Karpenter may provision and bin-pack Kubernetes nodes correctly without lowering overall costs when pod resource requests substantially exceed actual usage, because it schedules against declared requests rather than runtime consumption; the source cites average CPU requests 69% above use and a sample cluster with 44.87 CPU provisioned, 24.9 requested, and 3.94 used. It recommends first verifying that the Karpenter controller, NodePools, provisioning events, and NodeClaims are healthy, then prioritizing workload rightsizing through VPA recommendations or other tools before adjusting node settings. Other possible barriers include disabled or blocked consolidation, restrictive NodePool instance requirements or limits, Spot capacity that is unavailable or remains unused after on-demand fallback, strict PodDisruptionBudgets, do-not-disrupt annotations, long termination periods, and DaemonSet resource overhead that creates a minimum node-size cost. Flat total bills can also reflect non-compute charges such as storage, egress, load balancers, and control-plane fees, or accounting effects from Reserved Instances and Savings Plans. Because consolidation occurs gradually and billing data can lag, the source advises monitoring consolidation events and node counts over at least 30 days while evaluating compute costs separately from total spending.

Non-production Kubernetes clusters often incur excessive costs because they run continuously with production-sized resource requests despite low utilization and limited working-hour use. The recommended cost-reduction sequence is to schedule scale-down or cluster hibernation during idle periods, rightsize CPU and memory requests based on actual development usage, use Spot or preemptible nodes for interruption-tolerant stateless workloads, and simplify production-style high-availability designs such as multi-AZ deployments and high replica counts. Scheduling alone can remove roughly 70% of compute time for a typical 50-hour workweek, although managed control-plane charges may remain, while rightsizing addresses inherited overprovisioning and Spot instances can substantially lower compute prices. Implementations must account for stateful-service startup and data seeding, GitOps and autoscaler conflicts, PodDisruptionBudgets, and shared staging environments that may need greater resilience. The discussion also emphasizes automated TTL-based deletion of preview and feature-branch environments, namespace-level cost allocation and quotas, and preserving production-like topology for performance, security, or load-testing environments where configuration fidelity is essential.

Token cost attribution for AI workloads on Kubernetes requires connecting two separate billing systems: cloud GPU node-hour charges and model API token charges, which lack a shared identifier by default. The proposed approach is to propagate consistent team, cost-center, environment, and model labels from Kubernetes workloads into inference requests, enforce them during admission, expose them through the Downward API, and use gateways such as LiteLLM or provider metadata and per-team API keys to record spend by team. Self-hosted inference requires combining GPU node costs with vLLM token and utilization metrics, while external APIs rely on request-level metadata, project keys, or workspace IDs; shared keys and shared infrastructure make attribution less reliable without disciplined instrumentation. FOCUS 1.4 standardizes billing-record formats but does not yet define the Kubernetes-to-token linkage, leaving organizations to build custom joins until anticipated future standards expand coverage. The discussion recommends beginning with showback reports and near-real-time budget caps before formal chargeback, then using attribution data to target optimization opportunities such as GPU sharing, rightsizing, MIG partitioning, spot capacity, and cross-cloud scheduling, particularly given reported low average GPU utilization.

Kubernetes autoscaling is divided between workload tools that adjust pod replicas or resource requests, including HPA, VPA, and KEDA, and node tools that add or remove infrastructure, such as Cluster Autoscaler and Karpenter; most clusters require both categories. Cluster Autoscaler works across major clouds but relies on predefined node groups and typically scales nodes in three to four minutes, whereas Karpenter selects fitting instance types per pending pod, provisions them in roughly 45–90 seconds, and can consolidate workloads, though its strongest support is on AWS and newer Azure offerings. HPA scales replicas from resource or custom metrics, VPA derives request recommendations from historical use but can conflict with CPU-based HPA, and KEDA extends scaling to external event signals and scale-to-zero use cases such as queues, batch processing, and GPU workloads. Managed services such as EKS Auto Mode and GKE Autopilot reduce operational overhead but limit host-level control and may add cost or use request-based billing. The discussion emphasizes that autoscaling alone often does not minimize Kubernetes spending because node provisioning follows declared resource requests rather than actual consumption; reported CPU requests average 69% above real usage, making rightsizing an important complement to scaling and consolidation.

Kubernetes troubleshooting is presented as a signal-driven process in which pod statuses, exit codes, logs, and events identify distinct failure categories and their appropriate first diagnostic commands. OOMKilled with exit code 137 requires confirmation through the pod’s termination reason and is commonly tied to inadequate memory limits, leaks, or node pressure, while CrashLoopBackOff indicates repeated restarts and should be investigated using logs from the previous container instance. ImagePullBackOff is diagnosed through pod event messages that distinguish invalid image references, authentication failures, and network problems, whereas Node NotReady calls for reviewing node conditions and kubelet logs before cordoning or draining the node. The guide emphasizes that exit codes such as 1, 127, 137, 139, and 143 narrow likely causes, with 143 often reflecting normal graceful termination during updates, scaling, or node maintenance. It argues that inaccurate CPU and memory requests and limits are a common underlying contributor to instability and inefficiency, recommending sizing based on observed p95 working-set data, potentially using VPA recommendations, monitoring, or automated rightsizing tools.

Automated Kubernetes rightsizing can reduce resource waste and OOMKills when it adjusts resources bidirectionally, lowering allocations for consistently overprovisioned workloads while raising memory requests and limits for workloads nearing their thresholds. Citing a representative cluster in Cast AI’s 2026 report, the discussion says OOMKill events fell from roughly 40–50 per reporting interval, with spikes above 80, to near zero after automation was enabled, while provisioned CPU declined by about half, though it notes this was an observational before-and-after result rather than a controlled experiment. It distinguishes memory-related OOMKills from CPU throttling, which is governed by CPU limits and Linux CFS quotas rather than requests, and recommends separate strategies for each. Safe adoption depends on sufficient observation periods, peak-oriented memory sizing, headroom, recommend-only testing, gradual rollout, monitoring, rollback procedures, and exclusions for workloads such as stateful services, memory leaks, unusual batch spikes, CPU-based HPA workloads, and services already managed by VPA.

Cast AI presents its platform as combining node-level automation with workload-level rightsizing through PrecisionPack, countering the characterization that it only optimizes infrastructure nodes. PrecisionPack monitors container CPU and memory consumption, recommends and applies per-container resource requests and limits based on observed usage, and continuously revises them as workloads change, with support for several Kubernetes workload types and optional recommendation-only, deferred, restart-based, or in-place application modes. The text argues that rightsizing is important because Kubernetes scheduling and autoscaling depend on declared requests rather than actual utilization, so inflated requests can drive unnecessary node provisioning. It cites Cast AI’s 2026 report claiming 69% CPU and 79% memory overprovisioning, average CPU utilization of 8%, an approximately 50% reduction in provisioned CPU for organizations using automated rightsizing, and a reduction in OOM kills through bidirectional adjustments that can increase resources for underprovisioned containers. In-place CPU resizing is described as available on Kubernetes 1.33 or later, while memory changes generally require restarts, and the platform is compared with VPA and other workload optimization tools as an integrated option that combines automated rightsizing with node provisioning and purchasing decisions.

Cast AI is presented as a Kubernetes optimization and node-provisioning platform with low technical lock-in because it creates standard cloud VMs in a customer’s own account, does not alter application manifests, Helm charts, images, code, or CI/CD pipelines, and can be removed while clusters and existing nodes continue operating. Its primary dependency is characterized as moderate operational lock-in: teams that rely on its automated rightsizing, instance selection, bin-packing, and provisioning must restore those processes or adopt another autoscaler after leaving, a challenge compared with removing Karpenter, Cluster Autoscaler, or similar automation tools. The platform begins with a read-only metrics-collection phase and, when automation is enabled, deploys Kubernetes components, custom resources, IAM permissions, and mutating webhooks that adjust pod resource requests at admission time rather than editing stored configurations. It supports Helm-based GitOps workflows and Terraform-managed policies, although real-time instance placement remains dynamic rather than fully declarative. A documented exit process disables policies, disconnects the cluster, removes IAM and Kubernetes resources, and allows migration to Karpenter or Cluster Autoscaler, though the latter requires recreated node groups.