ECS gegen EKS: Welcher AWS Container Service ist der richtige für dich?

Was ist ECS?

ECS ist Amazons eigenertary managed container orchestration service. Es bietet eine einfache und sichere Möglichkeit, containerisierte Anwendungen auszuführen. ECS ist auf Einfachheit ausgelegt und reduziert die Entscheidungen der Kunden in Bezug auf Computer-, Netzwerk- und Sicherheitskonfigurationen, ohne dass sie Abstriche bei der Größe oder den Funktionen machen müssen.

Es gibt ein paar Begriffe und Komponenten, mit denen du dich bei ECS vertraut machen musst.

1. Cluster
2. Kapazitätsanbieter
3. Aufgabenstellung
4. Aufgabe
5. Service

Cluster

Ein ECS-Cluster umfasst Dienste, Aufgaben und Kapazitätsanbieter. Sie enthält auch die ECS-Kontrollebene, die von AWS verwaltet wird und für uns nicht sichtbar ist.

Kapazitätsanbieter

Container brauchen einen Server, auf dem sie laufen, sei es eine virtuelle Maschine in der Cloud oder dein lokaler Computer. Im Zusammenhang mit ECS kannst du den "Launch Type" auswählen, um deine Container auf Elastic Compute Cloud (EC2) oder Fargate auszuführen.

Registerkarte Infrastruktur der AWS ECS-Konsole.

Aufgabe

Eine Aufgabe ist ein Satz von laufenden Containern, die gemäß einer Aufgabendefinition konfiguriert sind. Im Wesentlichen stellt er eine Instanz einer Aufgabendefinition dar, ähnlich wie ein Container als Instanz eines Bildes dient.

Aufgabenstellung

Wir haben ein Dockerfile für unsere Anwendung und daraus ein Image erstellt. Wir haben das Image in eine Container-Registry wie DockerHub oder AWS ECR übertragen. Was nun? Wir erstellen eine Aufgabendefinition, die eine Konfiguration oder ein Blueprint für unsere Container (die auf einem ECS-Cluster eingesetzt werden sollen) ist und die folgenden Informationen enthält:

• Bild(er). Eine Aufgabe kann mehr als ein Bild enthalten.
• Die Portnummer, die für die Kommunikation mit unserer Anwendung verwendet wird.
• Bände.
• Ressourcen (CPU und Speicher), die wir für unsere Anwendungen reservieren.

Aufgabendefinition in der AWS ECS-Konsole.

Service

Was passiert, wenn wir einen eigenständigen Container starten und er abstürzt? Nichts passiert. Es bleibt im Zustand des Absturzes. Dieses Verhalten ist identisch, wenn wir eine eigenständige Aufgabe auf ECS erstellen. Wir nutzen den ECS-Service, um sicherzustellen, dass unsere Anwendungen immer verfügbar sind. Ein Dienst sorgt dafür, dass eine gewünschte Anzahl von Aufgaben jederzeit verfügbar ist.

Wenn eine Aufgabe abstürzt oder der zugrundeliegende Server (und damit der Container) ausfällt, erstellt der Dienst eine neue Aufgabe bei einem verfügbaren Kapazitätsanbieter.

Implementierung von ECS

Nachdem wir nun die Grundlagen von ECS kennengelernt haben, wollen wir ein einfaches Nginx-Image starten und darauf zugreifen. Mit dem oben genannten ECS-Cluster und der Aufgabendefinition werde ich einen Dienst erstellen, der auf die Aufgabendefinition verweist:

Services in der AWS ECS-Konsole.

Dieser Dienst wird wiederum eine Aufgabe erstellen.

Eine Aufgabe in der AWS ECS-Konsole.

Zugriff auf die öffentliche IP-Adresse der Aufgabe:

Erfolgreicher Zugriff auf die Anwendung, die auf dem ECS läuft.

Was ist EKS?

Bevor du dich mit Elastic Kubernetes Service(EKS) beschäftigst, musst du verstehen, was Kubernetes ist. Kubernetes ist eine Open-Source-Container-Orchestrierungs-Engine, die die Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen automatisiert. 

Wenn du mehr erfahren möchtest, empfehle ich dir den Kurs Einführung in Kubernetes. 

