Platform engineering

Kubernetes 1.37 beta lands a StatefulSet Recreate strategy and CRI pod checkpoint RPCs

Kubernetes 1.37 beta lands a StatefulSet Recreate strategy and CRI pod checkpoint RPCs

The headline changes

Kubernetes v1.37.0-beta.0 dropped this week during the release code freeze, and for anyone who owns rollout code the two beats that matter are a new StatefulSet update strategy and a pod-level checkpoint and restore RPC on the CRI interface. The release also promotes PLEGOnDemandRelist and InPlacePodVerticalScalingInitContainers to GA, moves ClusterTrustBundle to stable, and cuts metrics.k8s.io over to v1. A v1.36.3 patch landed alongside it with a fix for a kubelet memory-leak regression that first slipped in during 1.36.

Per Last Week in Kubernetes Development, both builds use Go 1.26.5 and default to etcd 3.7.0. Code freeze is on. Feature blogs are due August 3, docs freeze on August 5, and the cherry-pick deadline for the next set of patches is August 7.

Recreate for StatefulSets, and why deployment tooling has to notice

Until now StatefulSets have had two update strategies to pick from, RollingUpdate and OnDelete. The 1.37 beta adds a third, Recreate, which tears the set down before bringing the new version up. That is the same shape as a Deployment's Recreate strategy, applied to workloads with stable network identity and attached storage.

The operational read is simple. A rolling update on a StatefulSet has always been the least-bad option for stateful workloads that cannot briefly run mixed versions. Recreate makes the mixed-version window impossible, at the cost of accepting a real downtime window on rollout. That is a valid answer for singletons and for workloads that must never have two versions talking to the same data at once. It is also a footgun for anything that quietly relied on rolling to hide restart cost. If your GitOps sync policy assumes rolling semantics on every StatefulSet in the cluster, audit the manifests before you pin to 1.37 anywhere you cannot easily roll back.

Pod checkpoint and restore, in the CRI itself

KEP-5823 adds two RPCs to the v1.RuntimeService CRI interface, CheckpointPod and RestorePod. The interface change is worth flagging on its own. It moves what was a kubelet-side and container-runtime-side experiment into the contract that every conforming runtime has to answer, which is the layer where node agents and platform migration tools live.

The obvious use cases are live pod migration between nodes and long-lived debug workflows where you snapshot state before an intrusive change. The hazards are the same ones that have kept CRIU-style container checkpointing out of most production pipelines up to now: secrets, open file descriptors, and network state that do not survive a serialize and deserialize round trip. The API is landing in beta. Assume the tooling that consumes it will land later, and read the runtime notes before you promise anyone a hot migration.

What else is worth pinning

A short list of the smaller items in v1.37.0-beta.0 that will show up in someone's postmortem eventually.

  • PLEGOnDemandRelist goes GA. This changes the kubelet's pod lifecycle event loop from a fixed-cadence relist to on-demand, and it is the kind of change that closes one class of stuck-pod bug and opens another. Read the changelog before you shrug at it.
  • InPlacePodVerticalScalingInitContainers goes GA. Vertical scaling on init containers without a pod restart is now a supported path, which matters for workloads whose init containers do heavy migration work.
  • metrics.k8s.io moves to v1, and ClusterTrustBundle goes stable. Autoscaling controllers and workload identity code that pinned to the beta APIs should be checked.
  • PersistentVolumeClaimUnusedSinceTime is on by default in beta. It surfaces PVCs that have not been mounted recently, which is useful for cost work and dangerous if a cron consumer of a PVC has been off for a while.
  • A new "/allocatedPods" kubelet endpoint (KEP-6030) exposes what the kubelet believes it has committed to, distinct from what is actually running. That is a real gap for on-call debugging today.

The 1.36.3 note, and where it bites

The v1.36.3 patch is not the headline but it is the one to backport first. It rolls up fixes for DRA scheduling and allocator bugs, the kubelet memory-leak regression that landed during 1.36, server-side apply regressions, and kubeadm etcd learner promotion and join resiliency improvements. If you are still on 1.36 with a leaking kubelet you already know why.

The Recreate strategy and the CRI checkpoint API are the two changes to test against your deployment stack before 1.37 hits any cluster you have to keep alive at 3am. The rest turn boring once they are shipped, which is the point of a beta.

Source: Last Week in Kubernetes Development (lwkd.info)

Related
Platform engineering

Kyverno's CLI learns to fake production so offline policy tests stop lying

A CNCF blog post walks through how the Kyverno CLI now stands up an in-memory fake of the Kubernetes API cache, so policies that lean on GlobalContextEntry lookups can be exercised offline instead of silently skipping. The workflow that used to say 'all pass' when it really meant 'never ran' has finally closed.

July 29, 2026
Platform engineering

Google's pitch: put Agent Substrate on top of GKE Agent Sandbox, and call it the AI-agent runtime

Two months after GKE Agent Sandbox went GA in May 2026, Google introduced a follow-up called Agent Substrate in the same post. The New Stack's read is that Google now wants Kubernetes to be the runtime for AI agents on the primitives GKE already uses for production services.

July 26, 2026
Platform engineering

After the ingress-NGINX retirement, what your migration plan owes production

The Kubernetes SIG Network retired ingress-nginx in March 2026, leaving clusters still on it exposed to unpatched CVEs and stalled feature work. A CNCF post lays out the two migration paths operators are picking between and the tooling to make the move.

July 11, 2026

Turn this into your pipeline. Build it on Buddy.

Start free