Ingress-Operator

Der Red Hat OpenShift Ingress-Operator implementiert Routing-Regeln, die auf den gesamten eingehenden Datenverkehr für die Apps in Ihrem Cluster angewendet werden.

Die Ingress-Controller werden von dem Ingress-Operator verwaltet. Während der Clustererstellung wird der Ingress-Standardcontroller mit der Ingress-Standardunterdomäne für Ihren Cluster im Format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud registriert. Wenn Sie Ihre App bei dieser Unterdomäne registrieren, indem Sie eine Routenressource erstellen, stellt der Ingress-Controller sicher, dass Anforderungen an Ihre App über diese Unterdomäne ordnungsgemäß an Ihre App-Pods weitergeleitet werden. Führen Sie den Befehl oc describe ingresscontroller/default -n openshift-ingress-operator aus, um den Ingress-Standardcontroller in Ihrem Cluster anzuzeigen.

Wenn Sie Ihre App bei einer anderen Domäne registrieren möchten, können Sie einen angepassten Ingress-Controller erstellen, der stattdessen Routing-Regeln für eine angepasste Domäne bereitstellt.

Ingress-Controller

Für jeden IngressController wird ein HAProxy-basierter Red Hat OpenShift Ingress-Controller und ein Ingress-Controllerservice in jeder Zone erstellt, in der Sie über Workerknoten verfügen.

Der Ingress-Operator konfiguriert den Ingress-Controller mit derselben Domäne, die im IngressController angegeben ist. Der Ingress-Controller ist für eingehende HTTP-, HTTPS- oder TCP-Serviceanforderungen über diese Domäne empfangsbereit. Die Servicekomponente für die Lastausgleichsfunktion des Ingress-Controllers leitet dann Anforderungen an die Pods für diese App nur gemäß den Regeln weiter, die in der Routenressource definiert und vom Ingress-Controller implementiert wurden.

Wenn Sie über einen Cluster mit mehreren Zonen verfügen, wird ein Ingress-Hochverfügbarkeitscontroller in Ihrem Cluster bereitgestellt und mit einer VPC-Lastausgleichsfunktion mit mehreren Zonen konfiguriert. Pro Zone sind zwei Workerknoten erforderlich, sodass die beiden Replikate des Ingress-Controllers ordnungsgemäß bereitgestellt und aktualisiert werden können.

Wenn Sie einen Ingress-Controller manuell erstellen, wird der Ingress-Controller nicht automatisch bei der Ingress-Unterdomäne oder einer App in Ihrem Cluster registriert.

Routenressource

Um eine App mithilfe von Routen zugänglich zu machen, müssen Sie einen Kubernetes-Service für Ihre App erstellen und diesen Service beim Ingress-Controller registrieren, indem Sie eine Routenressource definieren. Die Ingress-Ressource ist eine Red Hat OpenShift-Ressource, die die Regeln für die Weiterleitung eingehender Anforderungen für Apps definiert.

Die Routenressource gibt auch den Pfad zu Ihren App-Services an. Die Pfade zu Ihren App-Services werden an die Ingress-Unterdomäne Ihres Clusters angefügt, um eine eindeutige App-URL wie z. B. mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1 zu bilden.

Eine Routenressource ist für jedes Projekt erforderlich, in dem Sie Apps zugänglich machen möchten.

• Wenn sich alle Apps in Ihrem Cluster in demselben Projekt befinden, müssen Sie eine Routenressource erstellen, um die Routingregeln für die Apps zu definieren, die Sie zugänglich machen möchten. Wenn Sie für die Apps in einem einzelnen Projekt unterschiedliche Domänen verwenden möchten, ist zu beachten, dass pro Domäne eine Ressource erstellt werden kann.
• Wenn sich die Apps in Ihrem Cluster in verschiedenen Projekten befinden, müssen Sie für jedes Projekt eine Routenressource erstellen, um die Routingregeln der App zu definieren.

Weitere Informationen finden Sie im Abschnitt Netzbetrieb für einzelne oder mehrere Projekte planen.

Wenn Sie Routing-Regeln für Ihre App anpassen möchten, können Sie routenspezifische HAProxy-Annotationen verwenden, die den Datenverkehr für Ihre App verwalten. Diese unterstützten Annotationen haben das Format haproxy.router.openshift.io/<annotation> oder router.openshift.io/<annotation>. Beachten Sie, dass IBM Cloud Kubernetes Service-Annotationen (ingress.bluemix.net/<annotation>) und NGINX-Annotationen (nginx.ingress.kubernetes.io/<annotation>) für den Ingress-Controller oder die Routenressource in Red Hat OpenShift Version 4 nicht unterstützt werden.

