Nachhaltige Softwarebereitstellung in Kubernetes

Inhaltsverzeichnis

Nachhaltigkeit in der Softwareentwicklung wird immer wichtiger – insbesondere im Kontext der Anwendungsbereitstellung in der Cloud. Steigende Energiepreise motivieren immer mehr Unternehmen, über nachhaltigere Softwarearchitektur nachzudenken und ihre auf Computing zurückzuführenden CO₂-Emissionen detaillierter zu überwachen.

Im Cloud-Native-Umfeld gibt es immer mehr Werkzeuge und Methoden, um beispielsweise die Nachhaltigkeit einer Software durch nachfrageorientierte, bedarfsgerechte Skalierung zu verbessern. Der Artikel zeigt anhand eines konkreten Fallbeispiels, wie Entwicklerinnen und Entwickler mithilfe der Open-Source-Software Knative eine containerisierte Anwendung in Kubernetes in einen dynamisch skalierbaren Serverless-Dienst überführen können, der sich in Zeiten fehlender Nachfrage sogar komplett abschaltet.

Bedarfsgerecht skalieren für mehr Nachhaltigkeit

Knative basiert auf Kubernetes, das sich als Rückgrat moderner containerisierter Anwendungslandschaften etabliert hat. Kubernetes bietet viele Möglichkeiten zum Automatisieren der Bereitstellung, Skalierung und Verwaltung von Containeranwendungen. Trotz seiner Flexibilität fehlt Kubernetes jedoch die Fähigkeit, Serverless-Anwendungen bereitzustellen. Unter anderem erachtet die Green Software Foundation das zugrunde liegende Bereitstellungsmuster als nachhaltig, bei dem Anwendungen sich basierend auf der aktuellen Nachfrage skalieren und gegebenenfalls auch komplett abschalten lassen.

Soll eine einfache Beispielanwendung aus einem standardmäßigen Kubernetes-Deployment in einen Knative-Service migriert werden, gilt es, die folgenden Qualitätskriterien zu berücksichtigen:

• Die Migration sollte möglichst wenige Anpassungen am Quellcode erfordern. Nur dadurch lässt sich sicherstellen, dass sich größere Anwendungen einfach migrieren lassen, ohne zu hohe Kosten für einen Umbau der Anwendungslandschaft zu verursachen.
• Die in der existierenden Anwendungsumgebung etablierte Praxis für Logging, Monitoring und Tracing sollte weiterhin nutzbar sein. Um eine einfache Migration zu ermöglichen, ist es daher notwendig, die Kompatibilität von Knative mit den vorhandenen Tools sicherzustellen. Das im Folgenden skizzierte Beispiel baut daher auf der weit verbreiteten Monitoringsoftware Prometheus auf.
• Existierende Endpunkte der Beispielanwendung sollen mit Knative nach der Migration unter denselben Routen verfügbar sein. In größeren Anwendungslandschaften sind Routen häufig statische Adressen der Services. Wenn nach einer Migration ein Service plötzlich unter einer anderen URL verfügbar ist, kann dies Probleme verursachen, insbesondere wenn die Kommunikation nicht über ein API-Gateway oder eine Service-Registry entkoppelt ist.
• Das Lastmuster der Beispielanwendung muss längere Zeiträume ausweisen, in denen der Service nicht aufgerufen wird, es also keine Zugriffe durch Nutzerinnen und Nutzer gibt. Nur führt das Herunterskalieren der Anwendung auf null Replikas zu einem nennenswerten Ressourcengewinn.

Die zu migrierende Beispielapplikation besteht aus einem einfachen, zustandslosen Kubernetes-Deployment, das eine REST API über einen Ingress bereitstellt. Der Prometheus-Operator soll die Metriken zur Überwachung der Applikation über die Kubernetes Custom Resource ServiceMonitor erfassen – wie Abbildung 1 verdeutlicht.

Knative: Serverless-Dienste in Kubernetes

Das Open-Source-Projekt Knative zielt darauf ab, Serverless Workloads in Kubernetes auszuführen und zu verwalten. Dazu stellt es Funktionen für die automatische Skalierung bereit – bis hin zu der Fähigkeit, Anwendungen auf null Pods herunterzuskalieren, um den Leerlauf von Pods zu vermeiden. Auch wenn die Ersparnisse pro Anwendung klein sein mögen, summiert sich der Effekt über Tausende von Pods und eine Vielzahl von Anwendungen gerade in großen Clustern. Dabei ist zu beachten, dass Knative nur mit zustandslosen Anwendungen umgehen kann, die ausschließlich über HTTP kommunizieren.

Software effizienter entwickeln und betreiben

Wie Observability, Platform Engineering und andere neue Ansätze Entwicklerinnen und Entwicklern über den gesamten Software Development Lifecycle hinweg zu produktiverem Arbeiten verhelfen, zeigen die Artikel des neuen Sonderheftes iX Developer "Cloud Native".

Um eine Serverless-Laufzeitumgebung innerhalb eines Kubernetes-Clusters zu schaffen, müssen mehrere Komponenten von Knative Serving zusammenarbeiten. Dazu zählen insbesondere Service, Route und Revision:

• Service: Ein Knative-Service definiert eine Serverless-Anwendung und ist daher nicht mit einem Service in Kubernetes zu verwechseln. Beim Anlegen eines Knative-Services wird automatisch eine Route und eine Konfiguration erstellt.
• Route: Sie bestimmt, wie Anfragen an die verschiedenen Revisionen einer Anwendung geleitet werden. Es lässt sich beispielsweise festlegen, dass 90 Prozent der Anfragen an die aktuelle Version der Anwendung und die restlichen 10 Prozent an eine neue Version fließen sollen.
• Revision: Bei jeder Änderung am Knative-Service erstellt Knative eine neue Revision. Jede Revision repräsentiert einen Snapshot des Codes und der zugehörigen Konfiguration.