Introducing Sed: Your cloud & AI assistant

Meet Sed
Sedai Logo

Introducing Kubernetes Pod Interceptor: Optimize Without Fighting Your Pipeline

Ethan Andyshak Headshot

Ethan Andyshak

VP of Product

September 10, 2026

Introducing Kubernetes Pod Interceptor: Optimize Without Fighting Your Pipeline

Featured

Sedai has released Pod Interceptor and Smart Scheduler, two changes to how Sedai executes and schedules on Kubernetes, so the optimization you've already identified actually lands.


Every platform team knows the challenge: you have a savings target, a dashboard full of recommendations, and a long list of reasons why none of it gets implemented this quarter. CI/CD guardrails fight automated changes. Manual optimization steps get skipped. Nodes stay provisioned long after the work they were sized for has moved on.

Today we're introducing two changes to how Sedai carries out optimization on Kubernetes: the Pod Interceptor – a new workload optimization execution model – and the Smart Scheduler, a new scheduling layer.

The problem: your own tooling is in the way

Getting a workload from an idea to a running application in Kubernetes takes a few steps: it starts as a definition in your infrastructure-as-code (IaC), gets realized as a deployment spec in Kubernetes, and finally spawns as a live pod on your cluster. Your CI/CD pipeline's job is to make sure the first two stay in sync, so when Sedai (or anything else) reaches in and edits the deployment spec directly to right-size a workload, CI/CD sees drift and reverts it. Optimization and GitOps end up in a tug-of-war.

Previously, the way we helped you avoid that fight was Sedai Sync — detecting when CI/CD reverted an optimization and reapplying it directly to the live environment. It works, but it's one more moving part, and it doesn't remove the underlying tension.

There's a second, quieter cost too: even when optimization isn't fighting your pipeline, it's still often manual. Sedai's existing Cluster Compaction feature can consolidate workloads onto fewer nodes, but it requires someone to log in and click "run.” Unsurprisingly, that's a step most teams don't get around to.

Pod Interceptor: Optimization Without the Drift Fight

The Pod Interceptor changes where Sedai acts. Instead of editing the deployment spec — the step your CI/CD pipeline is actively watching — Sedai intercepts the pod as it's spawned from that spec, and right-sizes it before it becomes a running instance. Your CI/CD pipeline still sees your IaC and your deployment spec in agreement. No conflict, no revert, no drift alert. The optimization simply happens a layer downstream, where nothing is watching for it.

It's a deliberate trade-off. Some teams are IaC purists who want the live pod to always mirror what's written in code. For them, our existing model, along with our IaC loopback feature, still applies. Other teams care less about that literal match and more about avoiding pipeline conflicts. For them, this is exactly the "good hygiene" they're after. 

A few things worth calling out:

  • Pod Interceptor will be the default for new customers, with existing customers rolling out now. Our original execution model remains available as an option for anyone who prefers it.
  • Guardrails as Code is still available to govern every change, in both the legacy and Pod Interceptor models — it's what limits how far Sedai is allowed to go.
  • Sedai Sync steps back to a supporting role for Kubernetes workloads under Pod Interceptor. With drift no longer the default case, it runs quietly in the background as a safety net for edge cases (like a brief window during pod rescheduling) and remains the primary mechanism for the legacy execution model and non-Kubernetes workloads.

Pod Interceptor is an escape hatch: a way to run autonomous optimization without an overhaul of your CI/CD configuration. Combined with the legacy model, it also means Sedai offers the broadest set of execution options in the category — where most competitors give you one way to run, we give you two.

Deployment spec update modelPod Interceptor

Smart Scheduler: turning savings into fewer nodes, automatically

Right-sizing a workload only becomes a lower cloud bill once it translates into fewer nodes. That's historically been a manual step, and it's what Smart Scheduler is built to close, continuously and without anyone clicking a button.

Smart Scheduler works alongside the native Kubernetes scheduler, and does two things:

  1. Workload-aware placement. The default Kubernetes scheduler spreads pods across nodes to load-balance, without any sense of which workloads belong together. Smart Scheduler adds that awareness: it looks at whether an application is CPU-bound, memory-bound, general-purpose, or "sensitive" (fragile, low-replica workloads that need extra care), and routes it to nodes accordingly, packing compatible workloads densely rather than spreading them thin.
  2. Continuous strategic descheduling. Even well-placed pods can end up stranded — the last workload keeping an otherwise-emptied node alive. Smart Scheduler identifies these cases and consolidates them elsewhere, freeing the node to be reclaimed.

The combination means nodes get used more efficiently from the moment pods are created, and get cleaned up automatically as workloads change, all running continuously, with no manual "compact now" step and no approval queue.

It's a similar goal to node auto-provisioners like Karpenter, but without the migration lift: no re-platforming required, and it works across cloud providers where Karpenter-style consolidation is harder to adopt (notably Azure and GCP, versus AWS).

Because Smart Scheduler runs alongside the default scheduler rather than replacing it, adoption is incremental and safe: you can opt specific namespaces, workloads, or node pools in or out, and if Smart Scheduler ever has an issue, workloads simply fall back to default Kubernetes scheduling behavior — the same behavior you're running today.

Smart Scheduler

Built to work together

Pod Interceptor and Smart Scheduler solve different problems. One is about how Sedai makes changes without fighting your pipeline, the other is about what happens to workload savings once they're made. Used together, they mean Sedai can identify an optimization, apply it without triggering a GitOps revert, and consolidate the resulting savings onto fewer nodes, all without a human in the loop.

If you want to go deeper on how Pod Interceptor interacts with your existing IaC workflows, our IaC integration resources are being updated to reflect the new model, reach out to your Sedai team for the latest.

Learn More

Have questions about how Pod Interceptor or Smart Scheduler would work in your environment? We're happy to walk through how it works for your clusters.

Kubernetes Pod Interceptor