Dienstdefinition für Azure Red Hat OpenShift
Die folgenden Abschnitte enthalten Dienstdefinitionen, um Sie bei der Verwaltung Ihres Azure Red Hat OpenShift-Kontos zu unterstützen.
Abrechnung
Azure Red Hat OpenShift-Cluster werden im Azure-Abonnement eines Kunden bereitgestellt. Ein Kunde bezahlt Azure direkt für Kosten, die durch einen Azure Red Hat OpenShift-Cluster entstehen.
Azure Red Hat OpenShift-Knoten werden in Azure Virtual Machines ausgeführt. Sie werden gemäß den Preisen für virtuelle Azure Linux-Computer abgerechnet. Compute-, Netzwerk- und Speicherressourcen, die von einem Azure Red Hat OpenShift-Cluster genutzt werden, werden basierend auf der Nutzung abgerechnet.
Neben den Compute- und Infrastrukturkosten fallen für Anwendungsknoten zusätzliche Kosten für die Azure Red Hat OpenShift-Lizenzkomponente an. Diese Kosten basieren auf der Anzahl von Anwendungsknoten und dem Instanztyp.
Es stehen alle standardmäßigen Azure-Kaufoptionen zur Verfügung – einschließlich Reservierungen und Azure-Vorauszahlung. Standardmäßige Azure-Kaufoptionen können für Azure Red Hat OpenShift verwendet werden. Darüber hinaus können standardmäßige Azure-Kaufoptionen für virtuelle Computer, Netzwerke und Speicherressourcen verwendet werden, die durch den Azure Red Hat OpenShift-Cluster verbraucht werden.
Weitere Informationen zu den Preisen finden Sie unter Azure Red Hat OpenShift – Preise.
Cluster-Self-Service
Kunden können ihre Cluster mithilfe des Azure-Befehlszeilenprogramms (CLI) erstellen und löschen. Azure Red Hat OpenShift-Cluster werden mit einem kubeadmin-Benutzer bereitgestellt, dessen Anmeldeinformationen nach erfolgreicher Clusterbereitstellung über die Azure CLI verfügbar sind.
Alle weiteren Azure Red Hat OpenShift-Clusteraktionen wie etwas das Skalieren von Knoten können über die OpenShift-API mithilfe von Tools wie der OpenShift-Webkonsole oder der OpenShift-Befehlszeilenschnittstelle (oc) ausgeführt werden.
Azure-Ressourcenarchitektur
Für eine Azure Red Hat OpenShift-Bereitstellung werden zwei Ressourcengruppen innerhalb eines Azure-Abonnements benötigt. Die erste Ressourcengruppe wird vom Kunden erstellt und enthält die virtuellen Netzwerkkomponenten für den Cluster. Dank der separaten Platzierung der Netzwerkelemente können Kunden Azure Red Hat OpenShift gemäß ihren Anforderungen konfigurieren sowie Peeringoptionen hinzufügen.
Die zweite Ressourcengruppe wird vom Azure Red Hat OpenShift-Ressourcenanbieter erstellt. Sie enthält Azure Red Hat OpenShift-Clusterkomponenten wie virtuelle Computer, Netzwerksicherheitsgruppen und Lastenausgleichsmodule. Die in dieser Ressourcengruppe enthaltenen Azure Red Hat OpenShift-Clusterkomponenten können vom Kunden nicht geändert werden. Die Clusterkonfiguration muss über die OpenShift-API mithilfe der OpenShift-Webkonsole oder -Befehlszeilenschnittstelle oder mithilfe ähnlicher Tools durchgeführt werden.
Hinweis
Der Dienstprinzipal für den ARO-Ressourcenanbieter erfordert die Rolle „Netzwerkmitwirkender“ im VNet des ARO-Clusters. Dies ist für den ARO-Ressourcenanbieter erforderlich, um Ressourcen wie den ARO Private Link-Dienst und Lastenausgleichsmodule zu erstellen.
Red Hat-Operatoren
Kunden sollten bei der Clustererstellung ein Red Hat-Pullgeheimnis für den Azure Red Hat OpenShift-Cluster bereitstellen. Das Red Hat-Pullgeheimnis ermöglicht Ihrem Cluster den Zugriff auf Red Hat-Containerregistrierungen und andere Inhalte aus dem OpenShift-Operator-Hub.
Azure Red Hat OpenShift-Cluster können Anwendungen zwar auch ohne das Red Hat-Pullgeheimnis bereitstellen, aber keine Operatoren aus dem Operator-Hub installieren.
Das Red Hat-Pullgeheimnis kann auch nach der Bereitstellung für den Cluster bereitgestellt werden.
Compute
Azure Red Hat OpenShift-Cluster werden mit drei oder mehr Workerknoten bereitgestellt.
In Regionen, die mehrere Verfügbarkeitszonen umfassen, wird in jeder Zone eine Workerknoten-Computergruppe erstellt. Außerdem wird ein Workerknoten aus jeder Computergruppe bereitgestellt.
Wenn eine Azure-Region keine Verfügbarkeitszonen unterstützt, werden die Workerknoten aus einer einzelnen Computergruppe bereitgestellt. Kunden haben die Möglichkeit, die Knotenanzahl und die Berechtigung in jeder Region zu erhöhen.
Azure Red Hat OpenShift-Cluster werden mit drei Knoten der Steuerungsebene bereitgestellt. Diese Knoten sind für den etcd-Schlüssel-Wert-Speicher und für API-bezogene Workloads zuständig. Knoten der Steuerungsebene können nicht für Kundenworkloads verwendet werden. Für die Bereitstellung von Knoten der Steuerungsebene gelten die gleichen Regeln wie für Workerknoten.
- In Regionen, die mehrere Verfügbarkeitszonen umfassen, wird in jeder Zone eine Computergruppe für den Knoten der Steuerungsebene erstellt. Aus jeder Computergruppe wird ein Knoten der Steuerungsebene bereitgestellt.
- Falls eine Azure-Region keine Verfügbarkeitszonen unterstützt, werden die Knoten auf Steuerungsebene aus einer einzelnen Computergruppe bereitgestellt.
Azure-Computetypen
Eine Liste der unterstützten Typen und Größen von Knoten der Steuerungsebene sowie von Workerknoten finden Sie unter Unterstützte VM-Größen.
Azure-Regionen
Informationen zu Regionen, die von Azure Red Hat OpenShift werden, finden Sie unter Verfügbare Produkte nach Region.
Führen Sie über die Azure CLI den folgenden Befehl aus, um eine Liste der verfügbaren Regionen anzuzeigen:
az provider show -n Microsoft.RedHatOpenShift --query "resourceTypes[?resourceType == 'OpenShiftClusters']".locations -o yaml
Ein bereitgestellter Azure Red Hat OpenShift-Cluster kann nicht in eine andere Region verschoben werden. Auch ist es nicht möglich, Azure Red Hat OpenShift-Cluster in ein anderes Abonnement zu verschieben.
Vereinbarung zum Servicelevel
SLA-Details finden Sie unter SLA für Azure Red Hat OpenShift.
Unterstützung
Supportanfragen für Azure Red Hat OpenShift können wie folgt übermittelt werden:
- Durch Anfordern von Support im Azure-Portal
- Durch Anfordern von Support über das Red Hat-Kundenportal
Anforderungen werden von Supporttechnikern von Microsoft und Red Hat geprüft und bearbeitet. Azure Red Hat OpenShift beinhaltet Red Hat-Premium-Support. Auf den Support kann über das Microsoft Azure-Portal zugegriffen werden.
Wenn Sie Supporttickets direkt für Red Hat erstellen möchten, muss Ihr Cluster über ein Pullgeheimnis verfügen. Dieses können Sie bei der Clustererstellung hinzufügen. Es kann aber auch in einem bereits vorhandenen Cluster hinzugefügt oder aktualisiert werden.
Logging
Die folgenden Abschnitte enthalten Informationen zur Sicherheit von Azure Red Hat OpenShift.
Clustervorgänge und Überwachungsprotokollierung
Azure Red Hat OpenShift wird mit Diensten zur Gewährleistung der Integrität und Leistung des Clusters und seiner Komponenten bereitgestellt. Diese Dienste enthalten Clustervorgänge und Überwachungsprotokolle. Clustervorgänge und Überwachungsprotokolle werden für den Support und die Problembehandlung automatisch an ein Azure-Aggregationssystem weitergeleitet. Auf diese Daten können nur autorisierte Supportmitarbeiter über genehmigte Mechanismen zugreifen.
Kundenclusteradministratoren können einen optionalen Protokollierungsstapel bereitstellen, um alle Protokolle aus ihrem Azure Red Hat OpenShift-Cluster zu aggregieren. Beispielsweise können Überwachungsprotokolle des Knotensystems sowie Infrastrukturprotokolle aggregiert werden. Durch diese Protokolle werden jedoch weitere Clusterressourcen verbraucht.
Anwendungsprotokollierung
Wenn der Zugriff auf OperatorHub.io aktiviert ist, enthält Azure Red Hat OpenShift einen optionalen Protokollierungsstapel, der auf Elasticsearch, Fluentd und Kibana (EFK) basiert.
Der Protokollierungsstapel (Logging Operator) kann so konfiguriert werden, dass er die Kundenanforderungen erfüllt. Es ist allerdings nicht für die langfristige Archivierung von Protokollen vorgesehen, sondern für eine kurzfristige Aufbewahrung konzipiert, um die Behandlung von Cluster- und Anwendungsproblemen zu unterstützen.
Wenn der Clusterprotokollierungsstapel installiert ist, werden an STDOUT gesendete Anwendungsprotokolle von Fluentd gesammelt. Die Anwendungsprotokolle werden über den Clusterprotokollierungsstapel verfügbar gemacht. Die Aufbewahrungsdauer ist zwar auf sieben Tage festgelegt, pro Shard gilt jedoch eine Obergrenze von 200 GiB an Protokollen. Für eine längerfristige Aufbewahrung sollten Kunden in ihren Bereitstellungen den Sidecar-Containerentwurf verwenden. Kunden sollten Protokolle an den Protokollaggregations- oder Analysedienst ihrer Wahl weiterleiten.
Überwachung
Der folgende Abschnitt enthält Informationen zur Überwachung von Azure Red Hat OpenShift.
Clustermetriken
Azure Red Hat OpenShift wird mit Diensten zur Gewährleistung der Integrität und Leistung des Clusters und seiner Komponenten bereitgestellt. Diese Dienste umfassen unter anderem das Streamen wichtiger Metriken an ein Azure-Aggregationssystem zu Support- und Problembehandlungszwecken. Auf diese Daten können nur autorisierte Supportmitarbeiter über genehmigte Mechanismen zugreifen.
Azure Red Hat OpenShift-Cluster verfügen über einen integrierten Prometheus-/Grafana-Stapel, damit Kunden sich die Clusterüberwachung ansehen können. Der Stapel enthält CPU-, arbeitsspeicher- und netzwerkbasierte Metriken.
Diese Metriken, auf die über die Webkonsole zugegriffen werden kann, können auch verwendet werden, um den Status auf Clusterebene sowie die Kapazität/Nutzung über ein Grafana-Dashboard anzuzeigen. Diese Metriken ermöglichen außerdem die automatische horizontale Skalierung von Pods auf der Grundlage von CPU- oder Arbeitsspeichermetriken, die von einem Azure Red Hat OpenShift-Kunden bereitgestellt werden.
Network
Die folgenden Abschnitte enthalten Informationen zum Netzwerk von Azure Red Hat OpenShift.
Domänengeprüfte Zertifikate
Azure Red Hat OpenShift enthält standardmäßig TLS-Sicherheitszertifikate, die sowohl für interne als auch für externe Dienste im Cluster erforderlich sind. Für externe Routen wird ein TLS-Platzhalterzertifikat (Transport Layer Security) bereitgestellt und im Cluster installiert. Ein TLS-Zertifikat wird auch für den OpenShift-API-Endpunkt verwendet. Für diese Zertifikate wird DigiCert als Zertifizierungsstelle (ZS) verwendet.
Benutzerdefinierte Domänen
Während der Bereitstellung ermöglicht Azure Red Hat OpenShift die Angabe einer benutzerdefinierten Domäne für Ihren Cluster. Die benutzerdefinierte Domäne wird sowohl für Clusterdienste als auch für Anwendungen verwendet. In Ihrem DNS-Server müssen zwei DNS-A-Einträge für die angegebene Domäne erstellt werden:
- api: Verweist auf die IP-Adresse des API-Servers.
- *.apps: Verweist auf die Eingangs-IP-Adresse.
Von Azure Red Hat OpenShift werden standardmäßig selbstsignierte Zertifikate für alle Routen verwendet, die für benutzerdefinierte Domänen erstellt werden. Wenn Sie benutzerdefinierte Domänen verwenden möchten, stellen Sie eine Verbindung mit dem Cluster her. Führen Sie als Nächstes die in der OpenShift-Dokumentation beschriebenen Schritte aus, um eine benutzerdefinierte Zertifizierungsstelle (ZS) für Ihren Eingangsdatencontroller sowie eine benutzerdefinierte ZS für Ihren API-Server zu konfigurieren.
Benutzerdefinierte Zertifizierungsstellen für Builds
Azure Red Hat OpenShift unterstützt die Verwendung von Zertifizierungsstellen, um von Builds beim Pullen von Images aus einer Imageregistrierung als vertrauenswürdig eingestuft werden zu können.
Load Balancer
Azure Red Hat OpenShift wird mit zwei Azure-Lastenausgleichsmodulen bereitgestellt. Das erste wird für bei Anwendungen eingehenden Datenverkehr sowie für die OpenShift- und Kubernetes-APIs verwendet. Das zweite wird für die interne Kommunikation zwischen Clusterkomponenten verwendet.
Eingehender Clusterdatenverkehr
Projektadministratoren können Routenanmerkungen für verschiedenste Zwecke hinzufügen – unter anderem zur Eingangssteuerung über eine Liste zugelassener IP-Adressen.
Eingangsrichtlinien können mithilfe von NetworkPolicy-Objekten geändert werden. Von diesen Objekten wird das Plug-In „ovs-networkpolicy“ verwendet. Die Verwendung von NetworkPolicy-Objekten ermöglicht die uneingeschränkte Steuerung der Netzwerkrichtlinie für eingehenden Datenverkehr bis hinab zur Podebene – auch zwischen Pods im gleichen Cluster und sogar im gleichen Namespace.
Der gesamte Clusterdatenverkehr durchläuft den definierten Lastenausgleich.
Ausgehender Clusterdatenverkehr
Die Steuerung des ausgehenden Datenverkehrs von Pods über EgressNetworkPolicy-Objekte kann verwendet werden, um ausgehenden Datenverkehr in Azure Red Hat OpenShift zu verhindern oder zu beschränken. Derzeit müssen alle virtuellen Computer über ausgehenden Internetzugriff verfügen.
Netzwerkkonfiguration für die Cloud
Azure Red Hat OpenShift ermöglicht die Konfiguration privater Netzwerkverbindungen über verschiedene von Cloudanbietern verwaltete Technologien:
- VNet-Verbindungen
- Azure-VNET-Peering
- Azure VNet Gateway
- Azure Express Route
Von Red Hat SRE wird keine Überwachung dieser privaten Netzwerkverbindungen bereitgestellt. Für die Überwachung dieser Verbindungen ist der Kunde zuständig.
Vom Kunden angegebenes DNS
Azure Red Hat OpenShift-Kunden können ihre eigenen DNS-Server angeben. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten DNS in einem ARO-Cluster (Azure Red Hat OpenShift).
Containernetzwerkschnittstelle
Azure Red Hat OpenShift verwendet OVN (Open Virtual Network) als Containernetzwerkschnittstelle (Container Network Interface, CNI). Das Ersetzen der CNI wird nicht unterstützt. Weitere Informationen finden Sie unter OVN-Kubernetes-Netzwerkanbietern für Azure Red Hat OpenShift-Cluster.
Storage
Die folgenden Abschnitte enthalten Informationen zum Speicher von Azure Red Hat OpenShift.
Verschlüsselung ruhender Daten
Azure Storage verwendet serverseitige Verschlüsselung (Server Side Encryption, SSE), um Ihre Daten beim Speichern in der Cloud automatisch zu verschlüsseln. Standardmäßig werden Daten mit von der Microsoft-Plattform verwalteten Schlüsseln verschlüsselt.
Blockspeicher (RWO)
Persistente Volumes basieren auf Azure-Datenträgerblockspeicher mit einmaligem Lese-/Schreibzugriff (Read-Write-Once, RWO). 1.024-GiB-Datenträger werden dynamisch erstellt und an die einzelnen Azure Red Hat OpenShift-Knoten der Steuerungsebene angefügt. Bei diesen Datenträgern handelt es sich um SSD Premium-LRS-Datenträger, die von Azure verwaltet werden. Datenträgergrößen für die standardmäßigen Workerknoten-Computergruppen können während der Clustererstellung konfiguriert werden.
Kunden verfügen über Berechtigungen zum Erstellen weiterer Computergruppen, um ihre Anforderungen besser zu erfüllen.
Persistente Volumes (PVs) können immer nur an einen einzelnen Knoten angefügt werden und sind spezifisch für die Verfügbarkeitszone, in der sie bereitgestellt wurden. Sie können an einen beliebigen Knoten in der Verfügbarkeitszone angefügt werden.
Die Anzahl von PVs vom Typ „Blockspeicher“, die an einen einzelnen Knoten angefügt werden können, wird durch Azure begrenzt. Azure-Grenzwerte hängen von Art und Größe des virtuellen Computers ab, den der Kunde für Workerknoten auswählt. Informationen zur maximalen Anzahl von Datenträgern für die Dasv4-Serie finden Sie beispielsweise unter Dasv4-Serie.
Freigegebener Speicher (RWX)
Freigegebener Speicher für Azure Red Hat OpenShift-Cluster muss vom Kunden konfiguriert werden. Ein Beispiel zum Konfigurieren einer Speicherklasse für Azure Files finden Sie unter Erstellen einer Azure Files Storage-Klasse in Azure Red Hat OpenShift 4.
Plattform
Die folgenden Abschnitte enthalten Informationen zur Plattform von Azure Red Hat OpenShift.
Clustersicherungsrichtlinie
Wichtig
Für Ihre Anwendungen und Anwendungsdaten muss unbedingt ein Sicherungsplan vorhanden sein.
Die Sicherung von Anwendungen und Anwendungsdaten ist kein automatisierter Bestandteil des Azure Red Hat OpenShift-Diensts. Ein Tutorial für eine manuelle Anwendungssicherung finden Sie unter Erstellen einer Sicherung einer Azure Red Hat OpenShift 4-Clusteranwendung.
DaemonSets
Kunden können DaemonSets in Azure Red Hat OpenShift erstellen und ausführen. Mit dem folgenden nodeSelector-Element können Sie die Ausführung von DaemonSets auf Workerknoten beschränken:
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
Version von Azure Red Hat OpenShift
Azure Red Hat OpenShift wird als Dienst ausgeführt. Dadurch verfügen Kunden immer über die neueste stabile OpenShift Container Platform-Version. Informationen zur Support- und Upgraderichtlinie finden Sie unter Supportlebenszyklus für Azure Red Hat OpenShift 4.
Supportlebenszyklus
Informationen zum Supportlebenszyklus von Azure Red Hat OpenShift finden Sie unter Supportlebenszyklus für Azure Red Hat OpenShift 4.
Containerengine
Azure Red Hat OpenShift wird unter OpenShift 4 ausgeführt und verwendet die CRI-O-Implementierung der Kubernetes-CRI (Container Runtime Interface) als einzige verfügbare Containerengine.
Betriebssystem
Azure Red Hat OpenShift wird unter OpenShift 4 ausgeführt und verwendet Red Hat Enterprise Linux CoreOS (RHCOS) als Betriebssystem für alle Knoten der Steuerungsebene sowie für alle Workerknoten. Windows-Workloads werden in Azure OpenShift nicht unterstützt, da die Plattform derzeit keine Windows-Workerknoten unterstützt.
Kubernetes-Operatorunterstützung
Azure Red Hat OpenShift unterstützt Operatoren, die von Red Hat und zertifizierten unabhängigen Softwareherstellern (Independent Software Vendors, ISVs) erstellt wurden. Für von Red Hat bereitgestellte Operatoren wird Support von Red Hat bereitgestellt. Für ISV-Operatoren wird Support vom jeweiligen ISV bereitgestellt.
Um OperatorHub verwenden zu können, muss Ihr Cluster mit einem Red Hat-Pullgeheimnis konfiguriert sein. Weitere Informationen zur Verwendung von OperatorHub finden Sie unter Grundlegendes zu OperatorHub.
Sicherheit
Die folgenden Abschnitte enthalten Informationen zur Sicherheit von Azure OpenShift.
Authentifizierungsanbieter
Azure Red Hat OpenShift-Cluster sind nicht mit Authentifizierungsanbietern konfiguriert.
Kundinnen und Kunden müssen eigene Anbieter konfigurieren, z. B. Microsoft Entra ID. Weitere Informationen zum Konfigurieren von Anbietern finden Sie in den folgenden Artikeln:
Compliance
Ausführliche Informationen zu Azure Red Hat OpenShift-Zertifizierungen im Zusammenhang mit der Einhaltung gesetzlicher Bestimmungen finden Sie unter Microsoft Azure-Complianceangebote.
Nächste Schritte
Weitere Informationen finden Sie in der Dokumentation zu Unterstützungsrichtlinien.