By SIG-Etcd dropped etcd v3.7.0-beta.0 on May 20, and the headline isn’t a feature — it’s a removal. The v2 store, etcd’s eight-year compatibility layer, is completely gone. This is the first etcd release running 100% on v3store, and it pulls no punches: v2 discovery, v2 bootstrap, v2 requests, and the v2 client have all been excised. If your cluster tooling still speaks etcd v2, you’ll find out when v3.7 hits GA — probably late June. Better to find out now.
etcd Is Kubernetes’ Brain. Act Accordingly.
If you’ve spent your career thinking of etcd as “the thing that just runs,” here’s your reminder: etcd stores every Pod, Deployment, ConfigMap, and Secret in your cluster. kube-apiserver reads and writes exclusively through it. Every scheduling decision, every controller reconciliation loop, every kubectl apply — it all flows through etcd. When etcd has a bad day, your entire cluster has a bad day. That’s the infrastructure you’re now upgrading.
What’s Actually Gone in v3.7
The v2 store removal has been telegraphed since etcd v3.4. The --enable-v2 flag was already removed in v3.6. What v3.7 does is finish the job: discovery, bootstrap, v2 requests, and the v2 client are gone at the source. Multiple deprecated experimental flags are gone too — which means startup failures if you’re still using them.
The tool most commonly affected is Flannel, the CNI plugin. Flannel historically used the etcd v2 client. If your cluster runs Flannel and you haven’t verified it’s using the v3 API, this is worth checking before GA day. Running a quick grep for v2 client imports across any custom etcd tooling is also worth the 10 minutes.
The practical check: run etcdctl version on your client tools. Then verify what version of Flannel you’re on and whether it has migrated to the v3 API. If you’re already on v3.6.11 in staging, pull the v3.7 beta and see what breaks. That’s exactly what SIG-Etcd is asking for.
RangeStream: The Feature Worth Your Attention
The v2 removal gets the headlines, but RangeStream is the improvement that will matter day-to-day for large clusters. In v3.6 and earlier, any request returning a large result set forces clients to wait for the entire response — all at once, in memory, before a single byte is sent back. For clusters running AI/ML workloads with thousands of Pods and ConfigMaps, this creates memory spikes and unpredictable latency on LIST operations.
RangeStream changes this by streaming results in chunks, with the server handling pagination internally and adaptive chunk sizing. It pins results to a single MVCC revision for consistency — no phantom reads mid-stream. Critically, it’s additive: older clients that don’t call RangeStream are completely unaffected. If you’re running a large cluster and have seen kube-apiserver memory spikes during LIST operations, this is worth testing in staging. The RangeStream KEP has the full technical spec.
etcd v3.4 Is EOL Right Now
If your self-managed cluster is still on etcd v3.4, you missed the May 15 deadline. That version hit end-of-life a week ago. SIG-etcd may push one final security patch before the end of May, but after that — nothing. No CVE fixes, no backports, no exceptions. Running etcd on an EOL version means running unpatched distributed consensus software at the core of your infrastructure. Check endoflife.date/etcd for the full support timeline. There is no good reason to delay upgrading to v3.5 or v3.6.
If you’re on a managed Kubernetes service — EKS, GKE, AKS — etcd upgrades happen automatically as part of control plane upgrades. This section is for self-managed clusters on kubeadm or bare metal.
The Beta Window: Use It
v3.7 is in beta, not GA. Release candidates are expected in June, with GA likely in late June or early July. That’s a 4-to-6-week window to test against your actual workloads before everyone else is pressured to upgrade. Do not put this in production yet — but do test it. SIG-Etcd explicitly called for community testing in the announcement. That’s candor you don’t always see from a mature CNCF project. Take them up on it.
What to Do Right Now
- If on etcd v3.4: Upgrade to v3.5 or v3.6 immediately. This is not optional.
- Audit your v2 clients: Run
etcdctl versionon client tools; check Flannel version and API mode; grep for v2 client imports in custom tooling. - Test the beta: If running v3.6.11 in staging, pull the v3.7 beta from the etcd releases page and validate your workloads. File issues if you find regressions.
- Back up before any upgrade: Take an etcd snapshot backup before touching any etcd version in any environment.
- Watch for RC: Follow etcd releases for RC announcements — that’s when the upgrade timeline for production gets real.
