Kubernetes LoadBalancer Service Behavior

Kubernetes LoadBalancer Service Behavior refers to the precise mechanics of how a LoadBalancer-type Service provisions and integrates with an external cloud load balancer, extending NodePort behavior with an additional, cloud-managed layer that presents a single stable external address rather than requiring clients to target individual node IPs. This type's behavior depends heavily on the underlying cloud provider integration, since Kubernetes itself does not implement the load balancer — it delegates provisioning to a cloud controller.

Provisioning Behavior

Delegation to the Cloud Controller Manager

Creating a LoadBalancer Service does not itself create a load balancer; it triggers the cloud controller manager (or an equivalent controller in non-cloud environments) to call the underlying cloud provider's API and provision an actual load balancer resource, a process that is asynchronous and can take anywhere from seconds to several minutes depending on the provider.

apiVersion: v1
kind: Service
metadata:
  name: ledger-api-public
spec:
  type: LoadBalancer
  selector:
    app: ledger-api
  ports:
    - port: 443
      targetPort: 8443

Status Reflects Provisioning Progress

While provisioning is in progress, the Service's status.loadBalancer.ingress field remains empty; once the cloud load balancer is ready, the controller populates this field with the allocated external IP or hostname, which is the signal that the Service has become externally reachable.

kubectl get service ledger-api-public -o jsonpath='{.status.loadBalancer.ingress}'

Traffic Path Behavior

External Load Balancer as the True Entry Point

Once provisioned, all external traffic first reaches the cloud provider's load balancer, which then forwards it into the cluster, typically by targeting either the NodePort opened by the Service (since a LoadBalancer Service is built as a superset of NodePort behavior) or, in providers supporting it, directly to pod IPs bypassing the NodePort layer entirely.

Behavior With externalTrafficPolicy

Just as with NodePort, the externalTrafficPolicy field governs whether the load balancer's traffic, once inside the cluster, is spread across any node (Cluster, potentially obscuring client source IP) or only forwarded to nodes hosting a ready backing pod (Local, preserving source IP but requiring the cloud load balancer to health-check individual nodes).

spec:
  type: LoadBalancer
  externalTrafficPolicy: Local

Provider-Specific Configuration Behavior

Annotation-Driven Customization

Because the base LoadBalancer spec is provider-agnostic, provider-specific behavior — such as choosing between a classic, network, or application load balancer, enabling TLS termination at the load balancer, or attaching a specific subnet — is configured through provider-recognized annotations rather than native spec fields, meaning the same Service manifest often cannot be moved unmodified between cloud providers.

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:...:certificate/abc123"

Static IP Reservation Behavior

Some providers allow a pre-reserved static IP to be requested for a LoadBalancer Service via loadBalancerIP or a provider-specific annotation, which changes the provisioning behavior from allocating a new ephemeral address to attaching the Service to an address that persists independently of the Service object's own lifecycle, useful when an external DNS record must point at a fixed address.

Deletion and Cleanup Behavior

Deprovisioning on Service Deletion

Deleting a LoadBalancer Service triggers the cloud controller to deprovision the associated external load balancer resource, but this deprovisioning is also asynchronous, and a load balancer can occasionally be left behind if the deletion call fails silently or if the Service is deleted while the controller managing it is unavailable, which is why periodic reconciliation audits against the cloud provider's own resource inventory are a standard operational safeguard.

kubectl delete service ledger-api-public

Behavior During Cluster or Controller Outage

If the cloud controller manager is unavailable when a LoadBalancer Service is created or deleted, the Service object still exists in the Kubernetes API with a pending or stale status, but the corresponding external infrastructure change does not occur until the controller resumes and reconciles the backlog, meaning Service object state and actual cloud infrastructure state can diverge temporarily.

Health Checking Behavior

External Health Checks Independent of Kubernetes Probes

Cloud load balancers typically perform their own external health checks against nodes or backend targets, configured separately from the Kubernetes-native readiness probes on the pods themselves, meaning a pod can be marked ready by Kubernetes while still failing the load balancer's own external check, or vice versa, if the two health check configurations are not kept aligned.