Cluster an der Edge
Die meisten der früheren Blogs in dieser laufenden Reihe zum Thema Edge Computing befassten sich mit Geräten.
Geräte aller Art – Audiogeräte, Videogeräte, IoT-Geräte und verschiedene Sensoren und Aktuatoren. In diesem Beitrag geht es um Container, die auf kleinen Edge-Clustern bereitgestellt werden, die als Edge-Knoten fungieren – ja, mit Kubernetes-Clustern auf Raspberry-Pi-Klasse-Maschinen oder in kleinen Formfaktoren wie dem Intel NUC mit genügend Rechenleistung und Speicher. Insbesondere Cluster, die eine Kubernetes-basiertenachgelagerte Verteilung wie K3S oder MicroK8S oder eine abgespeckte Red Hat OpenShift Container Platform (OCP) mit drei Knoten auf einem kleinen Cluster als Edge-Knoten an einem lokalen Standort ausführen, sind weit davon entfernt einem Rechenzentrum.
Rechenintensive Anwendungen erfordern eine hohe Rechenkapazität für die Datenverarbeitung und Speicherung, die IoT-Geräte nicht leisten können, da sie oft über begrenzte Ressourcen verfügen. Daher können Unternehmen Cluster am Edge als dynamische, robuste Umgebungen nutzen, in denen die Betriebsteams die Anforderungen an Speicher, Berechnungen, geringe Latenz, hohe Leistung und hohe Bandbreite erfüllen können. Außerdem erfordern einige hoch verfügbare gemeinsam genutzte Dienste lokal möglicherweise die Skalierbarkeit, für die Kubernetes-Cluster ausgelegt sind, z. B. Edge-Cloud-Bereitstellungen.
Ein Edge-Cluster kann oft eine logische Resourcing boundary für ein Unternehmen sein. Die Investitionen in die High-End-Edge-Geräte sind für Unternehmen außerdem teuer. Vermutlich wurden bereits zahlreiche Altlast-Geräte mit festen Funktionen oder dedizierte Geräte bereitgestellt und budgetiert. Die Edge-Cluster-Technologie bietet Unternehmen die Möglichkeit, ihre Anwendungen mit einem Edge-nativen Ansatz zu modernisieren und zukunftssicher zu machen. Dazu werden solche Geräte mit einem Edge-Cluster mit geringem Platzbedarf verbunden, auf dem eine Gerätemanagement- oder IoT-Plattformlösung ausgeführt wird. Der Edge-Cluster würde dann wie ein Edge-Gerät verwaltet und betrieben werden.
Cluster am Edge bieten die folgenden Hauptvorteile:
- Skalierbar: Bieten Sie Kunden die Möglichkeit, dem Cluster je nach Bedarf zusätzliche Kapazitäten hinzuzufügen. Es kann so eingerichtet werden, dass es automatisch skaliert wird, wodurch der Zeit- und Arbeitsaufwand des Betriebsteams reduziert wird.
- Verteilt: Schnellere Erkenntnisse und Maßnahmen, da ein größerer Teil der Daten vom Edge-Cluster verarbeitet und analysiert wird, wodurch die Kosten und der Zeitaufwand für das Senden von Daten in die Cloud vermieden werden.
- Konform: Die Verarbeitung von Daten im Edge-Cluster hilft auch bei der Einhaltung von Vorschriften, dem Datenspeicherort und der Datenisolierung.
- Sicher: Sichere Kommunikation zwischen allen im Cluster gehosteten App-Servern.
- Hohe Verfügbarkeit: Die Failback-Optionen auf dem Cluster und die Möglichkeit, bei Bedarf neue Knoten zu erstellen, um den reibungslosen Betrieb der Anwendung zu gewährleisten, erhöhen die Zuverlässigkeit.
Lassen Sie uns ein Beispiel aus dem Einzelhandel durchgehen. Ein Einzelhändler möchte ein bestimmtes Produkt aus dem Ladenregal nehmen oder es aufgrund eines Sicherheitsrückrufs anderweitig nicht mehr zum Kauf verfügbar machen. Sie müssten ihr zentrales Bestandssystem aktualisieren und diese Aktualisierung bereitstellen, damit sie in mehreren Filialen wirksam wird.
Ein Edge-Cluster im speichern, gepaart mit IoT-Geräten, Kameras und Sensoren, ist gut geeignet, um dieses Szenario zu unterstützen. Während das Bestandssystem des speichers die jeweilige SKU (Stock Keeping Unit) als zurückgezogen markiert, wird der Filialleiter ebenfalls benachrichtigt, die physischen Produkte aus den Regalen zu nehmen. Gleichzeitig wird das POS-System (Point of Sale) aktualisiert, um den Barcode des jeweiligen Produkts ungültig zu machen. Eine gut konzipierte Edge-Cluster-Lösung würde solch schnelle Maßnahmen in großem Maßstab ohne kostspielige Verzögerungen oder menschliche Fehler ermöglichen.
Abbildung 1 zeigt den Edge-Cluster, der in einem typischen Grid-Lay-Geschäft mit Sicherheits- und Inventarkameras, Point-of-Sale-Systemen (POS), einem Eingangssensor und Temperatursensoren in Gefriergeräten bereitgestellt wird:
Sehen wir uns ein weiteres Beispiel an, zunächst aus dem Transportsektor. Ein Frachtschiff, das nur eine begrenzte Anbindung an das Netz hat, trägt Hunderte von Kühlcontainern an sich. Kühlcontainer sind, einfach ausgedrückt, große Kühlschränke, die von Containerschiffen verschieben, um temperaturempfindliche Waren wie Fleisch, Gemüse und Arzneimittel zu verschieben, ohne zu verderben. Der Inhalt bestimmt die Temperatur, die in diesen Kühlschränken aufrechterhalten wird.
Die Kühlcontainer müssen nicht nur für eine stabile Temperatur im Inneren sorgen, sondern auch die Luftfeuchtigkeit kontrollieren und einen ausreichenden Luftstrom fördern. Die Überwachung und Verwaltung der Thermostaten, Lüfter und anderer wichtiger Komponenten des Kühlcontainers erfolgt am besten durch einen Edge-Cluster, selbst bei der begrenzten Konnektivität an Bord des Schiffes. Diese Konfiguration ermöglicht auch die Überwachung und Alarmierung auf dem Schiff, ohne dass eine Cloud-basierte Infrastruktur erforderlich ist. Wenn das Schiff einen Hafen erreicht, verbindet sich der Edge-Cluster wieder mit dem Edge-Hub am Schiffsdock oder in der Cloud. Die Verwaltung dieser Kühlcontainer und anderer Geräte in großem Maßstab und mit wenig bis gar keinem menschlichen Eingreifen ist nur über eine gut konzipierte Edge-Cluster-Lösung VIA® möglich.
Ein Edge-Cluster kann klein genug sein, um in ein verfügbares Regal auf engstem Raum zu passen – z. B. in ein Schnellrestaurant, einen Zug, einen Krankenwagen, einen Kiosk, Geschäfte, Lagerhäuser und Produktionshallen. Wir können für diese Umgebung relevante Workloads bereitstellen. Dies könnten Anwendungen zur Erkennung, Temperaturmessungen, Ticketing-Anwendungen, geschäftskritische Sprachdienste oder sogar AR/VR-Anwendungen sein.
Als repräsentatives Beispiel für eine bescheidene Kubernetes-Cluster-Installation für die oben genannten Szenarien finden Sie hier einige Details zur Implementierung mit K3s. Denken Sie daran, dass Sie auch ähnliche Kubernetes-Distributionen wie Minikube oder Microk8s verwenden können. Die folgende Liste zeigt einen einfachen Knoten mit 1 Master und 2 Worker K3s (https://k3s.io/) Cluster-Setup. Es werden die minimalen Befehle angezeigt, die auf jeder Komponente ausgeführt werden müssen. Die Topologie mit 3 Knoten ist in der folgenden Tabelle dargestellt:
K3S_URL ist die IP-Adresse des Masterknotens zusammen mit dem Port, wobei 6443 der HTTPS-Listen-Port ist. Beachten Sie, dass K3s standardmäßig containerd-Container und nicht Docker verwendet.
Master
$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/Token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd
Arbeiter 1
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"
Arbeiter 2
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585
Aus Sicht von IBM Edge Application Manager (IEAM) ähnelt ein Edge-Cluster einem Edge-Gerät, weil auf beiden ein Edge-Agent installiert ist. Abbildung 2 zeigt die allgemeinen Komponenten eines Edge-Clusters:
Edge-Cluster sind im Grunde Edge-Knoten, die Kubernetes-basierte Cluster sind. Was ist also der Grund für die Einrichtung eines kleinen Clusters als Edge-Knoten? Jeder Edge-Knoten – in diesem Fall der Edge-Cluster – wird bei der Börse unter dem Unternehmen des Edge-Cluster-Besitzers registriert. Die Registrierung besteht aus einer ID und einem Token, der nur für diesen Edge Cluster gilt. Ein autonomer Agentenprozess wird auf diesem Edge-Cluster ausgeführt und setzt die vom Eigentümer des Edge-Clusters festgelegten Richtlinien durch. Gleichzeitig werden autonome Vereinbarungs-Bots (oder Bots) Bereitstellungsrichtlinien zugewiesen, um Dienste in diesen Edge-Clustern bereitzustellen.
Die obigen Informationen beschreiben die Schritte in IBM Edge Application Manager, das die Bereitstellung von Edge-Services auf einem Edge-Cluster über einen Kubernetes-Operator ermöglicht und damit die gleichen autonomen Bereitstellungsmechanismen wie Edge-Geräte ermöglicht. Damit steht die volle Power® von Kubernetes als Container-Management-Plattform für Edge zur Verfügung.
Unter diesem Link im Product Knowledge Center werden die Schritte zum Installieren eines Edge-Agenten auf einem Edge-Cluster beschrieben. Danach können entsprechende Anwendungen auf diesem Edge-Cluster installiert werden. Wie Sie vielleicht schon erraten haben, unterstützt IEAM Kubernetes, K3s, MiniKube, Microk8s und Red Hat OpenShift.
In diesem Blog wurde der einzigartige geschäftliche Nutzen beschrieben, der durch die Bereitstellung von Clustern am Edge erzielt wird – nicht unbedingt am Remote Edge, aber dennoch Edge-Knoten an entfernten lokalen Standorten. Um zu wiederholen, Edge-Knoten-Clustering-Funktionen helfen Ihnen bei der Verwaltung und Bereitstellung von Workloads von einem Management-Hub-Cluster auf entfernten Instanzen von OCP oder anderen Kubernetes-basierten Clustern.
Ein Edge-Cluster ermöglicht Anwendungsfälle am Edge, die Colocation von Rechenleistung mit Geschäftsabläufen erfordern oder die mehr Skalierbarkeit, Verfügbarkeit und Rechenleistung erfordern, als dies von einem Edge-Gerät unterstützt werden kann. Darüber hinaus ist es nicht ungewöhnlich, dass Edge-Cluster Anwendungen bereitstellen, die zur Unterstützung von Services benötigt werden, die auf Edge-Geräten ausgeführt werden, da sie sich in unmittelbarer Nähe zu diesen Geräten befinden.
Es gibt ein neueres Open-Source-Container-Management-Tool für die Entwicklung, Verwaltung und Ausführung von OCI-Containern (Open Container Initiative). Podman (kurz für Pod Manager) genannt, ist eine Option, die sich gut für Edge-Cluster eignet. Podman wird als Teil der libpod-Bibliothek bereitgestellt und kann zum Erstellen und Verwalten von Containern verwendet werden. Es kann zwar Docker-Container ausführen, läuft aber derzeit nur auf Linux-basierten Betriebssystemen. Hier erfahren Sie mehr über Podman.
Das IBM Cloud Architecture Center bietet viele Hybrid- und Multicloud-Referenzarchitekturen.
Sie können auch die neu veröffentlichte, auf Edge bezogene Automobilreferenzarchitektur einsehen.
Besonderer Dank geht an Joe Pearson und David Booz für die Durchsicht des Artikels.
Bitte schauen Sie sich auch die weiteren Folgen dieser Reihe von Blogbeiträgen zum Thema Edge Computing an:
- Teil 3: „Architektur an der Edge“
- Teil 4: „DevOps an der Edge“
- Teil 7: „Sicherheit an der Edge“
- Teil 8: „Analyse an der Edge“
- Teil 9: „5G an der Edge“
- Teil 10: „Cluster an der Edge“
- Teil 11: „Automatisierung an der Edge“
- Teil 12: „Netzwerk-Slicing an der Edge“
- Teil 13: „Daten an der Edge“
- Teil 14: „Architektonische Entscheidungen an der Edge“
- Teil 15: „GitOps amn der Edge“
- Teil 17: „Speicherdienste an der Edge“
- Teil 18: „Cloud-Services an der Edge“
- Teil 20: „Datensouveränität an der Edge“
- Teil 22: „Vernetzte Produkte an der Edge“
- Teil 23: „Foundation Models an der Edge“