DerDokumentation von MetalLBbesagt, dass:
Im Layer-2-Modus geht der gesamte Datenverkehr für eine Service-IP an einen Knoten.
Meines Wissens liegt dies vor allem daran, dass:
Ein Knoten übernimmt die Verantwortung für die Bekanntgabe eines Dienstes im lokalen Netzwerk.
Wie im Rest der Dokumentation erwähnt, stellt dieses Verhalten eine erhebliche Einschränkung dar. Die Verkehrsbandbreite ist auf das beschränkt, was durch den gewählten Knoten fließen kann. Aber liegt es an ARP, wie in der Dokumentation behauptet wird?
Eine Lösung, die ich mir vorstellen könnte, um diese Einschränkung zu beseitigen, besteht darin, einen „Lautsprecher“ pro Knoten zu haben. Wenn ein neuer Satz von Pods und Diensten bereitgestellt wird, ist der Lautsprecher, der auf dem Knoten ausgeführt wird, der den neuen Knoten betreibt, für die ARP-Ankündigung verantwortlich. Auf diese Weise nimmt der eingehende Datenverkehr immer die optimale Route. Ist das technisch machbar?
Antwort1
MetalLB hat recht. Das Spielen von Level-2-Adressierungsspielen bedeutet, dass nur ein Host gleichzeitig Unicast-Verkehr empfangen kann. Pro Serviceadresse.
Angenommen 2001:db8:c0ba:4816::a, die Serviceadresse ist und zeigt derzeit auf eine Netzwerkkarte bei Ethernet 6E:17:C2:2E:F4:A4. Ein Fehler in diesem Host löst ein Failover aus. Es findet eine Nachbarerkennung statt und jetzt zeigt sie auf einen anderen Host mit 6E:17:C2:2E:E7:B8. Es besteht keine Möglichkeit für Multipathing, das HA-Protokoll und die Unicast-Arbeitslast sind dafür zu einfach. Natürlich könnten mehr Serviceadressen vorhanden sein, also 2001:db8:c0ba:4816::bkönnten sie zu einem anderen, möglicherweise ungenutzten Host führen.
Benutzer von VRRP- oder PowerHA-Clustern werden mit solchen Aktiv-/Passiv-Setups vertraut sein. Außer dass MetalLB aus irgendeinem Grund ihr eigenes Ding neu implementiert hat.
Der MetalLB-BGP-Modus ist anders, Layer-3-Routing. Dadurch ist ECMP möglich, wenn mehrere nächste Hops für die Service-Adressroute installiert sind. Vergleichen Sie mit Designs fürGroße mehrschichtige Lastenausgleichsmodule mit ECMP.
Ein aktiver Host pro Service-IP ist je nach Design möglicherweise kein Problem. Hosts können recht groß skaliert werden, beispielsweise mit 25-GB-Verbindungen. Bei Bedarf kann die eigentliche Arbeit auf andere Hosts verschoben werden, sodass nur ein Proxy zum Beenden der Front-End-Verbindungen übrig bleibt.