Introducing Autonomous Infrastructure: Kubernetes Requests That Keep Themselves Right

Every team running Kubernetes makes the same trade-off when they set CPU and memory requests.

Plan for stability, and you budget for more than you need. Nobody can quite explain why the number has to be that high, but nobody wants to be the one who cut it either.

Plan lean, and you're fine until traffic spikes. Think of an online retailer that's steady most of the year, then Black Friday hits. Either you've been paying for Black Friday capacity since January, or your engineers get paged at 2am trying to figure out what's going on.

Either way, the number someone picked at deploy time stays put while your traffic doesn't. Requests don't ebb and flow with the workload, so they drift further from reality every week.

Today we're launching groundcover Autonomous Infrastructure in beta. It's the first product built on Wand, the Kubernetes optimization company we acquired in September. Our CEO Shahar wrote about why observability needs to start fixing problems instead of only finding them. This post is about what we built and how it works.

What it does

Autonomous Infrastructure continuously rightsizes CPU and memory requests for the Kubernetes Deployments you turn on. When a workload is over-provisioned, it shrinks the request. When a workload is running short, it grows it.

Stability is the first constraint. Most teams don't avoid rightsizing because they like paying for idle capacity. They avoid it because cutting too far causes incidents, and a tool that only cuts is a tool engineering won't turn on.

See what it would change before you turn it on

If you already run groundcover, the eBPF sensor in your cluster has been collecting the data this needs. Open Autonomous Infrastructure and every Deployment already has a recommendation, whether or not you've turned anything on. Brand-new Deployments show as Learning until there's enough data to go on.

For each workload, you see current CPU next to recommended CPU, current memory next to recommended memory, and the estimated monthly impact in dollars. Savings and stability investment both show up, so you can see where it would spend money to keep something healthy, not just where it would save. Estimates start at default list prices, and you can enter your own prices and discount to match what you pay.

If you lead an engineering or infrastructure team, this is the part I'd look at first: the waste in your clusters, in dollars, before you commit to anything.

Sizing with the whole node in view

What sold me on Wand was talking to the founders about how they approach sizing. Most rightsizing tools look at one workload at a time. That sounds reasonable until a request that looks right for one service starves its neighbors on a crowded node, or something else on that node keeps sitting over-provisioned.

Autonomous Infrastructure still optimizes each workload, but it folds node contention into every recommendation, so an increase for one workload doesn't push the node out of resources.

Two other details stood out to me:

• Sidecars get sized too. Istio, Linkerd and Vault agents, plus native sidecars, all add to a pod's requests, and they're often where waste hides.
• It won't fight your autoscaler. If an HPA or KEDA scales a workload on CPU or memory utilization, that resource is locked and left alone.

Autonomous, inside your guardrails

I'll be honest: when I first heard the name Autonomous Infrastructure, it scared me a little. It sounds like handing over the keys to the castle. And the most skeptical SRE at our booth is going to ask exactly that: why should I trust you to manage my infrastructure?

You don't have to, at least not right away. Autonomous Infrastructure is off by default. You opt a cluster in, then turn it on one Deployment at a time. Turn it on for the workloads you're comfortable with, leave the rest alone, and keep watching the recommendations until you trust them. Not every workload has to be autonomous.

When you do turn it on, it stays inside lines you already drew:

• Requests only, never limits. Your declared limit is the ceiling. If a recommendation wants more than your limit allows, the workload shows as Bounded, which usually means the limit itself deserves a look.
• No restart when it can avoid one. Changes are applied as in-place resizes when Kubernetes allows it. When it doesn't, it falls back to a rollout with a backoff, so workloads aren't restarted over and over.
• GitOps-safe. Changes are recorded as annotations that Argo CD and Flux don't treat as drift, so your workloads don't go OutOfSync.
• Admin-only and audited. Only admins can turn it on or change settings, and every action produces an audit event.
• Easy to turn off. Deactivating a Deployment stops new changes, and rolling it out restores its original values.

On limits specifically: changing them doesn't save money, because Kubernetes schedules on requests. Limits are also tied to how applications run. A JVM sizes its heap from the memory limit, for example. Changing them from the outside is how you create surprises, so we don't.

Under the hood

Recommendations come from full-fidelity eBPF data with no sampling. The algorithm runs in the groundcover backend inside your own cloud, through our BYOC architecture, so your data stays where it already lives. It's built on Wand's optimization engine.

What's in the beta

The beta covers Kubernetes Deployments, including their sidecars. More workload kinds, reacting to OOM kills, and JVM-aware sizing are on the roadmap.

Try it

We're launching in beta - if you're at KubeCon + CloudNativeCon North America in Salt Lake City, come find us at booth #111. We'll be running live demos all week, and I'd love to hear how your team sets requests today.

Your traffic changes every day. Your requests should too.