Worker-zu-Worker-Kommunikation mithilfe von VPC-Teilnetzen

Bevor Sie zum ersten Mal einen VPC-Cluster erstellen, müssen Sie in jeder Zone, in der Sie Worker-Knoten bereitstellen möchten, ein VPC-Subnetz anlegen. Ein VPC-Teilnetz besteht aus einem angegebenen Bereich privater IP-Adressen (CIDR-Block) und konfiguriert eine Gruppe von Workerknoten und Pods so, als wären diese an dasselbe physische Kabel angeschlossen.

Wenn Sie einen Cluster erstellen, geben Sie für jede Zone ein vorhandenes VPC-Teilnetz an. Jeder Workerknoten, den Sie in einem Cluster hinzufügen, wird mit einer privaten IP-Adresse aus dem VPC-Teilnetz in dieser Zone bereitgestellt. Nach der Bereitstellung des Workerknotens bleibt die IP-Adresse des Workerknotens nach einer Operation vom Typ reboot (Neustart) erhalten; nach Operationen vom Typ replace (Ersetzen) und update (Aktualisieren) ändern sich die IP-Adresse des Workerknotens jedoch.

Teilnetze stellen einen Kanal für die Konnektivität zwischen den Workerknoten innerhalb des Clusters bereit. Darüber hinaus kann jedes System, das mit einem der privaten Teilnetze in derselben VPC verbunden ist, mit den Workerknoten kommunizieren. So können zum Beispiel alle Teilnetze in einer VPC über die Weiterleitung des privaten Layers 3 mit einem integrierten VPC-Router kommunizieren. Wenn mehrere Ihrer Cluster in der Lage sein müssen, miteinander zu kommunizieren, können Sie diese Cluster in derselben VPC erstellen. Wenn Ihre Cluster jedoch nicht miteinander kommunizieren müssen, können Sie eine bessere Segmentierung des Netzes erreichen, indem Sie die Cluster in separaten VPCs erstellen. Zur Vermittlung des Datenverkehrs im privaten Netz können Sie auch Zugriffssteuerungslisten (ACLs) für Ihre VPC-Teilnetze erstellen. Zugriffssteuerungslisten bzw. ACLs (Access Control Lists) bestehen aus Regeln für den eingehenden und den ausgehenden Datenverkehr, mit denen definiert wird, welcher Ingress und Egress für die einzelnen VPC-Teilnetze zulässig ist.

Wenn Sie einen VPC-Cluster erstellen und während der Clustererstellung sowohl den öffentlichen als auch den privaten Cloud-Serviceendpunkt aktivieren, wird für den Zugriff auf Komponenten wie beispielsweise die Red Hat OpenShift-Webkonsole für Ihren Cluster standardmäßig der öffentliche Cloud-Serviceendpunkt verwendet. Damit Konsolenpods über den öffentlichen Serviceendpunkt eine sichere allgemein zugängliche Verbindung über das Internet herstellen können, müssen Sie für jedes öffentliche VPC-Teilnetz, für das Ihre Workerknoten bereitgestellt sind, ein öffentliches Gateway aktivieren.

Wenn Sie einen VPC-Cluster erstellen und während der Clustererstellung nur den privaten Cloud-Serviceendpunkt aktivieren, wird für den Zugriff auf Red Hat OpenShift-Komponenten wie beispielsweise die Red Hat OpenShift-Webkonsole oder OperatorHub standardmäßig der private Cloud-Serviceendpunkt verwendet. Sie müssen (z. B. über eine VPN-Verbindung) mit dem privaten VPC-Netz verbunden sein, um auf diese Komponenten zugreifen oder kubectl-Befehle für Ihren Cluster ausführen zu können.

Der standardmäßige IP-Adressbereich für VPC-Teilnetze ist 10.0.0.0 bis 10.255.255.255. Eine Liste der IP-Adressbereiche pro VPC-Zone finden Sie unter Standardadressenpräfixe in einer VPC.

