Cloud-Computing

Kubernetes und Edge-Computing – Teil 1: Rechenleistung vor Ort nutzen

Die leistungsfähige Container-Orchestrierungsplattform Kubernetes im Bereich Edge-Computing einzusetzen klingt vielleicht auf den ersten Blick nach einer abgefahrenen Idee. Wozu soll das gut sein? Ein tieferer Blick offenbart die Sinnhaftigkeit sowie einen spannenden Bereich mit vielen Möglichkeiten. Der erste Teil gibt eine Einführung und geht vor allem auf Kubernetes selbst ein, der zweite Teil stellt eine Reihe weiterer Technologien im Kubernetes-Umfeld vor.

Ludwig Mittermeier

Author

Harald Müller

Author

25.09.2020
Lesezeit: 16 Minuten
22 Views

Kubernetes

Kubernetes [Ku] hat seinen Ursprung bei Google, also im Cloud-Computing-Umfeld. Es wurde dafür entwickelt, viele Microservices auf einer großen Anzahl von Servern zu betreiben. Dies schließt insbesondere die folgenden Aspekte mit ein:

Auswahl eines geeigneten Servers für jeden Microservice, zum Beispiel basierend auf der aktuellen Auslastung,
Überwachen der Microservices und gegebenenfalls Neustart beziehungsweise Umzug auf einen anderen Server,
Verwalten und Bereitstellen von Konfigurationsparametern wie Datenbankverbindungen und Sicherheitseinstellungen,
Bereitstellen einer leistungsfähigen Netzwerkinfrastruktur für die Microservices.

Im Jahr 2015 wurde Kubernetes in der Version 1.0 von Google veröffentlicht und an die Linux Foundation übergeben. Die Firmen Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, IBM, Docker, Univa und VMware gründeten in diesem Zug die unter dem Dach der Linux Foundation stehende Cloud Native Computing Foundation (CNCF), die sich seitdem um die Weiterentwicklung von Kubernetes kümmert. Es ist eines der aktivsten Projekte auf GitHub und es werden regelmäßig vier Releases pro Jahr veröffentlicht.

Bemerkenswert ist, dass es nicht nur „das eine“ Kubernetes gibt, sondern eine ziemlich große Zahl an Kubernetes-Distributionen und Service-Angeboten. Alle großen Cloud-Anbieter haben mittlerweile „Kubernetes-as-a-Service“ im Angebot. Wie zu erwarten unterscheiden sich diese Distributionen und Service-Angebote hinsichtlich Funktionalität und Betriebseigenschaften. Zum Glück stellt jedoch ein Zertifizierungsprogramm der CNCF die Interoperabilität sicher, und so verhalten sich aus Sicht eines Entwicklers zertifizierte Kubernetes-Distributionen und Service-Angebote im Kern gleich.

Mittlerweile hat sich Kubernetes zum Quasi-Standard für Container-Orchestrierung entwickelt und weite Verbreitung in Public-und Private-Cloud-Umgebungen gefunden. Kubernetes hat also seinen Ursprung im Cloud-Bereich und sich dort auf breiter Basis etabliert.

Bevor wir uns anschauen, warum es auch für den Edge-Computing-Bereich interessant ist, ein kurzer Einschub zur Motivation für Edge-Computing sowie verschiedene Arten davon.

Motivation für Edge-Computing

Jeder von uns trägt mindestens ein Smartphone mit einer Leistungsfähigkeit (CPU, Speicher, Netzwerkverbindungen) mit sich, die vor wenigen Jahren noch einem sehr gut ausgestatteten Desktop-Rechner oder einer Workstation entsprochen hätte. Diese Zunahme von Rechenleistung vor Ort ist ein allgemeiner Trend, der nicht nur im Endkonsumenten-Bereich zu beobachten ist, sondern auch bei industriellen Anwendungen, wie zum Beispiel in den Bereichen Industrieautomatisierung, Gebäudemanagement, Verkehrsinfrastruktur, Netzwerk- und Mobilfunkinfrastruktur sowie Energienetze.

In all diesen Bereichen sind zunehmend vor Ort Geräte wie beispielsweise Embedded Control Units, Industrie-PCs oder industrielle Steuerungen verbaut, die mehr Rechen- und Speicherkapazität bereitstellen, als für die Erfüllung ihrer ursprünglichen Kernaufgaben unbedingt nötig ist. Dies stellt quasi eine Sogwirkung dar. Wenn die Rechenleistung schon vor Ort verfügbar ist, kann man sie schließlich auch nutzen.

