Kubernetes and GPU operations made easy

Wave sizes, scales, and diagnoses your Kubernetes workloads inside your own cluster. Your team gets right-sized requests, replicas that follow traffic, and the cause of each failure, all in one console.

Without Wave

Kubernetes cluster without WaveKubernetes clusterAPI serverHPAKarpenterreacts in ~30scold node ~31snodeOOMKilled, no causenodePending

On-call engineer joins dashboards and alerts by hand

Each part works alone. Nobody sees the whole cluster.

~30s and ~31s from Wave feature pages. Pod counts are illustrative.

With Wave

The same cluster with WaveKubernetes clusterOne layer thatsizes, scales, and diagnosesAPI serverreplicas ~10s · warm nodesnodeWave Agentsized to real usenodeWave Agentcause shown

Your team sees it all in one console

One layer sees the whole cluster and acts on it.

~10s from the Autopilot feature page. Kubernetes icons: Kubernetes community, Apache-2.0.

Enterprise challenges

Six problems you can check in your own cluster

Each card starts with a number from a named source. Open a card to see what Wave changes.

Requests far above use, then sized to useWithout WaveWith Waverequest ≫ usesized to use
Wave Sizing

You pay for 10 CPU cores and use 1

Pods request far more than they use, and nobody knows which value is safe. Memory use averages 23%.

CAST AI, 2025 Kubernetes Cost Benchmark Report

Smart Sizing →
Restart loop, then a failure with its typeWithout WaveWith WaveOOMKilledrestarts, no causetype + logs saved
Wave Diagnosis

The Pod restarts every 5 minutes, and kubectl get shows only CrashLoopBackOff

A high-impact Kubernetes outage takes a median of 51 minutes to resolve, and 39% take an hour or more.

kubernetes.io, Pod Lifecycle; Komodor, 2025 Enterprise Kubernetes Report

Pod / Container Failures →
6 scattered object lists, then one pathWithout WaveWith Wave6 kubectl listsone path
Platform & Observability

Which Pod serves /checkout? 6 kubectl lists to find out

Gateway, HTTPRoute, Service, EndpointSlice, Pod, and Node are separate lists. Engineers already spend 33% of their time addressing disruptions.

Kubernetes Gateway API and core API; New Relic, 2025 Observability Forecast

Cluster Map →
The first new Pod: 31 seconds, then 3 seconds, in one Wave benchmark runWithout WaveWith Wavefirst new Pod: 31sfirst new Pod: 3s
Wave Karpenter

The new Pod sits in Pending for 31 seconds while a node starts

By default, Karpenter launches a node only after a Pod is Pending. In one Wave benchmark run, the first new Pod waited 31 seconds for the node and its image.

Wave 3.1.0 release post, one benchmark run, first new Pod

Node Warmup →
Replicas lag the peak, then are ready before itWithout WaveWith WavePods too latePods ready early
Wave Autoscale

Logins peak at 9:00: HPA takes 30+ seconds to go from 10 to 80 Pods

You know the peak is coming, but HPA starts only after the load arrives, and it can at most double the pods every 15 seconds.

Calculated from the kubernetes.io HPA defaults, starting at 10 pods

Autopilot Scheduler →
Requests fail, then only low-priority requests are rejectedWithout WaveWith Waverequests faillow priority shed
Wave Flow

A ticket sale opens, and traffic hits 4x the previous peak

Bots and fans without codes drove 3.5 billion requests, 4x Ticketmaster's previous peak.

Ticketmaster, Eras Tour presale, Nov 2022

Wave Flow →
HOW IT WORKS

How Wave runs in your cluster

The five stages above run on one mechanism. Wave collects metrics, logs and Kubernetes state together, reasons over them, and applies the result.

Wave system architecture inside your Kubernetes clusterYour Kubernetes clusternodeWave Agent+ cAdvisor, on every node1Read: metrics over gRPCStatefulSet, one PodDecides what to changeWave CoreAPI, Autopilot, Smart SizingWave IntelligenceML models of each workloadWave Web Consolewhat your team opens2

Metrics history on one PVC (40Gi). No outside database.

