Tools und Erweiterungen für K8s-Umgebungen Kubernetes im Do-it-Yourself-Verfahren

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

„Kubernetes“ oder kurz „K8s“ hat die verteilte Landschaft der Container-Orchestrierung und Anwendungsvirtualisierung im Sturm erobert und bricht weiterhin Rekorde der Popularität. Wer für Kubernetes coden möchte, hat es jedoch nicht leicht.

Kubernetes ist die meistgenutzte Plattform für die Ausführung von containerisierten Anwendungen. Laut einer am 17. November 2020 veröffentlichten Umfrage der Cloud Native Computing Foundation (CNCF) bekennen sich neun von zehn Entwicklern zur Nutzung von K8s; gut vier von fünf (83 Prozent) vertrauen darauf sogar in ihrer Produktionsumgebung. Europa war an der diesjährigen CNCF-Umfrage mit 38 Prozent der Teilnehmer vertreten.

Als die mit Abstand beliebteste Kubernetes-Umgebung konnte dieses Jahr wieder Minikube mit einem Anteil von 37 Prozent punkten. Zwei weitere haben jedoch im Laufe des vergangenen Jahres merklich zugelegt: On-Premises-, sprich Vor-Ort-Installationen und Kubernetes in Docker (kind).

Während sich 2019 nur 23 Prozent der Nutzer eine On-Prem-Installation zugetraut hatten, sind es dieses Jahr 31 Prozent. Einen noch stärkeren Zuwachs seiner Nutzerbasis konnte kind verzeichnen: Während im vergangenen Jahr nur 13 Prozent der Befragten über eine Kubernetes-Umgebung in Docker verfügten, hat sich die Zahl seither genau verdoppelt.

Docker und Helm

Kubernetes in Docker meistert die Bereitstellung lokaler Kubernetes-Cluster in Container-Knoten von Docker. Ursprünglich hatte sich das Werkzeug beim Testen von Kubernetes seine Sporen verdient; inzwischen haben es anscheinend viele Entwickler als eigenständige Kubernetes-Umgebung entdeckt und für gut befunden.

Helm, der offizielle Paketmanager von Kubernetes, gilt nach wie vor als das beliebteste Werkzeug zum Verpacken von Kubernetes-Anwendungen. Er ist aktuell bei 63 Prozent der Befragten der CNCF-Umfrage im Einsatz. Auf Platz zwei kommt weit abgeschlagen Kustomize, der Kubernetes-native, deklarative Konfigurationsmanager (neuerdings im Funktionsumfang von kubectl und zugänglich über den Befehl apply -k).

An Tools mit Kustomize-Integrationen mangelt es im Übrigen nicht; zu den viel versprechendsten zählen „kots“, „argo“, „Kubestack“, „flux“ und „unfork“. Ungeachtet der anhaltenden Popularität ist der Weg zu einer erfolgreichen Containerisierung mit Kubernetes doch gespickt mit Überraschungen und Stolperfallen.

Die Qual der Wahl

Kubernetes schreibt dem Entwickler weder bestimmte Sprache(n) noch bestimmte Tools vor. So haben die Entwickler die ultimative Freiheit bei der Wahl ihrer Umgebung, aber auch die Qual der Wahl. In erster Linie gilt es, die Frage nach dem Standort der Dev-Umgebung und jenem der finalen Bereitstellung zu beantworten.

Zur Auswahl stehen dabei vier Möglichkeiten:

• alles lokal („pure offline mode“): der Dev-Cluster und die Bereitstellung können beide auf dem lokalen Computer laufen, wenn die Entwicklungswerkzeuge es zulassen; diesen Weg können Entwickler unter anderem bei der Verwendung von Minikube, Docker für Mac/Windows und Minishift einschlagen;

• die Dev-Umgebung läuft lokal, die Bereitstellung per Netzwerkumleitung („proxied mode“): Dieser Ansatz lässt sich mit Tools wie Telepresence umsetzen;

• die Dev-Umgebung läuft lokal, die Bereitstellung erfolgt „live“ in der Cloud: Mit Tools wie „Skaffold“ propagieren sich lokale Code-Änderungen automatisch auf die Bereitstellung;

• Beide Kubernetes-Umgebungen laufen in der Wolke: Sie lassen sich dann zwar vorhersehbar replizieren (anders als eine lokale Bereitstellung mit jeweils ihren eigenen Besonderheiten, die sich dem Entwickler insbesondere im Zusammenhang mit der Authentifizierung wiederholt in den Weg stellen), dafür schlagen sie während der gesamten Laufzeit mit Pay-as-you-go-Kosten der Bereitstellung zu Buche.

