Kubernetes 1.35 to 1.38: What Actually Changes in Production

Kubernetes did not suddenly become a different platform in version 1.37. It changed one default, one graduation and one deprecation at a time across 1.35, 1.36 and 1.37. Read each release announcement separately and the sequence looks like 197 enhancements. Operate clusters through all three and a clearer story appears.

Kubernetes is replacing old node assumptions with cgroup v2, containerd 2.x and nftables. It is pulling more security into the core through user namespaces, fine-grained kubelet authorization, CEL admission policy and native Pod certificates. And it is growing a first-class resource model for GPUs, batch jobs and AI workloads through Dynamic Resource Allocation and workload-aware scheduling.

This is not a catalogue of every KEP. It is the production map: what became usable, what can break, what you should audit before an upgrade, and what Kubernetes 1.38 may add next.

Four version numbers, one migration: modern nodes, native policy, workload identity and resource-aware scheduling.

The 30-Second Version Map

As of 22 September 2026 , these are the upstream versions that matter:

Version	Released / planned	Upstream status	Production headline
1.35 Timbernetes	17 Dec 2025	Active; EOL 28 Feb 2027	In-place Pod resize goes Stable; the node-modernisation deadline becomes real
1.36 Haru	22 Apr 2026	Active; EOL 28 Jun 2027	User namespaces, native mutation, OCI image volumes and stronger kubelet auth go Stable
1.37 Garhwal	26 Aug 2026	Latest Stable; EOL 28 Oct 2027	HPA scale-to-zero, Memory QoS and gang scheduling advance; workload identity and storage migration stabilise
1.38	16 Dec 2026 planned	In development	Enhancement set still moving; do not treat candidates as shipped features

The upstream project maintains the latest three minor branches. That does not mean your provider supports all three on the same day. GKE, EKS and AKS each have their own qualification calendar, default feature gates and extended-support policy. Start with the upstream release status, then check your provider’s version matrix.

What Changed Across the Three Releases

The useful way to read 1.35–1.37 is by capability, not chronology.

Capability	1.35	1.36	1.37
In-place Pod resource resize	Stable	Pod-level resources advance	Scheduler preemption for resize enters Alpha
HPA	Per-HPA tolerance Beta	Scale-to-zero Alpha	Scale-to-zero Beta, on by default
Workload identity	Pod certificates Beta	External SA token signer Stable	Pod certificates + trust bundles Stable
Container isolation	User namespaces Beta/default	User namespaces Stable	Rootless kubelet Beta
Admission policy	Foundations mature	MutatingAdmissionPolicy Stable	Manifest-based admission config Beta
Specialized devices	Core DRA always on	Partitioning and device controls mature	More DRA pieces Stable; workload integration Beta
Batch / AI scheduling	Gang scheduling Alpha	Workload-aware scheduling expands	Gang scheduling Beta
Control-plane scale	Comparable resource versions	Sharded list/watch work advances	Resilient cache init Stable; RangeStream Beta
Node baseline	cgroup v2 transition; last containerd 1.x release	containerd 2.x expected	cgroup v1 override is temporary; modern baseline assumed

The headline is not one feature. It is the rate at which experimental primitives became defaults.

Kubernetes 1.35: The Node and Pod Baseline Moves

Kubernetes 1.35 shipped 60 enhancements, but four changes matter disproportionately in production.

In-place Pod resize becomes real

CPU and memory requests can now change without recreating the Pod. The /resize subresource reached Stable, giving vertical autoscaling a core primitive it had lacked for years.

That does not mean every resize is disruption-free. A container can declare whether changing CPU or memory requires a restart, a resize cannot change the Pod’s QoS class, and a node without enough capacity leaves the request pending. The mechanics and the current VPA caveat are covered in my Kubernetes autoscaling deep dive.

Security starts following the workload, not the Secret

Pod certificates entered Beta. Instead of mounting a long-lived private key from a Secret, a kubelet can request short-lived X.509 credentials and rotate them for the workload. This is the beginning of a native workload-identity path that reaches Stable in 1.37.

The same release moved cached-image authorization closer to how operators assume it already works. With KubeletEnsureSecretPulledImages, a Pod cannot automatically reuse a private image merely because another authorised Pod previously cached it on that node. In multi-tenant clusters, that closes a surprisingly practical isolation gap.

Autoscaling becomes workload-specific

