Bearbeiten

Freigeben über


Häufig gestellte Fragen zu Azure Red Hat OpenShift

Dieser Artikel beantwortet häufig gestellte Fragen zu Microsoft Azure Red Hat OpenShift.

Installation und Upgrade

Wo finde ich Informationen zu Preisen und Vereinbarungen zum Servicelevel?

Informationen zu den Preisen finden Sie unter Azure Red Hat OpenShift-Preise.

Informationen zu Vereinbarung zum Servicelevel (SLA) finden Sie unter Vereinbarung zum Servicelevel für Onlinedienste.

Welche Azure-Regionen werden unterstützt?

Eine Liste der unterstützten Regionen für Azure Red Hat OpenShift 4.x finden Sie unter Verfügbare Regionen.

Welche Größen von virtuellen Computern kann ich verwenden?

Eine Liste der unterstützten Größen virtueller Computer für Azure Red Hat OpenShift 4 finden Sie unter Unterstützte Ressourcen für Azure Red Hat OpenShift 4.

Was ist die maximale Anzahl von Pods in einem Azure Red Hat OpenShift-Cluster? Was ist die maximale Anzahl von Pods pro Knoten in Azure Red Hat OpenShift?

Die tatsächliche Anzahl der unterstützten Pods hängt von den Arbeitsspeicher-, CPU- und Speicheranforderungen einer Anwendung ab.

Azure Red Hat OpenShift 4.x hat ein Limit von 250 Pods pro Knoten und ist auf 250 Computeknoten begrenzt. Durch diese Grenzwerte wird die maximale Anzahl der in einem Cluster unterstützten Pods auf 250 × 250 = 62.500 begrenzt. Diese Grenzwerte sind mit denen für Cluster identisch, die mit benutzerdefiniertem Routing (User Defined Routing, UDR) erstellt wurden und mit Version 4.11 oder höher ausgeführt werden.

Kann ein Cluster Computeknoten über mehrere Azure-Regionen hinweg besitzen?

Nein Alle Knoten in einem Azure Red Hat OpenShift-Cluster müssen aus derselben Azure-Region stammen.

Kann ein Cluster über mehrere Verfügbarkeitszonen hinweg bereitgestellt werden?

Ja. Ein Cluster kann automatisch über mehrere Verfügbarkeitszonen hinweg bereitgestellt werden, wenn Ihr Cluster in einer Azure-Region bereitgestellt wird, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Verfügbarkeitszonen.

Werden Knoten der Steuerungsebene abstrahiert, weil sie zu Azure Kubernetes Service (AKS) gehören?

Nein Alle Ressourcen, einschließlich der Clusterknoten der Steuerungsebene, werden in Ihrem Kundenabonnement ausgeführt. Diese Typen von Ressourcen werden in einer „Nur-Lesen“-Ressourcengruppe platziert.

Befindet sich der Cluster in einem Kundenabonnement?

Die verwaltete Azure-Anwendung befindet sich in einer gesperrten Ressourcengruppe im Kundenabonnement. Kunden können Objekte in dieser Ressourcengruppe anzeigen, aber nicht ändern.

Gibt es ein Element in Azure Red Hat OpenShift, das mit anderen Kunden gemeinsam genutzt wird? Oder ist alles unabhängig?

Jeder Azure Red Hat OpenShift-Cluster ist einem bestimmten Kunden zugeordnet und befindet sich im Abonnement des Kunden.

Sind Infrastrukturknoten verfügbar?

Ja, mit ARO können Sie Infrastrukturcomputersätze erstellen, auf denen nur Infrastrukturkomponenten wie der Standard-Router, die integrierte Containerregistrierung und die Komponenten für Cluster-Metriken und -Überwachung laufen. Weitere Informationen finden Sie unter Bereitstellen von Infrastrukturknoten in einem ARO-Cluster.

Wie gehe ich mit Clusterupgrades um?

Informationen zu Upgrades, Wartung und unterstützten Versionen finden Sie unter Unterstützung des Lebenszyklus für Azure Red Hat OpenShift 4.

Wie werden Hostbetriebssystem und OpenShift-Software aktualisiert?

Die Hostbetriebssysteme und die OpenShift-Software werden aktualisiert, wenn Azure Red Hat OpenShift Nebenreleaseversionen und Patches von der OpenShift-Upstreamcontainerplattform anwendet.

Wie sieht der Prozess für einen Neustart des aktualisierten Knotens aus?

Knoten werden im Rahmen eines Upgrades neu gestartet.

Clustervorgänge

Kann ich Prometheus zum Überwachen meiner Anwendungen verwenden?

Prometheus ist vorinstalliert und für Azure Red Hat OpenShift 4.x-Cluster konfiguriert. Erfahren Sie mehr über die Clusterüberwachung.

Kann ich Prometheus zum Überwachen von Metriken zur Clusterintegrität und -kapazität verwenden?