Kubernetes-Objekte wie „ingres“ verhalten sich von Bereitstellung zu Bereitstellung sehr unterschiedlich. Viele Entwickler greifen daher auf Tools wie „Kubespy“ oder „Octant“ zu, um sich aus der Konfiguration einen Reim zu machen.

In dem Bericht „The Forrester Wave: Multicloud Container Development Platforms“ vom dritten Quartal 2020 hat das Beratungsinstitut Forrester neun Multi-Cloud-fähige Entwicklungsplattformen für Container ausmachen können: „Canonical microk8s“, „D2iQ“ (zuvor bekannt als „Mesosphere“) mit der „Ksphere Suite“, „Google Anthos“, „Mirantis“, „Platform9 Systems“, „Rancher“ (neuerdings aus dem Hause Suse), „Red Hat/IBM Openshift“ und VMware „Tanzu“ (entstanden aus Akquisitionen von Pivotal, Heptio und Bitnami).

Diese Plattformen reflektieren die Überzeugung, dass Entwickler die „integrierte Entwicklererfahrung“ zunehmend meiden würden. Sie würden demnach „mit ihren Füßen abstimmen“, indem sie weg von schlüsselfertigen PaaS-Umgebungen hin zu Kubernetes-Distributionen im Selbstbedienungsmodell migrierten. Coder würden es demnach vorziehen, die einzelnen Bestandteile ihrer Entwicklungsumgebung individuell zusammenzustellen und nicht als hartcodierte Dienste zu verbrauchen.

Laut dem Bericht von Forrester habe sich diese Überzeugung unter anderem Canonical, bekannt als Heim der Linux-Distribution Ubuntu, des beliebtesten Betriebssystems auf OpenStack, auf die Fahnen geschrieben. Die Softwareschmiede sei mit ihrer Anwendung „JuJu“ und der eigenen Infrastrukturmodellierungs-Engine auf enormen Zuspruch gestoßen. Mit microk8s bietet Canonical eine hochverfügbare autonome Zero-Ops Kubernetes-Umgebung in Produktionsqualität für Clouds, Cluster und lokale Workstations auf Linux, Windows und MacOS mit selbstheilenden Clustern.

Wer sich aus einzelnen Puzzle-Teilchen eine eigene Entwicklungsumgebung im DIY-Verfahren zusammenstricken will, braucht den nötigen Überblick. Denn die Möglichkeiten sind nahezu endlos und es kommen ständig neue hinzu.

Draft

Mit dem „MS-Azure-orientierten Tool Draft“ können Entwickler, wie der Name schon andeutet, den ersten Entwurf einer containerisierten Anwendung zur Bereitstellung auf Kubernetes aufsetzen. Bei der erstmaligen Initialisierung wertet Draft den Code automatisch aus und baut dafür ein Grundgerüst auf (Engl. scaffolding), um der Containerisierung der entstehenden Anwendung auf die Sprünge zu helfen.

Mithilfe von Heuristiken und einer Vielzahl vordefinierter Projektvorlagenentwürfe entsteht so eine erste Docker-Datei zum Containerisieren der Anwendung sowie ein Helm-Chart, mit dem sich diese in einem Kubernetes-Cluster bereitstellen und verwalten lässt. Entwickler-Teams können sogar ihre eigenen Projektentwürfe mitbringen, um das vom Tool erstellte Grundgerüst ihren besonderen Bedürfnissen anzupassen.

Doch der praktische Nutzen von Draft geht weit über das Bootstrapping der Anwendung hinaus. Draft provisioniert einen Server in dem bereits vorhandenen Kubernetes-Cluster und synchronisiert ihn daraufhin automatisch mit dem Code auf der Entwickler-Maschine. Wird der Code der Anwendung lokal geändert, geht der Draft-Daemon hin und synchronisiert diesen lokalen Code mit dem Draft-Server in Kubernetes; so wird die automatische Bereitstellung eines neuen Containers ohne jegliche Benutzeraktionen initiiert.

Das ist alles schön und gut, nur hat Draft nach wie vor einen nicht zu unterschätzenden Schönheitsfehler: Es versteht sich bisher als ein Experiment, ein Entwurf also im wörtlichen Sinne. Andererseits lässt sich Draft als Ergänzung zu Tools wie „Squash“ nutzen und es kann Skaffold komplett ersetzen.