Wenn Sie beim Erstellen der VPC den klassischen Zugriff aktivieren, werden die IP-Bereiche der von Ihnen erstellten Teilnetze automatisch durch die Standardadresspräfixe für den klassischen Zugriff bestimmt. Die standardmäßigen IP-Bereiche für VPC-Teilnetze mit klassischem Zugriff stehen jedoch in Konflikt zu den Teilnetzen für die Red Hat OpenShift on IBM Cloud-Steuerebene. Stattdessen müssen Sie die VPC ohne die automatischen Standard-Adresspräfixe erstellen und anschließend eigene Adresspräfixe und Subnetze innerhalb dieser Bereiche für Ihren Cluster anlegen.

Müssen Sie Ihren Cluster unter Verwendung von Teilnetzen mit angepassten Bereichen erstellen? Lesen Sie dazu diese Anleitung zu angepassten Adresspräfixen. Wenn Sie Teilnetze für angepasste Bereiche für Ihre Workerknoten verwenden, müssen Sie sicherstellen, dass sich Ihre Workerknotenteilnetze nicht mit dem Pod-Teilnetz Ihres Clusters überschneiden.

Löschen Sie nicht die Teilnetze, die Sie Ihrem Cluster bei der Clustererstellung oder beim Hinzufügen von Workerknoten in einer Zone zugeordnet haben. Wenn Sie ein von Ihrem Cluster verwendetes VPC-Teilnetz löschen, können bei allen Lastausgleichsfunktionen, die IP-Adressen aus dem Teilnetz verwenden, Probleme auftreten, und Sie können möglicherweise keine neuen Lastausgleichsfunktionen erstellen.

Berücksichtigen Sie bei der Erstellung von VPC-Teilnetzen für Ihre Cluster die folgenden Features und Einschränkungen. Weitere Informationen zu VPC-Teilnetzen finden Sie in Merkmale von Teilnetzen in der VPC.

• Die CIDR-Standardgröße eines jeden VPC-Teilnetzes beträgt /24 und kann damit bis zu 253 Workerknoten unterstützen. Falls Sie beabsichtigen, mehr als 250 Workerknoten pro Zone in einem Cluster bereitzustellen, sollten Sie die Erstellung eines größer ausgelegten Teilnetzes in Betracht ziehen.
• Nachdem Sie ein VPC-Teilnetz erstellt haben, können Sie die Größe und den IP-Bereich des Teilnetzes nicht mehr ändern.
• Mehrere Cluster in derselben VPC können Teilnetze gemeinsam nutzen.
• VPC-Subnetze sind an eine einzelne Zone oder Region gebunden und können sich nicht über mehrere Zonen oder Regionen erstrecken.
• Nachdem Sie ein Teilnetz erstellt haben, können Sie es nicht in eine andere Zone, Region oder VPC verschieben.
• Wenn Sie Workerknoten haben, die an ein vorhandenes Teilnetz in einer Zone angehängt sind, können Sie das Teilnetz für diese Zone im Cluster nicht ändern.
• Die Bereiche 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 und 172.20.0.0/16 dürfen nicht verwendet werden.

Worker-zu-Master- und Benutzer-zu-Master-Kommunikation über virtuelle private Endpunkte oder Cloud-Serviceendpunkte

Red Hat OpenShift on IBM Cloud nutzt verschiedene Arten von Service-Endpunkten, um eine Verbindung zwischen autorisierten Cluster-Benutzern und Worker-Knoten zum „ Kubernetes “-Master herzustellen. Berechtigte Clusterbenutzer kommunizieren mit dem Kubernetes-Master über Cloud-Serviceendpunkte. Abhängig von Ihrer Clusterversion kommunizieren Workerknoten mit dem Kubernetes-Master über Cloud-Serviceendpunkte oder virtuelle private VPC-Endpunkte.

Vor dem Erstellen eines Clusters müssen Sie Ihr Konto zur Verwendung von Serviceendpunkten aktivieren. Für die Aktivierung von Serviceendpunkten führen Sie ibmcloud account update --service-endpoint-enable true aus.

In VPC-Clustern in Red Hat OpenShift on IBM Cloud können Sie den privaten Cloud-Serviceendpunkt nicht inaktivieren und keinen Cluster nur mit dem öffentlichen Cloud-Serviceendpunkt einrichten.

