Resource optimization for AKS node pools and autoscalers.
Agent-driven optimization of pods, storage, autoscalers, and node fleets for AKS clusters backed by VMSS-based node pools or Karpenter — landing as Karpenter NodePool, Bicep / Terraform, or GitOps diffs.
Request and limit specifications, kept in sync with workload reality.
On AKS, Azure Advisor produces sizing guidance and the open-source VPA can surface request recommendations — but neither closes the loop, so recommendations accumulate and rarely land. Kubex applies them continuously via mutating webhooks and in-place resize, leaving AKS-managed namespaces untouched.
Continuous request right-sizing
Tuned from learned utilization, freeing capacity the cluster autoscaler holds in reserve.
Limits prevent OOM and throttling
Shaped to actual peak behaviour, not template defaults.
Predictive scaling and new-workload sizing
Predictive Pod Scaler resizes ahead of learned patterns; Container Deployment Sizer drafts new specs via MCP.
Local storage requests aligned to actual disk pressure.
Ephemeral storage is the resource discovered during incidents. On AKS, under-spec’d ephemeral-storage triggers disk-pressure evictions; over-spec’d caps pod density. Kubex tracks usage and adjusts requests via the same in-place path as CPU and memory.
Pressure-driven scheduling stays accurate
Requests reflect real disk consumption, not worst-case guesses.
Capacity restoration
Right-sized requests release headroom held against worst-case usage.
Disk-pressure evictions eliminated upstream
Requests track growth, so disk-pressure conditions never form.
Horizontal autoscaling, configured from how the workload behaves.
On AKS, HPA (often paired with KEDA for event-sourced scaling) carries elasticity for most workloads, but keeping it correct is hard — thresholds inherit from templates, policies stay default, HPAs outlive their pod sizing. The HPA Optimizer recomputes thresholds, scale policies, and replica bounds against today’s workload.
Thresholds re-anchored after pod sizing
Recomputed when right-sizing shifts the request denominator.
Scale policies tuned to reaction time
Against observed behaviour, not Helm-chart defaults.
OOM and throttling shielded
Flags HPA settings that let pods hit throttling or OOM before scale-out.
Node fleets that match the workload they actually run.
AKS node-pool specs drift from workload reality once pod sizing changes land. Kubex addresses this in two modes: simulation-based VM-SKU and scale-set parameter recommendations for VMSS-backed pools (via Terraform, az CLI, or GitOps), and NodePool specs via the Karpenter Optimizer on AKS (NAP) — with spot, ARM, and GPU candidates included.
Output is the artifact, not a recommendation
VMSS-backed node-pool specs, NodePools, or Terraform / Bicep diffs through existing change-management.
Aware of both AKS autoscaler modes
VMSS-backed node pools and Karpenter (NAP) each get the right primitive — VMSS scale-set parameters or NodePool requirements.
Continuous re-evaluation as pod sizing evolves
Recompute as pod requests change.
Higher pod density, with safety bounds that keep it usable.
On AKS, the cluster autoscaler and the scheduler’s bin-packing strategies (MostAllocated, RequestedToCapacityRatio) under-pack by default. Tuning them before right-sizing pods is the failure mode — overstacking, throttling, OOM. The Bin Packer ties density to pod-sizing maturity, raising it as sizing stabilises.
Max-pods and strategy per node type
Aligned to actual pod profile — MostAllocated / RequestedToCapacityRatio.
Consolidation thresholds move with pod-sizing maturity
AKS cluster-autoscaler scale-down delay and Karpenter consolidationPolicy auto-tuned from observed pod-sizing accuracy.
Per-pool consolidation profiles
System, GPU, and general pools each get their own aggressiveness — density gains don't churn pools that need to stay stable.
Capacity initialized before the load curve hits.
Reactive autoscaling adds nodes after pressure arrives — paid every day on daily-cyclical workloads. The Node Prewarmer provisions ahead of forecast from Kubex’s pattern models. Leverage peaks on GPU inference — CUDA pulls and model load dominate cold starts.
Predictive scheduling against learned patterns
Runs ahead of the daily load cycle, not after pressure.
GPU-aware pre-warming
CUDA pulls and model load accounted for, so inference SLOs aren't paid in warm-up.
Coordinated with bin packing
Pre-warm respects consolidation thresholds, so headroom doesn't fight stable-load density.
Inference and training, sized to the right GPU.
GPU workloads bring decisions CPU tooling doesn’t make — sharing strategy, partitioning, and SKU. On AKS Kubex covers all of it: time-slicing via NVIDIA KAI, MIG on Ampere/Hopper/Blackwell, SKU selection, and cross-provider analysis across Azure GPU SKUs (NC, ND, NV families), neoclouds, and adjacent CSPs.
Per-workload sharing strategy
MIG, time-slicing, or MPS — by isolation, flexibility, or memory profile.
SKU selection includes provider economics
Factor in benchmarks, availability, and pricing — not the local default.
Cross-provider price/performance
Workloads evaluated across CSPs, neoclouds, and on-prem — comparison, not auto-move.
AI Agent
Brings optimization intelligence to wherever you work. Talk to Kubex in plain language, or connect your AI agents via MCP and make them infrastructure optimization experts.
Query your infrastructure in plain language and get direct, explainable answers about resource behavior, changes, and optimization decisions.
Connect Claude, Cursor, or any AI agent via MCP. You're not giving it raw data. You're making it an infrastructure optimization expert.
Grounded in deterministic AI, with private LLM integration. We don't train on your data.
See what Kubex can do in your AKS cluster.
A walk-through of the agent surface and change-management flow — on a cluster you actually run.
