Eliminieren von Ebenen beim Skalieren von Apps in Containern mithilfe von F5 BIG-IP
Oder sind das „Tränen“ der Frustration? ¯\_(ツ)_/¯ Vielleicht ist es beides.
Es besteht eine Beziehung zwischen Netzwerk- und Anwendungsarchitekturen. Normalerweise sprechen wir gerne darüber, wie sich Änderungen und Verschiebungen in Anwendungsarchitekturen auf das Netzwerk auswirken – sowohl in Bezug auf die Lösungen als auch auf deren Architektur. Aber auch das Gegenteil ist der Fall: Die Architektur und das Verhalten des Netzwerks können ziemlich dramatische Auswirkungen auf Anwendungen und deren Architektur haben.
Einer der Gründe, warum wir heute eine Zerlegung von Monolithen in zahlreiche Microservices erleben und dies noch nicht während der SOA-Jahre geschah, ist das Netzwerk. Oder genauer gesagt: wegen der Geschwindigkeit des Netzes. Damals, zu Zeiten von SOA, gab es durch die Natur der Vernetzung (und die Gesetze der Physik) bedingte Einschränkungen, die das Verfassen einer einzigen Antwort aus mehr als drei oder vier Diensten unmöglich machten. Okay, nicht unmöglich, aber aufgrund der bei jedem Anruf auftretenden Latenz unerwünscht.
Heute verfügen wir über schnellere, leistungsfähigere Netzwerke und eine um ein Vielfaches schnellere Rechenleistung, die diese Zerlegung möglich macht. Noch einfacher wird es durch die Art der Container, die so oft mit Microservices gepaart werden, wie etwa Kaffee mit Donuts. Da „das Netzwerk“ zwischen zwei Diensten, die kommunizieren müssen, häufig eine virtuelle Konstruktion ist (Pakete verlassen den Hostserver nie wirklich und unterliegen daher nicht der Latenz, die beim „Übertragen auf die Leitung“ entsteht), ist die Anzahl der Dienste, die zum Antworten auf eine einzelne Anfrage aufgerufen werden können, viel höher, als wir in Zeiten von SOA vernünftigerweise erreichen konnten.
Das bedeutet allerdings nicht, dass wir die Anzahl der Verbindungen und Hops, die wir durchlaufen müssen, um auf eine Anfrage zu antworten, oder den Einfluss der Architektur auf die Anwendungsleistung ignorieren sollten. Denn auch wenn die Berechnung schneller und die Leitungen dicker sind, müssen wir uns immer noch mit dem Betriebsaufwand auseinandersetzen. Eine Sache, die die Leistung immer noch beeinträchtigt. Eine der einfachsten Möglichkeiten, den Betriebsaufwand zu bewältigen (und die Leistung zu verbessern), besteht darin, die Komplexität durch die Beseitigung (unnötiger) Ebenen in einer Architektur zu reduzieren.
Reduzierung der Komplexität von Containerumgebungen
Die meisten Containerbereitstellungen verwenden eine Art Lastenausgleich innerhalb des Clusters, um die Skalierung der Microservices/Apps innerhalb der Containerumgebung zu verwalten. Das liegt daran, dass sie häufig mit dem L7-Routing von APIs (also der Eingangskontrolle) beauftragt werden und native Lastenausgleichskonstrukte auf iptables basieren, das natürlich kein HTTP spricht – die Sprache des L7-Routings. Es gibt also eine Reihe von L7-Load Balancern im Cluster-Container.
Heutzutage ist bei den meisten Bereitstellungen auch ein Lastenausgleich außerhalb des Clusters erforderlich, um den externen Datenverkehr an den richtigen Lastenausgleich innerhalb des Clusters weiterzuleiten. Dazu verwenden sie die herkömmliche Lastverteilung, um die Anforderungen an den richtigen internen Lastenausgleich zu verteilen.
Den Load Balancer außerhalb von BIG-IP nennen wir „internen lb“ und den innerhalb des Clusters „ internen lb“ . Weil es mein Blog ist, deshalb.
Das Problem besteht darin, dass die Anzahl der internen lb -Instanzen (manchmal dramatisch) schwankt. Jedes Mal, wenn es eine Änderung gibt, muss der BIG-IP darüber informiert werden. Traditionell war dies ein manueller Vorgang, der erforderte, dass der BIG-IP-Eigentümer den Pool manuell änderte. Das ist frustrierend für Entwickler und DevOps und mühsam für NetOps. Mit anderen Worten: Niemand möchte es auf diese Weise machen.
Aus diesem Grund gibt es Lösungen wie den F5 Container Connector . F5 Container Connector ist ein Container-nativer Dienst, der sich in den Container-Orchestrator integrieren lässt und die Umgebung beobachtet. Wenn es eine Änderung gibt, die sich auf ein internes lb auswirkt, wird ein Prozess zum Aktualisieren von BIG-IP ausgelöst . Dies bedeutet, dass BIG-IP bei schwankender Nachfrage automatisch auf dem neuesten Stand gehalten wird und Anfragen entsprechend an ein aktives, gesundes internes LB verteilen kann. Keine manuelle Änderung notwendig.
Diese zweistufige Skalierungsarchitektur hat den Vorteil, dass sie einen geeigneten Eingangsstandort (die BIG-IP) bereitstellt, an dem SSL/TLS beendet werden kann, was zu messbaren Leistungsverbesserungen führt. Hübsch.
Aber warum hier aufhören? BIG-IP kann L7-Routing bereitstellen. Wenn Sie die Dienste von F5 Container Connector nutzen, können Sie durch die vollständige Beseitigung des internen Aufwands weitere Leistungssteigerungen (und einen geringeren Betriebsaufwand) erzielen. Wirklich. BIG-IP kann als Ingress-Controller für Kubernetes und Red Hat OpenShift fungieren.
Indem Sie die Verantwortung für den Dateneingang auf BIG-IP übertragen, eliminieren Sie eine ganze Skalierungsebene (das interne Pfund), was die Leistung sofort verbessert. Da es sich bei dem externen Containercluster um ein F5 BIG-IP handelt, können Sie darüber hinaus sicherheitsorientierte Anwendungsdienste wie ein erweitertes WAF mit Bot-Abwehr am Kontaktpunkt und nicht innerhalb des Containerclusters (oder gar nicht) bereitstellen.
Clash of Ops-Clans
Da Container immer häufiger in die Produktion gelangen (und das wird passieren), ist eine verstärkte Zusammenarbeit zwischen DevOps und NetOps erforderlich, um diese Art von Verbesserungen zu implementieren und die Skalierbarkeit, Geschwindigkeit und Sicherheit von Apps zu gewährleisten. Schließlich geht es nicht nur um das Drücken von Schaltflächen und Self-Service-Pipelines. Die Architektur ist eine kritische Komponente, die unter Einbeziehung der Eingaben von DevOps und NetOps entwickelt werden muss, damit wir Möglichkeiten zur Verbesserung von Dingen wie der Anwendungsleistung nicht verpassen.
Denn Anwendungsleistung ist ein Mannschaftssport. Es wird durch den Code (AppDev), durch die Plattform, auf der der Code bereitgestellt wird (DevOps), durch die Netzwerkarchitektur und durch die Anwendungsdienste beeinflusst, die zum Sichern und Skalieren der App verwendet werden (NetOps). Eine Architekturoptimierung durch die Beseitigung von Ebenen, wenn möglich, ist aus betrieblicher und geschäftlicher Sicht sinnvoll. Allerdings ist dazu die Beteiligung aller Spieler im Team erforderlich.
Bestellen Sie also Pizza und Bier, bringen Sie DevOps und NetOps zusammen und beginnen Sie zu reden. Finden Sie heraus, ob auch Sie die Leistung von Apps verbessern können, indem Sie unnötige Ebenen in Ihrer Containerumgebung entfernen.