# Karpenter Enterprise Meets Azure – Karpenter, Your Way: Self-Hosted or NAP-enabled AKS > Source: > Published: 2026-10-29 12:04:34+00:00 Karpenter gives AKS teams flexible node provisioning and consolidation. Whether you operate Karpenter yourself or use Microsoft’s Node Auto-Provisioning (NAP), another operating loop remains: keeping workload requests aligned with real usage, deciding which changes to delegate, and checking how those changes affect applications. Cast AI’s Karpenter Enterprise Suite closes this loop: Karpenter keeps provisioning; Cast AI adds workload rightsizing, coordinated rebalancing, and cost visibility, with automation enabled at your team’s pace. ## What Karpenter and NAP already solve Self-managed Karpenter and AKS Node Auto-Provisioning both reduce the work of maintaining static node pools and pre-sizing VM capacity. They watch unschedulable pods, choose capacity that fits the workload’s requested CPU and memory, and remove or replace nodes when consolidation is possible under current scheduling constraints. NAP removes more of the platform maintenance burden. Microsoft runs the managed Karpenter control plane, patches it, and hides it from the cluster’s node-level workload footprint. Self-managed Karpenter gives teams more direct control over the upstream project, version timing, and configuration lifecycle, but also leaves them responsible for upgrades, identity setup, controller health, and support through the open-source path. In both cases, Karpenter is the right foundation for dynamic provisioning. The day-2 question is what happens around it: how to reconcile pod requests with real (under)utilization, whether rebalancing decisions consider current cost and risk signals, and whether the team can verify that optimization did not trade savings for application impact. ## What remains manual after provisioning is automated Karpenter provisions against requested CPU and memory. If requests are inflated, the cluster can still carry excess capacity even when provisioning and consolidation are working as designed. If requests are too low, teams may hesitate to automate changes because the operational risk is unclear. That is where enterprise operations often get thin: engineers review usage manually, adjust requests, inspect consolidation opportunities, decide whether disruption controls are acceptable, and assemble cost and reliability evidence after the fact. NAP removes the toil of operating the autoscaler itself, but it does not eliminate those review, tuning, and verification loops. ## Cast AI Closes the Karpenter-on-AKS Automation Loop Cast AI’s Karpenter Enterprise Suite supports AKS clusters running self-managed Karpenter 1.0.0 or later, or native NAP. It does not fork Karpenter or replace the provisioner. Karpenter remains the provisioning foundation, while Cast AI adds an operational layer for workload rightsizing, coordinated rebalancing, and cost visibility. The core operating loop is: 1. **Observe actual workload usage.** Workload Autoscaler analyzes CPU and memory consumption over time. 2. **Improve pod requests.** Cast AI can recommend or apply more accurate requests so workloads describe their needs more precisely. 3. **Coordinate node optimization.** Rebalancing evaluates already-running capacity against cost, utilization, scheduling constraints, and configured guardrails. 4. **Verify the outcome.** Teams compare the optimization result with cost and application signals instead of relying on a savings estimate alone. This positioning keeps the article away from “Karpenter is not enough” framing. The better message is that Karpenter is a strong provisioning layer, and Cast AI helps teams reduce the manual work around it. ## Rebalancing without forcing a migration Adoption is designed to be reversible. Removing Castware components leaves the underlying Karpenter or NAP setup in place, so teams can add optimization without moving their base provisioning logic behind a different control plane. Cast AI gives teams several ways to control how much automation they delegate: - **Manual Rebalancer** runs an on-demand optimization pass so teams can review a specific opportunity before enabling ongoing automation. - **Scheduled rebalancing** defines time windows for when node changes may occur, keeping optimization away from sensitive operating periods. - **Continuous rebalancing** can execute qualifying changes automatically when enabled and when configured savings and safety thresholds are met. - **Workload Autoscaler** improves request accuracy so future provisioning and consolidation decisions start from better workload data. For a cautious rollout, start with manual rebalancing and request recommendations. Review the proposed changes, confirm which workloads are protected by PodDisruptionBudgets, and compare the expected savings with application metrics for the same period. Then enable scheduled or continuous automation once the team is comfortable with the guardrails. ## Setting reliability guardrails to autoscaling & rebalancing Optimization ≠ savings at any cost. We believe it must respect Kubernetes disruption controls, including PodDisruptionBudgets, and flag it when a workload cannot move safely. Cast AI’s Container Live Migration can further reduce disruption for eligible workloads by moving running containers between nodes without losing application state or network connections for supported workloads and environments. Cast AI helps teams verify optimization outcomes in production. However, users should validate the specific capabilities available for their AKS setup and release before relying on automated gates or rollbacks. ## Getting started Onboarding does not require a cluster migration or a change to how teams define Karpenter NodePools and NodeClasses. The practical path is: 1. **Confirm the cluster mode.** Identify whether the cluster uses self-managed Karpenter or NAP. For self-managed Karpenter, verify that the version is 1.0.0 or later and check[compatibility](https://karpenter.sh/docs/upgrading/compatibility/) with the cluster’s Kubernetes version. Don’t assume Karpenter lives in the`karpenter` namespace:[Azure provider](https://github.com/Azure/karpenter-provider-azure) use`kube-system` , so worth checking other namespaces as well. If no deployment turns up in any namespace, you’re most likely on NAP, AKS’s managed flavor: a hidden control-plane component with no pod to find. Cast AI works with NAP-enabled AKS clusters. 2. **Connect the cluster.** Use Cast AI’s documented AKS connection flow, including the required identity and permissions setup. The walkthrough is in[__the castctl guide__](https://docs.cast.ai/docs/connect-with-castctl) . If you’d rather control every value yourself, the getting started[guide](https://docs.cast.ai/docs/karpenter-enterprise-getting-started#install-the-umbrella-chart) also documents the manual Helm install. 3. **Start with visibility and recommendations.** Review workload request recommendations, cost reporting, and manual rebalancing feature before turning them on. 4. **Enable automation deliberately.** rebalancing is opt-in by design. Continuous rebalancing is a single toggle in the console’s autoscaler policies or by adding the relevant values to the helm chart[Continuous Rebalancing for Karpenter | Cast AI Docs](https://docs.cast.ai/docs/karpenter-enterprise-continuous-rebalancing) . Start small and scale progressively.