Datenfluss in einem klassischen Einzelzonencluster

Das folgende Diagramm zeigt, wie ein Router Netzverkehr vom Internet an eine App in einem klassischen Einzelzonencluster überträgt.

1. Eine Anforderung an Ihre App verwendet den Hostnamen für die Route, den Sie für Ihre App festgelegt haben.

2. Ein DNS-Service löst die Unterdomäne in die portierbare öffentliche IP-Adresse eines Router-Service auf.

3. Der Router empfängt die Anforderung und leitet sie über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der Router-Pod ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, sendet der Router die Anforderungen zwischen den App-Pods.

4. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich der Router, der die Clientanforderung weitergeleitet hat, befindet. Der Router sendet daraufhin das Antwortpaket über den Lastausgleichsservice an den Client.

Datenfluss in einem klassischen Mehrzonencluster

Das folgende Diagramm zeigt, wie ein Router den Netzverkehr vom Internet an eine App in einem klassischen Cluster mit mehreren Zonen überträgt.

1. Eine Anforderung an Ihre App verwendet den Hostnamen für die Route, den Sie für Ihre App festgelegt haben.

2. Ein DNS-Service löst die Routenunterdomäne in die portierbare öffentliche IP-Adresse eines Router-Service auf, der von der MZLB (Mehrzonenlastausgleichsfunktion) als in einwandfreiem Zustand gemeldet wurde. Die MZLB überprüft fortlaufend die portierbaren öffentlichen IP-Adressen der Services, die den Router in jeder Zone Ihres Clusters zugänglich machen. Anforderungen werden von den Router-Services in verschiedenen Zonen in einem Umlaufzyklus bearbeitet.

3. Nach Auflösung der IP-Adresse des Routerservice empfängt der Router die Anforderung.

4. Der Router leitet die Anforderung über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der Router-Pod ausgeführt wird. Jeder Router sendet Anforderungen an die App-Instanzen in der eigenen Zone und an App-Instanzen in anderen Zonen weiter. Wenn mehrere App-Instanzen in einer Zone bereitgestellt sind, alterniert der Router Anforderungen zwischen den App-Pods.

5. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich der Router, der die Clientanforderung weitergeleitet hat, befindet. Der Router sendet daraufhin das Antwortpaket über den Lastausgleichsservice an den Client.

Datenfluss in einem VPC-Mehrzonencluster 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. Der Ingress-Controller weist öffentlich zugängliche Routen für Ihre Apps zu und ist empfangsbereit für Anforderungen an Ihre Apps in der öffentlichen Hostnetzschnittstelle.

Das folgende Diagramm zeigt, wie ein Ingress-Controller den Netzverkehr aus dem Internet an eine App in einem VPC-Cluster mit mehreren Zonen überträgt.

1. Eine Anforderung an Ihre App verwendet den Hostnamen für die Route, den Sie für Ihre App festgelegt haben.

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 externen IP-Adressen Ihrer Ingress-Controller-Services variabel und werden hinter einem von VPC zugewiesenen Hostnamen aufbewahrt.

3. Die VPC-Lastausgleichsfunktion löst den VPC-Hostnamen in eine verfügbare externe IP-Adresse eines Ingress-Controllerservice auf, der als in einwandfreiem Zustand gemeldet wurde. Die VPC-Lastausgleichsfunktion überprüft kontinuierlich die externen 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 leitet die Anforderung über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Jeder Ingress-Controller sendet Anforderungen an die App-Instanzen in seiner eigenen Zone und an App-Instanzen in anderen Zonen. Wenn mehrere App-Instanzen in einer Zone bereitgestellt werden, alterniert der Ingress-Controller zusätzlich Anforderungen zwischen App-Pods.

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.

Datenfluss in einem VPC-Mehrzonencluster 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. Der Ingress-Controller ordnet privat zugängliche Routen für Ihre Apps zu und überwacht die Netzschnittstelle des privaten Hosts. Nur Clients, die mit Ihrem privaten VPC-Netz verbunden sind, können auf Apps zugreifen, die von einer privaten Route zugänglich gemacht werden.