3API serverKubernetesHPAreplicasPodsCPU and memoryPVCsizeKarpenternodesIstioWave FlowYour team uses the Web ConsoleAlerts go to Slack or a webhook

1 Read, 2 Decide, 3 Change. Every change goes through the Kubernetes API.

Powered byAutopilotSmart SizingKarpenterFlowDiagnosisincl. AI Agent NEW

Console Demo

See the console before you install anything

Click through sizing recommendations, Autopilot scaling, and K8s diagnosis — with simulated data, right in your browser.

Explore the console demo →
console.waveautoscale.com

Trusted by Leading Organizations

AWS EKS Service Ready Partner
Red Hat Partner Program tier 2026 — Ready
HPE
CNCF
Getting started

3 simple steps to production

Works on EKS, GKE, AKS, OpenShift, and self-managed Kubernetes 1.26+.

1

Request a license key

Free for clusters under 200 vCPU. Two install methods issue the key by email in seconds. The rest are answered by a person.

Request free key →
2

Install via Helm

One values file with your key and storage class, one helm install. Air-gapped clusters supported.

$ helm repo add wave-autoscale-helm \ https://release.waveautoscale.io/helm-chart$ helm install wave-autoscale-helm \ wave-autoscale-helm/wave-autoscale-helm \ -f values-ghcr.yaml \ -n wave-autoscale --create-namespace
3

Open the console

Port-forward, sign in, and Wave starts auto-discovering workloads. Autopilot can run in observe-only mode first.

$ kubectl port-forward -n wave-autoscale \ svc/wave-autoscale-svc 3025:3025# open http://localhost:3025
Default login · admin / waveautoscale
FAQ

Common questions, clear answers

We already use HPA — why do we need this?

HPA only watches whether resource usage crosses a threshold, not how your workload actually performs. Wave Autopilot uses ML-based workload performance modeling to reach scaling decisions in about 10 seconds — roughly 2× faster than HPA, without threshold tuning.

Isn't KEDA the same thing?

No. KEDA specializes in event-driven workloads (Kafka, queues) — a different objective. KEDA complements HPA and Wave Autopilot rather than replacing them. Wave Autopilot scales long-running services based on workload performance, which is a separate problem.

How is this different from VPA for resource sizing?

VPA uses CPU percentile statistics alone, so a fixed CPU allocation can't adapt to sporadic request surges. Wave Smart Sizing factors in both CPU percentiles and real-time workload demand, maintaining optimal success rates — for example allocating 2.0 cores instead of 1.5 when bursts demand it.

Does Wave Flow replace Istio?

No. Wave Flow runs on top of Istio — adding priority shaping, a virtual waiting room, and visibility through Envoy filters and control-plane extensions. Your existing Istio mesh is untouched; Wave Flow makes overload behavior graceful instead of treating every request equally.

We use Karpenter already. What does Wave Karpenter add?

Three things. Karpenter Dashboard shows nodes, cost per hour, Spot ratio, and thrashing for each NodePool in Wave Console. Node Warmup starts a node before the next Pod needs one: in one Wave benchmark run, the first new Pod was ready in 3 seconds instead of 31. Spot Workload Placement keeps Pods up to a threshold on On-Demand and puts the rest on Spot, by replica number, with no change to your YAML.

We already have Grafana — why Wave Diagnosis?

Grafana shows you the metrics, but you still have to guess what's wrong. Threshold alerts miss slowly-progressing issues until they become incidents. Wave Diagnosis ships with five ML diagnostics — cluster resource forecasting (7–60 days out), memory leak detection, CPU utilization analysis, pod scheduling delay detection, and idle node detection — so you can shift from reactive to proactive operations.

Will this work in our air-gapped or on-prem environment?

Yes. Wave runs entirely inside your cluster with no external dependencies. Air-gapped environments are fully supported, including private container registries. Wave is an AWS EKS Service Ready Partner and a Red Hat Certified Partner, and also runs on bare-metal Kubernetes.

Ready to operate Kubernetes the right way?

Start with a free Smart Sizing Report on your own cluster. No credit card. White-glove onboarding included.