Unterstützungsrichtlinien in Azure Red Hat OpenShift 4.0

Artikel
08/29/2024

Bestimmte Konfigurationen Ihrer Cluster in Azure Red Hat OpenShift 4 können sich auf die Unterstützbarkeit Ihres Clusters auswirken. In Azure Red Hat OpenShift 4 können Clusteradministratoren Änderungen an internen Clusterkomponenten vornehmen. Es werden jedoch nicht alle Änderungen unterstützt. Die Unterstützungsrichtlinien unten fassen zusammen, welche Änderungen die Richtlinien verletzen und damit die Unterstützung durch Microsoft und Red Hat aufheben.

Hinweis

Features, die auf der OpenShift-Plattform für Container als Technologievorschau gekennzeichnet sind, werden in Azure Red Hat OpenShift nicht unterstützt.

Clusterkonfigurationsanforderungen

Compute

Der Cluster muss mindestens drei Workerknoten und drei Masterknoten aufweisen.
Skalieren Sie die Clusterworker nicht auf Null, oder versuchen Sie, den Cluster herunterzufahren. Das Aufheben der Zuordnung oder das Herunterfahren von VMs in der Clusterressourcengruppe wird nicht unterstützt.
Erstellen Sie in einem Cluster nicht mehr als 250 Workerknoten. 250 ist die maximale Anzahl von Knoten, die in einem Cluster erstellt werden können. Weitere Informationen finden Sie unter Konfigurieren mehrerer IP-Adressen pro ARO-Clusterlastenausgleich.
Wenn Sie Infrastrukturknoten verwenden, führen Sie keine nicht angegebenen Workloads darauf aus, da sich dies auf die Vereinbarung zum Servicelevel und die Clusterstabilität auswirken kann. Außerdem werden drei Infrastrukturknoten empfohlen – einer für jede Verfügbarkeitszone. Weitere Informationen finden Sie unter Bereitstellen von Infrastrukturknoten in einem Azure Red Hat OpenShift-Cluster (ARO).
Nicht-RHCOS-Serverknoten werden nicht unterstützt. Sie können z. B. keinen RHEL-Serverknoten verwenden.
Versuchen Sie nicht, einen Masterknoten zu entfernen, zu ersetzen, hinzuzufügen oder zu ändern. Dies ist ein Vorgang mit hohem Risiko, der Probleme mit etcd, dauerhafte Netzwerkverluste und Verlust von Zugriff und Verwaltbarkeit durch ARO SRE verursachen kann. Wenn Sie den Eindruck haben, dass ein Masterknoten ersetzt oder entfernt werden soll, wenden Sie sich an den Support, bevor Sie Änderungen vornehmen.
Stellen Sie sicher, dass ausreichend VM-Kontingente zur Verfügung stehen, falls die Knoten der Steuerungsebene skaliert werden müssen, indem Sie mindestens die doppelte Anzahl der aktuellen vCPU der Steuerungsebene bereithalten.

Operatoren

Alle Clusteroperatoren in OpenShift müssen in einem verwalteten Zustand verbleiben. Die Liste der Clusteroperatoren kann zurückgegeben gegeben werden, indem oc get clusteroperators ausgeführt wird.

Verwaltung von Arbeitsauslastungen

Fügen Sie keine Taints hinzu, die verhindern würden, dass OpenShift-Standardkomponenten geplant werden.
Um Unterbrechungen infolge der Clusterwartung zu vermeiden, sollten clusterinterne Workloads mit Hochverfügbarkeitsverfahren konfiguriert werden, einschließlich, aber nicht beschränkt auf Podaffinität und -Antiaffinität, Budgets für die Unterbrechung von Pods und angemessener Skalierung.
Führen Sie keine zusätzlichen Workloads auf den Knoten auf Steuerungsebene aus. Sie können zwar auf den Knoten der Steuerungsebene geplant werden, dies führt aber zu zusätzlicher Ressourcenauslastung sowie Stabilitätsproblemen, die sich auf den gesamten Cluster auswirken können.
Das Ausführen von benutzerdefinierten Workloads auf Infrastrukturknoten – einschließlich Operatoren, die vom Operator Hub installiert wurden oder anderen von Red Hat bereitgestellte Operatoren – wird nicht unterstützt.

