Frequently asked questions

The real questions from real evaluations — answered with the same caveats-first policy as the benchmarks.

Does Temper coexist with HPA and VPA?

Yes — they operate on different axes. HPA changes replica counts based on metrics; Temper arbitrates CPU among whatever pods land on a node, so they compose naturally. VPA rewrites resource requests, which Temper then consumes as its sizing input — also compatible, with one operational note: in namespaces where the overcommit webhook is enabled, both VPA and the webhook are adjusting requests at admission time. That works (the webhook annotates originals and never touches limits or Critical pods), but keep one clear owner of request values per namespace so audit trails stay legible.

We run Karpenter / Cast AI / a rightsizer. Do we have to replace anything?

No. Complement mode is the default: Temper’s own placement layer ships disabled, and the node engine works under any placer because it needs only Kubernetes-native inputs. Your tool decides where pods go and what they request; Temper decides who gets the CPU when the node is busy. Measured with Karpenter in both arms: −40% provisioned vCPU at equal load and SLO. Details.

Are CPU limits still enforced while Temper is attached?

Honest answer: cgroup cpu.max quotas are not kernel-enforced while a sched_ext scheduler is attached — a property of the kernel feature, not a Temper choice. Containment comes from Temper’s layer ceilings instead; quota-derived ceilings are on the roadmap; memory limits are unaffected; and the kill switch restores CFS with quotas instantly. Full disclosure: safety & rollback.

What happens if the agent crashes, gets OOM-killed, or is deleted?

The kernel detects the scheduler detach and atomically reverts the node to stock CFS — measured under load as a 0.03 ms p99 blip with the replacement agent Ready in 15 s. Degradation is per-node, never per-cluster, and the failure direction is always “absence of benefit,” not harm.

Do we need to change our applications?

No. Enforcement inputs are pod.spec.priority (PriorityClasses) and the resource requests you already declare. The only per-workload action is assigning a PriorityClass — one line in a pod spec. Workload profiles are optional and applied by image match or a single annotation.

What does it cost in overhead?

The always-on observation layer measures 0.13% of one core (<1% budget). The scheduler itself runs in the kernel’s scheduling path — that is the mechanism, not an overhead item — and the benchmark deltas on the benchmarks page are all net of everything Temper adds.

Does it run air-gapped?

Yes, by architecture rather than by feature flag: there is no SaaS control plane, no telemetry beacon, no license-check callback — zero external calls. The Enterprise tier adds an air-gap install kit (offline images, signed artifacts, SBOM) for environments where even the initial pull must be offline.

What’s the licensing? Can we see the source?

Temper is commercial software in a design-partner phase. The repository is not public yet; source access is available to design partners, and every release ships with an SBOM, image signatures, and the exact carry-patches applied to the pinned upstream scheduler — so what runs on your nodes is reviewable and diffable even before broad source availability.

Why doesn’t it run on AKS or GKE Autopilot?

AKS: Microsoft currently disables sched_ext in its node kernels, including the 6.12 HWE kernel — there is nothing to attach to. GKE Autopilot and similar fully-managed modes forbid privileged DaemonSets outright. We state both plainly in the platform matrix rather than working around policy.

Can we roll it out to part of the fleet?

Yes — that is the recommended path. Mixed fleets are safe: nodes without the agent (or without sched_ext) run stock CFS as they do today. Start with one node pool, verify with the linter and your SLOs, then expand. Canary tooling for agent upgrades is built into the chart (operations).

Does Temper manage memory and network too?

Enforcement is CPU scheduling — that is where sched_ext gives kernel-level leverage. Memory and I/O are monitored (PSI pressure, per-pod memory and network panels, contention incident detection) but arbitrated by the kernel’s existing mechanisms; memory limits behave exactly as before. We say “CPU” precisely because that is what we can prove.

How do QoS tiers and workload profiles relate?

Tiers arbitrate between workloads (which pod wins a busy node); profiles structure threads within one workload (which of a pod’s threads get exclusive cores or latency treatment). Tiers alone carry most headline benchmark results; profiles add the workload-specific stage on top. See QoS tiers and workload profiles.

Who do we contact about security?

security@temper.codes — disclosure policy, the security whitepaper, threat model, and the review package for your security team are described on the security page.