Amazon EKS – Was steckt dahinter?

Lesezeit: 6 Min, veröffentlicht am 18.06.2018
Amazon EKS – Was steckt dahinter?

Nach der Ankündigung einer Managed Kubernetes Lösung auf der re:Invent Ende 2017 hat das lange Warten seit letzter Woche ein Ende. EKS 1 wird generell verfügbar und kann allgemein genutzt werden, wenn auch die EU-Regionen vorerst außen vor sind. Wir wollen uns kurz anschauen, was EKS uns nun wirklich abnimmt und um welche Bereiche man sich selbst kümmern muss.

Es gibt unzählige Möglichkeiten, einen Kubernetes-Cluster selbst zu betreiben. Angefangen beim manuellen Aufsetzen auf die harte Tour 2 über CLI-Tools kube-adm, kops oder andere kommerzielle Angebote kann man aus einer Vielzahl von Möglichkeiten auswählen. Mit EKS (Elastic Kubernetes Service) nimmt AWS uns das Aufsetzen und den Betrieb der Master Nodes ab, inklusive HA-Unterstützung und Integration mit AWS-Diensten.

Andere Public-Cloud-Anbieter stellen mit Google Kubernetes Engine (GKE) und Azure Kubernetes Service (AKS) bereits fertige Managed Kubernetes Angebote zur Verfügung. EKS fällt hier aber ein wenig aus der Reihe. Anders als bei GKE und AKS hat man bei EKS nur die Minion-Instanzen in Form einer oder mehrerer AutoScaling Groups unter Kontrolle. Die Master werden von EKS verwaltet, d.h. Themen, wie Updates, Hochverfügbarkeit und Skalierung können wir delegieren.

Erste Schritte

Um einen EKS-Cluster zu starten, braucht es ein paar AWS-Ressourcen, die mit Hilfe eines CloudFormation-Templates erstellt werden können. Im Wesentlichen geht es hierbei um eine Security Group für den Zugriff, eine IAM-Rolle, die bestimmte Berechtigungen an EKS delegiert und um eine Auto Scaling Group für die Minion-Nodes. Je nach Umgebung kann man das CloudFormation Template 3 über die Konsole oder die API ausführen. Die detaillierte Anleitung findet sich in der EKS Dokumentation.

Zum Launch wird EKS in der Web Console, in der AWSCLI, in der API und in CloudFormation unterstützt. Dazu gesellt sich noch Support für Terraform 4. Hier sollte für jeden Anwendungsfall etwas dabei sein.

Wer gerne – wie bei kops – mit einem Befehl einen Cluster erstellen möchte, findet mit eksctl 5 das passende Tool:

➜  eks eksctl create cluster                                                                                                                                                                                                     
2018-06-13T14:18:39+02:00 [x]  importing SSH public key "/Users/andreas/.ssh/id_rsa.pub" as "EKS-beautiful-sheepdog-1528892319"
2018-06-13T14:18:40+02:00 [x]  creating EKS cluster "beautiful-sheepdog-1528892319" in "us-west-2" region
2018-06-13T14:18:40+02:00 [x]  creating VPC stack "EKS-beautiful-sheepdog-1528892319-VPC"
2018-06-13T14:18:40+02:00 [x]  creating ServiceRole stack "EKS-beautiful-sheepdog-1528892319-ServiceRole"
2018-06-13T14:19:21+02:00 [✔]  created ServiceRole stack "EKS-beautiful-sheepdog-1528892319-ServiceRole"
2018-06-13T14:19:41+02:00 [✔]  created VPC stack "EKS-beautiful-sheepdog-1528892319-VPC"
2018-06-13T14:19:41+02:00 [x]  creating control plane "beautiful-sheepdog-1528892319"
2018-06-13T14:28:44+02:00 [✔]  created control plane "beautiful-sheepdog-1528892319"
2018-06-13T14:28:44+02:00 [x]  creating DefaultNodeGroup stack "EKS-beautiful-sheepdog-1528892319-DefaultNodeGroup"
2018-06-13T14:33:07+02:00 [✔]  created DefaultNodeGroup stack "EKS-beautiful-sheepdog-1528892319-DefaultNodeGroup"
2018-06-13T14:33:07+02:00 [✔]  all EKS cluster "beautiful-sheepdog-1528892319" resources has been created
2018-06-13T14:33:07+02:00 [x]  wrote "/Users/andreas/.kube/eksctl/clusters/beautiful-sheepdog-1528892319"
2018-06-13T14:33:13+02:00 [x]  the cluster has 0 nodes
2018-06-13T14:33:13+02:00 [x]  waiting for at least 2 nodes to become ready
2018-06-13T14:33:47+02:00 [x]  the cluster has 2 nodes
2018-06-13T14:33:47+02:00 [x]  node "ip-192-168-164-141.us-west-2.compute.internal" is ready
2018-06-13T14:33:47+02:00 [x]  node "ip-192-168-239-146.us-west-2.compute.internal" is ready
2018-06-13T14:34:00+02:00 [x]  EKS cluster "beautiful-sheepdog-1528892319" in "us-west-2" region is ready

