Erstellen eines VPC-Clusters in der Konsole

Erstellen Sie Ihren VPC- Red Hat OpenShift-Cluster mithilfe der IBM Cloud-Konsole. Befolgen Sie die Konsolenanweisungen, um die folgenden Clusterkonfigurationen vorzunehmen. Um mit der Erstellung Ihres Clusters zu beginnen, navigieren Sie zur Konsole und klicken Sie auf "Cluster erstellen ".

Virtual Private Cloud

Wählen Sie die vorhandene VPC-Instanz ( Virtual Private Cloud ) aus, in der Sie Ihren Cluster erstellen wollen. Wenn Sie noch keine VPC haben, können Sie eine erstellen.

Standort

Überprüfen Sie die Workerzonen und Teilnetze für Ihren Cluster. Die Zonen werden auf der Grundlage der von Ihnen ausgewählten VPC gefiltert und enthalten die von Ihnen zuvor erstellten VPC-Teilnetze. Wählen Sie je nach gewünschter Verfügbarkeitsstufe für Ihren Cluster eine oder mehrere Zonen aus. Standardmäßig sind Ihre Clusterressourcen für hohe Verfügbarkeit auf drei Zonen verteilt. Sie können später Zonen zu Ihrem Cluster hinzufügen.

Version

Wählen Sie Ihre Clusterversion aus. Standardmäßig werden Cluster mit der Standardversion von Kubernetes erstellt, aber Sie können eine andere unterstützte Version angeben.

Lizenz

Wenden Sie eine Berechtigung an oder erwerben Sie eine Lizenz für Ihren Cluster. Weitere Informationen finden Sie unter Ihrem Konto Softwarelizenzen zuordnen, Ihrem Cluster Cloud Paks, Berechtigungen oder Lizenzen hinzufügen und in den häufig gestellten Fragen zu Cloud Pak.

Workerpool

Der Cluster-Worker-Pool definiert die Zahl und den Typ der Workerknoten, die Ihre Workload ausführen. Sie können Ihre Worker-Pool-Details jederzeit ändern.

• Workerknoten pro Zone: Für Hochverfügbarkeit werden mindestens 3 Workerknoten pro Zone empfohlen.

• Flavor: Der Flavor definiert die Architektur sowie die Anzahl der virtuellen CPUs, den Arbeitsspeicher, die GPU und den Festplattenspeicher, die auf jedem Worker-Knoten eingerichtet und den Containern zur Verfügung gestellt werden. Die verfügbaren Bare-Metal- und virtuellen Maschinentypen variieren je nach Zone, in der Sie den Cluster implementieren. Eine Liste der verfügbaren Versionen finden Sie unter VPC-Versionen.
• Wenn Sie eine Version in der Konsole auswählen, können Sie verfügbare Versionen nach Maschinentyp, Architektur und Betriebssystem filtern. Die verfügbaren Maschinentypen sind shared und dedicated. Beachten Sie, dass die Option dedicated nur verfügbar ist, wenn Sie bereits einen dedizierten Host-Pool in Ihrem Konto haben. Eine Liste der verfügbaren Betriebssysteme und Architekturen nach Clusterversion finden Sie unter Verfügbare Versionen.

• Lokale Platte verschlüsseln: -Workerknoten verfügen standardmäßig über AES-256-Bit-Plattenverschlüsselung. Sie können die Plattenverschlüsselung inaktivieren, wenn Sie den Cluster erstellen. Wenn Sie die Verschlüsselung aktivieren, wird jeder Workerknoten im Worker-Pool mithilfe der von Ihnen verwalteten KMS-Providerberechtigungsnachweise verschlüsselt. Nur die Knoten des default-Worker-Pools werden verschlüsselt. Wenn Sie nach dem Erstellen des Clusters weitere Workerpools erstellen, müssen Sie die Verschlüsselung in jedem Pool separat aktivieren. Jeder Workerpool in Ihrem Cluster kann dieselbe KMS-Instanz mit Rootschlüssel bzw. dieselbe KMS-Instanz mit verschiedenen Rootschlüsseln oder verschiedene Instanzen verwenden.

• Sekundärer Speicher: Sie können eine sekundäre Platte für Ihre Workerknoten bereitstellen, z. B. eine 900gb.5iops-tier-Blockspeicherplatte. Wenn Sie eine sekundäre Platte hinzufügen, wird diese Platte für die Containerlaufzeit verwendet, während die primäre Platte für das Betriebssystem verwendet wird. Sekundäre Platten sind in Szenarios nützlich, in denen mehr Containerspeicher benötigt wird, wie z. B. die Ausführung von Pods mit großen Images. Beachten Sie, dass bei der Verwendung von Sekundärspeicher die Pods aufgrund der Overlay-Dateisysteme möglicherweise nicht die volle IOPS-/Bandbreitenleistung der Volumes nutzen können. Sekundäre Platten werden in Ihrem Konto bereitgestellt und Sie können sie in der VPC-Konsole anzeigen. Die Gebühren für diese Platten sind getrennt von den Kosten für jeden Mitarbeiter und werden als unterschiedliche Position auf Ihrer Rechnung angezeigt. Auch diese sekundären Volumina werden auf die Kontingentnutzung Ihres Kontos angerechnet. Wenn Sie planen, sekundären Speicher auf Knoten zu verwenden, denen persistente Datenträger zugeordnet werden könnten, wird dringend empfohlen, die 10-iops-Schichten oder höher zu verwenden. Dies liegt daran, dass die Speicherbandbreitenzuordnung für die Knoten von sekundären Speicherdatenträgern und allen angeschlossenen PVCs gemeinsam genutzt wird. Bei Verwendung von 5 E/A-Operationen pro Sekunde kann dies zu einer verminderten Leistung beim Extrahieren von Images oder beim Schreiben von Pods in den Speicher führen. Weitere Informationen zur Bandbreitenzuweisung finden Sie unter Bandbreitenzuweisung in virtuellen Serverinstanzen.

