What StornX gives you
Six concrete properties of the controller - each rooted in a real problem you have probably hit in a multi-AZ Kubernetes cluster.
Communication-aware placement
OptiScaler picks the node and zone for every new replica based on the live service graph - chatty services end up together, fault tolerance is preserved by design.
Adaptive traffic balancing
OptiBalancer continuously tunes Istio DestinationRule weights using latency, CPU and replica counts. Gradual steps and dead-zone gating prevent oscillation.
Zero application changes
One Helm release, one Pod, no sidecars, no CRDs, no annotations on your workloads. Defers to existing HPAs and respects PDBs.
Lower cross-AZ cost
By keeping communicating Pods in the same zone whenever fault tolerance allows, StornX directly attacks one of the largest hidden line items on a multi-AZ Kubernetes bill.
Graceful zone-degradation handling
Traffic is shifted away from a degrading AZ within one cycle. Replacement replicas land in healthy zones. Error spikes become latency wobbles.
Explainable decisions
Every scaling action and DestinationRule patch is one structured log line with the inputs and the reason. No black-box ML, no surprises.