Orchestrierung des Container-Betriebs mit Amazon Web Services

Wer IT-Applikationen mittels Container-Technologie betreiben möchte, steht zunächst vor der Wahl der passenden Cloud-Plattform und des geeigneten Orchestrierungssystems. Über die verschiedenen Möglichkeiten im Ökosystem von Amazon Web Services gibt es in diesem Artikel mehr zu lesen.

Im Artikel Einführung in die Container-Technologie haben wir ein grundlegendes Verständnis über Container gelegt.

Wer nun anstrebt den nächsten Schritt zu gehen und seine IT-Applikationen mittels Container-Technologie zu betreiben, der steht zunächst vor der Wahl der passenden Cloud-Plattform. Amazons Web Services (AWS), Microsoft Azure oder die Google Cloud Plattform (GCP) sind hier aktuell die bevorzugtesten Plattformanbieter. Jeder dieser Anbieter bietet jeweils eigene Kubernetes-Services als Platform-as-a-Service (PaaS) an.

Kubernetes (k8s), ursprünglich von Google entwickelt, ist heute ein quelloffenes Projekt der Cloud Native Computing Foundation (CNCF) und aktuell die meistgenutzte Container-Orchestrierungsplattform.

Als offener Standard vereinfacht Kubernetes die Migration von Containern aus Kubernetes-Instanzen verschiedener Clouds. Die Orchestrierung mittels Kubernetes ist daher nicht nur bei AWS möglich, sondern wird auch bei anderen führenden Cloud-Plattformen eingesetzt. Alle zuvor genannten Cloud-Hyperscaler sind der CNCF angehörig und damit aktive Unterstützer von Kubernetes, was die Integration oder die Migration von Cloud-Anwendungen erleichtert. Allerdings beschränken sich die bereitgestellten Dienste der Hyperscaler meistens auf die Bereitstellung der Kubernetes Control-Plane und überlassen die Verwaltung der Applikationen dem Nutzer.

Wer überwiegend im Ökosystem von Amazon Web Services unterwegs ist, sollte nachfolgende Orchestrierungstools kennen und für den eigenen Einsatz bewerten können.

Amazons „Elastic Container Service“ (ECS)

ECS ist ein skalierbarer, vollständig verwalteter Service zur Container-Orchestrierung, der speziell für AWS entwickelt wurde – und somit eine sehr gute Integration in das AWS-Ökosystem mitbringt.

Mit dem möglichen Orchestrierungs-Tool Elastic Container Service (ECS) verspricht AWS Sicherheit, Zuverlässigkeit und Skalierbarkeit bei der Ausführung vertraulicher, unternehmenskritischer Anwendungen. Dieser Service zeichnet sich durch eine einfache Bedienung und geringe Komplexität aus. Ebenfalls vorteilhaft bei ECS ist, dass keine Grundgebühr anfällt und auch keine dedizierte Steuerungsebene nötig ist, weil das Deployment der Container direkt über die AWS-Managementkonsole verwaltet werden kann.

Allerdings kann man sich mit ECS auch Nachteile einhandeln: ECS bietet weder eine Multi-Cloud-Fähigkeit noch die Option einer On-Premises-Installation. Dazu kommt: Hybride Cluster sind nur über AWS Outposts* möglich, was wiederum eine starke Herstellerabhängigkeit nach sich zieht.

*AWS Outposts sind vollständig von AWS verwaltete Hardware Ressourcen für das On-Premise-Rechenzentrum, die die AWS-Infrastruktur inklusive einiger AWS-Services, -APIs und -Tools zur Realisierung einer Hybrid Cloud einbindet. AWS Outposts sind gedacht für Workloads, die Zugriffe mit geringer Latenz auf On-Premise-Systeme und lokale Datenverarbeitung erfordern, etwa bei der Migration von Legacy-Anwendungen mit lokalen Systemabhängigkeiten.

Elastic Kubernetes Service (EKS) bringt Kubernetes-Service mit

Die zuvor genannten ECS-Nachteile können längst nicht alle Nutzer akzeptieren. Deshalb bietet AWS gegen eine geringe Grundgebühr mittlerweile auch den Elastic Kubernetes Service (EKS) als Orchestrierungssystem an.

EKS ist ein verwalteter, hochverfügbarer und skalierbarer Kubernetes-Service. Dieser Service ermöglicht die Bereitstellung, die Skalierung und den Betrieb Container-basierter Anwendungen, ohne selbst eine Control-Plane für Kubernetes einrichten und betreiben zu müssen.