Das Booten und Verwalten eines Kubernetes-Clusters von Grund auf kann jedoch komplex und zeitaufwändig sein. Viele Komponenten und Konfigurationen, die für die Einrichtung von Kubernetes erforderlich sind, sind in allen Organisationen und Teams ähnlich. Um diese undifferenzierte Schwerstarbeit zu abstrahieren und die Einführung von Kubernetes zu vereinfachen, hat AWS EKS entwickelt.

EKS ist ein verwalteter Kubernetes-Service von AWS, der einen Großteil des betrieblichen Aufwands übernimmt. Sie vereinfacht die Kubernetes-Bereitstellung, -Skalierung und -Verwaltung, indem sie die Kontrollebene im Namen der Nutzer verwaltet. Durch die Abstraktion der Notwendigkeit, diese Komponenten zu verwalten, ermöglicht Amazon EKS den Nutzern, sich auf die Ausführung ihrer containerisierten Arbeitslasten und die Verwaltung von Arbeitsknoten oder Fargate-Aufgaben zu konzentrieren.

In diesem Abschnitt wird kurz auf EKS eingegangen. Mehr unter, siehe den Artikel Grundlagen der Container-Orchestrierung mit AWS Elastic Kubernetes Service (EKS).

Es gibt ein paar Begriffe und Komponenten, mit denen du dich für EKS vertraut machen musst:

1. Cluster (Master- und Worker-Knoten)
2. Manifest-Dateien
3. Pods
4. ReplicaSet
5. kubectl Kommandozeilen-Dienstprogramm

Cluster

Ein Kubernetes-Cluster ist eine Gruppe von Servern oder virtuellen Maschinen, auf denen die Kubernetes-Workloads laufen. Sie besteht aus dem Master-Knoten (gemeinhin als Steuerebene bezeichnet) und Worker-Knoten. 

In EKS wird der Master-Knoten von AWS in seiner eigenen VPC verwaltet; er ist von uns abstrahiert. In der Zwischenzeit können wir die Worker Nodes über EC2-Instanzen verwalten oder mit Fargate serverlos arbeiten.

EKS Control Plane Netzwerkkonnektivität. Bildquelle: AWS

Pods

Ein Pod ist eine Kubernetes-API-Ressource. Sie sind die kleinsten einsatzfähigen Einheiten in Kubernetes. Sie sind eine Gruppe von einem oder mehreren Containern und enthalten Angaben über das zu verwendende Image, den Port, die Befehle usw.

Registerkarte Ressourcen in der AWS EKS-Konsole.

ReplicaSet

Genau wie ein Pod ist auch ein ReplicaSet eine Kubernetes-API-Ressource. So wird sichergestellt, dass immer die gewünschte Anzahl von Pods läuft.

Manifest-Dateien

Kubernetes-Manifestdateien sind Konfigurationsdateien, die dazu dienen, den gewünschten Zustand von Kubernetes-Ressourcen deklarativ zu definieren. Diese Dateien beschreiben, welche Ressourcen in einem Kubernetes-Cluster vorhanden sein sollen, ihre Konfigurationen und wie sie miteinander interagieren.

Manifestdateien werden normalerweise in YAML geschrieben:

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Kommandozeilenprogramm zur Kommunikation mit dem Kubernetes-Cluster. Wir können den Befehl kubectl verwenden, um Kubernetes-Ressourcen zwingend zu erstellen, zu verwalten und zu löschen, oder ihn zusammen mit den Manifestdateien deklarativ verwenden.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Implementierung von EKS

Lass uns nun demonstrieren, wie EKS funktioniert, indem wir das gleiche Nginx-Image ausführen und darauf zugreifen. 

Der Einfachheit halber werde ich eine EC2-Instanz/einen Worker Node in einem öffentlichen Subnetz erstellen, die Anwendung dort bereitstellen, sie über eine Kubernetes-Service-Ressource vom Typ NodePort bereitstellen und über die öffentliche IP der Instanz darauf zugreifen. 

Ich verwende das Pod- und Servicemanifest oben und den Befehl kubectl, um den Pod zu erstellen:

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

