Kubernetes zur Vermeidung von Cloud Vendor Lock-in

Cloud-Plattformen bieten zahlreiche Vorteile, bergen jedoch auch Risiken – allen voran das Risiko eines Vendor Lock-ins. Kann Kubernetes als Abstraktionsschicht dazu beitragen, diese Abhängigkeiten zu vermeiden?

Verheissungsvolle Cloud mit Risiken

Wenn heute neue Applikationen entwickelt oder bereitgestellt werden, stellt sich unweigerlich die Frage nach der geeigneten Plattform. Cloud-Plattformen bieten sich oft an, da sie flexibel skalierbare Ressourcen zur Verfügung stellen. Auch Anforderungen wie Geo-Redundanz, Datensicherung oder Betriebsverantwortung sind in der Regel bereits integriert (siehe z. B. „5 Essential Characteristics of the Cloud | amtelco“ für eine kurze Einführung).

Die zahlreichen Vorteile gehen jedoch mit nicht zu unterschätzenden Risiken und Nachteilen einher:

• Vendor Lock-in
  Mit der Wahl eines bestimmten Cloud-Anbieters begibt man sich häufig in eine technische Abhängigkeit – etwa durch proprietäre APIs, spezielle Dienste oder Tools zur Ressourcenverwaltung.
• Fehlende Kostentransparenz
  Die Preisstrukturen der Anbieter sind oft komplex und schwer durchschaubar. Erhöht ein Anbieter seine Preise, ist ein Wechsel mit erheblichem Aufwand verbunden.
• Governance-Vorgaben
  Politische Unsicherheiten und gesetzliche Rahmenbedingungen lassen es nicht immer zu, Daten im Ausland zu speichern oder Dienste von Anbietern unter fremdem Einfluss zu nutzen. Änderungen der globalen Lage können zudem Anpassungen der eigenen Governance-Richtlinien erzwingen.

Viele Organisationen stellen sich daher die Frage: Wie lassen sich die Vorteile der Cloud nutzen, ohne sich den genannten Nachteilen auszuliefern?

Kubernetes als Abstraktions-Layer

Eine Lösung liegt in der Nutzung von Kubernetes. Es wurde entwickelt, um containerisierte Anwendungen effizient in verschiedenen Umgebungen zu orchestrieren – ob on-premises, in der Public Cloud oder in hybriden Szenarien. Dabei abstrahiert Kubernetes die zugrunde liegende Infrastruktur, sodass Anwendungen weitgehend unabhängig vom Betreiber laufen können.

Ursprünglich von Google stammend, wird Kubernetes seit einigen Jahren durch die Cloud Native Computing Foundation CNCF weiterentwickelt. Die CNCF ist Bestandteil der Linux Foundation und zählt viele grosse Firmen wie Google, Alibaba, Microsoft, Ericsson, Amazon, VMWare etc. aus Amerika, Europa und Asien zu ihren Mitgliedern. Damit ist sie sehr breit abgestützt und nicht den Entscheidungen einzelner Firmen oder Personen ausgeliefert. Kubernetes hat sich dadurch zum De-Facto Standard für die Container-Orchestrierung etabliert.

Vorteile von Kubernetes

• Plattformunabhängigkeit
  Kubernetes ist auf nahezu allen grossen Cloud-Plattformen, aber auch kleineren, regionaleren Anbietern sowie in eigenen Rechenzentren einsetzbar. Diese Vielseitigkeit ermöglicht es, Anwendungen relativ einfach von einer Umgebung in eine andere zu migrieren, ohne sie grundlegend ändern zu müssen.
• Standardisierte APIs
  Kubernetes bietet ein einheitliches API, unabhängig davon, welche Infrastruktur genutzt wird. Entwickler können sich auf diese Standardisierung verlassen, wodurch die Kompatibilität zwischen verschiedenen Umgebungen erhöht wird.
• Portable Container
  Container-Technologien wie Docker erlauben es, Anwendungen und ihre Abhängigkeiten in einem isolierten Paket bereitzustellen. Kubernetes erweitert diese Portabilität, indem es sicherstellt, dass diese Container überall konsistent betrieben werden können.
• Offene Standards
  Kubernetes basiert auf Open-Source-Technologie und wird von einer grossen Community entwickelt. Durch die Verwendung offener Standards und offener Schnittstellen wird verhindert, dass proprietäre Technologien die Flexibilität einschränken.
• Ökosystem
  Um Kubernetes hat sich ein grosses Ökosystem gebildet. Für zahlreiche Standard-Applikationen wie Datenbanken, Web-Server, Applikations-Server, Backup-Lösungen, Message Broker etc. gibt es Packages, mit welchem diese einfach installiert und aktualisiert werden können.