EKS bietet mehr Funktionalität und einen höheren Abstraktions- und Automatisierungsgrad als ECS.

Der Elastic Kubernetes Service stellt also einen Kubernetes-Cluster bereit, ohne dass dafür eine eigene Kubernetes-Steuerebenen oder -Knoten installiert, betrieben und gewartet werden müssen. Bereitgestellt wird eine „Control Plane“, auch Master genannt. Bedient werden kann diese „Control Plane“ über Kubectl, das Standard-Befehlszeileninterface von k8s. Es können aber durchaus auch andere Benutzerschnittstellen genutzt werden. Die zur Ausführung von Anwendungen erforderliche Ressourcen werden in sogenannten „Manifest-Dateien“ (YAML oder JSON) definiert.

EKS soll als Plattform für das automatisierte Bespielen, Skalieren und Warten der Anwendungscontainer auf verteilten Nodes bereitstehen – und unterstützt die Nutzung einer ganzen Reihe bewährter Container-Tools.

Gemeinsam genutzte Speicher- und Netzwerk-Ressourcen

Container werden bei k8s zu sogenannten „Pods“ zusammengefasst und auf „Nodes“ betrieben. Pods sind die kleinsten verteilbaren Recheneinheiten, die mit Kubernetes erstellt und verwaltet werden können. Pods kann man sich wie „Erbsenschoten“ vorstellen, in denen statt der Erbsen ein oder mehrere Container mit gemeinsam genutzten Speicher- und Netzwerk-Ressourcen und einer Spezifikation für den Betrieb untergebracht sind.

Der Inhalt eines Pod wird immer gemeinsam platziert und geplant – und in dem gemeinsamen Kontext ausgeführt. Ein Pod modelliert also, jeweils anwendungsspezifisch, einen „logischen Host“ für einen oder mehrere Anwendungs-Container, die relativ eng miteinander verbunden sind.

Nodes sind in der Regel virtuelle Server, auf denen dann die mittels Kubernetes verwaltete Container-Technologie ausgeführt wird. Diese Nodes wiederum werden in einem Kubernetes-Cluster zusammengefasst. Skalieren lassen sich in diesen Kubernetes-Clustern einerseits die Pods/Container, andererseits aber auch die Nodes im Cluster selbst. Auf diese Weise lassen sich die Nodes und Container jederzeit so skalieren, dass die Leistung optimal im Cluster verteilt wird.

Erhöhter Konfigurationsaufwand bei Verwendung von EKS

Das klingt zunächst gut und verspricht weitgehende Unabhängigkeit vom starren Hardware-Fundament. Doch wie immer steckt der Teufel im Detail. Zum einen ist für den Container-Betrieb unter EKS fundiertes k8s-Fachwissen notwendig. Außerdem muss man wissen: Nicht alle AWS-Services sind direkt integrierbar; zum Beispiel bleibt das Rechtemanagement, das AWS per IAM-Service vorgibt, außen vor. Hier muss der Kunde selbst eine Integration / Konfiguration der User, Rollen und Rechte innerhalb des Clusters vornehmen.

Beim sogenannten „Self Healing“ vergleicht der Controller den Zielzustand des Clusters mit dem Ist-Zustand und behebt alle etwaigen Unterschiede automatisch. Dabei arbeitet er mit dem Key-Value-Store etcd, einer konsistenten, hochverfügbaren Datenbank, in der Ziel-Konfiguration und aktueller Cluster-Zustand gespeichert werden. Mit dem integrierten Scheduler werden bei Anfragen vom API-Server die funktionierenden Nodes mit freier Kapazität ermittelt, aus denen dann im Zuge eines Loadbalancing für das anstehende Pod-Deployment der geeignete Node ausgewählt wird. Per Kubectl können die Container gestartet, gestoppt und manuell überwacht werden, während die Verbindungen zu den Pods vom Kube-Proxy als „Loadbalancer“ verwaltet und gesteuert werden.

Im Vergleich zu ECS muss bei EKS jedoch mit einem höheren Konfigurationsaufwand gerechnet werden.

Wenn Sie zu diesem Thema und zusätzlich bspw. zum Betrieb von ECS mit Fargate tiefergehende Informationen benötigen, empfehlen wir unser kostenfreies eBook "Container-Acceleration".