A First Look at Kubernetes Service APIs

Vorwort

Wir wissen, dass Kubernetes eine Reihe von Lösungen für die Bereitstellung von Diensten innerhalb des Clusters bietet, eine der beliebtesten ist Ingress, ein Standard für die Bereitstellung von Diensten nach außen, der mehrere Implementierungen von Drittanbietern hat, jede mit ihrem eigenen Technologie-Stack und Abhängigkeiten von Gateways, die nicht miteinander kompatibel sind.

Um die verschiedenen Ingress-Implementierungen zu vereinheitlichen und eine einheitliche Verwaltung auf Kubernetes zu erleichtern, hat die SIG-NETWORK Community die Kubernetes Service APIs veröffentlicht, eine Reihe von Standardimplementierungen, die als Ingress der zweiten Generation bezeichnet werden.

Themenbeschreibung

Dieser Artikel bietet eine Einführung in die Grundkonzepte der Kubernetes Service APIs, beginnend mit einigen Fragen.

Einführung

Die Kubernetes Service APIs werden als die zweite Generation der Ingress-Technologie bezeichnet, aber in welcher Hinsicht sind sie besser als die erste Generation?

Die Kubernetes Service APIs wurden nicht entwickelt, um auf Ingress beschränkt zu sein, sondern um das Dienstnetzwerk mit einem Fokus auf Ausdrucksfähigkeit, Skalierbarkeit und RBAC zu verbessern.

1. Mehr Funktionen, z.B. Verwaltung des Datenverkehrs basierend auf dem Header, Gewichtung.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. Verbesserung der Skalierbarkeit, die Service APIs führen das Konzept einer mehrschichtigen API ein, wobei jede Schicht ihre eigene Schnittstelle offenlegt, was es anderen benutzerdefinierten Ressourcen ermöglicht, mit der API zu interagieren, um eine feinere (API-granulare) Kontrolle zu ermöglichen.

3. Rollenorientiertes RBAC: Die Realisierung der mehrschichtigen API, eine der Ideen ist, Ressourcenobjekte aus der Perspektive der Benutzer zu entwerfen. Diese Ressourcen werden schließlich mit den gemeinsamen Rollen der Ausführung von Anwendungen auf Kubernetes abgebildet.

Welche Ressourcenobjekte werden von den Kubernetes Service APIs abstrahiert?

Basierend auf Benutzerrollen werden die Kubernetes Service APIs die folgenden Ressourcen definieren:

GatewayClass, Gateway, Route

1. GatewayClass definiert eine Gruppe von Gateway-Typen mit gemeinsamer Konfiguration und Verhalten:

• Beziehung zu Gateway, ähnlich der ingess.class Annotation in Ingress;
• Eine GatewayClass definiert eine Gruppe von Gateways, die dieselbe Konfiguration und dasselbe Verhalten teilen. Jede GatewayClass wird von einem einzelnen Controller behandelt, wobei der Controller eine Eins-zu-Viele-Beziehung zur GatewayClass hat;
• GatewayClass ist eine Cluster-Ressource. Es muss mindestens eine GatewayClass definiert werden, um ein funktionierendes Gateway zu haben.

2. Gateway fordert einen Punkt an, an dem Datenverkehr in Dienste innerhalb des Clusters umgewandelt werden kann:

• Was es tut: bringt Datenverkehr von außerhalb des Clusters in den Cluster. Dies ist die eigentliche Ingress-Entität;
• Es definiert eine Anforderung für eine spezifische LB-Konfiguration, die auch die Implementierung der Konfiguration und des Verhaltens der GatewayClass ist;
• Gateway-Ressourcen können direkt vom Betreiber oder vom Controller, der die GatewayClass behandelt, erstellt werden;
• Gateway und Route stehen in einer Viele-zu-Viele-Beziehung.

3. Route beschreibt, wie Datenverkehr, der durch ein Gateway fließt, einem Dienst zugeordnet wird.

Darüber hinaus definieren die Kubernetes Service APIs ein BackendPolicy-Ressourcenobjekt, um eine flexible Konfiguration von Backend-Diensten zu ermöglichen.

Das BackendPolicy-Objekt ermöglicht es Ihnen, TLS, Gesundheitsprüfungen zu konfigurieren und den Typ des Backend-Dienstes anzugeben, wie z.B. Dienst oder Pod.

Welche Änderungen wird die Einführung der Kubernetes Service APIs mit sich bringen?

Die Kubernetes Service APIs, als Implementierungsstandard, bringen die folgenden Änderungen mit sich.