Auf der anderen Seite gibt es auch eine Druckwirkung: Sowohl technische als auch rechtliche Gründe führen dazu, dass häufig nicht wie vor einigen Jahren noch der erste Impuls ist: „Ab damit in die Cloud“. Man denke zum Beispiel an eine Industrie-Automatisierungsanlage, bei der mittels der Auswertung von Kamerabildern das Resultat eines Fräsvorgangs kontrolliert werden soll. Sollte die Analyse des Bildes ergeben, dass nicht korrekt gefräst wurde, so soll das Werkstück sofort aussortiert werden. Diese Überwachung muss natürlich hinreichend zuverlässig und schnell erfolgen, um den Produktionsablauf nicht zu stören.

Würden die Kamerabilder in eine Public-Cloud-Umgebung übertragen, so stünden dort zweifelsfrei genügend Rechen- und Speicherkapazität zur Verfügung, um mit den ausgefeiltesten (Machine Learning) Algorithmen die Kamerabilder zu begutachten. Jedoch würde der ganze Produktionsprozess ins Stocken kommen, wenn einmal eine Unterbrechung der Netzwerkverbindung von der Fabrik in die Public Cloud auftreten würde. Bandbreite und Latenz müssen jederzeit gut genug sein, um mit dem Takt der Industrieanlage Schritt zu halten. Es ist schwierig bis unmöglich, dies zuverlässig und konstant über einen längeren Zeitraum zu garantieren.

Manche Applikationen wie beispielsweise Bewegungssteuerung von Maschinen erfordern Echtzeitbedingungen und extrem kurze Latenzen, eine Auslagerung dieser kritischen Teile in die Public Cloud ist gänzlich unmöglich. Zudem ist die Qualität von Netzwerken in verschiedenen Ländern sehr unterschiedlich. Abgesehen davon gibt es noch die rechtlichen Aspekte. Man könnte zu folgender Einschätzung kommen: „Wir wollen nicht, dass solche Bilder in eine Public-Cloud-Umgebung übertragen werden, Verschlüsselung hin oder her. Jemand könnte ja Menge und Qualität unserer Produktion überwachen“. Darüber hinaus gibt es auch rechtliche Beschränkungen beispielsweise bezüglich des Orts der Verarbeitung und Speicherung von persönlichen Daten, was besonders im medizinischen Bereich relevant ist.

Diese technischen und rechtlichen Gründe stellen also die Druckwirkung dar, die dazu führt, dass solche Rechenaufgaben vor Ort erledigt werden müssen anstatt in einer Public-Cloud-Umgebung.

Betrachtet man die eben angesprochenen „Rechenaufgaben“ näher, so gilt es natürlich, den allgemeinen Trend hin zu containerisierten Microservices zu berücksichtigen. Eine „Rechenaufgabe“ kann also aus mehreren Microservices bestehen und es gibt mehrere mögliche Deployment-Varianten:

Alle Microservices einer „Rechenaufgabe“ sollen in der Cloud laufen.
Alle Microservices einer „Rechenaufgabe“ sollen im Edge (vor Ort) laufen.
Manche Microservices einer „Rechenaufgabe“ sollen in der Cloud laufen, der Rest im Edge.

Besonders die letzte Variante ist spannend. Hier ist es äußerst vorteilhaft, wenn die zur Verfügung stehenden Rechenkapazitäten als ein einheitlich zu nutzender Pool betrachtet werden. Manche davon laufen eben in der Cloud, manche davon in der Edge, was jeweils bestimmte Vor- und Nachteile mit sich bringt. Die Herausforderung besteht nun darin, eine geeignete Verteilung der containerisierten Microservices in solchen kombinierten Cloud-Edge-Umgebungen zu realisieren. Und da Kubernetes die derzeit leistungsfähigste Container-Orchestrierungsplattform ist, liegt es nahe, Kubernetes für solche Einsatzzwecke zu verwenden oder für eine solche Verwendung zu erweitern.

Arten von Edge-Computing

Beim Thema Edge-Computing gibt es sehr verschiedene Vorstellungen davon, was Edge überhaupt ist. Der Begriff Edge bezieht sich darauf, dass sich diese Geräte am Rande beziehungsweise an der Grenze des Netzwerks befinden. In der Arbeitsgruppe LF Edge der Linux Foundation [LF-Edge] wurde im Rahmen des sogenannten Open Glossary of Edge Computing [GLO] eine der bisher fundiertesten Definitionen erarbeitet. Man unterscheidet dort zwischen Infrastructure Edge und Device Edge. Auch wenn diese Definition eher aus der Sicht der Telekommunikationsanbieter erfolgt, ist sie sehr hilfreich.

Unter Device Edge versteht man Geräte, die sich im Besitz und Einflussbereich des Kunden befinden, das umfasst sowohl Privatkunden als auch Unternehmen. Im Device Edge kann es sehr wohl eine sehr große Anzahl von Edge-Geräten geben, und diese können räumlich verteilt sein, zum Beispiel über Haushalte, Fabriken, Kunden, Länder, Kontinente. Die Geräte der Device Edge können sehr unterschiedlich sein, von größeren Servern oder gar Serververbunden über (industrielle) PCs bis hin zu Embedded Devices mit eingeschränkten Rechen- und Speicherressourcen. Eine Gemeinsamkeit der Geräte in der Device Edge ist, dass diese vor Ort sind, oder neudeutsch On-Premises.

Im Industriebereich unterscheidet man noch eine weitere Ebene, die sogenannte Feldebene. Hier tummeln sich, meist in einem abgeschotteten und speziell abgesicherten Bereich, die Feldgeräte, die die direkte Verbindung mit der physikalischen Welt herstellen – beispielsweise mit Maschinen in einer Fabrik. Hier werden häufig spezielle Industrienetze und Kommunikationsprotokolle verwendet, die den Sicherheits- und Echtzeitanforderungen in diesem Bereich gerecht werden. Mit dem Fortschreiten von Industrial IoT halten aber auch in dieser Domäne mehr und mehr IT-Technologien Einzug.

Im Gegensatz zum Device Edge bezeichnet Infrastructure Edge den Rand des Netzwerks aus Sicht des Telekommunikationsbetreibers. Dies beinhaltet Komponenten auf der Netzseite, beispielsweise DSL- oder 3G/4G/5G-Zugangspunkte. Dazu können noch Cloud-artige Erweiterungen der Telekommunikationsanbieter kommen, sogenannte Edge Clouds. Diese können Cloud-Dienste, Inhalte und Netzwerkfunktionen anbieten und sind im Vergleich zu Public Clouds unter relativ niedrigen Latenzzeiten zu erreichen.

Cloud-Edge-Kontinuum

Bisher war von Edge und Cloud die Rede, ohne auf Mischformen zu achten. Natürlich gibt es wie so oft in der Welt nicht nur schwarz und weiß, sondern auch einen fein schattierten Graubereich dazwischen. Bereits Edge-Geräte können auf verschiedenen Leistungsstufen angesiedelt sein. Dann kann es nahe den Edge-Geräten Rechenknoten verschiedener Größe und Leistungskapazitäten geben. Je nach Domäne haben diese unterschiedliche Bezeichnungen, wie beispielsweise Industrie-PC oder Appliance. Als Nächstes kann es vor Ort oder in der Nähe eine Private Cloud geben, bevor man ganz am Ende des Spektrums in der Public Cloud angelangt ist. Aus diesem Grund ist mittlerweile meist von einem sogenannten Cloud-Edge-Kontinuum die Rede. Betrachtet man die oben beschriebenen Deployment-Varianten von verteilten Anwendungen, dann wird klar, dass ein besonderer Vorteil daraus entsteht, das gesamte Cloud-Edge-Kontinuum mit möglichst einheitlichen Verfahren und Werkzeugen abdecken zu können.

Container in kombinierten Cloud-Edge-Umgebungen

Es ist also sinnvoll und wichtig, Container in kombinierten Cloud-Umgebungen zu verteilen und dies mit einer leistungsfähigen Container-Verwaltungsplattform zu tun. Was sind aber eigentlich die Herausforderungen in Bezug auf Container und Microservices in solchen Umgebungen? Die Wesentlichen sind Folgende:

