Cloud-nativ entwickeln mit Kubernetes

Kubernetes ist nicht nur ein beliebtes Werkzeug für Cloud-Architekten und Administratoren, sondern wird zunehmend auch direkt von Anwendungsentwicklern genutzt. Beim Einsatz von Kubernetes in der Softwareentwicklung gilt es jedoch, einige Herausforderungen zu meistern – trotz Best Practices und geeignetem Tooling.

Architektur/Methoden  –  6 Kommentare

Als Container-Orchestrator beherrscht Kubernetes vor allem den Betrieb und die Skalierung von Anwendungen. Im Developer Report 2019 von Stack Overflow taucht Kubernetes jedoch auch auf Platz 4 der Technologien auf, die Entwickler in Zukunft gerne lernen und verwenden möchten. Das wachsende Interesse von seiten der Developer-Community ist ein Zeichen dafür, dass Kubernetes in Zukunft nicht mehr nur ein allein auf Admins zugeschnittenes Tool für den Betrieb von Software bleibt, sondern unter Anwendungsentwicklern wachsende Bedeutung gewinnt. Doch bei der Nutzung von Kubernetes in der Softwareentwicklung treten eine ganze Reihe an Herausforderungen auf:

  • Wie stellt man Entwicklern Kubernetes zur Verfügung?
  • Wie wird das Deployment von Anwendungen mit Kubernetes so aufgebaut, dass Entwickler möglichst einfach neue Features testen können?
  • Welche Tools gibt es, die entwicklungsspezifische Aufgaben wie Debugging unterstützen?

Auf diese und weitere Fragestellungen gibt es eine Reihe möglicher Antworten, die dieser Artikel diskutiert. Dabei nehmen die Autoren einen auf die Praxis gerichteten Blickwinkel ein, um eine Übersicht an Techniken vorstellen zu können, die sich für verschiedene Aufgabenstellungen nutzen lassen. Denn nicht nur die Open-Source-Community hat die Notwendigkeit zur Verwendung von Kubernetes in der Entwicklung bereits erkannt, auch innerhalb der Cloud-Native-Community zielt eine Reihe neu gestarteter Projekte darauf, Entwicklern das Arbeiten mit Kubernetes zu erleichtern.

Cluster-Bereitstellung für Entwickler

Wenn Entwickler Kubernetes einsetzen möchten, stellt sich zuerst die Frage, welche Art von Cluster am geeignetsten ist. Dabei gibt es grundsätzlich zwei Optionen:

  • Erstellen eines lokalen Clusters auf dem Rechner des Entwicklers
  • Nutzung eines Remote-Clusters (Cloud)

Kubernetes auf der ContainerConf

Kubernetes und andere Cloud-native-Themen spielen auch auf der ContainerConf eine wichtige Rolle. Gemeinsam mit der Continuous Lifecycle findet die von heise Developer, iX und dpunkt.verlag veranstaltete Konferenz in diesem Jahr vom 12. bis 15. November in Mannheim statt.

Einen lokalen Single-Node-Cluster können Entwickler mit Tools wie minikube oder kind (Kubernetes in Docker) einfach mit nur wenigen Kommandos innerhalb weniger Minuten erstellen. Noch einfacher geht es mit der grafischen Oberfläche von Docker Desktop. Unabhängig von der Wahl der Tools bietet dieser lokale Ansatz den Vorteil, dass alle Entwickler einen eigenen Cluster nutzen können und der Administrationsaufwand niedrig bleibt. Darüber hinaus lässt sich ein solcher Cluster ohne große Mühe wieder löschen und neu aufsetzen, um bei Bedarf zu einem Clean State zurückzukehren oder etwaige Administrationsfehler zu beheben.

Lokale Cluster haben jedoch auch entscheidende Nachteile. Solche Testumgebungen unterscheiden sich typischerweise stark vom später anvisierten eigentlichen Produktionssystem. Cluster-interne oder Cloud-Provider-spezifische Services lassen sich in der Regel nicht nutzen, Persistent Volumes werden immer auf dem lokalen Rechner verwaltet und ein Zugriff auf Cloud-Storage wie S3 oder die Nutzung von Cloud-Hardware wie GPUs entfällt. Lokale Cluster sind zudem durch die Hardware-Ressourcen des Entwicklerrechners beschränkt, die der dauerhafte Betrieb eines Kubernetes-Clusters überdurchschnittlich belastet.

Methoden zur Cluster-Bereitstellung
Cluster-Bereitstellung Lokaler Cluster Remote Cluster Remote Cluster
Cluster-Typ Separater Cluster für jeden Entwickler Separater Cluster für jeden Entwickler Shared Cluster für mehrere Entwickler
Isolationsebene Cluster Cluster Namespace
Setup-Aufwand sehr gering gering in Public Clouds, höher in Private Clouds überschaubar
Administrationsaufwand sehr gering hoch gering
Administration durch Entwickler Admins / Entwickler Admins
Produktions-ähnliche Testumgebung nein ja ja
Zugriff auf Cloud-Services nur remote ja ja