Kubernetes 1.19: Die Zukunft von Traffic Ingress und Routing

Die Kubernetes-Community verabschiedet sich von Ingress und entwickelt das Traffic Routing neu, damit es mit mehreren Teams und Rollen besser skaliert.

Michael Vittrup Larsen

Michael is a Consultant at our office in Aarhus. He has an MScEE from Aalborg University where he specialized in digital signal processing. Before joining us Michael was working on building and optimizing cloud infrastructure for the telecoms sector. In his spare time, he likes to explore the wilderness on his mountain bike.

Kubernetes 1.19 und die Ingress-Ressource

In Kubernetes 1.19 wurde die Ressource Ingress, die definiert, wie HTTP-Traffic in Kubernetes eingeht und weitergeleitet wird, von Beta auf GA hochgestuft. Während die Ingress-Ressource den Beta-Status hatte, gab es in Kubernetes 1.18 einige Entwicklungen, etwa die Einführung von Hostname-Wildcards. Meiner Ansicht nach wird die künftige Weiterentwicklung von Traffic-Ingress und Routing in Kubernetes über andere Ressourcentypen erfolgen. Die Entwicklungen in Kubernetes 1.18 und die Hochstufung von Ingress auf GA/v1 in 1.19 lassen sich als Umsetzung der dringendsten Anforderungen verstehen, bevor das Design der Ingress-Ressource festgelegt wurde.

Eine Ressource mit fester Revision erhält nur Bugfixes und abwärtskompatible Änderungen. Daher ist es unwahrscheinlich, dass wir künftig größere Änderungen an der Ingress-Ressource sehen werden. Die lange Beta-Phase in Kombination mit der weiten Verbreitung der Ingress-Ressource bedeutet zudem, dass sie de facto schon lange GA-Status hatte und ohne Bruch der Abwärtskompatibilität nicht wesentlich weiterentwickelt werden konnte. Man könnte dies fix, (forget) and look forward nennen: das Design festschreiben, künftig nur noch Bugs beheben und neue Ressourcentypen für ein weiterentwickeltes Design schaffen.

Das Problem mit der Ingress-Ressource besteht darin, dass ihr Design ohne größere Abweichungen vom aktuellen Ansatz nicht wirklich weiterentwickelbar ist. Wenn wir also innovieren und die Ingress-Ressource grundlegend verändern wollen, müssen wir einen neuen Ressourcentyp schaffen. Das zeigt sich auch an der laufenden Arbeit der Kubernetes-Service-APIs-SIG und beispielsweise der Gateway API.

Was sind also die größten Probleme mit der Ingress-Ressource, und welches Modell können wir von Version 2 des Ressourcentyps Ingress erwarten? Lest weiter ...

Kubernetes Ingress-Ressource

Die Ingress-Ressource in Kubernetes ist der offizielle Weg, HTTP-basierte Services bereitzustellen. Die Ingress-Ressource führte während der vergangenen 18 Kubernetes-Versionen ein unsicheres Leben als Beta-Ressource – ja, seit Kubernetes v1.1! Die lange Zeit als Beta-API und die Vielzahl an Ingress-Controller-spezifischen Annotations, mit denen sich das Verhalten der Ingress-Ressource erweitern und ändern lässt, zeigen, dass die Ingress-Ressource nicht so gut konzipiert ist wie andere Kubernetes-Ressourcen. Im folgenden Abschnitt beschreiben wir das Skalierungsproblem der Ingress-Ressource und einen Lösungsansatz.

Getrennte Rollen

Ein Problem der Ingress-Ressource ist, dass sie Folgendes in einer einzigen Ressourcendefinition zusammenfasst:

Identität – der Domainname
Authentifizierung – das TLS-Zertifikat
Routing – welche URL-Pfade an welche Kubernetes-Services weitergeleitet werden

Wenn jemand eine etwas komplexere Website verwaltet, deren Komponenten von mehreren unabhängigen Teams betreut werden, sollten die oben genannten Bereiche idealerweise getrennten Rollen zugewiesen werden. Zum Beispiel:

Sicherheits-/Infrastrukturadministrator – verwaltet Domainnamen und TLS-Zertifikate
Website-Administrator – verwaltet das Routing zu Komponenten und Anwendungen, die von einzelnen Teams betreut werden
Anwendungsteams – verwalten das Routing zu verschiedenen Anwendungsversionen, Canarys, Blue/Green-Versionen usw.

Stellt euch eine Website vor, example.com, die aus zwei Komponenten besteht: login und mainsite. Jede wird von einem eigenen Team betreut. Die verschiedenen Rollen und das Traffic-Routing lassen sich wie in der folgenden Abbildung darstellen. Blaue Kästen stehen für eine Rolle, rote Kästen für eine Traffic-Routing-Definition. Routing-Definitionen verwenden entweder einen URL-Pfad oder einen HTTP-Header als Selektor.

the-future-of-traffic-ingress-and-routing-1

Hier verwaltet die Rolle „Sicherheitsadministrator“ die Identität der Website über den Domainnamen und TLS-Zertifikate – und möglicherweise auch DNS, das nicht Teil dieser Beschreibung ist. Domainname und TLS-Zertifikat ändern sich nur selten, daher sollte der Zugriff auf diese Rolle stark eingeschränkt sein. Werden Zertifikate mit Lets Encrypt verwaltet, bedeutet der eingeschränkte Zugriff auch, dass Website-Administratoren oder Anwendungsteams keine Zertifikatserneuerungen auslösen können. Das verringert die Wahrscheinlichkeit, das Zertifikats-Ratenlimit von Lets Encrypt zu erreichen. Es besteht also kein Risiko, aufgrund des Ratenlimits kein TLS-Zertifikat zu erhalten.