Die Edge-Geräte befinden sich typischerweise hinter einem Proxy oder einer Firewall und haben keine öffentlich erreichbare IP-Adresse.
Die Netzwerkverbindung von Edge-Geräten kann ungenügend (geringe Bandbreite) und zeitweise unterbrochen sein.
Die Kommunikation zwischen Cloud- und Edge-Geräten bedingt üblicherweise hohe Latenzen, das ist insbesondere für industrielle Anwendungen oftmals eine Hürde.
Unter Umständen hat man es mit verschiedenen Prozessor-Typen zu tun, zum Beispiel x86 in der Cloud und ARM bei den Edge-Geräten.
Edge-Geräte sind im Gegensatz zu virtuellen Maschinen in der Cloud nicht alle gleich. Nur an bestimmte ist zum Beispiel ein spezieller Sensor oder Aktor angeschlossen.

Als Nächstes wollen wir uns nun anschauen, welche Möglichkeiten Kubernetes selbst bietet, um Container in kombinierten Cloud-Edge-Umgebungen zu verwalten, und wie diese Möglichkeiten mit den eben erwähnten Herausforderungen umgehen können.

Kubernetes-Konzepte: Node Federation und Cluster Federation

Die Knoten eines Kubernetes-Clusters befinden sich typischerweise an einem Ort – sei es eine Region eines Public-Cloud-Anbieters oder ein traditionelles Rechenzentrum. Es gibt jedoch auch Ausnahmen. Ein Beispiel: Um die Verfügbarkeit zu erhöhen, verteilt man gerne die Knoten eines Kubernetes-Clusters über mehrere Regionen eines Public-Cloud-Anbieters. Aufgrund schneller Netzwerkverbindungen zwischen den Regionen und flexibel konfigurierbarer Netzwerke ist das kein größeres Problem und man kann auf diese Art und Weise Kubernetes-Cluster bauen, die sich über mehrere Länder oder sogar Kontinente erstrecken. Dieses Konstrukt nennt man Kubernetes Node Federation. Es handelt sich also hier um einen einzigen Kubernetes-Cluster, bestehend aus einem API-Server und einem Scheduler, die sich um alle Knoten des Clusters kümmern (Anmerkung: Wahlweise können die zentralen Komponenten eines Kubernetes-Clusters redundant ausgelegt werden, es handelt sich aber trotzdem um einen einzigen Cluster).

Ein anderes Konzept nennt sich Cluster Federation. Hier hat man es nicht mit einem einzigen Kubernetes-Cluster zu tun, sondern mit mehreren. Man stelle sich im einfachsten Fall zwei Umgebungen oder Regionen R1 und R2 bei unterschiedlichen Cloud-Umgebungen vor. In beiden Umgebungen läuft jeweils ein eigenständiger Kubernetes-Cluster A und B. Durch die Anwendung des Föderierungskonzepts werden die beiden Cluster quasi miteinander verbunden, sie können als einziger Cluster angesehen und behandelt werden. Dazu wird auf Cluster A eine sogenannte Federation Control Plane installiert und Cluster B wird mit dieser verbunden. Durch das Deployment einer Applikation in diesem föderierten Cluster landen die Pods letztendlich auf den Worker Nodes der Cluster A und B. Dabei kann entweder Kubernetes die Wahl gelassen werden, welche Worker Nodes welchen Clusters für ein Deployment zum Einsatz kommen oder alternativ kann mit den bekannten Kubernetes-Bordmitteln Einfluss darauf genommen werden.

Dabei sind Cluster A und B vollwertige Kubernetes-Cluster inkl. API-Server und Scheduler, die auch weiterhin separat voll funktionsfähig bleiben. Insbesondere kann man Applikationen direkt auf A oder B deployen, indem man die jeweiligen API-Aufrufe auf ihre API-Server macht. Das Deployment über die Federation Control Plane ist also optional beziehungsweise eine zusätzliche Möglichkeit. Selbstverständlich können nicht nur zwei, sondern mehrere Cluster in einer Föderation zusammengefasst werden.

Die Kubernetes Community arbeitet schon seit einiger Zeit am Thema Cluster Federation und man ist immer noch nicht am Ziel. Beim ersten Ansatz (v1) war das Konzept so, dass im Cluster A der Cluster B mittels eines virtuellen Kubelets als ein Worker Node abgebildet war.

