Kubernetes v1.37 beta is mostly about not OOMing your control plane during LIST storms

Etcd RangeStream in the apiserver: fewer giant LIST buffers, less latency jitter

KEP-5966 lands a backend-only optimization: RangeStream (server-streaming gRPC) replaces the old “paginate unary Range until you hate yourself” behavior for big list reads during watch-cache initialization. The gate is named EtcdRangeStream, and the KEP is explicit about what changes: watch-cache sync() consumes chunks, converts each chunk into synthetic “created” events, and queues them without assembling the full list in memory. That’s the whole point: stop building a single monster allocation that spikes RSS and turns GC into a crime scene.

So what? Large clusters have been paying a hidden tax: LIST-heavy workflows (resyncs, cache warmups, certain controller patterns) create unpredictable latency and memory usage. Streaming doesn’t magically make etcd fast, but it makes the failure mode less catastrophic: you can process incrementally and overlap network I/O with decode, instead of blocking on “download everything, then decode everything.”

Feature gate behavior is engineered for skew, but you still have to test the right thing

The KEP bakes in the obvious reality: not everyone will be on an etcd that supports RangeStream. When etcd returns Unimplemented, kube-apiserver falls back to unary Range. That’s good engineering. It’s also an easy way to fool yourself during testing: flip the gate, see no explosions, and conclude the optimization works—while you were never actually using it.

Gotcha: validating usage is metric-driven. The KEP calls out etcd_request_duration_seconds_count{operation=”listStream”} as the “streaming happened” indicator. If it’s missing or stuck at zero, you didn’t test RangeStream. Period.

Concrete rollback signals (because you’ll need them)

Everyone loves performance work until it regresses a weird corner. The KEP is unusually operationally minded here: watch apiserver_watch_cache_initialization_duration_seconds{group,resource}. If that number spikes vs your baseline, stop arguing and roll it back. Also track etcd_request_duration_seconds{operation=”listStream”} p99; if streaming is slower than the previous paginated path in your environment, you’ve learned something unpleasant about your IO/CPU balance.

Failure modes: compaction and “silent fallback”

Streaming introduces a failure you’ll see in logs: interrupted streams due to compaction. The KEP calls out the classic error string: mvcc: required revision has been compacted. Expect retries with backoff. That’s survivable, but it can create thundering-herd behavior if you’re already near the edge.

Control planes are getting hammered harder than they were designed for. More CRDs. More controllers. More “platform as a product” internal teams piling on. Meanwhile, etcd has always punished large read workloads with ugly memory characteristics when clients insist on full result sets. RangeStream is maintainers admitting the obvious: buffering massive lists is architectural debt, not a user problem.

Also: etcd v3.7 removes more legacy v2store baggage. That’s not sexy, but it’s the kind of housecleaning that keeps operational behavior predictable. Fewer ancient codepaths means fewer weird flags that only one large provider still uses, and fewer “why does this still exist?” support cases.

Net: v1.37 beta is the platform leaning into incremental/streaming primitives because cluster state keeps growing, and pretending everything fits in RAM is how you end up debugging apiserver restarts at 2 AM.

Target to test: Kubernetes v1.37.0-beta.0 (scheduled 2026-07-15) and etcd v3.7.0-beta.0 or newer in a non-prod control-plane lane.

Test etcd 3.7 beta quickly (standalone)

ETCD_VER=v3.7.0-beta.0
GOOGLE_URL=https://storage.googleapis.com/etcd
curl -L ${GOOGLE_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd.tgz
mkdir -p /tmp/etcd-test && tar xzvf /tmp/etcd.tgz -C /tmp/etcd-test --strip-components=1
/tmp/etcd-test/etcd --version
/tmp/etcd-test/etcdctl version

Or run the beta container

ETCD_VER=v3.7.0-beta.0
docker run --rm -p 2379:2379 -p 2380:2380 
  --name etcd-${ETCD_VER} 
  gcr.io/etcd-development/etcd:${ETCD_VER} 
  /usr/local/bin/etcd 
  --listen-client-urls http://0.0.0.0:2379 
  --advertise-client-urls http://0.0.0.0:2379 
  --listen-peer-urls http://0.0.0.0:2380 
  --initial-advertise-peer-urls http://0.0.0.0:2380 
  --initial-cluster s1=http://0.0.0.0:2380 
  --initial-cluster-state new 
  --logger zap --log-outputs stderr

Enable the Kubernetes-side gate (kube-apiserver)

Set the apiserver feature gate (method depends on your distro). The generic flag form is:

kube-apiserver --feature-gates=EtcdRangeStream=true

Red Flags to watch for (logs + metrics)

• Silent fallback: apiserver warnings about etcd not supporting RangeStream / Unimplemented. If you see this, you did not test the new path.
• Compaction-induced retries: mvcc: required revision has been compacted during watch-cache init.
• Regression canary: apiserver_watch_cache_initialization_duration_seconds rising above baseline for key resources.
• Streaming actually used: etcd_request_duration_seconds_count{operation=”listStream”} > 0. No counter movement, no streaming.
• Proxy limitation: RangeStream is not supported by the etcd gRPC proxy; don’t route apiserver traffic through it and expect this to work.

🛠️ Try These Free Tools

See all free tools →