Skaffold

Googles quelloffenes Werkzeug Skaffold zielt darauf ab, die Portabilität für CI-Projekten (Continuous Integration) mit verschiedenen Build-Systemen, Image-Registrierungs- und Bereitstellungstools zu ermöglichen. Es verfügt zwar über die Fähigkeit zum Generieren von Manifesten, aber sie ist kein herausragendes Merkmal von Skaffold.

Das wichtigste Feature von Skaffold ist die Erweiterbarkeit; sie ermöglicht es dem Benutzer, in jedem der Schritte bei der Erstellung und Bereitstellung seiner Anwendung externe Werkzeuge hinzuzuschalten. Skaffold kann lokale Code-Änderungen beobachten und die Bereitstellung daraufhin auslösen. Es lässt sich durchaus anstelle von Draft nutzen.

Squash

Squash besteht aus einem Debug-Server, der vollständig in Kubernetes integriert ist, und einem IDE-Plugin. Das Werkzeug erlaubt es dem Entwickler, Breakpoints einzufügen und die Anwendung von einer IDE aus wie gewohnt zu debuggen. Es erlaubt dem Entwickler, den Debugger an einen Kubernetes-Pod anzuhängen, welcher in dem betreffenden Kubernetes-Cluster (sei es lokal oder in der Cloud) läuft. Squash unterstützt Go, Python, Node.js, Java und den GNU-Debugger gdb.

Telepresence

Zum Austesten von Code-Änderungen muss der Entwickler das Image neu erstellen, in eine Docker-Registry verschieben und anschließend die Bereitstellung auf Kubernetes erneut initiieren. Das dauert alles seine Zeit. Das Tool „Telepresence“ kann Abhilfe schaffen.

Telepresence beschleunigt die Iterationsschritte der Entwicklung containerisierter Anwendungen, indem es die Notwendigkeit der Bereitstellung auf dem Cluster aufhebt. Hierzu macht es sich einen Zwei-Wege-Proxy in dem Kubernetes-Cluster zu Nutze. Dieser Proxy spiegelt die Remote-Bereitstellung an einen Prozess am Port 8080 auf dem lokalen Computer.

Telepresence überschreibt die Netzwerk- und Dateisystemschnittstelle für diesen Prozess und koordiniert dabei auch den Zugriff auf config-Maps und Secrets. So ist es möglich, den Code lokal zu bearbeiten und auf dem Kubernetes-Cluster zu testen. Telepresence unterstützt die Entwicklung von Kubernetes- und OpenShift-basierten Microservices und ist ein Projekt der CNCF.

Kubernetes-Tools für VS Code

Bei Kubernetes-Tools für VS Code handelt es sich um eine Erweiterung für Microsoft Visual Studio Code, welche die IDE um quelloffene Werkzeuge zur Entwicklung von Anwendungen für Kubernetes-Cluster ergänzt. Die Erweiterung funktioniert überall und mit jeder Kubernetes-Bereitstellung (unter anderem auf Azure, Minikube, AWS und GCP). Sie fügt dem VC Code-Editor eine Kubernetes-Schaltfläche hinzu.

Mit der Erweiterung kann VS Code unter anderem Kubernetes-Cluster anzeigen und verwalten sowie Container aus Dockerfiles erstellen und ausführen und „Intellisense“-Funktionalität auf Kubernetes- und Helm-Ressourcen erweitern. Die Erweiterung bietet Entwicklern eine Vielzahl nützlicher Features speziell zum Erstellen und Testen von Charts für eine reibungslose Bereitstellung verteilter Anwendungen auf Kubernetes-Clustern.

Zu den unbestreitbaren Highlights dieser „Werkzeugkiste“ zählt Draft, eines der Früchte von Microsofts Akquisition der Container-Plattform Deis in 2017. Mit der API, die Microsoft veröffentlicht hat, können Entwickler dem „Werkzeugkasten“ eigene Module hinzufügen. Die API Library ist als NPM-Paket erhältlich, so dass sie sich sie in Projekte leicht importieren lässt, um neue Erweiterungen darauf aufzusetzen.

* Das Autoren-Duo Anna Kobylinska und Filipe Pereia Martins arbeitet für McKinley Denali Inc. (USA)

(ID:47041368)