Linux 7.0 Ships, K8s Bans AI Co-Authors, Cluster Autoscaler Gets CapacityBuffer
Cluster Autoscaler: CapacityBuffer Beta, WAS Architecture Proposed, Repo Split Planned
- CapacityBuffer is now beta in Cluster Autoscaler 1.35 — a first-class API that formalizes the balloon-pod pattern. CA keeps spare capacity above scheduled pods; incoming pods absorb the buffer while CA provisions to restore it. A cloud provider extension point allows offering suspended nodes (lower cost, slightly worse latency) as the buffer backing. A second flavor — buffer consumed by specific workloads and not recreated — is in progress.
- CapacityQuota (alpha, available to test now) applies label-selector-based provisioning caps to arbitrary node groups: "at most 1,000 CPU across nodes with label X." Complements CapacityBuffer; the two are designed to be used together.
- Node group template visibility API is in design to fix the zero-node-group problem where CA guesses (and caches) what a new node looks like on restart. The new API lets users declare what's running on nodes — custom DRA drivers, DaemonSets adding custom resources — so CA applies them on top of cloud provider templates. Progress to accelerate post-KubeCon.
- Workload-Aware Scheduler (WAS) is an architectural proposal to eliminate scheduler simulation entirely. Instead of CA/Karpenter independently simulating kube-scheduler behavior, new APIs enable direct communication: CA publishes
PotentialCapacity(candidate node groups); the scheduler reads both real and potential nodes when evaluating pending pods; CA reacts toCapacityRequestsfrom the scheduler rather than pending pods directly. APreferenceAPI aligns autoscaler and operator node-selection preferences with scheduler scoring — enabling pluggable scheduler support and eliminating race conditions. Still early proposal stage; a major summit was planned for the day after the KubeCon EU talk. - Repo restructure incoming: CA core logic will be extracted to a new repository; the existing repo retains cloud provider code. Cloud providers are encouraged to extract independently. Three GKE-specific CA features — node group auto provisioning, custom compute class preferences, and spot/on-demand fallback chains — will be upstreamed to the new core repo.
- DRA support is production-ready as of CA 1.35 for node-local devices (e.g., NVIDIA GPU driver). Scaling from zero nodes works for select drivers only; arbitrary DRA drivers still require at least one existing node in the group. CSI node volume limits are now correctly tracked in CA's internal simulation, resolving a long-standing race where the scheduler could overschedule volumes onto a node before its CSI node object was published.
Kubernetes Steering: AI Disclosure Now Mandatory, CLA Bot Closes Non-Human Co-Authors
- The Kubernetes Steering Committee confirmed at KubeCon EU that the AI usage policy will change from "please disclose" to a hard requirement. PRs with undisclosed AI-generated content will be closed without comment; one steering member stated they closed a PR for this "just yesterday."
- The CLA bot now checks
Co-Authored-ByandCo-Developed-Byheaders — any non-human entity without a signed CLA is automatically blocked. This was an oversight that has now been patched. The Linux Foundation confirmed that LLMs cannot sign CLAs; co-authoring commits with AI agents will not be permitted. - Steering explicitly ruled out using AI for project governance — annual reports, contributor relations, SIG management. The stated reasoning: steering involves sensitive situations affecting contributors' careers; offloading that is "actively disrespectful."
- Low-quality AI-generated PRs are described as a mounting reviewer burden: multiple submitted PRs referenced non-existent struct members and variables that did not compile. The Kubernetes project's CI does not run on external contributor PRs by default, meaning some passed initial review before the issue was caught locally.
- On the US Supreme Court ruling that LLM-generated content is not copyrightable: the Linux Foundation VP of Legal confirmed awareness but has issued no guidance to projects on handling commits that may contain non-copyrightable content.
Headlamp Moves to kubernetes-sigs; SIG UI Seeking 5 New CNCF Project Integrations
- Headlamp joined
kubernetes-sigs/headlampunder SIG UI as a shared, vendor-agnostic Kubernetes UI. Current shipped plugins: Flux, Karpenter, OpenCost. A Cluster API plugin is in active development (week 2 of LF Mentorship Program) — maintainers intentionally preserved old CAPI API support after learning operators plan to use it for 2+ years past the new API's availability. - The plugin system is TypeScript-based; CRD-heavy projects get near-automatic integration from existing schemas. Multi-cluster support, namespace-based multi-tenancy, and RBAC-controlled namespace creation are available in both in-cluster web and desktop (macOS, Windows, Linux) modes.
- SIG UI is seeking 5 new CNCF project collaborations aligned with the LF Mentorship program timeline. The proposal → alpha → beta lifecycle runs ~3 months with maintainer collaboration on which CRDs and user workflows to prioritize.
Supply Chain Hardening: GitHub Actions Patterns from KubeCon EU
- Pin GitHub Actions to commit SHAs, not semver tags: tags are mutable and were the attack vector in the tj-actions exploit (covered in yesterday's TeamPCP writeup — the same vulnerability class). The tooling cost is automated by Renovate/Dependabot. CodeQL for GitHub Actions workflows specifically flags missing
permissions:blocks and missing pinned SHAs; free for open-source repos. - OIDC token exchange at publish time replaces long-lived PATs: each publish requests a scoped, short-lived token (typically ≤1 hour, single-use) from the registry (NuGet, JFrog, AWS, etc.), tied to the specific repo and environment. Token theft from a supply chain compromise yields an already-expired credential. GitHub recently added support for custom OIDC attributes for further scoping.
- SLSA provenance at publish + verify at consumption: sign artifacts and generate SLSA provenance at build time using the native GitHub attestation action; consumers verify with
gh attestation verifybefore use. Without the consumption verification step, all upstream signing is security theater at the boundary that actually matters.
Linux 7.0 Stable Ships Today; Last-Minute AMD Zen 3 MCE Fix Included
- Linux 7.0 stable released today, April 12, on schedule despite an unusually high-volume RC cycle. A last-minute patch for AMD Zen 3 (Ryzen 5000 series) filters bogus L3 cache deferred errors caused by garbage MCE values introduced in a recent kernel rework — the fix is a CPU model/stepping check and is safe to include this late. Marked for backport to recent stable kernels.
- Linux 7.0 is the kernel base for Ubuntu 26.04 LTS "Resolute Raccoon" shipping April 23. The cgroup v2-only enforcement (systemd 259 drops v1) remains the primary upgrade-planning item for Kubernetes node OS teams — workloads or tooling referencing cgroupv1 paths must be validated before any node image migration to 26.04. GKE is already removing cgroup v1 support in version 1.35, with upgrade blocks for clusters that have not migrated.
Get Platform and Infra Briefing in your inbox
Subscribe to receive new issues as they're published.