Das folgende Diagramm zeigt, wie ein Ingress-Controller den Netzverkehr von privaten Netzen an eine App in einem VPC-Cluster mit mehreren Zonen überträgt.

1. Ein Client, der mit Ihrem privaten VPC-Netz verbunden ist, sendet mithilfe der privaten Route der App eine Anforderung an Ihre App. 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 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 leitet die Anforderung über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die IP-Adresse des Workerknotens geändert, auf dem der Pod des Ingress-Controllers ausgeführt wird. Jeder Ingress-Controller sendet Anforderungen an die App-Instanzen in seiner eigenen Zone und an App-Instanzen in anderen Zonen. Wenn mehrere App-Instanzen in einer Zone bereitgestellt werden, alterniert der Ingress-Controller zusätzlich Anforderungen zwischen App-Pods.

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 das Antwortpaket dann über die VPC-Lastausgleichsfunktion und über die IBM Cloud VPC-VPN, Transit Gateway oder Direct Link an den Client.

Öffentliche Routen in klassischen Clustern oder VPC-Clustern mit Public-Cloud-Serviceendpunkt einrichten

Wenn Ihr Cluster auf einer klassischen Infrastruktur erstellt wurde oder wenn Ihr Cluster auf einer VPC-Infrastruktur erstellt wurde und Sie während der Clustererstellung den Endpunkt für den öffentlichen Cloud-Service aktiviert haben, wird Ihr Cluster standardmäßig mit einem öffentlichen Ingress-Controller erstellt. Mit diesem Ingress-Controller können Sie öffentliche Routen für Ihre App erstellen.

1. Erstellen Sie einen Kubernetes Service ClusterIP für Ihre App-Bereitstellung. Der Service stellt eine interne IP-Adresse, an die der Ingress-Controller Datenverkehr senden kann, für die App bereit.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Wählen Sie eine Domäne für Ihre App aus. Beachten Sie, dass Routen-URLs maximal 130 Zeichen lang sein dürfen. IBM-provided domain: Wenn Sie keine benutzerdefinierte Domäne verwenden müssen, wird ein Routen-Hostname im Format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Angepasste Domäne: Um eine angepasste Domäne anzugeben, arbeiten Sie mit Ihrem DNS-Provider oder IBM Cloud® Internet Services.

   1. Rufen Sie die öffentliche IP-Adresse für den öffentlichen Ingress-Controllerservice in jeder Zone in der Spalte EXTERNAL-IP ab. Beachten Sie, dass der Ingress-Controllerservice in der ersten Zone, in der Sie über Workerknoten verfügen, immer den Namen router-default hat und Ingress-Controllerservices in den Zonen, die Sie später zu Ihrem Cluster hinzufügen, Namen wie router-dal12 haben.

      oc get svc -n openshift-ingress
      

   2. Erstellen Sie eine angepasste Domäne mit Ihrem DNS-Provider. Wenn Sie dieselbe Unterdomäne für mehrere Services in Ihrem Cluster verwenden wollen, können Sie eine Platzhalterunterdomäne wie beispielsweise *.example.com registrieren.

   3. Ordnen Sie Ihre angepasste Domäne der öffentlichen IP-Adresse des Ingress-Controllers zu, indem Sie die IP-Adresse als A-Datensatz hinzufügen.

3. Richten Sie eine Route entsprechend dem Typ der von Ihrer App erforderten TLS-Terminierung ein. Wenn Sie keine benutzerdefinierte Domäne haben, lassen Sie die Option --hostname weg. Ein Routenhostname wird für Sie im Format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud generiert. Wenn Sie eine Platzhalterunterdomäne registriert haben, geben Sie in jeder erstellten Route eine eindeutige Unterdomäne an. Beispielsweise können Sie in dieser Route --hostname svc1.example.com und in einer anderen Route --hostname svc2.example.com angeben.

   • Einfach:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • Passthrough:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Müssen HTTP/2-Verbindungen verarbeitet werden? Nachdem Sie die Route erstellt haben, führen Sie oc edit route <app_service_name> aus und ändern Sie den targetPort-Wert der Route in https. Sie können die Route testen, indem Sie curl -I --http2 https://<route> --insecure ausführen.
   • Rand: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift edge route.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Neu verschlüsseln: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift re-encrypt route.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

