Suche
Serverless in Sicht

AWS goes Kubernetes: Eine Einführung zu Amazon EKS

Philipp Garbe

© Shutterstock / Digital Storm

Nach Google und Azure hat auch AWS seinen eigenen Kubernetes Service auf der re:Invent 2017 angekündigt: Den Elastic Container Service for Kubernetes oder kurz EKS. Seit Juni ist dieser in der US-Region verfügbar und die Erwartung ist groß, dass EKS demnächst auch in der EU-Region ausgerollt wird.

Was ist eigentlich EKS?

Zuerst einmal ist EKS ein offizielles Kubernetes in der Version 1.10 (weitere Versionen sind geplant) und als solches von der Cloud Native Compute Foundation zertifiziert. Damit ist sichergestellt, dass Anwendungen, die bisher auf Kubernetes laufen auch in EKS funktionieren. Das erleichtert natürlich eine mögliche Migration.

Im Prinzip besteht Kubernetes aus zwei Komponenten: Einem Cluster von Worker Nodes, auf dem die Container gestartet werden, und der Control Plane. Diese kümmert sich darum, dass die gewünschten Änderungen am Cluster auch tatsächlich durchgeführt werden. Dazu wird der Zustand sämtlicher Kubernetes-Objekte fortlaufend aufgezeichnet (Ist-Zustand) und mit dem erwarteten Soll-Zustand verglichen. Bei Abweichungen wird versucht, den Soll-Zustand wieder herzustellen.

Im Gegensatz zu einem selbst aufgesetzten Kubernetes Cluster muss man sich bei EKS nicht selbst um die Control Plane kümmern, diese wird nämlich von AWS verwaltet. EKS stellt sicher, dass die Control Plane in mehreren Availability Zones (AZ) läuft, um hohe Verfügbarkeit garantieren zu können. Kaputte Instanzen werden automatisch ausgetauscht und auch um das Patching muss man sich keine Gedanken mehr machen.

Integration mit anderen AWS Services

Zusammen mit Partnern und der Open Source Community hat AWS Erweiterungen für Kubernetes geschaffen, die das Zusammenspiel mit anderen AWS Services erleichtern sollen. Die wichtigsten Erweiterungen darunter sind:

IAM-Authentifizierung

Da man sich bei AWS sowieso mit IAM (dem Identity and Access Management) anmelden muss, wäre es unnötig sich bei Kubernetes nochmal zu authentifizieren. Deshalb wurde der initial von Heptio entwickelte aws-iam-authenticator übernommen, der die Authentifizierung zwischen IAM und Kubernetes übernimmt. Mithilfe der aws-auth ConfigMap wird das Mapping von IAM-Nutzern oder -rollen und den K8s-Nutzern und -gruppen definiert.

Quelle: Amazon

Die Autorisierung übernimmt weiterhin RBAC (Role-based Access Control), das native rollen-basierte Zugriffssystem für Kubernetes. Permissions können für den gesamten Cluster oder auch pro Namespace definiert werden und regeln den Zugriff der einzelnen API-Aufrufe. Damit kann der Zugriff auf bestimmte Bereiche des Clusters (=Namespace) eingeschränkt werden. Was allerdings fehlt, ist die IAM-Integration für Pods. Mit Bordmitteln ist es deshalb nicht möglich, auf andere AWS Services wie S3 oder DynamoDB zuzugreifen. In diesem Fall hilft es, auf Projekte aus der Kubernetes Community wie z.B. kube2iam zurückzugreifen.

VPC Support

Ein VPC garantiert die Isolation der eigenen Anwendungen auf Netzwerkebene. Dazu kann der Netzwerkverkehr mithilfe von Security Groups und Netzwerk-ACLs eingeschränkt werden. Um Container in Kubernetes in das VPC zu integrieren, verwendet EKS das Plug-in Amazon VPC CNI. Dadurch ist es möglich, dass Kubernetes Pods IP-Adressen des VPCs zugewiesen bekommen.

Die maximale Anzahl der Pods hängt vom EC2-Instanztyp ab und errechnet sich aus der maximalen Anzahl der Netzwerk-Interfaces, multipliziert mit der Anzahl der IPv4-Adressen pro Interface. Bei einer t2.medium sind das 3 Interfaces mit bis zu 6 IP-Adressen, also 15 Pods. Die primäre IP-Adresse des ENI ist hier für internen Netzwerkverkehr reserviert. Zudem müssen die verfügbaren IP-Adressen des jeweiligen Subnets berücksichtigt werden.