Der Scheduler von Cluster A hatte also keinen Einblick, dass sich dahinter ein kompletter Cluster verbirgt, und war daher in seinen Scheduling-Entscheidungen sehr eingeschränkt. Man deklarierte Kubernetes Cluster Federation v1 als Sackgasse, verfolgte diesen Weg nicht weiter und die Special Interest Group (SIG) Multicluster begann, ein neues Konzept für Kubernetes Cluster Federation zu definieren und zu implementieren. Es trägt den Namen KubeFed [Fed] und erlaubt im Wesentlichen die Koordination der Konfiguration mehrerer Cluster mithilfe einer Programmierschnittstelle (API) in einem sogenannten Hosting Cluster. Die Programmierschnittstelle ist sehr generisch gehalten und erlaubt die Definition von Ressourcen sowie deren Abbildung beziehungsweise Anwendung in verschiedenen Clustern. Dies ermöglicht zum Beispiel die Synchronisation von DNS-Einträgen in mehreren Clustern und stellt die Grundlage dar für höherwertige Funktionalitäten wie regelbasiertes Deployment von Pods sowie dynamisches Scheduling. Somit bietet KubeFed interessante Features und man darf erwarten, dass es den Einsatz von Kubernetes in kombinierten Cloud-Edge-Umgebungen erleichtert. Derzeit befindet es sich allerdings noch in einem frühen Alpha-Stadium.

Erfahrungen mit Kubernetes Node Federation

Damit ein Kubernetes-Cluster ordentlich funktioniert, ist es notwendig, dass die einzelnen Rechenknoten sich netzwerkmäßig gegenseitig erreichen können. Um virtuelle Maschinen einer Public Cloud und Edge-Geräte in einen Kubernetes-Cluster aufnehmen zu können, ist es erforderlich, ein VPN aufzusetzen.

Dann gilt es, sich zu entscheiden, wo der Kubernetes-Master-Knoten laufen soll: in der Public Cloud oder auf einem der Edge-Geräte. Für die Cloud-Seite spricht, dass man hier einfach eine genügend groß dimensionierte virtuelle Maschine verwenden kann und die Cloud eine stabilere Netzwerkanbindung hat als die Edge-Geräte. Auf der virtuellen Maschine, die den Kubernetes-Master beinhaltet, kann man nun beispielsweise mit kubeadm init einen Kubernetes-Cluster aufsetzen und die Edge-Geräte mit kubeadm join diesem Kubernetes-Cluster hinzufügen.

Als Container-Laufzeitumgebung wird beispielsweise Docker verwendet, das mittlerweile automatisch das für die jeweilige Prozessorarchitektur passende Image von einer Registry holt. Voraussetzung ist natürlich, dass die Images auch für alle nötigen Prozessorarchitekturen vorhanden sind. Dieses Konstrukt funktioniert prinzipiell und wird von den Autoren für diverse Prototypen und Untersuchungen verwenden. Es bietet jedoch an einigen Stellen Herausforderungen und ist deshalb für den produktiven Einsatz nur beschränkt zu empfehlen:

Das Netzwerk-Setup führt gerne zu Problemen, die sehr zeitaufwendig zu debuggen sind. Die Kombination aus physikalischem Netzwerk, VPN und Kubernetes-Overlay-Netzwerk ist nicht zu unterschätzen.
Verschiedene Linux-Distributionen auf Cloud- und Edge-Seite mit sich ändernden Versionen, in Kombination mit sich ändern den Versionen von Docker und kubeadm führen dazu, dass die Installation eines solchen Clusters meist hakelig ist.
Es ist schwierig, die Installation zu automatisieren. Während es für Cloud-Umgebungen mehrere Möglichkeiten einer automatisierten Installation gibt, ist die Unterstützung für die Installation eines Clusters in einer gemischten Umgebung sehr rudimentär. Setzt man beispielsweise den Cluster in der Cloud mit Terraform auf, so erhält man einen Kubernetes-Cluster, bei dem ein sogenanntes Cloud Provider Plugin zum Beispiel für Amazon AWS aktiv ist. Versucht man nun, einen Baremetal-Knoten als Edge-Gerät zu diesem Cluster hinzuzufügen, so wird dieser als Nicht-AWS-Knoten identifiziert und sofort wieder aus dem Cluster geworfen.

Neben Kubernetes selbst gibt es eine Reihe weiterer Technologien im Kubernetes-Umfeld, die Teile der beschriebenen Herausforderungen adressieren und sich in kombinierten Cloud-Edge-Umgebungen einsetzen lassen oder sogar speziell für diese Herausforderungen geschaffen worden sind. Die folgenden Technologien sollen im zweiten Teil dieses Artikels vorgestellt werden: