Ingress – NGINX in IBM Cloud

Ingress ist eine Kubernetes Service Discovery-Methode, die die Dienste in Ihrem Cluster dem öffentlichen oder privaten Netzwerk zugänglich macht, indem sie Anfragen an Ihre Anwendungen weiterleitet und die Arbeitslast des Netzwerkverkehrs ausgleicht. Ingress verwaltet den externen Zugriff auf Ihre Services auf der Basis einer Gruppe von Routing-Regeln, die Sie konfigurieren und die auf den gesamten eingehenden Datenverkehr angewendet werden.

Wenn Sie einen IBM Cloud Kubernetes Service-Cluster bereitstellen, stellt IBM alle Komponenten bereit, die für die Verwendung von Ingress erforderlich sind. Wenn Sie dann für den Einstieg bereit sind, erstellen Sie eine Ingress-Ressource, um anzugeben, wie diese Komponenten zusammenarbeiten.

Weitere Informationen zu Kubernetes Ingress finden Sie in der Dokumentation zu Kubernetes.

Von IBMbereitgestellte Ingress-Komponenten

Wenn Sie einen Cluster erstellen, werden alle Komponenten bereitgestellt, die für die Verwendung von Ingress erforderlich sind. Sie geben diese Komponenten an, wenn Sie Ihre Ingress-Ressource erstellen.

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

Ingress-Domäne

Die Standard-Ingress-Domäne wird verwendet, um eine eindeutige URL für jede Anwendung in Ihrem Cluster zu bilden, und ist die Domäne, auf die die IP-Adressen aller ALBs in Ihrem Cluster verweisen. Wenn Sie einen Cluster erstellen, wird automatisch eine eindeutige Ingress-Unterdomäne erstellt und als Standarddomäne registriert. Sie können die Standarddomäne in eine beliebige Domäne in Ihrem Cluster ändern.

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

Private ALBs verweisen nicht auf die von IBM bereitgestellte Ingress-Subdomain und benötigen stattdessen eine eigene Domain.

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 Bestandteile der Subdomain beschrieben.

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

Der Name des Clusters.

  • Wenn der Clustername aus 26 Zeichen oder weniger besteht und in dieser Region eindeutig ist, wird der gesamte Clustername einbezogen und nicht geändert: myclustername.
  • Wenn der Clustername aus 26 Zeichen oder weniger besteht und ein Cluster mit identischem Namen in dieser Region vorhanden ist, wird der gesamte Clustername einbezogen und ein Gedankenstrich sowie sechs Zufallszeichen hinzugefügt: myclustername-ABC123.
  • Wenn der Clustername aus 26 Zeichen oder mehr besteht und in dieser Region eindeutig ist, werden nur die ersten 24 Zeichen des Clusters verwendet: myveryverylongclusternam.
  • Wenn der Clustername aus 26 oder mehr Zeichen besteht und ein Cluster mit identischem Namen in dieser Region vorhanden ist, werden nur die ersten 17 Zeichen des Clusternamens verwendet und ein Gedankenstrich sowie sechs Zufallszeichen hinzugefügt: myveryverylongclu-ABC123.
<globally_unique_account_HASH> Ein global eindeutiger Hash wird für Ihr IBM Cloud-Konto erstellt. Alle Unterdomänen, die Sie für NLBs in Clustern in Ihrem Konto erstellen, verwenden diesen global eindeutigen Hash.
0000 Dient als Zähler für jede Unterdomäne, 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.

Zur Bildung einer eindeutigen URL für jede App werden die Pfade zu Ihren App-Services an die öffentliche Route angehängt. Sehen Sie sich beispielsweise die folgende App- URLan.

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

Ingress-Klasse

Die Ingress-Klasse bestimmt den Typ des verwendeten Ingress-Controllers. IBM bietet zwei Ingress-Klassen, eine öffentliche (public-iks-k8s-nginx) und eine private (private-iks-k8s-nginx). Beide Klassen implementieren den NGINX Ingress-Controller. Wenn Sie Ihre Ingress-Ressource erstellen, bestimmt die von Ihnen angegebene Ingress-Klasse, ob Ihre Apps öffentlich oder privat zugänglich gemacht werden.

Sie können eine angepasste Ingress-Klasse verwenden, indem Sie Ihre eigene IngressClass-Ressource erstellen.

Lastausgleichsfunktionen für Anwendungen (ALBs)

ALBs lauschen auf eingehende HTTP, HTTPS oder TCP Dienstanforderungen und leiten diese Anforderungen dann gemäß den in der Ingress-Ressource definierten Regeln an den entsprechenden App-Pod weiter. Wenn Sie einen Standardcluster mit einer klassischen oder VPC-Infrastruktur erstellen, wird automatisch eine öffentliche und eine private ALB für Sie in jeder Zone erstellt.

