Die Entwicklung mit Kubernetes ist schwierig. Glücklicherweise gibt es eine Reihe von Tools, die Entwickler_innen dabei unterstützen, Kubernetes in der Entwicklung zu nutzen. Hier möchte ich einen Überblick darüber geben, welche Tools es gibt, was sie tun und wie sie die Entwicklung mit Kubernetes erleichtern.
Tool-Übersicht
Es gibt eine Vielzahl verschiedener Tools, die unterschiedliche Teile des Entwicklungsworkflows unterstützen:
Die Grundlagen: Docker, kubectl, Managed Kubernetes
Die Entwicklung von Anwendungen, die in Kubernetes in Produktion laufen, erfordert den Einsatz von Container-Technologie – in der Regel Docker – und natürlich Kubernetes. Ich gebe einen kurzen Überblick über Docker und kubectl, da sie die Grundlage für jede Entwicklungsarbeit an Kubernetes-basierten Anwendungen bilden. Theoretisch (und auch in der täglichen Praxis vieler Entwickler_innen) sind Docker und kubectl alles, was man benötigt, um Kubernetes-basierte Anwendungen zu entwickeln. Zur besseren Übersicht liste ich auch einige Managed Kubernetes-Angebote und verwandte Tools auf.
Tools zur Emulation oder zum lokalen Betrieb von Kubernetes
Diese Tools ermöglichen es, ein Kubernetes-Cluster oder eine ähnliche Umgebung lokal zu betreiben.
Die wichtigsten Tools sind: minikube und kind.
Tools zum Erstellen, Deployen und Interagieren mit Containern in Kubernetes-Clustern
Diese Tools erleichtern es, Container zu erstellen, Container in einem (lokalen oder remote) Kubernetes-Cluster auszuführen und mit Containern zu interagieren, sobald sie in einem Kubernetes-Cluster laufen.
Die relevanten Tools sind: Draft, Devspace, Skaffold, Tilt und Garden.
Remote-Entwicklungsumgebungen für Kubernetes
Diese Tools verlagern die Entwicklungsarbeit von den Laptops der Entwickler_innen in die Cloud, indem sie Arbeitsumgebungen in der Cloud bereitstellen, in denen Container erstellt, getestet und in ein Remote-Cluster deployed werden.
Die wichtigsten Tools sind: Okteto, Eclipse Che und DevStack.
Im Folgenden gebe ich eine kurze Beschreibung jedes Tools, erkläre, wie es in den Entwicklungsprozess passt, und biete einige Links zu weiteren Informationen.
Docker
Docker ist kein reines Kubernetes-Entwicklungstool, aber da die Mehrheit der Entwickler_innen, die Anwendungen entwickeln, die in Kubernetes in der Produktion laufen, Docker als- oder einzige Laufzeitumgebung in der Entwicklung verwenden, verdient es hier eine Erwähnung.
Was ist Docker?
Docker ist die Containerisierungstechnologie, die den Großteil der Anwendungen zugrunde liegt, die in Kubernetes in Produktion laufen. Es ist nicht die einzige Container-Laufzeitumgebung, aber mit Abstand die gängigste.
Anwendungen, die in Kubernetes in der Produktion laufen, müssen containerisiert sein. Diese Container können in einem Kubernetes-Cluster ausgeführt werden, aber auch direkt auf einem Laptop oder einer VM mit Docker. Dies ist das am häufigsten verwendete Setup, wenn Entwickler_innen containerisierte / dockerisierte Anwendungen entwickeln, die später in Kubernetes in Produktion laufen. Docker ist Open Source.
Wo passt Docker Desktop in den Entwicklungsprozess?
Es gibt eine Reihe nützlicher Tools, die zusammen mit Docker verwendet werden können. Docker Desktop ist ein Paket aus Docker-Tools, einschließlich der Docker-Engine, einer Kommandozeilenschnittstelle (CLI) und einer grafischen Benutzeroberfläche zur Verwaltung von Container-Images, Containern und containerisierten Anwendungen auf einem lokalen Computer. Mit Docker Desktop können Container erstellt, veröffentlicht, ausgeführt sowie gestartet und gestoppt werden. Es verfügt auch über eine Funktion, die das Deployment eines Single-Node-Kubernetes-Clusters lokal ermöglicht. Docker Desktop beinhaltet auch Docker Compose, ein Tool zur Definition von Anwendungen, die aus mehreren Containern bestehen. In einer Docker-Compose-Datei legen Entwickler_innen fest, aus welchen Containern die Anwendung besteht und wie diese miteinander kommunizieren.
Ein sehr häufiger Entwicklungsworkflow besteht darin, eine containerisierte Anwendung während der Entwicklung lokal mit Docker Compose auszuführen und sie dann in Kubernetes in Produktion zu deployen.
Links
Produktwebsite: https://www.docker.com/
Github: https://github.com/docker
Dokumentation: https://docs.docker.com/
kubectl
What is kubectl?
kubectl ist das native Kommandozeilen-Tool für Kubernetes. Es stellt alle Kubernetes-Funktionalitäten über ein Terminal zur Verfügung, das interaktiv oder per Skript genutzt werden kann. Mit kubectl können Kubernetes-Cluster konfiguriert und verwaltet, Workloads gemanagt, mit Containern interagiert, Deployments in einem Cluster durchgeführt sowie Fehler behoben werden.
Wo passt kubectl in den Entwicklungsprozess?
kubectl ist ein leistungsstarkes Tool, das es ermöglicht, das gesamte Spektrum der Kubernetes-Funktionalitäten zu nutzen. Daher ist es auch relativ komplex. Viele der anderen hier beschriebenen Tools zielen darauf ab, die Handhabung von Kubernetes zu erleichtern, indem sie Funktionalitäten abstrahieren oder bündeln, die auch über kubectl verfügbar sind. Da kubectl jedoch den gesamten Funktionsumfang von Kubernetes bereitstellt, kann es (und wird es oft) auch als einziges Tool genutzt werden, um Kubernetes-Cluster zu verwalten und mit ihnen zu interagieren.
Links
Dokumentation: https://kubernetes.io/docs/reference/kubectl/
K3s, MikroK8s, GKE, EKS, AKS, DOKS, Rancher
All diese Abkürzungen stehen für verschiedene Kubernetes-Distributionen, die hauptsächlich für den produktiven Einsatz von Kubernetes entwickelt wurden. Da sie keine reinen Entwicklungstools sind, werde ich nur kurz erklären, was jede von ihnen ist:
K3s: Eine Kubernetes-Distribution, die für den Betrieb auf ressourcenbeschränkter Infrastruktur entwickelt wurde, z. B. an IoT-/Edge-Standorten oder in anderen Rechenumgebungen, die nicht horizontal skalieren. Mit K3s kann man beispielsweise ein Kubernetes-Cluster auf einem Raspberry Pi betreiben.
MicroK8s: Ermöglicht den Betrieb von Kubernetes-Clustern auf jeder Art von Hardware, ob klein oder groß, in der Cloud, am Edge oder anderswo.
Rancher: Eine Plattform zum Betreiben und Verwalten selbstgehosteter Kubernetes-Cluster.
GKE: Das Managed-Kubernetes-Angebot von Google Cloud.
EKS: Das Managed-Kubernetes-Angebot von Amazon Web Services (AWS).
AKS: Das Managed-Kubernetes-Angebot von Azure (Microsoft).
DOKS: Das Managed-Kubernetes-Angebot von DigitalOcean.
minikube
Was ist minikube?
Minikube ist ein Tool, das es ermöglicht, ein Single-Node-Kubernetes-Cluster in einem Container oder einer VM auf ihren lokalen Computern zu betreiben. Der Hauptzweck von minikube ist es, das Ausführen eines Kubernetes-Clusters lokal zu vereinfachen, um sowohl das Experimentieren mit Kubernetes als auch die Entwicklung von Kubernetes-basierten Anwendungen zu erleichtern.
Minikube-Cluster verfügen über viele Funktionen eines normalen Kubernetes-Clusters, wie z. B. Lastverteilung, Multi-Cluster-Unterstützung, Node Ports, persistente Speicher-Volumes und Ingress-Management. Es ist kompatibel mit drei Container-Runtimes: Docker, containerd und cri-o. Minikube ist Open Source.
Wo passt minikube in den Entwicklungsprozess?
Minikube macht es möglich, ein Kubernetes-Cluster auf einem Laptop oder lokalen Computer zu betreiben. Dadurch können Entwickler_innen ihre Anwendungen auf das lokale minikube-Cluster deployen, diese Anwendungen im Cluster inspizieren und bearbeiten – und das auf eine Weise, die einer Produktionsumgebung sehr nahekommt.
Minikube wird zusammen mit anderen Kubernetes-Entwicklungstools wie Skaffold, Tilt, Garden, Draft, kubectl oder Devspace bzw. DevStack verwendet. Diese anderen erleichtern das Deployment von Anwendungen in einem Cluster, z. B. einem minikube-Cluster, und bieten praktische Funktionen zur Interaktion mit Containern, die in einem minikube- (oder anderen) Cluster laufen.
Links
Github: https://github.com/kubernetes/minikube?tab=readme-ov-file
Dokumentation: https://minikube.sigs.k8s.io/docs
kind
Was ist kind?
kind (Kubernetes IN Docker) ist ein Tool zum lokalen Ausführen eines Kubernetes-Clusters unter Verwendung von Docker-Container-Nodes. Im Gegensatz zu minikube läuft kind nicht in einer VM oder einem Docker-Container und ermöglicht den Betrieb von Multi-Node-Clustern. Der Anwendungsfall von kind ist dem von minikube sehr ähnlich: Entwickler_innen können damit ihre Anwendungen lokal in einer Umgebung ausführen, die einer Kubernetes-Produktionsumgebung ähnelt.
kind wurde ursprünglich entwickelt, um die Entwicklung von Kubernetes selbst zu erleichtern. Deshalb unterstützt es das Erstellen von Kubernetes-Releases direkt aus dem Kubernetes-Quellcode. Obwohl es noch ein relativ junges Projekt ist, hat es bereits große Popularität bei Entwicklern gewonnen, die an Kubernetes-basierten Anwendungen arbeiten. kind ist Open Source.
Wo passt kind in den Entwicklungsprozess?
Kubernetes-Entwicklungstools wie Skaffold, Tilt, Garden, Draft, kubectl oder Devspace bzw. DevStack verwendet. Diese Tools erleichtern die Bereitstellung von Anwendungen in einem Cluster, wie z. B. einem kind-Cluster, und bieten praktische Funktionen zur Interaktion mit Containern, die in einem Cluster laufen.
Links
Github: https://github.com/kubernetes-sigs/kind
Produktwebsite: https://kind.sigs.k8s.io/
Dokumentation: https://kind.sigs.k8s.io/docs/
Draft
Was ist Draft?
Draft ist ein Open-Source-Tool von Microsoft, das es einfacher machen soll, Kubernetes zum ersten Mal auszuprobieren. Es erstellt grundlegende Dockerfiles, Kubernetes-Manifeste, Helm-Charts und andere Konfigurationsdateien (einschließlich GitHub Actions), um eine Anwendung zu containerisieren und in ein Kubernetes-Cluster zu deployen. Draft führt den Benutzer durch eine Reihe von Fragen und generiert basierend auf den Antworten entsprechende Konfigurationsdateien. Diese Dateien sind minimal und enthalten nur grundlegende Konfigurationsoptionen. Es ist ein nützliches Werkzeug, um einen ersten Eindruck davon zu bekommen, wie ein Dockerfile, ein Kubernetes-Manifest und ein Helm-Chart für eine Anwendung aussehen könnten. Draft verfügt auch über eine „Validate“-Funktion, die bestehende Kubernetes-Manifeste scannt und überprüft, ob sie (AKS-)Best Practices folgen. Draft ist Open Source.
Wo passt Draft in den Entwicklungsprozess?
Draft ist besonders nützlich, wenn man Kubernetes zum ersten Mal ausprobiert, auch mit einer Anwendung, die noch nicht containerisiert ist. Durch die Generierung minimaler Konfigurationsdateien hilft es Nutzern, die Struktur dieser Dateien zu verstehen und den Einstieg in das Schreiben eigener oder das Erweitern der von Draft generierten Dateien zu finden. Es ist weniger hilfreich, wenn Docker- und Kubernetes-Konfigurationen bereits existieren und bietet keine Funktionen zur täglichen Verwaltung von Kubernetes oder zum Deployment in ein lokales Kubernetes-Cluster. Daher ist es in erster Linie ein Werkzeug, um über Kubernetes zu lernen.
Links
Github: https://github.com/Azure/draft
Devspace
Was ist Devspace?
Devspace ist ein Kommandozeilen-Tool, das eine Vielzahl von Funktionen bietet, um die Arbeit mit Containern in Kubernetes-Clustern zu erleichtern. Zu den Hauptfunktionen gehören:
- Container-Images builden und deployen
- Dateien beobachten und Container in
- Echtzeit aktualisieren (Hot Reload)
- Logs von Containern streamen
- Dateien zwischen Containern und dem lokalen Computer synchronisieren (2-Wege-Dateisynchronisation)
- Terminals in Containern öffnen
- Ports von Containern zu localhost weiterleiten
- Container und ihren Status auflisten und beobachten
- Container-Images basierend auf einem Tag-Schema taggen
- Container-Images zu Registries pushen
Devspace verfügt auch über eine kleine Benutzeroberfläche, die hauptsächlich aus einem Terminal zur Ausführung von Befehlen besteht. Es ist ein Client-Only-Tool und verwendet kube-context, um mit Kubernetes-Clustern zu kommunizieren, ähnlich wie kubectl. Devspace ist Open Source.
Wo passt Devspace in den Entwicklungsprozess?
Devspace ist ein Tool, das die Arbeit mit Containern in Kubernetes-Clustern und die Verwaltung von Container-Builds und -Deployments erleichtert. Es ersetzt nicht das eigentliche Kubernetes-Cluster, sondern erleichtert die Arbeit damit. Devspace kann mit jedem lokalen oder Cloud-basierten Kubernetes-Cluster arbeiten: minikube, k3s, MikroK8s, kind, GKE (Google), EKS (AWS), AKS (Azure), DOKS (Digital Ocean), Rancher und anderen selbstverwalteten Kubernetes-Clustern.
Links
Github: https://github.com/devspace-sh/devspace
Produktwebsite: https://www.devspace.sh/
Dokumentation: https://www.devspace.sh/docs/
Skaffold
Was ist Skaffold?
Skaffold ist ein Tool zum Builden und Deployen von containerisierten Anwendungen in ein (lokales oder remote) Kubernetes-Cluster. Wenn Änderungen im Quellcode festgestellt werden, erstellt Skaffold die Container-Images neu, pusht sie zu einem Container-Registry, taggt sie basierend auf einer Tagging-Policy, testet die Container und deployed sie in ein Kubernetes-Cluster. (All dies ist natürlich konfigurierbar und optional.) Skaffold zielt darauf ab, die Standardisierung zu erleichtern, indem es sowohl eine YAML-basierte Konfigurationsstandard bietet, die es ermöglicht, ein Repository zu klonen und sofort zu erstellen und auszuführen, als auch kontext- und plattformbewusste Konfigurationsoptionen, die die gleiche grundlegende Konfiguration in unterschiedlichen Umgebungen funktionieren lassen. Es ist ein Client-Only Kommandozeilentool. Skaffold ist Open Source.
Wo passt Skaffold in den Entwicklungsprozess?
Skaffold erleichtert das kontinuierliche Builden und Deployen von Containern während der Entwicklung. Beim Arbeiten mit Skaffold benötigen Sie weiterhin ein Kubernetes-Cluster, in das Sie deployen – entweder lokal oder remote, z. B. ein minikube-Cluster auf Ihrem Laptop oder ein normales Cloud-Kubernetes-Cluster. Möglicherweise möchten Sie auch weiterhin Tools wie Devspace verwenden, um nach dem Deployment Ihrer Container in Ihr Kubernetes-Cluster eine Verbindung herzustellen, Logs zu streamen und allgemein mit Ihren Containern zu arbeiten.
Links
Produktwebsite: https://skaffold.dev/
Github: https://github.com/GoogleContainerTools/skaffold
Dokumentation: https://skaffold.dev/docs/
Tilt
Was ist Tilt?
Tilt ist ein Tool zum Builden und Deployen von Containern in ein (lokales oder remote) Kubernetes-Cluster. Es überwacht Codeänderungen, die einen Rebuild der Container auslösen, die dann automatisch in Ihr Kubernetes-Cluster deployed werden. Tilt bietet auch Funktionen zur Unterstützung beim Debuggen von Services, die in Kubernetes laufen. Besonders fokussiert sich Tilt auf Anwendungen, die aus vielen Services (d. h. Containern) bestehen und komplexe Abhängigkeiten haben, die schwer gemeinsam zu debuggen sind. Tilt zielt darauf ab, diesen Prozess zu erleichtern.
Wo passt Tilt in den Entwicklungsprozess?
Ähnlich wie Skaffold erleichtert Tilt das Builden und Deployen von Containern. Es wird weiterhin ein Kubernetes-Cluster benötigt, in das Sie Ihre Container deployen, beispielsweise ein lokales minikube-Cluster oder ein Kubernetes-Cluster in der Cloud. Tilt konzentriert sich stärker darauf, Einblicke in die laufenden Container in Kubernetes zu geben. Es kann nützlich sein, zusätzliche Tools wie Devspace zu verwenden, um das Streamen von Logs oder das Öffnen eines Terminals innerhalb eines Containers zu erleichtern, wenn dies erforderlich ist.
Links
Produktwebsite: https://tilt.dev/
Github: https://github.com/tilt-dev/tilt
Dokumentation: https://docs.tilt.dev/
Garden
Was ist Garden?
Garden ist ein DevOps-Tool, das darauf abzielt, das Deployen von Containern zu Kubernetes für Entwicklung, Test und Produktion mit derselben Konfiguration zu vereinfachen. Dies soll es erleichtern,
- neue Kubernetes-Cluster nach Bedarf bereitzustellen,
- es soll die Notwendigkeit, Umgebungen teilen zu müssen, reduzieren
- und das Testen von Features in einer isolierten Umgebung erleichtern.
Garden kann Codeänderungen überwachen und kann nur die geänderten Komponenten redeployen. Das Tool bietet auch Funktionen zum Streamen von Logs von Containern, die in einem Kubernetes-Cluster laufen und ermöglicht es, Dienste, die in verschiedenen Umgebungen ausgeführt werden, zu kombinieren. Damit können Entwickler_innen z.B. einen oder einige Dienste lokal ausführen und sich zu den anderen Diensten in einem Remote-Kubernetes-Cluster verbinden.
Wo passt Garden in den Entwicklungsprozess?
Garden deployed Container in bestehende Kubernetes-Cluster. Wie bei anderen Deployment-Tools bedeutet dies, dass Sie weiterhin Kubernetes-Cluster benötigen, in die Garden deployed – sei es ein lokales minikube-Cluster oder ein normales Cloud-Kubernetes-Cluster. Garden kümmert sich dann automatisch um das Rebuilding,, Testen und Deployen Ihrer Container nach einer Änderung am Quellcode. Entwickler_innen können Garden auch nutzen, um Logs von Containern zu streamen.
Links
Produktwebsite: https://garden.io/
Github: https://github.com/garden-io/garden
Dokumentation: https://docs.garden.io/
Okteto
Was ist Okteto?
Okteto ist eine Entwicklungsplattform für Kubernetes. Es überwacht Änderungen am Quellcode auf Ihrem Laptop. Bei einer Änderung wird dieser Code mit einem Entwicklungscontainer in einem Kubernetes-Cluster synchronisiert. In diesem Entwicklungscontainer wird der Code gebuildet (d. h. Container werden erstellt) und sofort in das Kubernetes-Cluster deployed. Das einzigartige Merkmal von Okteto ist der Entwicklungscontainer, in dem die Container-Erstellung durchgeführt wird. Dieser bietet eine standardisierte, kontrollierte Umgebung, die so konfiguriert werden kann, dass sie Produktions-Umgebungen spiegelt und über mehr Rechenressourcen verfügt als ein Laptop. Es gibt eine Open-Source-Version von Okteto mit einem minimalen Funktionsumfang sowie ein kommerzielles Angebot mit erweiterten Funktionen.
Wo passt Okteto in den Entwicklungsprozess?
Okteto erleichtert und beschleunigt das Testen und Deployen von Codeänderungen an einer containerisierten Anwendung, die in Kubernetes läuft. Es spart viel Zeit, indem es den Build- und Deployment-Prozess automatisiert und eine Art Hot Reload für eine in Kubernetes laufende Anwendung bietet. Als Build- und Deployment-Tool benötigt Okteto weiterhin ein Kubernetes-Cluster, zu dem es eine Verbindung herstellen kann. Während es theoretisch möglich ist, Okteto mit einem lokalen minikube (oder ähnlichem) Cluster zu verwenden, ist dies nicht der Hauptzweck von Okteto, das speziell darauf abzielt, Entwicklern_innen mehr Remote-Compute-Ressourcen zur Verfügung zu stellen, um Build und Deployment zu beschleunigen. In einer typischen Konfiguration wäre Okteto mit einem Cloud-Kubernetes-Cluster verbunden.
Links
Produktwebsite: https://www.okteto.com/
Github: https://github.com/okteto/okteto
Dokumentation: https://www.okteto.com/docs/
Eclipse Che
Was ist Eclipse Che?
Eclipse Che ist eine Cloud-Entwicklungsumgebung, die in Kubernetes läuft. Entwickler_innen arbeiten innerhalb eines Entwicklungs-Pods in einem Kubernetes-Cluster, zu dem sie Entwicklungs-Container deployen, die ihre Arbeitsumgebungen enthalten, wie z.B. Quellcode, Runtimes und ein IDE-Backend, zusammen mit mehreren anderen Anwendungscontainern. Entwickler_innen können entweder eine Online-IDE wie VS Code nutzen oder ein JetBrains IDE-Backend in ihrem Entwicklungs-Container ausführen, auf dem sie mit ihrem lokalen JetBrains IDE (z.B. IntelliJ oder PyCharm) zugreifen. Jede_r Entwickler_in hat einen eigenen Entwicklungs-Pod, in dem mehrere Container neben dem Entwicklungs-Container deployed werden können. So kann jede_r Entwickler_in eine eigene, vollwertige Instanz der Anwendung in einem eigenen Kubernetes-Pod betreiben. Eclipse Che ist Open Source. Es gibt ein kommerzielles SaaS-Angebot von Eclipse Che, das von Red Hat bereitgestellt wird.
Wo passt Eclipse Che in den Entwicklungsprozess?
Eclipse Che ermöglicht Entwicklern_innen die Verbindung zu und Arbeit innerhalb eines Entwicklungs-Containers in einem Kubernetes-Pod auf einem Kubernetes-Cluster. Mit Eclipse Che ist es möglich, über den Browser von jedem Gerät aus zu arbeiten. Alternativ wird nur ein IDE-Thin-Client benötigt. Alles andere läuft im Kubernetes-Cluster. Während es technisch möglich ist, Eclipse Che mit einem lokalen minikube-Cluster zu verwenden, ist dies nicht der Hauptzweck: Che soll die Abhängigkeit von Laptops reduzieren und mehr Rechenressourcen sowie standardisierte Umgebungen bieten. Daher läuft Eclipse Che typischerweise in einem Cloud-Kubernetes-Cluster. Che bietet auch keine Automatisierung des Deployments oder andere praktische Funktionen (wie Log-Streaming, Terminals innerhalb von Containern usw.), die andere Kubernetes-Tools hier bieten. Daher werden Entwickler_innen weiterhin andere Tools zusammen mit Che in ihrem Entwicklungsworkflow verwenden.
Links
Produktwebsite: https://eclipse.dev/che/
Github: https://github.com/eclipse-che/che
Dokumentation: https://eclipse.dev/che/docs/s
DevStack
Was ist DevStack?
Cloudomation DevStack ist eine Plattform für Cloud-Entwicklungsumgebungen, die für die Entwicklung von Anwendungen verwendet werden kann, die in Produktion in Kubernetes laufen – entweder mit einem Docker- oder einem Kubernetes-basierten Entwicklungsworkflow. DevStack ermöglicht es, Entwicklungsumgebungen zu definieren. Diese bestehen aus mehreren Containern, die entweder in einem Kubernetes-Cluster oder auf einer virtuellen Maschine nur mit Docker bereitgestellt werden. Docker- und Kubernetes-Entwicklungstools können zusammen mit der Anwendung deployed werden, entweder direkt auf der VM oder in einem Entwicklungs-Container. DevStack kann Änderungen am Quellcode überwachen und Container auf der VM oder im Kubernetes-Cluster neu erstellen und deployen. Die Konfiguration von Entwicklungsumgebungen erfolgt in Python und kann stark angepasst werden. Darüber hinaus ermöglicht DevStack die Automatisierung von Container-Tests und -Deployments und kann zur Automatisierung der gesamten CI/CD-Pipeline verwendet werden.
Wo passt DevStack in den Entwicklungsprozess?
Als Plattform für Entwicklungsumgebungen und Deployment-Automatisierung ermöglicht es DevStack Developern, standardisierte Entwicklungsumgebungen schnell und einfach einzurichten. Durch die Überwachung von Änderungen und das Re-Deployment von Codeänderungen in Containern werden manuelle Schritte automatisiert und der Entwicklungsprozess erheblich beschleunigt. Im Gegensatz zu anderen Plattformen ermöglicht es DevStack Benutzer_innen, zwischen einem Docker-only-Entwicklungsworkflow oder dem Betrieb von Entwicklungsumgebungen innerhalb eines Kubernetes-Clusters zu wählen. In beiden Fällen kann DevStack entweder bestehende Infrastruktur nutzen (d.h. in ein bestehendes Kubernetes-Cluster deployen) oder die Infrastruktur-Erstellung automatisieren (d.h. VMs erstellen, auf denen die Container deployed werden). Für einen Docker-only-Workflow bietet DevStack Funktionen wie Portweiterleitung, Log-Tailing und das Öffnen einer Terminal-Sitzung innerhalb der Container über CLI. Für einen Kubernetes-basierten Workflow können zusätzliche Kubernetes-Entwicklungstools verwendet werden, um mit den Containern innerhalb des Kubernetes-Clusters zu interagieren.
Links
Produktwebsite: https://cloudomation.com/devstack/
Dokumentation: https://docs.cloudomation.com/devstack
Warum sollten diese Tools genutzt werden?
Es ist wichtig zu erwähnen, dass es nicht zwingend erforderlich ist, einen Kubernetes-Cluster (oder etwas, das wie ein Kubernetes-Cluster funktioniert) zu verwenden, um Anwendungen zu entwickeln, die in Produktion in Kubernetes laufen.
Jede Anwendung, die in Kubernetes läuft, ist containerisiert. Diese Container können in einem Kubernetes-Cluster betrieben werden, aber sie können auch ohne einen solchen laufen, beispielsweise nur mit Docker. Die überwiegende Mehrheit der Entwickler_innen, die an Kubernetes-Basierten-Anwendungen arbeiten, betreiben keinen lokalen Kubernetes-Cluster und nutzen keinen Remote-Cluster für die Entwicklung. Die meisten nutzen Container direkt über Docker auf ihren Laptops.
Das ist viel einfacher und in vielen Fällen ausreichend. Es gibt aber drei Gründe, warum es notwendig sein kann, Container in Kubernetes – während der Entwicklung – zu betreiben:
- Unterschiedliches Verhalten von Containern in Docker und Kubernetes
Container verhalten sich beim Ausführen in Docker anders als beim Ausführen in Kubernetes. In einigen Fällen kann dies zu Problemen führen, wenn man nur mit Docker entwickelt und dann auf Kubernetes deployed. - Entwicklung Kubernetes-spezifischer Funktionen
Um einige Funktionen zu entwickeln, die in Kubernetes funktionieren sollen, benötigt man einfach Kubernetes – zum Beispiel zum Entwickeln von Kubernetes-Netzwerk-Richtlinien. - Ressourcenbeschränkungen bei großen Anwendungen
Für große Anwendungen mit vielen Komponenten kann es schlichtweg unmöglich sein, sie auf einem Laptop auszuführen, weil dieser nicht über genügend Rechenressourcen verfügt.
Viele Unternehmen entscheiden sich, (1) zu ignorieren und Probleme zu beheben, wenn sie auftreten. (2) ist ein eher seltener Fall, für den viele Unternehmen Workarounds finden. Der Hauptgrund, warum die Entwicklung innerhalb von Kubernetes zunehmend häufiger wird, ist (3): Anwendungen werden größer und komplexer, und Entwickler_innen sind zunehmend nicht mehr in der Lage, sie lokal zu deployen, sei es mit oder ohne Kubernetes. In diesem Szenario verschärft ein lokaler Kubernetes-Cluster die Situation sogar noch, da er ebenfalls Ressourcen beansprucht.
Das bedeutet, dass die einzigen Gründe, einen Kubernetes-Cluster lokal zu betreiben, darin bestehen, eine Umgebung zu erhalten, die der Produktionsumgebung ähnlicher ist und/oder um Kubernetes-spezifische Funktionen und Konfigurationen zu entwickeln. Darüber hinaus gibt es keinen tatsächlichen Nutzen, Kubernetes lokal auszuführen. Die Lastverteilung und flexible Skalierung von Kubernetes sind lokal unnötig.
Da es schwierig ist, einen Minikube- oder ähnlichen Cluster lokal zu betreiben und noch schwieriger, Remote-Kubernetes-Entwicklungsumgebungen einzurichten und zu pflegen, ist es wichtig, dass man überlegt, ob dies wirklich benötigt wird und ob der Bedarf stark genug ist, um den Aufwand zu rechtfertigen.
Denn, wie viele Entwickler_innen oder DevOps-Ingenieure_innen sagen werden: Kubernetes ist eine Herausforderung. Es ist eine komplexe Software, die viel Wissen und Aufwand erfordert, um eingerichtet, konfiguriert und betrieben zu werden.
