Copied to Clipboard
If you're managing clusters across multiple environments — dev, staging, prod — run this in each context. If you use GitOps via ArgoCD or FluxCD, also grep your manifests in Git:
grep -r 'externalIPs' ./manifests/ --include='*.yaml'
Document every hit. That list is your migration backlog.
2. Enable the DenyServiceExternalIPs Admission Controller Immediately
Kubernetes has shipped the DenyServiceExternalIPs admission controller since v1.21 specifically to block new usage of this field. If your clusters do not have it enabled, enable it now — before your next sprint.
For clusters you manage directly (kubeadm, Talos, RKE2), add DenyServiceExternalIPs to your API server's --enable-admission-plugins flag. For managed Kubernetes on EKS or GKE, check whether the control plane exposes this — if not, implement a validating webhook that rejects any Service with a non-empty spec.externalIPs field.
This is not optional housekeeping. This stops the bleeding. No new usage means no new technical debt accumulating while you work through the existing backlog.
3. Migrate Workloads to Supported Alternatives — Today, Not Next Quarter
The reason the Kubernetes project felt comfortable making this a hard deprecation is that the ecosystem now has mature alternatives. Your migration path depends on your cluster type:
On bare-metal or on-prem clusters (common in Brisbane enterprise and government)
-
MetalLB — a battle-hardened load-balancer implementation for non-cloud environments. Supports BGP and Layer 2 modes. Drop-in replacement for most
spec.externalIPs use cases.
-
Cilium Gateway API — if you're already running Cilium as your CNI, the Gateway API implementation covers the same use cases with better security primitives.
-
Gateway API (sig-network) — the official successor to Ingress and the recommended path for new cluster networking going forward.
On cloud-managed clusters (EKS, AKS, GKE)
- Use
LoadBalancer type Services backed by your cloud provider's NLB or ALB. If you were using spec.externalIPs to work around cost or complexity, that's a conversation worth having — the security tradeoff is not acceptable.
For internal service-to-service routing
- If you were using
spec.externalIPs for internal routing hacks, migrate to ExternalName Services, headless Services, or proper ingress/gateway patterns.
4. Update Your IaC, Helm Charts, and GitOps Manifests
Knowing you have a problem and fixing your running clusters is only half the job. If spec.externalIPs is baked into a Helm chart — yours or a third-party one — the field will reappear on the next helm upgrade.
- Audit your Helm
values.yaml files and chart templates for externalIPs.
- Check upstream Helm charts you've vendored or depend on — open issues with maintainers if they haven't already removed the field.
- Update your ArgoCD/FluxCD ApplicationSets and Kustomize overlays.
- Add a CI check — a simple
grep in your pipeline — that fails any PR introducing externalIPs into a manifest. Make the linter your enforcement mechanism before the admission controller becomes your last line of defence.
5. Communicate the Change Across Your Platform Tenants
If you run a shared Kubernetes platform — common in Brisbane's growing platform engineering teams across industries like resources, financial services, and state government — your tenants need to know this is coming.
Send a platform notice this week. Include:
- What
spec.externalIPs is and why it's being removed (link to CVE-2020-8554)
- The timeline: deprecated now, removed in a future minor release
- The approved alternative patterns your platform supports
- A deadline for tenant teams to migrate their workloads
- Who to contact for migration support
Don't frame this as "Kubernetes is making a change." Frame it as "here's what your platform team is doing to keep your workloads secure, and here's what we need from you."
The Bigger Picture for Brisbane Platform Teams
The removal of spec.externalIPs is a signal, not just a deprecation. The Kubernetes project is actively unwinding "insecure by default" decisions made in the early days of the ecosystem. More removals are coming — PodSecurityPolicy was just the beginning.
Brisbane DevOps and SRE teams that treat deprecation notices as immediate action items — not future-sprint backlog items — are the ones whose platforms stay stable when the removal actually lands. The teams that ignore them are the ones getting paged at 2am when kube-proxy stops routing traffic to a Service that still references a field that no longer exists.
Audit today. Migrate this sprint. Enforce via admission control and CI. That's the playbook.
Frequently Asked Questions
What is spec.externalIPs in Kubernetes and why is it being removed?
spec.externalIPs is a Service field that lets you assign additional IP addresses a Service responds on. It's being removed because it was designed assuming all cluster users are fully trusted — an assumption that doesn't hold in multi-team clusters. CVE-2020-8554 documented how this can be exploited, and the Kubernetes project has decided to formally deprecate it in v1.36 ahead of full removal.
When will spec.externalIPs actually stop working in Kubernetes?
The field is formally deprecated in v1.36 (released May 2026). Full removal from kube-proxy and conformance criteria will happen in a future minor release — likely v1.37 or v1.38. Given Kubernetes releases roughly every four months, teams should treat this as a 4-8 month window at most.
What can I use instead of spec.externalIPs for on-prem or bare-metal Kubernetes clusters?
MetalLB is the most widely adopted replacement for bare-metal and on-prem clusters, supporting both Layer 2 and BGP modes. The Kubernetes Gateway API (managed by SIG Network) is the strategic long-term path. If you're already running Cilium as your CNI, its Gateway API implementation is another strong option.
How do I find out if my cluster is using spec.externalIPs?
Run: kubectl get services --all-namespaces -o json | jq '.items[] | select(.spec.externalIPs != null and .spec.externalIPs != [])' against each cluster context. Also grep your GitOps manifests and Helm chart templates for the string 'externalIPs' to catch usage baked into IaC.
What is the DenyServiceExternalIPs admission controller and should I enable it?
DenyServiceExternalIPs is a built-in Kubernetes admission controller that rejects any Service creation or update that includes a non-empty spec.externalIPs field. It has been available since v1.21. Yes — enable it on every cluster now. It prevents new usage from being introduced while you migrate existing workloads, and it functions as a policy enforcement layer ahead of the full removal.