Der Inhalt entscheidet

von Thomas Drilling

Kubernetes stellt viele fortschrittliche Funktionen wie Namespaces für Applikationen oder Rolling Releases ohne Wartungsfenster zur Verfügung. Doch benötigen IT-Verantwortliche für das Einrichten und den Betrieb im eigenen Rechenzentrum umfangreiches Fachwissen. Alternativ lässt sich gehostetes Kubernetes in der Public Cloud nutzen. Das haben Google, Microsoft und AWS mit unterschiedlichen Stärken und Schwächen im Angebot.

AWS, Google und Microsoft haben vorgefertigte Services für Kubernetes im Portfolio, mit deren Hilfe IT-Verantwortliche verteilte, Containerbasierte Anwendungen betreiben können. Hier haben Sie auch den Vorteil im Boot, dass die Applikationen ohne großen Aufwand über eine öffentliche IP-Adresse verfügbar sind und sich die Knotenzahl der Cluster je nach Lastsituation nahezu beliebig um Compute-Ressourcen erweitern lässt. Dank Elastizität und Autoscaling klappt das auch automatisch beziehungsweise lastbasiert.

Kubernetes ohne großen Aufwand

Die drei Dienste, die dedizierte Kubernetes-Cluster gebrauchsfertig hinstellen, hören auf die Bezeichnungen Google Kubernetes Engine (GKE), Azure Kubernetes Serivce (AKS) und Elastic Kubernetes Service (EKS) bei AWS. Neben der einfachen Bereitstellung der Steuerebene genießen Sie mit einem Kubernetes-Dienst aus der Cloud aber noch weitere Vorteile: So lässt sich auf Basis der jeweils in die Cloud eingebauten Shells von Google, Microsoft und AWS meist ohne großen Aufwand direkt loslegen, ohne sich um die Installation der Toolsets wie kubectl kümmern zu müssen. Nur für den lokalen Betrieb müssen Sie sich mit mehr oder weniger Aufwand gegen den Kubernetes-Cluster authentifizieren und die gewünschten Toolsets selbst installieren – doch dafür bieten die genannten Hersteller weitreichende Unterstützung.

Letztendlich unterschieden sich die drei Dienste lediglich darin, wie gut die jeweiligen Cloudbackend-Dienste wie virtuelle Netzwerke und Storage über die entsprechenden Kubernetes-APIs (allen voran CNI und CSI) integrierbar sind. Ferner gibt es neben dem Aspekt Sicherheit und Authentifizierung Unterschiede bei Verwaltbarkeit, Integration mit Toolsets und letztendlich bei den Kosten.

Hier kommt es zum Beispiel darauf an, ob der Nutzer nur für Compute-Knoten oder auch für die Nutzung des vom Anbieter verwalteten Kubernetes-Masters zahlt und ob sich die Compute-Ebene auch serverlos betreiben lässt. Letztendlich fällt bei vielen Unternehmen aber auch gerade deshalb die Wahl auf Kubernetes als Cluster-Manager, weil sich am Workflow nichts ändert, egal ob Sie Container-Anwendungen auf Docker, lokalem Kubernetes-Cluster, vSphere mit Tanzu, Pivotal, Google, Microsoft oder AWS bereitstellen.

Dass Google mit seiner im Mai 2018 veröffentlichten Version 1.10 der Google Kubernetes Engine (GKE) der erste Anbieter war, der einen verwalteten Dienst für Kubernetes in der Public Cloud bot, sollte nicht verwundern. Schließlich stammt Kubernetes aus der Feder einiger engagierter Google-Entwickler, die mit Kubernetes den Google-eigenen Cluster-Manager Borg nachentwickelt hatten, bevor das Projekt im Jahr 2015 der zu diesem Zweck gegründeten Cloud Native Computing Foundation übergeben wurde. Doch schon im Juni 2018 zog AWS mit der allgemeinen Verfügbarkeit seines Elastic Container Service nach, gefolgt von Microsoft im Juli 2018 mit seinem Azure Kubernetes Service.

Google Kubernetes Engine in Betrieb nehmen

Die Google Kubernetes Engine stellt einen vollständig verwalteten Cluster zur Verfügung. Google unterscheidet zwischen zonalen, regionalen, privaten und Autopilot-Clustern. Unter dem Autopilot-Modus versteht Google eine Kubernetes-Umgebung, mit der Sie sich auf Ihre Dienste und Anwendungen konzentrieren können, da Google die Knotenverwaltung vollständig übernimmt. Das heißt, Sie können Ihre Pods ohne Planung der Knotennutzung bereitstellen. Während Sie im Standardmodus für die Anzahl der Knoten zahlen, erfolgt dies im Autopilot-Modus auf Basis des Ressourcenverbrauchs der einzelnen Pods.