Quelle: Amazon

Logging

EKS schickt automatisch Zugriffe auf das EKS API nach CloudTrail, einem AWS Service, der alle Aktivitäten innerhalb eines AWS Accounts protokolliert, um sie für Compliance oder Audits auswerten oder überwachen zu können. Hier ist zu beachten, dass es nur Zugriffe auf das EKS API protokolliert und nicht das Kubernetes API selbst.

Kosten

In der US-Region kostet EKS 0,20$ pro Stunde und Cluster. Das sind im Monat um die 140$. Zusätzlich kommen noch die Kosten für die EC2-Instanzen der Worker Nodes hinzu und ggf. andere AWS Services wie z.B. LoadBalancer.

Was ist eigentlich Fargate?

Mit Fargate kann man Container laufen lassen, ohne sich um Server oder Cluster zu kümmern. Das bedeutet, dass die Worker Nodes auch von AWS verwaltet werden und man sich dann nicht mehr um die Provisionierung, Konfiguration oder das Skalieren kümmern muss. Mit diesem Komfort ergeben sich allerdings auch ein paar Einschränkungen: Bei ECS bedeutet das, dass kein Privileged Mode möglich ist und auch keine Docker Security Options angegeben werden können. Es werden außerdem nur nicht-persistente, leere Data Volumes unterstützt.

Die Preise bei Fargate sind im Vergleich zu EC2 höher und wirken auf den ersten Blick so relativ teuer. Allerdings muss bei diesem Vergleich auch die TCO berücksichtigt werden. Was kostet mich der Betrieb eines Clusters und dessen Weiterentwicklung? Wie hoch ist meine Auslastung? Können meine Services nicht mit kleineren CPU/Memory-Einheiten effizienter skalieren? Fargate für EKS ist bisher nur angekündigt und welche Features dann möglich sind und mit welchen Einschränkungen zu rechnen ist, bleibt abzuwarten.

Braucht es dann noch ECS?

Diese Frage ist berechtigt und eine eindeutige Antwort wird es wohl nicht geben. Konkurrenz belebt natürlich das Geschäft, allerdings ist die Community hinter Kubernetes schon beeindruckend. Ein gutes Zeichen für ECS ist, dass es bei AWS intern auch von anderen Services verwendet wird und deshalb vor allem AWS an der Weiterentwicklung interessiert ist. Außerdem ist der Betrieb eines Clusters kostenlos, was sich bei mehreren Cluster durchaus rechnen kann.

ECS punktet im Vergleich vor allem durch die bessere Integration ins AWS-Ökosystem und IAM-Rollen werden bei Tasks direkt unterstützt. Auch die Integration mit LoadBalancer, Security Groups und den gesamten CodeStar-Funktionen (CodePipeline, CodeBuild und CodeDeploy) fühlt sich bei ECS verständlicherweise natürlicher an.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Fazit

Wer mit ECS zufrieden ist, kann auch weiterhin mit ECS arbeiten. Die Gefahr, auf dem Abstellgleis zu landen, stellt sich erst einmal nicht und man spart sich dabei auch ein bisschen Geld. Auch die native Integration mit anderen AWS Services ist für viele Kunden wichtig.

Alle, die bereits Kubernetes im Einsatz haben, freuen sich sicherlich darauf, die Arbeit zu sparen, die das Verwalten eines eigenen Kubernetes Clusters mit sich bringt, und den von AWS verwalteten Service nutzen zu können. Auch Migrationsprojekte werden dadurch einfacher. Spannend wird es allerdings erst so richtig, wenn auch Fargate für EKS veröffentlicht wird und man sich um keine Cluster mehr kümmern muss. Eine Taskdefinition oder ein Podfile sollte dann reichen, um den Container Serverless betreiben zu können.

Geschrieben von
Philipp Garbe
Philipp Garbe
Philipp Garbe works as Lead Software Developer at AutoScout24 in Munich. As Docker Captain he also tries to share his knowledge and experience about containers. Philipp is driven by technologies and tools that allow him to release faster and more often. He expects that every commit automatically goes into production and it shouldn’t surprise that he’s excited about microservices, docker and the Cloud. Affected by Pain-driven Development, he believes that things need to be changed whenever the pain is big enough.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: