Ressourcen und Zeit sparen beim Starten dutzender OpenShift-Cluster

Jeder, der Kubernetes oder OpenShift in der Produktion eingesetzt hat, kennt diesen Schmerz. Sie möchten einen kleinen isolierten Cluster für Staging oder ein separates Team aufsetzen, aber mindestens drei Nodes für Master-Nodes mit etcd und Controllern bereitzustellen, ist überdimensioniert. Wenn Sie zehn, dreißig oder hundert Cluster benötigen, schießen die Cloud-Rechnungen schnell in die Höhe, und die Zeit für die Erstellung einer weiteren Umgebung dehnt sich auf Dutzende von Minuten aus.

Red Hat-Entwickler stießen auf dasselbe Problem und veröffentlichten eine Lösung als Open Source. Das Projekt heißt HyperShift (oder Hosted Control Planes). Im Wesentlichen handelt es sich um eine Schicht, die die Steuerungsebene des Clusters von separaten Nodes in reguläre Pods innerhalb eines zentralen Management-Clusters verschiebt.

Lassen Sie uns untersuchen, wie dies funktioniert und wer davon profitiert.

Der Kern der architektonischen Ausrichtung

In einer klassischen OpenShift- oder Kubernetes-Konfiguration verfügt jeder Cluster über eigene dedizierte virtuelle oder physische Maschinen für den API-Server, etcd, Controller und Scheduler. Sie zahlen für diese Nodes, auch wenn der Cluster größtenteils im Leerlauf ist.

HyperShift trennt die Steuerungsebene von den Worker-Nodes.

Sie haben einen großen Management-Cluster. Wenn Sie einen neuen OpenShift-Cluster für Benutzer oder Entwicklungsteams erstellen müssen, stellt HyperShift die Management-Komponenten des neuen Clusters — etcd, kube-apiserver, openshift-apiserver — als Standard-Pods (Deployment und StatefulSet) direkt im Management-Cluster bereit.

Worker-Nodes werden derweil separat dort erstellt, wo Sie sie benötigen: in AWS, Azure oder auf Bare Metal. Sie verbinden sich mit dem als Pod laufenden API-Server in der Management-Infrastruktur.

Warum den vertrauten Ansatz ändern

Wenn Sie mehrere Cluster verwalten, werden die Vorteile in drei Bereichen sofort deutlich.

Erstens — Kosteneffizienz. Anstatt mindestens drei VMs für Master-Nodes für jeden einzelnen Cluster zu kaufen, nutzen Sie die Ressourcen eines bestehenden Management-Clusters. Dutzende Steuerungsebenen laufen auf einem einzigen Ressourcen-Pool, was eine viel dichtere Packung ermöglicht.

Zweitens — Geschwindigkeit der Infrastrukturbereitstellung. Das Bootstrapping eines vollständigen Nodes mit Betriebssystem, etcd-Konfiguration und Komponenteninitialisierung dauert 15 bis 45 Minuten. Steuerungsebenen-Pods in HyperShift starten in Minuten oder sogar Sekunden. Dies verändert den Ansatz für Dev/Test-Umgebungen grundlegend: Ein Cluster wird zu einer temporären Ressource, die leicht für eine Aufgabe erstellt und schnell gelöscht werden kann.

Drittens — Trennung von Verantwortlichkeiten und Sicherheit. Entwickler und Anwendungen erhalten nur Zugriff auf ihre Worker-Nodes und den API-Server. Sie haben keinen physischen oder Netzwerkzugang zu den Maschinen, auf denen die Steuerungsebene oder etcd läuft. Das Operations-Team aktualisiert und überwacht alle API-Server zentral an einem Ort.

Wie es in der Praxis aussieht

HyperShift maintains 100% compatibility with the standard Kubernetes API and OpenShift Container Platform (OCP) tools. From a developer or CI/CD pipeline perspective, the created cluster is indistinguishable from a regular one: you get a standard kubeconfig and work through kubectl or oc.

Das Management erfolgt über das CLI-Tool hypershift oder über Custom Resources (CRD), was perfekt in GitOps-Ansätze wie ArgoCD passt.

Hier ist ein Beispiel, wie das Erstellen eines Clusters in AWS über die CLI aussieht:

hypershift create cluster aws \
  --name dev-cluster \
  --node-pool-replicas 2 \
  --base-domain example.com \
  --pull-secret /path/to/pull-secret.json \
  --aws-creds /path/to/aws-credentials

Im Hintergrund erstellt der Befehl die CRD HostedCluster und NodePool. HyperShift startet Steuerungsebenen-Pods im Management-Cluster, stellt ein Paar EC2-Instanzen in AWS für Worker-Nodes bereit und verknüpft sie miteinander.

Unter der Haube und Feinheiten

Das Projekt ist in Go geschrieben und wird aktiv vom OpenShift-Team weiterentwickelt. Das Repository hat bereits über 500 Forks, obwohl die Sterne noch relativ wenige sind — knapp über fünfhundert. Das liegt daran, dass HyperShift lange Zeit eine interne Red Hat-Technologie für den ROSA-Service (Red Hat OpenShift Service on AWS) war und nun schrittweise zum Standard für On-Premises- und Multi-Cloud-Installationen wird.

Wichtige Funktionen umfassen:

• Vollständige Isolation zwischen dem Management-Cluster und Client-Workloads.
• Unterstützung für die Bereitstellung von Worker-Nodes über verschiedene Anbieter: AWS, Azure, KubeVirt, Bare Metal.
• Einheitlicher Aktualisierungsvektor. Die Aktualisierung der OpenShift-Version für die Steuerungsebene kann unabhängig durch Ändern der Version in der CRD erfolgen, ohne alle Worker-Nodes sofort neu zu starten.

Gibt es Fallstricke? Natürlich. Der Management-Cluster wird zum Single Point of Failure für die Steuerungsebenen aller Ihrer Client-Cluster. Wenn der Management-Cluster ausfällt, funktionieren die auf Worker-Nodes laufenden Services weiter, aber die Verwaltbarkeit geht verloren, bis die Infrastruktur wiederhergestellt ist. Daher gelten erhöhte Anforderungen an die Zuverlässigkeit des Management-Clusters und an etcd-Backups.

Für wen es sich lohnt einen Blick zu werfen

HyperShift ist nicht notwendig, wenn Sie einen einzelnen monolithischen Cluster für das gesamte Unternehmen haben. Aber es wird zum Lebensretter, wenn:

• Sie eine Plattform für interne Teams aufbauen und isolierte Cluster bei Bedarf bereitstellen möchten.
• Sie eine SaaS-Lösung basierend auf Kubernetes mit physischer Trennung von Clients verkaufen.
• Sie es leid sind, für ungenutzte Master-Nodes in Public Clouds zu zahlen.

Sie können das Projekt anhand der offiziellen Dokumentation unter hypershift.pages.dev ausprobieren. Sie benötigen einen bestehenden OpenShift 4.x-Cluster als Management-Cluster und Zugriff auf AWS oder lokale VMs für die Erstellung von Workern.