Resource optimization that works with the OpenShift control plane.
Agent-driven optimization of pods, storage, autoscalers, and node fleets across OpenShift — recommendations land as MachineSets, NodePools, or Terraform diffs in the existing GitOps flow.
Request and limit specifications, kept in sync with workload reality.
OpenShift ships VPA and RHACM right-sizing, but neither closes the loop. Kubex applies recommendations continuously via mutating webhooks and in-place resize — OpenShift-managed namespaces untouched.
Continuous request right-sizing
Tuned from learned utilization, freeing capacity the OpenShift node 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 gets discovered during incidents. On OpenShift, 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 OpenShift, HPA 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.
OpenShift node specs drift once pod sizing changes land. Kubex covers three modes: simulation-based recommendations for ASG/VMSS-backed compute, MachineSets via the OpenShift Node Optimizer, and NodePool specs via the Karpenter Optimizer.
Output is the artifact, not a recommendation
MachineSets, NodePools, or Terraform diffs through existing change-management.
Awareness across all three autoscaler modes
Default, OpenShift node autoscaler, and Karpenter — each handled with the right primitive.
Continuous re-evaluation as pod sizing evolves
Recompute as pod requests change.
Higher pod density, with safety bounds that keep it usable.
OpenShift consolidation and the scheduler’s 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
Auto-tuned across default, OpenShift, and Karpenter from observed pod-sizing accuracy.
On-prem hardware deferral, not just cloud savings
On bare metal and VMware, density defers the next hardware refresh.
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 OpenShift Kubex covers all of it: time-slicing via NVIDIA KAI, MIG on Ampere/Hopper/Blackwell, SKU selection, and cross-provider analysis across CSPs, neoclouds, and on-prem.
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.
See what Kubex can do in your own OpenShift clusters
A walk-through of the agent surface and change-management flow — on a cluster you actually run.
