LoadBalancer — the cloud-managed external endpoint

A LoadBalancer Service allocates a cloud-provider load balancer. The external client connects to the load balancer’s IP; the load balancer forwards to the Service ClusterIP via the NodePort; the kube-proxy forwards to a Pod. The LoadBalancer is the production choice for non-HTTP traffic. This lesson walks the mechanism, the cost, the failure modes, and the operational discipline.

The LoadBalancer manifest

apiVersion: v1
kind: Service
metadata:
  name: billing
spec:
  type: LoadBalancer
  selector:
    app: billing
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

The Service’s loadBalancerClass field can specify a particular cloud provider’s implementation. The default is the cloud provider’s default.

The traffic flow

The traffic flow:

sequenceDiagram
    autonumber
    participant EC as External client
    participant LB as Cloud LB
    participant N as Node IP:NodePort
    participant KP as kube-proxy
    participant P as Pod
    EC->>LB: TCP <lb-ip>:80
    LB->>N: forward to <node-ip>:<node-port>
    N->>KP: kube-proxy DNAT to ClusterIP
    KP->>P: DNAT to Pod IP:8080
    P->>P: handle request
    P->>KP: response
    KP->>N: response
    N->>LB: response
    LB->>EC: response

The cloud load balancer is the external endpoint. The load balancer forwards to a node’s NodePort; the kube-proxy on the node DNATs to the Service ClusterIP; the kube-proxy DNATs to a Pod.

The cloud provider integration

The cloud provider’s controller-manager watches the Service of type LoadBalancer and allocates a load balancer. The integration is per-provider:

• AWS: AWS Cloud Provider integration allocates an ELB or NLB.
• GCP: GCP Cloud Provider integration allocates a Network Load Balancer.
• Azure: Azure Cloud Provider integration allocates a Load Balancer.
• Bare-metal: MetalLB or similar projects allocate a virtual IP on the local network.

The cluster operator must verify the integration. The cloud provider’s documentation is the source of truth.

The cost

The LoadBalancer Service has a per-Service cost. The cloud provider’s pricing varies:

• AWS: NLB is $0.0225/hour; ELB is $0.0225/hour. 100 LoadBalancer Services ~= $225/month.
• GCP: ~$0.025/hour per forwarding rule.
• Azure: ~$0.025/hour per load balancer.

The cost is significant for clusters with many external services. The cluster operator must monitor the cost and migrate HTTP traffic to Ingress.

The annotations

The LoadBalancer supports annotations for cloud- specific configuration:

apiVersion: v1
kind: Service
metadata:
  name: billing
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  selector:
    app: billing
  ports:
    - port: 80
      targetPort: 8080

The annotations tell the cloud provider how to configure the load balancer. The cluster operator must consult the cloud provider’s documentation for the ed annotations.

The status

The Service’s status has the load balancer’s IP:

kubectl get svc billing -o jsonpath='{.status.loadBalancer.ingress}'

[{"ip": "1.2.3.4"}]

The IP is the cloud load balancer’s IP. The cluster operator can verify the load balancer is configured correctly.

The failure modes

The LoadBalancer’s failure modes:

• Cloud provider failure: the cloud provider’s load balancer is unavailable. The external traffic is lost.
• Quota exceeded: the cloud provider’s quota for load balancers is exhausted. The Service stays pending.
• Cost: the cloud provider’s load balancer is expensive. The cost is per-Service.
• No TLS: the LoadBalancer is unencrypted. The external traffic is in plaintext.
• Slow reconciliation: the cloud provider’s controller can take minutes to allocate the load balancer.
• Misconfigured annotations: the annotations produce a wrong configuration. The fix is to consult the cloud provider’s documentation.

The operational discipline

The LoadBalancer’s operational discipline:

• Use LoadBalancer for non-HTTP traffic. The production choice for HTTP is Ingress.
• Monitor the cloud provider’s billing. The cost is per-Service; the cluster operator must track the cost.
• Audit the LoadBalancer usage. The cluster operator must enumerate every LoadBalancer Service.
• Migrate HTTP traffic to Ingress. The Ingress is the production choice for HTTP traffic.
• Document the LoadBalancer’s annotations. The annotations are cloud-specific.
• Test the LoadBalancer at every release. The annotations are a security-relevant change.

Quiz

Production discipline

• Use LoadBalancer for non-HTTP traffic. The production choice for HTTP is Ingress.
• The cost is per-Service. The cluster operator must monitor the cost.
• Audit the LoadBalancer usage. The cluster operator must enumerate every LoadBalancer Service.
• Migrate HTTP traffic to Ingress. The Ingress is the production choice for HTTP traffic.
• Document the LoadBalancer’s annotations. The annotations are cloud-specific.
• Test the LoadBalancer at every release. The annotations are a security-relevant change.
• Monitor the cloud provider’s billing. The cost is per-Service; the cluster operator must track the cost.
• Plan the cluster’s HA. The LoadBalancer is a cloud-managed resource; the cluster operator must understand the cloud provider’s SLAs.
• Document the LoadBalancer’s design. The LoadBalancer is the cluster’s external endpoint; the documentation is the reference.