Erklärung der Optionen für die Bereitstellung von Apps

Um Ihre Apps sicher für den externen Datenverkehr zugänglich zu machen, können Sie aus den folgenden Diensten wählen.

Red Hat OpenShift Ingress-Controller

Stellen Sie mehrere Anwendungen in einem Cluster bereit, indem Sie das Routing mit dem Ingress-Controller „ Red Hat OpenShift “ einrichten. Der Ingress-Controller verwendet die Ingress-Unterdomäne als geschützten und eindeutigen öffentlichen oder privaten Einstiegspunkt für die Weiterleitung eingehender Anforderungen. Sie können eine Unterdomäne verwenden, um mehrere Apps in Ihrem Cluster als Services zugänglich zu machen. Die Ingress-Controller-Lösung verwendet drei Komponenten.

• Der Ingress-Operator, der die Ingress-Controller in Ihrem Cluster verwaltet.
• Der Ingress-Controller ist ein HAProxy-basierter Kubernetes Service, der den gesamten eingehenden Datenverkehr für die Apps in Ihrem Cluster verwaltet, indem Routing-Regeln für die Apps implementiert werden. Dieser Controller wird vom Ingress-Operator verwaltet. Der Ingress-Controller ist für eingehende HTTP- oder HTTPS-Serviceanforderungen empfangsbereit und leitet anschließend Anforderungen an die Pods für diese App nur gemäß den Regeln weiter, die in der Ingress-Ressource definiert und vom Ingress-Controller bereitgestellt wurden.
• Die Ressource "Route" definiert die Regeln für die Weiterleitung und den Lastausgleich eingehender Anforderungen für eine App.

Eine Route stellt einen Service als Hostnamen im Format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud bereit. Ein Ingress-Controller wird standardmäßig in Ihrem Cluster bereitgestellt, sodass Routen von externen Clients verwendet werden können. Der Ingress-Controller verwendet den Serviceselektor, um den Service und die Endpunkte zu suchen, die den Service unterstützen. Sie können den Serviceselektor so konfigurieren, dass der Datenverkehr über eine einzige Route an mehrere Services weitergeleitet wird. Sie können auch nicht gesicherte oder gesicherte Routen erstellen, indem Sie das TLS-Zertifikat verwenden, das vom Ingress-Controller für Ihren Hostnamen zuwiesen wird. Beachten Sie, dass der Ingress-Controller nur die HTTP- und HTTPS-Protokolle unterstützt.

NodePort

Wenn Sie Ihre App mit einem NodePort-Service zugänglich machen, werden dem Service eine Knotenportnummer im Zahlenbereich 30000-32767 und eine interne Cluster-IP-Adresse zugewiesen. Für den Zugriff auf den Service von außerhalb des Clusters verwenden Sie die öffentliche oder private IP-Adresse eines beliebigen Workerknotens und den NodePort im Format <IP_address>:<nodeport>. Die öffentliche und private IP-Adresse des Workerknotens sind jedoch keine permanenten Adressen. Wenn ein Workerknoten entfernt oder neu erstellt wird, werden ihm eine neue öffentliche und eine neue private IP-Adresse zugewiesen. Knotenports eignen sich auch ideal zum Testen des öffentlichen oder privaten Zugriffs oder zum Bereitstellen von Zugriff nur für kurze Zeit.

LoadBalancer

Der LoadBalancer-Servicetyp wird in Abhängigkeit vom Infrastrukturprovider Ihres Clusters unterschiedlich implementiert.

• Klassische Cluster: Netzlastausgleichsfunktion (NLB). Jeder Standardcluster wird mit 4 portierbaren öffentlichen IP-Adressen und 4 portierbaren privaten IP-Adressen bereitgestellt, mit denen Sie eine Layer 4-TCP/UDP-Netzlastausgleichsfunktion (NLB) für Ihre App erstellen können. Diese NLB kann durch Zugänglichmachen jedes beliebigen Ports, den Ihre App benötigt, entsprechend angepasst werden. Die portierbaren öffentlichen und privaten IP-Adressen, die dem NLB zugeordnet sind, sind permanent und ändern sich nicht, wenn ein Workerknoten im Cluster erneut erstellt wird. Wenn Sie öffentliche NLBs erstellen, können Sie eine Unterdomäne für Ihre App erstellen, die die öffentlichen NLB-IP-Adressen über einen DNS-Eintrag registriert. Sie können außerdem Statusprüfmonitore für die NLB-IP-Adressen für jede Unterdomäne aktivieren.
• VPC-Cluster: Lastausgleichsfunktion für VPC. Wenn Sie einen Kubernetes-Lastausgleichsservice für eine App in Ihrem Cluster erstellen, wird automatisch eine Layer 7-VPC-Lastausgleichsfunktion in Ihrer VPC außerhalb Ihres Clusters erstellt. Die VPC-Lastausgleichsfunktion arbeitet mit mehreren Zonen und leitet Anforderungen für Ihre App über die privaten Knotenports (NodePorts) weiter, die automatisch auf Ihren Workerknoten geöffnet werden. Standardmäßig wird die Lastausgleichsfunktion mit einem Hostnamen erstellt, den Sie für den Zugriff auf Ihre App nutzen können. Sie können aber auch eine Unterdomäne für Ihre App erstellen, wodurch ein DNS-Eintrag erstellt wird.

Ingress

Sie können Ingress verwenden, um Ihre App über den Ingress-Controller Red Hat OpenShift für externen Datenverkehr zugänglich zu machen. Red Hat OpenShift Controller Manager konvertiert Ihre Ingress-Ressourcen in Routenressourcen und der Red Hat OpenShift Ingress-Controller verarbeitet diese Routen.