Der EKS-Cluster hat eine EC2-Instanz:

EC2-Instanz/Arbeitsknoten.

Finde die öffentliche IPv4-Adresse der Instanz.

Die öffentliche IP-Adresse der EC2-Instanz/des Worker Nodes.

Zugriff auf die öffentliche IP-Adresse der Instanz mit dem Port 31000:

Erfolgreicher Zugriff auf die Anwendung, die auf dem EKS läuft.

ECS vs. EKS: Ähnlichkeiten

Nachdem wir nun die Grundlagen von ECS und EKS behandelt haben, können wir einige Gemeinsamkeiten zwischen ihnen erkennen. Das ist nicht überraschend, da es sich bei beiden um Tools zur Container-Orchestrierung handelt.

Rechenleistung

Beide Dienste ermöglichen es, Anwendungen auf EC2 laufen zu lassen, wobei die Benutzer für die Wartung, das Patchen und das Upgraden der EC2-Instanzen verantwortlich sind, oder auf AWS Fargate, der serverlosen Rechenoption, bei der AWS die zugrunde liegenden Server verwaltet, sodass keine Infrastrukturverwaltung erforderlich ist.

Workload Management Modell

Beide Dienste haben ähnliche Strukturen und Ansätze zur Verwaltung und Pflege von Anwendungsressourcen.

In AWS ECS wird die Konfiguration, die festlegt, wie Container ausgeführt werden sollen, als Aufgabendefinition bezeichnet, während dies in AWS EKS durch eine Pod-Manifestdatei erreicht wird. Nach der Bereitstellung läuft die containerisierte Anwendung in ECS innerhalb einer Aufgabe, während sie in EKS innerhalb eines Pods läuft. Um sicherzustellen, dass eine bestimmte Anzahl von Aufgaben oder Pods immer läuft, verwendet ECS einen Dienst, während EKS für diese Funktion auf ein Replikat-Set zurückgreift.

Tiefe Integration mit anderen AWS-Services

Als Containerdienst auf AWS hat Amazon große Anstrengungen unternommen, um sicherzustellen, dass ECS und EKS gut mit anderen AWS-Diensten zusammenarbeiten. 

Für die Vernetzung gibt es Amazon VPC, mit dem Container in isolierten Umgebungen mit voller Kontrolle über Netzwerkkonfigurationen, Sicherheitsgruppen und Subnetze laufen können. Load Balancer für die Weiterleitung des Datenverkehrs an Container. 

Lösungen wie EBS, EFS und S3 sind verfügbar, um die Anforderungen an persistenten Speicher für containerisierte Anwendungen zu erfüllen.

Beide Dienste nutzen AWS IAM, um den Zugriff und die Berechtigungen granular zu steuern. Damit wird festgelegt, auf welche AWS-Ressourcen die containerisierte Anwendung zugreifen kann, z. B. S3, DynamoDB oder RDS.

Zusammenfassung der wichtigsten Gemeinsamkeiten

ECS vs. EKS: Unterschiede

Es ist wichtig, die Unterschiede zwischen Amazon ECS und Amazon EKS zu verstehen, wenn du dich zwischen ihnen entscheiden willst. 

In diesem Abschnitt werden wir ihre Hauptunterschiede in Bezug auf Benutzerfreundlichkeit, Skalierbarkeit, Anpassung und Kosten aufschlüsseln und dir dabei helfen, herauszufinden, welcher Dienst am besten zu deinen technischen Anforderungen und Geschäftszielen passt.

Benutzerfreundlichkeit und Lernkurve

EKS baut auf Kubernetes auf. Daher ist eine Vertrautheit mit Kubernetes-Konzepten und -Tools erforderlich. Die Lernkurve für EKS wird also steiler sein als für ECS. Dazu musst du verstehen, wie der Befehl kubectl funktioniert und einige andere grundlegende Kubernetes-API-Ressourcen wie Services (nicht zu verwechseln mit dem Begriff "Services", der im Zusammenhang mit ECS verwendet wird), Config Maps, Ingress usw. Der Abschnitt "Was ist EKS" oben kratzt kaum an der Oberfläche dessen, was EKS bietet.

