kubernetessecurityPractitioner

Kubernetes v1.36: Why You Should Ditch Service ExternalIPs

5 min read Kubernetes BlogMay 14, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

The deprecation of .spec.externalIPs in Kubernetes v1.36 is a significant shift aimed at enhancing security. This field was an early attempt to provide cloud-load-balancer-like functionality for non-cloud clusters, but it has become a vector for security exploits. By removing this feature, Kubernetes encourages you to adopt safer, more reliable methods for exposing services.

Instead of relying on .spec.externalIPs, you can now utilize LoadBalancer Services, which are more secure and manageable. If you're operating in a non-cloud environment, consider using MetalLB, a third-party load balancer controller. With MetalLB, you can configure a pool of IP addresses for your cluster, allowing you to create a LoadBalancer Service that MetalLB will manage. Key parameters like loadBalancerClass, which prevents real load balancer controllers from managing your service, and autoAssign, which determines if IP addresses should be automatically assigned, are crucial for proper configuration. For example, you can set up a LoadBalancer Service with a non-existent loadBalancerClass to ensure it operates as intended.

In production, it's essential to note that since Kubernetes 1.21, the project has recommended disabling .spec.externalIPs altogether. If you're not using this field, you won't face issues, but if you are, it's time to transition to the recommended alternatives. Kubernetes now emits warnings when .spec.externalIPs is used, so heed these alerts to avoid potential pitfalls.

Key takeaways

→Understand that .spec.externalIPs is deprecated due to security vulnerabilities.
→Utilize LoadBalancer Services or MetalLB for exposing services in non-cloud environments.
→Configure key parameters like loadBalancerClass to prevent unwanted management of your service.
→Heed Kubernetes warnings about .spec.externalIPs to avoid operational issues.
→Transition away from .spec.externalIPs to align with best practices since Kubernetes 1.21.

Why it matters

This change impacts production environments by pushing you towards more secure and manageable service exposure methods. Ignoring this shift could lead to security vulnerabilities and operational headaches.

Code examples

YAML

1apiVersion: v1
2kind: Service
3metadata:
4  name: my-example-service
5spec:
6  type: ClusterIP
7  selector:
8    app.kubernetes.io/name: my-example-app
9  ports:
10  - protocol: TCP
11    port: 80
12    targetPort: 8080
13  externalIPs:
14  - "192.0.2.4"

Bash

1$ cat loadbalancer-service.yaml
2apiVersion: v1
3kind: Service
4metadata:
5  name: my-example-service
6spec:
7  # prevent any real load balancer controllers from managing this service
8  # by using a non-existent loadBalancerClass
9  loadBalancerClass: non-existent-class
10  type: LoadBalancer
11  selector:
12    app.kubernetes.io/name: my-example-app
13  ports:
14  - protocol: TCP
15    port: 80
16    targetPort: 8080
17$ kubectl apply -f loadbalancer-service.yaml
18service/my-example-service created
19$ kubectl patch service my-example-service --subresource=status --type=merge -p '{"status":{"loadBalancer":{"ingress":[{"ip":"192.0.2.4"}]}}}'

YAML

1apiVersion: metallb.io/v1beta1
2kind: IPAddressPool
3metadata:
4  name: production
5  namespace: metallb-system
6spec:
7  addresses:
8  - 192.0.2.0/24
9  autoAssign: true
10  avoidBuggyIPs: false