Traefik Ingress in IBM Cloud

Ingress macht Dienste in Ihrem Cluster für ein öffentliches oder privates Netzwerk zugänglich. Es leitet Anfragen an Ihre Apps weiter und verwaltet den externen Zugriff auf der Grundlage der von Ihnen konfigurierten Routing-Regeln.

Wenn Sie einen „ IBM Cloud Kubernetes Service “-Cluster einrichten, können Sie einen oder mehrere Traefik-basierte Ingress-Controller aktivieren. Unter IBM finden Sie die Komponenten, die Sie für die Nutzung des Ingress-Controllers benötigen. Um festzulegen, wie die Komponenten zusammenarbeiten, erstellen Sie Ingress-Ressourcen.

Weitere Informationen zu „ Kubernetes “ und „Ingress“ finden Sie unter Kubernetes Dokumentation.

IBM-bereitgestellte Ingress-Komponenten

Wenn Sie einen Cluster erstellen, stellt „ IBM “ die Komponenten bereit, die Sie für die Nutzung von Ingress benötigen. In Ihrer Ingress-Ressource legen Sie fest, wie diese Komponenten verwendet werden.

  • Ingress-Domäne
  • Ingress-Klasse
  • Lastausgleichsfunktionen für Anwendungen (ALBs)
  • TLS-Zertifikat

Ingress-Domäne

Die Standard-Ingress-Domäne bildet für jede App in Ihrem Cluster eine eindeutige URL. Auf diese Domäne verweisen die IP-Adressen aller ALBs in Ihrem Cluster.

Wenn Sie einen Cluster erstellen, wird automatisch eine eindeutige Ingress-Subdomain angelegt und als Standarddomain registriert. Sie können Die Standarddomäne ändern auf jede beliebige Domain umleiten, die in Ihrem Cluster vorhanden ist.

Private ALBs verweisen nicht auf die von „ IBM “ bereitgestellte Ingress-Subdomain, sondern erfordern stattdessen eine benutzerdefinierte Domain.

Sie können auch eine eigene Domain erstellen oder hinzufügen, die beim internen Domain-Anbieter von IBM Cloud oder bei einem externen Anbieter unter IBM Cloud Internet Services registriert ist.

Die Subdomain ist im folgenden Format registriert.

<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud

In der folgenden Tabelle werden die einzelnen Teile der Subdomain beschrieben.

Erläuterungen zum Format für Ingress-Unterdomänen
Unterdomänenkomponente Beschreibung
<cluster_name>

Der Name Ihres Clusters.

  • Wenn der Clustername aus maximal 26 Zeichen besteht und in dieser Region eindeutig ist, wird der vollständige Clustername verwendet: myclustername.
  • Wenn der Clustername aus maximal 26 Zeichen besteht und in dieser Region bereits ein anderer Cluster mit demselben Namen existiert, wird der vollständige Clustername verwendet und um einen Bindestrich sowie sechs zufällige Zeichen ergänzt: myclustername-ABC123.
  • Wenn der Clustername aus 26 oder mehr Zeichen besteht und in dieser Region eindeutig ist, werden nur die ersten 24 Zeichen verwendet: myveryverylongclusternam.
  • Wenn der Clustername 26 Zeichen oder mehr umfasst und in dieser Region bereits ein anderer Cluster mit demselben Namen existiert, werden nur die ersten 17 Zeichen verwendet und ein Bindestrich sowie sechs zufällige Zeichen hinzugefügt: myveryverylongclu-ABC123.
<globally_unique_account_HASH> Ein global eindeutiger Hash wird für Ihr IBM Cloud-Konto erstellt. Alle Subdomains, die Sie für NLBs in Clustern in Ihrem Konto erstellen, verwenden diesen Hash.
0000 Dient als Zähler für jede Subdomain, die in Ihrem Cluster erstellt wird.
<region> Die Region, in der der Cluster erstellt wird.
containers.appdomain.cloud Die Unterdomäne für IBM Cloud Kubernetes Service-Unterdomänen.

Um für jede App eine eindeutige URL „ URL “ zu bilden, werden die Pfade zu Ihren App-Diensten an die öffentliche Route angehängt. Siehe dazu beispielsweise die folgende App: URL.

mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1

Ingress-Klasse

Die Ingress-Klasse bestimmt, welche Art von Ingress-Controller verwendet wird. „ IBM “ stellt zwei Ingress-Klassen bereit: eine öffentliche (public-iks-traefik) und eine private (private-iks-traefik). Beide Klassen implementieren den Traefik-Ingress-Controller. Wenn Sie Ihre Ingress-Ressource erstellen, legt die von Ihnen angegebene Ingress-Klasse fest, ob Ihre Apps öffentlich oder privat zugänglich sind.

Sie können eine benutzerdefinierte Ingress-Klasse verwenden, indem Sie „ ingressClass “ in der anpassbaren Deployment-Konfiguration konfigurieren.

Lastausgleichsfunktionen für Anwendungen (ALBs)

ALBs überwachen eingehende Serviceanfragen an HTTP, HTTPS oder TCP und leiten diese Anfragen gemäß den Regeln, die Sie in der Ingress-Ressource definieren, an den entsprechenden App-Pod weiter.

Wenn Sie einen Standard-Cluster mit klassischer oder VPC-Infrastruktur erstellen, werden in jeder Zone automatisch ein öffentlicher und ein privater ALB für Sie angelegt.

ALBs in klassischen Clustern

