Platform support: where it runs, honestly
The gate is a node kernel with sched_ext plus permission to run a privileged DaemonSet. Kernel version alone is not enough — we verify configs on live nodes and say NO where it is a no.
Requirements
- Node kernel ≥ 6.12 with
CONFIG_SCHED_CLASS_EXT=yand BTF enabled. - Permission to run a privileged DaemonSet with hostPID and
/sysmounts. - Kubernetes ≥ 1.33 with standard (not fully-managed) node pools.
The verified matrix
| Platform | Node OS / kernel | Status | Confidence |
|---|---|---|---|
| GKE Standard ≥1.36Our reference platform | COS-129, 6.12 | Yes | Verified live |
| EKS, AL2023 (K8s 1.36)EKS’s default node OS works | AL2023, 6.18 | Yes | Verified live |
| EKS, Bottlerocket (K8s ≥1.33) | Bottlerocket, 6.12 / 6.18 | Yes | Verified live |
| EKS Auto Mode (K8s 1.36)Privileged DaemonSet admitted; scheduler attached | Bottlerocket, 6.18 | Yes | Verified live |
| EKS Graviton / ARM64Attach + QoS path verified; GA gated on one reliability fix | AL2023 arm64 | Preview | Verified attach; GA pending |
| RHEL 10 hosts (upstream K8s / k3s / RKE2) | RHEL 10, 6.12 | Config-verified | Kernel config read from source; lab run pending |
| On-prem Ubuntu 25.04+ / custom ≥6.12 | 6.14+ / operator-built | Likely | Canonical documents sched_ext from 25.04 |
| GKE AutopilotKernel qualifies, but privileged DaemonSets are forbidden | COS-129+ | No | Verified (docs + live) |
| AKSMicrosoft disables sched_ext in its kernels, even the 6.12 HWE kernel | Azure Linux 3.0 / Ubuntu 24.04 | No | Verified (kernel config in source) |
| OpenShift (OCP 4.x current)Arrives when RHCOS rebases onto RHEL 10 | RHCOS / RHEL 9, 5.14 | Not yet | Verified (kernel version) |
Checking a node yourself
On any node (or via a privileged debug pod), a kernel with sched_ext exposes its state in sysfs:
cat /sys/kernel/sched_ext/state
# "disabled" — kernel supports sched_ext, nothing attached (good to go)
# "enabled" — a sched_ext scheduler is already attached
# file absent — the kernel lacks CONFIG_SCHED_CLASS_EXT; Temper cannot enforce hereThe agent performs the same verification at startup and refuses loudly (in logs and the
node’s infera.io/agent-status annotation) rather than half-working.
Mixed fleets
Heterogeneous fleets are safe and normal: nodes that fail the gate simply run stock CFS — absence of benefit, not harm. This makes incremental adoption the default path: add a qualifying node pool, verify, expand.
ARM64 status
On EKS Graviton, scheduler attach and the QoS enforcement path are verified working; general availability is gated on one known reliability fix. If ARM64 is your fleet, talk to us about the design-partner program — it is the fastest way to move a platform up this table.