Informationen zum klassischen Clusternetzbetrieb

Wenn Sie einen klassischen Cluster erstellen, müssen Sie die Netzkonfiguration auswählen, damit bestimmte Clusterkomponenten miteinander und mit Netzen oder Services außerhalb des Clusters kommunizieren können.

Kommunikation zwischen Workerknoten: Klassische VLANs und Teilnetze

Beim Erstellen eines klassischen Clusters werden die Workerknoten des Clusters automatisch mit einem privaten VLAN und optional mit einem öffentlichen VLAN verbunden. Ein VLAN konfiguriert eine Gruppe von Workerknoten und Pods so, als wären diese an dasselbe physische Kabel angeschlossen, und es bietet einen Kanal für die Konnektivität zwischen Workerknoten.

Sie können keine klassischen Red Hat OpenShift on IBM Cloud-Cluster erstellen, die nur mit einem privaten VLAN verbunden sind. Ihre Workerknoten müssen sowohl mit öffentlichen als auch mit privaten VLANs verbunden sein.

VLAN-Verbindungen für Workerknoten

Alle Workerknoten müssen mit einem privaten VLAN verbunden sein, sodass jeder Workerknoten Informationen an andere Workerknoten senden und Informationen von diesen empfangen kann. Das private VLAN stellt private Teilnetze bereit, mit denen Ihren Workerknoten und privaten App-Services private IP-Adressen zugewiesen werden. Sie können einen Cluster mit Workerknoten erstellen, die auch mit einem öffentlichen VLAN verbunden sind. Das öffentliche VLAN stellt öffentliche Teilnetze bereit, mit denen Ihren Workerknoten und öffentlichen App-Services öffentliche IP-Adressen zugewiesen werden. Wenn Sie Ihre Anwendungen jedoch vor dem öffentlichen Netzwerk schützen müssen, stehen Ihnen mehrere Optionen zur Absicherung Ihres Clusters zur Verfügung, beispielsweise die Erstellung von Calico-Netzwerkrichtlinien oder die Isolierung externer Netzwerk-Workloads auf Edge-Worker-Knoten.

Wenn Sie zum ersten Mal einen Cluster in einer Zone erstellen, werden automatisch ein öffentliches VLAN und ein privates VLAN in dieser Zone für Sie in Ihrem IBM Cloud-Infrastrukturkonto bereitgestellt. Wenn Sie angeben, dass Workerknoten nur mit einem privaten VLAN verbunden sein müssen, wird ein privates VLAN nur in dieser Zone automatisch bereitgestellt. Für jeden weiteren Cluster, den Sie in dieser Zone erstellen, können Sie das VLAN-Paar angeben, das Sie verwenden möchten. Sie können dasselbe öffentliche und private VLAN wiederverwenden, die für Sie erstellt wurden, da ein VLAN von mehreren Clustern gemeinsam genutzt werden kann.

Weitere Informationen zu VLANs, Teilnetzen und IP-Adressen finden Sie unter Übersicht über den Netzbetrieb in IBM Cloud Kubernetes Service.

Müssen Sie Ihren Cluster unter Verwendung angepasster Teilnetze erstellen? Lesen Sie dazu die Informationen in Vorhandene Teilnetze zum Erstellen eines Clusters verwenden.

Workerknotenkommunikation über Teilnetze und VLANs

