2 ms·

That's just not true, especially if you compare it to the LoadBalancer you get on a cloud platform which usually involves zero clicks. I'm not saying it's impos

by dewey 4y ago

That's just not true, especially if you compare it to the LoadBalancer you get on a cloud platform which usually involves zero clicks. I'm not saying it's impossible but it's definitely not "easy". Configuration instructions: https://metallb.universe.tf/configuration/ https://metallb.universe.tf/configuration/ Hint: You better know what all of these are in your environment: For a basic configuration featuring one BGP router and one IP address range, you need 4 pieces of information: The router IP address that MetalLB should connect to, The router’s AS number, The AS number MetalLB should use, An IP address range expressed as a CIDR prefix.

icedchai 4y ago
Did you miss the part about layer 2 configuration, where you don't need BGP at all? https://metallb.universe.tf/configuration/#layer-2-configuration https://metallb.universe.tf/configuration/#layer-2-configura...
- jsmith45 4y ago
  But then "When announcing in layer2 mode, one node in your cluster will attract traffic for the service IP." This bottlenecking seems undesirable. At the very least, if you have one "main" traffic heavy service whichever node ends up servicing that IP address could have elevated cpu usage from processing all the network traffic via kube-proxy. The obvious solution would be to allocate say 2 or more so ip addresses for the service with dns round robin set up. Then as long as all three are being handled by different nodes you are not bottlenecking nearly as badly. But perhaps I am missing it, but I'm not seeing a feature where you can force those two or more ip addresses to be claimed by different nodes. (If the feature is strict, then you would want more data plane nodes than IPs, so that having one node down will result in having part of the Round robin DNS unclaimed by any node).
  - icedchai 4y ago
    True. If you want true load balancing, you need a layer 3 solution (BGP.)

by dewey 4y ago

icedchai 4y ago

Did you miss the part about layer 2 configuration, where you don't need BGP at all? https://metallb.universe.tf/configuration/#layer-2-configuration https://metallb.universe.tf/configuration/#layer-2-configura...

jsmith45 4y ago
But then "When announcing in layer2 mode, one node in your cluster will attract traffic for the service IP." This bottlenecking seems undesirable. At the very least, if you have one "main" traffic heavy service whichever node ends up servicing that IP address could have elevated cpu usage from processing all the network traffic via kube-proxy. The obvious solution would be to allocate say 2 or more so ip addresses for the service with dns round robin set up. Then as long as all three are being handled by different nodes you are not bottlenecking nearly as badly. But perhaps I am missing it, but I'm not seeing a feature where you can force those two or more ip addresses to be claimed by different nodes. (If the feature is strict, then you would want more data plane nodes than IPs, so that having one node down will result in having part of the Round robin DNS unclaimed by any node).
- icedchai 4y ago
  True. If you want true load balancing, you need a layer 3 solution (BGP.)