Warum Kubernetes in der Cloud nicht so anbieterunabhängig ist, wie es scheint – und was Sie dagegen tun können

F5-Ökosystem | 26. November 2020
kubernetes1

Kubernetes ist eine Open-Source-Plattform. Daher könnte man meinen, dass sie anbieterunabhängig ist und man problemlos von einer Kubernetes-Implementierung zu einer anderen wechseln kann.

Doch damit lägen Sie falsch. Tatsächlich sind viele Kubernetes-Lösungen – insbesondere solche, die an eine bestimmte Public Cloud gebunden sind – weit weniger herstellerunabhängig, als Sie vielleicht denken.

Glücklicherweise bedeutet das nicht, dass Sie die Public Cloud nicht als Kubernetes-Hosting-Lösung nutzen können, wenn Sie einen Lock-in vermeiden möchten. Das ist durchaus möglich, allerdings müssen Sie Ihre Kubernetes-Strategie so gestalten, dass Sie nicht an den Kubernetes-Dienst eines bestimmten Cloud-Anbieters gebunden sind und dennoch die Vorteile von cloudbasiertem Kubernetes nutzen können.

Cloudbasierte Kubernetes-Optionen

Heute bieten alle großen Public-Cloud-Anbieter gehostete Kubernetes-Dienste über eine SaaS-Architektur an. Amazon bietet den Elastic Kubernetes Service, Azure den Azure Kubernetes Service, Google die Google Kubernetes Engine und IBM den IBM Cloud Kubernetes Service.

Da diese Services cloudbasierte Infrastruktur mit Software kombinieren, die die Bereitstellung und Verwaltung von Kubernetes automatisiert, sind sie eine attraktive Lösung für Unternehmen, die Kubernetes schnell in Betrieb nehmen möchten.

Lock-in-Risiken bei Kubernetes in der Cloud

Die Tatsache, dass diese Cloud-Kubernetes-Dienste anbieterunabhängig erscheinen, macht sie zusätzlich attraktiv. Auf den ersten Blick mag es so wirken, als ließe sich problemlos von einer Kubernetes-SaaS-Plattform zu einer anderen wechseln. Alle diese Plattformen basieren auf dem standardmäßigen Open-Source-Kubernetes. Sie bieten Zugriff auf dieselben Kubernetes-Werkzeuge (wie kubectl) und unterstützen im Allgemeinen dieselben Arten von Speicher- und Netzwerkkonfigurationen. Aus dieser Perspektive wirken sie weitgehend anbieterunabhängig.

Bei genauerer Betrachtung stellt man jedoch fest, dass die Public Clouds, die Kubernetes als gehosteten Dienst anbieten, nicht ganz so flexibel und universell sind, wie es zunächst den Anschein hat. Sie sind auf unterschiedliche Weise in andere Dienste der jeweiligen Public Cloud integriert und von ihnen abhängig. Unabhängig davon, welche Cloud Sie zur Verwaltung Ihrer Kubernetes-Cluster verwenden, müssen Sie dort IAM-Richtlinien erstellen. Für die Authentifizierung kommen unter Umständen anbieterspezifische Dienste zum Einsatz, etwa Azure Active Directory beim Azure Kubernetes Service. Zudem gibt es häufig ergänzende oder alternative Tools, deren Verwendung die Kubernetes-Dienste nahelegen, auch wenn sie nicht zwingend vorgeschrieben sind. Google Kubernetes Engine empfiehlt beispielsweise gke-deploy anstelle von kubectl, während Elastic Kubernetes Service für die Verwendung mit eksctl, dem proprietären Tool von Amazon, konzipiert ist.

Der zugrunde liegende Kubernetes-Code mag also unabhängig davon, in welcher Cloud Sie Kubernetes hosten, derselbe sein. Und theoretisch könnten Sie sich mit entsprechendem Aufwand auf allgemeine Tools beschränken. Doch die Tools und Konfigurationen, die Sie letztlich höchstwahrscheinlich verwenden werden, sind nicht herstellerunabhängig. Sie sind auf den jeweils genutzten Kubernetes-Dienst zugeschnitten.

Das stellt eine große Hürde dar, wenn Sie beispielsweise vom Azure Kubernetes Service zur Google Kubernetes Engine wechseln möchten. Selbst wenn Sie Ihre Kubernetes-Workloads per Lift-and-Shift migrieren können, ist dies bei den zugehörigen Toolchains und Konfigurationsdateien nicht möglich.

Vermeiden Sie die Abhängigkeit von einem Cloud-Kubernetes-Anbieter

Wenn Sie bei der Bereitstellung von Kubernetes-Clustern von der Benutzerfreundlichkeit und Skalierbarkeit der Public Cloud profitieren möchten, aber eine Anbieterbindung vermeiden wollen, gibt es zwei grundlegende Lösungen.

Eine Möglichkeit besteht darin, eigene Cluster manuell mithilfe cloudbasierter virtueller Maschinen einzurichten und anschließend selbst zu verwalten. Bei diesem Ansatz stehen Ihnen zwar nicht die Automatisierungsfunktionen und Integrationen der SaaS-Kubernetes-Angebote der Cloud-Anbieter zur Verfügung, wohl aber die Infrastruktur. Da Sie keine spezialisierten Tools verwenden, lassen sich Ihre Cluster leichter von einem Cloud-Host zu einem anderen migrieren, ohne alles neu aufsetzen zu müssen. Der Nachteil besteht natürlich darin, dass die Einrichtung und Verwaltung Ihrer Cluster einen erheblichen manuellen Aufwand erfordert.

Der andere Ansatz – der stärker automatisiert und skalierbar ist – besteht darin, eine Lösung wie den VoltStack® Service von Volterra zu nutzen, um Ihre Cluster unabhängig davon zu verwalten, in welchen Clouds sie sich befinden. Bei dieser Strategie ersetzen Sie im Wesentlichen die Cloud-spezifischen Tools der Plattform jedes Anbieters durch eine zentrale Steuerungszentrale, die mit jeder Public Cloud funktioniert. Dadurch lassen sich Cluster problemlos zwischen verschiedenen Public Clouds migrieren oder replizieren. Sie erhalten dieselben Verwaltungsmöglichkeiten wie bei Diensten wie Google Kubernetes Engine und Azure Kubernetes Engine, ohne an bestimmte Public Clouds gebunden zu sein.

Fazit

Machen Sie nicht den Fehler anzunehmen, Kubernetes sei immer gleich, unabhängig davon, wo oder wie Sie es betreiben. Zwischen den verschiedenen cloudbasierten Kubernetes-Diensten bestehen erhebliche Unterschiede, die die Portabilität von Kubernetes-Clustern von einer Cloud in eine andere beeinträchtigen können. Ganz zu schweigen davon, dass sie die Verwaltung von Clustern in verschiedenen Clouds erschweren, da jede Cloud über andere Tools verfügt.

Die gute Nachricht ist, dass es dafür eine Lösung gibt: Wenn Sie eine Cloud-unabhängige Kubernetes-Managementlösung wie den Dienst VoltStack von Volterra zur Verwaltung all Ihrer Cluster einsetzen, machen Sie sich von einzelnen Cloud-Anbietern unabhängig und profitieren dennoch von der Benutzerfreundlichkeit cloudbasierter Kubernetes-Dienste.

Teilen
Schlagwörter: 2021

Ähnliche Blogbeiträge

F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5-Ökosystem | 05.08.2025

F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen

F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.

API-Sicherheitsrisiken und -herausforderungen
F5-Ökosystem | 21.07.2025

API-Sicherheitsrisiken und -herausforderungen

Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.

Ein Meilenstein für die Community Impact Grants von F5
F5-Ökosystem | 21.01.2025

Ein Meilenstein für die Community Impact Grants von F5

F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.

Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
F5-Ökosystem | 22.05.2023

Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten

Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.

Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
F5-Ökosystem | 16.09.2020

Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff

Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.

Das Internet der Sicherheitsdinge
F5-Ökosystem | 11.05.2015

Das Internet der Sicherheitsdinge

Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...