• GPU: Wenn Sie planen, KI-, visuelle oder hochwertige Grafik-Workloads in Ihrem Cluster zu implementieren, stellen Sie sicher, dass Sie eine GPU-Worker-Node-Variante auswählen.

Zusätzliche Geschmacksrichtungen, darunter Geschmacksrichtungen mit NVIDIA V100, A100, H100, und H200 GPUs, sind nur für zugelassene Konten verfügbar. Um Zugriff auf andere in der Zulassungsliste aufgeführte Versionen anzufordern, fordern Sie Zugriff auf die Zulassungsliste an.

Verschlüsselung des Worker-Pools

Verwalten Sie die Verschlüsselung Ihrer Worker-Knoten, indem Sie einen KMS-Anbieter (Key Management Service) auf Worker-Pool-Ebene aktivieren. Wählen Sie Ihre KMS-Instanz und CRN aus.

Netzwerk-Plug-in „ 4.20 “ oder höher

Wählen Sie die Container-Netzwerkschnittstelle (CNI) aus, die Sie verwenden möchten. Wählen Sie zwischen „ Calico “ und „Open Virtual Network“. Bitte beachten Sie, dass „Open Virtual Network“ nur für die Cluster-Version „ 4.20 “ und höher von „ OpenShift “ sowie für RHCOS-Worker-Knoten verfügbar ist. Weitere Informationen finden Sie unter „ Auswahl einer Container-Netzwerkschnittstelle(CNI) “.

Netzeinstellungen

Serviceendpunkte ermöglichen die Kommunikation mit dem Master. Sie können Ihren Cluster mit einem öffentlichen Serviceendpunkt oder sowohl einem öffentlichen als auch einem privaten Cloud-Serviceendpunkt konfigurieren. Weitere Informationen darüber, welche Konfiguration erforderlich ist, um mit dem Internet verbundene Apps auszuführen oder um dafür zu sorgen, dass Ihr Cluster weiterhin privat bleibt, finden Sie in Konfiguration des Clusternetzes planen. Sie können die Cloud-Service-Endpunkte nach dem Erstellen des Clusters nicht mehr ändern.

Interne Registry

Wählen Sie Ihre COS-Instanz aus. Die Container-Images, die in der internen Registry Ihres Red Hat OpenShift on IBM Cloud-Clusters gespeichert werden, werden automatisch in einem Object Storage-Bucket gesichert. Alle Daten, die im Object Storage-Bucket gespeichert sind, bleiben erhalten, selbst wenn Sie den Cluster löschen.

Schutz des ausgehenden Verkehrs

Das Standardverhalten für Cluster der Version 4.15 und höher besteht darin, dass nur der erforderliche Netzdatenverkehr für den Cluster funktioniert und alle anderen abgehenden Verbindungen inaktiviert werden. Wenn Sie über Apps oder Dienste verfügen, die eine Verbindung zum öffentlichen Internet erfordern, wie etwa GitHub Repositorien, Docker Nabe,quay.io, Die Red Hat Marketplace Und OperatorHub, Beachten Sie, dass Sie entweder den Schutz für ausgehenden Datenverkehr vollständig deaktivieren müssen (sodass der gesamte ausgehende Datenverkehr zugelassen wird) oder Sicherheitsgruppenregeln hinzufügen müssen, um nur den ausgehenden Datenverkehr zuzulassen, den Sie benötigen.

Clusterverschlüsselung

Aktivieren Sie die Datenverschlüsselung mit einem Key Management Service (KMS), um geheime Schlüssel und andere sensible Informationen in Ihrem Cluster zu verschlüsseln. Sie können KMS auch später aktivieren.

Verwaltung geheimer Ingress-Schlüssel

IBM Cloud Secrets Manager verwaltet Ingress-Unterdomänenzertifikate und andere geheime Schlüssel in Ihrem Cluster zentral. Während des Clustererstellungsprozesses können Sie eine Secrets Manager-Instanz in Ihrem Cluster registrieren. Sie können auch eine Gruppe geheimer Schlüssel angeben, mit deren Hilfe Sie den Zugriff auf die geheimen Schlüssel in Ihrem Cluster steuern können. Beide Optionen können nach der Erstellung des Clusters konfiguriert oder geändert werden.

VPC-Sicherheitsgruppen

Stellen Sie zusätzlich zur kube-<clusterID> Sicherheitsgruppe bis zu vier benutzerdefinierte Sicherheitsgruppen bereit, die auf alle Worker-Knoten im VPC-Cluster angewendet werden sollen. Weitere Informationen finden Sie unter Secure by Default-Cluster-VPC-Netzwerke verstehen.

Clusterdetails

Sie können den eindeutigen Clusternamen und alle Tags anpassen, die Sie zum Organisieren und Identifizieren Ihrer IBM Cloud-Ressourcen verwenden möchten, z. B. team oder billing department.

Wählen Sie die Ressourcengruppe aus, in der Ihr Cluster erstellt wird. Ein Cluster kann nur in einer Ressourcengruppe erstellt werden; nach der Erstellung des Clusters kann seine Ressourcengruppe nicht geändert werden. Um Cluster in einer anderen Ressourcengruppe als der Standard-Ressourcengruppe zu erstellen, müssen Sie mindestens die **Viewer-**Rollefür die Ressourcengruppe besitzen.