Ihr VPC-Cluster wird standardmäßig mit einem Public- und einem Private-Cloud-Serviceendpunkt erstellt. Zum Erstellen von Clustern mit Workerknoten, die ausschließlich mit dem privaten Netz verbunden sind, müssen Sie während der Clustererstellung lediglich den privaten Serviceendpunkt aktivieren. Aktivieren Sie nicht den öffentlichen Serviceendpunkt. Um beispielsweise in der CLI einen VPC-Cluster zu erstellen, der ausschließlich über einen Endpunkt für private Cloud-Dienste verfügt, fügen Sie die Option „ --disable-public-service-endpoint “ hinzu. Wenn Sie diese Option angeben, wird Ihr Cluster mit Routern und Ingress-Controllern erstellt, die Ihre Anwendungen standardmäßig nur im privaten Netzwerk verfügbar machen. Falls Sie Apps später einem öffentlichen Netz zugänglich machen möchten, müssen Sie manuell öffentliche Router und Ingress-Controller erstellen.

Worker-zu-Master-Kommunikation in VPC-Clustern

Die Kommunikation zwischen den Worker-Knoten und dem „ Kubernetes “-Master erfolgt standardmäßig über den virtuellen privaten Endpunkt(VPE)der VPC. Das VPE-Gateway für Ihren Cluster verwendet je nach Region eines dieser beiden Hostnamenformate: CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com oder CLUSTERID.private.REGION.containers.cloud.ibm.com. Der gesamte Datenverkehr zwischen Worker und Master wird über dieses private VPE-Gateway geleitet.

Wenn die Verbindung zum VPE-Gateway fehlschlägt und in Ihrem Cluster der Schutz für ausgehenden Datenverkehr deaktiviert ist, greifen die Worker-Knoten auf den Endpunkt des Public-Cloud-Dienstes zurück. Dieser Fallback tritt nur auf, wenn das VPE-Gateway nicht erreichbar ist, nicht jedoch im Normalbetrieb. Wenn der Schutz des ausgehenden Datenverkehrs aktiviert ist, erfolgt kein Fallback auf den öffentlichen Endpunkt.

Um die Kommunikation über Endpunkte öffentlicher und privater Cloud-Dienste oder VPEs zu sichern, richtet „ Red Hat OpenShift on IBM Cloud “ bei der Erstellung des Clusters automatisch eine Konnectivity-Verbindung zwischen den Master- und Worker-Knoten von „ Kubernetes “ ein. Die Worker-Knoten kommunizieren sicher mit dem Master über „ TLS “-Zertifikate, und der Master kommuniziert mit den Workern über die Konnectivity-Verbindung.

Benutzer-zu-Master-Kommunikation in VPC-Clustern

Sie können berechtigten Clusterbenutzern die Kommunikation mit dem Kubernetes-Master ermöglichen, indem Sie den Public- und den Private-Cloud-Serviceendpunkt oder nur den Private-Cloud-Serviceendpunkt aktivieren.

• Public- und Private-Cloud-Serviceendpunkt: Standardmäßig werden alle Aufrufe an den Master, die von berechtigten Clusterbenutzern eingeleitet werden, über den Public-Cloud-Serviceendpunkt weitergeleitet. Wenn sich berechtigte Clusterbenutzer in Ihrem VPC-Netz befinden oder über eine VPC-VPN-Verbindung verbunden sind, kann über den Private-Cloud-Serviceendpunkt auf den Master zugegriffen werden.
• Nur Private-Cloud-Serviceendpunkt: Um über den Private-Cloud-Serviceendpunkt auf den Master zugreifen zu können, müssen sich berechtigte Clusterbenutzer entweder in Ihrem VPC-Netz befinden oder über eine VPC-VPN-Verbindung verbunden sein.

Sie können den Netzwerkzugriff auf die Dienstendpunkte Ihres Clusters mit kontextbasierten Einschränkungen sichern. Über die Service-Endpunkte des Clusters werden nur autorisierte Anfragen an Ihren Cluster-Master zugelassen, die aus Subnetzen stammen, die auf der Zulassungsliste stehen. Die Verwendung kontextbezogener Beschränkungen hilft dabei, nicht autorisierte Scan-Aktivitäten zu verhindern. Weitere Informationen finden Sie unter Verwendung kontextbezogener Einschränkungen.

