Red Hat OpenShift am Edge: Zero-Touch-Provisionierung

Die Informationstechnologie durchläuft eine bemerkenswerte Entwicklung, wobei sich die Deployment- und Wartungsszenarien täglich ändern. Immer mehr Daten und Geräte am Edge müssen verarbeitet und verwaltet werden. Daher müssen die Technologien angepasst werden, um die Einführung solcher Strategien zu unterstützen und zu fördern.

Red Hat OpenShift kann Anforderungen abdecken, die vom Management einer infrastrukturunabhängigen Anwendungsplattform bis hin zum Deployment On-Premise oder in der Cloud reichen – ob Private, Public oder Hybrid Cloud.

Die Fähigkeit, sich an die verschiedenen Szenarien anzupassen, hat sich jedoch im Laufe der Zeit enorm weiterentwickelt. Schlankere Konfigurationen, wie der kompakte 3-Node-Deployment-Modus oder die Single-Node-Konfiguration, ermöglichen dieselbe Flexibilität und Performance, allerdings mit geringerem Platzbedarf. 

Dank dieser Flexibilität passt sich OpenShift an Deployments in Szenarien mit reduzierter Rechenkapazität und Hardware-Nutzungsbeschränkungen wie Remote-Standorte an, unabhängig davon, ob es sich um Zweigstellen oder einzelne Computing- und Verarbeitungsstandorte handelt.

Angenommen, wir haben eine Vielzahl dieser Edge-Standorte und müssen sie mit einer Technologie erreichen, die für eine zentralisierte Computing-Kapazität und Verwaltung unserer Workloads sorgt. Wir sind in der Lage, Konfigurationen und Einstellungen zu replizieren und zu propagieren, die mit vordefinierten Richtlinien und standortbezogenen Szenarien konform und vor allem kurzfristig verfügbar sind. So reduzieren wir die Komplexität und verbessern die Reproduzierbarkeit und Zuverlässigkeit.

Dieser Use Case kann dank der Flexibilität des Assisted Installers von OpenShift und der Vielseitigkeit und Einfachheit des zentralisierten Cluster- und Infrastrukturmanagements von Red Hat Advanced Cluster Management for Kubernetes mit Zero-Touch-Provisionierung (ZTP) abgedeckt werden.

Zero-Touch-Provisionierung ist, wie der Name schon sagt, ein Modus der Provisionierung von OpenShift-Clustern auf Bare Metal. Mit dieser Art der Provisionierung können wir je nach den Anforderungen von Remote-Standorten mehrere Cluster-Setup-Varianten erstellen, ohne physisch mit unseren Geräten zu interagieren. Um dies zu erreichen, müssen die gewünschten Konfigurationen für unsere Cluster auf bestimmten Ressourcen deklariert werden. Die verschiedenen Komponenten von Red Hat Advanced Cluster Management haben dann die Aufgabe, diese in Provisionierungsvorgänge zu übersetzen – und zwar sowohl für die Infrastrukturknoten über eine Verbindung mit dem Baseboard Management Controller (BMC) als auch für die Cluster durch Nutzung der OpenShift Assisted Installer-Funktionen.

Da die definierten Ressourcen eigenständig sind, können sie in einem Git Repository gespeichert und mit dem OpenShift GitOps Operator (basierend auf ArgoCD) angewendet werden, wobei unsere Standorte und Cluster wie normale Anwendungen definiert werden.

Nachfolgend finden Sie ein Diagramm mit einigen Use Cases, in dem zu sehen ist, dass dieser Modus der Provisionierung nur einen Cluster umfasst, der als Hub innerhalb des zentralen Rechenzentrums fungiert.

Die Funktionen, die wir heute besprechen, befinden sich derzeit in der Technologievorschau. Wir können jedoch nachvollziehen, wie wir optimierte Konfigurationen in großem Umfang erstellen und bereitstellen können.

Use Case: Single-Node OpenShift am Edge mit ZTP

Schauen wir uns nun die einzelnen Teile unseres Puzzles an und wie wir sie alle zu einem vollständigen Bild zusammensetzen können.

Folgende Hauptkomponenten von Red Hat Advanced Cluster Management sind am Prozess beteiligt:

• OpenShift Bare Metal Operator
• Assisted Installer
• Multi-Cluster-Engine – Hive Operator