4. Vergewissern Sie sich, dass die Route für Ihren App-Service erstellt wurde.

   oc get routes
   

5. Optional: Passen Sie die Standard-Routing-Regeln mit optionalen Konfigurationen an. Sie können zum Beispiel streckenspezifische HAProxy Anmerkungen verwenden.

Öffentliche Routen in VPC-Clustern nur mit einem Private-Cloud-Serviceendpunkt einrichten

Wenn Ihr Cluster in der VPC-Infrastruktur erstellt wird und Sie während der Clustererstellung nur den privaten Cloud-Serviceendpunkt aktiviert haben, wird Ihr Cluster standardmäßig nur mit einem privaten Router erstellt. Um Ihre Apps öffentlich zugänglich zu machen, müssen Sie zuerst eine öffentliche IngressController-Ressource erstellen und diese mit einer Unterdomäne konfigurieren. Der Ingress-Operator erstellt und konfiguriert automatisch einen neuen öffentlichen Ingress-Controller auf der Basis des IngressControllers, mit dem Sie öffentliche Routen für Ihre Apps erstellen können.

Beachten Sie, dass auch wenn Sie in den folgenden Schritten eine IngressController-Ressource erstellen, der IngressController nur zum Erstellen und Konfigurieren des erforderlichen Ingress-Controllers erforderlich ist. Nach der Erstellung des Ingress-Controllers verwenden Sie den Ingress-Controller direkt zum Erstellen von Routen.

1. Bereiten Sie die Domäne vor, die Sie für Ihren Ingress-Controller verwenden wollen.

   • Angepasste Domäne: Arbeiten Sie mit Ihrem DNS-Provider (Domain Name Service) oder IBM Cloud-DNS, um eine angepasste Domäne zu registrieren. Wenn Sie dieselbe Unterdomäne für mehrere Services in Ihrem Cluster verwenden wollen, können Sie eine Platzhalterunterdomäne wie beispielsweise *.example.com registrieren. Wenn Sie eine angepasste Domäne verwenden, müssen Sie auch das Domänenzertifikat in Ihrer IngressController-Spezifikation angeben. Weitere Informationen finden Sie unter Angepasstes Standardzertifikat festlegen.
   • Von IBM bereitgestellte Domäne:
     1. Listen Sie die vorhandenen Unterdomänen in Ihrem Cluster auf. Kopieren Sie in der Spalte Unterdomäne der Ausgabe die Unterdomäne mit dem höchsten 000<n>-Wert.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        In dieser Beispielausgabe hat die Unterdomäne mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud den höchsten 000<n>-Wert von 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Ändern Sie in der kopierten Unterdomäne den 000<n>-Wert in der Unterdomäne auf 000<n+1>. Zum Beispiel wird die Subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud in mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud geändert. Diese Unterdomäne werden Sie in späteren Schritten registrieren.

2. Erstellen Sie eine YAML-Datei, die einen öffentlichen Ingress-Controller mit der Domäne aus Schritt 1 konfiguriert.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: public
     namespace: openshift-ingress-operator
   spec:
     # defaultCertificate: If you are using a custom domain, specify the domain certificate
       # name: custom-certs-default
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: External
       type: LoadBalancerService
   

3. Erstellen Sie die IngressController-Ressource im openshift-ingress-operator-Namensbereich Ihres Clusters. Wenn Sie den IngressController erstellen, wird automatisch ein öffentlicher Ingress-Controller erstellt und im openshift-ingress-Namensbereich basierend auf den IngressController-Einstellungen bereitgestellt. Außerdem wird ein Ingress-Controllerservice erstellt, um den Ingress-Controller zugänglich zu machen.

   oc create -f public.yaml -n openshift-ingress-operator
   