Wenn Sie einen klassischen Cluster erstellen, werden in jeder Zone automatisch ein öffentlicher und ein privater ALB für Sie angelegt. Öffentlichen und privaten ALBs in klassischen Clustern wird eine statische IP-Adresse zugewiesen, die sich während der gesamten Lebensdauer des Clusters nicht ändert.

Öffentliche ALBs nutzen dieselbe von „ IBM “ bereitgestellte Ingress-Subdomain, die bei der Bereitstellung eines Clusters für Sie registriert wird, und die individuelle IP-Adresse jedes öffentlichen ALB ist mit dieser Subdomain verknüpft. Um die IP-Adresse eines öffentlichen ALB zu ermitteln, führen Sie den Befehl „ ibmcloud ks ingress alb ls “ aus und überprüfen Sie das Feld „ALB IP“ in der Ausgabe.

Private ALBs in klassischen Clustern verwenden nicht die von „ IBM “ bereitgestellte Ingress-Subdomain und werden nicht automatisch aktiviert. Sie müssen zunächst private ALBs in der CLI aktivieren und anschließend die Klasse „ private-iks-traefik “ in Ihrer Ingress-Ressource angeben. Nachdem die privaten ALBs aktiviert wurden, können Sie die privaten IP-Adressen ermitteln, indem Sie den Befehl „ ibmcloud ks ingress alb ls “ ausführen und das Feld „ALB IP“ in der Ausgabe überprüfen.

Wenn ein öffentlicher oder privater ALB-Pod neu geplant wird, behält er dieselbe IP-Adresse bei. Das Entfernen einer Zone mit einem ALB oder das Entfernen aller Worker in einem VLAN dieser Zone führt jedoch dazu, dass die IP-Adresse dieses ALB entfernt wird.

ALBs in VPC

Wenn Sie einen VPC-Cluster erstellen, werden in jeder Zone automatisch ein öffentlicher und ein privater ALB für Sie angelegt. Zudem wird automatisch ein öffentlicher VPC-Load-Balancer außerhalb Ihres Clusters in Ihrer VPC erstellt. Wenn Sie private ALBs in Ihrem VPC-Cluster aktivieren, wird gleichzeitig ein privater VPC-Load-Balancer erstellt.

Die IP-Adressen für ALBs in VPC-Clustern sind nicht statisch und können sich im Laufe der Zeit ändern. Daher ordnen die VPC-Lastverteiler die öffentliche oder private IP-Adresse Ihrer ALBs einem statischen Hostnamen zu. Für öffentliche und private ALBs werden unterschiedliche Hostnamen verwendet. Der ALB-Hostname ist unabhängig von der Ingress-Subdomain des Clusters.

Um den Hostnamen eines ALB in einem VPC-Cluster zu ermitteln, führen Sie den Befehl „ ibmcloud ks ingress alb ls “ aus. Private Hostnamen werden nur angezeigt, wenn private ALBs aktiviert sind.

Anforderungen an Worker-Knoten für ALBs

Pro Zone in Ihrem Cluster sind mindestens zwei Worker-Knoten erforderlich, damit die ALBs mit hoher Verfügbarkeit funktionieren und regelmäßig aktualisiert werden können.

Anti-Affinitätsregeln für ALB-Pods stellen sicher, dass pro Worker-Knoten nur ein Pod eingeplant wird. Wenn automatische Updates auf ALB-Pods angewendet werden, wird der Pod neu geladen.

Wenn Sie nur einen Worker-Knoten und somit nur einen ALB-Pod haben, wird der Pod nicht automatisch aktualisiert, um Unterbrechungen des Datenverkehrs zu vermeiden. In diesem Fall werden Aktualisierungen erst dann übernommen, wenn Sie den Pod manuell löschen und einen neuen einplanen. Wenn pro Zone mindestens zwei Worker-Knoten vorhanden sind, lässt sich dieses Szenario vermeiden.

Beachten Sie, dass es bei einem Ausfall einer Zone zu zeitweiligen Störungen bei Anfragen an den Ingress ALB in dieser Zone kommen kann.

Standard- TLS-Zertifikat

Wenn Sie einen Cluster erstellen, wird ein Standardzertifikat für „ TLS “ erstellt, das Sie mit der von „ IBM “ bereitgestellten Ingress-Subdomain verwenden können. Sie können entweder das Standardzertifikat „ TLS “ oder ein benutzerdefiniertes Zertifikat angeben, das Sie in der Ingress-Ressource bereitstellen.

Erwägen Sie die Verwendung von Secrets Manager zur zentralen Verwaltung und automatischen Aktualisierung Ihrer Ingress-Subdomain-Zertifikate und anderer Geheimnisse.

Die Einrichtung von Ingress mit „ TLS “-Zertifikaten erfordert das Erstellen oder Importieren von Secrets. Wenn Sie die Ingress-API von „ IBM Cloud “ zur Durchführung dieser Schritte verwenden möchten, benötigen Sie eine Standardinstanz von „ Secrets Manager “. Alternativ können Sie die Befehle „ kubectl “ verwenden, um Ihre Zertifikate zu kopieren.

Erste Schritte mit Ingress

Wenn Sie bereit sind, Ingress in Ihrem Cluster zu verwenden, erstellen Sie eine Ingress-Ressource, um Ihre Ingress-Komponenten zu konfigurieren, Regeln für die Weiterleitung von Anfragen festzulegen und den Pfad zu den App-Diensten anzugeben. Für jeden Namespace, der eine App oder einen Dienst enthält, den Sie verfügbar machen möchten, ist eine eigene Ingress-Ressource erforderlich.