Wenn Sie ein bestehendes vertrauenswürdiges Profil zu Ihrem Cluster hinzufügen möchten, geben Sie die ID des vertrauenswürdigen Profils an. Wenn Sie kein vertrauenswürdiges Profil angeben, können Sie den Clustererstellungsprozess stattdessen mit einem API-Schlüssel abschließen. Weitere Informationen finden Sie unter Konfigurieren eines vertrauenswürdigen Profils.

Beobachtbarkeitsintegrationen

Sie können zusätzliche Beobachtbarkeitsintegrationen aktivieren, die Sie in Ihren Cluster einschließen wollen. Einige Integrationen werden automatisch aktiviert, wenn Sie eine vorhandene Plattforminstanz dieser Integration haben. In diesem Fall können Sie die Integration nicht deaktivieren. Wenn Sie eine Integration verwenden möchten und nur eine Anwendungsinstanz dieser Integration vorhanden ist, ist die Integration standardmäßig inaktiviert und Sie müssen sie manuell aktivieren.

• Protokollierung: Sie können IBM Cloud Logs verwenden, um Betriebssystemprotokolle, Anwendungsprotokolle und Plattformprotokolle zu verwalten. Wenn Sie diese Integration später aktivieren möchten, lesen Sie bitte IBM Cloud Logs.

• Überwachung und Schutz der Arbeitslast: Die Integration des Überwachungsdienstes ermöglicht einen operativen Einblick in die Leistung und den Zustand Ihrer Anwendungen, Dienste und Plattformen. Wenn Sie diese Integration deaktivieren und später wieder aktivieren möchten, lesen Sie bitte Überwachung des Clusterzustands. Die Security and Compliance Center Workload Protection Integration findet und priorisiert Software-Schwachstellen, erkennt und reagiert auf Bedrohungen und verwaltet Konfigurationen, Berechtigungen und Compliance von der Quelle bis zur Ausführung. Weitere Informationen finden Sie auf der Seite Workload-Schutz Einstieg.
• Geben Sie den Konfigurationstyp an, um entweder neue oder vorhandene Instanzen von Monitoring und Workload Protection zu verwenden. Wenn Sie vorhandene Instanzen von Monitoring und Workload Protection verwenden möchten, müssen die Instanzen der beiden Integrationen verbunden werden. In diesem Fall geben Sie entweder die Überwachungs- oder die Workload-Schutz-Instanz an, die Sie verwenden möchten; Sie können nicht beide Instanzen angeben, aber beide Instanzen werden verwendet, solange sie verbunden sind. Sie können bestehende Instanzen von der Detailseite der Überwachung oder Workload Protection Instanz aus verbinden.

Erstellen von VPC-Clustern über die Befehlszeilenschnittstelle (CLI)

• Stellen Sie sicher, dass Sie die Voraussetzungen erfüllen, um Ihr Konto vorzubereiten und sich für eine Cluster-Konfiguration zu entscheiden.
• Installieren Sie die IBM Cloud-CLI und das Red Hat OpenShift on IBM Cloud-Plug-in.
• Installieren Sie das VPC-CLI-Plug-in.

1. Melden Sie sich über die Befehlszeile bei Ihrem IBM Cloud-Konto an und geben Sie die IBM Cloud-Region und -Ressourcengruppe an, in der der VPC-Cluster erstellt werden soll. Informationen zu den unterstützten Regionen finden Sie in Abschnitt VPC in einer anderen Region erstellen. Geben Sie Ihre IBM Cloud-Berechtigungsnachweise ein, wenn Sie dazu aufgefordert werden. Wenn Sie über eine föderierte ID verfügen, melden Sie sich bitte über die Option --sso an.

   ibmcloud login -r REGION [-g <resource_group>] [--sso]
   

2. Erstellen Sie eine VPC in derselben Region, in der Sie den Cluster erstellen möchten. Müssen die Cluster von Workerknoten in Ihrer VPC Informationen an die klassische IBM Cloud-Infrastruktur senden und von ihr empfangen? Sie müssen die Schritte im Abschnitt VPC-Teilnetze für klassischen Zugriff erstellen ausführen, um einen für den klassischen Zugriff aktivierten VPC und VPC-Teilnetze zu erstellen, ohne automatisch Standardadressenpräfixe zu erstellen.

3. Erstellen Sie ein Teilnetz für Ihre VPC.

   • Wenn Sie einen Cluster mit mehreren Zonen erstellen möchten, wiederholen Sie diesen Schritt, um zusätzliche Subnetze in allen Zonen zu erstellen, die Sie in Ihren Cluster aufnehmen möchten.
   • VPC-Teilnetze stellen IP-Adressen für Ihre Workerknoten und Services für Lastausgleichsfunktionen bereit. Daher müssen Sie ein VPC-Teilnetz mit einer ausreichenden Anzahl von IP-Adressen erstellen, beispielsweise 256. Sie können die Anzahl der IPs, über die ein VPC-Teilnetz später verfügt, nicht ändern.
   • Die folgenden reservierten Bereiche dürfen nicht verwendet werden: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 und 172.20.0.0/16.
   • Wenn Workerknoten auf öffentliche Endpunkte zugreifen müssen oder wenn Sie planen, sowohl die öffentlichen als auch die privaten Cloud-Serviceendpunkte zu aktivieren, müssen Sie an jedes Teilnetz ein öffentliches Gateway anhängen, um auf Red Hat OpenShift-Standardkomponenten wie die Webkonsole oder den OperatorHub zuzugreifen.
   • Wichtig: Löschen Sie die Teilnetze, die Sie bei der Clustererstellung oder beim Hinzufügen von Workerknoten in einer Zone an Ihren Cluster angehängt haben, nicht. 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.
   • Weitere Information finden Sie in Übersicht über den VPC-Netzbetrieb in Red Hat OpenShift on IBM Cloud: Teilnetze.

