Your Kubernetes Clusters Just Got a Hard Deadline

If your platform team is running Kubernetes in Brisbane — whether on-prem in a Fortitude Valley data centre, on EKS, AKS, or a bare-metal cluster out of a Queensland government facility — the v1.36 release has handed you a ticking clock.

The .spec.externalIPs field for Kubernetes Services is now formally deprecated. Not soft-deprecated. Not "we recommend avoiding it." Formally, officially, documented-in-the-changelog deprecated — with full removal from kube-proxy and conformance criteria coming in a future minor release. That future release could be v1.37 or v1.38. The Kubernetes release cadence is roughly every four months. You do not have years.

This matters because .spec.externalIPs has been a known security liability since CVE-2020-8554 was published in 2020. Any cluster where users are not 100% trusted — which is every multi-team cluster, every shared platform, every SaaS product running on Kubernetes — is potentially vulnerable. The deprecation is the project drawing a hard line on "insecure by default" patterns it can no longer defend.

Here is exactly what your team needs to do, starting today.

1. Audit Every Service in Every Cluster for spec.externalIPs Usage

Before you do anything else, you need ground truth. Run this against every cluster your team manages:

kubectl get services --all-namespaces -o json | \
  jq '.items[] | select(.spec.externalIPs != null and .spec.externalIPs != []) | \
  {namespace: .metadata.namespace, name: .metadata.name, externalIPs: .spec.externalIPs}'

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.