Geschwindigkeit und Maßstab: F5 BIG-IP als Ingress-Kontrolle für Kubernetes
Im Containerland herrscht ebenso viel Verwirrung wie Chaos. Jeder Tag scheint der Welt der Container-Orchestrierungsumgebungen eine neue Funktion oder Komponente hinzuzufügen. Das ist notwendig, denn die Nutzung von Containern ist noch in der Entwicklungsphase und erstreckt sich über das Experimentelle hinaus ins Existenzielle.
Geschwindigkeit und Umfang zählen zu den beiden Hauptfaktoren für die Bereitstellung von Containern. Bei Ersterem geht es sowohl um Entwicklung als auch um Lieferung und daher liegt der Fokus auf der Größenordnung. Aber es geht hier nicht nur um den Standardprotokollmaßstab, sondern um den Anwendungsmaßstab .
Die Unterscheidung ist wichtig. Container wurden als die Kategorie mit der höchsten Wahrscheinlichkeit gewählt, in der sie Microservices enthalten, und eine der Grundregeln für Microservices besteht darin, dass die Kommunikation ausschließlich über API erfolgt. Eine API, die auf HTTP – nicht TCP – basiert und daher für die Skalierung eine intelligentere Lösung erfordert.
Die meisten Container-Orchestrierungsumgebungen werden mit Proxys ausgeliefert, die eine Vanilla-Skalierung ermöglichen. Das bedeutet einfaches, altmodisches Lastenausgleich (POLB) auf der TCP-Ebene. IP-Adressen und Ports sind die Lingua Franca dieser Proxys. Während sie in einer Umgebung gut funktionieren, in der Dienste auf Grundlage einer IP-Adress-/Port-Kombination unterschieden werden, funktionieren sie nicht so gut für Anwendungen (Dienste), die durch HTTP-Schichtmerkmale – wie API-Version, URI oder Hostname – unterschieden werden. Dabei handelt es sich um Konstrukte auf Anwendungsebene (HTTP) , die intelligentere Proxys erfordern, um sowohl das Routing als auch die Skalierung mit der gewünschten Geschwindigkeit zu ermöglichen. Diese Konstrukte müssen beim Empfang einer Anforderung von einer clientseitigen Entität berücksichtigt werden, was die meisten Standard-Skalierungslösungen für Container nicht bieten können.
Als Antwort auf diesen Bedarf entsteht das Konzept der Ingress*-Kontrolle. Bei Ingress Control handelt es sich im Grunde um App- oder HTTP-Routing , Layer-7-Switching, Content-Switching oder einen der etwa zwölf anderen Begriffe, unter denen diese Funktion seit der Jahrhundertwende bekannt ist. Die Ingress-Kontrolle geht von einer Dienstdifferenzierung auf der Anwendungsebene (HTTP) aus und berücksichtigt diese dementsprechend bei Routing- und Skalierungsentscheidungen innerhalb der Containerumgebung.
Aber Sie können nicht einfach eine F5 BIG-IP vor eine Containerumgebung setzen und es Ingress-Kontrolle nennen. Das liegt daran, dass ein Ingress-Controller auch in die Container-Orchestrierungsumgebung integriert werden muss, um den gewünschten Umfang und die gewünschte Geschwindigkeit zu erreichen. Dazu benötigen Sie etwas, das innerhalb der Containerumgebung lebt und Container-Orchestrierung und BIG-IP beherrscht.
Dies ist die Aufgabe des BIG-IP-Controllers für Kubernetes . Es handelt sich um einen Docker-Container, der in einem Kubernetes- Pod ausgeführt wird und es Ihnen ermöglicht, eine BIG-IP als Kubernetes-Ingress-Controller zu verwenden. Das bedeutet, dass es die Kubernetes-Ingress-Ressource lesen und BIG-IP automatisch mit den entsprechenden Objekten konfigurieren kann, um sicherzustellen, dass Anforderungen basierend auf den gewünschten App-Layer-Konstrukten skaliert werden.
Bevor dieser Controller verfügbar war, neigten die Leute dazu, BIG-IP zu verwenden, um den Datenverkehr über eine zweite Schicht von Proxys zu „verteilen“, die innerhalb der Container-Orchestrierungsumgebung ausgeführt wurden. Diese Proxys ermöglichten die Ingress-Kontrolle. Es gibt einige gute Gründe, damit aufzuhören. Dazu gehört auch der rekursive Aufwand, den Sie betreiben müssen, wenn Sie Ihren Verfügbarkeitsdienst innerhalb der Sache ausführen, für die er die Verfügbarkeit bereitstellt.
Weitere gute Gründe sind:
- DDoS-Abwehr aktivieren
- Nutzen Sie eine Web Application Firewall zum Schutz von APIs und Apps
- Unterstützen Sie IPv6-Clients bei der Verwendung von IPv4-Container-Apps.
- TLS auf BIG-IP auslagern und mit selbstsignierten Zertifikaten neu verschlüsseln
- Verwenden Sie Anwendungsbeschleunigungsoptionen, um die Leistung zu verbessern
Was auch immer der Grund sein mag, tatsächlich können Sie einen BIG-IP als Ingress-Controller für Kubernetes verwenden. Zum Skalieren sind keine zwei unterschiedlichen Ebenen erforderlich. Durch die Beseitigung dieser zweiten Skalierungsebene verbessern Sie die Geschwindigkeit (der Bereitstellung und Implementierung) und vereinfachen Implementierungen. Gleichzeitig erhalten Sie eine Plattform, auf der Sie eine große Vielfalt an erweiterten Diensten für Sicherheit, Geschwindigkeit und Skalierung aktivieren können.
Weitere Informationen zum BIG-IP-Controller für Kubernetes finden Sie hier , Sie können ihn hier vom Docker-Hub herunterladen oder ihn einfach direkt abrufen:
Docker-Pull f5networks/k8s-bigip-ctlr
Skalieren Sie.
* Ja, das große „I“ ist wichtig, da es sich vom traditionellen Netzwerkbegriff „Ingress“ unterscheidet, der sich einfach auf „Zugriff auf die Umgebung“ bezieht, während „Ingress“ für „HTTP-Routing“ verwendet wird. Ja, wir neigen dazu, die Dinge unnötig kompliziert zu machen, aber so ist die Welt, in der Entwickler Netzwerkkonstrukte implementieren und mehr als nur die Bereitstellung von Apps neu definieren.