4. Erstellen Sie den Cluster in Ihrem VPC. Mit dem Befehl ibmcloud oc cluster create vpc-gen2 können Sie in Ihrer VPC einen Einzelzonencluster mit Workerknoten erstellen, die nur mit einem VPC-Teilnetz verbunden sind. Wenn Sie einen Mehrzonencluster erstellen möchten, können Sie die IBM Cloud-Konsole verwenden. Nach der Erstellung des Clusters können Sie zu Ihrem Cluster aber auch noch weitere Zonen hinzufügen. Die Bereitstellung des Clusters dauert einige Minuten.

   ibmcloud oc cluster create vpc-gen2 --name CLUSTER_NAME --zone VPC_ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR --version 4.21_openshift --cos-instance COS_CRN --workers NUMBER_WORKERS_PER_ZONE [--offering OFFERING] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id ID] [--pod-subnet] [--service-subnet] [--disable-public-service-endpoint] [[--kms-account-id KMS_ACCOUNT_ID] --kms-instance KMS_INSTANCE_ID --crk ROOT_KEY_ID] [--secondary-storage STORAGE] [--disable-outbound-traffic-protection] [--operating-system SYSTEM] [--cni CNI]
   

   --name <cluster_name>

   Geben Sie einen Namen für Ihren Cluster an. Der Name muss mit einem Buchstaben beginnen, darf Buchstaben, Ziffern, Punkte (.) und den Bindestrich (-) enthalten und darf maximal 35 Zeichen lang sein. Verwenden Sie einen Namen, der in allen Regionen eindeutig ist. Der vollständig qualifizierte Domänenname für die Ingress-Unterdomäne setzt sich aus dem Clusternamen und der Region zusammen, in der der Cluster bereitgestellt wird. Um sicherzustellen, dass die Ingress-Unterdomäne innerhalb einer Region eindeutig ist, wird der Clustername möglicherweise abgeschnitten und es wird ein beliebiger Wert innerhalb des Ingress-Domänennamens angehängt.

   --zone <zone>

   Geben Sie die IBM Cloud-Zone an, in der Sie Ihren Cluster erstellen wollen. Stellen Sie sicher, dass Sie eine Zone verwenden, deren Standort mit der Stadtmetropole übereinstimmt, die Sie bei der Erstellung Ihrer VPC ausgewählt haben, und dass Sie über ein bestehendes VPC-Teilnetz für diese Zone verfügen. Wenn Sie Ihre VPC zum Beispiel in der Metropole Dallas erstellt haben, muss für Ihre Zone us-south-1, us-south-2 oder us-south-3 festgelegt werden. Führen Sie ibmcloud oc zone ls --provider vpc-gen2 aus, um verfügbare VPC-Clusterzonen aufzulisten. Beachten Sie, dass Sie bei der Auswahl einer Zone außerhalb Ihres Landes möglicherweise eine gesetzliche Genehmigung benötigen, bevor Daten physisch in einem anderen Land gespeichert werden dürfen.

   --vpc-id <vpc_ID>

   Geben Sie die ID der VPC ein, die Sie zuvor erstellt haben. Führen Sie zum Abrufen der ID Ihrer VPC den Befehl ibmcloud oc vpcs aus.

   --subnet-id <subnet_ID>

   Geben Sie die ID des VPC-Teilnetzes ein, das Sie zuvor erstellt haben. Wenn Sie einen VPC-Cluster über die Befehlszeilenschnittstelle (CLI) erstellen, können Sie Ihren Cluster zunächst in einer Zone mit nur einem Teilnetz erstellen. Zur Erstellung eines Multizonen-Clusters fügen Sie mehr Zonen mit den Teilnetzen hinzu, die Sie zuvor für Ihren Cluster erstellt haben, nachdem der Cluster erstellt wurde. Um die IDs Ihrer Teilnetze in allen Ressourcengruppen aufzulisten, führen Sie ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone> aus.

   --flavor <worker_flavor>

   Geben Sie den Typ von Workerknoten an, den Sie verwenden möchten. Der Typ bestimmt die Menge an virtueller CPU, Hauptspeicher und Festplattenspeicher, die in jedem Workerknoten eingerichtet wird und allen Containern zur Verfügung steht. VPC-Workerknoten können auf gemeinsam genutzten Infrastrukturen nur als virtuelle Maschinen erstellt werden. Bare Metall- oder softwaredefinierte Speichermaschinen werden nicht unterstützt. Um die verfügbaren Varianten anzuzeigen, listen Sie zunächst die verfügbaren VPC-Zonen mit auf und verwenden Sie anschließend die Zone ibmcloud oc zone ls --provider vpc-gen2, um die unterstützten Varianten durch Ausführen von aufzulisten ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2. Nachdem Sie Ihren Cluster erstellt haben, können Sie verschiedene Varianten hinzufügen, indem Sie einen Workerknoten oder einen Worker-Pool zum Cluster hinzufügen.

   --version 4.21_openshift

   Die Red Hat OpenShift-Version für den Cluster-Masterknoten. Führen Sie den Befehl ibmcloud oc versions aus, um die verfügbaren Versionen anzuzeigen.

   --cos-instance <cos_CRN>

   Bezieht die CRN-ID einer Standardinstanz von IBM Cloud Object Storage ein, um die interne Registry Ihres Clusters zu sichern. Wenn Sie den Cloudressourcennamen (CRN) vorhandener Instanzen auflisten möchten, führen Sie ibmcloud resource service-instances --long aus und suchen Sie die ID für Ihre Object Storage-Instanz. Um eine Standardobjektspeicherinstanz zu erstellen, führen Sie ibmcloud resource service-instance-create <name> cloud-object-storage standard global aus und notieren Sie die zugehörige ID.

   --workers <number>

   Geben Sie die Anzahl der Workerknoten an, die im Cluster eingebunden werden sollen. Wenn Sie diese Option nicht angeben, wird ein Cluster mit dem Mindestwert eins (1) erstellt.

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS: Optional. Das Betriebssystem der Workerknoten in Ihrem Cluster. Eine Liste der verfügbaren Betriebssysteme nach Cluster-Version finden Sie in den Versionsinformationen unter Red Hat OpenShift on IBM Cloud. Wenn keine Option angegeben ist, wird das Standardbetriebssystem verwendet, das der Clusterversion entspricht.

   --offering <offering>

   Optional. Geben Sie den Typ des Cluster-Angebots an. Zulässige Werte sind kubernetes, openshift und openshift-vs. Verwenden Sie „ openshift-vs “, um einen „ Red Hat OpenShift Virtualization Service“-Cluster mit vorkonfigurierten Virtualisierungsfunktionen zu erstellen. Weitere Informationen finden Sie unter „ Red Hat OpenShift: Überblick über den Virtualisierungsdienst “.

   --cluster-security-group <group_ID>

   Optional. Geben Sie mindestens eine Sicherheitsgruppen-ID an, die auf alle Worker im Cluster angewendet werden soll. Für OpenShift Version 4.15 und Kubernetes Version 1.30 und höher werden diese Sicherheitsgruppen zusätzlich zur Sicherheitsgruppe IBM-managed kube-clusterID angewendet. Geben Sie für frühere Clusterversionen die Option --cluster-security-group cluster an, um die kube-clusterID-Sicherheitsgruppe anzuwenden. Wenn kein Wert angegeben wird, wird eine Standardgruppe von Sicherheitsgruppen einschließlich kube-clusterID angewendet. Weitere Informationen finden Sie unter VPC-Sicherheitsgruppen zu Clustern und Worker-Pools während der Erstellung hinzufügen.

   Die auf einen Cluster angewendeten Sicherheitsgruppen können nicht geändert werden, nachdem der Cluster erstellt wurde. Sie können Regeln der Sicherheitsgruppen ändern, die auf den Cluster angewendet werden, aber keine Sicherheitsgruppen auf Clusterebene hinzufügen oder entfernen. Wenn Sie die falschen Sicherheitsgruppen bei der Clustererstellung anwenden, müssen Sie den Cluster löschen und einen neuen erstellen. Weitere Details finden Sie unter VPC-Sicherheitsgruppen zu Clustern und Worker-Pools während der Erstellung hinzufügen, bevor Sie Ihrem Cluster Sicherheitsgruppen hinzufügen.

   --sm-group GROUP

   Optional. Die Geheimgruppen-ID der Secrets Manager-Instanz, in der Ihre Geheimnisse gespeichert sind. Informationen zum Abrufen der ID einer Gruppe geheimer Schlüssel finden Sie in der Secrets Manager-CLI-Referenz. Verwenden Sie diese Option, um eine Gruppe geheimer Schlüssel anzugeben, die steuert, wer in Ihrem Team Zugriff auf geheime Clusterschlüssel hat.

   --sm-instance INSTANCE

   Optional. Die CRN der Secrets Manager-Instanz. Um den CRN einer Instanz abzurufen, führen Sie ibmcloud oc ingress instance ls --cluster CLUSTER aus. Geben Sie diese Option an, wenn Sie eine Secrets Manager-Instanz im Cluster registrieren möchten.

   --trusted-profile-id ID

   Geben Sie die ID eines vorhandenen vertrauenswürdigen Profils an, das mit dem Cluster verknüpft werden soll. Mit vertrauenswürdigen Profilen können Sie Zugriff auf Ressourcen in Ihrem Konto gewähren, ohne separate IAM-Anmeldeinformationen verwalten zu müssen. Weitere Informationen finden Sie unter Konfigurieren eines vertrauenswürdigen Profils.

   --pod-subnet

   Im ersten Cluster, den Sie in einer VPC erstellen, ist 172.17.0.0/18 das Standard-Pod-Teilnetz.

   In dem zweiten Cluster, den Sie in dieser VPC erstellen, lautet das Standard-Pod-Subnetz 172.17.64.0/18. In jedem weiteren Cluster ist der Podteilnetzbereich das nächste verfügbare Bereich, der keine Überschneidung mit dem Teilnetz /18 hat. Wenn Sie beabsichtigen, Ihren Cluster über IBM Cloud® Direct Link oder einen VPN-Service mit lokalen Netzen zu verbinden, können Sie mögliche Teilnetzkonflikte vermeiden, indem Sie die CIDR-Notation für ein angepasstes Teilnetz angeben, das die privaten IP-Adressen für Ihre Pods zur Verfügung stellt.

   Sie können die Teilnetzgröße angeben, indem Sie sie in die Option --pod-subnet einschließen. Beispiel: --pod-subnet 0.0.0.0/X, wobei X die erforderliche Teilnetzgröße des Pods ist. Anschließend wird das Pod-Teilnetz automatisch ausgewählt. Bei der automatischen Zuweisung des Pod-Subnetzes beginnt die Zuweisung bei 172.17.0.0, die maximale Subnetzgröße ist auf 13 und die minimale Subnetzgröße auf 23 begrenzt.

   Berücksichtigen Sie bei der Festlegung der Teilnetzgröße die Größe des Clusters, den Sie erstellen wollen, und die Anzahl der Workerknoten, die Sie möglicherweise später hinzufügen. Das Subnetz muss eine CIDR-Adresse von mindestens haben /23, wodurch genügend Pod-IP-Adressen für maximal vier Worker-Knoten in einem Cluster bereitgestellt werden. Für größere Cluster verwenden Sie /22, um genügend Pod-IP-Adressen für acht Workerknoten zu haben, /21, um genügend Pod-IP-Adressen für 16 Workerknoten zu haben, usw. Beachten Sie, dass sich Pod- und Serviceteilnetze nicht überschneiden dürfen. Wenn Sie für Ihre Worker-Knoten Subnetze mit benutzerdefiniertem Adressbereich verwenden, müssen Sie sicherstellen, dass sich die Subnetze Ihrer Worker-Knoten nicht mit dem Pod-Subnetz Ihres Clusters überschneiden. Das ausgewählte Teilnetz muss sich in einem der folgenden Bereiche befinden: 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255, 198.18.0.0 - 198.19.255.255.

   --service-subnet

   Allen Services, die auf dem Cluster bereitgestellt werden, wird standardmäßig eine private IP-Adresse im Bereich 172.21.0.0/16 zugeordnet. Wenn Sie beabsichtigen, Ihren Cluster über IBM Cloud Direct Link oder einen VPN-Service mit lokalen Netzen zu verbinden, können Sie mögliche Teilnetzkonflikte vermeiden, indem Sie die CIDR-Notation für ein angepasstes Teilnetz angeben, das die privaten IP-Adressen für Ihre Services zur Verfügung stellt. Das Teilnetz muss im CIDR-Format mit einer Länge von mindestens /24 angegeben werden. Auf diese Weise sind maximal 255 Services (oder mehr) im Cluster zulässig. Das ausgewählte Teilnetz muss sich in einem der folgenden Bereiche befinden: 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255, 198.18.0.0 - 198.19.255.255. Beachten Sie, dass sich Pod-und Serviceteilnetze nicht überschneiden dürfen.

   --disable-public-service-endpoint

   Schließen Sie diese Option in Ihren Befehl ein, um Ihren VPC-Cluster nur mit einem Private-Cloud-Serviceendpunkt zu erstellen. Wenn Sie diese Option nicht angeben, wird Ihr Cluster mit einem öffentlichen und einem privaten Cloud-Serviceendpunkt eingerichtet. Der Serviceendpunkt bestimmt, wie Ihr Red Hat OpenShift-Master und die Workerknoten kommunizieren, wie Ihr Cluster auf andere IBM Cloud-Services und auf Apps außerhalb des Clusters zugreift und wie sich Ihre Benutzer mit Ihrem Cluster verbinden. Weitere Informationen finden Sie in Konfiguration des Clusternetzes planen. Wenn Sie diese Option auswählen, wird Ihr Cluster standardmäßig mit Routern und Ingress-Controllern erstellt, die Ihre Anwendungen ausschließlich 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.

   --kms-account-id <KMS_acount_ID>

   Optional: Muss eingeschlossen werden, wenn die Optionen --kms-instance-id und --crk bereitgestellt werden und sich die KMS-Instanz in einem anderen Konto als dem Konto des Clusters befindet. Andernfalls kann sie weggelassen werden. Die Einrichtung der Verschlüsselung mithilfe eines KMS aus einem anderen Konto ist nur für Konten verfügbar, die in der Zulassungsliste aufgeführt sind. Um zur Zulassungsliste hinzugefügt zu werden, öffnen Sie einen Fall mit Unterstützung.

   --kms-instance <KMS_instance_ID>

   Optional: Geben Sie die ID einer KMS-Instanz (Key Management Service) an, die zum Verschlüsseln der lokalen Platte auf den Workerknoten im default-Workerpool verwendet wird. Führen Sie zum Auflisten der verfügbaren KMS-Instanzen den Befehl ibmcloud oc kms instance ls aus. Wenn Sie diese Option einschließen, müssen Sie auch die Option --crk einschließen. Bevor Sie die KMS-Verschlüsselung verwenden können, müssen Sie eine KMS-Instanz erstellen und die erforderliche Serviceberechtigung in IAM einrichten. Siehe Verwaltung von Verschlüsselungen für Workerknoten in Ihrem Cluster.

   --crk <root_key>

   Optional: Schließen Sie die ID des Rootschlüssels in die KMS-Instanz ein, um die lokale Platte auf den Workerknoten im default-Workerpool zu verschlüsseln. Um die verfügbaren Stammelementschlüssel aufzulisten führen Sie ibmcloud oc kms crk ls --instance-id aus. Wenn Sie diese Option einschließen, müssen Sie auch die Option --kms-instance einschließen. Bevor Sie die KMS-Verschlüsselung verwenden können, müssen Sie eine KMS-Instanz erstellen und die erforderliche Serviceberechtigung in IAM einrichten. Siehe Verwaltung von Verschlüsselungen für Workerknoten in Ihrem Cluster.

   --secondary-storage STORAGE

   Optional. Die Speicheroption für die Instanzvariante. Beispiel: 900gb.5iops-tier. Wenn Sie eine sekundäre Platte hinzufügen, wird diese Platte für die Containerlaufzeit verwendet, während die primäre Platte für das Betriebssystem verwendet wird. Führen Sie den Befehl ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2 aus, um die Speicheroption für eine Version anzuzeigen. Eine Liste der VPC-Workerknotentypen finden Sie unter VPC-Typen.

   --disable-outbound-traffic-protection

   Optional. Deaktivieren Sie den Schutz des ausgehenden Datenverkehrs.

   --cni CNI

   Stellen Sie das Netzwerk-Plugin für den Cluster ein. Calico ist standardmäßig eingestellt. Akzeptierte Werte: Calico, OVNKubernetes.

   --offering OFFERING

   Optional. Geben Sie den Typ des Cluster-Angebots an. Verwenden Sie „ openshift-vs “, um einen „ Red Hat OpenShift Virtualization Service“-Cluster mit vorkonfigurierten Virtualisierungsfunktionen zu erstellen. Sofern nicht anders angegeben, wird ein Standard- OpenShift-Cluster erstellt. Weitere Informationen finden Sie unter „ Red Hat OpenShift: Überblick über den Virtualisierungsdienst “.

5. Prüfen Sie, ob die Erstellung des Clusters angefordert wurde. Es kann einige Minuten dauern, bis die Maschinen mit den Workerknoten angewiesen werden und der Cluster in Ihrem Konto eingerichtet und bereitgestellt wird.

   ibmcloud oc cluster ls
   

   Wenn die Bereitstellung des Red Hat OpenShift Masters abgeschlossen ist, ändert sich der Status des Clusters in normal. Sobald der Red Hat OpenShift-Master bereit ist, werden Ihre Workerknoten eingerichtet.

   NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    aaf97a8843a29941b49a598f516da72101   normal   20170201162433   3          Dallas     4.21.27_1544_openshift      Default               vpc-gen2
   

6. Überprüfen Sie den Status der Workerknoten.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Wenn die Workerknoten bereit sind, ändert sich der **Status des Worker-Knoten ** in normal und der Status ändert sich in Ready. Wenn der Status des Knotens Ready (Bereit) lautet, können Sie auf den Cluster zugreifen. Beachten Sie, dass selbst bei Bereitschaft des Clusters einige seiner Teile, die von anderen Services wie den geheimen Ingress-Schlüsseln oder geheimen Schlüsseln für Registry-Image-Pull-Operationen verwendet werden, möglicherweise noch in Verarbeitung sind.

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   b3c.4x16.encrypted  normal   Ready    dal10   4.21.27_1544_openshift
   

   Jedem Workerknoten werden eine eindeutige Workerknoten-ID und ein Domänenname zugewiesen, die nach dem Erstellen des Clusters nicht manuell geändert werden dürfen. Wenn Sie die ID oder den Domänennamen ändern, kann der Red Hat OpenShift Master Ihren Cluster nicht verwalten.

