ROSA Architektur - Red Hat OpenShift Service in AWS
Vergleich von ROSA mit HCP und ROSA Classic

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

ROSA Architektur

Red Hat OpenShift Service in AWS (ROSA) hat die folgenden Cluster-Topologien:

  • Gehostete Steuerungsebene (HCP) — Die Kontrollebene wird bei Red Hat gehostet AWS-Konto und von Red Hat verwaltet. Worker-Knoten werden beim Kunden eingesetzt. AWS-Konto

  • Klassisch — Die Steuerungsebene und die Worker-Knoten werden beim Kunden bereitgestellt AWS-Konto.

ROSA mit HCP bietet eine effizientere Architektur der Steuerungsebene, die dazu beiträgt, die beim Betrieb anfallenden AWS Infrastrukturgebühren zu reduzieren ROSA und die Clustererstellung zu beschleunigen. Sowohl ROSA mit HCP als auch ROSA Classic können in der AWS ROSA Konsole aktiviert werden. Sie haben die Wahl, welche Architektur Sie verwenden möchten, wenn Sie ROSA Cluster mithilfe der ROSA CLI bereitstellen.

Anmerkung

ROSA mit Hosted Control Planes (HCP) bietet keine FedRAMP High- und HIPAA-Qualified-Compliance-Zertifizierungen an. Weitere Informationen finden Sie unter Compliance in der Red Hat-Dokumentation.

Anmerkung

ROSA mit Hosted Control Planes (HCP) bietet keine FIPS-Endpunkte (Federal Information Processing Standard).

Vergleich von ROSA mit HCP und ROSA Classic

In der folgenden Tabelle wird ROSA mit den klassischen Architekturmodellen HCP und ROSA verglichen.

ROSA mit HCP ROSA klassisch

Hosting der Cluster-Infrastruktur

Komponenten der Steuerungsebene wie etcd, API-Server und OAuth werden in einem Unternehmen von Red Hat gehostet. AWS-Konto

Komponenten der Steuerungsebene, wie etcd, API-Server und OAuth, werden in einem kundeneigenen Unternehmen gehostet. AWS-Konto

Amazon VPC

Worker-Knoten kommunizieren mit der Steuerungsebene über. AWS PrivateLink

Worker Nodes und Control Plane Nodes werden in der VPC des Kunden bereitgestellt.

AWS Identity and Access Management

Verwendet AWS verwaltete Richtlinien.

Verwendet vom Kunden verwaltete Richtlinien, die vom Service definiert werden.

Bereitstellung in mehreren Zonen

Die Steuerungsebene wird in mehreren Availability Zones (AZs) eingesetzt.

Die Kontrollebene kann innerhalb einer einzelnen AZ oder in mehreren AZ bereitgestellt werden AZs.

Infrastrukturknoten

Verwendet keine dedizierten Infrastrukturknoten. Plattformkomponenten werden auf Worker-Knoten bereitgestellt.

Verwendet zwei dedizierte Single-AZ- oder drei Multi-AZ-Knoten zum Hosten von Plattformkomponenten.

OpenShift Fähigkeiten

Plattformüberwachung, Image-Registrierung und der Ingress-Controller werden in den Worker-Knoten bereitgestellt.

Plattformüberwachung, Image-Registrierung und der Ingress-Controller werden in speziellen Infrastrukturknoten bereitgestellt.

Cluster-Upgrades

Die Steuerungsebene und jeder Maschinenpool können separat aktualisiert werden.

Der gesamte Cluster muss gleichzeitig aktualisiert werden.

Minimaler Amazon EC2 Platzbedarf

Zwei Amazon EC2 Instanzen sind erforderlich, um einen Cluster zu erstellen.

Sieben Single-AZ- oder neun Amazon EC2 Multi-AZ-Instances sind erforderlich, um einen Cluster zu erstellen.

AWS-Regionen

Informationen zur AWS-Region Verfügbarkeit finden Sie unter Red Hat OpenShift Service in AWS Endpunkte und Kontingente im AWS Allgemeinen Referenzhandbuch.

Informationen zur AWS-Region Verfügbarkeit finden Sie unter Red Hat OpenShift Service in AWS Endpunkte und Kontingente im AWS Allgemeinen Referenzhandbuch.