• Multi-Cloud-Strategien
  Mit Kubernetes können Unternehmen Workloads über mehrere Cloud-Anbieter hinweg verteilen. Dies erhöht nicht nur die Verfügbarkeit, sondern reduziert auch die Abhängigkeit von einem einzigen Anbieter. Es erfolgt entweder durch Verteilen der Workload auf mehrere Cluster bei verschiedenen Anbietern (einfachere Variante) oder durch Bau eines Clusters, welche sich über verschiedene Anbieter erstreckt (kompliziertere Variante).

Herausforderungen von Kubernetes

Nebst der vielen Vorteile bringt der Einsatz von Kubernetes aber auch seine Herausforderungen und Risiken mit sich:

• Komplexität
  Die Konfiguration und der Betrieb eines Kubernetes-Clusters erfordern fundierte Fachkenntnisse. Der Einstieg in das Thema hat eine steile Lernkurve.
• Managementaufwand
  Kubernetes reduziert zwar die Abhängigkeit von Anbietern, erfordert jedoch Aufwand für die Wartung und Aktualisierung der Cluster.
• Kosten
  Die Bereitstellung und der Betrieb eines Kubernetes-Clusters können initial hohe Kosten verursachen, insbesondere wenn die Infrastruktur on-premise betrieben wird.

Optionen zum Betrieb von Kubernetes

Es gibt unterschiedlichste Optionen, um Kubernetes zu betreiben. Die grundlegende Frage ist dabei erst mal, ob man dies an eine Public Cloud outsourcen möchte (und kann) oder ob man es on-premise haben möchte.

Public Cloud

Die einfachste Möglichkeit ist sicherlich, schlüsselfertige Kubernetes-Cluster bei einem globalen Cloud-Anbieter wie AWS, Azure oder auch regionalen Anbieter zu beziehen. Damit sind Setup und Betrieb schon weitgehendst abgedeckt. Dabei müssen aber folgende Punkte beachtet werden:

• Proprietäre Erweiterungen
  Proprietäre Erweiterungen der Anbieter können hilfreich sein, bergen aber wieder die Gefahr, sich in einen Vendor Lock-in zu begeben. Ihre Verwendung sollte daher mit Bedacht entschieden werden.
• Kostentransparenz
  Die Preismodelle der verschiedenen Anbieter sind oft recht komplex und setzen sich aus mehreren Komponenten zusammen. Hier muss man gut hinschauen, sonst kann es rasch teuer werden.

On-Premise

Die andere Möglichkeit ist, Kubernetes selbst zu betreiben und so gänzlich unabhängig zu bleiben. Dieser Weg ist mit mehr Hürden gespickt, bei deren Bewältigung sich in der Praxis folgende Massnahmen bewährt haben:

• Nutzung von Managed Kubernetes-Lösungen
  Einige Anbieter wie Red Hat OpenShift, Rancher oder VMware Tanzu bieten Managed Kubernetes-Lösungen für eigene Umgebungen an. Diese reduzieren den Aufwand für die Installation und Wartung erheblich, indem sie automatische Updates, Monitoring und Sicherheitsfunktionen bereitstellen.
• Verwendung von Kubernetes-Distributionspaketen
  Distributionspakete wie k3s oder MicroK8s sind speziell für einfache und ressourcenschonende Setups konzipiert. Sie eignen sich besonders für kleinere Umgebungen oder Entwicklungszwecke und reduzieren die Einstiegshürden.

Daneben gibt es auch diverse Zwischenlösungen oder auch Mischformen. Was optimal ist, hängt weitgehend von den Rahmenbedingungen der Organisation und den Anforderungen ab.

Generelle Best Practices

Unabhängig von der Art des Clusters sind generell folgende Best Practices empfehlenswert:

• Automatisierung mit Infrastructure-as-Code
  Tools wie Terraform, Ansible und Helm können genutzt werden, um die Bereitstellung und Konfiguration des Clusters zu automatisieren. Dadurch werden manuelle Fehler minimiert und die Wiederholbarkeit der Deployment-Prozesse verbessert.
• Monitoring und Logging
  Tools wie Prometheus, Grafana oder ELK-Stack können helfen, die Performance und Verfügbarkeit des Clusters zu überwachen. Eine frühzeitige Problemerkennung reduziert den Wartungsaufwand.
• Training und Zertifizierung
  Investitionen in Schulungen und Zertifizierungen wie die Certified Kubernetes Administrator (CKA) helfen dem IT-Team, die notwendigen Kenntnisse für die Verwaltung eines Kubernetes-Clusters aufzubauen.
• Sicherheitsrichtlinien (Hardening)
  Durch die Implementierung bewährter Sicherheitspraktiken, wie die Minimierung von Root-Rechten oder die Verwendung von Network Policies, lässt sich der Verwaltungsaufwand langfristig verringern.