Ferner können Sie in GKE auch Cluster erstellen, auf denen Windows Server läuft. Der einfachste Fall ist der Einzelzonen-Cluster: Dieser besitzt eine einzige Control-Plane, die in einer einzelnen Zone in Betrieb ist. Diese verwaltet die Arbeitslasten aller Knoten in derselben Zone. Voraussetzung für alle in diesem Artikel gezeigten Schritte ist, dass Sie in Google die Kubernetes-Engine-API für Ihr Projekt aktivieren.

Zum Erstellen eines Clusters müssen Sie eine Kubernetes-Version der Control-Plane angeben und mindestens einen Knoten-Pool anlegen (Default Pool). Die Anzahl der Knoten muss dabei die verfügbaren Ressourcenkontingente für die Knoten und ihre Ressourcen berücksichtigen. Per Default werden drei Knoten erzeugt, Sie können aber auch mit weniger starten.

Die "Automatische Skalierung" ist standardmäßig deaktiviert, lässt sich aber einschalten. Hingegen sind automatische Updates immer aktiv. Beim Knoten-Image kommt per Default "Container-Optimized OS mit Containerd (cos_containerd)" mit der Größe "e2.medium" zum Einsatz, aber auch "Ubuntu mit Docker" ist problemlos möglich.

Die Knotenkonfiguration umfasst auch die Größe des Bootlaufwerks oder eine Begrenzung der maximalen Pod-Zahl. Die Knotenpool-Konfiguration beinhaltet auch die Knotensicherheit. Hier können Sie Typ und Grad des API-Zugriffs auswählen, den Sie der VM erteilen möchten. Der Defaultwert ist "Lesezugriff für Storage- und Dienstverwaltung, Schreibzugriff für Cloud Logging und Monitoring, Lese-/Schreibzugriff für Service Control". Die Knotenpool-Konfiguration ist damit bereits erledigt.

Die weiteren Konfigurationsschritte betreffen den Cluster und umfassen die Bereiche Automatisierung, Netzwerk, Sicherheit und zusätzliche Funktionen. Bei Automatisierung legen Sie Kriterien für Autoscaling sowie die automatische Wartung und Bereitstellung auf Clusterebene fest. Mit dem Autoscaling-Profil "Ausgeglichen" sind Sie erst einmal gut bedient. In einem produktiven Setup könnten Sie zusätzlich ein Wartungsfenster aktivieren.

GKE-Netzwerke definieren

Im Bereich "Netzwerk" wählen Sie ein virtuelles Netzwerk für den Cluster aus. Das Default-Netzwerk wird automatisch erstellt, ebenso wie das Knoten-Subnetz (default). Das Netzwerk bestimmt, mit welchen anderen Compute-Engine-Ressourcen der Kubernetes-Cluster kommunizieren kann. Ferner legen Sie hier das Subnetz fest, in dem sich der Kubernetes-Cluster befindet. Haben sie "VPC nativ" aktiviert, muss das Subnetzwerk mindestens zwei sekundäre Bereiche enthalten, auf die kein anderer Kubernetes-Cluster zugreift.

Google unterscheidet übrigens nicht zwischen Control-Plane und Workload-Netzwerk. Ferner legen Sie hier einen Dienstadressbereich fest. In GKE erhalten Cluster-Dienste stets eine IP-Adresse aus diesem privaten IP-Adressbereich gemäß RFC 1918. Die Eingabe kann in CIDR-Schreibweise oder mit Maske erfolgen. Lassen Sie das Feld leer, verwendet GKE einen Standardbereich. Zusätzlich lassen sich an dieser Stelle bei Bedarf Netzwerkrichtlinien angeben.

Die Kubernetes-Network-Policy-API erlaubt Ihnen festzulegen, welche Pods miteinander kommunizieren dürfen. Außerdem können Sie hier für das Troubleshooting die "Knoteninterne Sichtbarkeit" aktivieren, um beispielsweise mit Hilfe von VPC-Flow-Logs den knoteninternen Traffic zur Google-Service-Fabric sichtbar zu machen. Auch das "HTTP Load Balancing"-Add-on nehmen Sie an dieser Stelle in Betrieb. Dies ist für den gemeinsamen Einsatz von "Google Cloud Load Balancer" und Kubernetes Ingress notwendig. Dies erzeugt einen Kubernetes-Controller, der Änderungen der Loadbalancing-Konfiguration auf Ihr GCP-Projekt koordiniert. Schließlich verhindern Sie mit der Option "Autorisierte Netzwerke der Steuerungsebene aktivieren", dass nicht vertrauenswürdige Quell-IP-Adressen, die nicht von der GCP stammen, über HTTPS auf den Kubernetes-Master zugreifen.

