Mein Kubernetes ist da!
Du hast Dich für ein Managed Kubernetes entschieden? Herzlich Glückwunsch! Jetzt kann die Zukunft losgehen.
Mit einem Managed Kubernetes ist es am Anfang wie mit einer neuen Cloud-Umgebung: Es ist aufregend, ohne Frage. Die Anbindung und Einrichtung muss trotzdem gut geplant werden. Hier kommt nämlich die Magie zum Einsatz, die sich so viele wünschen.
Im folgenden Artikel listen wir einmal die wichtigsten Arbeitsbereiche für die grundlegende Einrichtung auf, die auf einen Besitzer einer Kubernetes-Umgebung zukommen können.
Das umfasst
- Das Netzwerk
- Das Storage Management
- die Nutzung von Proxies
Wir gehen davon aus, dass Du bereits Deine eigenen Anwendungen als Docker-Images vorliegen hast und über die Integration in einen Kubernetes-Cluster nachdenkst.
Die gesamte Infrastruktur ist automatisch – aber was heißt das genau?
Bei einem Managed Kubernetes werden meist drei wichtige Komponenten ausgeliefert, die für eine Integration oder sogar Migration Deiner Anwendungen grundlegend wichtig sind. Sie werden durch ihre eigenen Schnittstellen von Kubernetes verwaltet.
Cloud Native Network
Cloud Native Network in Kombination mit Coordination & Service Discovery gibt Dir ein Tool, welches die interne Erreichbarkeit Deiner Anwendungen gewährleistet. Dafür müssen zunächst folgende Fragen beantwortet sein:
- Wie teile ich meine Anwendungen auf? Sollen sie alle im gleichen Netzwerk (z. B. einem Namespace) erstellt werden? Benötige ich eine Trennung zwischen meiner Entwicklungs- und Produktionsumgebung?
- Welche Namensvergabe ist für mich sinnvoll? Erhalten Anwendungen feste Namen (definiert über sogenannte Services) oder regle ich das über eine eigene Service Discovery auf Applikationsebene?
- Welche Bestandteile möchte ich später von außen erreichbar gestalten? Wie viel Sicherheit benötige ich dafür? Müssen die Zugriffe noch zusätzlich abgesichert werden?
- Wie möchte ich meine Anwendungen beschränken? Dürfen diese auf alle externen Ressourcen zugreifen?
Aus den Fragen ergeben sich dann die ersten Aufwände im Bereich der Konfiguration Deiner Anwendung. Besonders die Service Discovery kann, richtig benutzt, viel Arbeit abnehmen. Es kann sogar selektiv eingestellt werden, welche Anwendungen von außen erreicht werden können und welche Container nach außen kommunizieren dürfen. Hier empfiehlt es sich, genau über sogenannte Ingress- und Egress-Routen Bescheid zu wissen.
Cloud Native Storage
Cloud Native Storage wiederum benötigt zur Nutzung nicht viele Fragestellung:
- Muss ich die Daten meiner Anwendung für Neustarts vorhalten? Wenn ja, warum eigentlich?
- Dürfen die Daten nur innerhalb meines Kubernetes-Clusters existieren?
- Welches Backup-Verhalten benötigt jede Anwendung dafür?
Daraus ergeben sich wiederum einige Aufgaben. Kubernetes als System erzwingt den flüchtigen Zustand, wo es nur geht. Deswegen sollten so wenige Anwendungskomponenten wie möglich von einem persistenten Zustand ausgehen.
Danach sollte aus der zweiten Frage die Anforderung abgeleitet werden, ob dateiabhängige Systeme (z. B. Datenbanken) außerhalb des Kubernetes-Clusters sicherer aufgehoben werden können oder nicht.
Schlussendlich ist die Frage des Backups- und Recovery-Prinzips die Wichtigste, denn sie bestimmt, wie Du eventuelle Ausfälle am Besten meisterst. Kleiner Tipp: Sei so generisch wie möglich, damit sich die entstehenden Prozesse beispielsweise auch in einer späteren CI/CD-Pipeline wiederfinden können.
Service Proxy
Die letzte grundlegende Komponente, der Service Proxy, bestimmt vor allem die externe Erreichbarkeit. Diese Komponente wirft einige Fragen auf:
- Welche Dienste müssen erreichbar sein? Sind es webbasierte Ingress-Dienste?
- Benutzen diese Dienste HTTPS oder existieren auch andere TCP- oder UDP-Protokolle?
- Wie gestaltet sich der Zugriff? Benötige ich bereits im Proxy-Verhalten Sicherheitsmechanismen, wie nutzerbasierte Authentifizierung o.ä.?
Der Service Proxy ist stark abhängig von den Ingress-Einstellungen, die Du bereits im Cloud Native Network definiert hast. Sie ist auch eine der ersten Zusatzkomponenten, die Dir bis zum Optimum viel Arbeit abverlangen kann. Gleichzeitig ist sie auch eine der besten Varianten, um Dir auf lange Sicht diese Arbeit abzunehmen und zu automatisieren. Deswegen sind die aufkommenden Aufgaben hier schon sehr individuell und hängen vom Identity-Management und der gesamten Systemarchitektur Deiner Applikation ab.
Es gibt auch die Möglichkeit über sogenannte Floating-IPs die LoadBalancer-Ressource zu nutzen, die besonders bei den Protokollen sinnvoll sein kann, die nicht HTTPS benutzen.
Wenn all die Fragen beantwortet und technisch definiert sind, fehlen “nur” noch die Kubernetes-Ressourcen um Deine Docker-Images mit den entsprechenden Spezifikationen starten zu können.
Getreu dem Motto “It’s something ¯\_(ツ)_/¯” hast Du jetzt endlich eine lauffähige Anwendung in Deiner Kubernetes-Umgebung!
Jetzt kann man sich auf die nächsten Themen stürzen, die Kubernetes einem bereits auf dem Silbertablett präsentiert. Wenn man einmal mit dem Code Refactoring begonnen hat, kommen schnell Wünsche nach weiterer Unterstützung auf.
Spannend sind vor allem die Themengebiete von Orchestration & Management, CI/CD, Streaming & Messaging oder auch des API Gateways. Die vollständige Liste von Möglichkeiten sind auf der Seite der Cloud Native Computing Foundation zu finden.
Aber eins nach dem anderen. Die Themen behandeln wir gern in einem anderen Blog-Eintrag 🙂
Viel Spaß beim Basteln!
Dein SysEleven Team
PS: Wenn Du Fragen dazu hast, dann kannst Du uns gern eine Mail schreiben, einen Beratungstermin buchen oder ein Kommentar hinterlassen.
PPS: Stay safe and healthy.
