Load Balancer Lifecycle¶
How the DO Load Balancer is created, scaled, monitored, and deleted — all through the Service, never the DO LB API directly.
§34.1 How DO LB Connects to Envoy Gateway¶
When Envoy Gateway is installed, it creates a Kubernetes Service of type LoadBalancer. The DO Cloud Controller Manager (CCM) sees this Service and auto-provisions a DO Load Balancer. The DO LB forwards TCP traffic to worker nodes, and Cilium (kube-proxy replacement on DOKS) routes to Envoy Gateway pods.
§34.2 Starbase Controls, Shuttle Applies¶
Starbase never calls the DO LB API directly. The DO CCM reconciliation loop would revert direct API changes. Instead:
| Action | How |
|---|---|
| Create | Envoy Gateway Helm install creates the Service → CCM provisions LB |
| Scale | Starbase puts lb_size_units in desired state → Shuttle patches Service annotation do-loadbalancer-size-unit → CCM resizes LB |
| Monitor | Starbase reads LB metrics via DO API (read-only, safe) |
| Delete | Starbase deletes cluster → all Services deleted → CCM deletes LB |
§34.3 Why This Way¶
The DO CCM "owns" the LB-to-Service mapping. Fighting it (creating LBs via API, then adopting) adds complexity. Letting the Service control the LB, and controlling the Service via desired state, is the path of least resistance. It also fits the "Starbase decides, Shuttle applies" principle.
Cross-references
The Gateway whose Service provisions this LB → §33 · the full traffic path through the LB → §5 · the desired-state principle this follows → §32. Canonical map: Canonical Sources.