Load balancing distributes incoming work across multiple application instances. In Kubernetes, a Service distributes requests among the pods backing it. This lets an application use additional replicas without making clients choose a pod themselves. section 1.2.1 section 3.3.3
See requests reach different pods
Run `kubectl scale deployment kiada --replicas=3`, then check `kubectl get deploy` for three ready replicas. Send several requests to the Service URL. The responses identify different pod names, in no fixed order. The application must still support horizontal scaling; Kubernetes can replicate it, but cannot make it scalable. section 3.3.3
Do not confuse the Service’s internal load balancing with an external load balancer. A Service gives the pods one stable cluster IP and distributes traffic among them. A Service of type `LoadBalancer` additionally asks supported infrastructure for a load balancer that clients can reach externally. That load balancer forwards connections to healthy nodes; the Service distributes the resulting traffic among pods. section 3.4 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
This Service manifest sets `type: LoadBalancer` while retaining a pod selector and port mappings. Apply it, then inspect the Service’s external IP with `kubectl get svc kiada`. section 11.2.2
A `LoadBalancer` Service depends on cluster support. Cloud clusters commonly provide it; an on-premises cluster may need an add-on. Without support, the Service can still be created but is accessible only through its node ports. For HTTP traffic routed to backend services through an Ingress, a separate L7 load balancer or reverse proxy performs the routing. section 11.2.2 section 12.1
