LoadBalancer Deep Dive

Understand how Kubernetes LoadBalancer services provision real infrastructure, how cloud-specific annotations shape that infrastructure, and how to template everything cleanly in Helm.

Learning Objectives

• Explain the cloud controller manager loop that provisions external load balancers
• Use cloud-specific annotations for AWS NLB/CLB, GCP, and Azure
• Deploy MetalLB for bare-metal / on-premises clusters
• Configure health checks, session affinity, and externalTrafficPolicy
• Template LB annotations per provider from values.yaml
• Weigh cost trade-offs: one LB per service vs shared ingress

How LoadBalancer Services Work

When you create a Service of type LoadBalancer, the cloud controller manager detects the new object and calls the cloud provider API to provision a real load balancer (AWS ELB, GCP forwarding rule, Azure LB, etc.).

The Reconciliation Loop

1. User creates a Service with type: LoadBalancer
2. Cloud controller watches for Service events, calls cloud API
3. Cloud provisions an external LB with a public or internal IP
4. The controller writes the IP back into status.loadBalancer.ingress
5. Traffic flows: Client → Cloud LB → NodePort → Pod

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: my-app

Cloud-Specific Annotations

Each cloud provider uses annotations on the Service to customize the load balancer it provisions.

metadata:
  annotations:
    # NLB instead of Classic LB
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    # Instance vs IP targets
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    # Internal-only
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
    # Health check
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "HTTP"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/healthz"

# GCP — internal LB
metadata:
  annotations:
    networking.gke.io/load-balancer-type: "Internal"

# Azure — internal LB
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz"

MetalLB for On-Premises

No cloud controller in bare-metal clusters means type: LoadBalancer stays in Pending forever. MetalLB fills that gap with two modes: L2 (ARP/NDP) and BGP.

# IPAddressPool — defines which IPs MetalLB can hand out
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.200-192.168.1.250
---
# L2Advertisement — announce IPs via ARP
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-advert
  namespace: metallb-system
spec:
  ipAddressPools:
    - production-pool

externalTrafficPolicy & Session Affinity

Two critical Service fields control how traffic reaches pods and whether client identity is preserved.

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

Static vs Dynamic IP & Health Checks

IP Allocation

• Dynamic (default): Cloud assigns a new IP each time the LB is recreated. DNS must be updated.
• Static: Pre-allocate an IP (Elastic IP on AWS, static IP on GCP) and pin it to the Service with spec.loadBalancerIP or provider annotations.

spec:
  type: LoadBalancer
  loadBalancerIP: 35.200.10.50   # pre-allocated static IP
  ports:
    - port: 443
      targetPort: 8443

Health Check Configuration

Cloud LBs perform their own health checks (separate from liveness/readiness probes). Configure via annotations:

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "10"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
    service.beta.kubernetes.io/aws-load-balancer-healthy-threshold: "2"
    service.beta.kubernetes.io/aws-load-balancer-unhealthy-threshold: "3"

Templating LB Annotations in Helm

Real charts must work across AWS, GCP, Azure, and bare-metal. Template annotations conditionally from values.yaml.

# values.yaml
service:
  type: LoadBalancer
  annotations: {}
  # Override per cloud:
  # annotations:
  #   service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
  #   service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "mychart.fullname" . }}
  {{- with .Values.service.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  type: {{ .Values.service.type }}
  {{- if .Values.service.loadBalancerIP }}
  loadBalancerIP: {{ .Values.service.loadBalancerIP }}
  {{- end }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
  selector:
    {{- include "mychart.selectorLabels" . | nindent 4 }}

Cost Considerations & Summary

One LB per Service vs Shared Ingress

Key Takeaways

• Cloud controller manager is the bridge between type: LoadBalancer and real infrastructure
• Annotations are the primary knob for configuring cloud LBs
• MetalLB fills the gap for on-prem with L2 and BGP modes
• externalTrafficPolicy: Local preserves source IP at the cost of even distribution
• Template annotations in Helm to keep charts cloud-agnostic