ECS und EKS erfordern Kenntnisse über AWS-Dienste wie CloudWatch, IAM, ASG usw. Zum Glück ist das alles für ECS nötig, aber nicht für EKS. ECS gewinnt also in Bezug auf die Benutzerfreundlichkeit.

Skalierbarkeit

Beide Dienste können gleich gut skalieren, wenn sie richtig konfiguriert sind. Wie sie skalieren, ist jedoch unterschiedlich. ECS unterstützt Autoscaling über ECS Service Auto Scaling für Aufgaben und ECS Cluster Auto Scaling für Instanzen. Sie nutzt nur AWS-eigene Dienste wie CloudWatch-Metriken und ASG-Skalierungsrichtlinien.

EKS nutzt jedoch Kubernetes-eigene Skalierungsfunktionen, wie den Horizontal Pod Autoscaler (HPA) für Pods und den Cluster Autoscaler für Instanzen. Der Cluster Autoscaler ist nicht standardmäßig auf dem EKS-Cluster installiert und muss daher vom Benutzer selbst installiert werden. Dies erhöht die Komplexität, da sowohl für die AWS-Ressourcen (z. B. IAM-Rollen) als auch für die Kubernetes-API-Ressourcen (z. B. Servicekonten) die richtige Konfiguration erforderlich ist, damit der Cluster Autoscaler funktioniert.

Eine kürzlich eingeführte neue Funktion für EKS, EKS AutoMode, kann diese zusätzliche Komplexität beseitigen. Es verlagert die Verwaltung und Skalierung der EKS-Arbeitsknoten zu AWS, ist aber mit zusätzlichen Kosten verbunden.

Flexibilität und Anpassungsfähigkeit

Wie bereits erwähnt, ist ECS Amazons eigener verwalteter Container-Orchestrierungsdienst, der auf Einfachheit ausgelegt ist. AWS übernimmt die meisten Aufgaben der Cluster-Verwaltung und bietet vordefinierte Konfigurationen an, die für gängige Container-Workloads geeignet sind, aber möglicherweise keine Nischenanforderungen erfüllen. Das reduziert zwar die Komplexität, schränkt aber die Anpassungsmöglichkeiten im Vergleich zu Kubernetes ein.

EKS bietet die volle Leistungsfähigkeit von Kubernetes und ermöglicht es Nutzern, Deployments, Pod-Planung, Speicherklassen und Netzwerkrichtlinien an ihre Bedürfnisse anzupassen. Erweiterte Orchestrierungsfunktionen wie benutzerdefinierte Ressourcendefinitionen (CRDs) und Operatoren ermöglichen eine beispiellose Flexibilität bei der Anwendungsentwicklung. 

EKS kann auch mit verschiedenen Open-Source-Tools und Plugins aus dem Kubernetes-Ökosystem wie Prometheus, Grafana und Istio integriert werden, so dass Entwickler maßgeschneiderte Lösungen entwickeln können. Damit gewinnt EKS den Wettbewerb um Flexibilität und Anpassungsfähigkeit.

Kosten

Zusätzlich zu den Standardkosten für Netzwerkressourcen (z. B. öffentliche IPv4-Adressen, NAT-Gateways) und Rechen- und Speicherressourcen (z. B. EC2-Instanzen, Fargate und EBS-Volumes), die sowohl für ECS als auch für EKS gelten, ECS hat niedrigere Kosten und eine viel einfachere Kostenstruktur.

Für die ECS-Kontrollebene fallen keine Gebühren an. Mit anderen Worten: Wenn du einen ECS-Cluster ohne laufende Aufgaben erstellen würdest, würden dir keine Kosten entstehen. Bei EKS fallen hingegen Kosten für die von AWS verwaltete Kontrollebene an, unabhängig davon, ob du Anwendungen im Kubernetes-Cluster laufen hast.

Die Kosten für die EKS-Kontrollebene variieren je nach der verwendeten Kubernetes-Version. Eine Kubernetes-Version mit Standard-Support kostet $0,10 pro Cluster und Stunde, während eine Version mit erweitertem Support $0,60 pro Cluster und Stunde kostet.

Zusammenfassung der wichtigsten Unterschiede