In verschiedenen Situationen muss es den Komponenten in Ihrem Cluster erlaubt sein, über mehrere private VLANs zu kommunizieren. Wenn Sie zum Beispiel einen Mehrzonencluster erstellen wollen, wenn Sie über mehrere VLANs für einen Cluster verfügen, oder wenn Sie über mehrere Teilnetze im selben VLAN verfügen, können die Workerknoten in verschiedenen Teilnetzen im selben VLAN oder in verschiedenen VLANs nicht automatisch miteinander kommunizieren. Sie müssen entweder VRF (Virtual Routing and Forwarding) oder das VLAN Spanning für Ihr IBM Cloud-Infrastrukturkonto aktivieren.

  • VRF (Virtual Routing and Forwarding): VRF ermöglicht allen privaten VLANs und Teilnetzen in Ihrem Infrastrukturkonto die Kommunikation miteinander. Außerdem ist VRF erforderlich, um die Kommunikation Ihrer Worker und Ihres Masters über den Private-Cloud-Serviceendpunkt sowie die Kommunikation mit anderen IBM Cloud-Instanzen, die Private-Cloud-Serviceendpunkte unterstützen, zu ermöglichen. Mit dem Befehl ibmcloud account show können Sie überprüfen, ob VRF bereits aktiviert ist. Führen Sie ibmcloud account update --service-endpoint-enable true aus, um VRF zu aktivieren. Die Ausgabe dieses Befehls fordert Sie zum Öffnen eines Supportfalls auf, um Ihr Konto für die Verwendung von VRF und Serviceendpunkten zu aktivieren. VRF schließt die Option des VLAN Spannings für Ihr Konto aus, da alle VLANs kommunizieren können. Wenn VRF aktiviert ist, kann jedes System, das mit einem der privaten VLANs in demselben IBM Cloud-Konto verbunden ist, mit den Workerknoten im Cluster kommunizieren. Sie können Ihren Cluster von anderen Systemen im privaten Netz mithilfe von Calico-Richtlinien für private Netze isolieren.
  • VLAN-Spanning: Sie können den Endpunkt des Private-Cloud-Dienstes nicht aktivieren, wenn Sie sich dafür entscheiden, VLAN-Spanning anstelle von VRF zu aktivieren. Aktivieren Sie VLAN-Spanning, wenn Sie VRF nicht aktivieren können oder wollen, beispielsweise wenn der Master im privaten Netzwerk nicht erreichbar sein muss oder wenn Sie eine Gateway-Appliance verwenden, um über das öffentliche VLAN auf den Master zuzugreifen. Beachten Sie: Wenn Sie beispielsweise über eine vorhandene Gateway-Appliance verfügen und anschließend einen Cluster hinzufügen, werden die neuen portablen Subnetze, die für den Cluster bestellt wurden, nicht auf der Gateway-Appliance konfiguriert, aber VLAN-Spanning ermöglicht das Routing zwischen den Subnetzen.

Worker-zu-Master- und Benutzer-zu-Master-Kommunikation: Serverendpunkte

Es muss ein Kommunikationskanal eingerichtet werden, damit Workerknoten eine Verbindung zum Kubernetes-Master herstellen können. Sie können die Kommunikation zwischen Ihren Workerknoten und dem Kubernetes-Master dadurch ermöglichen, dass Sie entweder nur den Public-Cloud-Serviceendpunkt, sowohl Public- als auch Private-Cloud-Serviceendpunkt oder nur den Private-Cloud-Serviceendpunkt aktivieren.

Um die Kommunikation über öffentliche und private Cloud-Service-Endpunkte zu sichern, richtet IBM Cloud Kubernetes Service beim Erstellen des Clusters automatisch eine Konnectivity-Verbindung zwischen dem Kubernetes Master und dem Worker-Knoten ein. Die Worker kommunizieren sicher mit dem Master über TLS-Zertifikate, und der Master kommuniziert mit den Workern über die VPN-Verbindung.

Nur öffentlicher Serviceendpunkt

Wenn Sie VRF für Ihr Konto nicht aktivieren können oder möchten, können Ihre Workerknoten die Verbindung zum Kubernetes-Master im öffentlichen VLAN automatisch über den Serviceendpunkt der öffentlichen Cloud herstellen.

  • Die Kommunikation zwischen Workerknoten und Master wird sicher über das öffentliche Netz durch den Public-Cloud-Serviceendpunkt eingerichtet.
  • Der Master ist für berechtigte Clusterbenutzer nur über den Public-Cloud-Serviceendpunkt öffentlich zugänglich. Ihre Clusterbenutzer können sicher auf Ihren Kubernetes-Master über das Internet zugreifen, um zum Beispiel kubectl-Befehle auszuführen.
  • Optional können Sie den Zugriff auf die öffentlichen und privaten Dienstendpunkte Ihres Clusters durch kontextbasierte Einschränkungen sichern.

