K3s: PROPOSAL: Separate servicelb into it's own project/controller

[toonsevrin]

Coming from k3s and moving into the cloud, I really like servicelb and would like to continue to use it (instead of expensive cloud lbs). This is a proposal to allow us to install servicelb as a k8s deployment that listens to LoadBalancer services.

[brandond]

I don't believe it's meant for large-scale deployment, since it requires that you have a node with the desired port available. Have 10 services you want to expose on port 443? You'll need at least 10 nodes. It also doesn't support any sort of HA, since it's exposed through a single port on a single node.

As an alternative, you might look at metallb?

[toonsevrin]

Hi Brandon, this layout has actually worked out for all our clusters. We do this with a DaemonSet proxy (that uses hostPorts). The reason for this is because we use an Ingress proxy that routes according to the http host (subdomain).

To address your other concern: Exposing 10 services on port 443, should not be possible by default (except if you segment your nodes but that's a little to advanced if you ask me), use a proxy router.

HA: I'd consider this relatively HA. As long as downtime is expected, you can pull the node (automatically) from your DNS set. Of course as with any DNS load balancing: if your node stops unexpectedly, your clients will have to hit the TTL first. We use cloudflare which addresses this (they provide yet another proxy layer).

Anyways, our indeed has a few extras to make everything really nice (eg. when we scale down an api request is send to our DNS to remove the IP, we also do healthchecking to make sure that our dns is always up to date and our dns actually terminates traffic so that dns updates are pretty much instant).

But the thing is, with this setup, if you care a little less about HA, this is all not necessary. Put your single ingress service as type NodePort and you are good to go. In my opinion this is still perfect for most production deployments.