Kubernetes loadBalancerClass Multi-Controller Routing Prompt
Run multiple LoadBalancer implementations (cloud LB, MetalLB, a hardware controller) in one cluster by routing each Service to the right provider with spec.loadBalancerClass.
- Target user
- Platform engineers with hybrid or multi-LB clusters
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer running more than one LoadBalancer implementation in a single cluster, and you need each Service of type LoadBalancer to be claimed by exactly the right one. I want a `loadBalancerClass` routing design. I will provide: - The LB providers in play (cloud provider LB, MetalLB, a bare-metal/hardware controller, an internal vs external split) - Which workloads should use which provider - Symptoms (two controllers fighting over a Service, or a Service stuck Pending) Your job: 1. **Explain the mechanism**: `spec.loadBalancerClass` on a type=LoadBalancer Service names which controller owns it. A controller is expected to reconcile only Services whose class it recognizes; a Service with NO class is handled by the default/legacy provider, which is exactly where conflicts start. 2. **Map providers to class strings** (e.g. `service.k8s.aws/nlb`, `metallb.universe.tf/metallb`, or a custom `example.com/internal`) and note that the value is immutable after creation — changing provider means recreating the Service. 3. **Diagnose the conflict**: when two controllers both claim class-less Services, show how to identify which is reconciling via events and the `status.loadBalancer` ownership, and fix by assigning explicit classes. 4. **Handle the default**: how to make new Services safe — admission policy or a mutating default that stamps a class so nothing is left ambiguous. 5. **Internal vs external split**: show two classes (or a class plus provider-specific annotations) routing some Services to an internal LB and others to a public one. 6. **Produce the annotated Service manifests** per workload group and a verification step (the Service gets an external IP from the intended provider). 7. **Mark DESTRUCTIVE** the Service recreation needed to change class, since it drops the existing external IP/connections. Output format: mechanism explanation, provider→class table, the per-group Service YAML, and verification commands. Do not apply — give me commands to inspect ownership first. --- LB providers: [DESCRIBE] Workload-to-provider mapping: [DESCRIBE] Symptoms: [DESCRIBE]
Why this prompt works
The moment a cluster has more than one LoadBalancer implementation — a cloud LB for public traffic and MetalLB for bare-metal internal, say — Services without an explicit owner become a battleground. Two controllers both try to reconcile the same class-less Service, fight over status.loadBalancer, and you get flapping IPs or a Service stuck Pending. spec.loadBalancerClass is the field that resolves this, but it’s recent enough that most operators have never set it and don’t realize it’s immutable once written.
This prompt works because it treats the problem as an ownership-routing problem rather than a single-controller config problem. It maps each provider to its class string, makes the class-less default explicit as the root of most conflicts, and pushes for a stamping mechanism so no future Service is left ambiguous. The internal-versus-external split is the practical payoff: two classes cleanly route some traffic public and some private without annotation guesswork.
The immutability warning is the load-bearing safety note — changing a Service’s class means recreating it and dropping its external IP, so the prompt marks that DESTRUCTIVE and has you inspect current ownership before touching anything. The AI produces the manifests and the verification commands; you confirm each Service gets its IP from the intended provider. More Service-routing patterns are in the Kubernetes & Helm guides and the prompt library.
Related prompts
-
Kubernetes LoadBalancer / NodePort Service Debug Prompt
Diagnose LoadBalancer service issues — stuck Pending, externalTrafficPolicy: Local pitfalls, source IP preservation, cloud provider quirks, NodePort range collisions.
-
Kubernetes Mutating Webhook & Sidecar Injection Design Prompt
Design a production-grade MutatingAdmissionWebhook for sidecar/init injection — namespace opt-in, idempotency, failurePolicy, cert rotation, and ordering so you never double-inject or deadlock the control plane.
-
Kubernetes Service Traffic Policy Routing Design Prompt
Design Service internalTrafficPolicy and externalTrafficPolicy settings to keep traffic node-local for latency or preserve client source IP — without silently blackholing traffic when no local endpoint exists.