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 →Shadow AI in CI/CD: Securing the Path from Developer Laptop to Kubernetes
Shadow AI tools are creeping into your CI/CD pipelines without oversight, posing significant risks. Understanding how these tools operate and the potential for prompt injection is crucial for safeguarding your deployments. Dive into how to model these threats effectively.
Cortex Security Audit: What You Need to Know
Cortex has completed a rigorous security audit by OSTIF, enhancing its credibility as a multi-tenant storage solution for Prometheus and OpenTelemetry. The audit focused on the security health of tenant boundaries and cluster operations, using advanced code review techniques. This is crucial for anyone looking to deploy Cortex in sensitive environments.
Runtime Supply Chain Verification with NRI: Securing Your Kubernetes Deployments
In a world where supply chain attacks are rampant, ensuring the integrity of your container images is crucial. The Node Resource Interface (NRI) allows you to enforce supply chain verification at runtime, leveraging plugins to validate image attestations before they even start. Dive into how this mechanism works and what you need to watch out for in production.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.