Sure, but most cloud environments are handled by other LoadBalancer controllers specific to that environment. See: Kubernetes Cloud Controller Manager.
> MetalLB is extremely new while VIP+Nginx/HAP has been working forever and is the standard choice for implementing a HA LB.
I do not disagree with that. Hell, I've filed/fixed metallb issues myself already.
> MetalLB plays the same exact role as what the OP is laying just in a different style that has nothing to do with k8s. MetalLB could have been unicast VRRP for all it matters. The value is the code to instrument the LB from within k8s which can work with any external LB.
Sure, but the author is not describing it to act as a Kube LoadBalancer, but as a separate entity with its own configuration. So to actually then use Kubernetes meaningfully they still need to bring something that actually fulfills LoadBalancer requests. Might as well use the same code for both cases.
> In k8s load balancers are inherently external to the cluster and need to maintain their state. It doesn't really matter how this is accomplished but Pacemaker/Corosync is the "off the shelf and supported by your distro with good docs" option.
Why? You can easily keep all state and components within k8s, as MetalLB does.
> The k8s cluster needs something outside itself to route traffic to all the nodes. There isn't a way around this.
Sure, that's called BGP to a ToR that can then ECMP-route traffic where needed, and that's what metallb gives you.
I guess I should have said "its own state." I mean you can shove just about any software into a container and get k8s to run it but the point is that k8s can't load balance by itself without managing an environment specific external resource. Because I would count BGP as using the router in the same way that it would use HAProxy.
Would "load balancers are necessarily on the outside of the cluster" be better phrasing?
Which will be internally backed by exactly the kind of infra the OP is describing.
* MetalLB doesn't work in most cloud environments because the networking is weird.
* MetalLB is extremely new while VIP+Nginx/HAP has been working forever and is the standard choice for implementing a HA LB.
* MetalLB plays the same exact role as what the OP is laying just in a different style that has nothing to do with k8s. MetalLB could have been unicast VRRP for all it matters. The value is the code to instrument the LB from within k8s which can work with any external LB.
In k8s load balancers are inherently external to the cluster and need to maintain their state. It doesn't really matter how this is accomplished but Pacemaker/Corosync is the "off the shelf and supported by your distro with good docs" option.
"Why don't you just use $managed_k8s?" -- Because it defeats the purpose of learning how to administer it.
Sibebar:
Why is everybody treating k8s like it's something special and magical here and needs it's own solution? Your k8s cluster is a group of app servers with a little bit of networking sprinkle so that you can reach every app from any node and some API sprinkle to allow the app servers to instrument external resources.
The k8s cluster needs something outside itself to route traffic to all the nodes. There isn't a way around this. From an infra perspective a k8s cluster is a black box of generic app servers that want to be able to control the LB with an API integration. Nothing else.