Ist meine Applikation für Kubernetes geeignet?

Um die Frage im Titel zu beantworten, ist es notwendig, die spezifischen Anforderungen Ihrer Anwendung sowie die Stärken und möglichen Herausforderungen von Kubernetes zu verstehen.

In diesem Artikel beleuchte ich die Grundlagen von Kubernetes und bewerte die Kompatibilität von Anwendungen mit Kubernetes, die technischen Voraussetzungen und die Szenarien, in denen eine alternative Lösung besser passend sein könnte. Unabhängig davon, ob Sie ein Startup sind, das grundlegende Infrastrukturentscheidungen trifft, oder ein etabliertes Unternehmen, das eine Umstellung in Betracht zieht, wird dieser Leitfaden sowohl die architektonischen als auch die infrastrukturellen Anforderungen der Anwendung hervorheben, damit Sie alle Vorzüge von Kubernetes nutzen können.

Was Kubernetes ist und was es nicht ist

Kubernetes ist eine Open-Source-Plattform, die die Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen standardisiert und automatisiert. Zu seinen zentralen Funktionen gehören:

• Rollouts und Rollbacks: Es ermöglicht das stufenweise Ausrollen von Änderungen an einem Dienst oder das Zurücksetzen zu einer früheren Version, falls Probleme auftreten.
• Service Discovery und Load Balancing: Der Datenverkehr wird automatisch erkannt und je nach Notwendigkeit oder Konfiguration an die entsprechenden Container weitergeleitet.
• Skalierung: Sie erlaubt die automatische oder manuelle Skalierung von Diensten, so dass die Anwendungen eine höhere Last bewältigen können.
• Zustandsüberwachung und Selbstheilung: Es hat eingebaute Mechanismen zur Überprüfung des Zustands von Diensten und zum Neustart ausgefallener Container, wodurch eine hohe Verfügbarkeit sichergestellt wird.
• Konfigurations- und Geheimhaltungsmanagement: Es verwaltet Konfigurationsdaten und Geheimnisse, ohne sie unbefugten Personen oder Anwendungen zugänglich zu machen.
• Ressourcenmanagement und -planung: Dieser Aspekt bestimmt, welcher Knoten einen bestimmten Container auf der Grundlage von Ressourcenverfügbarkeit, Beschränkungen oder Affinitäten ausführt.
• Netzwerkkonfiguration: Diese Funktion erstellt und verwaltet ein privates Netzwerk für Container und stellt sicher, dass diese sicher kommunizieren können.

Das ist Kubernetes NICHT:

• Eine Virtualisierungsplattform - Kubernetes orchestriert Container, nicht virtuelle Maschinen.
• Eine Platform-as-a-Service (PaaS) per se, es dient jedoch als Motor für viele PaaS von verschiedenen Cloud-Anbietern.
• Nicht ausschließlich Cloud-nativ - Kubernetes kann vor Ort, in einer Cloud oder in hybriden Szenarien eingesetzt werden.

Vorteile von Kubernetes

• Open Source.
• Plattformunabhängig.
• Es sind viele Distributionen verfügbar, die für verschiedene Anwendungsszenarien konzipiert wurden, z. B. für Cloud, On-Premises und Edge-Computing.
• Viele Anbieter offerieren verwaltetes Kubernetes als PaaS.
• Hochverfügbar.
• Autoskalierbar und selbstheilend.
• Das Kubernetes-Ökosystem umfasst Hunderte von Tools und Erweiterungen, und ständig werden neue entwickelt. Viele von ihnen sind Open Source und auf der CNCF-Landschaftsseite gelistet.

Anforderungen für den Betrieb von Anwendungen in Kubernetes

Es wird oft behauptet, dass eine Anwendung einer Microservices-Architektur folgen muss, um mit Kubernetes kompatibel zu sein. Das ist nicht wahr. Zwar sind Microservices in der Regel weniger komplex in der Anpassung für die Cluster-Bereitstellung, aber eine monolithische Anwendung kann effizient in einem Kubernetes-Cluster funktionieren, wenn sie containerisiert ist und den in diesem Artikel beschriebenen Richtlinien folgt.

Was versteht man unter der Containerisierung einer Anwendung?

Containerisierung ist eine Technologie, die es ermöglicht, Anwendungen zusammen mit allen notwendigen Tools und Bibliotheken zu paketieren, damit sie korrekt funktionieren können. Sie ermöglicht auch die Isolation dieser Anwendungen von anderen Containern und Prozessen. Container-Images können in eine Container-Registry hochgeladen werden, um dann in einem Cluster bereitgestellt oder in eine lokale Entwicklungsumgebung heruntergeladen zu werden.

Zwölf-Faktor-App-Methodik: Ideal für Kubernetes