Die Rolle „Website-Administrator“ definiert das Routing auf oberster Ebene, etwa zu den beiden Anwendungen, die von unseren zwei Teams verwaltet werden. Dieses Routing ändert sich nur, wenn wir Anwendungen zu unserer Website hinzufügen oder daraus entfernen.

Die „Anwendungsteams“ verwalten die Unterkomponenten jeder Anwendung, einschließlich Test-Deployments. Jedes Anwendungsteam kann beispielsweise Routing zu Testinstanzen definieren, um Canary-Tests, Blue/Green-Tests usw. umzusetzen.

In Kubernetes definiert die Ingress-Ressource Domainname, TLS-Zertifikat und Routing zu Kubernetes-Services in einem einzigen Objekt. Daraus folgt, dass ein Anwendungsteam, das beispielsweise Canary-Tests durchführen möchte, Zugriff zum Ändern der globalen Ingress-Ressource für die gesamte Website benötigt. Das hat Auswirkungen auf Sicherheit und Stabilität. Besonders offensichtlich ist: Ein Syntaxfehler in der Ingress-Ressource macht die gesamte Website unzugänglich.

Die Arbeit der Kubernetes API SIG an der Gateway API soll dieses Setup mit mehreren Rollen unterstützen. Zwar gibt es noch keine Implementierungen der Gateway API, doch die API ist stark von der API des Contour-Ingress-Controllers inspiriert. In den folgenden Abschnitten zeigen wir euch, wie ihr dieses Setup mit mehreren Rollen mit Contour umsetzen könnt. So erhaltet ihr einen Eindruck von der potenziellen künftigen Gateway API in Kubernetes.

Ein Setup mit mehreren Rollen mit Contour und Envoy umsetzen

Envoy ist ein von der Cloud Native Computing Foundation (CNCF) graduierter Proxy, und Contour ist ein auf Envoy basierender Ingress-Controller. Contour erweitert das Konzept von Ingress-Ressourcen um ein HTTPProxy-Objekt, das die Delegation eines HTTPProxy-Objekts an ein anderes ermöglicht. Anders ausgedrückt: Damit lässt sich Traffic-Routing mithilfe mehrerer HTTPProxy-Ressourcen in mehreren Kubernetes-Namespaces definieren, wobei der Zugriff auf Namespaces durch verschiedene Rollen eingeschränkt wird. Dies wird unten dargestellt.

Contour graph with security admin role, site admin role and login application team role

Ein Beitrag über Kubernetes ist ohne etwas YAML nicht vollständig. Sehen wir uns daher das YAML für die oben beschriebene Implementierung an. Zunächst der HTTPProxy der obersten Ebene, der die Identität der Website definiert:

Die HTTPProxy-Ressource example-com-root im Namespace security-admin-only definiert die Identität der Website über den Domainnamen und das TLS-Zertifikat und delegiert das weitere Routing an die HTTPProxy-Ressource site-fanout im Namespace site-admin-only:

Die HTTPProxy-Ressource site-fanout leitet alles unter dem Pfad /login an die HTTPProxy-Ressource login im Namespace login weiter. Das Team, das die Login-Anwendung verwaltet, hat vollständigen Zugriff auf den Namespace login und kann daher die folgende HTTPProxy-Ressource erstellen, um an Kubernetes-Services weiterzuleiten, die es ebenfalls verwaltet:

Die HTTPProxy-Ressource login leitet an den Kubernetes-Service test-login-app-service weiter, wenn der HTTP-Header x-test den Wert true enthält, beispielsweise für einen Blue-Green-Test. Andernfalls erfolgt die Weiterleitung an den Kubernetes-Service login-app-service.

Rego und Conftest

Natürlich sollten die oben genannten Namespaces mit Kubernetes RBAC abgesichert sein. So kann das Team „login“ beispielsweise nur HTTPProxy-Ressourcen in seinem Namespace login erstellen. Vielleicht fragt ihr euch jedoch, wie sich die Erstellung von HTTPProxy-Root-Ressourcen wie example-com-root oben auf den Namespace security-admin-only beschränken lässt.

Die Erstellung solcher Ressourcen lässt sich mit OPA GateKeeper beschränken. GateKeeper ist ein Kubernetes-Admission-Controller, der Richtlinien akzeptiert, die mit der Sprache Rego definiert werden. Ich habe ein Beispiel für einen Rego-basierten Test erstellt, der auf HTTPProxy-Root-Ressourcen prüft. Der Test ist Teil einer Testsuite, die sich für GitOps CI eignet, etwa wenn ihr eure Kubernetes-Ressourcen vor dem Deployment in Kubernetes validieren möchtet.

Wann werden wir eine neue Ingress-Ressource in Kubernetes sehen?

Wahrscheinlich nie.

Der Trend bei Kubernetes geht dahin, Erweiterungen über CRDs (Custom Resource Definitions) umzusetzen – ein dynamischer Ansatz, bei dem Erweiterungen außerhalb des Kubernetes-Kerns eingeführt werden. Das bedeutet, dass Projekte wie Contour oder Istio eigene CRDs bereitstellen, mit denen wir Traffic Ingress und Routing definieren können. Daher ist es unwahrscheinlich, dass eine neue gemeinsame Ingress-Definition in den Kubernetes-Kern aufgenommen wird.