ALBs in klassischen Clustern

Wenn Sie einen klassischen Cluster erstellen, wird in jeder Zone automatisch eine öffentliche und eine private ALB erstellt. Öffentlichen und privaten ALBs in klassischen Clustern wird eine statische IP-Adresse zugeordnet, die sich während der Lebensdauer des Clusters nicht ändert.

Öffentliche ALBs verwenden dieselbe von IBMbereitgestellte Ingress-Unterdomäne, die für Sie registriert ist, wenn Sie einen Cluster bereitstellen, und jede einzelne IP-Adresse einer öffentlichen ALB ist mit dieser Unterdomäne verknüpft. Um die IP-Adresse einer öffentlichen ALB zu suchen, führen Sie 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 IBMbereitgestellte Ingress-Unterdomäne und werden nicht automatisch aktiviert. Sie müssen zuerst private ALBs in der Befehlszeilenschnittstelle aktivieren und dann die Klasse private-iks-k8s-nginx in Ihrer Ingress-Ressource angeben. Nachdem die privaten ALBs aktiviert wurden, können Sie die privaten IP-Adressen finden, indem Sie 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. Wenn Sie jedoch eine Zone mit einer ALB oder alle Worker in einem VLAN in dieser Zone entfernen, wird die IP-Adresse dieser ALB entfernt.

ALBs im VPC

Wenn Sie einen VPC-Cluster erstellen, wird automatisch eine öffentliche und eine private ALB für Sie in jeder Zone erstellt. Außerdem wird automatisch eine öffentliche VPC-Lastausgleichsfunktion außerhalb Ihres Clusters in Ihrer VPC erstellt. Wenn Sie private ALBs in Ihrem VPC-Cluster aktivieren, wird auch eine private VPC-Lastausgleichsfunktion erstellt.

IP-Adressen für ALBs in VPC-Clustern sind nicht statisch und können sich im Laufe der Zeit ändern. Daher stellen die VPC-Lastausgleichsfunktionen die öffentliche oder private IP-Adresse Ihrer ALBs hinter einen statischen Hostnamen. Separate Hostnamen werden für öffentliche oder private ALBs angewendet. Beachten Sie, dass der ALB-Hostname von der Ingress-Unterdomäne des Clusters getrennt ist.

Um den Hostnamen einer ALB in einem VPC-Cluster zu suchen, führen Sie ibmcloud ks ingress alb ls aus. Private Hostnamen werden nur aufgelistet, wenn private ALBs aktiviert sind.

Voraussetzungen für Workerknoten für ALBs

Pro Zone in Ihrem Cluster sind mindestens zwei Workerknoten erforderlich, damit ALBs mit hoher Verfügbarkeit funktionieren und regelmäßige Aktualisierungen empfangen. Anti-Affinitätsregeln für ALB-Pods stellen sicher, dass nur ein Pod für jeden Workerknoten geplant ist. Wenn automatische Updates auf ALB-Pods angewendet werden, wird der Pod neu geladen. Wenn Sie nur einen Workerknoten und daher einen ALB-Pod haben, wird der Pod nicht automatisch aktualisiert, um Datenverkehrsunterbrechungen zu vermeiden. Aktualisierungen werden nur angewendet, wenn Sie den Pod manuell löschen und einen neuen planen. Durch die Verwendung von mindestens zwei Workerknoten pro Zone wird dieses Szenario vermieden.

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-Zertifikat TLS

Wenn Sie einen Cluster erstellen, wird ein Standardzertifikat TLS erstellt, das Sie mit der von IBM bereitgestellten Ingress-Subdomäne verwenden können. Sie können das Standardzertifikat TLS oder ein benutzerdefiniertes Zertifikat, das Sie bereitstellen, in der Ingress-Ressource angeben.

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 beinhaltet die Erstellung oder den Import von Geheimnissen. Wenn Sie die IBM Cloud Ingress API verwenden möchten, um diese Schritte auszuführen, müssen Sie eine Standardinstanz Secrets Manager haben. Andernfalls können Sie Ihre Zertifikate mit kubectl-Befehlen kopieren.

Einführung in Ingress

Wenn Sie Ingress in Ihrem Cluster verwenden können, erstellen Sie eine Ingress-Ressource, um Ihre Ingress-Komponenten zu konfigurieren, Regeln für Routing-Anforderungen zu definieren und den Pfad zu App-Services anzugeben. Für jeden Namensbereich, der eine App oder einen Service enthält, die bzw. den Sie zugänglich machen möchten, ist eine separate Ingress-Ressource erforderlich.