Öffentliche und private Cloud-Serviceendpunkte

Wenn Sie Ihren Master öffentlich oder privat für Clusterbenutzer zugänglich machen wollen, können Sie den Public- und den Private-Cloud-Serviceendpunkt aktivieren. VRF ist in Ihrem IBM Cloud-Konto erforderlich und Sie müssen Ihr Konto zur Verwendung von Serviceendpunkten aktivieren. Führen Sie ibmcloud account update --service-endpoint-enable true aus, um VRF und Serviceendpunkte zu aktivieren.

  • Wenn Workerknoten mit öffentlichen und privaten VLANs verbunden sind, wird die Kommunikation zwischen Workerknoten und Master sowohl über das private Netz durch den Private-Cloud-Serviceendpunkt als auch über das öffentliche Netz durch den Public-Cloud-Serviceendpunkt hergestellt. Dadurch, dass die Hälfte des Worker-zu-Master-Datenverkehrs über den öffentlichen Endpunkt und die andere Hälfte über den privaten Endpunkt geleitet wird, ist Ihre Master-zu-Worker-Kommunikation vor potenziellen Ausfällen des öffentlichen oder privaten Netzes geschützt. Wenn Workerknoten nur mit privaten VLANs verbunden sind, wird die Kommunikation zwischen Workerknoten und Master über das private Netz nur durch den Private-Cloud-Serviceendpunkt hergestellt.
  • Der Master ist für berechtigte Clusterbenutzer durch den Public-Cloud-Serviceendpunkt öffentlich zugänglich. Der Master ist privat durch den Private-Cloud-Serviceendpunkt zugänglich, wenn sich berechtigte Clusterbenutzer in Ihrem privaten IBM Cloud-Netz befinden oder durch eine VPN-Verbindung oder IBM Cloud Direct Link mit dem privaten Netz verbunden sind. Beachten Sie, dass Sie den Master-Endpunkt über eine private Lastausgleichsfunktion zugänglich machen müssen, damit Benutzer über eine VPN- oder eine IBM Cloud Direct Link-Verbindung auf den Master zugreifen können.
  • Optional können Sie den Zugriff auf die öffentlichen und privaten Dienstendpunkte Ihres Clusters durch kontextbasierte Einschränkungen sichern.

Nur privater Serviceendpunkt

Wenn Sie Ihren Master nur privat zugänglich machen wollen, können Sie den Private-Cloud-Serviceendpunkt aktivieren. VRF ist in Ihrem IBM Cloud-Konto erforderlich und Sie müssen Ihr Konto zur Verwendung von Serviceendpunkten aktivieren. Führen Sie ibmcloud account update --service-endpoint-enable true aus, um VRF und Serviceendpunkte zu aktivieren. Beachten Sie, dass nur bei Verwendung des Private-Cloud-Serviceendpunkts keine Gebühren in Rechnung gestellt oder für gemessene Bandbreite erhoben werden.

  • Die Kommunikation zwischen Workerknoten und Master wird über das private Netz durch den Private-Cloud-Serviceendpunkt hergestellt.
  • Der Master ist privat zugänglich, wenn sich berechtigte Clusterbenutzer in Ihrem privaten IBM Cloud-Netz befinden oder durch eine VPN-Verbindung oder Direct Link mit dem privaten Netz verbunden sind. Beachten Sie, dass Sie den Master-Endpunkt über eine private Lastausgleichsfunktion zugänglich machen müssen, damit Benutzer über eine VPN- oder eine Direct Link-Verbindung auf den Master zugreifen können.
  • Optional können Sie den Zugriff auf die öffentlichen und privaten Dienstendpunkte Ihres Clusters durch kontextbasierte Einschränkungen sichern.

Kommunikation zwischen Workerknoten und anderen IBM Cloud-Services oder lokalen Netzen

Ermöglichen Sie Ihren Workerknoten die sichere Kommunikation mit anderen IBM Cloud-Services und mit einem lokalen (On-Premises-) Netz.

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

