Architektur und Bereitstellung der Anwendungen mit Kubernetes
Wenn man überlegt, wie man seine neu entwickelte Anwendung betreiben möchte, kommt man nicht mehr um Kubernetes herum. Aber was genau bedeutet das und welche Möglichkeiten gibt es, eine Anwendung in Kubernetes zu betreiben?
Kubernetes (kurz K8s, da zwischen dem "K" und dem "s" von Kubernetes 8 Buchstaben sind) wurde im Jahr 2014 von Google entwickelt und als Open Source Projekt veröffentlicht. Es wurde entwickelt, um das Problem der Verwaltung einer Container-Umgebung zu lösen. Kubernetes ermöglicht es Entwicklern, Ihre Anwendungen in einer einheitlichen Art und Weise zu verwalten und bereitzustellen, unabhängig von der Infrastruktur, auf der sie ausgeführt werden.
Wenn man sich entschließt, seine Anwendung in Kubernetes betreiben zu wollen, dann sollte man diese Anwendung auch dementsprechend designen. Unter anderem sollte man die Logs nach stdout schreiben und auf Konfigurationsdateien verzichten. Man sollte lieber Environment Variablen nutzen.
Architektur von Kubernetes
Kubernetes ist nach dem sogenannten Master-Worker Prinzip aufgebaut. Master Nodes, egal ob einer oder mehrere, sind für die Verwaltung der Worker Nodes und Pods im Cluster zuständig, ebenso überwachen die Master Nodes die Pods, prüft ob Scaling Aufgaben nötig sind und ob alle Komponenten “gesund” sind. Auf den Worker Nodes laufen die Anwendungen, die in den Clustern deployed wurden.
Vorteile von Kubernetes
Durch Kubernetes hat man einige Vorteile im Gegensatz zu herkömmlichen Monolith-Anwendungen:
- Dadurch, dass man bei Kubernetes auf Container setzt, benötigt man für den Betrieb der Anwendung deutlich weniger Ressourcen.
- Kubernetes kann das komplette Scaling der Anwendung übernehmen.
- Dadurch, dass Kubernetes komplett Open Source ist, kann man es überall laufen lassen, ganz egal ob in der Cloud oder im eigenen Rechenzentrum, egal ob auf virtuellen Maschinen oder auf Bare Metal Maschinen.
Wie Kubernetes bereitstellen
On Prem
Im eigenen Rechenzentrum gibt es viele verschiedene Möglichkeiten, man kann Suse Rancher nutzen oder alles mit Ansible selber machen. Kubernetes selbst zu betreiben bringt relativ viel Aufwand mit sich, daher ist ein self Hosted Kubernetes eher selten zu empfehlen. Am ehesten, wenn es regulatorische Gründe gibt, weswegen man nicht in die Cloud gehen darf.
Cloud
Alle großen Cloud Provider bieten Managed Kubernetes an:
- Google Cloud: GKE (Google Kubernetes Engine)
- Azure: AKS (Azure Kubernetes Service)
- AWS: EKS (Elastic Kubernetes Service)
Der große Vorteil eines Managed Kubernetes Clusters ist, dass man sich nicht mehr um die Bereitstellung der Nodes kümmern muss. Ebenso bieten die Cloud Provider ein einfaches Tool zum Updaten der Cluster an. Man sollte vor dem Update mit einem Tool wie kube-no-trouble checken, ob man deprecated APIs nutzt, welche in der neuen Version möglicherweise entfernt werden. Man bucht sich eine Controlplane (die Master node), anschließend hat man die Wahl, welchen Modus die Worker Nodes haben. Bei AWS zum Beispiel kann man zwischen EC2 und Fargate Mode wählen. Der Unterschied dieser Modi ist, dass der Fargate Modus ein serverless Ansatz ist. Man hat keine eigenen Server, sondern der eigene Workload läuft auf einem geteilten Server im Hintergrund. Der EC2 Modus erstellt und beendet nach Bedarf automatisch AWS EC2 Instanzen.
Ein weiterer Vorteil von Managed Kubernetes ist die komplette Integration in die Cloud-Landschaft des jeweiligen Providers. Wenn man in einem EKS Cluster einen Kubernetes Service mit dem Typen “LoadBalancer” deployed, bekommt man einen AWS Network Loadbalancer, bei dem Kubernetes Objekt Ingress bekommt man einen Application Load Balancer. Während es bei einem Self-Hosted Kubernetes Cluster sehr aufwändig ist eine hohe Verfügbarkeit und Zuverlässigkeit zu gewährleisten kann man dieses Problem bei den Cloud Providern umgehen, indem man das Cluster in mehrere Availability Zones (AZs) in einer Region bereitstellt.
An dieser Stelle ist man mit der Entscheidung über die Verwendung von Kubernetes (Für & Wider) noch nicht am Ende. Es gilt sich zu überlegen, wie man Kubernetes per se angehen möchte. Will man es selber hosten? Wenn nicht, bei welchem Cloud Provider? Will man die Nodes selber managen oder nur noch seine Ressourcen in Kubernetes definieren? Ich persönlich kann Kubernetes nur empfehlen, da ich es zuvor nicht erlebt habe, wie man eine Containerumgebung so einfach verwalten und skalieren kann. Nicht umsonst ist Kubernetes die Nummer Eins Container-Orchestrierung-Tool!
Habt Ihr schon Erfahrungen damit? Seid ihr zufrieden oder nicht? Kommt gerne
auf mich oder direkt auf ADEAL zu.
Euer Pascal