The HPA’s fixed cluster-wide 10% tolerance had always been blunt. Kubernetes 1.35 added a per-HPA tolerance field in Beta, letting a latency-sensitive workload react at 5% while a noisy workload keeps a wider deadband.

Fine-grained container restart rules also moved to Beta. A batch or AI Pod can keep restartPolicy: Never while allowing one container to restart for selected exit codes, avoiding a full Pod replacement for a recoverable GPU or network initialisation failure.

The old node stack gets an expiry date

Version 1.35 was the last Kubernetes release to support containerd 1.x. It also made failCgroupV1 default to true: a kubelet on cgroup v1 refuses to start unless you explicitly opt back into the legacy path. That override exists for migration, not as an architecture choice.

At the networking layer, IPVS began its retirement path in favour of nftables. If your platform templates still hard-code mode: ipvs, this is not future housekeeping. It is upgrade debt with a published direction.

Kubernetes 1.36: Security and Policy Move In-Process

Kubernetes 1.36 shipped 70 enhancements. Its strongest theme is removing infrastructure that existed only because the core API could not safely do the job itself.

User namespaces reach Stable

A process can be UID 0 inside its container while mapping to an unprivileged UID on the host. That does not make containers equivalent to VMs, but it materially reduces the impact of a container escape and is especially valuable for multi-tenant worker nodes.

This is defence in depth, not permission to run everything privileged. Pod Security Standards, seccomp, capabilities and a hardened runtime boundary still matter.

Kubelet authorization stops requiring nodes/proxy

Fine-grained kubelet API authorization reached Stable. Monitoring agents no longer need the broad nodes/proxy permission merely to read selected kubelet endpoints. That closes a long-standing least-privilege problem: nodes/proxy can reach far more of the kubelet API than most observability clients need.

MutatingAdmissionPolicy reaches Stable

CEL-based mutation now runs inside the API server. Common defaults and transformations no longer require a separately deployed webhook, Service, TLS certificate and network hop.

This does not eliminate OPA, Gatekeeper or Kyverno. Native policy does not replace image verification, resource generation, background scanning or rich reporting. The practical boundary is mapped in OPA vs Kyverno: Kubernetes Ships Policy Now.

OCI artifacts become volumes

The image volume source reached Stable. Models, binaries, configuration bundles and static assets can be packaged as OCI artifacts, pulled through the registry supply chain and mounted read-only without baking them into the application image or writing an init-container downloader.

That is directly useful for AI platforms: model weights and runtime images can move on separate release cadences while sharing registry authentication, provenance and retention controls.

Two upgrade traps arrive

The old gitRepo volume plugin is permanently disabled in 1.36. It had been deprecated since 1.11, but “deprecated” and “cannot be re-enabled” are operationally different states. Replace it with an init container or a maintained sync tool.

Service.spec.externalIPs is deprecated, with removal planned for 1.43. The field has a history of security problems because it can redirect traffic for addresses Kubernetes does not own. Prefer a LoadBalancer, a deliberately managed NodePort, or Gateway API. For the migration path on GKE, see Gateway API vs Ingress.

Kubernetes 1.37: The Latest Version Is an Operations Release

Kubernetes 1.37 contains 67 enhancements: 16 Stable, 23 Beta, 27 Alpha and one tracked deprecation/removal. The interesting part is how many affect cost, recovery and platform safety rather than application syntax.

HPA can finally scale selected workloads to zero

HPA scale-to-zero is Beta and enabled by default. It works with object or external metrics , because CPU and memory metrics do not exist when there are no Pods to measure.

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: queue-worker

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: queue-worker

  minReplicas: 0

  maxReplicas: 50

  metrics:

    - type: External

      external:

        metric:

          name: queue_depth

        target:

          type: AverageValue

          averageValue: "5"

This is useful for queue consumers, batch workers and expensive GPU inference that can tolerate cold start. It is not a free serverless switch. Your external metrics adapter must remain available at zero, and you need an SLO that includes activation latency.

Native workload identity reaches Stable

Pod certificates and ClusterTrustBundles are Stable. A workload can mount automatically refreshed private keys and certificates through a projected volume, while trust anchors arrive through a separate projected trust-bundle source.

You still need a signer controller: Kubernetes defines request, delivery and rotation, not your enterprise CA policy. But the workload-facing contract is now a stable core API rather than a collection of Secret conventions.

Metrics and resource management mature

