Kubernetes (oftmals als “K8s” abgekürzt) hat vor Jahren den Kampf der Container-Orchestrierungstools gewonnen. Dennoch gibt es immer noch viele Möglichkeiten, Kubernetes heute zu implementieren und es mit verschiedenen Infrastrukturen zusammenarbeiten zu lassen. Es gibt viele Tools, einige besser gepflegt als andere. Die interessanteste Entwicklung in diesem Bereich ist jedoch, dass die Top-Cloud-Anbieter beschlossen haben, ihre eigenen verwalteten Kubernetes-Versionen herauszubringen:
- Microsoft Azure bietet den Azure Kubernetes Service (AKS) an
- AWS bietet den Amazon Elastic Kubernetes Service (EKS) an
- Google Cloud bietet den Google Kubernetes Engine (GKE) an
Aus Sicht des DevOps, was bieten diese Plattformen? Erfüllen sie ihre Versprechungen? Wie stehen sie im Vergleich zu anderen Benchmarks wie der Erstellungszeit? Wie gut integrieren sie sich in ihre jeweiligen Plattformen, insbesondere ihre CLI-Tools? Wie ist es, sie zu pflegen und mit ihnen zu arbeiten? In diesem Artikel werden wir diese Fragen und mehr beleuchten.
AKS vs. EKS vs. GKE: Beworbene Funktionen
Wir haben beschlossen, die verschiedenen Funktionen der verwalteten Kubernetes-Versionen in folgende Kategorien einzuteilen:
- Globale Übersicht
- Networking
- Skalierbarkeit und Performance
- Sicherheit und Überwachung
- Ökosystem
- Preisgestaltung
Diese Details können sich im Laufe der Zeit ändern, da Cloud-Anbieter ihre Produkte regelmäßig aktualisieren.
Globale Übersicht
Kubernetes selbst war ein Google-Projekt, daher ist es sinnvoll, dass sie 2014 als erste eine gehostete Version vorgeschlagen haben. Azure war als Nächstes mit AKS dran und hatte daher etwas Zeit, um Verbesserungen vorzunehmen. AWS war der letzte, der seine eigene Version herausgebracht hat, EKS, daher wirkt es manchmal rückständig. Was die Preisgestaltung betrifft, bewegen sich die Dinge natürlich immer, und Google hat sich im Juni 2020 dazu entschlossen, den Preis von 0,10 US-Dollar pro Stunde einzuführen, wie bereits bei AWS. Azure ist hier der Außenseiter, da der AKS-Dienst kostenlos angeboten wird, aber es ist unklar, wie lange das so bleiben wird. Ein weiterer wesentlicher Unterschied liegt in der Upgrade-Funktion des Clusters. Die automatisierten Upgrades sind bei GKE am fortgeschrittensten und standardmäßig aktiviert. AKS und EKS sind sich hier ähnlich, da beide manuelle Anfragen erfordern, um den Master oder die Worker-Nodes aktualisieren zu können.
Networking
Auf Netzwerkebene sind die drei Cloud-Anbieter sehr ähnlich. Alle ermöglichen es Kunden, Netzwerkrichtlinien mit Calico zu implementieren. Was das Load Balancing betrifft, implementieren sie alle ihre Integrationen mit ihren eigenen Lastenausgleicher-Ressourcen und bieten den Ingenieuren die Wahl, was sie verwenden möchten. Der Hauptunterschied besteht hier in den Mehrwerten des Service Mesh. AKS unterstützt von Haus aus kein Service Mesh (obwohl Ingenieure manuell Istio installieren können). AWS hat sein eigenes Service Mesh namens App Mesh entwickelt. Google hat sein eigenes Integration mit Istio veröffentlicht (aber noch in der Beta-Phase), das Kunden direkt bei der Erstellung des Clusters hinzufügen können.
Die beste Wahl: GKE
Skalierbarkeit und Performance
In Bezug auf die Performance und Skalierbarkeit von GKE, AKS und EKS scheint GKE führend zu sein. Es unterstützt die größte Anzahl von Knoten (5.000) und bietet eine umfangreiche Dokumentation, wie man einen Cluster richtig skalieren kann. Alle Funktionen für hohe Verfügbarkeit sind verfügbar und können einfach angepasst werden. Darüber hinaus hat GKE kürzlich Anthos eingeführt, ein Projekt zur Schaffung eines Ökosystems rund um GKE und seine Funktionen. Mit Anthos können Sie GKE lokal bereitstellen. AWS hat jedoch einen entscheidenden Vorteil: Es ist der einzige Anbieter, der das Ausführen von Bare-Metal-Knoten in Ihrem Kubernetes-Cluster ermöglicht. AKS fehlt seit Juni 2020 die hohe Verfügbarkeit für den Masternode, was ein wichtiger Aspekt ist. Aber das könnte sich natürlich bald ändern.
Die beste Wahl: GKE
Sicherheit und Überwachung
In Bezug auf Compliance sind alle drei Cloud-Anbieter gleichwertig. In Bezug auf die Sicherheit bieten EKS und GKE einen weiteren Sicherheitsschutz durch ihre integrierten Schlüsselverwaltungsdienste. Was die Überwachung betrifft, bieten Azure und Google Cloud ihre eigene Überwachungsumgebung rund um Kubernetes an. Dabei ist zu beachten, dass die von Google entwickelte Überwachung kürzlich auf das Kubernetes Engine Monitoring umgestellt wurde, das speziell für Kubernetes entwickelt wurde. Azure bietet ihr eigenes Container-Überwachungssystem an, das ursprünglich für ein grundlegendes, nicht-Kubernetes Container-Ökosystem entwickelt wurde. Es wurde um die Überwachung einiger Kubernetes-spezifischer Metriken und Ressourcen (Clustergesundheit, Bereitstellungen) erweitert und befindet sich im Vorschaumodus (Juni 2020). AWS bietet eine leichte Überwachung für die Steuerebene direkt in Cloudwatch an. Zur Überwachung der Worker können Sie die von Kubernetes Container Insights bereitgestellten Metriken über einen speziellen CloudWatch-Agenten verwenden, den Sie im Cluster installieren können.
Die beste Wahl: GKE
Ökosystem
Die drei Anbieter haben unterschiedliche Stärken und Assets in Bezug auf das Ökosystem. AKS verfügt mittlerweile über sehr umfangreiche Dokumentation zu seiner Plattform und ist in Bezug auf Posts auf Stack Overflow die Nummer zwei. EKS hat die geringste Anzahl von Posts auf Stack Overflow, profitiert aber von der Stärke des AWS Marketplace. GKE, als älteste Plattform, hat die meisten Posts auf Stack Overflow und eine anständige Anzahl von Apps in seinem Marktplatz, aber auch die umfassendste Dokumentation.
Die besten Wahlen: GKE und EKS
Preisgestaltung
Bei den Gesamtkosten bleibt GKE trotz der Einführung des $0,10 pro Stunde Preispunkts für jeden Cluster immer noch bei weitem die günstigste Cloud. Dies liegt an einer spezifischen Eigenschaft von Google – “sustained use discounts”, die angewendet werden, wenn der monatliche Verbrauch von On-Demand-Ressourcen einen bestimmten Mindestbetrag erreicht. Es ist wichtig zu beachten, dass die Beispiel-Preistabelle den Datenverkehr zum Kubernetes-Cluster, den der Cloud-Anbieter berechnen kann, nicht berücksichtigt. Der Grund, warum AWS die Verwendung ihres kostenlosen Tiers nicht zum Testen eines EKS-Clusters zulässt, ist, dass EKS größere Maschinen als die tX.micro-Tier benötigt und die minutengenaue Preisgestaltung von EKS nicht im kostenlosen Tier enthalten ist. Dennoch kann es wirtschaftlich sein, eine der verwalteten Kubernetes-Optionen mit einer anständigen Auslastung mithilfe der Spot-/preemptible-Nodes jedes Cloud-Anbieters zu testen. Diese Taktik spart leicht 80 bis 90 Prozent des Endpreises. (Natürlich wird nicht empfohlen, auf solchen Maschinen produktionskritische Workloads auszuführen!)
Die beworbenen Funktionen und der Vorteil von Google
Bei der Betrachtung der verschiedenen beworbenen Funktionen im Internet scheint es eine Korrelation zwischen der Dauer, die die verwaltete Kubernetes-Version bereits auf dem Markt ist, und der Anzahl der Funktionen zu geben. Wie bereits erwähnt, scheint es ein unbestreitbarer Vorteil von Google zu sein, da sie der Initiator des Kubernetes-Projekts waren und daher eine bessere und stärkere Integration in ihre eigene Cloud-Plattform haben. Aber AKS und EKS dürfen auch nicht unterschätzt werden, da sie weiterentwickelt werden und beide von ihren einzigartigen Funktionen profitieren können. AWS ist beispielsweise der einzige Anbieter, der eine Integration von Bare-Metal-Knoten hat und auch die höchste Anzahl an Anwendungen in seinem Marktplatz vorweisen kann.
Nun, da die beworbenen Funktionen für jedes Kubernetes-Angebot klar sind, schauen wir uns einige praktische Tests näher an.
Kubernetes: AWS vs. GCP vs. Azure in der Praxis
Werben ist eine Sache, aber wie schneiden die verschiedenen Plattformen im Hinblick auf die Bereitstellung von Produktions-Workloads ab? Als Cloud-Engineer weiß ich, wie wichtig es ist, wie lange es dauert, einen Cluster zu erstellen und wieder herunterzufahren, wenn die Infrastruktur als Code durchgesetzt wird. Aber ich wollte auch die Möglichkeiten jeder CLI erkunden und kommentieren, wie einfach (oder schwierig) es ist, bei jedem Cloud-Anbieter einen Cluster zu erstellen.
Benutzererfahrung bei der Erstellung eines Clusters
AKS
Bei AKS ähnelt das Erstellen eines Clusters der Erstellung einer Instanz in AWS. Suchen Sie einfach das AKS-Menü und gehen Sie durch eine Reihe von verschiedenen Menüs. Sobald die Konfiguration validiert ist, kann der Cluster in einem zweistufigen Prozess erstellt werden. Es ist sehr einfach und Ingenieure können schnell und einfach einen Cluster mit den Standardeinstellungen starten.
EKS
Die Erstellung eines Clusters ist bei EKS im Vergleich zu AKS definitiv komplexer. Zunächst einmal erfordert AWS standardmäßig einen Ausflug zu IAM, um eine neue Rolle für das Kubernetes-Kontrollflugzeug zu erstellen und den Ingenieur ihr zuzuweisen. Es ist auch wichtig zu beachten, dass diese Cluster-Erstellung die Erstellung der Knoten nicht beinhaltet. Als ich durchschnittlich 11 Minuten gemessen habe, bezog sich dies nur auf die Erstellung des Masters. Die Erstellung der Knotengruppe ist ein weiterer Schritt für den Administrator und erfordert erneut eine Rolle für die Worker mit drei erforderlichen Richtlinien, die über das IAM-Kontrollfeld erstellt werden müssen.
GKE
Für mich ist die Erfahrung der manuellen Erstellung eines Clusters am angenehmsten bei GKE. Nachdem Sie den Kubernetes Engine in der Google Cloud Console gefunden haben, klicken Sie auf “Cluster erstellen”. Verschiedene Kategorien von Einstellungen werden in einem Menü auf der linken Seite angezeigt. Google füllt den neuen Cluster mit einem leicht modifizierbaren Standard-Knotenpool vor. Last but not least hat GKE die schnellste Cluster-Erstellungszeit, was uns zur nächsten Tabelle führt.
Zeit für die Erstellung eines Clusters
Ich habe diese Tests in derselben Region (Frankfurt und Westeuropa für AKS) durchgeführt, um mögliche Auswirkungen auf die Zeiten zu reduzieren. Ich habe auch versucht, dieselbe Größe für die Knoten des Clusters auszuwählen: Drei Knoten mit jeweils zwei vCPUs und sieben oder acht GB Speicher, eine Standardgröße, um eine kleine Last auf Kubernetes auszuführen und zu experimentieren. Ich habe jeden Cluster dreimal erstellt, um einen Durchschnitt zu berechnen.
In diesen Tests war GKE immer weit voraus und benötigte für die Erstellung eines Clusters immer weniger als drei Minuten.
Kubernetes: AWS vs. GCP vs. Azure CLI-Übersicht
Nicht alle CLIs sind gleich, aber in diesem Fall sind alle drei CLIs tatsächlich Module einer größeren CLI. Wie ist es, mit der CLI-Toolchain jedes Cloud-Anbieters zu arbeiten?
AKS-CLI (über az)
Nach der Installation der az-Tools und des AKS-Moduls (über az aks install-cli) muss das CLI autorisiert werden, um mit dem Azure-Konto des Projekts zu kommunizieren. Dies besteht darin, die Anmeldeinformationen zu erhalten, um die lokale kubeconfig-Datei über az aks get-credentials -resource-group myResourceGroup -name myAKSCluster zu aktualisieren.
Ebenso erfolgt die Erstellung eines Clusters mit az aks create -resource-group myResourceGroup -name myAKSCluster.
EKS-CLI (über aws oder eksctl)
Bei AWS finden wir einen anderen Ansatz – es gibt zwei verschiedene offizielle CLI-Tools zur Verwaltung von EKS-Clustern. Wie immer kann aws mit AWS-Ressourcen verbinden, insbesondere mit Clustern. Das Hinzufügen von Anmeldeinformationen zu einer lokalen kubeconfig kann über aws eks update-kubeconfig -name cluster-test erfolgen.
Ingenieure können jedoch auch eksctl, entwickelt von Weaveworks und in Go geschrieben, verwenden, um einen EKS-Cluster einfach zu erstellen und zu verwalten. Ein großer Vorteil von EKS für Cloud-Ingenieure besteht darin, dass sie es mit YAML-Konfigurationsdateien kombinieren können, um Infrastructure-as-Code (IaC) zu erstellen, da es mit CloudFormation zusammenarbeitet. Es ist definitiv ein Asset, das bei der Integration eines EKS-Clusters in eine größere Infrastruktur auf AWS berücksichtigt werden sollte.
Die Erstellung eines Clusters über eksctl ist so einfach wie eksctl create cluster, es sind keine weiteren Parameter erforderlich.
GKE-CLI (über gcloud)
Bei GKE sind die Schritte sehr ähnlich: Installieren Sie gcloud und authentifizieren Sie sich über gcloud init. Von dort aus haben die Ingenieure verschiedene Möglichkeiten: Sie können einen Cluster erstellen, löschen, beschreiben, Anmeldeinformationen abrufen, die Größe ändern, aktualisieren oder aktualisieren oder eine Liste der Cluster abrufen.
Die Syntax für die Erstellung eines Clusters mit gcloud ist einfach: gcloud container clusters create myGCloudCluster -num-nodes=1
AKS vs. EKS vs. GKE: Ergebnisse des Testlaufs
In der Praxis sehen wir, dass GKE sicherlich der schnellste ist, um einen grundlegenden Cluster zu starten, sowohl in Bezug auf die Konsolen-Benutzerfreundlichkeit als auch auf die Zeit zum Erstellen des Clusters. Auch die Verbindung zu einem Cluster ist bei GKE am einfachsten, da es den “Verbinden”-Button direkt neben dem Cluster hat.
In Bezug auf die CLI-Tools haben die drei Cloud-Anbieter ähnliche Funktionen implementiert. Hier können wir jedoch den Schwerpunkt auf das von Weaveworks bereitgestellte zusätzliche Tool für EKS legen. eksctl ist das perfekte Tool, um Infrastructure-as-Code auf der bestehenden AWS-Infrastruktur umzusetzen und andere Dienste mit EKS zu kombinieren.
Verwaltete Kubernetes-Angebote: AWS vs. GCP vs. Azure
Für diejenigen, die gerade erst in die Welt von Kubernetes einsteigen, ist die Implementierung von GKE für mich die beste Wahl, da sie am einfachsten ist. Es ist einfach einzurichten, hat eine einfache und schnelle Benutzererfahrung beim Erstellen und ist gut in die Google Cloud Platform integriert.
Obwohl AWS der letzte war, der ins Rennen eingestiegen ist, hat es einige unbestreitbare Vorteile wie Bare-Metal-Knoten und die einfache Tatsache, dass es mit dem Anbieter mit dem größten Marktanteil integriert ist.
Schließlich hat AKS seit seiner Einführung große Fortschritte gemacht. Es wird nicht lange dauern, bis Funktionen und Werkzeuge aufeinander abgestimmt sind und Innovation ermöglicht wird. Und wie bei jedem verwalteten Kubernetes-Angebot wird bei Personen, die bereits auf der Hauptplattform sind, die Integration ein Verkaufsargument sein.
Sobald ein Team einen Kubernetes-Cloud-Anbieter ausgewählt hat, könnte es interessant sein, die Erfahrungen anderer Teams, insbesondere Misserfolge, zu betrachten. Diese Post-Mortems sind ein Spiegelbild realer Fälle – immer ein guter Ausgangspunkt, um die eigenen cutting-edge Best Practices zu entwickeln. Ich freue mich auf Ihre Kommentare!