4. Rufen Sie den VPC-Hostnamen aus dem Feld EXTERNAL IP des Service router-public ab. In VPC-Clustern sind die externen IP-Adressen Ihrer Router-Services variabel und werden stattdessen hinter einem von der VPC zugeordneten Hostnamen verborgen.

   oc get svc router-public -n openshift-ingress
   

   Beispielausgabe

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Registrieren Sie den VPC-Hostnamen des Service bei der in Schritt 1 ausgewählten Domäne. Dieser Schritt stellt sicher, dass die IP-Adressen Ihrer Ingress-Controller-Services, die sich hinter dem VPC-Hostnamen befinden, mit der Domäne registriert werden, die Sie für den Ingress-Controller ausgewählt haben.

   • Angepasste Domäne: Stimmen Sie mit Ihrem DNS-Provider das Hinzufügen des VPC-Hostnamens für den Service als CNAME ab, der Ihrer angepassten Domäne zugeordnet wird.

   • Von IBM bereitgestellte Domäne: Erstellen Sie einen DNS-Eintrag für den VPC-Hostnamen des Service. Wenn Sie den folgenden Befehl ausführen, wird die in Schritt 2 angegebene Unterdomäne automatisch generiert und beim Ingress-Controllerservice registriert.

     ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
     

6. Optional: Wenn Sie das Ingress-Controller-Sharding verwenden möchten, damit bestimmte Routen von einem bestimmten Ingress-Controller verarbeitet werden, z. B. private Routen nur für einen privaten Router zugelassen werden, dann können Sie entweder Routenbezeichnungen oder Namensbereichsbezeichnungen verwenden, um die Sharding-Methode anzugeben. Um den Selektor während der Erstellungszeit hinzuzufügen, schließen Sie ihn in die ingresscontroller-YAML unter spec ein. Wenn Sie beispielsweise zulassen möchten, dass ein Ingress-Controller nur Ingress/Routen mit der Bezeichnung type=sharded verarbeitet, können Sie eine routeSelector hinzufügen. Weitere Informationen finden Sie unter Ingress-Controller-Sharding.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Um Selektoren zu einem vorhandenen Ingress-Controller hinzuzufügen, rufen Sie eine Liste der Ingress-Controller ab.

      oc get ingresscontroller -n openshift-ingress-operator
      

   2. Fügen Sie die Selektoren zu Ingress-Controllern hinzu, auf denen Sie Sharding verwenden möchten.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. Beachten Sie, dass dem Standard-IngressController keine Selektoren hinzugefügt werden, sodass alle Routen weiterhin zum Standard-Ingress-Controller im Cluster zugelassen werden. Sie können die relevante Route oder Namensbereichsbezeichnungsselektoren verwenden, um dieses Verhalten zu ändern. Um beispielsweise den Standardrouter so anzupassen, dass Ingress/Routen mit der Bezeichnung type=sharded übersprungen werden, führen Sie den folgenden Patchbefehl aus.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

      Mehrere Routen und Ingresses im Cluster hängen vom standardmäßigen öffentlichen Ingress-Controller ab. Stellen Sie sicher, dass die Änderungen korrekt sind, bevor Sie den Standard-Ingress-Controller bearbeiten. Weitere Informationen zu finden Sie unter Ingress-Controller-Sharding.

7. Erstellen Sie einen Kubernetes Service ClusterIP für Ihre App-Bereitstellung. Der Service stellt eine interne IP-Adresse, an die der Ingress-Controller Datenverkehr senden kann, für die App bereit.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Richten Sie eine Route entsprechend dem Typ der von Ihrer App erforderten TLS-Terminierung ein. Wenn Sie die Option --hostname nicht angeben, wird der Hostname der Route für Sie im Format <app_service_name>-<app_project>.<router-subdomain> generiert.

   • Einfach:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • Passthrough:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Müssen HTTP/2-Verbindungen verarbeitet werden? Nachdem Sie die Route erstellt haben, führen Sie oc edit route <app_service_name> aus und ändern Sie den targetPort-Wert der Route in https. Sie können die Route testen, indem Sie curl -I --http2 https://<route> --insecure ausführen.
   • Rand: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift edge route.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Neu verschlüsseln: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift re-encrypt route.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

9. Vergewissern Sie sich, dass die Route für Ihre App erstellt wurde.

   oc get routes
   

10. Optional: Passen Sie die Routing-Regeln des öffentlichen Ingress-Controllers mit optionalen Konfigurationenan. Sie können zum Beispiel streckenspezifische HAProxy Anmerkungen verwenden.

11. Zum Erstellen von Routen für weitere Apps unter Verwendung derselben Unterdomäne können Sie die Schritte 7 bis 10 wiederholen, sodass die Route von demselben öffentlichen Ingress-Controller generiert wird. Wenn Sie Routen für weitere Apps unter Verwendung einer anderen Unterdomäne erstellen möchten, wiederholen Sie alle Schritte in diesem Abschnitt, um einen neuen öffentlichen Ingress-Controller mit einer anderen Domäne zu erstellen.

Private Routen in klassischen Clustern oder VPC-Clustern mit Public-Cloud-Serviceendpunkt einrichten

Wenn Ihr Cluster auf einer klassischen Infrastruktur erstellt wird oder wenn Ihr Cluster auf einer VPC-Infrastruktur erstellt wird und Sie während der Clustererstellung den Endpunkt für den öffentlichen Cloud-Service aktiviert haben, wird Ihr Cluster standardmäßig nur mit einem öffentlichen Ingress-Controller erstellt. Um Ihre Apps privat zugänglich zu machen, müssen Sie zuerst eine private IngressController-Ressource erstellen und den Controller mit einer Unterdomäne konfigurieren. Der Ingress-Operator erstellt automatisch einen neuen privaten Ingress-Controller, mit dem Sie private Routen für Ihre Apps erstellen können.

Beachten Sie, dass auch wenn Sie in den folgenden Schritten eine IngressController-Ressource erstellen, die IngressController-Ressource nur erforderlich ist, um den erforderlichen Ingress-Controller für Sie zu erstellen und zu konfigurieren. Nach der Erstellung des Ingress-Controllers verwenden Sie den Router direkt, um Routen zu erstellen.

1. Bereiten Sie die Domäne vor, die Sie für Ihren Ingress-Controller verwenden wollen.

   • Angepasste Domäne in klassischen oder VPC-Clustern: Arbeiten Sie mit Ihrem DNS-Provider (Domain Name Service) oder IBM Cloud-DNS, um eine angepasste Domäne zu registrieren. Wenn Sie dieselbe Unterdomäne für mehrere Services in Ihrem Cluster verwenden wollen, können Sie eine Platzhalterunterdomäne wie beispielsweise *.example.com registrieren.
   • Von IBM bereitgestellte Domäne in VPC-Clustern:
     1. Listen Sie die vorhandenen Unterdomänen in Ihrem Cluster auf. Kopieren Sie in der Spalte Unterdomäne der Ausgabe die Unterdomäne mit dem höchsten 000<n>-Wert.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        In dieser Beispielausgabe hat die Unterdomäne mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud den höchsten 000<n>-Wert von 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Ändern Sie in der kopierten Unterdomäne den 000<n>-Wert in der Unterdomäne auf 000<n+1>. Zum Beispiel wird die Subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud in mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud geändert. Diese Unterdomäne werden Sie in späteren Schritten registrieren.

2. Erstellen Sie eine Konfigurationsdatei für einen privaten Ingress-Controller mit der Domäne aus Schritt 1.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: private
     namespace: openshift-ingress-operator
   spec:
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: Internal
       type: LoadBalancerService
   

3. Erstellen Sie die IngressController-Ressource im openshift-ingress-operator-Namensbereich Ihres Clusters. Wenn Sie die IngressController-Ressource erstellen, wird automatisch ein privater Ingress-Controller erstellt und im openshift-ingress-Namensbereich basierend auf den IngressController-Einstellungen bereitgestellt. Außerdem wird ein Ingress-Controllerservice erstellt, um den Ingress-Controller mit einer IP-Adresse (klassische Cluster) oder einem VPC-Hostnamen (VPC-Cluster) zugänglich zu machen.

   oc create -f private.yaml -n openshift-ingress-operator
   