Wann sollte man ECS wählen?

Die Wahl hängt von den Anforderungen deiner Anwendung, den Geschäftszielen, der Expertise deines Teams, dem Betriebsbudget und den allgemeinen Prioritäten ab.

Da ECS einfacher und kostengünstiger ist, eignet es sich ideal für Teams mit knapperen Budgets, kürzeren Markteinführungszeiten und einer Vorliebe für schlanke Abläufe. Sie eignet sich besonders gut für Anwendungen, die keine Portabilität über mehrere Clouds oder hybride Umgebungen hinweg benötigen, und ist ausschließlich für den Betrieb auf AWS konzipiert. Als AWS-spezifischer Service passt sich ECS nahtlos an die Arbeitslasten an, die auf das AWS-Ökosystem beschränkt sind.

Sowohl ECS als auch EKS unterstützen Fargate für serverlose Container-Implementierungen, wobei ECS eine einfachere Integration bietet. Mit ECS kannst du direkt Aufgaben auswählen, die auf Fargate ausgeführt werden sollen, ohne zusätzliche Konfiguration. Im Gegensatz dazu müssen bei Fargate mit EKS Pod-Labels festgelegt werden, um zu bestimmen, welche Workloads auf Fargate laufen sollen, was die Komplexität erhöht. Das macht ECS zu einer attraktiven Wahl für Teams, die eine einfachere serverlose Erfahrung suchen.

Wann solltest du dich für EKS entscheiden?

Kubernetes, die Plattform, die EKS zugrunde liegt, ist Cloud-agnostisch und ermöglicht die konsistente Ausführung von Arbeitslasten bei AWS, anderen Cloud-Anbietern und in lokalen Umgebungen. Diese Portabilität ist besonders für Unternehmen von Vorteil, die in Multi-Cloud-Konfigurationen oder hybriden On-Premises-Infrastrukturen arbeiten. Azure und Google Cloud bieten auch verwaltete Kubernetes-Dienste an - Azure Kubernetes Service (AKS) bzw. Google Kubernetes Engine (GKE) - was die Allgegenwart von Kubernetes in modernen Cloud-Umgebungen unterstreicht.

EKS ist ideal, wenn deine Anwendung oder dein Anwendungsfall erweiterte Anpassungen und Erweiterungen erfordert. Kubernetes unterstützt zum Beispiel die Erstellung von Custom Resource Definitions (CRDs), mit denen du benutzerdefinierte Ressourcen zur Verwaltung bestimmter Anwendungskonfigurationen oder zur Integration mit externen Systemen definieren kannst. Diese Flexibilität ist ein wichtiges Unterscheidungsmerkmal für EKS.

Auch wenn EKS die Kontrollebene abstrahiert und sich bei der Verwaltung auf AWS verlässt, erfordert der effektive Betrieb in einer EKS-Umgebung dennoch Vertrautheit mit den Kubernetes-API-Ressourcen und -Konzepten. Daher ist die Kubernetes-Expertise des Teams entscheidend, um die Plattform effektiv zu nutzen.

EKS bietet außerdem eine breite Palette von anpassbaren Add-ons, die installiert werden können, um die Funktionalität des Clusters zu erweitern. Diese Add-ons erleichtern die Ausstattung eines Clusters mit den notwendigen operativen Tools, vereinfachen die Einrichtung und steigern die Produktivität.

EKS Add-ons Auswahl.

Zusammenfassend lässt sich sagen, dass EKS gut geeignet ist für Microservices-Architekturen oder Anwendungen mit zahlreichen miteinander verbundenen Komponenten, die eine hohe Kontrolle und Granularität erfordern. Das ist besonders vorteilhaft für Teams, die erweiterte Anpassungsoptionen benötigen oder in Umgebungen arbeiten, in denen die Übertragbarkeit von Arbeitslasten wichtig ist.

ECS vs. EKS-Entscheidungsflussdiagramm. Bild vom Autor.

Tools und Integrationen

