Da die Welten von DevOps und NetOps aufeinanderprallen und Containerumgebungen Definitionen umfassen, die traditionell im Netzwerk verwendet werden, erscheint es sinnvoll, die Verwendung des oft verwirrenden Begriffs „Ingress“ in Bezug auf den Datenpfad und die Containerumgebungen zu untersuchen.
Die Begriffe „Ingress“ und „Egress“ werden traditionell verwendet, um die Richtung des Datenverkehrs im Netzwerk aus der Perspektive des Rechenzentrums zu beschreiben. Der Eingang ist eingehend, der Ausgang ist ausgehend.
Mit der Weiterentwicklung der Containerumgebungen hat sich für den Begriff „Ingress“ eine sehr spezifische, anwendungsbezogene Definition etabliert.
Eindringen. Ein API-Objekt, das den externen Zugriff auf die Dienste in einem Cluster verwaltet, normalerweise HTTP. Ingress kann Lastausgleich, SSL-Terminierung und namensbasiertes virtuelles Hosting bereitstellen.
Es ist wichtig, einen Moment innezuhalten und festzuhalten, dass eine Ingress-Ressource in einer Kubernetes-Umgebung Fähigkeiten beschreibt, die innerhalb der Container-Grenzen ausgeführt werden sollen.
Jeder Ingress fungiert als Reverse-Proxy, der externe Anfragen annimmt und sie gemäß den Regeln der Kubernetes-Ingress-Ressource an den passenden Kubernetes-Dienst weiterleitet. Dieser Dienst verteilt die Anfragen über verbundene Container, meist unter Nutzung nativer Layer-4-(TCP)-Lastausgleichsverfahren. So präsentieren Sie der Außenwelt eine einheitliche API. Der Ingress wertet die API-Aufrufe (URI-Pfad) aus und leitet sie an die passenden, in Containern gehosteten Microservices im Container-Cluster weiter.
F5 bietet dieselben Funktionen wie ein klassischer Kubernetes-Ingress, fügt jedoch zusätzliche Funktionen in Form von SNI-Routing und Layer 4 (TCP)-Lastausgleich hinzu. Die Möglichkeit, SNI-Routing (Server Name Indicator) durchzuführen, ist ein Vorteil für diejenigen, die eine durchgängige TLS-Verschlüsselung des Nachrichtenaustauschs wünschen, da F5 dadurch Anfragen basierend auf den Informationen in den Headern richtig weiterleiten kann, ohne die eigentliche Nutzlast/Nachricht zu entschlüsseln. Dadurch wird zwar der Funktionsumfang eingeschränkt, der auf die Anfrage angewendet werden kann – sie kann beispielsweise nicht auf schädliche Inhalte geprüft werden –, es bietet jedoch die notwendige Unterstützung für Architekturen, in denen Inhalte aus rechtlichen oder betrieblichen Gründen verschlüsselt bleiben müssen. Die Lastverteilung auf Layer 4 (TCP) wird häufig außerhalb einer Containerumgebung verwendet, um Ingress-Dienste im Kubernetes-Stil zu skalieren.
F5 wird normalerweise außerhalb der Containerumgebung bereitgestellt. Es wird häufig als Lastausgleichslösung verwendet, um Cluster extern verfügbar zu machen, d. h. öffentlichen Zugriff auf Dienste zu ermöglichen, die aus einem Containercluster bestehen. Eine CNCF-Umfrage ergab, dass 67 % der Befragten eine Load Balancer-Option wählen, um Cluster-Dienste extern verfügbar zu machen, während weitere 33 % Ingress-Funktionen (L7) nutzen.
Um Ihnen dieselben Funktionen wie ein Kubernetes-Ingress zu bieten, nutzen wir einen container-nativen „Connector“, der die Aktualisierung der Richtlinien zur Datenverkehrssteuerung ermöglicht. Dieser Connector arbeitet innerhalb und integriert sich nahtlos mit dem Container-Orchestrator, meist Kubernetes, aber auch Red Hat OpenShift ist weit verbreitet. Wir kommunizieren mit F5 Ingress über eine API. Dabei aktualisieren wir sowohl die Definitionen der Ingress-Ressourcen (HTTP-Routing-Richtlinien) als auch die Systemkonfiguration, wie das Starten oder Entfernen einer Containerinstanz, die eine bestehende Service-Definition beeinflusst.
Der Vorteil der Verwendung von F5 gegenüber einfachen Ingress-Diensten besteht in der Möglichkeit, erweiterte Funktionen auf eingehenden und ausgehenden Datenverkehr anzuwenden. Sicherheit, Header-Anreicherung und kundenspezifische Leistungsoptimierungen können bei der Verwendung von F5 angewendet werden, ohne die Containerumgebung oder -architektur oder die Anwendung selbst zu ändern.
Weitere Ressourcen: