Lastausgleich des Datenverkehrs zu Anwendungen in Kubernetes-Clustern
Kubernetes (auch bekannt als K8s), das ursprünglich von Google entwickelte Container-Orchestrierungstool, hat sich schnell zur bevorzugten Plattform für die Bereitstellung von containerisierten Anwendungen in Public und Private Clouds entwickelt.
Für die DevOps-Teams stellt K8s eine gemeinsame Plattform für die Bereitstellung ihrer Anwendungen in den verschiedenen Cloud-Umgebungen bereit, abstrahiert die Feinheiten der zugrunde liegenden Cloud-Infrastruktur und ermöglicht es ihnen, sich auf ihre Aufgaben zu konzentrieren. Für Unternehmen bedeutet dies Flexibilität bei der Bereitstellung der Anwendungen in der Cloud, die den Anforderungen der Kunden am besten entspricht, bei gleichzeitiger Optimierung der Kosten.
Diese Flexibilität, Anwendungen in jeder beliebigen Cloud bereitzustellen, bringt jedoch die Herausforderung mit sich, sie den Endnutzern auf zuverlässige und einheitliche Weise zugänglich zu machen. Wenn beispielsweise eine Anwendung von einer privaten Cloud auf public cloud (wie AWS oder Azure) verlagert wird, wie können Sie dann das gleiche Maß an Zugänglichkeit, Leistung, Zuverlässigkeit und Sicherheit wie in der privaten Cloud gewährleisten?
Um Anwendungen für Endbenutzer zugänglich zu machen, unterstützt Kubernetes die folgenden Optionen:
NodePort: In diesem Fall wird jedem Knoten ein Port zugewiesen (bekannt als NodePort), und die Endbenutzer können unter der IP-Adresse und dem Portwert des Knotens auf die Anwendung zugreifen. Bei dieser Option müssen Sie manuell einen Load Balancer konfigurieren, um den Datenverkehr auf die Knoten zu verteilen.
LoadBalancer: Wie NodePort weist auch diese Option jedem Knoten einen Port zu und stellt zusätzlich eine Verbindung zu einem externen Load Balancer her. Diese Option erfordert eine Integration mit der zugrunde liegenden Infrastruktur des Cloud-Anbieters und wird daher in der Regel mit public cloud Anbietern verwendet, die über eine solche Integration verfügen. Diese enge Integration macht jedoch den Wechsel einer Anwendung von einem Cloud-Anbieter zu einem anderen schwierig und fehleranfällig.
Ingress-Controller: K8s definiert einen Ingress Controller, der verwendet werden kann, um HTTP- und HTTPS-Verkehr an Anwendungen zu leiten, die innerhalb des Clusters laufen. Ein Ingress Controller macht jedoch einen externen Load Balancer nicht überflüssig. Wie im Falle des Load Balancers hat jeder public cloud Anbieter seinen eigenen Ingress Controller, der mit seinem eigenen Load Balancer zusammenarbeitet. Der AKS Application Gateway Ingress Controller von Azure ist zum Beispiel ein Ingress Controller, der mit dem Azure Application Gateway zusammenarbeitet. Dies wiederum macht die Zugangslösung spezifisch für eine Cloud-Bereitstellung.
Natürlich bietet keine der oben genannten Optionen eine wirklich Cloud-unabhängige Lösung. Auch wenn die Verwendung der benutzerdefinierten Load Balancing- oder Ingress Controller-Lösung eines Cloud-Anbieters kurzfristig schnell und einfach sein mag, erhöht sie insgesamt die Verwaltungskomplexität und hemmt die Automatisierung, da Sie nun mit mehreren verschiedenen Lösungen umgehen müssen.
Die angestrebte Lösung würde die folgenden Hauptmerkmale aufweisen:
Cloud-agnostisch: Die Lösung sollte sowohl in öffentlichen als auch in privaten Clouds funktionieren. Das bedeutet, dass sie in verschiedenen Formfaktoren (z. B. virtuell, physisch und Container) verfügbar sein sollte, damit sie in der für die jeweilige Umgebung optimalen Form bereitgestellt werden kann.
Dynamische Konfiguration des Load Balancers: Die Lösung sollte in der Lage sein, den Load Balancer dynamisch zu konfigurieren, um den Datenverkehr zu den Pods innerhalb des Kubernetes-Clusters zu leiten, wenn die Pods erstellt und hoch- bzw. herunterskaliert werden.
Unterstützung von Automatisierungswerkzeugen: Die Lösung sollte Automatisierungstools für die Integration in bestehende DevOps-Prozesse wie CI/CD-Pipelines unterstützen.
Zentralisierte Sichtbarkeit und Analyse: Die Lösung sollte eine zentralisierte Sichtbarkeit und Analyse bieten. Dies würde eine proaktive Fehlerbehebung und eine schnelle Ursachenanalyse ermöglichen, was zu einer höheren Betriebszeit der Anwendung führt.
Wie A10 helfen kann
A10 bietet eine solche Lösung mit seinem Thunder® ADC und dem Thunder Kubernetes Connector (TKC):
Thunder ADC: Thunder ADC ist in verschiedenen Formfaktoren erhältlich, wie z. B. virtuell, physisch und in Containern, was bedeutet, dass die Lösung sowohl in multi-cloud als auch in hybrid-cloud Umgebungen eingesetzt werden kann. Es befindet sich außerhalb des Kubernetes-Clusters und sorgt für einen Lastausgleich des Datenverkehrs, der für die Anwendungen innerhalb des Clusters bestimmt ist. Damit dies funktioniert, muss der Thunder ADC konfiguriert werden, was von der TKC übernommen wird.
TKC: Die TKC wird innerhalb des Kubernetes-Clusters als Container ausgeführt und konfiguriert die Thunder ADC automatisch, während die Pods erstellt und hoch- bzw. herunterskaliert werden.
Die TKC nimmt als Input eine Ingress Resource-Datei. Diese Datei enthält SLB-Parameter, die auf Thunder ADC zu konfigurieren sind, z. B. die virtuelle IP (VIP), das Protokoll (z. B. http) und die Portnummer (z. B. 80), die Thunder ADC für Benutzeranfragen abhören wird, und den Namen der Dienstgruppe, die die Liste der Knoten enthält, an die Thunder ADC den Verkehr weiterleitet.
Die Ingress-Ressourcendatei gibt auch den Dienst innerhalb des Kubernetes-Clusters an, für den die SLB-Konfiguration auf Thunder ADC vorgenommen werden soll. Die TKC überwacht den K8s-API-Server (kube-apiserver) auf Änderungen an diesem Dienst, wenn die entsprechenden Pods erstellt oder hoch- bzw. herunterskaliert werden, und verfolgt die Knoten, auf denen diese Pods ausgeführt werden. Es wird dann einen aXAPI-Aufruf (REST-API) an die Thunder ADC richten und diese Knoten automatisch als Mitglieder der Service-Gruppe auf der Thunder ADC konfigurieren.
Dies vereinfacht und automatisiert den Prozess der Konfiguration von Thunder ADC , wenn neue Dienste im K8s-Cluster bereitgestellt werden. Außerdem wird die Lernkurve für DevOps-Ingenieure verkürzt, da sie die SLB-Konfigurationsparameter mithilfe der Ingress-Ressourcendatei festlegen können, anstatt Zeit mit dem Erlernen der Konfigurationsbefehle für Thunder ADC zu verbringen.
Für das Senden von Daten an die Pods unterstützt die A10-Lösung zwei Hauptbetriebsarten:
Lastausgleich auf Knotenebene: In diesem Modus sendet Thunder ADC den Datenverkehr an den NodePort, der auf jedem Knoten für die Anwendung zugewiesen ist. Beim Erreichen des Knotens wird der Datenverkehr dann intern durch den K8s-Cluster ausgeglichen und an die Pods gesendet. Bei dieser Methode erfolgt der Lastausgleich auf Knotenebene und nicht auf Pod-Ebene. Das heißt, wenn ein Knoten über 10 Pods und ein anderer über 20 Pods verfügt, wird der Datenverkehr dennoch gleichmäßig auf die beiden Knoten verteilt (unter der Annahme eines Round-Robin-Lastausgleichs), was zu einer ungleichen Verteilung des Datenverkehrs auf Pod-Ebene führt.
Lastausgleich auf Pod-Ebene: In einer kommenden Version wird die TKC in der Lage sein, Thunder ADC so zu programmieren, dass der Datenverkehr direkt an die Pods gesendet wird, wodurch der interne Lastausgleichsmechanismus des Kubernetes-Clusters umgangen wird. Dies wird durch IP in IP-Tunnel zum Pod-Netzwerk auf jedem Knoten erreicht. In diesem Modus erfolgt der Lastausgleich auf Pod-Ebene, wodurch eine ausgewogene Verteilung des Datenverkehrs auf die Pods gewährleistet wird (unter der Annahme eines Round-Robin-Lastausgleichs). Diese Option erfordert jedoch, dass das mit dem K8s-Cluster verwendete Container Network Interface (CNI)-Plugin die Bekanntgabe des Pod-Subnetzes unterstützt (z. B. Calico CNI-Plugin).
Neben der automatischen Konfiguration der Thunder ADC durch TKC bietet die A10-Lösung folgende weitere Vorteile:
Unterstützung für Automatisierungstools: Die A10-Lösung kann durch die Unterstützung von Automatisierungstools wie Terraform und Ansible leicht in bestehende DevOps-Prozesse integriert werden.
Unterstützung für L4- und L7-Lastausgleich: Mit der Lösung von A10 haben Sie die Flexibilität, je nach Anforderung sowohl L4- als auch L7-Lastausgleich durchzuführen. Dies steht im Gegensatz zu Ingress Controller-Lösungen, die nur L7-Routing (HTTP/HTTPS) unterstützen.
Leistungsstarke Datenverkehrsverwaltung: Thunder ADC bietet Richtlinien für die Datenverkehrsverwaltung auf Unternehmensebene, einschließlich Header-Rewrite, Bandbreiten- oder Anwendungsratenbegrenzung und einer Liste von TLS-Verschlüsselungen für Sicherheitsrichtlinien.
Zentralisierte Richtlinien: Da der gesamte Anwendungsverkehr über Thunder ADC läuft, bietet es einen zentralen Punkt für die Anwendung und Durchsetzung von Richtlinien in Bezug auf Sicherheit oder allgemeine Geschäftsanforderungen.
Zentralisierte Analysen: Wenn die Lösung zusammen mit dem A10 Harmony Controller® eingesetzt wird, können DevOps/NetOps-Teams zentralisierte Verkehrsanalysen für eine einfachere und schnellere Fehlerbehebung erhalten, was zu einer konsistenteren Betriebszeit und Kundenzufriedenheit führt. Die A10-Lösung unterstützt auch Open-Source-Überwachungstools wie Prometheus/Grafana, so dass Teams, die diese Tools verwenden, dies auch weiterhin tun können.
Flexible Lizenzierung: Mit A10's FlexPool, einem Software-Abonnementmodell, haben Unternehmen die Flexibilität, Kapazitäten zuzuweisen und über mehrere Standorte zu verteilen, wenn sich ihre Geschäfts- und Anwendungsanforderungen ändern.
Wie man anfängt
Eine Demo des TKC in Aktion sehen Sie im A10-Webinar zu Advanced Application Access für Kubernetes.
Um TKC in die Praxis umzusetzen, laden Sie das TKC-Image aus dem Docker-Repository herunter und befolgen Sie die in der TKC-Konfigurationsanleitung beschriebenen Schritte.