Egal, ob es sich um eine containerisierte Anwendung oder eine Anwendung handelt, die direkt auf einer VM läuft, Überwachung und Beobachtbarkeit sind von größter Bedeutung. Durch ihre Zugehörigkeit zum AWS-Ökosystem können sowohl ECS als auch EKS auf AWS-Tools und Dienste von Drittanbietern zurückgreifen, um den gesamten Softwareentwicklungszyklus (SDLC) für containerisierte Anwendungen zu verbessern.

Überwachung und Protokollierung

Überwachung und Protokollierung sind unerlässlich, um einen Überblick über deine Anwendungen und deine Infrastruktur zu erhalten. AWS bietet native Tools und unterstützt Integrationen von Drittanbietern sowohl für ECS als auch für EKS, wie Amazon CloudWatch für Metriken, Protokolle und Alarme. 

AWS X-Ray zum Verfolgen von Anfragen über Microservices hinweg macht es einfach, Leistungsprobleme in ECS-Aufgaben oder EKS-Pods zu analysieren und zu beheben. Tools von Drittanbietern wie Datadog, Prometheus, Grafana und New Relic bieten erweiterte Visualisierungs- und Alarmierungsfunktionen, die auf Container zugeschnitten sind.

CI/CD-Pipelines

CI/CD-Pipelines helfen dabei, Tests, Scans und Deployments zu automatisieren und sorgen so für schnellere Iterationen und weniger manuellen Aufwand. Beliebte CI/CD-Tools wie GitLab-Pipelines und GitHub Actions lassen sich in ECS und EKS integrieren, um Container-Builds, Tests und Deployments zu ermöglichen. Diese Tools arbeiten mit Docker-Containern für ECS oder Helm-Charts für EKS.

Infrastruktur als Code (IaC)

IaC ist entscheidend für die Schaffung einer konsistenten und wiederholbaren Infrastruktur, die Minimierung der Bereitstellungszeit und die Verringerung des Risikos menschlicher Fehler im Zusammenhang mit manuellen Konfigurationen über die AWS Management Console. 

Beliebte IaC-Tools sind Terraform und AWS CloudFormation. Obwohl beide weit verbreitet sind, wird Terraform oft wegen seiner Cloud-agnostischen Fähigkeiten bevorzugt, die es Teams ermöglichen, ihre Infrastruktur über mehrere Cloud-Anbieter hinweg mit einem einzigen Tool zu verwalten.

Vernetzung und Sicherheit

AWS bietet robuste Netzwerk- und Sicherheitsfunktionen für ECS und EKS, um eine sichere Kommunikation und Zugriffskontrolle zu gewährleisten, wie z.B. AWS VPC-Netzwerke zur Isolierung von Ressourcen innerhalb privater Subnetze. AWS WAF und Shield: Schütze Anwendungen, die auf ECS und EKS gehostet werden, vor gängigen Webschwachstellen und DDoS-Angriffen. AWS KMS zur Verschlüsselung von EBS-Volumes und Kubernetes-Geheimnissen, die in etcd gespeichert sind.

Fazit

ECS und EKS sind beides robuste Container-Orchestrierungsdienste von AWS, die jeweils auf unterschiedliche Anwendungsanforderungen und Teamprioritäten zugeschnitten sind. 

ECS ist einfacher zu starten, einfacher bereitzustellen, einzusetzen und zu warten und hat geringere Betriebskosten. Im Gegensatz dazu hat EKS eine steilere Lernkurve und eine höhere anfängliche Komplexität, bietet aber eine unübertroffene Flexibilität und fortschrittliche Anpassungsoptionen, was es ideal für Teams mit speziellen oder komplexen Anforderungen macht. 

Die Wahl zwischen ECS und EKS hängt von den Anforderungen deiner Anwendung, der Expertise des Teams und der gewünschten Balance zwischen Einfachheit und Kontrolle ab.

Wenn du deine AWS-Kenntnisse vertiefen möchtest, ist der AWS-Konzepte-Kurs ein guter Startpunkt. Wenn du tiefer in die AWS-Tools und -Technologien eintauchen möchtest, schau dir den Kurs AWS Cloud Technology and Services an. Außerdem bietet der Lernpfad "Containerisierung und Virtualisierung " denjenigen, die sich für die Containerisierung interessieren, wertvolle Einblicke, um die Verwaltung und den Einsatz von Containern zu verbessern.