→ Back to Home
Kubernetes

Kubernetes 1.35 Reaches GKE Rapid Channel, Solidifying cgroup v1 Deprecation

Kubernetes 1.35 has officially landed in Google Kubernetes Engine's (GKE) Rapid channel as of September 18, 2026, becoming the default version for early adopters. This follows its earlier rollout to Amazon EKS in August and Microsoft AKS in March. The most impactful change in this release is not a new API, but rather a "kill switch": the `failCgroupV1` parameter now defaults to `true`. This means that any kubelet attempting to start on a node still utilizing the older cgroup v1 resource-accounting model will refuse to boot unless an administrator explicitly overrides this setting. This change is particularly significant because it formalizes the deprecation of cgroup v1, pushing users towards the more advanced cgroup v2. For practitioners, this isn't just a version bump; it's a mandate to modernize their underlying Linux environments. Organizations running self-managed Kubernetes clusters or older versions of managed services need to assess their node configurations and plan for upgrades to cgroup v2. Failure to do so will result in nodes failing to join or restart, leading to potential outages. This move impacts anyone responsible for the operational stability and resource efficiency of Kubernetes clusters, from platform engineers to SREs. The shift to cgroup v2 aligns with a broader trend in cloud-native infrastructure towards more efficient and robust resource management. Kubernetes has consistently evolved to leverage underlying kernel features for better performance and isolation. The project's upstream release of 1.35 on December 17, 2025, bundled 60 enhancements, reflecting continuous development aimed at improving the platform's capabilities. This push for modernization is also seen in the increasing adoption of Kubernetes for demanding workloads like AI/ML, which require precise resource allocation and management. In practice, practitioners should immediately identify any clusters or nodes still relying on cgroup v1. For managed Kubernetes services, this might involve reviewing the provider's documentation for upgrade paths and compatibility matrices. For self-managed environments, a thorough audit of the operating system and container runtime configurations is crucial. The transition to cgroup v2 offers benefits such as improved resource isolation, better performance for certain workloads, and enhanced observability. However, it requires careful planning and testing to ensure a smooth migration and avoid unexpected downtime. This is a clear signal that the Kubernetes ecosystem is maturing, and staying current with these foundational changes is essential for maintaining a healthy and performant infrastructure.
#kubernetes#cgroupv2#gke#deprecation#resource management#upgrade
Read original source