A LoadBalancer service makes an application reachable through an external load balancer. Kubernetes creates the Service, but the cluster’s infrastructure must provide the load balancer. Once provisioned, its address appears as the Service’s EXTERNAL-IP. The Service still has an internal cluster IP. section 3.3.2 section 3.4
Expose a Deployment
Run `kubectl expose deployment kiada --type=LoadBalancer --port 8080`, then check `kubectl get svc kiada`. EXTERNAL-IP may initially show `<pending>` while provisioning takes place. When an address appears, a client can request the application at that address and port—for example, `curl 35.246.179.22:8080`. section 3.3.2
A LoadBalancer service extends NodePort: the external load balancer sends connections to a node port on a healthy node, and the Service routes them to its backing pods. Unlike a ClusterIP service, it can serve clients outside the cluster without requiring you to set up that load balancer manually. Support depends on the environment: cloud clusters commonly provide it, while on-premises clusters may need an add-on such as MetalLB. Without support, the Service can still exist but remains accessible only through its node ports. section 11.2 section 11.2.2
Listing 11.4 A LoadBalancer-type service
apiVersion: v1
kind: Service
metadata:
name: kiada
spec:
type: LoadBalancer #1
selector:
app: kiada
ports:
- name: http
port: 80
nodePort: 30080
targetPort: 8080
- name: https
port: 443
nodePort: 30443
targetPort: 8443
A Service manifest selects the application’s pods and sets `type: LoadBalancer`. Its `nodePort` values are explicit here, but they can be omitted if their exact numbers do not matter. section 11.2.2
To change an existing Service, apply an updated manifest rather than deleting and recreating it; this preserves its internal cluster IP. Where supported, additional fields can select a load-balancer class, request an IP, restrict client source ranges, or control node-port allocation. section 11.2.2
