Dora NodaIf you read a Kubernetes 1.35 changelog anytime after December 2025, you learned that StatefulSet rolling updates finally got a maxUnavailable field — beta, on by default, letting more than one replica update at once instead of the historical strict one-pod-at-a-time crawl. That was true on launch day. It has not been true since March 20, 2026.
Here's the status as of today, verified against the actual Kubernetes GitHub issues and PRs, not the release notes everyone still cites: MaxUnavailableStatefulSet ships disabled by default on every GA Kubernetes release you can currently run — both 1.35.x and 1.36.x. A rollout-deadlock bug got it turned back off within the same release cycle it launched in, and the fix isn't landing until 1.37, due August 26, 2026. And even once it's back, the quorum math below shows it buys the most common HA topology — a 3-node Postgres or Redis StatefulSet — exactly zero rollout-time savings.
What Actually Happened
MaxUnavailableStatefulSet graduated from alpha to beta in Kubernetes v1.35 ("Timbernetes," GA'd December 17, 2025), and beta shipped with the gate enabled by default — the behavior most 1.35 writeups, including the release blog roundups, describe. The field lets .spec.updateStrategy.rollingUpdate.maxUnavailable accept an absolute number or a percentage of desired replicas, instead of the hardcoded 1 every StatefulSet rollout had paid for since the controller existed.
It didn't survive contact with production. Issue #137409, filed against server version 1.35.1, describes a genuine deadlock: when a StatefulSet's current revision has a bad config and needs to move to a fixed one, the controller can get stuck comparing currentRevision to updateRevision and never converges — pods sit in a crashloop on the broken revision instead of rolling forward. The bug is specific to the Parallel pod-management path miscounting already-unavailable old-revision pods against the maxUnavailable budget, so the controller thinks its budget is spent when it isn't.
Upstream's response was fast and conservative. PR #137904 flipped the feature gate's default back to false on the 1.36/master branch, merged March 20, 2026, then got backported to the 1.35 release branch via PR #137926. The actual fix — PR #137666, which stops Parallel pod management from counting stale-revision unavailable pods toward the budget — merged April 22, 2026, but only against master. The release team's call: no backport to 1.35 or 1.36. It ships correctly-gated-on only starting in v1.37.
That means Kubernetes 1.36, which GA'd on April 22, 2026 — the same day the fix merged — shipped with the feature already disabled by default, inheriting the reverted gate from master. Every GA minor version currently in front of you defaults this feature off. The "beta and on by default" framing is accurate only for a roughly three-month window in early 2026 that has already closed.
Check What Your Cluster Is Actually Running
Don't trust the version number. Feature-gate defaults for beta features are explicitly allowed to change between patch releases — which is exactly what happened here — so the only reliable check is your own control plane:
# Confirm the gate's live state on your API server
kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep MaxUnavailableStatefulSet
# Or check what your kube-apiserver was actually started with
kubectl -n kube-system get pod -l component=kube-apiserver -o yaml \
| grep -A2 feature-gatesIf you manage a fleet of clusters at different patch versions — which any Cluster API-driven platform running rolling node-pool upgrades will, by design, have during the upgrade window — this check needs to run per-cluster, not once against a reference version. A fleet mid-upgrade from 1.35.0 (gate on) to 1.35.4 (gate off) has clusters silently disagreeing about maxUnavailable semantics on the same StatefulSet spec.
The Quorum Math
Assume it's turned on — either you're deliberately running 1.35.0–1.35.3 or 1.36.0–1.36.x with the gate flipped back on, or you're already planning for 1.37. The next question is how high you can actually set maxUnavailable on a quorum-based stateful workload — Kafka, ZooKeeper, etcd, a Redis Sentinel/Cluster deployment, any StatefulSet where a majority of members has to stay reachable — without risking a majority-down window.
The constraint is simple: never let maxUnavailable exceed the number of replicas you can lose while keeping a quorum.
quorum(N) = floor(N / 2) + 1
safe_max_unavailable = N - quorum(N)
= ceil(N / 2) - 1Rolling out a StatefulSet in batches of safe_max_unavailable takes ceil(N / safe_max_unavailable) batches, against a N-batch baseline for the old one-at-a-time default. Worked out for the replica counts you'll actually run:
| Replicas (N) | Quorum | Safe maxUnavailable | Batches (new) | Batches (baseline) | Speedup |
|---|---|---|---|---|---|
| 3 | 2 | 1 | 3 | 3 | 1.0x — no gain |
| 5 | 3 | 2 | 3 | 5 | 1.67x |
| 7 | 4 | 3 | 3 | 7 | 2.33x |
| 9 | 5 | 4 | 3 | 9 | 3.0x |
| 11 | 6 | 5 | 3 | 11 | 3.67x |
Two things worth stopping on. First, a 3-node cluster — the default HA topology for most self-hosted Postgres, Redis, and etcd deployments — gets zero benefit from this feature. Quorum on 3 nodes is 2, so the safe ceiling is 1, identical to the field's own default value. If most of your fleet's tenant databases run 3 replicas, as most do, this KEP changes nothing for them regardless of which version it ships enabled in.
Second, notice the batch count holds at exactly 3 all the way from N=5 to N=11. That's not a coincidence of the numbers I picked: for any odd N ≥ 5, safe_max_unavailable = (N-1)/2, and two batches of that size cover N-1 replicas — always one short of N, always forcing a third, smaller batch.
So quorum-safe rolling updates on an odd-sized cluster converge to exactly 3 pod-cycles of wall-clock time, independent of cluster size — an 11-node Kafka StatefulSet rolls in the same wall-clock time as a 5-node one, assuming each pod's own restart/catch-up time (T) dominates over scheduling latency, which it does for anything with meaningful startup work. The one-at-a-time baseline, by contrast, scales linearly with N. That's where the real win lives: not in a fixed multiplier, but in decoupling rollout wall-clock time from cluster size once you cross five replicas.
Where It Actually Applies — and Where It Doesn't
The quorum math above only matters for workloads that go through the StatefulSet controller's native RollingUpdate strategy in the first place — and not every stateful operator does.
CloudNativePG, the most common Postgres operator on Kubernetes, doesn't. It drives Postgres rollouts itself: the operator terminates and recreates replica pods one at a time, highest ordinal first, and switches the primary over last — specifically so a majority of write-capable replicas is never down at once. That ordering guarantee is already stricter than anything Parallel pod management can promise; the KEP is explicit that Parallel provides no ordering guarantees at all. MaxUnavailableStatefulSet graduating to beta, staying beta, or reaching GA in 1.37 changes nothing about CloudNativePG-managed Postgres rollout speed.
Where the feature does apply directly: operators and raw StatefulSets that actually use the native RollingUpdate strategy. The OT-CONTAINER-KIT redis-operator defaults its managed StatefulSets to RollingUpdate, so a Redis Sentinel or Cluster deployment managed by it is a direct beneficiary once the gate is on. So is any Kafka, ZooKeeper, or etcd-style StatefulSet you run without an operator that reimplements its own rollout ordering, and so is any generic per-tenant stateful workload a self-hosted PaaS schedules directly onto its own StatefulSets.
One more caveat from the KEP itself before you flip this on for anything: minReadySeconds is currently mishandled during updates under Parallel pod management — the documented mitigation is to stay on OrderedReady. That's not a downgrade of the win: OrderedReady combined with maxUnavailable > 1 still updates pods highest-ordinal-first, but batches safe_max_unavailable of them together instead of one at a time, which is both the safer setting for anything where ordinal 0 carries meaning and the one the quorum table above already assumes.
Planning for 1.37
If you're running a fleet of Cluster API-provisioned nodes across mixed Kubernetes versions — the normal state of a platform doing rolling node-pool upgrades rather than a synchronized fleet-wide bump — the actionable move today isn't to wait for 1.37. It's to stop assuming the release matrix tells you the truth about a beta feature gate, check each cluster's actual state with the commands above, and size any StatefulSet you do turn this on for against the quorum table, not against how high the field will technically accept.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, on a Cluster API fleet you actually control down to the feature-gate level. Star the repo on GitHub or deploy your first app today.
Sources
- KEP-961: Implement maxUnavailable in StatefulSet
- kubernetes/kubernetes#137409 — StatefulSet pods stuck on broken revision with MaxUnavailableStatefulSet enabled
- kubernetes/kubernetes#137904 — Demote MaxUnavailableStatefulSet feature gate to off by default
- kubernetes/kubernetes#137926 — Backport gate demotion to release-1.35
- kubernetes/kubernetes#137666 — Fix Parallel pod management maxUnavailable accounting
- Kubernetes v1.35: Timbernetes release announcement
- CloudNativePG: Rolling Updates documentation
- OT-CONTAINER-KIT redis-operator setup guide
- Redis Sentinel high availability documentation