Lastausgleichslösung auswählen

Wenn Sie wissen, welche Optionen Sie haben, um Apps in Ihrem Red Hat OpenShift-Cluster zugänglich zu machen, können Sie die beste Lösung für Ihre Workload auswählen.

In der folgenden Tabelle werden die Merkmale der einzelnen Bereitstellungsmethoden für Apps verglichen.

* Der SSL-Abschluss erfolgt mit dem Befehl ibmcloud oc nlb-dns. In klassischen Clustern werden diese Befehle nur für öffentliche NLBs unterstützt.

Öffentlichen externen Lastausgleich planen

Stellen Sie eine App in Ihrem Cluster öffentlich für das Internet bereit.

In klassischen Clustern sind Ihre Worker-Knoten mit einem öffentlichen VLAN verbunden. Das öffentliche VLAN bestimmt die öffentliche IP-Adresse, die dem jeweiligen Workerknoten zugeordnet ist. Diese Adresse stellt jedem Workerknoten eine öffentliche Netzschnittstelle bereit. Öffentliche Netzbetriebsservices stellen eine Verbindung zu dieser öffentlichen Netzschnittstelle her, indem sie Ihre App mit einer öffentlichen IP-Adresse und wahlweise einer öffentlichen URL bereitstellen.

In VPC-Clustern werden Ihre Workerknoten nur mit privaten VPC-Teilnetzen verbunden. Wenn Sie öffentliche Netzbetriebsservices erstellen, wird jedoch automatisch eine VPC-Lastausgleichsfunktion erstellt. Die VPC-Lastausgleichsfunktion kann öffentliche Anforderungen an Ihre App weiterleiten, indem sie eine öffentliche URL für Ihre App bereitstellt. Wenn eine App öffentlich zugänglich gemacht wird, kann jeder, der über die öffentliche URL verfügt, eine Anforderung an Ihre App senden.

Wenn eine App öffentlich zugänglich gemacht wird, kann jeder, der über die öffentliche Service-IP-Adresse oder die URL verfügt, die Sie für Ihre App eingerichtet haben, eine Anforderung an Ihre App senden. Aus diesem Grund machen Sie so wenige Apps wie möglich zugänglich. Machen Sie eine App nur dann der Öffentlichkeit zugänglich, wenn Ihre App bereit ist, Datenverkehr von externen Web-Clients oder Benutzern zu akzeptieren.

Die öffentliche Netzschnittstelle für Workerknoten wird durch vordefinierte Calico-Netzrichtlinieneinstellungen geschützt, die bei der Clustererstellung auf jedem Workerknoten konfiguriert werden. Standardmäßig wird der gesamte ausgehende Netzverkehr für alle Workerknoten zugelassen. Eingehender Netzverkehr wird abgesehen von bestimmten Ports blockiert. Diese Ports werden geöffnet, damit IBM den Netzverkehr überwachen sowie Sicherheitsupdates für den Kubernetes-Master automatisch installieren kann und damit Verbindungen zu öffentlichen Netzservices hergestellt werden können. Weitere Informationen zu diesen Richtlinien und zur Vorgehensweise bei der Änderung dieser Richtlinien finden Sie in Netzrichtlinien.

Privaten externen Lastausgleich planen

Stellen Sie eine App privat in Ihrem Cluster nur für das private Netz bereit.

Wenn Sie eine App in einem Kubernetes-Cluster in IBM Cloud Kubernetes Service bereitstellen, haben Sie die Möglichkeit, die App nur für solche Benutzer und Services zugänglich zu machen, die sich in demselben privaten Netz wie Ihr Cluster befinden. Der private Lastausgleich eignet sich ideal, um Ihre App für Anforderungen von außerhalb des Clusters verfügbar zu machen, ohne die App der allgemeinen Öffentlichkeit zugänglich zu machen. Sie können den privaten Lastausgleich auch verwenden, um den Zugriff, das Anforderungsrouting und andere Konfigurationen für Ihre App zu testen, bevor Sie Ihre App später mit öffentlichen Netzservices der Öffentlichkeit zugänglich machen.

Nehmen Sie zum Beispiel an, dass Sie eine private Lastausgleichsfunktion für Ihre App erstellen. Auf diese private Lastausgleichsfunktion kann wie folgt zugegriffen werden:

• Von einem beliebigen Pod im selben Cluster.
• Von einem beliebigen Pod in einem beliebigen Cluster im selben IBM Cloud-Konto.
• Von allen Systemen über eine VPN-Verbindung zu dem Teilnetz, in dem sich die IP-Adresse der Lastausgleichsfunktion befindet (wenn Sie sich nicht im IBM Cloud-Konto, aber dennoch hinter der Unternehmensfirewall befinden).
• Von einem beliebigen System über eine VPN-Verbindung zu dem Teilnetz, in dem sich die IP-Adresse der Lastausgleichsfunktion befindet (wenn Sie sich in einem anderen IBM Cloud-Konto befinden).
• Von jedem System, das mit einem beliebigen der privaten VLANs im selben IBM Cloud-Konto verbunden ist (wenn Sie mit klassischen Clustern arbeiten und eine VRF-Funktion oder VLAN Spanning aktiviert ist).
• In VPC-Clustern:
  • Von allen Systemen in derselben VPC, wenn Datenverkehr zwischen VPC-Teilnetzen zugelassen wird.
  • Von allen Systemen, die Zugriff auf die VPC haben, in der sich der Cluster befindet, wenn Datenverkehr zwischen VPCs zugelassen wird.