EKS - Elastic Kubernetes Service

AWS Elastic Kubernetes Service

AWS EKS ist eine managed Kubernetes Control Plane (abgebildet im sog. Master-Node - im Gegensatz zu den Worker-Nodes = Data-Plane), die den härtesten Teil eines Kubernetes Clusters abbildet. Das Control-Plane-Cluster läuft in einem von AWS managed VPC, hat aber eine Verbindung in das vom Kunden managed Worker-Cluster (abgebildet als Node-Groups).

man muss natürlich nicht AWS EKS verwenden, um Kubernetes auf EC2 zu nutzen. Man kann auch die Control-Plane vollkommen selbst bauen. Die Control-Plane ist allerdings der komplexe Part eines Kubernetes-Clusters. Man benötigt hier entsprechend Erfahrung und Zeit, um einen HA-Cluster zuverlässig (etcd Backup) bereitzustellen und alle 6 Monate eine Migration der Kubernetes Version vorzunehmen. Aus diesem Grund hat sich AWS entschieden EKS anzubieten. Kubernetes selbst ist Technologie-agnostic, d. h. das unterliegende Backend (Cloud, OnPrem) spielt keine Rolle für die Orchestrierung von Workload. Allerdings wird ein Backend benötigt und hier kommen natürlich alle Cloud-Anbieter (AWS; Azure, Google) in Frage ... man kann prinzipiell aber natürlich auch seine eigene Hardware bereitstellen.

Für die Data-Plane bietet AWS

  • EC2 Instanzen, NLBs (Network-Load-Balancers), EBS-Volumes,

  • oder AWS Fargate

  • oder beides

Die Data-Plane ist der einfache Teil, weil man hier nur eine Integration in den Cluster braucht um Compute-Ressourcen zur Verfügung zu stellen.

AWS-EKS vs AWS-ECS

Der Elastic-Container-Service (ECS) stellt eine AWS-spezifische Alternative zu Kubernetes dar. Genau wie AWS-EKS kann es mit EC2 oder Fargate Ressourcen als Compute-Nodes arbeiten.

EC2 vs Fargate Data Plane

Der Fargate Ansatz reduziert den Maintenance Aufwand deutlich, da Auto-Scaling und VMs automatisch managed sind von AWS selbst. Dafür ist er in der Vielfalt limitiert (z. B. kein Support von DaemonSets).

Fargate verwendet letztlich auch EC2 Instanzen ... man muss sie aber nicht managen.

AWS EKS Workshop

Der offizielle Amazon EKS Workshop ist eine tolle Einführung und ein MUST-HAVE für den Einstieg.

Der Terraform-Code erzeugt ein Cluster (ACHTUNG: signifikante KOSTEN) und auch eine Cloud9 Entwicklungsumgebung, so dass man die Beispiele leicht nachvollziehen kann, ohne die ganzen Tools lokal selbst installieren zu müssen. Über Addons lässt sich der Umfang leicht konfigurieren. Ein Reset ist leicht über ein einziges Kommando zu bewerkstelligen (``).

Step-by-Step Workshop wie man ein AWS EKS Cluster auf Basis des aws-samples/eks-workshop-v2 GitHub repos aufsetzt. Diese Projekt bietet schon eine Vielzahl von .

Nach einem initialen

terraform apply -auto-apply

steht das EKS-Cluster bereits zur Verfügung.

kubectl CLI

siehe hier @pierreinside

Verwendet man Amazon-EKS, so kann man sich per

aws eks --region <aws_region> update-kubeconfig --name <cluster-name>

die Konfiguration in eine Datei erzeugen lassen. Per Default ist es ~/.kube.config. Hat man allerings eine KUBECONFIG Umgebungsvariable gesetzt, dann wird diese Datei verwendet.

Ich bevorzuge für jedes Cluster eine eigene Datei in ~/.kube.config (z. B. ~/.kube/config-microk8s, ~/.kube/config-aws-eks). Deshalb mache ich VOR der Cluster ein export KUBECONFIG=~/.kube/config-aws-eks und anschließend das aws eks update-kubeconfig. Später kann ich dann zwischen den verschiedenen Clustern mit einem einfach export KUBECONFIG=... wechseln.

Eine Liste der im Account verfügbaren Cluster bekommt man per aws eks list-clusters (die korrekte Konfiguration der AWS Credentials natürlich vorausgesetzt).

eksctl CLIs

Mit der eksctl wird das AWS EKS Cluster gemanaged. Mit

eksctl create cluster \
  --name my-eks-cluster \
  --region eu-central-1 \
  --ssh-access \
  --ssh-public-key=my-public-keypair \
  --node-type=m5.large \
  --nodes=2

kann man besipielsweise ein AWS-EKS-Cluster erzeugen. Bei diesem einzelnen Befehl werden sehr viele AWS-Ressourcen erstellt und miteinander über Konfiguration verknüpft. Somit ist das ekscli ein sehr mächtiger Apparat, der auf hohem Abstraktionslevel sitzt.

Diese CLIs sind i. a. sehr praktisch für die Fehleranalyse. Für die Administration (Erstellung/Konfiguration/Löschung) eines Clusters sind sie aber nicht erste Wahl, da die Wahrscheinlichkeit hoch ist, dass durch die fehlende Automatisierung Snowflake Server entstehen (Kommandos werden in einer bestimmten Reihenfolge evtl. sogar fehlerhaft oder unvollständig) ausgeführt werden. Aus diesem Grund empfiehlt sich für die Administration Terraform oder AWS Cloudformation.

Bewertung

Es ist ok eksctl für gelegentlich Abfragen über das Cluster zu verwenden (z. B. zur Fehleranalyse). Vielleicht ist es auch ein nettes Learning, mal ein Cluster damit aufzubauen.

Allerdings sollte man jegliche Infrastruktur-Komponenten mit Infrastructure-as-Code managen (z. B. via terraform). Tut man das nicht entstehen Snowflake-Installationen, die nur noch manuell gemanged werden können und das ist sehr fehleranfällig und kaum nachvollziehbar. Mit Terraform kann man auch schnell mal erstellte (teure) Infrastruktur mit einem einzigen Kommando wieder abbauen. Insofern ist das auch in Lernsituationen die bessere Variante.

AWS Node-Group

nur wenn self-managed EC2 Instanzen als Worker-Nodes verwendet

  • in AWS verwendet man Node-Groups, um die Worker-Nodes in Gruppen zu separieren

Node Auto-Scaler

Der AWS Cluster-Autoscaler verwendet eine Auto-Scaling-Group, um die Anzahl der Nodes lastabhängig zu steuern.

neben diesem Node-Scaling gibt es auch ein Auto-Scaling auf Pod-Ebene (siehe Horizontal-Pod-Autoscaler)

Ingress

Service-Account

Der EKS-Service-Account ist die AWS-Identität, mit der die Kubernetes Ressourcen (z. B. Pods) arbeiten ... der Pod wird mit dem Service-Account assoziiert. Insofern hängen hier u. a. Berechtigungen dran.

Der Service-Account ist vergleichbar mit einem technischen User-Account

PreviousStatic Website HostingNextS3

Last updated

Was this helpful?