Die Zwölf-Faktoren-Methode (auch als 12-Faktoren-Methode bekannt) wurde einige Jahre vor der Standardisierung von Containern entwickelt. Dennoch ist sie ein ausgezeichneter Leitfaden für die besten Praktiken, die für eine effiziente Bereitstellung und den Betrieb einer Anwendung auf Kubernetes zu befolgen sind. Im Folgenden erläutern wir, was es bedeutet, die 12 Faktoren in Bezug auf Container und Kubernetes zu berücksichtigen:

1. Codebasis: Es sollte eine 1:1-Beziehung zwischen der Codebasis und der Anwendung existieren. Mit anderen Worten, die Anwendung muss erstellt und in ein Container-Image mit allen Abhängigkeiten und Systembibliotheken gepackt, in eine Container-Image-Registry gepusht und in einem Cluster bereitgestellt werden.

1. Abhängigkeiten: Die meisten Programmiersprachen oder Anwendungs-Frameworks verfügen über einen Paketmanager, der während des Container-Build-Prozesses zum Herunterladen von Abhängigkeiten genutzt werden sollte. Dies trifft auch auf bestimmte Systembibliotheken oder -tools zu, die entweder über ein Basis-Container-Image, das sie bereits enthält, oder während des Builds installiert werden können.
2. Konfiguration: Anwendungseinstellungen, die zwischen verschiedenen Phasen oder Umgebungen variieren, sollten nicht fest kodiert sein (z. B. ein Datenbank-Hostname). Zu diesem Zweck nutzt Kubernetes ConfigMaps, um Text oder Schlüssel-Wert-Paare zu speichern. Die ConfigMaps können einer Anwendung entweder über Systemumgebungsvariablen oder Dateien zur Verfügung gestellt werden.
3. Backing-Dienste: Die Anwendung muss Backing-Dienste so nutzen, dass ihre Ersetzung keine Änderungen am Anwendungscode erfordert. Beispielsweise darf die URL für die Datenbankverbindung nicht im Anwendungscode eingebettet sein, sondern muss z. B. in einer Konfigurationsdatei stehen. Das Ersetzen eines selbst gehosteten MySQL-Servers durch einen in der Cloud verwalteten Server erfordert also keine Änderungen am Code. Das Gleiche gilt für alle externen APIs, mit denen die Anwendung kommuniziert. Eine solche Konfiguration kann pro Umgebung mit ConfigMaps verwaltet werden, die als Umgebungsvariablen in Container injiziert oder als Volumes gemountet werden können. Alle Passwörter oder geheimen Schlüssel müssen als Kubernetes-Secrets gespeichert werden und dürfen niemals im Klartext in einem Code-Repository aufbewahrt werden. Im Kubernetes-Ökosystem unterstützen viele Tools die Verwaltung von Secrets.
4. Erstellen, freigeben, ausführen: Erstellung, Freigabe und Ausführung sollten getrennte Prozesse sein. Für Build und Deployment kann sogar ein unterschiedliches Tool verwendet werden. Der erste Faktor beschreibt bereits ein Build-Beispiel. Für die Verwaltung von Deployments empfehle ich den GitOps-Ansatz, bei dem der Cluster den im Cluster-Statuscode-Repository deklarierten Zustand der Anwendung verwaltet.

1. Prozesse: Eine Anwendung muss einen oder mehrere zustandslose Prozesse ausführen. Jegliche dauerhafte Daten müssen in Backing-Diensten gespeichert sein. Das bedeutet, persistierte Daten liegen in einer speziellen Datenbank, gemeinsamer Cache in einem schnellen Speicher (wie beispielsweise Redis oder Memcache), und Mediendateien in einem Dateispeicher (etwa S3-kompatibel, NFS oder Ceph).
2. Port-Bindung: Abhängig vom Anwendungsfall sollte eine Anwendung auf einem App-Server betrieben werden, der entweder für das öffentliche Internet oder intern innerhalb des Clusters zugänglich ist.

1. Gleichzeitigkeit: Eine Applikation sollte im Multiprozessmodell operieren, um eine automatische Skalierung durch Kubernetes basierend auf verfügbaren Ressourcen und tatsächlichem Bedarf zu ermöglichen. Es ist essentiell, dass die Applikation schnell hochfährt, um eine effektive automatische Skalierung sicherzustellen.
2. Entsorgbarkeit: Ein geplantes oder unerwartetes Herunterfahren der Applikation sollte keine Beschädigungen oder Nebenwirkungen hervorrufen. Graceful Shutdowns garantieren eine durchgehende Verfügbarkeit, unabhängig davon, ob die Applikation heruntergefahren wird.
3. Parität zwischen Entwicklung und Produktion: Die Entwicklerversion einer Applikation, einschließlich der ihr zugrunde liegenden Dienste, sollte der Produktionsversion so ähnlich wie möglich sein. Dank der Verwendung von Containern ist die Einrichtung wesentlich weniger komplex als die Installation des gesamten Software-Stacks auf einem lokalen Rechner.
4. Protokolle: Das Speichern von Protokollen an ihren Standardspeicherorten, wenn eine Applikation im großen Stil betrieben wird, macht eine Analyse oder Fehlerbehebung nahezu unmöglich. Daher sollten sämtliche Protokolle an die Standardausgabeströme (stdout und stderr) umgeleitet werden. Auf diese Weise können Tools wie Fluentd oder Promtail alle Protokolle für die weitere Verarbeitung sammeln.
5. Verwaltungsprozesse: Administrative Prozesse, die gelegentlich durchgeführt werden müssen, um die Applikation im gewünschten Zustand zu halten, sollten nicht vom Applikationsserver selbst ausgeführt werden. Andernfalls könnten doppelte Operationen und Race-Condition Probleme verursachen. Solche Prozesse sollten stattdessen als Kubernetes CronJob oder Job unter Verwendung der gleichen Version des Applikationscontainer-Images durchgeführt werden.

Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)