The metrics.k8s.io API finally reaches Stable after almost nine years in Beta. The old v1beta1 does not disappear immediately, but clients should start adopting v1.

Memory QoS reaches Beta and is enabled by default on cgroup v2 nodes. Kubernetes can use memory.min, memory.low and memory.high to protect requested memory and throttle pressure before a hard OOM. Defaults are conservative, so “enabled” does not mean your workloads are suddenly throttled; it means the platform now has a supported control surface.

For AI and HPC, gang scheduling reaches Beta. Kubernetes can treat a Pod group as an all-or-nothing workload instead of scheduling half a distributed training job and wasting its GPUs while the remaining workers stay Pending.

DRA becomes a platform architecture, not a device-plugin experiment

Dynamic Resource Allocation keeps absorbing the jobs that device plugins could not express cleanly. In 1.37, stable pieces include device taints and tolerations, extended-resource requests fulfilled through a DRA driver, standard NUMA attributes and richer ResourceClaim status.

The practical result is not “replace every device plugin tomorrow.” It is that GPU, accelerator and network-device allocation now has APIs for health, topology, partitioning and policy that can evolve without encoding everything into one integer resource count.

The control plane gets safer at scale

Resilient watch-cache initialization is Stable. During startup or recovery, kube-apiserver avoids turning cache warm-up into an uncontrolled burst against etcd. Some requests are bounded; others receive HTTP 429. Your operators and custom controllers must therefore respect Retry-After and implement backoff.

The new Beta EtcdRangeStream path streams large range results in chunks instead of building one huge response in memory. It requires etcd 3.7 or later and falls back automatically against older etcd. Concurrent watch-object decoding is also enabled by default and can substantially shorten cache initialization, but it can increase concurrent load on CRD conversion webhooks.

This is why a “green API server” is not enough upgrade validation. Load-test the webhooks that sit behind it.

Storage migrations become declarative

StorageVersionMigration is Stable and enabled by default. Operators and CRD authors can request that existing objects be rewritten into the current storage version without maintaining a fragile kubectl get | kubectl replace loop or an out-of-tree migrator.

It also gives key rotation a cleaner finish: after changing encryption-at-rest configuration, a migration can rewrite old objects under the new key rather than waiting for natural updates.

The Breaking-Change Audit That Matters

The feature list tells you what you can use. This table tells you what can stop working.

Assumption in your cluster	What changed	Action before 1.37
containerd 1.x is still acceptable	1.35 was the last supported release	Move every node to containerd 2.x and validate CRI configuration
cgroup v1 can remain indefinitely	kubelet defaults to failure; v1-only path is temporary	Move node OS and runtime to cgroup v2; remove the override
IPVS is the long-term kube-proxy backend	IPVS is deprecated; nftables is the successor	Inventory mode, kernel support, monitoring and NodePort assumptions
Service.spec.externalIPs is normal exposure	Deprecated in 1.36; removal targeted for 1.43	Replace with LoadBalancer, NodePort under explicit control, or Gateway API
gitRepo volumes still limp along	Permanently disabled in 1.36	Replace with init-container cloning or a maintained synchroniser
Static Pods can read Secrets/ConfigMaps	Explicitly prohibited in 1.37	Move data to files managed on the node or redesign the bootstrap path
SELinux volume relabelling always walks files	Mount-time labelling is Stable for opted-in CSI drivers	Find shared volumes with different SELinux labels; test Pod startup
kubectl run -f will stay	--filename/-f is deprecated	Use kubectl apply/create -f for manifests
kube-dns will remain packaged	No new packages expected after 1.40	Migrate to CoreDNS; node-local-dns remains separate and maintained

An upgrade is a dependency graph. The API server version is only one node.

Audit Your Cluster Before You Upgrade

Start with facts, not Helm chart versions in a spreadsheet.

1. Inventory node and runtime skew:

Terminal window

kubectl get nodes -o custom-columns=\

NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,\

OS:.status.nodeInfo.osImage,RUNTIME:.status.nodeInfo.containerRuntimeVersion

2. Check the kube-proxy mode:

Terminal window

kubectl -n kube-system get configmap kube-proxy \

  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

3. Find Services using externalIPs:

Terminal window