4. Rufen Sie die IP-Adresse oder den VPC-Hostnamen aus dem Feld EXTERNAL IP des Service router-private ab.

   oc get svc router-private -n openshift-ingress
   

   Beispielausgabe für klassische Cluster:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
   

   Beispielausgabe für VPC-Cluster:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Registrieren Sie die externe IP-Adresse oder den VPC-Hostnamen des Service in der Domäne, die Sie in Schritt 1 ausgewählt haben.

   • Angepasste Domäne, klassische Cluster oder VPC-Cluster: Stimmen Sie mit Ihrem DNS-Provider das Hinzufügen der externen IP-Adresse des Service als A-Datensatz (klassische Cluster) oder des VPC-Hostnamens als CNAME (VPC-Cluster) ab, der Ihrer angepassten Domäne zugeordnet wird.
   • Von IBM bereitgestellte Domäne (nur VPC-Cluster): Erstellen Sie einen DNS-Eintrag für den VPC-Hostnamen des Service. Wenn Sie den folgenden Befehl ausführen, wird die in Schritt 2 angegebene Unterdomäne automatisch generiert und beim Ingress-Controllerservice registriert.

     ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
     

6. Optional: Wenn Sie das Ingress-Controller-Sharding verwenden möchten, damit bestimmte Routen von einem bestimmten Ingress-Controller verarbeitet werden, z. B. private Routen nur für einen privaten Router zugelassen werden, dann können Sie entweder Routenbezeichnungen oder Namensbereichsbezeichnungen verwenden, um die Sharding-Methode anzugeben. Um den Selektor während der Erstellungszeit hinzuzufügen, schließen Sie ihn in die ingresscontroller-YAML unter spec ein. Wenn Sie beispielsweise zulassen möchten, dass ein Ingress-Controller nur Ingress/Routen mit der Bezeichnung type=sharded verarbeitet, können Sie eine routeSelector hinzufügen. Weitere Informationen finden Sie unter Ingress-Controller-Sharding.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Um Selektoren zu einem vorhandenen Ingress-Controller hinzuzufügen, rufen Sie eine Liste der Ingress-Controller ab.

      oc get ingresscontroller -n openshift-ingress-operator
      

   2. Fügen Sie die Selektoren zu Ingress-Controllern hinzu, auf denen Sie Sharding verwenden möchten.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. Beachten Sie, dass dem Standard-IngressController keine Selektoren hinzugefügt werden, sodass alle Routen weiterhin zum Standard-Ingress-Controller im Cluster zugelassen werden. Sie können die relevante Route oder Namensbereichsbezeichnungsselektoren verwenden, um dieses Verhalten zu ändern. Um beispielsweise den Standardrouter so anzupassen, dass Ingress/Routen mit der Bezeichnung type=sharded übersprungen werden, führen Sie den folgenden Patchbefehl aus.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

7. Erstellen Sie einen Kubernetes Service ClusterIP für Ihre App-Bereitstellung. Der Service stellt eine interne IP-Adresse, an die der Ingress-Controller Datenverkehr senden kann, für die App bereit.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Richten Sie eine Route entsprechend dem Typ der von Ihrer App erforderten TLS-Terminierung ein. Geben Sie den Hostnamen an, den Sie in Schritt 5 eingerichtet haben.

   • Einfach:

     oc expose service <app_service_name> --hostname <subdomain>
     

   • Passthrough:

     oc create route passthrough --service <app_service_name> --hostname <subdomain>
     

     Müssen HTTP/2-Verbindungen verarbeitet werden? Nachdem Sie die Route erstellt haben, führen Sie oc edit route <app_service_name> aus und ändern Sie den targetPort-Wert der Route in https. Sie können die Route testen, indem Sie curl -I --http2 https://<route> --insecure ausführen.
   • Edge: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift edge route.

     oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Neu verschlüsseln: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift re-encrypt route.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

9. Vergewissern Sie sich, dass die Route für Ihre App erstellt wurde.

   oc get routes
   

10. Optional: Passen Sie die Routing-Regeln des privaten Ingress-Controllers mit optionalen Konfigurationenan. Sie können zum Beispiel streckenspezifische HAProxy Anmerkungen verwenden.