Ihre Workerknoten können automatisch und sicher über das private Netz Ihrer IBM Cloud-Infrastruktur mit anderen IBM Cloud-Services, die Private-Cloud-Serviceendpunkte unterstützen (wie z. B. IBM Cloud® Container Registry), kommunizieren. Wenn ein IBM Cloud-Service keine Private-Cloud-Serviceendpunkte unterstützt, müssen Ihre Workerknoten mit einem öffentlichen VLAN verbunden sein, sodass sie sicher über das öffentliche Netz mit den Services kommunizieren können.

Wenn Sie die Calico-Richtlinien oder eine Gateway-Appliance verwenden, um die öffentlichen oder privaten Netze Ihrer Workerknoten zu steuern, müssen Sie den Zugriff auf die öffentlichen IP-Adressen der Services zulassen, die Public-Cloud-Serviceendpunkte unterstützen, und optional auf die privaten IP-Adressen der Services, die Private-Cloud-Serviceendpunkte unterstützen.

VPN-Verbindung für die Kommunikation über das öffentliche Netzwerk mit Ressourcen in lokalen Rechenzentren

  • Worker-Knoten, die mit öffentlichen und privaten VLANs verbunden sind: Richten Sie einen VPN-Dienst in Ihrem Cluster ein, um einen sicheren End-to-End-Kommunikationskanal über das Internet zwischen Ihrem Cluster und einem lokalen Netzwerk bereitzustellen. Es gibt mehrere Open-Source-Optionen, siehe Klassische VPN-Konnektivität.

  • Worker-Knoten, die ausschließlich mit einem privaten VLAN verbunden sind: Richten Sie einen VPN-Endpunkt auf einem Gateway-Gerät ein, beispielsweise einem Virtual Router Appliance (Vyatta).

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 ein benutzerdefiniertes Subnetz-CIDR für Pods und in der Option --service-subnet ein benutzerdefiniertes Subnetz-CIDR 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 IBM Cloud Kubernetes ServiceFunktionalität der Steuerungsebene reserviert sind.

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

Lassen Sie öffentliche oder private Datenverkehrsanforderungen von außerhalb des Clusters an Ihre 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-Netzbetriebsservices, wie z. B. private Knotenports (NodePorts), NLBs und Ingress-ALBs erstellen, um private Datenverkehrsanforderungen von außerhalb des Clusters an Ihre Apps zuzulassen. Anschließend können Sie Calico-Richtlinien des Typs 'Pre-DNAT' verwenden, um Datenverkehr an öffentliche Knotenports privater Netzbetriebsservices zu blockieren. Weitere Informationen finden unter Privaten externen Lastausgleich planen.

Öffentlicher Datenverkehr zu Cluster-Apps

Um Ihre Apps extern über das öffentliche Internet zugänglich zu machen, können Sie öffentliche NodePorts, Netzlastausgleichsfunktionen (NLBs) und Ingress-Lastausgleichsfunktionen für Anwendungen (ALBs) erstellen. Öffentliche Netzbetriebsservices stellen eine Verbindung zu dieser öffentlichen Netzschnittstelle her, indem sie Ihre App mit einer öffentlichen IP-Adresse und - abhängig vom Service - mit einer öffentlichen URL bereitstellen. 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. Sie können dann Calico-Richtlinien des Typs 'Pre-DNAT' verwenden, um den Datenverkehr zu öffentlichen Netzservices zu steuern, z. B. durch Zulassen des Datenverkehrs von bestimmten Quellen-IP-Adressen oder CIDRs und Blockieren des übrigen Datenverkehrs. Weitere Informationen finden unter Öffentlichen externen Lastausgleich planen.

