Cloud-nativ entwickeln mit Kubernetes
Seite 2: Remote-Cluster in der Cloud
Die Alternative zum lokalen Cluster sind dedizierte Remote-Cluster. Dabei gibt es grundsätzlich zwei Optionen: Entweder erhalten alle Entwickler eigene Cluster zum Testen oder ein Team teilt sich einen. In beiden Fällen profitieren Entwickler davon, ihre Software in einer Umgebung testen zu können, die sich kaum vom späteren Umfeld für den produktiven Einsatz der Applikationen unterscheidet. Darüber hinaus können Entwickler unkompliziert weitere Cloud-spezifische Dienste einbinden sowie die Leistungsfähigkeit und Skalierbarkeit der zugrundeliegenden Cloud-Hardware ausreizen, ohne den eigenen Rechner durch den Betrieb eines Clusters belasten zu müssen.
Soll ein separater Kubernetes-Cluster für jeden Entwickler zur Verfügung stehen, liegt die größte Herausforderung darin, die Berechtigungen der Nutzer so zu konfigurieren, dass alle Entwickler möglichst schnell und unkompliziert Cluster erstellen oder zumindest darauf zugreifen können. Wer auf einen Public Cloud Service wie Amazon Web Services (AWS) oder Microsoft Azure setzt, ist hier klar im Vorteil, denn die integrierte Rechteverwaltung dieser Plattformen bietet dafür meist vielfältige Optionen.
Darüber hinaus lassen sich mittels Terraform oder Cloud-Provider-spezifischem Tooling wie eksctl von AWS Kubernetes-Cluster mit nur einem Kommando erstellen. Mit der Anzahl an Clustern wächst allerdings der Administrationsaufwand. Daher ist insbesondere die Verwendung eines Managed Kubernetes Service – beispielsweise Elastic Kubernetes Service von AWS oder Google Kubernetes Engine – zu empfehlen, um typische Administrationsaufgaben wie Cluster-Upgrades zu automatisieren. Wer jedoch auf Public Cloud Services verzichtet, weil er die Entwicklung und den Betrieb der Software allein im eigenen Rechenzentrum belassen muss oder möchte, den erwartet ein deutlich höherer Aufwand, um eine Vielzahl an Kubernetes-Clustern für einzelne Entwickler zu erstellen und zu administrieren.
Shared-Cluster für mehrere Entwickler im Team
In diesem Fall hilft die oben erwähnte Variante der Shared-Cluster für mehrere Entwickler. Setup- und Administrationsaufwand lassen sich auf wenige oder sogar einen einzelnen Entwicklungs-Cluster reduzieren, wenn ein Team von Entwicklern Zugriff auf denselben Cluster erhält und die gegenseitige Isolierung für ein ungestörtes Nebeneinander auf Namespace-Ebene erfolgt.
Die größte Herausforderung bei der Nutzung eines solchen Shared-Clusters ist die Strukturierung der Multi-Tenancy innerhalb des Clusters. Damit mehrere Entwickler denselben Cluster nutzen können, muss sichergestellt sein, dass sie einander nicht in die Quere kommen. Dazu sind entsprechende Konfigurationen in Kubernetes vorzunehmen, darunter Role-Based Access Control, Pod Security Policies, Resource Quotas und Network Policies. Kubernetes bietet dabei sogar die Möglichkeit, eigene Admission Controller mit maßgeschneiderter Logik zu erstellen, die bei jeder Erstellung und Manipulation von Kubernetes-Ressource-Objekten anfragen und API-Server-Anfragen abbrechen oder abändern können.
Anwender, die den damit verbundenen manuellen Konfigurationsaufwand scheuen, können auf Werkzeuge wie Red Hat OpenShift oder DevSpace Cloud zurückgreifen. Rancher Labs hat zudem kürzlich ein neues Projekt namens k3v vorgestellt, das es neben der Isolierung mittels Namespaces und Service Accounts ermöglichen soll, virtuelle Cluster auf Basis eines oder sogar mehrerer darunterliegender Kubernetes-Cluster zu erstellen. Das Projekt befindet sich bisher jedoch noch im Status eines Proof of Concept.