11. Um Routen für weitere Apps mithilfe derselben Unterdomäne zu erstellen, können Sie die Schritte 7 bis 10 wiederholen, sodass die Route von demselben privaten Ingress-Controller generiert wird. Wenn Sie Routen für weitere Apps unter Verwendung einer anderen Unterdomäne erstellen möchten, wiederholen Sie alle Schritte in diesem Abschnitt, um einen neuen privaten Ingress-Controller zu erstellen.

Private Routen in VPC-Clustern nur mit einem Private-Cloud-Serviceendpunkt einrichten

Wenn Ihr Cluster in der VPC-Infrastruktur erstellt wird und Sie während der Clustererstellung den einzigen privaten Cloud-Serviceendpunkt aktiviert haben, wird Ihr Cluster standardmäßig mit einem privaten Ingress-Controller erstellt. Mit diesem Ingress-Controller können Sie private Routen für Ihre App erstellen.

1. Erstellen Sie einen Kubernetes Service ClusterIP für Ihre App-Bereitstellung. Der Service stellt eine interne IP-Adresse, an die der Ingress-Controller Datenverkehr senden kann, für die App bereit.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Wählen Sie eine Domäne für Ihre App aus.

   • Von IBM bereitgestellte Domäne: Wenn Sie keine angepasste Domäne benötigen, wird eine Routenunterdomäne im Format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud generiert.
   • Angepasste Domäne: Um eine angepasste Domäne anzugeben, arbeiten Sie mit Ihrem DNS-Provider oder IBM Cloud® Internet Services.

     1. Rufen Sie die externe IP-Adresse für den privaten Ingress-Controllerservice in jeder Zone in der Spalte EXTERNAL-IP ab. Beachten Sie, dass der Ingress-Controllerservice in der ersten Zone, in der Sie über Workerknoten verfügen, immer den Namen router-default hat und Ingress-Controllerservices in den Zonen, die Sie später zu Ihrem Cluster hinzufügen, Namen wie router-dal12 haben.

        oc get svc -n openshift-ingress
        

     2. Erstellen Sie eine angepasste Domäne mit Ihrem DNS-Provider. Wenn Sie dieselbe Unterdomäne für mehrere Services in Ihrem Cluster verwenden wollen, können Sie eine Platzhalterunterdomäne wie beispielsweise *.example.com registrieren.

     3. Ordnen Sie Ihre angepasste Domäne der privaten IP-Adresse der Ingress-Controllerservices zu, indem Sie die IP-Adressen als A-Datensätze hinzufügen.

3. Richten Sie eine Route basierend auf dem Typ der TLS-Terminierung, die Ihre App erfordert, ein. Wenn Sie keine benutzerdefinierte Domäne haben, lassen Sie die Option --hostname weg. Es wird eine Routenunterdomäne im Format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud generiert. Wenn Sie eine Platzhalterunterdomäne registriert haben, geben Sie in jeder erstellten Route eine eindeutige Unterdomäne an. Beispielsweise können Sie in dieser Route --hostname svc1.example.com und in einer anderen Route --hostname svc2.example.com angeben.

   • Einfach:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • Passthrough:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Müssen HTTP/2-Verbindungen verarbeitet werden? Nachdem Sie die Route erstellt haben, führen Sie oc edit route <app_service_name> aus und ändern Sie den targetPort-Wert der Route in https. Sie können die Route testen, indem Sie curl -I --http2 https://<route> --insecure ausführen.

   • Rand: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift edge route.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Neu verschlüsseln: Wenn Sie eine benutzerdefinierte Domäne verwenden, fügen Sie die Optionen --hostname, --cert und --key sowie optional die Option --ca-cert hinzu. Weitere Informationen zu den Anforderungen an TLS-Zertifikate finden Sie in der Dokumentation Red Hat OpenShift re-encrypt route.

     oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

4. Vergewissern Sie sich, dass die Route für Ihren App-Service erstellt wurde.

   oc get routes
   

5. Optional: Passen Sie die Standard-Routing-Regeln mit optionalen Konfigurationen an. Sie können zum Beispiel streckenspezifische HAProxy Anmerkungen verwenden.