Noch wichtiger als die Knotensicherheit ist das Thema Netzwerksicherheit. Hier haben Sie zahlreiche Auswahlmöglichkeiten. Standardmäßig ist etwa "Shielded GKE-Knoten" aktiviert. Solche Knoten bieten eine starke kryptografische Identität. Die Verschlüsselung von Secrets auf Anwendungsebene schützt Ihre Secrets in etcd mit einem von Ihnen selbst im Cloud-KMS verwalteten Schlüssel. Mit "Workload Identity aktivieren" stellen Sie eine sichere Verbindung von GKE-Arbeitslasten zu Google-APIs her.

Spannend bei GKE ist auch der Abschnitt "zusätzliche Funktionen", wo Sie etwa auf "Cloud Run for Anthos" zugreifen. Damit lassen sich zustandslose Anwendungen und Funktionen in diesem Cluster bereitstellen. Cloud Run for Anthos verwaltet dann selbständig und automatisch die zugrunde liegenden Ressourcen und skaliert die Anwendung abhängig von den Anfragen. Noch im Beta-Stadium ist die Möglichkeit, Istio zu aktivieren. Hierbei handelt es sich um ein Service Mesh, das Monitoring, Traffic-Steuerung und Sicherheit für alle Dienste bereitstellt, die in GKE laufen. Das Aktivieren der Option sorgt für die Installation der Istio-Komponenten im Cluster.

Letzte Schritte zum GKE-Cluster

Sobald Sie auf den "Erstellen"-Knopf drücken, wird der Cluster je nach Anzahl und Größe der Compute-Knoten in wenigen Minuten erstellt und in der Cluster-Liste angezeigt. Folgen Sie dem Link zum Cluster, landen Sie im Cluster-Menü und können die vom Erstellungs-Assistenten getroffenen Einstellungen überprüfen, zum Beispiel die gewählten Netzwerk-Adressbereiche.

Insgesamt sind Aufbau und Logik in der Menüführung vorbildlich. Alternativ können Sie alle bisher für die grafische Konsole beschriebenen Schritte auch per REST-Call oder CLI ausführen. So finden Sie etwa die Konfiguration nichtflüchtiger Volumes im Tab "Speicher". Dabei dienen Ressourcen vom Typ "Persistent Volume" zum Verwalten von dauerhaftem Speicher in einem Cluster. GKE verwendet für Persistent Volumes üblicherweise nichtflüchtigen Speicher.

Der Unterschied zu Kubernetes-Volumes besteht darin, dass Kubernetes den Lebenszyklus von Persistent Volume verwaltet. Ein solches Volume lässt sich dynamisch erzeugen, Sie müssen also den persistenten Speicher nicht manuell erstellen und löschen. Kubernetes-Volume-Implementationen wie "gcePersistentDisk" konfigurieren Sie dann mithilfe von Storage-Class-Ressourcen. Im Normalfall erstellt GKE automatisch eine Standard-Storage-Class, die den standardmäßigen nichtflüchtigen Speichertyp "ext4" verwendet. Der kommt nur zum Einsatz, wenn in einem "PersistentVolumeClaim" kein "StorageClassName" angegeben ist. Zudem können Sie auch andere Speicherlösungen wie NFS nutzen.

Workloads in GKE betreiben

Mit GKE lassen sich Arbeitslasten in der Konsole erstellen. Sie finden die Einstellungen im Menü "Arbeitslasten", wo Sie auf den Button "Bereitstellen" klicken und bei "Image-Pfad" das gewünschte Image aus docker.io oder Ihrer Google-Container-Registry angeben. Bei Bedarf fügen Sie hier weitere Container oder Umgebungsvariablen hinzu. Der Schritt "Konfiguration" des Assistenten erlaubt Ihnen, falls gewünscht, das "Kubernetes-Deployment" in YAML zu bearbeiten beziehungsweise den ausführenden Cluster auszuwählen. Nach wenigen Sekunden ist die Anwendung erstellt und im Reiter "Übersicht" einsehbar.

Um für Ihr Deployment einen Dienst zu erstellen, greifen Sie auf das Menü "Dienste und Ingress" zu. Alternativ vereinfacht der Knopf "Verfügbarmachen" im Übersichts-Tab den Vorgang. Hier können Sie dann beispielsweise den Diensttyp "Load-Balancer" wählen, die gewünschten Quell- und Ziel-Ports eintragen und Ihrem Dienst einen Namen geben. Sie finden die Cluster-IP-Adresse, die IP-Adresse des Loadbalancers und den externen Endpunkt dann nach kurzer Zeit auf der Übersichtsseite wieder.

In GKE authentifizieren

