Viele Unternehmen entscheiden sich für Red Hat OpenShift als gemeinsame Plattform für die Entwicklung und Ausführung ihrer Anwendungen. Auf diese Weise vermeiden sie eine heterogene Umgebung, die zu viel Komplexität führen kann. Sie nutzen Red Hat OpenShift nicht nur, um neue cloudnative Anwendungen zu entwickeln und auszuführen, sondern können auch ihre Legacy-Anwendungen zu dieser Plattform migrieren.

Ein wichtiger Vorteil von OpenShift besteht darin, dass Entwicklungsteams sich nur mit einer Oberfläche auskennen müssen, während die zugrunde liegenden Details der Plattform abstrahiert werden. Dies kann zu erheblichen Produktivitätssteigerungen führen.

Red Hat OpenShift Service on AWS (ROSA)

Einige Kunden, die sich für die Einführung von OpenShift entscheiden, möchten das Management ihrer Umgebung weiter vereinfachen. Sie ziehen es vor, sich nicht mehr über die Bereitstellung der Infrastruktur für ihre Cluster und deren Verwaltung kümmern zu müssen. Sie möchten, dass ihre Teams vom ersten Tag an produktiv sind und sich ausschließlich auf die Anwendungsentwicklung konzentrieren. Eine Möglichkeit, diese Ziele zu erreichen, ist der Einsatz von Red Hat OpenShift Service on AWS (ROSA).

ROSA wird vollständig in der Public Cloud von Amazon Web Services (AWS) gehostet. Der Service wird gemeinsam von Red Hat und AWS gewartet, das heißt, dass Control Plane und Rechenknoten vollständig von einem Red Hat Team aus Site Reliability Engineers (SREs) gemanagt werden – mit gemeinsamem Support von Red Hat und Amazon. Dazu gehören Installation, Management, Wartung und Upgrades für alle Knoten.

Deployment-Optionen für ROSA

ROSA kann grundsätzlich auf 2 Arten bereitgestellt werden: in einem öffentlichen Cluster und in einem PrivateLink-Cluster. In beiden Fällen empfehlen wir das Deployment in mehreren Verfügbarkeitszonen, um für Resilienz und Hochverfügbarkeit zu sorgen. 

Öffentliche Cluster werden hauptsächlich für Workloads ohne strenge Sicherheitsanforderungen verwendet. Der Cluster wird in einer Virtual Private Cloud (VPC) in einem privaten Subnetz bereitgestellt (das die Control Plane-Knoten, die Infrastrukturknoten und die Workerknoten enthält, auf denen die Anwendungen ausgeführt werden). Ein Zugriff über das Internet ist allerdings weiterhin möglich. Daher wird zusätzlich zur VPC ein öffentliches Subnetz benötigt. 

Über AWS Load Balancer (Elastic und Network Load Balancer), die in diesem öffentlichen Subnetz bereitgestellt werden, können das SRE-Team und die Nutzenden, die auf die Anwendungen zugreifen (d. h. Ingress-Datenverkehr zum Cluster), eine Verbindung herstellen. Bei Nutzenden leitet ein Load Balancer den Datenverkehr an den Router-Service um, der auf den Infrastrukturknoten ausgeführt wird. Von dort aus wird er an die gewünschte Anwendung weitergeleitet, die auf einem der Workerknoten ausgeführt wird. Das SRE-Team verwendet ein dediziertes AWS-Konto, um über verschiedene Load Balancer eine Verbindung zu den Kontroll- und Infrastrukturknoten herzustellen. 

Figure 1. ROSA public cluster

Abbildung 1. Öffentlicher ROSA-Cluster

Für Produktions-Workloads mit höheren Sicherheitsanforderungen empfehlen wir das Deployment eines PrivateLink-Clusters. In diesem Fall wird in der VPC, in der sich der Cluster befindet, nur ein privates Subnetz bereitgestellt, d. h. ein Zugriff über das öffentliche Internet ist überhaupt nicht möglich. 

Das SRE-Team verwendet ein dediziertes AWS-Konto, das über einen AWS PrivateLink-Endpunkt eine Verbindung zu einem AWS Load Balancer herstellt. Der Load Balancer leitet den Datenverkehr nach Bedarf zu den Kontroll- oder Infrastrukturknoten um. (Nachdem der AWS PrivateLink erstellt wurde, muss der Kunde den Zugriff über das AWS-Konto des SRE-Teams genehmigen.) Die Nutzenden stellen eine Verbindung zu einem AWS Load Balancer her, der sie zum Router-Service auf den Infrastrukturknoten umleitet. Von dort aus werden sie zum Workerknoten geleitet, auf dem die Anwendung ausgeführt wird, auf die sie zugreifen möchten.

Bei PrivateLink-Cluster-Implementierungen kommt es häufig vor, dass Kunden den Egress-Datenverkehr des Clusters an ihre On-Premise-Infrastruktur oder an andere VPCs in AWS Cloud umleiten möchten. Dazu können sie ein AWS Transit Gateway oder AWS Direct Connect verwenden, sodass in der VPC, in der sich der Cluster befindet, kein öffentliches Subnetz bereitgestellt werden muss. Selbst wenn der Egress-Datenverkehr ins Internet geleitet werden muss, können sie (über das AWS Transit Gateway) eine Verbindung zu einer VPC herstellen, die über ein öffentliches Subnetz mit einem AWS NAT-Gateway und einem AWS Internet-Gateway verfügt.

Figure 2. ROSA private cluster with PrivateLink

Abbildung 2. Privater ROSA-Cluster mit PrivateLink

Sowohl bei öffentlichen als auch bei PrivateLink-Implementierungen kann der Cluster mit anderen AWS-Services interagieren. Dabei kann die VPC, in der sich der Cluster befindet, über AWS VPC-Endpunkte mit den gewünschten Services kommunizieren.

Herstellung einer Verbindung zum Cluster

Für das SRE-Team wird die Verwendung des AWS Security Token Service (STS) empfohlen, um sich bei den ROSA-Clustern anzumelden und Administrationsaufgaben auszuführen. Dabei sollte das Least Privilege-Prinzip angewendet werden, damit nur die Rollen zugewiesen werden, die zum Ausführen einer Aufgabe unbedingt erforderlich sind. Das Token ist temporär und wird nur einmal verwendet. Wenn nach Ablauf des Tokens eine ähnliche Aufgabe erneut auszuführen ist, muss demnach ein neues Token angefordert werden.

STS kann auch verwendet werden, um den ROSA-Cluster mit anderen AWS-Services zu verbinden, darunter EC2 (wenn z. B. neue Server für den Cluster hochgefahren werden müssen) oder EBS (wenn persistenter Storage benötigt wird).

Zusammenfassung

Die Einführung von DevOps-Methoden und die Modernisierung der Anwendungsbereitstellung mithilfe einer Kubernetes-Plattform für Unternehmen wie OpenShift lässt sich auf alle Arten von Kunden anwenden. Sie können die Lösung lokal hosten und selbst verwalten. Wenn sie das nicht möchten, ist ROSA eine mögliche Option. Mithilfe der zahlreichen AWS-Services, die mit ROSA-Clustern interagieren können, können Kunden ihre Plattform optimal nutzen.

Mehr erfahren


About the author

Ricardo Garcia Cavero joined Red Hat in October 2019 as a Senior Architect focused on SAP. In this role, he developed solutions with Red Hat's portfolio to help customers in their SAP journey. Cavero now works for as a Principal Portfolio Architect for the Portfolio Architecture team. 

Read full bio