Einzelzonencluster

Das folgende Diagramm zeigt, wie Ingress die Kommunikation vom Internet zu einer App in einem klassischen Einzelzonencluster steuert.

1. Ein Benutzer sendet eine Anforderung an Ihre App, indem er auf die URL Ihrer App zugreift. Diese URL ist die Ingress-Unterdomäne für Ihren Cluster mit angehängtem Ingress-Ressourcenpfad für Ihre zugänglich gemachte App (z. B. mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

2. Ein DNS-Systemservice löst die Unterdomäne in der URL in die portierbare öffentliche IP-Adresse der Lastausgleichsfunktion auf, die den Ingress-Controller in Ihrem Cluster bereitstellt.

3. Basierend auf der aufgelösten IP-Adresse sendet der Client die Anforderung an den Ingress-Controllerservice.

4. Der Ingress-Controller überprüft die vom Ingress-Controller bereitgestellten Routingregeln für eine Routingregel für den Pfad myapp. Wenn eine übereinstimmende Regel gefunden wird, wird die Anforderung gemäß den Regeln, die Sie im Ingress-Controller definiert haben, und der Routenressource an den Pod weitergeleitet, in dem die App bereitgestellt wird. Die Quellen-IP-Adresse des Pakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, verteilt der Ingress-Controller die Anforderungen gleichmäßig auf die App-Pods.

5. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich der Ingress-Controller befindet, der die Anforderung weitergeleitet hat. Der Ingress-Controller sendet dann das Antwortpaket an den Client.

Mehrzonencluster

Das folgende Diagramm zeigt, wie Ingress die Kommunikation vom Internet zu einer App in einem klassischen Mehrzonencluster steuert.

1. Ein Benutzer sendet eine Anforderung an Ihre App, indem er auf die URL Ihrer App zugreift. Diese URL ist die Ingress-Unterdomäne für Ihren Cluster mit angehängtem Ingress-Ressourcenpfad für Ihre zugänglich gemachte App (z. B. mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

2. Ein DNS-Systemservice löst die Unterdomäne der Route in die variable öffentliche IP-Adresse eines Ingress-Controllerservice auf, der von der MZLB als einwandfrei gemeldet wurde. Die MZLB überprüft kontinuierlich die portierbaren öffentlichen IP-Adressen der Services, die den Ingress-Controller in jeder Zone in Ihrem Cluster zugänglich machen. Anforderungen werden von den Ingress-Controllerservices in verschiedenen Zonen in einem Umlaufzyklus verarbeitet.

3. Der Client sendet die Anforderung an die IP-Adresse des Service, der den Ingress-Controller zugänglich macht.

4. Der Ingress-Controller überprüft die vom Ingress-Controller implementierten Routingregeln für den Pfad myapp. Wenn eine übereinstimmende Regel gefunden wird, wird die Anforderung gemäß den Regeln weitergeleitet, die Sie in der IngressController-Ressource und der Routenressource für den Pod definiert haben, in dem die App bereitgestellt wird. Die Quellen-IP-Adresse des Pakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, sendet der Ingress-Controllerservice die Anforderungen zwischen den App-Pods über alle Zonen.

5. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem der Ingress-Controllerservice vorhanden ist, der die Anforderung weitergeleitet hat. Der Ingress-Controller sendet dann das Antwortpaket an den Client.

VPC-Cluster mit Public-Cloud-Serviceendpunkt

Wenn Sie einen VPC-Cluster mit mehreren Zonen mit aktiviertem öffentlichen Cloud-Serviceendpunkt erstellen, wird standardmäßig ein öffentlicher Ingress-Controller erstellt. Das folgende Diagramm zeigt, wie Ingress die Kommunikation vom Internet zu einer App in einem VPC-Mehrzonencluster steuert.

1. Ein Benutzer sendet eine Anforderung an Ihre App, indem er auf die URL Ihrer App zugreift. Diese URL ist die Ingress-Unterdomäne für Ihren Cluster für die zugänglich gemachte App mit dem Ingress-Ressourcenpfad (z. B. mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp).

2. Ein DNS-Service löst die Routenunterdomäne in den Hostnamen der VPC-Lastausgleichsfunktion auf, der dem Ingress-Controller zugeordnet ist. In VPC-Clustern sind die externen IP-Adressen variabel und werden hinter einem von der VPC zugeordneten Hostnamen verborgen.

3. Die VPC-Lastausgleichsfunktion löst den VPC-Hostnamen in eine verfügbare IP-Adresse in einer Zone für den Ingress-Controller auf, die als in einwandfreiem Zustand gemeldet wurde. Die VPC-Lastausgleichsfunktion überprüft kontinuierlich die externen IP-Adressen für den Ingress-Controller in jeder Zone in Ihrem Cluster.

4. Basierend auf der aufgelösten IP-Adresse sendet die VPC-Lastausgleichsfunktion die Anforderung an einen Ingress-Controller.

5. Der Ingress-Controller überprüft die vom Ingress-Controller implementierten Routingregeln für den Pfad myapp. Wenn eine übereinstimmende Regel gefunden wird, wird die Anforderung gemäß den Regeln weitergeleitet, die Sie in der IngressController-Ressource und der Routenressource für den Pod definiert haben, in dem die App bereitgestellt wird. Die Quellen-IP-Adresse des Pakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, verteilt der Ingress-Controller die Anforderungen zwischen den App-Pods gleichmäßig auf alle Zonen.

6. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem der Ingress-Controllerservice vorhanden ist, der die Anforderung weitergeleitet hat. Die VPC-Lastausgleichsfunktion sendet dann das Antwortpaket an den Client.

VPC-Cluster nur mit Private-Cloud-Serviceendpunkt

Wenn Sie einen VPC-Cluster mit mehreren Zonen nur mit dem privaten Cloud-Serviceendpunkt erstellen, wird standardmäßig ein privater Ingress-Controller erstellt. Nur Clients, die mit Ihrem privaten VPC-Netz verbunden sind, können auf Apps zugreifen, die von einem privaten Ingress-Controller zugänglich gemacht werden. Das folgende Diagramm zeigt, wie Ingress die Kommunikation von privaten Netzen zu einer App in einem VPC-Mehrzonencluster steuert.

1. Ein Client, der mit Ihrem privaten VPC-Netz verbunden ist, sendet mithilfe der URL Ihrer App eine Anforderung an Ihre App. Diese URL ist die Ingress-Unterdomäne für Ihren Cluster für die zugänglich gemachte App mit dem Ingress-Ressourcenpfad (z. B. mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp). Sie können zum Beispiel die Virtual Private Cloud VPN, IBM Cloud Transit Gateway oder IBM Cloud Direct Link verwenden, um Anforderungen von einem lokalen Netz, einer anderen VPC oder klassischen IBM Cloud-Infrastruktur an Apps zuzulassen, die in Ihrem Cluster ausgeführt werden.

2. Ein DNS-Service löst die Routenunterdomäne in den Hostnamen der VPC-Lastausgleichsfunktion auf, der den Services für den Ingress-Controller zugeordnet ist. In VPC-Clustern sind die privaten IP-Adressen der Ingress-Controllerservices variabel und werden hinter einem von VPC zugewiesenen Hostnamen aufbewahrt. Beachten Sie, dass der DNS-Datensatz für die Route-Unterdomäne zwar im öffentlichen DNS-System registriert ist, die Server für die DNS-Auflösung aber auch von der VPC erreichbar sein müssen.

3. Die private VPC-Lastausgleichsfunktion löst den VPC-Hostnamen in eine verfügbare private IP-Adresse eines Ingress-Controllerservice auf, der als in einwandfreiem Zustand gemeldet wurde. Die VPC-Lastausgleichsfunktion überprüft kontinuierlich die IP-Adressen der Services, die den Ingress-Controller in jeder Zone in Ihrem Cluster zugänglich machen.

4. Basierend auf der aufgelösten IP-Adresse sendet die VPC-Lastausgleichsfunktion die Anforderung an einen Ingress-Controllerservice.

5. Der Ingress-Controller überprüft die vom Ingress-Controller implementierten Routingregeln für den Pfad myapp. Wenn eine übereinstimmende Regel gefunden wird, wird die Anforderung gemäß den Regeln weitergeleitet, die Sie in der IngressController-Ressource und der Routenressource für den Pod definiert haben, in dem die App bereitgestellt wird. Die Quellen-IP-Adresse des Pakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, verteilt der Ingress-Controller die Anforderungen zwischen den App-Pods gleichmäßig auf alle Zonen.

6. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich der Ingress-Controller befindet, der die Clientanforderung weitergeleitet hat. Der Ingress-Controller sendet dann das Antwortpaket über die VPC-Lastausgleichsfunktion an den Client.