Kubernetes v1.36: Why You Should Ditch Service ExternalIPs
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
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"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"}]}}}'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: falseWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Navigating NIS2 and DORA Ownership in Kubernetes Teams
Understanding who owns NIS2 and DORA regulations on your Kubernetes platform team is crucial for compliance and security. The traceability chain involves specific roles across risk, legal, and security teams, alongside your platform and application teams. Get ready to clarify responsibilities and streamline your compliance efforts.
Guardrails, Not Gates: Rethinking Policy in Kubernetes
In a world where developer experience clashes with security, adopting a guardrail approach can transform your platform team's policies. Instead of blocking progress, guardrails guide developers while ensuring compliance. Learn how to implement validation effectively with Kyverno's enforcement settings.
Security Slam 2026: Elevate Your Kubernetes Security Posture
Get ready for Security Slam 2026, a 30-day virtual event designed to boost your project's security hygiene. Leverage OpenSSF projects and engage with advisors in a dedicated CNCF Slack channel to tackle security challenges tailored to your maturity level.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.