Protokollierung und Überwachung

Entfernen oder ändern Sie nicht den Standardclusterdienst von Prometheus, außer um die Planung der Prometheus-Standardinstanz zu ändern.
Entfernen oder ändern Sie nicht den Standardcluster-Alertmanager-SVC, Standardempfänger oder Standardbenachrichtigungsregeln, außer um andere Empfänger hinzuzufügen, die externe Systeme benachrichtigen sollen.
Entfernen oder ändern Sie die Protokollierung im Azure Red Hat OpenShift-Dienst nicht (MDSD-Pods).

Netzwerk und Sicherheit

Die von ARO bereitgestellte Netzwerksicherheitsgruppe kann nicht geändert oder ersetzt werden. Jeder Versuch, sie zu ändern oder zu ersetzen, wird rückgängig gemacht.
Alle Cluster-VMs benötigen direkten ausgehenden Internetzugriff, und zwar mindestens auf die Endpunkte für Azure Resource Manager (ARM) und die Dienstprotokollierung (Geneva). Es wird keine Form von HTTPS-Proxys unterstützt.
Der Azure Red Hat OpenShift-Dienst greift auf Ihre Cluster über den Private Link-Dienst zu. Ändern oder entfernen Sie den Dienstzugriff nicht.
Die Migration von OpenShift-SDN zu OVN wird nicht unterstützt.

Verwalten von Hadoop-Clustern in HDInsight mit .NET-SDK

Entfernen oder ändern Sie das Clusterpullgeheimnis „arosvc.azurecr.io“ nicht.
Erstellen Sie keine neuen MachineConfig-Objekte, oder ändern Sie keine vorhandenen Objekte, es sei denn, sie werden in der OpenShift-Dokumentation von Azure Red Hat explizit unterstützt.
Erstellen Sie keine neuen KubeletConfig-Objekte, oder ändern Sie keine vorhandenen Objekte, es sei denn, dies wird in der Azure Red Hat OpenShift-Dokumentation explizit unterstützt.
Legen Sie keine unsupportedConfigOverrides-Optionen fest. Durch Festlegen dieser Optionen werden Upgrades von Nebenversionen verhindert.
Platzieren Sie in Ihrem Abonnement oder Ihrer Verwaltungsgruppe keine Richtlinien, die SREs an der Durchführung normaler Wartungsarbeiten am Azure Red Hat OpenShift-Cluster hindern. Verlangen Sie zum Beispiel keine Tags für die RP-verwaltete Azure Red Hat OpenShift-Clusterressourcengruppe.
Umgehen Sie nicht die Ablehnungszuweisung, die als Teil des Diensts konfiguriert ist, und führen Sie keine administrative Aufgaben aus, die durch die Ablehnungszuweisung verboten sind.
OpenShift basiert auf der Möglichkeit, Azure-Ressourcen automatisch zu kennzeichnen. Wenn Sie eine Taggingrichtlinie konfiguriert haben, wenden Sie nicht mehr als 10 benutzerdefinierte Tags auf Ressourcen in der verwalteten Ressourcengruppe an.

Incident Management

Ein Incident ist ein Ereignis, das zu einer Beeinträchtigung oder einem Ausfall von Azure Red Hat OpenShift-Diensten führt. Incidents werden von einem Kunden- oder Customer Experience and Engagement-Mitglied (CEE) über einen Supportfall, direkt durch das zentrale Überwachungs- und Warnsystem oder direkt durch ein Mitglied des Teams ARO Site Reliability Engineer (SRE) ausgelöst.

Abhängig von den Auswirkungen auf den Dienst und den Kunden wird der Incident nach Schweregrad kategorisiert.