kubectl get services -A -o json | jq -r '

  .items[] | select((.spec.externalIPs // []) | length > 0) |

  [.metadata.namespace, .metadata.name, (.spec.externalIPs | join(","))] | @tsv'

4. Find removed gitRepo volumes in live Pods:

Terminal window

kubectl get pods -A -o json | jq -r '

  .items[] | select(any(.spec.volumes[]?; has("gitRepo"))) |

  [.metadata.namespace, .metadata.name] | @tsv'

5. Audit the dependencies Kubernetes cannot upgrade for you:

• CNI and CSI drivers;
• ingress/Gateway controller and service mesh;
• admission and CRD conversion webhooks;
• metrics adapter, autoscalers and policy engines;
• backup/restore tooling and operators;
• node image, kernel, SELinux policy and container runtime.

Then upgrade one minor at a time. Kubernetes version-skew policy allows kubelets to trail kube-apiserver, not leap arbitrarily across versions. Managed services may automate control-plane sequencing, but they cannot prove that your webhooks, CRDs and workloads survive it.

What Kubernetes 1.38 May Add

This section is deliberately dated. On 22 September 2026, Kubernetes 1.38 has not reached Enhancement Freeze. The release cycle began on 31 August; Enhancement Freeze is scheduled for 29 September AoE, code freeze for 16 November AoE, and GA for 16 December 2026.

The official v1.38 release tracking board already contains many candidate items, and its contents and statuses are still changing. A tracking board is a planning surface, not a shipping guarantee.

The confidence changes at each gate. Before Enhancement Freeze, every feature list is provisional.

The candidates worth watching because they continue the 1.35–1.37 direction include:

Candidate	Why it matters	Confidence today
Hermetic network-isolated Pods	A workload-level contract for Pods that must not have network connectivity	Tracked candidate; inclusion not final
In-place container probe updates	Change probes without recreating the Pod	Tracked candidate; inclusion not final
External node-liveness detection	Let specialised infrastructure provide stronger node-health signals	Tracked candidate; inclusion not final
Assigned resources through Downward API	Expose actual device/resource assignment to containers without API access	Tracked candidate; inclusion not final
Weighted kube-apiserver load balancing	Send more traffic to healthier or more capable API server peers	Tracked candidate; inclusion not final
Controller leader-election recovery	Reduce control-loop disruption around failed leaders	Tracked candidate; inclusion not final
StatefulSet integration with Workload APIs	Extend workload-aware scheduling beyond Jobs	Tracked candidate; inclusion not final

There are also continuations whose exact 1.38 state deserves watching: SELinux mount behaviour, cgroup v1 retirement, IPVS deprecation, DRA, workload-aware scheduling, Pod checkpoint/restore and in-place resize. I will update this article after Enhancement Freeze and again when 1.38.0 ships. Until then, any article promising a final “Kubernetes 1.38 feature list” is publishing a forecast as a changelog.

Which Version Should You Run?

New self-managed cluster: target 1.37 if your CNI, CSI, runtime and operators support it. There is little value in deliberately starting on 1.35, whose maintenance window begins in December 2026.

Existing production on 1.35: do not panic-upgrade, but complete the node-baseline work now: containerd 2.x, cgroup v2, add-on compatibility and IPVS inventory. Move through 1.36 in a tested sequence.

Managed Kubernetes: run the newest release your provider marks production-ready and your add-on matrix supports. Upstream Stable is an API maturity statement, not a provider availability promise.

Waiting for 1.38: do not hold a necessary security or support upgrade for a release whose features are not frozen. Upgrade to a supported 1.36/1.37 baseline; treat 1.38 as the next validation cycle.

For the larger operational boundary between upstream and managed services, see what EKS, AKS and GKE actually manage. For platform guardrails around the cluster, see the secure-by-default GKE reference architecture.

The Bottom Line

Kubernetes 1.35–1.37 is a platform transition disguised as three minor releases.

The old baseline was containerd 1.x, cgroup v1 compatibility, IPVS, broad kubelet proxy permissions, webhook infrastructure for every policy, Secrets for workload certificates and device plugins that reduced a GPU to a number. The emerging baseline is containerd 2.x, cgroup v2, nftables, fine-grained authorization, in-process CEL policy, rotating Pod identity and resource APIs that understand devices and whole workloads.

Do not upgrade for KYAML output or a longer list of feature gates. Upgrade because the supported security and resource model moved. Audit the assumptions that moved with it, canary the dependencies Kubernetes does not own, and keep 1.38 in the watchlist until the release team turns candidates into release notes.

Originally published at alekseialeinikov.com