Um sich zum Cluster zu verbinden, benötigt man, wie bei anderen Kubernetes-Lösungen auch, noch die Einträge für die kubeconfig. Hier kommt eine Besonderheit von EKS zum Tragen: Für die Integration in das Identity Access Management (IAM) von AWS setzt man nicht auf die normalerweise bei Kubernetes geläufigen Zertifikate, sondern kann sich mit Hilfe seiner AWS Credentials am Cluster einloggen. Damit das funktioniert, muss kubectl in Version 1.10 oder höher und der heptio-authenticator 6 installiert sein.

Batteries included?

Wer hinter EKS eine “fertige” Kubernetes Plattform vermutet, wird leider enttäuscht. In üblicher AWS Marnier ist EKS erstmal nur das Management der Control Plane, nicht mehr und nicht weniger. An RBAC (Role Based Access Control) im Cluster geht kein Weg vorbei, Authentifizierung am Cluster ist aber mit dem Heptio Authenticator kein Problem. Die üblichen Probleme, z.B. wie ein Pod eine AWS IAM Rolle annehmen kann, um andere AWS APIs aufrufen zu können, sind mit EKS nicht direkt gelöst.

Master- und Minion-Knoten Verantwortung für Master und Minion-Knoten bei EKS

Verantwortung für Master- und Minion-Knoten bei EKS

An den Stellen, an denen eine tiefere Integration sinnvoll erscheint, beteiligt sich AWS an der Open-Source-Entwicklung. Als wesentlichen Baustein für EKS hat Amazon mit aws-vpc-cni, ein CNI (Container Network Interface) Plugin veröffentlicht, was die nativen Möglichkeiten des Netzwerk-Stacks nutzt und somit so wenig wie möglich Performance verloren geht.

Für alles weitere muss man auf die bestehenden Projekte aus dem Kubernetes-Umfeld zurückgreifen bzw. darauf warten, dass offizieller Support dafür in Kubernetes integriert wird. Ob es jetzt um die Wahl des Ingress Controllers, des Monitorings oder die Zuordnung von AWS IAM Rollen an Pods geht, auch bei EKS stellen sich diese Fragen und man hat die gleichen Bausteine zur Verfügung, wie bei anderen Lösungen auch.

Vergleicht man EKS mit GKE oder AKS, so stellt sich relativ schnell die Frage nach dem Warum. Wo liegt denn jetzt der Mehrwert für die immerhin 144$ pro Monat, mit denen EKS zu Buche schlägt?

Der sichere Betrieb einer Control Plane für Kubernetes, die sowohl hochverfügbar als auch skalierbar ist, ist nicht trivial. Mit EKS bekommt man genau diesen Job abgenommen. Aktuell zahlt man dies noch mit einigen Einschränkungen, die Master lassen sich quasi nicht anpassen. Dazu erscheint der Preis für die Master relativ hoch, im Vergleich kommt ein kops-basiertes Setup mit je einer m4.large Instanz verteilt auf 3 Availability Zones, auch schon auf 219 Dollar pro Monat. Damit wäre man also schon günstiger unterwegs und man muss sich nicht um etcd-Upgrades und andere hakelige Aktionen kümmern.

Auch wenn das Setup aktuell noch ein wenig starr erscheint, so hat AWS angedeutet, dass man z.B. Packer-Skripte für angepasste Machine Images zur Verfügung stellen möchte. Weiterhin würden alle Anpassungen und Erweiterungen in die Upstream-Projekte zurückfließen. In den nächsten Wochen und Monaten werden sich bestimmt Best Practices und gut funktionierende Lösungen herauskristallisieren. AWS will bewusst keine eigenen Projekte starten, sondern durch Mitarbeit in der Community die Kompatibilität von bestehenden Projekten verbessern und neue Features beisteuern.

Ausblick

EKS bietet aktuell einen schnellen Start mit Kubernetes. Gegenüber kops hat es den Vorteil, dass schon eine Integration mit der AWS-Authentifizierung vorkonfiguriert ist und man hier sogar schon in den Genuss von Kubernetes 1.10 (aktuell steht man hier noch bei Kubernetes 1.9) und der neuen M5/C5-Instanzen (günstiger und mehr Performance) kommt.

Leider können wir EKS bisher nur sehr eingeschränkt einsetzen, da der initiale Launch nur die US-Regionen us-west-1 und us-east-1 berücksichtigt. Die für uns interessanten Regionen eu-west-1 und vor allem eu-central-1 (Frankfurt) lassen noch auf sich warten. Bis dahin muss man sich auf die bestehenden Möglichkeiten wie kops oder kubeadm verlassen, die auch solide Kubernetes Cluster provisionieren können. Wenn es nicht unbedingt Kubernetes sein muss, kann man heute schon mit AWS Fargate “einfach so” Container in der Cloud starten (und das sogar in eu-west-1).

Wir sind weiterhin gespannt, wie es weitergeht und halten Euch auf dem Laufenden!

Referenzen

  1. https://aws.amazon.com/de/eks/

    ↩

  2. https://github.com/kelseyhightower/kubernetes-the-hard-way

    ↩

  3. https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html

    ↩

  4. https://www.terraform.io/docs/providers/aws/guides/eks-getting-started.html

    ↩

  5. https://github.com/weaveworks/eksctl

    ↩

  6. https://github.com/heptio/authenticator

    ↩
Tags

Verfasst von:

Foto von Andreas

Andreas

Andreas hat als Software-Entwickler langjährige Erfahrung im Bereich DevOps gesammelt und ist Spezialist für ausfallsichere und hochperformante Lösungen in der Cloud.