Sergey Nivens - stock.adobe.com
Die Vor- und Nachteile von verwalteten Kubernetes-Services
Managed Services von Cloud-Anbietern können die Kubernetes-Bereitstellung vereinfachen, in einem Multi-Cloud-Modell aber auch einige Probleme verursachen.
Managed Kubernetes-Services von Public-Cloud-Providern bieten robuste und hochverfügbare Kubernetes-Implementierungen. Diese Dienste integrieren native Funktionen des jeweiligen Cloud-Providers, bieten aber auch spezifische Features für lokale Implementierung. Die Services lassen sich jedoch nicht immer mit den Angeboten anderer Cloud-Anbieter integrieren – zumindest nicht einfach.
Man sollte Managed Kubernetes-Services wie Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE) verwenden, wenn man sich auf einen einzigen Cloud-Anbieter festlegen möchte und alle Orchestrierungsprozesse mit Implementierungen auf der Plattform dieser Anbieter verknüpft. Je mehr Cloud-Lösungen zum Einsatz kommen, desto unwahrscheinlicher ist es, dass ein einzelner verwalteter Kubernetes-Dienst reibungslos funktioniert.
Unternehmen, die sich für die Zusammenarbeit mit mehreren Cloud-Anbietern entscheiden, sollten damit rechnen, dass die Integration von Container-Orchestrierungsaufgaben in einer Multi-Cloud-Bereitstellung schwierig wird.
Um die Vor- und Nachteile eines verwalteten Kubernetes-Dienstes für eine Cloud-Bereitstellung abzuwägen, sollte man folgende drei Schritte ausführen.
1. Bereitstellung planen
Der erste Schritt in jeder Container-Orchestrierungsstrategie ist die Zuordnung des Hosting-Bereichs – also des kompletten Ressourcensets, das Sie für das Hosting von Anwendungen verwenden. Dies kann ein lokales Rechenzentrum und mehrere Public-Cloud-Anbieter umfassen. Bestimmen Sie für jede Anwendung den Umfang ihrer Bereitstellung, einschließlich des Ortes, an dem Sie ihre Komponenten hosten werden. Dies zeigt, wie vielfältig Ihr Kubernetes-Einsatz sein wird.
Gut geplante Kubernetes-Services verfügen über einen Orchestrierungsplan, der zwei Dinge zeigt: Erstens, sie planen nur den Einsatz eines Cloud-Providers ein und sind bereit, bei einem Provider-Wechsel ihre Betriebsstrategie zu überarbeiten. Zweitens führen alle Anwendungen mit Komponenten, die in der Cloud und im Rechenzentrum gehostet werden, wenig bis gar kein Failover oder Bursting über diese Grenze hinaus durch.
Auf der anderen Seite sind schlechte Kandidaten für Managed Kubernetes-Dienste diejenigen, die mehrere Public-Cloud-Anbieter verwenden und Anwendungen schnell zwischen ihnen verschieben wollen. Darüber hinaus sind Unternehmen, die planen, alle Hosting-Ressourcen, einschließlich eines lokalen Rechenzentrums, als großen Ressourcenpool zu nutzen, aus dem Anwendungskomponenten entnommen werden können, für diese Managed-Services nicht gut geeignet.
2. Multi-Cloud-Ziele festlegen
Die meisten Unternehmen fallen irgendwo in die Mitte dieser beiden Extreme. Ist dies der Fall, müssen Sie im nächsten Schritt Ihre Multi-Cloud-Strategie definieren. Stellen Sie fest, ob Sie ein statisches Multi-Cloud-Modell haben – wo Sie Anwendungskomponenten in Hosting-Gruppen von festen Cloud-Anbietern platzieren – oder ein dynamisches Multi-Cloud-Modell – wo sich Komponenten frei über die Plattformen verschiedener Cloud-Anbieter bewegen.
Für diejenigen mit statischen Modell ist die Verwendung eines verwalteten Kubernetes-Dienstes in jeder Ihrer Public Clouds höchstwahrscheinlich gerechtfertigt, aber nur, wenn der Cloud-Provider Kubernetes eng mit einem Tool wie Istio integriert, das Workloads verteilt und verteilte Prozesse verwalten kann. In diesem Fall würde der Einsatz der Tools der einzelnen Cloud Provider wahrscheinlich Ihre Container-Hosting-Funktionen verbessern.
Diejenigen mit einem dynamischen Multi-Cloud-Modell werden jedoch höchstwahrscheinlich nicht von den von Managed Kubernetes-Services der Cloud-Anbieter profitieren. Stattdessen benötigen sie einen übergreifenden Orchestrierungsansatz, der Cloud-Grenzen frei überschreitet. Diese Unternehmen sollten darauf achten, ihre eigene Kubernetes-Orchestrierungsplattform mit Cloud-agnostischen Tools einzusetzen.
3. Sich festlegen
Managed Kubernetes-Services, die in der Cloud gehostete sind, lassen sich nicht mit den nativen Funktionen anderer Cloud-Anbieter integrieren. Das bedeutet, wenn Sie sich in einem Multi-Cloud-Modell auf diese Dienste festlegen, werden Sie sich in den meisten Fällen auch verpflichten, jede Ihrer Public Clouds separat zu orchestrieren.
Wenn Sie eine Softwaredistribution von Kubernetes wählen, wie zum Beispiel Red Hat OpenShift, müssen Sie sowohl Ihre Anwendungen als auch Kubernetes in jeder Ihrer Cloud-Domänen einsetzen. Sie müssen auch die Verfügbarkeit der Kubernetes-Elemente und deren Konnektivität mit den verfügbaren Steuerungs-Tools verwalten.
Ein gemeinsames Multi-Cloud-Framework für Kubernetes ist Stackpoint.io und unterstützt die drei großen Public-Cloud-Anbieter – AWS, Microsoft Azure und Google – sowie On-Premises Deployments. Mit Stackpoint.io können Unternehmen eine universelle, Multi-Cloud-basierte Kubernetes-Steuerungsebene erstellen, die die Bereitstellung vereinheitlicht. Es gibt eine Reihe von kommerziellen Anbietern, darunter DigitalOcean, Red Hat und VMware, die eine Version von Kubernetes und Stackpoint.io im Paket mit Support anbieten.
Denken Sie schließlich an den Support Ihres Cloud-Providers für Container und Kubernetes. Google hat ein starkes Engagement für beides gezeigt, aber der jüngste Führungswechsel bei Google könnte einen Richtungswechsel andeuten.
Microsoft seinerseits scheint ähnlich engagiert wie Google. AWS hat erst spät damit angefangen, verbessert aber kontinuierlich seinen eigenen Container-Hosting- und Orchestrierungsdienst – und sein neues Micro-Virtual-Machine-Angebot Firecracker könnte den Fokus stärker auf VMs setzen.
