Mit diesen K8-Distributionen bringen Sie Kubernetes zum Edge
Edge-Computing ist nicht mehr so weit entfernt, wie es einmal schien. Wir erklären verschiedene Möglichkeiten, Kubernetes an den Edge zu bringen, und welche am besten zu wem passt.
Eine der wichtigsten Fragen, die IT-Organisationen sich vor dem Implementieren von Edge Computing stellen sollten, ist, ob es sich dabei um eine Erweiterung ihrer Cloud-Infrastruktur handeln soll.
Die Rolle des Edge im Zusammenhang der gesamten IT-Infrastruktur ist für die Rolle von Kubernetes von grundlegender Bedeutung.
Grundlagen des Edge-Computing
Edge Computing soll Daten, die in der Peripherie des Netzwerks einer verteilten IT-Architektur gesammelt werden, so nahe wie möglich an ihrem Entstehungsort verarbeiten. Dies reduziert die Latenz und Probleme durch Netzwerkstörungen und bietet weitere Vorteile beim Arbeiten mit verteilten Speicher- und Rechenressourcen.
Edge-Computing-Geräte sind nicht Teil eines Ressourcenpools, sondern erfüllen bestimmte, eng umrissene Aufgaben. Das bedeutet, dass Cloud-Technologie, die gewöhnlich auf Ressourcenpools ausgerichtet ist, am Edge nicht ihr volles Potential entfaltet. Die Bereitstellung von Kubernetes am Edge sollte sich daran orientieren. Im Folgenden setzen wir uns mit verschiedenen Kubernetes-Varianten und ihrer Eignung für den Einsatz am Edge auseinander.
Standard-Kubernetes am Edge
Da Edge-Rechenzentren meistens sehr klein sind und nicht aus spezialisierten Servern bestehen, ist es sinnvoll, die Standard-Kubernetes-Technologie sowohl am Edge als auch in der Cloud zu verwenden. Einige Kubernetes-Funktionen erweisen sich bei ordnungsgemäßer Einrichtung in Edge-Anwendungen als nützlich.
Mit ReplicaSets können IT-Administratoren beispielsweise explizit eine Sicherungsressource zuweisen, um Failover von Edge-Anwendungen zu beschleunigen. ReplicaSets verwenden hostPath-Volumes, um Datenbanken von einem Edge-Host für alle darauf ausgeführten Pods verfügbar zu machen.
Mit Affinities, Taints und Tolerances können Sie Kubernetes so einrichten, dass Edge-Pods geeigneten Knoten zugeordnet werden und nicht geeigneten, beispielsweise weit entfernten Pods fernbleiben.
KubeEdge
Für die explizite Trennung von Edge und Cloud – und gleichzeitig für eine übergreifende Kubernetes-Bereitstellung – ist KubeEdge eine gute Lösung.
KubeEdge erstellt eine Edge-Umgebung auf einer Cloud-Plattform und verwendet Edge Controller, um diese Umgebung am mit der Hauptbereitstellung von Kubernetes zu verknüpfen. Dadurch entsteht ein ähnliches Setup, wie bei der Standard-Kubernetes-Bereitstellung über beide Umgebungen hinweg.
Es ist jedoch einfacher, den Edge-Teil zu verwalten, da weniger spezifische Regeln erforderlich ist, um Edge-Pods ordnungsgemäß auf Edge Nodes zu lenken und Sicherungspfade einzurichten. KubeEdge enthält außerdem ein Service-Mesh für den Zugriff auf Edge-Geräte.
K3s
Eine weitere interessante Distribution ist K3s, eine von Rancher entwickelte Kubernetes-Version mit geringem Platzbedarf, die auf Edge-Szenarien mit begrenzten Ressourcen zugeschnitten ist. Der Footprint von K3s ist nur halb so groß, wie der einer Standard-Kubernetes-Distribution und manchmal sogar kleiner. K3s ist vollständig CNCF-zertifiziert (Cloud Native Computing Foundation); das heißt, dass YAML-Konfigurationsdaten zwischen Standard-Kubernetes und K3s austauschbar sind.
Um sich für eine Kubernetes-Distribution am Edge zu entscheiden, sollten Sie sich fragen, ob Ihre Edge-Ressourcen mit den Cloud-Ressourcen vergleichbar sind.
K3s erstellt ein Edge-Cluster, das eine weitere Isolation zwischen Edge und Cloud ermöglicht. Dieses Setup kommt Szenarien zugute, in denen Edge-Pods nicht außerhalb des Edge laufen sollten – beispielsweise aus Ressourcen- oder Latenzgründen. K3s verfügt jedoch über nicht redundante Elemente – zum Beispiel Datenbankkomponenten wie SQLite. Das kann das Risiko eines Ausfalls erhöhen. Außerdem ist es schwieriger, ein separates K3s-Edge-Cluster zu koordinieren, wenn Administratoren Edge- und Cloud-Knoten dieselben Pods zuweisen können.
MicroK8s
Viele Benutzer betrachten MicroK8s als Vermittler zwischen Edge-Clustern und einer vollständigen Standard-Kubernetes-Bereitstellung. Die Distribution ist klein genug, um in Umgebungen mit begrenzten Ressourcen zu funktionieren, kann aber auch vollständige Cloud-Ressourcenpools orchestrieren. Somit ist MicroK8s wohl die agilste der Kubernetes-Optionen für den Edge. Sie erfordern trotzdem keine komplizierte Installation oder Bedienung.
Ein Nachteil ist, dass sie nicht alle möglichen Kubernetes-Funktionen unterstützen: IT-Organisationen mit einer vorhandenen Kubernetes-Bereitstellung müssen einige Funktionen neu definieren, um sie an MicroK8 anzupassen.
Für wen eignet sich welche Distribution?
Um sich für eine Kubernetes-Distribution am Edge zu entscheiden, sollten Sie sich fragen, ob Ihre Edge-Ressourcen mit den Cloud-Ressourcen vergleichbar sind. Sind die Unterschiede nicht allzu groß, ist eine Standardbereitstellung von Kubernetes die effizientere Variante. Sie arbeitet mit festen Affinitäten und zugehörigen Parametern zum Zuweisen von Pods an Edge-Knoten. Wenn die Edge- und Cloud-Umgebungen eher symbiotisch als einheitlich sind, ziehen Sie KubeEdge in Betracht.
Je größer die Unterschiede zwischen Edge- und Cloud-Umgebung sind, desto logischer ist es, die beiden zu trennen – insbesondere, wenn die Edge-Ressourcen zu knapp bemessen sind, um Standard-Kubernetes auszuführen. Wenn Sie eine gemeinsame Orchestrierung von Edge- und Cloud-Workloads wünschen, um Edge-Daten in der Cloud zu sichern, verwenden Sie MicroK8s oder eine ähnliche Distribution. Wenn Latenz oder Ressourcenspezialisierung am Edge diese Variante ausschließen, ist K3s eine gute Wahl.
In den wenigsten Fällen wird also eine einzige Kubernetes-Distribution alle Bedürfnisse Ihres Unternehmens erfüllen.
