Bereitstellen eines großen Azure Red Hat OpenShift-Clusters
Dieser Artikel enthält die Schritte und bewährten Methoden für die Bereitstellung großer Azure Red Hat OpenShift-Cluster mit bis zu 250 Workerknoten. Für Cluster dieser Größe gibt es einige Empfehlungen für Knoten auf Steuerungsebene und Infrastrukturknoten.
Achtung
Bevor Sie einen Cluster mit mehr als 120 Knoten löschen, skalieren Sie den Cluster auf 120 oder weniger Knoten herunter.
Empfehlungen
Knoten der Steuerungsebene
Für Cluster mit mehr als 100 Workerknoten werden die folgenden VM-Instanztypen (oder ähnliche Instanztypen der neueren Generation) für Knoten auf Steuerungsebene empfohlen:
- Standard_D32s_v3
- Standard_D32s_v4
- Standard_D32s_v5
Infrastrukturknoten
Für Cluster mit über 100 Workerknoten sind Infrastrukturknoten erforderlich, um Clusterworkloads (z. B. Prometheus) zu trennen und Konflikte mit anderen Workloads zu minimieren. Sie sollten drei (3) Infrastrukturknoten pro Cluster bereitstellen, um Redundanz- und Skalierbarkeitsanforderungen zu erfüllen.
Die folgenden Instanztypen werden für Infrastrukturknoten empfohlen:
- Standard_E16as_v5
- Standard_E16s_v5
Anweisungen zum Konfigurieren von Infrastrukturknoten finden Sie unter Bereitstellen von Infrastrukturknoten in einem Azure Red Hat OpenShift-Cluster. Diese Konfiguration erfolgt nach der Clusterbereitstellung.
Hinzufügen von IP-Adressen zum Lastenausgleich
Öffentliche Azure Red Hat OpenShift-Cluster werden mit einem öffentlichen Lastenausgleich erstellt, der für ausgehende Verbindungen innerhalb des Clusters verwendet wird. Standardmäßig wird für diesen öffentlichen Lastenausgleich eine öffentliche IP-Adresse konfiguriert. Dadurch wird die maximale Knotenanzahl Ihres Clusters auf 62 beschränkt. Damit Ihr Cluster auf die maximal unterstützte Anzahl von 250 Knoten skaliert werden kann, müssen Sie dem Lastenausgleich mehrere zusätzliche öffentliche IP-Adressen zuweisen. Sie können bis zu 20 IP-Adressen pro Cluster konfigurieren. Die Ausgangsregeln und Front-End-IP-Konfigurationen werden an die Anzahl der IP-Adressen angepasst.
Ein Cluster mit 180 Workerknoten benötigt beispielsweise mindestens drei (3) IP-Adressen (180 Knoten/62 Knoten pro IP-Adresse).
Dieser Schritt kann im Rahmen des Clustererstellungsprozesses oder später nach der Clustererstellung ausgeführt werden.
Bereitstellen eines Clusters
Bei der Bereitstellung eines großen Clusters müssen Sie bei der Erstellung mit höchstens 50 Workerknoten beginnen und dann den Cluster auf die gewünschte Anzahl von Workerknoten (bis zu 250 Workerknoten) aufskalieren.
Hinweis
Sie können zur Erstellungszeit zwar bis zu 50 Workerknoten definieren, es empfiehlt sich aber, mit einem kleinen Cluster (z. B. drei (3) Workerknoten) zu beginnen und dann nach der Installation des Clusters auf die gewünschte Anzahl von Workerknoten aufzuskalieren.
Führen Sie die Schritte unter Erstellen eines Azure Red Hat OpenShift 4-Clusters bis zu den Schritten unter „Erstellen Sie den Cluster“ aus, und fahren Sie dann gemäß den Anweisungen fort:
Mit dem folgenden Beispielbefehl können Sie unter Verwendung der Azure CLI einen Cluster mit „Standard_D32s_v5“ als Knoten auf Steuerungsebene bereitstellen und dabei drei öffentliche IP-Adressen anfordern und neun Workerknoten definieren:
az aro create \
--resource-group $RESOURCEGROUP \
--name $CLUSTER \
--vnet aro-vnet \
--master-subnet master-subnet \
--worker-subnet worker-subnet \
--master-vm-size Standard_D32s_v5 \
--worker-count 9 \
--lb-ip-count 3
Führen Sie den folgenden Befehl aus, um dem Lastenausgleich mithilfe der Azure CLI nach der Clustererstellung IP-Adressen hinzuzufügen:
az aro update
--name <CLUSTER_NAME>
–-resource-group <RESOURCE_GROUP>
--lb-ip-count <PUBLIC_IP_COUNT>`
Anschließend können Sie die entsprechenden OpenShift MachineSets konfigurieren, um die gewünschte Anzahl an Workerknoten zu erhalten. Ausführlichere Informationen finden Sie unter Manually scaling a compute machine set (Manuelle Skalierung einer Computemaschinengruppe).
Fahren Sie nach der erfolgreichen Installation des Clusters mit der Bereitstellung von Infrastrukturknoten fort, wie im Abschnitt Infrastrukturknoten beschrieben.