Kommunikation zwischen Workerknoten und anderen Services oder Netzen

Ermöglichen Sie Ihren Workerknoten die sichere Kommunikation mit anderen IBM Cloud-Services, lokalen (d. h. On-Premises-) Netzen, anderen VPCs und IBM Cloud-Ressourcen der klassischen Infrastruktur.

Kommunikation mit anderen IBM Cloud-Services über das private oder öffentliche Netz

Ihre Workerknoten können automatisch und sicher über das private Netz mit anderen IBM Cloud-Services kommunizieren, die Private-Cloud-Serviceendpunkte unterstützen, wie z. B. IBM Cloud® Container Registry. Wenn ein IBM Cloud-Service keine Private-Cloud-Serviceendpunkte unterstützt, können Workerknoten sicher über das öffentliche Netz durch das öffentliche Gateway des Teilnetzes mit den Services kommunizieren.

Beachten Sie, dass Sie bei Verwendung von Zugriffssteuerungslisten (ACLs) für Ihre VPC-Teilnetze Regeln für den eingehenden und den ausgehenden Datenverkehr erstellen müssen, damit Ihre Workerknoten mit diesen Services kommunizieren können.

Kommunikation mit Ressourcen in lokalen Rechenzentren

Zum Verbinden Ihres Clusters mit Ihrem lokalen Rechenzentrum können Sie den IBM Cloud® Virtual Private Cloud-VPN-Service oder IBM Cloud® Direct Link verwenden.

• Informationen zum Einstieg in das Virtual Private Cloud-VPN finden Sie in Lokales VPN-Gateway konfigurieren und VPN-Gateway in der VPC-Instanz erstellen und Verbindung zwischen dem VPC-VPN-Gateway und dem lokalen VPN-Gateway herstellen. Wenn Sie über einen Mehrzonencluster verfügen, müssen Sie in jeder Zone, in der Sie über Workerknoten verfügen, ein VPC-Gateway auf einem Teilnetz erstellen.
• Lesen Sie für den Einstieg in Direct Link die Informationen in IBM Cloud Direct Link Dedicated bestellen. In Schritt 8 können Sie eine Netzverbindung zu Ihrer VPC erstellen, die an das Direct Link-Gateway angehängt werden soll.

Wenn Sie planen, Ihren Cluster mit lokalen Netzen zu verbinden, überprüfen Sie die folgenden hilfreichen Informationen:

• Mit dem von IBM bereitgestellten Standardbereich 172.30.0.0.0/16 für Pods und dem Standardbereich 172.21.0.0.0/16 für Services können Teilnetzkonflikte auftreten. Sie können Subnetzkonflikte vermeiden, wenn Sie einen Cluster über die Befehlszeilenschnittstelle(CLI)erstellen, indem Sie in der Option „ --pod-subnet “ einen benutzerdefinierten CIDR-Bereich für Pods und in der Option „ --service-subnet “ einen benutzerdefinierten CIDR-Bereich für Dienste angeben.
• Wenn Ihre VPN-Lösung die Quellen-IP-Adressen von Anforderungen beibehält, können Sie angepasste statische Routen erstellen und so sicherstellen, dass Ihre Workerknoten Antworten von Ihrem Cluster an Ihr lokales Netz weiterleiten können.
• Beachten Sie, dass die Teilnetzbereiche 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 und 172.20.0.0/16 verboten sind, da sie für die Red Hat OpenShift on IBM CloudFunktionalität der Steuerungsebene reserviert sind.

Externe Kommunikation mit Apps, die auf Workerknoten ausgeführt werden

Lassen Sie private oder öffentliche Datenverkehrsanforderungen von außerhalb des Clusters für die Apps zu, die auf Workerknoten ausgeführt werden.

Privater Datenverkehr zu Cluster-Apps

