Kubernetes 1.37 Buries Service ExternalIPs and Beefs Up Network Observability

July 31, 2026. The Kubernetes release team published the v1.37 sneak peek, with the final release expected in mid-September 2026. The headline items: the beginning of Service ExternalIPs removal, the Mixed Version Proxy graduating to beta, new network metrics in the Cloud Controller Manager, and the release of etcd 3.7.0. Three structural changes that directly affect every production cluster administrator.

This is not a flashy feature release. It is a technical debt cleanup and a security hardening release.

Service ExternalIPs: closing an architectural attack vector

ExternalIPs have existed since the earliest Kubernetes releases. The idea: attach an external IP address directly to a Service, bypassing the cloud provider’s LoadBalancer. Convenient in theory, dangerous in practice.

The problem has been documented since 2019 (CVE-2019-11253 and its descendants): an attacker who can create or modify a Service can intercept traffic destined for any IP on the network. In essence, ExternalIPs let you receive traffic that was never addressed to you — an architectural man-in-the-middle.

Kubernetes 1.36 introduced the official deprecation of the feature behind a feature gate. Version 1.37 goes further:

• The ServiceExternalIPs feature gate is off by default for new clusters.
• An automatic migration mechanism is available: the API silently converts ExternalIPs to LoadBalancer addresses where a controller supports it, or to NodePort as a fallback.
• Existing clusters receive a formal warning in kube-apiserver on every use of ExternalIPs.

For ops teams, two immediate actions:

1. Audit all Services using externalIPs — kubectl get svc -A -o json | jq '.items[] | select(.spec.externalIPs != null) | {name: .metadata.name, namespace: .metadata.namespace, ips: .spec.externalIPs}' gives you the exhaustive list.
2. Migrate to legitimate alternatives: LoadBalancer (MetalLB on-prem), standardized Ingress via Gateway API, or, for hairpin NAT scenarios, an external probe driven by a DaemonSet.

Final removal is scheduled for Kubernetes 1.39 — roughly six months after 1.37. The clock is ticking.

Mixed Version Proxy: zero-downtime upgrades become the default

The Mixed Version Proxy (MVP) was introduced as alpha in Kubernetes 1.35. In 1.37, it graduates to beta and becomes safe for production use.

The problem it solves is familiar to anyone who has performed a cluster upgrade: during the window where the control plane runs version N+1 while kubelets are still on N, API requests may target resources that do not yet exist in the older version. Result: spurious 404 errors, crashing reconcilers, service interruptions.

MVP introduces a compatibility proxy between kube-apiservers of different versions. Here is how it works:

• Requests arriving at an N+1 apiserver for a resource that only exists since N+1 are automatically routed to the control-plane node that understands it.
• Responses are normalized: a field added in N+1 is stripped before being returned to an N-level client.
• The kube-scheduler and controller-manager use MVP to guarantee they never schedule Pods with fields that older kubelets cannot parse.

In beta, MVP is enabled by default on new clusters created with kubeadm 1.37. For existing clusters, the MixedVersionProxy feature gate controls activation.

The payoff is significant for multi-tenant or mission-critical clusters where maintenance windows are tight: an upgrade that used to require an hour of partial downtime can now complete without observable interruption.

Cloud Controller Manager: a new route synchronization metric

The Cloud Controller Manager (CCM) handles route synchronization between the Kubernetes cluster and the cloud provider’s underlying network. Until 1.36, this synchronization was a black box: impossible to know if a route was stuck, delayed, or failing without diving into raw logs.

Kubernetes 1.37 introduces the route_sync_duration_seconds metric, exposed in Prometheus format by the CCM. It breaks down into three labels:

• cloud_provider: identifies the provider (AWS, GCP, Azure, OpenStack…).
• operation: distinguishes create, update, and delete.
• status: success, timeout, or error.

Paired with standard Prometheus alerting, this metric detects a network desynchronization before it causes an outage. For a cluster with over 100 nodes, that is the difference between a 2 a.m. alert and an incident manager paged at 3 a.m.

etcd 3.7.0: faster, stabler, tighter

On July 31, 2026, etcd 3.7.0 was announced, and Kubernetes 1.37 recommends this version as the cluster storage baseline.

Key improvements:

• Parallelized compaction. Compaction — the periodic etcd operation that prunes old revisions and reclaims disk space — no longer blocks writes during execution. On a 50-node cluster, compaction time drops from 15 seconds to under 2 seconds.
• Mandatory TLS 1.3 for inter-node communication. Backward compatibility with TLS 1.2, which enabled silent downgrades, is gone.
• Watch progress notify. etcd clients now receive periodic notifications even when no change has occurred — eliminating unexplained timeouts on long-running watch sessions.

Migration from etcd 3.6 is transparent for a standard Kubernetes cluster: a rolling upgrade of the etcd pods is sufficient. Storage remains compatible; no dump/restore is required.

Verdict

Kubernetes 1.37 will not make tech press headlines — but it is precisely the release that SREs and cluster administrators have been waiting for. It removes a dangerous feature (ExternalIPs), smooths upgrades (Mixed Version Proxy), provides visibility into cloud networking (CCM), and hardens storage (etcd 3.7).

If you manage production clusters, your September action plan fits in three lines: audit your ExternalIPs now, enable the Mixed Version Proxy on your staging clusters this week, and schedule an etcd rolling upgrade during a standard maintenance window. The rest will follow.

References

• Kubernetes Blog, « Kubernetes v1.37 Sneak Peek, » July 31, 2026.
• Kubernetes Enhancement Proposal KEP-2340, « Mixed Version Proxy, » 2025.
• etcd GitHub Releases, « etcd v3.7.0 Release Notes, » July 31, 2026.