Der allgemeine Workflow, wie ein neuer Incident behandelt wird, ist unten beschrieben:

Ein SRE-First Responder wird auf einen neuen Incident aufmerksam gemacht und beginnt mit einer ersten Untersuchung.
Nach der ersten Untersuchung wird dem Incident ein Incidentleiter zugewiesen, der die Behebung koordiniert.
Der Incidentleiter verwaltet alle Kommunikation und Koordination rund um die Behebung, einschließlich relevanter Benachrichtigungen oder Supportfall-Updates.
Der Incident wurde behoben.
Der Incident wird dokumentiert und eine Grundursachenanalyse (Root Cause Analysis, RCA) innerhalb von 5 Werktagen nach dem Incident durchgeführt.
Ein RCA-Entwurfsdokument wird innerhalb von 7 Werktagen nach dem Incident mit dem Kunden geteilt.

Unterstützte VM-Größen

Azure Red Hat OpenShift 4 unterstützt Knoteninstanzen für die folgenden VM-Größen:

Knoten der Steuerungsebene

Reihen	Größe	vCPU	Memory: GiB
Dsv3	Standard_D8s_v3	8	32
Dsv3	Standard_D16s_v3	16	64
Dsv3	Standard_D32s_v3	32	128
Dsv4	Standard_D8s_v4	8	32
Dsv4	Standard_D16s_v4	16	64
Dsv4	Standard_D32s_v4	32	128
Dsv5	Standard_D8s_v5	8	32
Dsv5	Standard_D16s_v5	16	64
Dsv5	Standard_D32s_v5	32	128
Dasv4	Standard_D8as_v4	8	32
Dasv4	Standard_D16as_v4	16	64
Dasv4	Standard_D32as_v4	32	128
Dasv5	Standard_D8as_v5	8	32
Dasv5	Standard_D16as_v5	16	64
Dasv5	Standard_D32as_v5	32	128
Easv4	Standard_E8as_v4	8	64
Easv4	Standard_E16as_v4	16	128
Easv4	Standard_E20as_v4	20	160
Easv4	Standard_E32as_v4	32	256
Easv4	Standard_E48as_v4	48	384
Easv4	Standard_E64as_v4	64	512
Easv4	Standard_E96as_v4	96	672
Easv5	Standard_E8as_v5	8	64
Easv5	Standard_E16as_v5	16	128
Easv5	Standard_E20as_v5	20	160
Easv5	Standard_E32as_v5	32	256
Easv5	Standard_E48as_v5	48	384
Easv5	Standard_E64as_v5	64	512
Easv5	Standard_E96as_v5	96	672
Eisv3	Standard_E64is_v3	64	432
Eis4	Standard_E80is_v4	80	504
Eids4	Standard_E80ids_v4	80	504
Eisv5	Standard_E104is_v5	104	672
Eidsv5	Standard_E104ids_v5	104	672
Esv4	Standard_E8s_v4	8	64
Esv4	Standard_E16s_v4	16	128
Esv4	Standard_E20s_v4	20	160
Esv4	Standard_E32s_v4	32	256
Esv4	Standard_E48s_v4	48	384
Esv4	Standard_E64s_v4	64	504
Esv5	Standard_E8s_v5	8	64
Esv5	Standard_E16s_v5	16	128
Esv5	Standard_E20s_v5	20	160
Esv5	Standard_E32s_v5	32	256
Esv5	Standard_E48s_v5	48	384
Esv5	Standard_E64s_v5	64	512
Esv5	Standard_E96s_v5	96	672
Fsv2	Standard_F72s_v2	72	144
Mms*	Standard_M128ms	128	3.892

* Standard_M128ms' unterstützt keine Verschlüsselung auf dem Host.

Workerknoten

Allgemeiner Zweck

