Many small TCP/UDP Services
A cluster exposes many small services, each needing a stable external L4 endpoint. Paying for one cloud load balancer per Service becomes wasteful.
Active / controller
svc-lb-mux
Service LoadBalancer Multiplexer
Expose many L4 Services without paying for one cloud load balancer each.
svc-lb-mux is for platform and operations teams that need to expose many TCP/UDP services, but do not want every
application-facing LoadBalancer Service to create another provider L4 load balancer, IP, forwarding rule,
and recurring cost line.
1 muxcan front many compatible LoadBalancer Services
100 portsGKE-oriented cap per mux with default chart values
Native APIcontrol-plane only; no extra data-plane hop
Use it when
The problem is not ingress. It is too many L4 load balancers.
This is a narrow tool by design. It is useful when the workload really needs provider Layer 4 exposure and the cluster has many small services, many public ports, or a provider quota/cost ceiling that appears before the application does.
Quota-constrained clusters
Forwarding rules, IP addresses, load balancers, or provider-specific port limits become the bottleneck before the workload itself does.
Service workflow must stay familiar
Application teams still create normal LoadBalancer Services. The mux handles shared provider exposure behind that Kubernetes-native API.
How it works
Mux owns the provider edge. Channels stay the app-facing API.
A mux Service is the single provider-facing LoadBalancer. Channel Services remain normal Kubernetes Services,
but their spec.loadBalancerClass points at the mux instead of asking the cloud provider for another LB.
Clients
Provider L4 LB
Mux Service
selectorless LoadBalancercontroller-owned ports
Channel A
Channel B
Pods A
Pods B
controller syncs mux ports, endpoints, and status.loadBalancer.ingress
Provider reality
Cloud L4 behavior matters. The page should say so.
svc-lb-mux deliberately stays inside provider-managed Service LoadBalancer behavior. That keeps the normal path Kubernetes-native, but provider limits still define the safe operating envelope.
GKEActively validated
Defaults target external passthrough Network Load Balancers. One mux is capped at 100 Service ports to stay inside GKE-native behavior.
EKSSupported guide
AWS NLB setup is documented. Provider-specific validation should still be repeated in the target environment.
Other providersExperimental
The core model is Kubernetes-native, but cloud load balancer behavior, limits, and port handling vary by provider.
Current focus
Useful today for compatible workloads, still being hardened across providers.
The controller is intentionally small. Follow-up work is focused on larger backend state, repeatable provider validation, GitOps hardening, and better operator diagnostics.
EndpointSlice support for larger channel sets and clearer backend state.
Provider validation reports for GKE, EKS, and additional Kubernetes environments.
Debug UI rewrite with safer auth, modular diagnostics, and operator-focused topology views.