Für zusätzliche Sicherheit können Sie Netzwerk-Workloads auf Edge-Worker-Knoten isolieren.
Mit Edge-Workerknoten kann die Sicherheit des Clusters verbessert werden, indem der externe Zugriff auf weniger Workerknoten, die mit öffentlichen VLANs verbunden sind, beschränkt und die Netzworkload eingegrenzt wird. Wenn Sie Workerknoten als Edge-Knoten kennzeichnen, werden NLB- und ALB-Pods nur auf diesen angegebenen Workerknoten bereitgestellt. Um zu verhindern, dass andere Workloads auf Edge-Knoten ausgeführt werden, können Sie die Edge-Knoten zudem mit einem Taint versehen. Dann können Sie sowohl öffentliche als auch private NLBs und ALBs auf Edge-Knoten bereitstellen. Wenn Ihre Workerknoten zum Beispiel nur mit einem privaten VLAN verbunden sind, Sie allerdings öffentlichen Zugriff auf eine App in Ihrem Cluster zulassen müssen, können Sie einen Edge-Worker-Pool erstellen, in dem die Edge-Knoten mit öffentlichen und privaten VLANs verbunden sind. Auf diesen Edge-Knoten können Sie öffentliche NLBs und ALBs bereitstellen, um sicherzustellen, dass nur diese Worker öffentliche Verbindungen verarbeiten.

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

In diesem Szenario wollen Sie Workloads in einem klassischen Cluster ausführen, die für Anforderungen aus dem Internet zugänglich sind, sodass Endbenutzer auf Ihre Apps zugreifen können. Sie möchten die Möglichkeit haben, den öffentlichen Zugriff in Ihrem Cluster zu begrenzen und zu steuern, welche öffentlichen Anforderungen an Ihren Cluster zugelassen werden. Außerdem haben Ihre Worker automatischen Zugriff auf alle IBM Cloud-Services, die eine Verbindung zu Ihrem Cluster herstellen können.

Architekturdiagramm für einen Cluster, auf dem internetorientierte Workloads ausgeführt werden.
Netzwerkkonfiguration für einen Cluster, auf dem internetorientierte Workloads ausgeführt werden

Worker-zu-Worker-Kommunikation in klassischen Clustern mit Workloads, die mit dem Internet verbunden sind

Um diese Konfiguration zu erreichen, erstellen Sie einen Cluster, indem Sie Workerknoten mit öffentlichen und privaten VLANs verbinden.

Wenn Sie den Cluster mit öffentlichen und privaten VLANs erstellen, können Sie später nicht alle öffentlichen VLANs aus diesem Cluster entfernen. Durch das Entfernen aller öffentlichen VLANs aus einem Cluster werden mehrere Clusterkomponenten gestoppt. Erstellen Sie stattdessen einen neuen Worker-Pool, der nur mit einem privaten VLAN verbunden ist.

Worker-zu-Master- und Benutzer-zu-Master-Kommunikation in klassischen Clustern mit Workloads, die mit dem Internet verbunden sind

Sie können auswählen, ob Sie Worker-zu-Master- und Benutzer-zu-Master-Kommunikation über das öffentliche und das private Netz oder nur über das öffentliche Netz zulassen wollen.

  • Public- und Private-Cloud-Serviceendpunkte: Für Ihr Konto muss VRF und die Verwendung von Serviceendpunkten aktiviert sein. Die Kommunikation zwischen Workerknoten und Master wird sowohl über das private Netz durch den Private-Cloud-Serviceendpunkt als auch über das öffentliche Netz durch den Public-Cloud-Serviceendpunkt hergestellt. Der Master ist für berechtigte Clusterbenutzer durch den Public-Cloud-Serviceendpunkt öffentlich zugänglich.
  • Öffentlicher Serviceendpunkt: Wenn Sie VRF für Ihr Konto nicht aktivieren möchten oder können, können Ihre Workerknoten und autorisierten Clusterbenutzer automatisch über den öffentlichen Cloud-Serviceendpunkt eine Verbindung zum Kubernetes-Master über das öffentliche Netz herstellen.

Workerkommunikation mit anderen Services oder Netzen mit Workloads, die mit dem Internet verbunden sind

Ihre Workerknoten können automatisch sicher über das private Netz Ihrer IBM Cloud-Infrastruktur mit anderen IBM Cloud-Services kommunizieren, die Private-Cloud-Serviceendpunkte unterstützen. Wenn ein IBM Cloud-Service keine Private-Cloud-Serviceendpunkte unterstützt, können Worker über das öffentliche Netz sicher mit den Services kommunizieren. Sie können die öffentlichen oder privaten Schnittstellen von Workerknoten mithilfe von Calico-Netzrichtlinien für die Isolation öffentlicher oder privater Netze sperren. Sie müssen Zugriff auf die öffentlichen und privaten IP-Adressen der Services zulassen, die Sie in diesen Calico-Richtlinien verwenden wollen.

Wenn Ihre Arbeitsknoten auf Dienste in privaten Netzwerken außerhalb Ihres IBM Cloud-Kontos zugreifen müssen, lesen Sie bitte den Abschnitt Einrichten einer privaten Netzwerkkonnektivität

Externe Kommunikation mit Apps, die auf Workerknoten mit Workloads ausgeführt werden, die mit dem Internet verbunden sind

Wenn Sie eine App in Ihrem Cluster im Internet zugänglich machen wollen, können Sie einen Service für eine öffentliche Netzlastausgleichsfunktion (NLB) oder einen Service für eine Ingress-Lastausgleichsfunktion für Anwendungen (ALB) erstellen. Sie können die Sicherheit Ihres Clusters verbessern, indem Sie einen Pool mit Workerknoten erstellen, die als Edge-Knoten bezeichnet werden. Die Pods für öffentliche Netzservices werden auf den Edge-Knoten bereitgestellt, sodass externe Datenverkehr-Workloads auf nur wenige Worker in Ihrem Cluster eingegrenzt werden. Sie können den öffentlichen Datenverkehr zu den Netzservices, die ihre Apps zugänglich machen, weiter steuern, indem Sie Calico-Richtlinien des Typs 'Pre-DNAT' erstellen, z. B. Richtlinien mit Zulassungs- und mit Sperrlisten.

Sind Sie bereit, mit einem Cluster für dieses Szenario zu beginnen? Nachdem Sie Ihre Hochverfügbarkeitseinrichtung geplant haben, siehe Erstellen von Clustern.

Szenario: eingeschränkte öffentliche Konnektivität mit einer Gateway-Appliance zulassen

In diesem Szenario wollen Sie Workloads in einem klassischen Cluster ausführen, die für Services, Datenbanken oder andere Ressourcen in Ihrem lokalen Rechenzentrum zugänglich sind. Sie müssen jedoch begrenzten öffentlichen Zugriff auf Ihren Cluster bereitstellen und wollen sicherstellen, dass öffentlicher Zugriff gesteuert und in Ihrem Cluster isoliert wird. Beispielsweise benötigen Ihre Worker möglicherweise Zugriff auf einen IBM Cloud-Service, der keine Private-Cloud-Serviceendpunkte unterstützt und auf den über das öffentliche Netz zugegriffen werden muss. Oder Sie müssen begrenzten öffentlichen Zugriff auf eine App bereitstellen, die in Ihrem Cluster ausgeführt wird. Um dieses Cluster-Setup zu erreichen, können Sie eine Gateway-Appliance, wie z. B. Virtual Router Appliance (Vyatta), als öffentliches Gateway und Firewall konfigurieren.

Architekturdiagramm für einen Cluster, der eine Gateway-Appliance für den sicheren öffentlichen Zugriff nutzt.
Netzwerkeinrichtung für einen Cluster, der eine Gateway-Appliance für den sicheren öffentlichen Zugriff nutzt

Worker-zu-Worker-Kommunikation, Worker-zu-Master- und Benutzer-zu-Master-Kommunikation mit einer Gateway-Appliance

Wenn Sie Ihre Workerknoten nur in einem privaten VLAN einrichten und VRF für Ihr Konto nicht aktivieren möchten oder können, müssen Sie eine Gateway-Appliance konfigurieren, um Netzkonnektivität zwischen Ihren Workerknoten und dem Master über das öffentliche Netz zu ermöglichen. Sie können beispielsweise eine Virtual Router Appliance einrichten.

Sie können eine Gateway-Appliance mit angepassten Netzrichtlinien einrichten, um für Ihren Cluster dedizierte Netzsicherheit bereitzustellen und unbefugten Zugriff zu erkennen und zu unterbinden. Wenn Sie eine Firewall im öffentlichen Netz einrichten, müssen Sie die erforderlichen Ports und IP-Adressen für die einzelnen Regionen öffnen, damit der Master und die Workerknoten kommunizieren können. Wenn Sie diese Firewall für das private Netz konfigurieren, müssen Sie auch die erforderlichen Ports und IP-Adressen öffnen, um die Kommunikation zwischen den Workerknoten zuzulassen und Ihren Cluster über das private Netz auf die Infrastrukturressourcen zugreifen zu lassen. Sie müssen auch VLAN Spanning für Ihr Konto aktivieren, damit Teilnetze in demselben VLAN und über VLANs Daten weiterleiten können.

Workerkommunikation mit anderen Services oder Netzen mit einer Gateway-Appliance

Wie Sie Ihre Worker Nodes und Anwendungen sicher mit einem lokalen Netzwerk oder Services außerhalb von IBM Cloud verbinden können, erfahren Sie unter Einrichten einer privaten Netzwerkkonnektivität

Ihre Workerknoten können durch Ihre Gateway-Appliance sicher mit anderen IBM Cloud-Services und öffentlichen Services außerhalb von IBM Cloud kommunizieren. Sie können Ihre Firewall so konfigurieren, dass der Zugriff auf die öffentlichen und privaten IP-Adressen nur derjenigen Services zugelassen wird, die Sie verwenden wollen.

Externe Kommunikation mit Apps, die auf Workerknoten mit einer Gateway-Appliance ausgeführt werden

Wenn Sie privaten Zugriff auf eine App in Ihrem Cluster bereitstellen wollen, können Sie eine Netzlastausgleichsfunktion (NLB) oder Ingress-Lastausgleichsfunktion für Anwendungen (ALB) erstellen, um Ihre App nur im privaten Netz zugänglich zu machen. Wenn Sie begrenzten öffentlichen Zugriff auf eine App in Ihrem Cluster bereitstellen müssen, können Sie eine öffentliche NLB oder ALB erstellen, um Ihre App zugänglich zu machen. Da der gesamte Datenverkehr die Firewall Ihrer Gateway-Appliance durchläuft, können Sie den öffentlichen und privaten Datenverkehr zu den Netzservices steuern, die Ihre Apps zugänglich machen, indem Sie die Ports und IP-Adressen der Services in Ihrer Firewall öffnen, um den eingehenden Datenverkehr zu diesen Services zuzulassen.

Sind Sie bereit, mit einem Cluster für dieses Szenario zu beginnen? Nachdem Sie Ihre Hochverfügbarkeitseinrichtung geplant haben, siehe Erstellen von Clustern.

Szenario: Lokales Rechenzentrum in einen klassischen Cluster erweitern

In diesem Szenario wollen Sie Workloads in einem klassischen Cluster ausführen. Sie wollen jedoch, dass diese Workloads nur für die Services, Datenbanken oder andere Ressourcen in Ihrem lokalen Rechenzentrum, wie z. B. IBM Cloud Private, 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, wie z. B. IBM Cloud Object Storage.

Architekturdiagramm für einen Cluster, der über das private Netzwerk mit einem lokalen Rechenzentrum verbunden ist.
Netzwerkeinrichtung für einen Cluster, der über das private Netzwerk mit einem lokalen Rechenzentrum verbunden ist

Kommunikation zwischen Workerknoten für private Cluster

Um diese Konfiguration zu erreichen, erstellen Sie einen Cluster, indem Sie Workerknoten nur mit einem privaten VLAN verbinden. Zum Bereitstellen der Konnektivität zwischen dem Cluster-Master und den Workerknoten über das private Netz nur durch den Private-Cloud-Serviceendpunkt muss Ihr Konto für VRF und die Verwendung von Serviceendpunkten aktiviert sein. Da Ihr Cluster für alle Ressourcen im privaten Netz sichtbar ist, wenn VRF aktiviert ist, können Sie Ihren Cluster von anderen Systemen im privaten Netz mithilfe von Calico-Richtlinien für private Netze isolieren.