Beispielbefehle zum Erstellen von VPC-Clustern

Versionen mit Instanzspeicher sind für Konten mit Zulassungsliste verfügbar. Um zur Zulassungsliste hinzugefügt zu werden, öffnen Sie einen Fall mit Unterstützung.

Beispielbefehl zum Erstellen eines VPC-Clusters mit drei Workerknoten in us-east-1.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN--flavor bx2.4x16 --workers 3

Beispielbefehl zum Erstellen eines VPC-Clusters mit 3 Arbeitsknoten in us-east-1 mit einem benutzerdefinierten Pod-Subnetzbereich und einer benutzerdefinierten Größe und deaktiviertem Schutz für ausgehenden Datenverkehr.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN --flavor bx2.4x16 --workers 3 --pod-subnet 0.0.0.0/15 --disable-outbound-traffic-protection

Beispielbefehl für einen VPC-Cluster mit Workerknoten, auf denen das Betriebssystem Red Hat CoreOS (RHCOS) ausgeführt wird.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHCOS

Beispielbefehl für einen VPC-Cluster mit Arbeitsknoten, auf denen das Betriebssystem RHEL 9 ausgeführt wird und bei denen der Schutz für ausgehenden Datenverkehr deaktiviert ist.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHEL_9_64 --disable-outbound-traffic-protection