Reihen	Größe	vCPU	Memory: GiB
Dasv4	Standard_D4as_v4	4	16
Dasv4	Standard_D8as_v4	8	32
Dasv4	Standard_D16as_v4	16	64
Dasv4	Standard_D32as_v4	32	128
Dasv4	Standard_D64as_v4	64	256
Dasv4	Standard_D96as_v4	96	384
Dasv5	Standard_D4as_v5	4	16
Dasv5	Standard_D8as_v5	8	32
Dasv5	Standard_D16as_v5	16	64
Dasv5	Standard_D32as_v5	32	128
Dasv5	Standard_D64as_v5	64	256
Dasv5	Standard_D96as_v5	96	384
Dsv3	Standard_D4s_v3	4	16
Dsv3	Standard_D8s_v3	8	32
Dsv3	Standard_D16s_v3	16	64
Dsv3	Standard_D32s_v3	32	128
Dsv4	Standard_D4s_v4	4	16
Dsv4	Standard_D8s_v4	8	32
Dsv4	Standard_D16s_v4	16	64
Dsv4	Standard_D32s_v4	32	128
Dsv4	Standard_D64s_v4	64	256
Dsv5	Standard_D4s_v5	4	16
Dsv5	Standard_D8s_v5	8	32
Dsv5	Standard_D16s_v5	16	64
Dsv5	Standard_D32s_v5	32	128
Dsv5	Standard_D64s_v5	64	256
Dsv5	Standard_D96s_v5	96	384

Arbeitsspeicheroptimiert

Reihen	Größe	vCPU	Memory: GiB
Easv4	Standard_E4as_v4	4	32
Easv4	Standard_E8as_v4	8	64
Easv4	Standard_E16as_v4	16	128
Easv4	Standard_E20as_v4	20	160
Easv4	Standard_E32as_v4	32	256
Easv4	Standard_E48as_v4	48	384
Easv4	Standard_E64as_v4	64	512
Easv4	Standard_E96as_v4	96	672
Easv5	Standard_E8as_v5	8	64
Easv5	Standard_E16as_v5	16	128
Easv5	Standard_E20as_v5	20	160
Easv5	Standard_E32as_v5	32	256
Easv5	Standard_E48as_v5	48	384
Easv5	Standard_E64as_v5	64	512
Easv5	Standard_E96as_v5	96	672
Esv3	Standard_E4s_v3	4	32
Esv3	Standard_E8s_v3	8	64
Esv3	Standard_E16s_v3	16	128
Esv3	Standard_E32s_v3	32	256
Esv4	Standard_E4s_v4	4	32
Esv4	Standard_E8s_v4	8	64
Esv4	Standard_E16s_v4	16	128
Esv4	Standard_E20s_v4	20	160
Esv4	Standard_E32s_v4	32	256
Esv4	Standard_E48s_v4	48	384
Esv4	Standard_E64s_v4	64	504
Esv5	Standard_E4s_v5	4	32
Esv5	Standard_E8s_v5	8	64
Esv5	Standard_E16s_v5	16	128
Esv5	Standard_E20s_v5	20	160
Esv5	Standard_E32s_v5	32	256
Esv5	Standard_E48s_v5	48	384
Esv5	Standard_E64s_v5	64	512
Esv5	Standard_E96s_v5	96	672
Edsv5	Standard_E96ds_v5	96	672
Eisv3	Standard_E64is_v3	64	432
Eis4	Standard_E80is_v4	80	504
Eids4	Standard_E80ids_v4	80	504
Eisv5	Standard_E104is_v5	104	672
Eidsv5	Standard_E104ids_v5	104	672

Computeoptimiert

Reihen	Größe	vCPU	Memory: GiB
Fsv2	Standard_F4s_v2	4	8
Fsv2	Standard_F8s_v2	8	16
Fsv2	Standard_F16s_v2	16	32
Fsv2	Standard_F32s_v2	32	64
Fsv2	Standard_F72s_v2	72	144

Für Arbeitsspeicher und Compute optimiert

Reihen	Größe	vCPU	Memory: GiB
Mms*	Standard_M128ms	128	3.892