Beachten Sie, dass zwischen den Standardbereichen für Workerknoten, Pods sowie Services und den Teilnetzen in Ihren lokalen Netzen Teilnetzkonflikte bestehen können. Sie erstellen Ihren Cluster ohne von IBM bereitgestellte Subnetze, indem Sie die Option --no-subnet angeben. Nachdem der Cluster erstellt worden ist, können Sie zum Cluster angepasste Teilnetze hinzufügen. Darüber hinaus können Sie beim Erstellen Ihres Clusters mithilfe der Optionen --service-subnet und --pod-subnet im ibmcloud ks cluster create Befehl ein benutzerdefiniertes Subnetz-CIDR für Pods und Dienste festlegen.

Worker-zu-Master-und Benutzer-zu-Master-Kommunikation für private Cluster

Der Kubernetes-Master ist über den Private-Cloud-Serviceendpunkt zugänglich, wenn sich berechtigte Clusterbenutzer in Ihrem privaten IBM Cloud-Netz befinden oder mit dem privaten Netz verbunden sind, z. B. durch eine klassische VPN-Verbindung oder IBM Cloud Direct Link. Die Kommunikation mit dem Kubernetes-Master über den Private-Cloud-Serviceendpunkt muss jedoch über den IP-Adressbereich 166.X.X.X erfolgen, der über eine klassische VPN-Verbindung oder über IBM Cloud Direct Link nicht angesteuert werden kann. Sie können den Private-Cloud-Serviceendpunkt des Masters für Ihre Clusterbenutzer mithilfe einer privaten Netzlastausgleichsfunktion (NLB) zugänglich machen. Die private NLB macht den Private-Cloud-Serviceendpunkt des Masters als internen 10.X.X.X-IP-Adressbereich zugänglich, auf den Benutzer über eine VPN- oder IBM Cloud Direct Link-Verbindung zugreifen können. Wenn Sie nur den Private-Cloud-Serviceendpunkt aktivieren, können Sie das Kubernetes-Dashboard verwenden oder vorübergehend den Public-Cloud-Serviceendpunkt aktivieren, um die private NLB zu erstellen.

Workerkommunikation mit anderen Services oder Netzen für private Cluster

Ihre Workerknoten können automatisch sicher über das private Netz Ihrer IBM Cloud-Infrastruktur mit anderen IBM Cloud-Services (wie z. B. IBM Cloud® Container Registry) kommunizieren, die Private-Cloud-Serviceendpunkte unterstützen. Zum Beispiel unterstützen dedizierte Hardwareumgebungen für alle Standardplaninstanzen von IBM Cloudant Private-Cloud-Serviceendpunkte. Wenn ein IBM Cloud-Service keine Serviceendpunkte für private Clouds unterstützt, kann Ihr Cluster nicht auf diesen Service zugreifen.

Externe Kommunikation mit Anwendungen, die auf Worker-Knoten für private Cluster ausgeführt werden

Wenn Sie privaten Zugriff auf eine App in Ihrem Cluster bereitstellen wollen, können Sie eine Netzlastausgleichsfunktion (NLB) oder Ingress-Lastausgleichsfunktion für Anwendungen (ALB) erstellen. Diese Kubernetes-Netzservices machen Ihre App nur für das private Netz zugänglich, sodass alle lokalen Systeme mit einer Verbindung zum Teilnetz, in dem sich die NLB-IP befindet, auf die App zugreifen können.

Sind Sie bereit, mit einem Cluster für dieses Szenario zu beginnen? Nachdem Sie Ihre Hochverfügbarkeitseinrichtung geplant haben, siehe Erstellen von Clustern.

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 von Netzwerken zu beginnen, fahren Sie fort mit Verwendung von Calico Netzwerkrichtlinien zur Kontrolle des Datenverkehrs auf Classic-Clustern.