Kubernetes

Kubernetes 1.37 (Garhwal): SELinux remounts default, cgroupv2 tightening, IPVS deprecation

Kubernetes 1.37 (Garhwal) enables SELinux remounts, tightens cgroupv2 enforcement, and deprecates IPVS—update runtimes and remove static-pod secret refs.

August 31, 2026·3 min read·AI researched · AI written · AI reviewed

Kubernetes 1.37 just moved from permissive hardening to opinionated defaults. The most consequential change is not a new scheduler tweak or a metrics bump — it's that SELinux remount/relabeling (SELinuxMount) is enabled by default, cgroup v2 enforcement is stricter, static pod secret references are removed, and IPVS is being deprecated. Those are not incremental niceties; they raise the bar on runtimes and cluster operations in a way that will surface latent incompatibilities across on-prem, distro, and cloud-managed clusters.

This release (GA 2026) promotes many features to stable and aligns with newer Go toolchains required by recent Kubernetes releases. But the operational work sits outside the kube-apiserver: it's about container runtimes and CRI compatibility. Operators should consult vendor guidance and target a modern, CRI‑v1 compatible runtime that supports SELinux relabeling and the cgroup v2 behaviors Kubernetes now assumes.

Runtime upgrade is now the gating factor

Kubernetes is finally enforcing runtime hygiene. The combination of SELinuxMount on by default and stricter cgroup v2 requirements will break setups that relied on permissive host mounts or outdated SELinux label workflows. The removal of secret references in static pods is a breaking change that will manifest during kubelet restarts: static pods defined with secret refs will fail to start unless those references are removed or handled by an alternative secret distribution mechanism. IPVS support is being signaled for deprecation in this release; expect CNI and load‑balancer stacks to publish compatibility notes and migration paths (including eBPF-based alternatives).

The ecosystem reaction has been predictable: runtime projects and vendors are formalizing more regular cadences and clearer compatibility matrices so operators can plan upgrades. Follow your distro or cloud provider guidance for the exact containerd (or other runtime) versions they certify for Kubernetes 1.37 rather than assuming a particular upstream version number.

Practical steps worth doing now:

  • Check your runtime and CRI endpoint versions, for example: containerd --version and crictl --runtime-endpoint unix:///run/containerd/containerd.sock info (adjust the socket path for your environment).
  • Validate CRI compatibility: Kubernetes 1.37 expects runtimes that expose the stable CRI (v1); migrate any out-of-tree shims or very old CRI clients.
  • Audit static pods for secret references and remove or replace them before rolling kubelet upgrades.

This is the right move. Weve spent a decade papering over runtime differences with distro-specific hacks and shaky admission controllers. Kubernetes forcing a narrower compatibility set reduces the long tail of debugging where a kubelet behaves differently because of an older runtime. It will hurt teams who deferred runtime upgrades, but that pain is productive.

Kubeflow graduation — why it matters for platform teams

Kubeflow has recently completed additional maturity and security work and is moving toward broader adoption; upstream components are being validated against modern Kubernetes defaults. That matters because Kubeflow (and similar AI platforms) expect clusters that are compatible with stricter Pod Security Standards, multi-tenant defaults, and sane runtime behavior.

Operationally, Kubeflow's maturation shortens the window where you can safely run AI infra on old runtime stacks. If your cluster still can't safely run SELinux relabeling or is tied to an older container runtime, Kubeflow operators will hit failure modes rapidly.

What to expect in the next 90 days

Upgrade churn. Expect weeks of runtime and kubelet upgrades across cloud providers and distributions. Vendors will issue compatibility notes; managed clusters will stagger control-plane upgrades and advertise certified runtime support. Network plugin authors will publish IPVS deprecation guidance or offer eBPF/iptables migration paths.

One last blunt point: teams that treat runtimes as "infrastructure plumbing" and defer lifecycle work are about to be surprised by user-visible failures. Kubernetes 1.37 is not a gentle nudge — its an enforcement action. If your cluster upgrade plan is just "wait and hope," make a different plan: test on a branch cluster, check your runtime with containerd --version and crictl info, and scrub static pods for secret refs now. The ecosystem has finally synchronized its clocks; if you don't, you'll be doing reactive patching during the next maintenance window.

Sources

kubernetescontainerdselinuxipvs
← All articles
Kubernetes

Kubernetes v1.37 (Garhwal): metrics.k8s.io v1, PodCertificates and trust bundles graduate

Kubernetes v1.37 Garhwal promotes metrics.k8s.io to v1, graduates PodCertificate and cluster-trust-bundle APIs, deprecates IPVS, and tightens kubelet/SELinux.

Sep 1, 2026·3mkuberneteskubernetes-1.37
Kubernetes

Kubernetes: metrics.k8s.io API graduates to v1 stable

Kubernetes promotes the Metrics API (metrics.k8s.io) to v1 stable, closing autoscaler and observability compatibility gaps while runtimes evolve slowly.

Aug 30, 2026·3mkubernetesmetrics-api
Kubernetes

Kubernetes 1.37: Metrics API Graduates to Stable

Kubernetes v1.37 promotes the Metrics API to stable, standardizing in-cluster metrics for HPAs and autoscalers and forcing adapters and vendors to migrate.

Aug 28, 2026·3mkubernetes-1-37metrics-api