Sie können alle Bereitstellungsvorgänge des Clusters über REST-API und CLI erledigen. Anwendungsentwickler arbeiten aber vorrangig mit "kubectl", wozu es einer Authentifizierung bedarf. Denn sämtliche Cluster haben einen kanonischen Endpunkt, der den Kubernetes-API-Server zur Verfügung stellt, den wiederum kubectl und andere Dienste zur Kommunikation mit der Cluster-Steuerungsebene (Master) verwenden.

Diese finden Sie in der Cloudkonsole im Feld "Endpunkte" auf dem Tab "Details" des Clusters. Hier finden Sie auch das Cluster-Zertifikat. Rein private Cluster besitzen zwei separate Endpunkt-IP-Adressen: Einmal mit "privateEndpoint" eine interne IP-Adresse und dann mit "publicEndpoint" eine externe IP-Adresse. Das Feld "Endpoint" bezieht sich auf die externe IP-Adresse, sofern der öffentliche Zugriff auf den Endpunkt nicht deaktiviert ist und daher die private IP-Adresse im Einsatz ist.

Hinsichtlich der Authentifizierung des Clusters besteht bei Google die Besonderheit, dass sämtliche GKE-Cluster so konfiguriert sind, dass sie die Identitäten von Google-Cloud-Nutzern und -Dienstkonten akzeptieren. Sie validieren dazu die von kubectl bereitgestellten Anmeldedaten mit der mit der Nutzer- oder Dienstkonto-Identität verknüpften E-Mail-Adresse. Die Anmeldedaten dieser Konten müssen daher für die Authentifizierung den OAuth-Bereich "userinfo.email" enthalten.

Kubernetes nutzt eine YAML-Datei mit dem Namen "kubeconfig", um Informationen zur Clusterauthentifizierung für kubectl zu speichern. Die Datei enthält eine Liste von Kontexten, auf die kubectl beim Ausführen von Befehlen verweist. Sie wird per Default unter "/.kube/config" abgelegt. Möchten Sie kubectl-Befehle für einen Cluster ausführen, der in der Cloudkonsole, auf einem anderen Computer oder von einem anderen Mitglied des Projekts erstellt wurde, müssen Sie eine solche kubeconfig-Konfiguration erst erzeugen, zum Beispiel in der Cloud Shell mit

Anschließend können Sie mittels gcloud init oder gcloud config kubectl konfigurieren und nutzen.

Preise für GKE

Beim Autopilot-Cluster zahlen Sie pauschal 0,10 US-Dollar pro Stunde und Cluster, zuzüglich der CPU-, Speicher- und sitzungsspezifischen Speicherrechenressourcen, die Sie für jeden Ihrer Pods bereitstellen. Die bereitgestellte Menge der Pod-Ressourcen basiert auf den Ressourcenanforderungen von "Kubernetes PodSpec". Für alle System-Pods sowie die Leistung des Betriebssystems und nicht zugewiesenen Speicherplatz fallen keine Kosten an. Autopilot-Ressourcen werden grundsätzlich im Sekundentakt ohne Mindestgebühr abgerechnet.

Im Standardmodus fällt immer eine Verwaltungsgebühr von 0,10 US-Dollar pro Cluster und Stunde an, unabhängig von der Clustergröße oder der Topologie. Für Anthos-Cluster-Cluster gelten die Gebühren für die GKE-Clusterverwaltung nicht. Weitere Details können Sie im Google-Preisrechner [1] evaluieren.

Fazit

Der erste Teil unseres Vergleich der drei Angebote zu Kubernetes-Clouddiensten hat Ihnen den Umgang mit der Variante aus dem Hause Google nähergebracht. Trotz der komplexen Anforderungen, die Kubernetes mit sich bringt, gelangt der IT-Verantwortliche hier relativ schnell ans Ziel, einen laufenden Cluster sein Eigen zu nennen. Dabei ist das notwenige Know-how deutlich geringer als beim einem vergleichbaren lokalen Aufbau, der auf der sprichwörtlichen grünen Wiese beginnt. Dies muss der IT-Verantwortlich dann nur noch in Sachen Kosten gegenrechnen, die Google jedoch transparent darstellt. In Teil 2 betrachten wir die Kubernetes-Angebote von Microsoft und AWS und untersuchen, ob Admins bei diesen genauso schnell und zu welchen Kosten zu einem Kubernetes-Cluster gelangen.

Kubernetes-Dienste von Azure, AWS und Google im Vergleich (1)

Der Inhalt entscheidet

Kubernetes ohne großen Aufwand

Kubernetes ohne großen Aufwand

Google Kubernetes Engine in Betrieb nehmen

GKE-Netzwerke definieren

Letzte Schritte zum GKE-Cluster

Workloads in GKE betreiben

In GKE authentifizieren

Preise für GKE

Fazit