Freigeben über

Unterstützungsrichtlinien in Azure Red Hat OpenShift 4.0

Bestimmte Konfigurationen für Microsoft Azure Red Hat OpenShift 4-Cluster können sich auf die Unterstützung 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 unten aufgeführte Supportrichtlinie zeigt, welche Änderungen gegen die Richtlinie verstoßen und den Support von Microsoft und Red Hat ungültig machen.

Hinweis

Features, die als Technologievorschau in der OpenShift-Containerplattform gekennzeichnet sind, werden in Azure Red Hat OpenShift nicht unterstützt.

Clusterkonfigurationsanforderungen

Berechnen

  • 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 Azure Red Hat OpenShift-Clusterlastenausgleich.
  • Wenn Sie Infrastrukturknoten verwenden, führen Sie keine nicht entworfenen Workloads darauf aus, da sie sich auf die Servicelevelvereinbarung und die Clusterstabilität auswirken können. Außerdem empfiehlt es sich, drei Infrastrukturknoten zu haben; eine in jeder Verfügbarkeitszone. Weitere Informationen finden Sie unter Bereitstellen von Infrastrukturknoten in einem Azure Red Hat OpenShift-Cluster.
  • Nicht-RHCOS-Serverknoten werden nicht unterstützt. Sie können z. B. keinen RheL-Computeknoten (Red Hat Enterprise Linux) verwenden.
  • Versuchen Sie nicht, einen Masterknoten zu entfernen, zu ersetzen, hinzuzufügen oder zu ändern. Bei diesen Aufgaben handelt es sich um Vorgänge mit hohem Risiko, die Probleme mit etcd, dauerhaften Netzwerkverlusten sowie dem Verlust von Zugriff und Verwaltbarkeit für einen Site Reliability Engineer (SRE) verursachen können. 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 virtuelle Maschinenkontingente verfügbar sind, falls Steuerebenenknoten skaliert werden müssen, indem Sie mindestens das Doppelte Ihrer aktuellen Anzahl an Steuerebenenknoten vCPU vorhalten.

Betriebspersonal

  • 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.

Arbeitsauslastungsverwaltung

  • Fügen Sie keine Taints hinzu, die verhindern würden, dass OpenShift-Standardkomponenten geplant werden.
  • Um Unterbrechungen zu vermeiden, die von der Clusterwartung resultieren, sollten In-Cluster-Workloads mit methoden für hohe Verfügbarkeit konfiguriert werden. Zu diesen Methoden gehören, aber nicht beschränkt auf Pod-Affinität und Antiaffinität, Pod-Unterbrechungsbudgets und angemessene 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 Standardclusterdienst Alertmanager , den Standardempfänger oder alle Standardwarnungsregeln, mit Ausnahme von anderen Empfängern, die externe Systeme benachrichtigen.
  • Entfernen oder ändern Sie die Protokollierung im Azure Red Hat OpenShift-Dienst nicht (MDSD-Pods).

Netzwerk und Sicherheit

  • Sofern Sie ihre eigene Netzwerksicherheitsgruppe nicht über das Feature " Netzwerksicherheitsgruppe mitbringen" verwenden, kann die von Azure Red Hat OpenShift bereitgestellte Netzwerksicherheitsgruppe (Network Security Group, NSG) nicht geändert oder ersetzt werden. Jeder Versuch, die NSG 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). Das Proxying von HTTPS-Verkehr, das zum Ausführen des Azure Red Hat OpenShift-Dienstes erforderlich ist, wird nicht unterstützt. Siehe clusterweite Proxyanweisungen für die Proxykonfiguration.
  • Der Azure Red Hat OpenShift-Dienst greift auf Ihre Cluster über den Private Link-Dienst zu. Ändern oder entfernen Sie den Dienstzugriff nicht.

Clusterverwaltung

  • Ändern oder entfernen Sie den arosvc.azurecr.io Cluster-Pull-Secret nicht.
  • Erstellen Sie keine neuen MachineConfig Objekte, oder ändern Sie vorhandene 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 vorhandene Objekte, es sei denn, sie werden in der OpenShift-Dokumentation von Azure Red Hat 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.

Vorfallmanagement

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

Abhängig von der Auswirkung auf den Dienst und den Kunden wird der Vorfall im Hinblick auf den Schweregrad kategorisiert.

