Container in der AWS Cloud betreiben und überwachen

Table of Contents

Container as a Service (CaaS) ist ein cloudbasierter Service mit dem Container deployed, ausgeführt, skaliert und verwaltet werden können.

Im AWS Umfeld finden wir zwei solche Services, nämlich den Elastic Container Service (ECS) und den Elastic Kubernetes Service (EKS). In diesem Artikel, werden wir die zwei Services vorstellen und ihre Eigenschaften und Einsatzzwecke auflisten.

Elastic Container Service

Ein ECS Cluster beinhaltet alle Services, die  das Verwalten (Scheduling, Load Balancing, Container Lifecycle) der Container ermöglichen.

Die Container werden auf EC2 Instanzen gehostet, die zum Cluster verbunden sind. Auf jeder Instanz muss die Container Runtime (z.B. Docker) und ein ECS Agent installiert werden, der die Kommunikation zwischen der Control Plane (ECS) und der entsprechenden EC2 Instanz ermöglicht.

Obwohl wir die Verwaltung der Container dem ECS Service überlassen haben, müssen wir uns um die virtuellen Maschinen (EC2 Instanzen) selbst kümmern. Darunter versteht man z.B. :

  • Erstellen der EC2 Instanz
  • Verbinden der Instanz zum ECS Cluster
  • Sicherstellen, dass genügend Ressourcen verfügbar sind
  • Verwalten des Betriebsystems, das auf der Instanz läuft
  • Docker & ECS Agents
ECS - Architektur

EC2 lässt sich schnell und einfach mit anderen AWS Services integrieren :

  • CloudWatch für das Monitoring
  • Elastic Load Balancer für das Load-balancing
  • IAM für Authentifizierung und Autorisierung

Elastic Kubernetes Cluster

Wenn wir ein EKS Cluster erstellen, werden automatisch die Kubernetes Master Nodes deployed und der Kubernetes Master Service darauf installiert. Diese Master Nodes sowie die Etcd Datei, die den Zustand und Konfiguration des Clusters beschreiben, werden auf alle Availability Zones der ausgewählten AWS Region repliziert.

EKS - Architektur

Für die Worker Nodes können wir, wie bei ECS, EC2 Instanzen benutzen, die wir zu unserem EKS Cluster verbinden. Die Kommunikation zwischen Control Plane (Master Nodes) und den VMs erfolgt über Kubernetes Worker Processes (Analog zum ECS Agent für ECS)

Nodegroups

Wenn wir uns mehr auf die Entwicklung der Anwendung und weniger auf die Infrastruktur fokussieren wollen, können wir entweder Fargate für eine fully-managed Compute-Fleet oder EC2 Instanzen benutzen. Es gibt allerdings eine dritte semi-managed Option – Nodegroups
Eine Nodegroup (Autoscaling group + zugehörige EC2 Instanzen) übernimmt das Provisioning und die Verwaltung der Lifecycles von Nodes (EC2 Instanzen) für EKS Clusters. Jede Nodegroup benutzt die Amazon EKS-optimized Amazon Linux 2 AMI. Außerdem werden alle Nodes einer Nodegroup automatisch markiert (tagged) für die auto-discovery vom Kubernetes Cluster auto-scaler. 

Fargate

AWS Fargate ist ein serverloser Compute Engine Dienst für Container, der uns die oben genannten Verantwortungen übernimmt.

Wenn wir ein Container an Fargate übergeben, wird der Service Analysen durchführen, um zu schätzen, wie viel Ressourcen (CPU, RAM, …) dieser Container benötigt. Anhand dieser Informationen wird dann automatisch ein Server instanziiert, worauf der Container letztlich laufen wird. Damit müssen wir uns nicht mehr um die EC2 Instanzen kümmern und werden nur für die Ressourcen bezahlen, die unsere Container auch benötigt.

Der Nachteil eines solchen Einsatzes ist es, dass wir unflexibel sind, wenn wir mehr Konfiguration und Kontrolle über die VMs brauchen. In diesem Fall sind EC2 Instanzen eher zu empfehlen.

EC2 Spot

Spot Instanzen sind nicht genutzte EC2 Instanzen, die den AWS Kunden als Kaufoption mit erheblichen Ermäßigungen (bis zu 90%) zur Verfügung gestellt werden.

Spot Allocation Strategies

Es gibt zwei Strategien bzw. Möglichkeiten, wie Spot Instanzen bei einer Spot-Anfrage zur Verfügung gestellt werden können.

Lowest-price

Nimmt Instanzen aus dem Spot Instance Pool, die den niedrigsten Preis verlangen. Wenn der Preis sich ändert, wird die Instanz terminiert und durch eine billigere (falls vorhanden) ersetzt.

Capacity-optimized

Nimmt Instanzen aus dem Spot Instance Pool mit optimaler Kapazität, ohne Rücksicht auf den Preis. Im Gegensatz zu der lowest-price Strategie, wird die Änderung des Preises für eine Instanz nicht zu einer Terminierung führen.

EKS mit EC2 Spot

Container überwachen und beobachten

In einer verteilten Architektur (z.B. Microservices) ist es extrem wichtig den Status aller aktiven Komponenten zu überwachen. Hierfür brauchen wir einen komplexeren Monitoring Service als bei einer monolithischen Anwendung, da eine einzige Anomalie einen entscheidenden Prozess beeinträchtigen könnte. In diesem Abschnitt stellen wir AWS Services vor die uns ermöglichen Anomalien auf Komponentenebene zu identifizieren, Metriken von verschiedenen Quellen der Anwendung zu sammeln und daraus Visualisierungen zu erstellen.

CloudWatch Container Insights

Container Insights stellt uns Diagnoseinformationen und Metriken bereit (CPU, Memory, Network, Container Restart Failures, etc….). Aus diesen Metriken werden automatische Dashboards generiert, die uns helfen auftretende Probleme zu identifizieren und isoliert zu behandeln. Dieser Service ermöglicht uns auch, Alarme zu definieren, falls bestimmte Metriken definierte Thresholds unter- oder überschreiten. Außerdem können wir eigene Metriken sammeln und persönliche Dashboards einrichten, um diese Metriken zu visualisieren.

Container Insights - Dashboards

Amazon X-Ray

Amazon X-Ray ist ein Service zum Analysieren und Debuggen verteilter Anwendungen, die z.B. über eine Microservice Architektur verfügen.

Der Service verfolgt ankommende Requests  auf dem Weg durch einzelne Komponenten der Anwendung. An jeder Stelle werden Daten und Ressourcen zusammengefasst, aus denen am Ende eine End-to-End Ansicht der kompletten Anwendung abgebildet werden kann. Dies ermöglicht uns Anomalien schneller und präziser zu identifizieren, dadurch dass wir feststellen können, an welchen Stellen diese Anomalien stattfinden.

Das folgende Diagramm soll den Prozess und seine einzelne Schritte von X-Ray veranschaulichen 

X-Ray - Flow Diagramm
1) Collect Traces

Informationen zu einer Webanfrage werden über die Anwendung hinweg von allen Services gesammelt.

2) Record Traces

Diese Daten werden zu einem sogenannten Trace kombiniert.

3) View Service Map

Aus diesen Traces wird eine Service Map erstellt, die die Verknüpfungen der Services darstellt. Zudem stellt uns diese Ansicht ein paar Informationen über die Services zur Verfügung (z.B. HTTP Status Codes, Latenz, andere Metadata, etc..)

4) Analyze Issues

Der Service, der ein unerwartetes Verhalten zeigt, kann nun anhand geeigneter Tools tiefer analysiert werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.