Beispielbefehl zum Erstellen eines Clusters mit 3 Workerknoten in us-south-1 und zum Aktivieren der Plattenverschlüsselung für Workerknoten durch Angabe Ihrer KMS-Providerinstanz-ID, Konto-ID und CRK.

ibmcloud oc cluster create vpc-gen2 --name <cluster_name> --zone us-south-1 --vpc-id VPC-ID --subnet-id SUBNET-ID --flavor b3c.4x16 --workers 3 --kms-account-id KMS-ACCOUNT-ID --kms-instance-id KMS-INSTANCE-ID --crk CRK

Beispielbefehl zum Hinzufügen von Arbeitsknoten durch Hinzufügen einer Zone zu einem Multizonen-VPC-Cluster.

ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster <cluster_name_or_ID> --worker-pool WORKER-POOL --subnet-id SUBNET-ID

VPC-Cluster mit Terraform erstellen

• Terraform IBM Cloud ermöglicht eine vorhersehbare und konsistente Bereitstellung der IBM Cloud Plattforminfrastruktur und -ressourcen, einschließlich VPC-Clustern.

• Um einen VPC-Cluster mit Terraform zu erstellen, erstellen Sie zunächst eine Terraform-Konfigurationsdatei, die den Typ der Clusterressource deklariert, die Sie erstellen möchten. Anschließend wenden Sie die Terraform-Konfigurationsdatei an.

• Weitere Informationen zu Terraform finden Sie unter „Über Terraform“ auf IBM Cloud.

• Das Terraform IBM Modul - Red Hat OpenShift VPC-Cluster auf IBM Cloud enthält gebrauchsfertigen Infrastrukturcode und praktische Beispiele, die Ihre Bereitstellung beschleunigen können. Wenn Sie eine unternehmensgerechte OpenShift Umgebung schnell und konsistent bereitstellen möchten, ist dieses Modul ein guter Ausgangspunkt.

