Kubernetes aus der Cloud
Das Steuer übergeben
Kubernetes ist keine Software, die man startet und die dann einfach läuft. Einige Anbieter wollen den Kunden aber das Komplizierte abnehmen und bieten Cluster entweder direkt aus der Cloud oder als Managed Service.
Strenggenommen kommt Kubernetes nach wie vor von Google, obwohl inzwischen viele weitere Firmen wichtige Beiträge liefern. Der Suchmaschinen- und Cloud-Betreiber war naheliegenderweise der erste, der ein kommerzielles Angebot rund um die Container-Orchestrierung strickte. Die Mitbewerber schienen zum Teil große Schwierigkeiten zu haben, Cluster für ihre Kunden aufzubauen. Erst Mitte 2018 erklärten die wichtigsten Konkurrenten, Amazon und Microsoft, ihre Kubernetes-Angebote für allgemein verfügbar. Aber auch kleinere Cloud-Provider versuchen auf der Welle mitzuschwimmen und gingen mit ähnlichen Angeboten an den Markt – teilweise noch nicht ganz ausgereift: als Beta oder Preview.
Containerisierung bringt etliche Vorteile in der Anwendungsentwicklung. Nicht zuletzt, weil die Ergebnisse sich gut migrieren lassen – dieses Versprechen hatten bereits virtuelle Maschinen gegeben, Container erreichen dies tatsächlich. Trotzdem führen nur wenige Unternehmen einen kompletten Umzug durch. In der Regel behalten sie weiterhin Legacy-Systeme oder Applikationen, die sich nicht ohne weiteres in Microservices umwandeln lassen – und deswegen keine Kandidaten für einen containerisierten Betrieb sind. Oft laufen diese schon in der einen oder anderen Cloud. Dass Entwickler zunehmend auf Microservices setzen, zwingt die Provider, ihr Angebot auszubauen, wollen sie ihre Kunden behalten. So kommt es, dass bereits früh die Open Telekom Cloud ihre Cloud Container Engine gestartet und IBM Docker und Kubernetes auch für Power und seine Mainframes mit IBM-Z-Prozessoren migriert hat.
Natürlich könnten die Unternehmen selbst Kubernetes auf ihren Cloud-Instanzen installieren, doch der Aufwand ist vergleichsweise hoch und noch herrscht kein Überschuss an Fachkräften für Kubernetes. Das Know-how ist unter Umständen nur schwer zu beschaffen.
Etliche Dienstleister spezialisieren sich deshalb darauf, in beliebigen Clouds Kubernetes oder darauf basierende Produkte einzurichten. Da der Container-Orchestrierer beispielsweise oft innerhalb einer CI/CD-Umgebung verwendet wird, bietet Red Hat seit kurzem OpenShift Dedicated on Azure. In Deutschland haben sich die Start-ups Giant Swarm und Loodse darauf spezialisiert, Kubernetes in verschiedenen Clouds zu betreiben. Beide setzen dafür auf ein verschachteltes System, haben aber eindeutig unterschiedliche Zielgruppen und Servicemodelle.
Kleinere Unternehmen benötigen eventuell nicht die Performance der großen Cloud-Provider und können sich auch vorstellen, von einem kleineren Anbieter Kubernetes as a Service zu beziehen. In einem überschaubaren Rahmen mit nur einigen Knoten bieten das mittlerweile immer mehr Anbieter. 1&1 etwa hat inzwischen die Betaphase seiner Container as a Service abgeschlossen, DigitalOcean hat im Mai 2018 ein vergleichbares Programm begonnen.
Grob unterteilt sich das Angebot in drei Stufen. Bei Kubernetes as a Service bieten Provider ein fertiges System aus der Cloud, das Kunden direkt über die API ansprechen können. Sind die Bedürfnisse spezieller, springen Anbieter für Managed Kubernetes ein, die als externe Dienstleister den Betrieb der Kubernetes-Cluster übernehmen. Mehr Gestaltungsspielraum bei mehr eigener Verantwortung bieten Kubernetes-Scheduler oder -Installer, die den Cluster-Betrieb zu großen Teilen automatisieren. Dieser Artikel gibt einen Überblick über den Markt für diese drei Arten, Kubernetes zu verkaufen.
Google Kubernetes Engine
Google hatte Kubernetes ursprünglich aus der Taufe gehoben – einige Dienste des Suchmaschinenbetreibers laufen tatsächlich darauf. Der Container-Orchestrator ist Googles Borg nachempfunden, das der Konzern auch weiterhin für den Großteil seiner Infrastruktur verwendet. Letztlich ist Kubernetes eine abgespeckte Variante seines Vorbilds und hat von dort etwa das Konzept der Pods und die Services übernommen – allerdings mit dem expliziten Ziel, Containerverwaltung an Kunden weitergeben zu können.
Nutzern stellt sich Googles Kubernetes Engine (GKE) wie eine lokale Installation dar. Ist ein GKE-Cluster verfügbar, lassen sich Anwendungen beispielsweise einfach per kubectl, API oder HTTP/gRPC ansprechen und verwalten. Den Cluster steuert man über die Kubernetes Engine API oder das Kommandozeilenwerkzeug gcloud – wie die restlichen Funktionen der Google Cloud.
Bezahlen lässt sich Google lediglich die Worker Nodes, auf denen später die Pods und Deployments tatsächlich laufen. Master-Knoten gibt es nicht explizit, die API ist Teil der GKE. Da die Kunden die Nodes selbst verwalten, sind sie nicht Bestandteil des Service-Level-Agreements (SLA). Darin garantiert Google eine monatliche Uptime von 99,5 Prozent lediglich für die API.
Auf den Nodes läuft standardmäßig Googles Container-Optimized OS: ein Linux mit angepasstem Kernel, Cloud-Init zur Provisionierung, Docker, Kubernetes sowie Tools zum Einbinden in Googles Cloud. Auf expliziten Wunsch lässt sich auch Ubuntu installieren, das beispielsweise GlusterFS oder CephFS beherrscht. Auch heterogene Cluster sind möglich. Nutzer legen dafür Node-Pools aus gleichartigen Instanzen an, auf die die Kubernetes-Master die Jobs verteilen.
Weitere Hyperscaler
Mit dem Aufstieg von Kubernetes und immer höherer Adaption auch im Produktivbetrieb gerieten Microsoft und Amazon in Zugzwang, mit Google Schritt zu halten. Die immer größere Verbreitung von Microservices und das Heranwachsen von Kubernetes zum De-facto-Standard in der Microservice-Orchestrierung sind gerade für die großen Cloud-Betreiber zentrale wirtschaftliche Faktoren. Gleichzeitig haben auch Nutzer der großen Clouds Interesse daran, dort, wo sie bereits Infrastruktur besitzen, ihre Microservices laufen lassen zu können.