1. Allgemeingültigkeit: Es kann mehrere Implementierungen geben, genauso wie es mehrere Implementierungen von Ingress gibt. Ingress-Controller können entsprechend den Eigenschaften des Gateways angepasst werden, aber sie alle haben eine konsistente Konfigurationsstruktur. Eine Datenstruktur kann verwendet werden, um mehrere Ingress-Controller zu konfigurieren.
2. Das Konzept der Klassen: GatewayClasses ermöglicht die Konfiguration verschiedener Arten von Lastausgleichs-Implementierungen. Diese Klassen ermöglichen es dem Benutzer, leicht und explizit zu verstehen, welche Funktionen als Ressourcenmodelle selbst verwendet werden können.
3. Gemeinsame Gateways: Durch die Möglichkeit, unabhängige Routing-Ressourcen HTTPRoute an dieselbe GatewayClass zu binden, können sie Lastenausgleicher und VIPs teilen. Schichtweise nach Benutzer, dies ermöglicht es Teams, die Infrastruktur sicher zu teilen, ohne sich um die spezifische Implementierung des unteren Gateway kümmern zu müssen.
4. Backend-Referenzen mit Typen: Mit Backend-Referenzen mit Typen können Routen auf Kubernetes-Dienste oder jede Art von Kubernetes-Ressource verweisen, die als Gateway-Backend entworfen ist, wie z.B. ein Pod oder ein Statefulset wie eine DB, oder sogar eine zugängliche Cluster-externe Ressource.
5. Namespace-übergreifende Referenzen: Routen über verschiedene Namespaces können an ein Gateway gebunden werden, was den Zugriff über Namespaces hinweg ermöglicht. Es ist auch möglich, den Bereich der Namespaces einzuschränken, auf die eine Route unter einem Gateway zugreifen kann.

Welche Ingress-Implementierungen der Kubernetes Service APIs sind derzeit verfügbar?

Die Ingress, von denen bekannt ist, dass sie die Kubernetes Service APIs-Ressourcenobjekte auf Code-Ebene unterstützen, sind Contour, ingress-gce.

Wie verwalten die Kubernetes Service APIs Lese- und Schreibrechte für Ressourcen?

Die Kubernetes Service APIs sind basierend auf der Benutzerdimension in 3 Rollen unterteilt:

1. Infrastrukturanbieter GatewayClass;
2. Cluster-Betreiber Gateway;
3. Anwendungsentwickler Route.

RBAC (Role Based Access Control) ist der Standard, der für die Kubernetes-Autorisierung verwendet wird. Es ermöglicht Benutzern, zu konfigurieren, wer Operationen auf einem bestimmten Bereich von Ressourcen ausführen kann. RBAC kann verwendet werden, um jede der oben definierten Rollen zu aktivieren.

In den meisten Fällen wird erwartet, dass alle Rollen alle Ressourcen lesen können.

Das Drei-Schichten-Modell hat die folgenden Schreibrechte.

Was sind die Erweiterungspunkte für die Kubernetes Service APIs?

Die Anforderungen an Gateways sind sehr vielfältig, und es gibt viele Möglichkeiten, dasselbe Szenario zu implementieren, jede mit ihren eigenen Vor- und Nachteilen. Kubernetes Service APIs haben mehrschichtige Ressourcenobjekte extrahiert und auch einige Erweiterungspunkte reserviert.

Die Kubernetes Service APIs konzentrieren sich derzeit auf Route:

• RouteMatch erweitert die Route-Matching-Regeln.
• specify Backend erweitert spezifische Typen von Backend-Diensten, wie z.B. Dateisysteme, Funktionsausdrücke usw., zusätzlich zu den oben genannten Kubernetes-Ressourcen.
• Route-Filter fügt Erweiterungen zum Route-Lebenszyklus hinzu, um Anfragen/Antworten zu verarbeiten.
• Wenn keine der oben genannten Erweiterungen durch eine benutzerdefinierte Route erfüllt werden kann, kann eine Route vollständig angepasst werden.

Zusammenfassung

Dieser Artikel hat eine grundlegende Einführung in die Kubernetes Service APIs durch Fragen gegeben. Insgesamt verfeinern die Kubernetes Service APIs viele der Best Practices von Ingress, wie die verbesserte Ausdrucksfähigkeit, die tatsächlich die Fähigkeiten von Route erweitert, und die BackendPolicy-Objekte, die fast jede Kubernetes-Backend-Ressource für Upstream angeben können. Die Kubernetes Service APIs legen derzeit die Ressourcenobjekte auf einer breiten Ebene fest, aber es gibt noch viele Details innerhalb der Ressourcenobjekte, die diskutiert werden müssen, bevor sie definiert werden können, um mögliche Konfliktszenarien zu verhindern, und es gibt bestimmte Variablen in der Struktur.