Der allgemeine Workflow der Verwaltung eines neuen Vorfalls wird wie folgt beschrieben:

  1. Ein SRE-First Responder wird auf einen neuen Incident aufmerksam gemacht und beginnt mit einer ersten Untersuchung.

  2. Nach der ersten Untersuchung wird der Vorfall einem Vorfallleiter zugewiesen, der die Wiederherstellungsbemühungen koordiniert.

  3. Der Incidentleiter verwaltet alle Kommunikation und Koordination rund um die Behebung, einschließlich relevanter Benachrichtigungen oder Supportfall-Updates.

  4. Wenn der Vorfall gelöst wird, wird eine kurze Zusammenfassung des Vorfalls und der Lösung im vom Kunden initiierten Supportticket bereitgestellt. Diese Zusammenfassung hilft dem Kunden, den Vorfall und seine Lösung ausführlicher zu verstehen.

Wenn zusätzlich zu dem, was im Supportticket bereitgestellt wird, weitere Informationen erforderlich sind:

  1. Der Kunde muss innerhalb von fünf Werktagen nach der Vorfallauflösung weitere Informationen anfordern.

  2. Je nach Schweregrad des Vorfalls kann dem Kunden im Supportticket eine Zusammenfassung zur Ursache oder eine Analyse der Ursachen (Root Cause Analysis, RCA) bereitgestellt werden. Die zusätzlichen Informationen werden innerhalb von sieben Werktagen nach der Vorfallauflösung für die Zusammenfassung der Ursache und innerhalb von 30 Werktagen nach der Vorfallauflösung für die Ursachenanalyse bereitgestellt.

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 Speicher: 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
Ddsv5 Standard_D8ds_v5 8 32
Ddsv5 Standard_D16ds_v5 16 64
Ddsv5 Standard_D32ds_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 Speicher: 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
Ddsv5 Standard_D4ds_v5 4 16
Ddsv5 Standard_D8ds_v5 8 32
Ddsv5 Standard_D16ds_v5 16 64
Ddsv5 Standard_D32ds_v5 32 128
Ddsv5 Standard_D48ds_v5 48 192
Ddsv5 Standard_D64ds_v5 64 256
Ddsv5 Standard_D96ds_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 Speicher: 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

Für Compute optimiert

Reihen Größe vCPU Speicher: 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 Speicher: GiB
Mms * Standard_M128ms 128 3.892

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

Speicheroptimiert

Reihen Größe vCPU Speicher: GiB
L4s Standard_L4s 4 32
L8s Standard_L8s 8 64
L16s Standard_L16s 16 128
L32s Standard_L32s 32 256
L8s_v2 Standard_L8s_v2 8 64
L16s_v2 Standard_L16s_v2 16 128
L32s_v2 Standard_L32s_v2 32 256
L48s_v2 Standard_L48s_v2 48 384
L64s_v2 Standard_L64s_v2 64 512
L8s_v3 Standard_L8s_v3 8 64
L16s_v3 Standard_L16s_v3 16 128
L32s_v3 Standard_L32s_v3 32 256
L48s_v3 Standard_L48s_v3 48 384
L64s_v3 Standard_L64s_v3 64 512

GPU-Workload

Reihen Größe vCPU Speicher: GiB
NC4asT4v3 Standard_NC4as_T4_v3 4 28
NC6sV3 Standard_NC6s_v3 6 112
NC8asT4v3 Standard_NC8as_T4_v3 8 56
NC12sV3 Standard_NC12s_v3 12 224
NC16asT4v3 Standard_NC16as_T4_v3 16 110
NC24sV3 Standard_NC24s_v3 24 448
NC24rsV3 Standard_NC24rs_v3 24 448
NC64asT4v3 Standard_NC64as_T4_v3 64 440
ND96asr_v4* Standard_ND96asr_v4 96 900
ND96amsr_A100_v4 * Standard_ND96amsr_A100_v4 96 1924
NC24ads_A100_v4 * Standard_NC24ads_A100_v4 24 220
NC48ads_A100_v4 * Standard_NC48ads_A100_v4 48 440
NC96ads_A100_v4 * Standard_NC96ads_A100_v4 96 880

* Nur Tag 2 (nicht als Option bei der Installation unterstützt)

Verwandte Inhalte

Weitere Informationen finden Sie unter Supportlebenszyklus für Azure Red Hat OpenShift 4.