Da wir gleich auf Probleme im Zusammenhang mit Edge-Geräten eingehen, beziehen wir uns im Folgenden auf Bare Metal. Hier sind bereits Einrichtungsmodi basierend auf der vom Nutzenden bereitgestellten Infrastruktur und Installationen in der vom Installationsprogramm bereitgestellten Infrastruktur verfügbar. Diese werden wir in den verschiedenen Phasen des Deployments nutzen.

Ein Remote-Gerät ist mit einem Standort verknüpft. Dieser entspricht der Definition der grundlegenden Parameter, die während der Konfigurationsphase berücksichtigt werden müssen. Daraus ergibt sich eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD), die als „SiteConfig“ bezeichnet wird.

In der CRD ist Folgendes definiert:

• Details zum BMC, den wir zum Verwalten unserer Nodes verwenden
• Details zu den Clustern (Cluster-Name, Domain)
• Netzwerkkonfigurationen (Subnetz für Pods, Services, Maschinen)
• Node-Konfigurationen (Netzwerkeinstellungen, Partitionierung, ggf. erforderliche Härtung über Richtlinien)

Diese Informationen werden verwaltet und in Unterressourcen umgewandelt, die von den verschiedenen Komponenten verwaltet werden, um die verschiedenen Phasen des Deployments zu orchestrieren.

Zur Vereinfachung gestaltet sich der logische Ablauf von ZTP wie folgt:

Im Folgenden werden die verschiedenen genannten Ressourcen und ihre Rolle im Detail erläutert.

BareMetalHost

BareMetalHost (BMH) verarbeitet Informationen vom BMC, die dann vom OpenShift Bare Metal Operator interpretiert werden, um den Bare Metal Node in OpenShift zu erstellen und den Remote Node vorzubereiten und zu konfigurieren. Dies ist das Herzstück der Node-Provisionierung, da der Operator die Boot-Geräte remote konfigurieren kann, die auf das Setup zugeschnitten sind, das wir durchführen möchten.

InfraEnv

InfraEnv definiert Details zum Netzwerk, die NTP-Server, die auf den zu hostenden Nodes verwendet werden, den SSH-Schlüssel (Secure Shell), der für den Zugriff auf die angeschlossenen Nodes verwendet wird, und die Anmeldeinformationen für den Zugriff auf die für die Installation erforderlichen Container Images. Zusammen mit der ClusterDeployment-Ressource wird sie zum Erstellen der Discovery-ISO für den Assisted Installer verwendet.

AgentClusterInstall

Enthält die Informationen, die vom Assisted Installer verwendet werden, um das Boot-Image zu generieren, das von unseren Nodes verwendet wird, um die Installation und Konfiguration des Clusters fortzusetzen, einschließlich Version, Name und Netzwerkkonfigurationen.

ClusterDeployment

Kombiniert die in AgentClusterInstall definierten Informationen und fügt weitere Informationen hinzu, die für das ordnungsgemäße Deployment des Clusters erforderlich sind und in die Boot-ISO für den Node eingebettet werden.

ManagedCluster und KlusterletAddonConfig

Mit diesen Ressourcen sind Nutzende von Red Hat Advanced Cluster Management möglicherweise bereits vertraut. Sie definieren Informationen über den Cluster, damit er in Red Hat Advanced Cluster Management Hub importiert und verwaltet werden kann, und konfigurieren die für die Kommunikation erforderlichen Services.

Sobald der Provisionierungsprozess und die Cluster-Einrichtung über den OpenShift Installer abgeschlossen sind, wird das neue Single-Node OpenShift im Hub als installiert und angedockt angezeigt, sodass es für das Deployment unserer Workloads verwendet werden kann.

Zusammenfassung

In diesem Artikel wurde das Konzept von ZTP für OpenShift in Edge-Szenarien eingeführt und erläutert, wie der Plattform-Provisionierungsprozess mithilfe eines Infrastructure as Code-Ansatzes (IaC) einfacher, wiederholbarer und skalierbarer gestaltet werden kann.

Die Technologie wird kontinuierlich weiterentwickelt und ist mittlerweile so ausgereift, dass Sie mit dieser innovativen Methode experimentieren können, um eine vollständige Anwendungsplattform in viele verschiedene Szenarien zu integrieren.