Vorbereitende Schritte

• Installieren Sie die Terraform-CLI und das IBM Cloud Provider-Plug-in.
• Stellen Sie sicher, dass Sie einen IBM Cloud API-Schlüssel haben.

1. Erstellen Sie eine Terraform-Provider-Datei. Speichern Sie die Datei im Terraform-Verzeichnis. Weitere Informationen finden Sie in der Terraform-Dokumentation zu IBM Cloud Provider.

   Beispieldatei für Terraform-Provider.

   terraform {
       required_providers {
           ibm = {
               source = "IBM-Cloud/ibm"
               version = "1.53.0"
           }
       }
   }
   provider "ibm" {
       region = "us-south"
       ibmcloud_api_key = "<api-key>"
   }
   

2. a) Erstellen Sie eine Terraform-Konfigurationsdatei für einen VPC-Cluster. Speichern Sie die Datei im Terraform-Verzeichnis. Weitere Informationen und Optionen zur Clusterkonfiguration finden Sie in der Dokumentation zu Terraform ibm_container_cluster.

   Beispiel für eine Terraform-Konfigurationsdatei:

   resource "ibm_container_vpc_cluster" "cluster" {
       name              = "tf-vpc"
       vpc_id            = "<vpc_id>"
       flavor            = "bx2.16x64"
       worker_count      = "3"
       operating_system  = "REDHAT_8_64"
       kube_version      = "1.28.2"
       resource_group_id = "<resource_group_id>"
       zones {
           subnet_id = "<subnet_id>"
           name      = "us-south-1"
       }
   }
   

   name

   Erforderlich. Der Name des Clusters.

   vpc_id

   Erforderlich. Die ID der VPC, die Sie für Ihren Cluster verwenden möchten. Um die verfügbaren VPCs aufzulisten, führen Sie folgenden Befehl aus: ibmcloud is vpcs.

   flavor

   Erforderlich. Der Typ des Workerknotens. Der Typ bestimmt die Menge an Hauptspeicher, CPU und Plattenspeicher, die Ihren Workerknoten zur Verfügung steht. Eine Liste der verfügbaren Workerknotentypen finden Sie unter ibmcloud oc flavors --zone <zone> --provider classic oder unter Klassische Typen.

   worker_count

   Die Anzahl der Workerknoten, die zum Standard-Worker-Pool hinzugefügt werden sollen

   operating_system

   Das Betriebssystem der Workerknoten im Worker-Pool. Eine Liste der unterstützten Betriebssysteme nach Clusterversion finden Sie unter Red Hat OpenShift on IBM Cloud-Versionsinformationen.

   kube_version

   Die Kubernetes-Version Ihres Clusters. Standardmäßig werden Cluster mit der Standardversion von Kubernetes erstellt, aber Sie können eine andere unterstützte Version angeben.

   resource_group_id

   Die ID der Ressourcengruppe. Um die verfügbaren Ressourcengruppen anzuzeigen, führen Sie folgenden Befehl aus: ibmcloud resource groups. Wenn kein Wert angegeben wird, wird die Standardressourcengruppe verwendet.

   zones

   Ein verschachtelter Block, der die Zonen des Standardworker-Pools des VPC-Clusters beschreibt.

   • subnet_id: Erforderlich. Die ID des VPC-Teilnetzes, das Sie für Ihre Workerknoten verwenden möchten Führen Sie ibmcloud oc subnets --provider classic --zone <zone> aus, um vorhandene Teilnetze zu suchen.

   • name: Erforderlich. Der Zonenname für den Standardworker-Pool. Um die verfügbaren Zonen anzuzeigen, führen Sie folgenden Befehl aus: ibmcloud oc zones --provider vpc-gen2.

   b) Wenn Sie es vorziehen, Terraform IBM Module zu verwenden, können Sie auch das folgende Beispiel zur Bereitstellung verwenden Red Hat OpenShift Cluster auf VPC Gen2

       locals {
           worker_pools = [
               {
                   subnet_prefix    = "default"
                   pool_name        = "default"
                   machine_type     = "bx2.4x16"
                   workers_per_zone = 2
                   operating_system = "RHCOS"
               }
           ]
           cluster_vpc_subnets = {
               default    = [
                   {
                       id         = "0717-afc29fbb-0dbe-493a-a5b9-f3c5899cb8b9"
                       cidr_block = "192.168.32.0/22"                        
                       zone       = "us-south-1"
                   }
               ]
           }
       }
       module "ocp_base" {
           source               = "terraform-ibm-modules/base-ocp-vpc/ibm"
           version              = "3.81.3"
           region               = "us-south"
           resource_group_id    = "resource-group-id"
           cluster_name         = "test-ocp-cluster"
           force_delete_storage = true
           vpc_id               = "vpc-id"
           vpc_subnets          = local.cluster_vpc_subnets
           worker_pools         = local.worker_pools
       }
   

3. Navigieren Sie in der Befehlszeilenschnittstelle zum Terraform-Verzeichnis.

   cd <terraform_directory>
   

4. Führen Sie die Befehle zum Initialisieren und Planen Ihrer Terraform-Aktionen aus. Überprüfen Sie die Planausgabe, um sicherzustellen, dass die richtigen Aktionen ausgeführt werden.

   terraform init
   

   terraform plan
   

5. Wenden Sie die Terraform-Dateien an, um den Cluster zu erstellen. Navigieren Sie anschließend zur IBM Cloud-Konsole, um zu überprüfen, ob der Cluster bereitgestellt wird.

   terraform apply