Deployment von Applikationen

Hat man erst mal eine Kubernetes-Umgebung bereit, können nun die Applikationen bereitgestellt werden. Dafür erfüllen sie idealerweise über gewisse Voraussetzungen wie Zustandslosigkeit, Logging auf die Standard-Ausgaben, flexible Konfigurierbarkeit via Umgebungsvariablen oder Konfigurations-Dateien und Endpunkte für Health-Checks. Mit Frameworks wie Quarkus, .Net oder SpringBoot erstellte Web-Applikationen bringen diese Eigenschaften in der Regel schon mit.

Das eigentliche Deployment geschieht üblicherweise in folgenden Schritten:

1. Containerisierung der Applikation
   Die einzelnen Bestandteile der Applikation werden in Images gepackt und in einer Image Registry abgelegt. Die Images enthalten die ausführbaren Dateien inklusive Bibliotheken und allfälliger Laufzeitumgebungen.
2. Deployment-Manifest erstellen
   Mittels Manifests in der Form von YAML-Dateien wird Kubernetes mitgeteilt, wie die Images als Container deployed werden sollen. Es beschreibt auch, was wo persistiert wird und wie die Container untereinander oder mit der Aussenwelt kommunizieren dürfen. Oft werden diese Manifeste in konfigurierbaren Helm Charts bereitgestellt. Für sehr viele Standard-Applikation stehen bereits solche Charts zur Verfügung und können in eigene eingebunden werden.
3. Installation der Charts
   Die Charts können nun in ein oder mehreren Kubernetes Cluster (z. B. pro Stage) installiert werden. Um ein sauberes Konfigurations-Management zu gewährleisten bietet sich der GitOps-Ansatz an. Dabei wird die gesamte Konfiguration in git verwaltet und durch Tools wie ArgoCD oder Flux in die Cluster synchronisiert.

Idealerweise wird gleich die CI/CD-Pipe entsprechend aufgebaut:

Allfällige Migration in einen anderen Cluster

Durch das oben beschriebene Deployment wurde nun also die Applikation «Kubernetes-Ready» gemacht. Unabhängig vom Cluster verrichtet die Orchestrierung ihre Arbeit und koordiniert das Zusammenspiel zwischen den Containern. Sie stellt auch Storage- und Netzwerkressourcen bereit.

Sofern man sich an Standards gehalten hat und nicht den Verlockungen von proprietären Erweiterungen erlegen ist, lässt sich eine Applikation durch wenige Anpassungen in einen anderen Kubernetes-Cluster migrieren. Üblicherweise sind das:

• Storage-Klassen
  Die Storage Klassen beschreiben, wie dynamisch bereitgestellter Speicher erstellt werden soll. Je nach Anbieter können hier die Möglichkeiten unterschiedlich sein.
• Ingress
  Ein Ingress ist eine Kubernetes-Ressource, die Regeln für den externen Zugriff auf Dienste innerhalb eines Clusters über HTTP/HTTPS definiert. Sie fungiert als Reverse Proxy und ermöglicht z. B. Pfad- oder Host-basiertes Routing zu internen Services. Hier kann es Unterschied geben, was die Infrastruktur des Anbieters zur Verfügung stellt.
• Public IPs
  Sollte die Applikation gewisse Service direkt über Public IP Adressen bereitstellen, kann es auch hier notwendig sein, geringe Anpassungen vorzunehmen.

Diese Anpassungen erfolgen entweder direkt im GitOps-Repo, durch Neuinstallation von Charts mit geänderten Parametern oder durch Backup/Restore mit Mapping durch ein Tool wie z.B. Velero. Sie beschränken sich meist auf einzelne Zeilen.

Der zusätzliche Aufwand macht sich also bezahlt, in dem man so eine gewisse Unabhängigkeit geniesst und nicht auf Gedeih und Verderb einem Anbieter ausgeliefert ist.

Fazit

Kubernetes stellt eine leistungsfähige Abstraktionsschicht, um Risiken wie Vendor Lock-in zu vermeiden. Durch die Plattformunabhängigkeit, Standardisierung und Portabilität können Unternehmen flexibel bleiben und ihre IT-Strategie an wechselnde Anforderungen anpassen.

Allerdings sollte die Einführung von Kubernetes gut überlegt sein und geplant werden, um die damit verbundenen Herausforderungen erfolgreich zu meistern. Dabei gilt es stets, sich möglichst an die Standards zu halten und Kompromisse nur bewusst einzugehen. Organisationen, welche diese Hürden überwinden, profitieren aber langfristig von einer grösseren Unabhängigkeit in einer sich rasch ändernden Welt mit wechselnden Allianzen.