No, specifying externalIPs
for LoadBalancer
type of service is not required.
externalIPs it's a bit different feature of Kubernetes cluster:
If there are external IPs that route to one or more cluster nodes, Kubernetes services can be exposed on those externalIPs. Traffic that ingresses into the cluster with the external IP (as destination IP), on the service port, will be routed to one of the service endpoints. externalIPs are not managed by Kubernetes and are the responsibility of the cluster administrator.
In the ServiceSpec, externalIPs can be specified along with any of the ServiceTypes.
For LoadBalancer
service type loadBalancerIP
can be specified instead:
Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.
On cloud providers which support external load balancers, setting the type field to LoadBalancer will provision a load balancer for your Service. The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer will be published in the Service
’s .status.loadBalancer
field.
Traffic from the external load balancer will be directed at the backend Pods, though exactly how that works depends on the cloud provider. Some cloud providers allow the loadBalancerIP
to be specified. In those cases, the load-balancer will be created with the user-specified loadBalancerIP
. If the loadBalancerIP
field is not specified, an ephemeral IP will be assigned to the loadBalancer. If the loadBalancerIP
is specified, but the cloud provider does not support the feature, the field will be ignored.
Special notes for Azure: To use user-specified public type loadBalancerIP
, a static type public IP address resource needs to be created first, and it should be in the same resource group of the other automatically created resources of the cluster.
Interaction with the cloud is realizing by Cloud controller. You can find the list of supported cloud providers on the Cloud Providers page.
For cloud controller managers not in Kubernetes core, you can find the respective projects in repos maintained by cloud vendors or sig leads.
As of v1.8, cloud controller manager can implement:
- node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
- service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
- route controller - responsible for setting up network routes on your cloud
- persistent volume labels controller - responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.
- any other features you would like to implement if you are running an out-of-tree provider.