In Azure Red Hat OpenShift 4.x: Ja.

Können Protokolle von zugrunde liegenden virtuellen Computern an ein Protokollanalysesystem eines Kunden gestreamt werden?

Protokolle von zugrundeliegenden virtuellen Computern werden vom verwalteten Dienst verarbeitet und für Kunden nicht verfügbar gemacht.

Wie kann ein Kunde Zugriff auf Metriken wie CPU/Arbeitsspeicher auf Knotenebene erhalten, um Aktionen wie Skalieren, Debuggen von Problemen usw. auszuführen? Ich kann „kubectl top“ anscheinend nicht auf einem Azure Red Hat OpenShift-Cluster ausführen.

Für Azure Red Hat OpenShift 4.x-Cluster enthält die OpenShift-Webkonsole alle Metriken auf Knotenebene. Weitere Informationen finden Sie in der Red Hat-Dokumentation unter Anzeigen von Clusterinformationen.

Wie werden, wenn die Bereitstellung hochskaliert wird, Azure-Fehlerdomänen in der Pod-Platzierung zugeordnet, damit sichergestellt ist, dass nicht alle Pods für einen Dienst durch einen Fehler in einer einzelnen Fehlerdomäne lahmgelegt werden?

Es gibt standardmäßig fünf Fehlerdomänen, bei der Verwendung von VM-Skalierungsgruppen in Azure. Jede Instanz eines virtuellen Computers in einer Skalierungsgruppe wird in einer dieser Fehlerdomänen platziert. Dadurch ist sichergestellt, dass Anwendungen, die auf den Computeknoten in einem Cluster bereitgestellt werden, in separaten Fehlerdomänen platziert werden.

Weitere Informationen hierzu finden Sie unter Auswählen der richtigen Anzahl von Fehlerdomänen für VM-Skalierungsgruppen.

Gibt es eine Möglichkeit, die Pod-Platzierung zu verwalten?

Wenn Kunden die Rolle „customer-admin“ zugewiesen wurde, können sie Knoten abrufen und sich Bezeichnungen ansehen. Dies bietet eine Möglichkeit, einen beliebigen virtuellen Computer in der Skalierungsgruppe als Ziel festzulegen.

Die Verwendung bestimmter Bezeichnungen muss sehr vorsichtig erfolgen:

  • Der Hostname darf nicht verwendet werden. Der Hostname wird häufig mit Upgrades und Updates ausgetauscht und wird garantiert geändert.
  • Wenn der Kunde bestimmte Bezeichnungen oder eine Bereitstellungsstrategie benötigt, ließe sich dies erreichen. Es wäre jedoch technischer Aufwand erforderlich, und dieser Ansatz wird derzeit nicht unterstützt.

Weitere Informationen finden Sie unter Steuern der Pod-Platzierung.

Ist die Imageregistrierung extern verfügbar, damit ich Tools wie Jenkins verwenden kann?

Für 4.x-Cluster müssen Sie eine sichere Registrierung verfügbar machen und die Authentifizierung konfigurieren. Weitere Informationen finden Sie in der Red Hat-Dokumentation zu den folgenden Themen:

Kann ich meinen Cluster zwischen Azure-Mandanten verschieben/migrieren?

Das Verschieben Ihres ARO-Clusters zwischen Mandanten wird derzeit nicht unterstützt.

Kann ich meine ARO-Cluster aus dem aktuellen Azure-Abonnement in ein anderes verschieben?

Das Verschieben Ihres ARO-Clusters und der zugehörigen Ressourcen zwischen Abonnements wird nicht unterstützt.

Kann ich meine ARO-Cluster oder ARO-Infrastrukturressourcen in andere Ressourcengruppen verschieben oder sie umbenennen?

Das Verschieben oder Umbenennen Ihres ARO-Clusters und der zugehörigen Ressourcen wird nicht unterstützt.

Netzwerk

Kann ich einen Cluster in einem vorhandenen virtuellen Netzwerk bereitstellen?

In Clustern der Version 4.x können Sie einen Cluster in einem vorhandenen virtuellen Netzwerk bereitstellen.

Wird namespaceübergreifender Netzwerkdatenverkehr unterstützt?

Kunden- und einzelne Projektadministratoren können namespaceübergreifenden Netzwerkdatenverkehr pro Projekt mithilfe von NetworkPolicy-Objekten anpassen (einschließlich seiner Untersagung).

Ich versuche, über Peering eine Verbindung mit einem virtuellen Netzwerk in einem anderen Abonnement herzustellen, erhalte jedoch den Fehler „Fehler beim Abrufen des VNet-CDIRs“.

Stellen Sie in dem Abonnement mit dem virtuellen Netzwerk sicher, dass der Microsoft.ContainerService-Anbieter mit folgendem Befehl registriert wird: az provider register -n Microsoft.ContainerService --wait