Wenn Sie eine App in Ihrem Cluster bereitstellen, können Sie die App nur für Benutzer und Services zugänglich 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.

Sie können private Kubernetes-Netzservices verwenden, indem Sie beispielsweise LoadBalancer-Services erstellen, um Datenverkehrsanforderungen privater Netze von außerhalb des Clusters an Ihre Apps zuzulassen. Wenn Sie zum Beispiel einen Kubernetes-LoadBalancer-Service in Ihrem Cluster erstellen, wird in Ihrer VPC außerhalb Ihres Clusters automatisch eine Lastausgleichsfunktion für VPC 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. Für VPC ALBs und NLBs wird Ihren Load Balancern automatisch eine Sicherheitsgruppe in Form von kube-lbaas-<cluster-id> zugeordnet.

Weitere Informationen finden unter Privaten externen Lastausgleich planen.

Öffentlicher Datenverkehr zu Cluster-Apps

Um Ihre Apps über das öffentliche Internet zugänglich zu machen, können Sie öffentliche Netzbetriebservices verwenden. Auch wenn Ihre Workerknoten nur mit privaten VPC-Teilnetzen verbunden sind, kann die VPC-Lastausgleichsfunktion, die für öffentliche Netzbetriebsservices erstellt wird, durch das Bereitstellen einer öffentlichen URL für Ihre Anwendung öffentliche Anforderungen an Ihre Anwendung im privaten Netz weiterleiten. Wenn eine App öffentlich zugänglich gemacht wird, kann jeder, der über die öffentliche URL verfügt, eine Anforderung an Ihre App senden.

Sie können öffentliche Kubernetes-Netzservices verwenden, indem Sie beispielsweise LoadBalancer-Services erstellen. Wenn Sie zum Beispiel einen Kubernetes-LoadBalancer-Service in Ihrem Cluster erstellen, wird in Ihrer VPC außerhalb Ihres Clusters automatisch eine Lastausgleichsfunktion für VPC 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. Für VPC ALBs und NLBs wird Ihren Load Balancern automatisch eine Sicherheitsgruppe in Form von kube-lbaas-<cluster-id> zugeordnet.

Beispielszenarios für Netzkonfigurationen mit VPC-Clustern

Nachdem Sie sich mit Clusternetzen in ihren Grundlagen vertraut gemacht haben, sollten Sie die folgenden Beispielszenarios ansehen, in denen mehrere verschiedene Netzkonfigurationen mit VPC-Clustern Ihren Workloaderfordernissen entsprechen.

Szenario: Workloads von mit dem Internet verbundenen Apps in einem VPC-Cluster ausführen

In diesem Szenario führen Sie Workloads, die für Anforderungen aus dem Internet zugänglich sind, in einem VPC-Cluster aus. Der öffentliche Zugriff wird durch Sicherheitsgruppen so gesteuert, dass Endbenutzer auf Ihre Anwendungen zugreifen können, während unerwünschte öffentliche Anforderungen an Ihre Anwendungen verweigert werden. Darüber hinaus haben Ihre Worker automatisch Zugriff auf alle IBM Cloud Services, die Private-Cloud-Serviceendpunkte unterstützen.

Erweitern Sie Ihr lokales Rechenzentrum auf einen VPC-Cluster

In diesem Szenario führen Sie Workloads in einem VPC-Cluster aus. Sie möchten jedoch, dass diese Workloads nur für Services, Datenbanken oder andere Ressourcen in Ihren privaten Netzen in einem lokalen (On-Premises-) Rechenzentrum zugänglich sind. Ihre Cluster-Workloads benötigen möglicherweise Zugriff auf einige andere IBM Cloud-Services, die die Kommunikation über das private Netz unterstützen.

Nächste Schritte

Um den Planungsprozess fortzusetzen, erfahren Sie mehr über den Schutz sensibler Informationen in Ihrem Cluster, indem Sie Entscheidungen über den Grad der Verschlüsselung treffen, die Sie konfigurieren müssen. Wenn Sie bereit sind, mit der Einrichtung des Netzwerks zu beginnen, fahren Sie fort mit Understanding Secure by Default Cluster VPC Networking.