Obwohl CI/CD-Prozesse für die Bereitstellung einer Anwendung in Kubernetes nicht unbedingt erforderlich sind, bieten sie erhebliche Vorteile. Sie helfen dabei, den Bereitstellungsprozess zu rationalisieren und zu automatisieren, und verhindern die Bereitstellung von ungeprüften Versionen einer Anwendung.

Abwärtskompatibilität Ihrer Applikation

Rückwärtskompatible Modifikationen sollten schrittweise implementiert und auf zwei oder mehr aufeinanderfolgende Ausgaben verteilt werden. Zum Beispiel, wenn ein Funktionsupdate veröffentlicht wird, das von einer neuen Datenquelle (wie einer anderen Tabelle in der Datenbank) abhängt, sollte die alte Datenquelle nicht in derselben Release-Version gelöscht werden. Dies gewährleistet keine Ausfallzeiten bei Rolling-Deployment oder Canary-Deployment, bei der eine Gruppe von Benutzern die neue Version und eine andere Gruppe die vorherige Version für eine bestimmte Zeit erhält.

Szenarien, in denen Kubernetes weniger geeignet ist

Minimale Größe und Infrastrukturkosten

Für eine unkomplizierte Webanwendung oder einen Backend-Service, der keine Skalierung erfordert, ist Kubernetes übertrieben komplex. Die Kontrollebene von Kubernetes kann mehr Ressourcen beanspruchen als die Anwendung selbst. In solch einem Szenario ist ein einfaches verwaltetes Hosting oder eine serverlose Plattform wesentlich kostengünstiger und schneller zu implementieren.

Fehlende DevOps-qualifizierte Person oder Team

Die sichere und effektive Konfiguration einer Kubernetes-Umgebung und das Einrichten von Anwendungsbereitstellungen erfordern Expertenwissen. Daher ist ein bestimmtes Budget nötig, um eine solche Person einzustellen oder die Aufgabe an eine externe Agentur wie Kiwee zu delegieren.

Verwaltete oder unverwaltete Kubernetes-Variante

Managed Kubernetes bedeutet, dass die Cloud-Plattform die sogenannte Control Plane vollständig verwaltet. Die Control Plane ist ein Begriff für die Softwarekomponenten, die dafür verantwortlich sind, einen Kubernetes-Cluster und alle im Cluster laufenden Arbeitslasten betriebsbereit zu halten. Einige Anbieter bieten zudem automatische Aktualisierungen der Clusterknoten an. Dies ist zwar mit zusätzlichen Kosten verbunden, spart aber viel Zeit der DevOps-Ingenieure. Daher ist es für die meisten Anwendungsfälle eine kostenoptimale Lösung.

Zusammenfassung

Kubernetes ist definitiv eine Überlegung wert, wenn Ihre Anwendung einer Microservices-Architektur folgt oder wenn Sie eine skalierbare, containerisierte monolithische Anwendung haben, die die Zwölf-Faktoren-Methode implementiert hat.

Ist Ihre Anwendung klein und verbraucht wenig Ressourcen oder steht Skalierbarkeit nicht im Vordergrund, ist Kubernetes wahrscheinlich keine gute Wahl.

Die Migration einer Legacy-Anwendung auf Kubernetes kann in Betracht gezogen werden, ist aber oft ein komplexer Prozess, der eine gründliche Modernisierung der Anwendung erfordert. Bei Kiwee beginnen wir diesen Prozess mit einer Reihe von Workshops, in denen wir jeden Aspekt der Anwendung untersuchen und ihre Architektur skizzieren. So können wir die Arbeit planen, um die modernisierten Funktionen iterativ bereitzustellen.

Für eCommerce-Projekte, die auf den Plattformen Magento oder Shopware basieren, haben wir bereits eine vorkonfigurierte Lösung, um diese Plattformen in der Cloud auf Kubernetes bereitzustellen.

Die Modernisierung führt letztlich zu niedrigeren Wartungskosten dank moderner Technologien und Automatisierung. Auch die Entwickler haben mehr Lust, mit neuen Technologien an neuen Dingen zu arbeiten!

• cloud
• Kubernetes