Können IP-Adressbereiche für die Bereitstellung im privaten VNet angegeben werden, um Konflikte mit anderen Unternehmens-VNets zu vermeiden, nachdem Peering erfolgt ist?

In Clustern der Version 4.x können Sie Ihre eigenen IP-Adressbereiche angeben.

Ist das softwaredefinierte Netzwerkmodul konfigurierbar?

Das softwaredefinierte Netzwerk ist openshift-ovs-networkpolicy und nicht konfigurierbar.

Welcher Azure Load Balancer wird von Azure Red Hat OpenShift verwendet? Ist es die Standard- oder Basic-Variante, und ist diese konfigurierbar?

Azure Red Hat OpenShift verwendet die Standardvariante von Azure Load Balancer, und diese ist nicht konfigurierbar.

Berechtigungen

Kann ein Administrator Benutzer und Kontingente verwalten?

Ja. Ein Azure Red Hat OpenShift-Administrator kann zusätzlich zum Zugriff auf alle von Benutzern erstellte Projekte Benutzer und Kontingente verwalten.

Kann ich einen Cluster nur auf bestimmte Microsoft Entra-Benutzer*innen beschränken?

Ja. Sie können einschränken, welche Microsoft Entra-Benutzer*innen sich bei einem Cluster anmelden können, indem Sie die Microsoft Entra-Anwendung konfigurieren. Ausführliche Informationen finden Sie unter So beschränken Sie Ihre App auf eine Gruppe von Benutzer*innen.

Kann ich das Erstellen von Projekten durch Benutzer einschränken?

Ja. Melden Sie sich bei Ihrem Cluster als Administrator an, und führen Sie den folgenden Befehl aus:

oc adm policy \
    remove-cluster-role-from-group self-provisioner \
    system:authenticated:oauth

Weitere Informationen finden Sie in der OpenShift-Dokumentation unter dem Thema zum Deaktivieren der eigenständigen Bereitstellung für Ihre Clusterversion:

Welche UNIX-Rechte (in IaaS) sind für Master/Infra/App-Knoten verfügbar?

Der Knotenzugriff ist über die Clusteradministratorrolle verfügbar. Weitere Informationen finden Sie in der Übersicht über Kubernetes RBAC.

Welche OCP-Rechte haben wir? Clusteradministrator? Projektadministrator?

Die Clusteradministratorrolle ist verfügbar. Weitere Informationen finden Sie in der Übersicht über Kubernetes RBAC.

Welche Identitätsanbieter sind verfügbar?

Sie konfigurieren Ihren eigenen Identitätsanbieter. Weitere Informationen finden Sie in der Red Hat-Dokumentation zum Thema Konfigurieren von Identitätsanbietern.

Storage

Werden Daten in meinem Cluster verschlüsselt?

Standardmäßig werden ruhende Daten verschlüsselt. Die Azure Storage-Plattform verschlüsselt Ihre Daten automatisch vor dem dauerhaften Ablegen und entschlüsselt sie vor dem Abrufen. Weitere Informationen finden Sie unter Azure-Speicherdienstverschlüsselung für ruhende Daten.

Wie werden meine Speicherkonten gesichert?

Storage-Konten sind nur auf privaten Zugriff festgelegt.

Storage-Konten werden verschlüsselt (nur neue Cluster). Vorhandene Cluster müssen neu erstellt werden.

Storage-Konten werden mit „Allgemein v2“ für neue Cluster erstellt.

Speicherkonten vom Typ „Allgemein v2“ unterstützen die neuesten Azure Storage-Features und umfassen die gesamte Funktionalität von Konten des Typs „Allgemein v1“ und von Blob-Speicherkonten.

Der Zugriff auf Storage-Konten ist durch Firewallregeln über Azure-Netzwerksicherheitsgruppen (NSGs) beschränkt, die den Netzwerkdatenverkehr zu und von Ihren Speicherkonten filtern. Weitere Informationen finden Sie unter Überblick über Azure-Netzwerksicherheitsgruppen.

Das TLS-Protokoll (Transport Layer Security) Version 1.2 bietet sichere Kommunikation, Datenschutz und Datenintegrität.

Werden in etcd gespeicherte Daten unter Azure Red Hat OpenShift verschlüsselt?

Daten werden standardmäßig nicht verschlüsselt, aber Sie haben die Möglichkeit, die Verschlüsselung zu aktivieren. Weitere Informationen finden Sie im Leitfaden zum Verschlüsseln von etcd.

Können wir eine permanente Speicherlösung auswählen, z. B. OCS?

Azure Disk (Premium_LRS) ist als Standardspeicherklasse konfiguriert. Weitere Speicheranbieter und Einzelheiten zur Konfiguration (einschließlich Azure Files) finden Sie in der Red Hat-Dokumentation zum permanenten Speicher.

Speichert ARO Kundendaten außerhalb der Region des Clusters?

Nein Alle in einem ARO-Cluster erstellten Daten verbleiben innerhalb der Region des Clusters.