Erste Schritte mit Amazon EKS Auto Mode

Dieser Beitrag wurde gemeinsam von Alex Kestner (Sr Product Manager, Amazon EKS), Ashley Ansari (Sr. Product Marketing Manager), Robert Northard (Principal GTM SSA Containers) und Sheetal Joshi (Principal Solution Architect, Containers) verfasst.

Übersetzt von Bastian Klein

Einführung

Amazon Web Services (AWS) hat mit der Einführung von Amazon Elastic Kubernetes Service (EKS) Auto Mode einen bedeutenden Schritt in Richtung Vereinfachung des Kubernetes Cluster Managements unternommen. Diese neue Lösung zielt darauf ab, Kubernetes Cluster schneller einsatzbereit zu haben und die operative Komplexität für Unternehmen zu reduzieren.

Amazon EKS Auto Mode optimiert Cluster Management, in dem es automatisch Infrastruktur bereitstellt und skaliert, kontinuierlich Kosten optimiert, Betriebssysteme aktualisiert und eine Integration in AWS Security Services bietet. EKS Auto Mode konfiguriert das Cluster anhand von AWS Best-Practices, sodass Anwendungen direkt bereitgestellt werden können.

In diesem Beitrag erklären wir die Architektur von EKS Auto Mode und bieten Ihnen eine Anleitung, wie Sie eine hoch verfügbare und skalierende Beispielanwendung mit EKS Auto Mode bereitstellen.

Was ist neu?

Amazon EKS wird schon lange als sichere Methode gesehen, Kubernetes zu betreiben. Vor EKS Auto Mode mussten Kunden viel Zeit und Expertise investieren, um kontinuierlich die Infrastruktur für ihre Produktionsanwendungen zu verwalten. Nutzer hatten die Aufgabe, Wartungsarbeiten, wie etwa die Bereitstellung und Optimierung der richtigen Amazon Elastic Compute Cloud (Amazon EC2) Instanzen, Kostenoptimierung, oder die Installation und Aktualisierung von Plugins, durchzuführen. Zusätzlich musste weiterhin darauf geachtet werden, Cluster rechtzeitig auf den neusten Stand zu bringen und die Betriebssysteme der Amazon EC2 Instanzen zu aktualisieren. Folgendes Bild zeigt dies.

Vor Auto Mode

Vollautomatisierter Cluster-Betrieb bedeutet, dass EKS Auto Mode den Bedarf an spezialisiertem Fachwissen zur Verwaltung produktionsreifer Kubernetes-Infrastruktur reduziert und den Benutzern erheblich Zeit und Aufwand erspart. Anwender müssen keine Zeit und Ressourcen mehr für die Auswahl und Bereitstellung von EC2-Instanzen, die Optimierung von Ressourcen und Kosten sowie die Wartung von Plugins aufwenden.

Wenn Sie einen neuen EKS-Cluster erstellen oder einen bestehenden mit aktiviertem EKS Auto Mode aktualisieren, stellt Amazon EKS automatisch wesentliche Controller für Rechen-, Netzwerk- und Speicherfunktionen in AWS-Konten bereit.

EKS Auto Mode startet automatisch EC2-Instanzen basierend auf dem Bottlerocket-Betriebssystem und stellt Amazon Elastic Block Store (Amazon EBS)-Volumes in den AWS-Konten der Benutzer und in den vom Benutzer bereitgestellten VPCs bereit. EKS Auto Mode startet und verwaltet den Lebenszyklus dieser EC2-Instanzen, skaliert und optimiert die Datenebene entsprechend den sich ändernden Anwendungsanforderungen und ersetzt automatisch ungesunde Instanzen. Es bietet eine verwaltete Infrastruktur, ohne Ihnen die Tiefe und Breite der Amazon EC2-Funktionen vorzuenthalten, wie in der folgenden Abbildung dargestellt.

Mit Auto Mode

EKS Auto Mode ermöglicht es, dass Instanzfunktionen, die früher als Kubernetes DaemonSets ausgeführt wurden, nun als von AWS verwaltete Systemprozesse laufen. Dies umfasst Komponenten wie Service-Discovery, Service-Loadbalancer, Pod-Netzwerke, Blockspeicher und Berechtigungsbereitstellung. AWS übernimmt das Lifecycle-Management dieser Komponenten, einschließlich Updates für Sicherheitskorrekturen, und veröffentlicht eine neue Version des EKS Auto Mode Amazon Machine Image (AMI), das aktualisierte Komponenten für die unterstützte Kubernetes-Version enthält.

Darüber hinaus kümmert sich EKS Auto Mode automatisch um Cluster-Upgrades und Betriebssystem-Updates, indem die Instanzen unter Berücksichtigung der definierten Kubernetes Planungseinschränkungen ersetzt werden. Dies stellt sicher, dass Ihre Infrastruktur stets sicher und aktuell bleibt. Die erhebliche Reduzierung des betrieblichen Aufwands ermöglicht es, sich auf die Anwendungsentwicklung zu konzentrieren, anstatt sich mit der Infrastrukturverwaltung zu beschäftigen.

Erste Schritte

EKS Auto Mode ist für neue und bestehende EKS-Cluster verfügbar, die mit Version 1.29 oder höher laufen. Um mit EKS Auto Mode zu beginnen, können Sie das neue Konsolen Feature „Schnelle Konfiguration“ nutzen. Sie stellt einen Cluster mit sinnvoll voreingestellten Standardwerten bereit. Alternativ können Sie die Amazon EKS API, die AWS Management Console, eksctl oder Ihr bevorzugtes Infrastructure as Code (IaC)-Tool verwenden.

In diesem Abschnitt zeigen wir, wie EKS Auto Mode die Bereitstellung von Anwendungen auf Amazon EKS vereinfacht. Wir beginnen mit der Erstellung eines EKS-Clusters mit aktiviertem EKS Auto Mode und stellen dann eine Beispiel-Einzelhandelsanwendung bereit. Sie werden sehen, wie EKS Auto Mode automatisch neue Instanzen startet, AWS Load Balancer einrichtet, persistente Speicheranforderungen verwaltet und die Auto-Scaling-Anforderungen der Anwendung handhabt.

Voraussetzungen

Die folgenden Voraussetzungen sind notwendig, um die in diesem Beitrag beschriebenen Schritte erfolgreich durchführen zu können:

• Ein AWS Konto: Für diesen Beitrag nehmen wir an, dass Sie bereits ein AWS Konto mit Admin Berechtigungen besitzen
• Installieren Sie folgende Tools: Helm 3.9+, kubectl, eksctlund AWS Command Line Interface (AWS CLI).

Erstellen des Clusters

Für diesen Beitrag verwenden wir eksctl, ein Kommandozeilen-Tool, das die Erstellung eines EKS-Clusters erleichtert. Die folgende Beispielkonfiguration nutzt eksctl, um automatisch Cluster-Subnetze für die Cluster-Infrastruktur und Anwendungsbereitstellung zu generieren. Falls Sie nicht die Beispielkonfiguration verwenden, finden Sie im Amazon EKS Benutzerhandbuch eine vollständige Liste aller Voraussetzungen. Diese Voraussetzungen umfassen Änderungen an Cluster-IAM-Rollen und Knoten-IAM-Rollen. Diese stellen neue Berechtigungen für EKS Auto Mode bereit, um EC2-Instanzen in Ihrem Konto zu verwalten.

Wir aktivieren EKS Auto Mode mit integrierten verwalteten NodePools für Allgemeine- und Systemworkloads. Der NodePool für allgemeine Zwecke bietet Unterstützung für das Starten von Anwendungen, während der System-NodePool Add-ons verwaltet. Beide verwenden On-Demand EC2-Instanzen (Generation 5 oder neuer) aus den Familien C, M und R mit amd64-Architektur. Weitere Details zu integrierten NodePools finden Sie im EKS Auto Mode Benutzerhandbuch.

cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: eks-auto-mode-demo
  region: us-west-2
  version: "1.31"
  
addonsConfig:
  disableDefaultAddons: true  autoModeConfig:
  enabled: true
  nodePools: ["general-purpose", "system"]
  
EOF

eksctl create cluster -f cluster.yaml

Warten Sie bis der Cluster Zustand Aktiv anzeigt.

aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status'

Der Cluster ist nun bereit für die Bereitstellung von Anwendungen. Im nächsten Abschnitt zeigen wir, wie EKS Auto Mode die Anwendungsbereitstellung vereinfacht.

Bereitstellung einer Anwendung

Wir verwenden eine Beispiel-Einzelhandelsanwendung, bei der Benutzer einen Katalog durchsuchen, Artikel in ihren Warenkorb legen und eine Bestellung über den Checkout-Prozess abschließen können. Die Anwendung besteht aus mehreren Komponenten wie Benutzeroberfläche (UI), Katalog, Bestellungen, Warenkorb und Checkout-Services sowie einer Backend-Datenbank, die persistenten Blockspeicher benötigt und als Kubernetes Deployments und StatefulSets modelliert ist. Wir verwenden Kubernetes Ingress, um von außerhalb des Clusters auf die Anwendung zuzugreifen, und konfigurieren die Katalog-Anwendung so, dass sie Amazon EBS-persistenten Speicher nutzt. Um zu demonstrieren, wie EKS Auto Mode die Leistung verbessert, Skalierbarkeit bietet und die Verfügbarkeit erhöht, konfigurieren wir die UI-Anwendung so, dass sie horizontale Pod-Autoskalierung, Pod Topology Spread Constraints und Pod Disruption Budgets (PDBs) unterstützt.

Bevor wir die Anwendung bereitstellen, überprüfen wir den Cluster-Status.

kubectl get nodes
kubectl get pods

Die Listen der Instanzen und Pods sind leer.

Bevor wir mit der Anwendungsbereitstellung fortfahren, erstellen wir StorageClass und IngressClass. Diese Einrichtung stellt sicher, dass die notwendigen Infrastrukturkonfigurationen vorhanden sind, um die Speicher- und Ingress-Anforderungen für später bereitgestellte Anwendungen zu unterstützen. Typischerweise ist dies ein Schritt, der vom Plattform-Team einmalig nach der Erstellung des Clusters durchgeführt wird.

cat >ingress.yaml <<EOF
---
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: eks-auto-alb
spec:
  scheme: internet-facing
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: eks-auto-alb
spec:
  controller: eks.amazonaws.com/alb
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    name: eks-auto-alb
EOF

kubectl apply -f ingress.yaml
cat >ebs-sc.yaml <<EOF
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: eks-auto-ebs-csi-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
EOF
 
kubectl apply -f ebs-sc.yaml

Verwenden die helm für die Bereitstellung der Anwendung. Führen Sie den folgenden Befehl aus, um eine values.yaml Datei zu erstellen, die die zuvor festgelegten Anwendungsanforderungen spezifiziert:

cat >values.yaml <<EOF
catalog:
  mysql:
    secret:
      create: true
      name: catalog-db
      username: catalog
    persistentVolume:
      enabled: true
      accessMode:
        - ReadWriteOnce
      size: 30Gi
      storageClass: eks-auto-ebs-csi-sc

ui:
  endpoints:
    catalog: http://retail-store-app-catalog:80
    carts: http://retail-store-app-carts:80
    checkout: http://retail-store-app-checkout:80
    orders: http://retail-store-app-orders:80
    assets: http://retail-store-app-assets:80
  autoscaling:
    enabled: true
    minReplicas: 5
    maxReplicas: 10
    targetCPUUtilizationPercentage: 80
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  ingress:
    enabled: true
    className: eks-auto-alb
EOF

Stellen Sie die Einzelhandelsanwendung bereit. Beachten Sie bei der Bereitstellung die Konfiguration in der Datei values.yaml, insbesondere die Endpunkte für die Benutzeroberfläche (UI). Falls Sie einen anderen Chart-Namen als den Standard „retail-store-app“ gewählt haben, müssen Sie diese Endpunkte entsprechend aktualisieren.

helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3

EKS Auto Mode bewertet die Ressourcenanforderungen dieser Pods und bestimmt die optimale Rechenleistung für den Betrieb Ihrer Anwendungen, wobei die von Ihnen konfigurierten Planungseinschränkungen, einschließlich der topology spread constraints, berücksichtigt werden. Es verwendet den integrierten NodePool für allgemeine Zwecke, um Instanzen zu starten. Warten Sie, bis die Instanzen den Status „Ready“ erreichen.

kubectl wait --for=condition=Ready nodes --all

Beobachten Sie den Status der Applikation in einer anderen Kommandozeile.

kubectl wait --for=condition=available deployments --all

Die Komponenten der Einzelhandelsanwendung sollten sich nun im laufenden Zustand befinden.

Bei der Untersuchung des catalog-mysql-ebs StatefulSets können Sie sehen, dass EKS Auto Mode einen PersistentVolumeClaim mit 30 GiB und der storageClassName mit eks-auto-ebs-csi-sc erstellt und angehängt hat.

kubectl get statefulset retail-store-app-catalog-mysql \
  -o jsonpath='{.spec.volumeClaimTemplates}' | jq .
  
Output:
[
  {
    "apiVersion": "v1",
    "kind": "PersistentVolumeClaim",
    "metadata": {
      "creationTimestamp": null,
      "name": "data"
    },
    "spec": {
      "accessModes": [
        "ReadWriteOnce"
      ],
      "resources": {
        "requests": {
          "storage": "30Gi"
        }
      },
      "storageClassName": "eks-auto-ebs-csi-sc",
      "volumeMode": "Filesystem"
    }
  }
]

EKS Auto Mode hat automatisch einen Application Load Balancer (ALB) für die UI-Anwendung erstellt. Sie können den Namen des ALB mit dem folgenden Befehl ermitteln. Sobald der ALB bereit ist, können Sie den Link in Ihrem Webbrowser aufrufen. Sie sollten dann die Startseite der Einzelhandelsanwendung sehen.

kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"

Output:
k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com

Skalieren der Applikation

Nachdem Sie die Anwendung bereitgestellt haben, können Sie beobachten, wie EKS Auto Mode die Cluster-Infrastruktur skaliert, um die Anforderungen der Anwendung mithilfe von HorizontalPodAutoscaler (HPA) und Metrics-Server zu erfüllen. In Kubernetes passt ein HPA die Anzahl der Repliken in einem Deployment automatisch basierend auf beobachteten Metriken an. Der Metrics-Server sammelt CPU- und Speichernutzungsdaten des Kubelets und stellt sie dem HPA über den Kubernetes API-Server zur Verfügung. Der HPA überwacht diese Metriken kontinuierlich und passt die Anzahl der Repliken an, um das festgelegte Ziel zu erreichen.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

In diesem Beispiel verwenden wir den UI-Service und skalieren ihn basierend auf der CPU-Auslastung (80%) mit maximal 10 Repliken. Sie haben den HPA bereits als Teil des Anwendungs-Installationsschritts angewendet. Sehen Sie sich den Abschnitt „Auto Scaling“ in der Datei values.yaml an. Sie können die Auto-Scaling-Richtlinie mit dem folgenden Befehl nachlesen.

kubectl get hpa retail-store-app-ui

Generieren Sie Last, um zu beobachten, wie EKS Auto Mode die Cluster-Infrastruktur entsprechend der konfigurierten Auto-Scaling-Richtlinie hochskaliert.

kubectl run load-generator \
--image=public.ecr.aws/amazonlinux/amazonlinux:2023 \
--restart=Never -- /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done"

Sie haben nun Anfragen, die Ihre Anwendung erreichen. Beobachten Sie, wie neue Instanzen gestartet werden und mehr UI-Pods ausgeführt werden.

kubectl get nodes --watch

Output:
NAME                  STATUS   ROLES    AGE    VERSION
i-00018eaec7a3d5370   Ready    <none>   155m   v1.31.0-eks-672e808
i-043c71a371a8514a1   Ready    <none>   155m   v1.31.0-eks-672e808

Sie können den HPA mit folgendem Befehl beobachten.

kubectl get hpa retail-store-app-ui --watch

Output:
NAME                  REFERENCE                        TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 158%/80%   3         10        5          16m
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 161%/80%   3         10        6          16m
retail-store-app-ui   Deployment/retail-store-app-ui   cpu: 148%/80%   3         10        9          16m

Wie Sie sehen können, verwaltet EKS Auto Mode die Cluster-Infrastruktur vollständig und skaliert sie dynamisch basierend auf den Anforderungen der Anwendung. Sie können den Load-Generator beenden, indem Sie den Pod beenden. Wenn der Load-Generator beendet ist, reduziert der HorizontalPodAutoscaler langsam die Anzahl der Repliken auf die in seiner Konfiguration festgelegte Mindestanzahl.

kubectl delete pod load-generator

Wichtige Überlegungen

Hier sind einige Praktiken, die Sie bei der Bereitstellung von Workloads für Amazon EKS Auto Mode berücksichtigen sollten:

• Konfigurieren Sie Pod Disruption Budgets, um Workloads vor freiwilligen Unterbrechungen zu schützen: Bei freiwilligen Unterbrechungen, wie wenn EKS Auto Mode untergenutzte Instanzen außer Betrieb nimmt, helfen Pod Disruption Budgets dabei, die Rate zu kontrollieren, mit der Repliken eines Deployments unterbrochen werden. Dies trägt dazu bei, eine gewisse Kapazität beizubehalten, um weiterhin Anfragen bedienen zu können.
• Planen Sie Repliken über Instanzen und Verfügbarkeitszonen für hohe Verfügbarkeit: Verwenden Sie Pod Topology Spread Constraints, um Workloads über Instanzen zu verteilen und die Wahrscheinlichkeit zu minimieren, dass mehrere Repliken eines Deployments auf demselben Instanzen ausgeführt werden.
• Konfigurieren Sie angemessene Ressourcenanforderungen und -limits: EKS Auto Mode startet EC2-Instanzen basierend auf den vCPU- und Speicheranforderungen der Workloads. Ressourcenanforderungen müssen sorgfältig konfiguriert werden, da sonst Ressourcen überdimensioniert werden könnten. EKS Auto Mode berücksichtigt keine Ressourcenlimits oder die tatsächliche Nutzung.
• Anwendungen müssen “graceful shutdowns” unterstützen: Ihre Anwendung muss in der Lage sein, durch die Behandlung eines SIGTERM-Signals ordnungsgemäß herunterzufahren, um Arbeitsverluste oder Unterbrechungen der Endbenutzererfahrung während freiwilliger Unterbrechungen zu vermeiden. Wenn ein Kubernetes-Pod zur Räumung ausgewählt wird, wird ein SIGTERM-Signal an den Hauptprozess jedes Containers in den zu räumenden Pods gesendet. Nach dem Senden des SIGTERM-Signals gibt Kubernetes dem Prozess eine gewisse Zeit (Übergangszeit), bevor ein SIGKILL-Signal gesendet wird. Diese Übergangszeit beträgt standardmäßig 30 Sekunden. Sie können den Standardwert überschreiben, indem Sie terminationGracePeriodSeconds in Ihrer Pod-Spezifikation deklarieren.
• Vermeiden Sie übermäßige Einschränkungen bei der Auswahl von Rechenressourcen: Der NodePool für allgemeine Zwecke von EKS Auto Mode diversifiziert über verschiedene Amazon EC2-Familien (c, m, r) unterschiedlicher Größen, um die Möglichkeit zu maximieren, eine passende EC2-Instanz für einen Workload auszuwählen. Für Workloads mit spezifischen Rechenanforderungen können Sie bekannte Kubernetes-Labels verwenden, damit Pods beim Erstellen von Instanzen nur bestimmte Instanztypen, Architekturen oder andere Attribute anfordern können.

Weitere Informationen zu Anwendungs-Best-Practices finden Sie im Abschnitt Zuverlässigkeit des Amazon EKS Best Practices Guide.

Aufräumen

Um zukünftige Kosten zu vermeiden, löschen Sie die im Rahmen dieses Beitrags erstellten Ressourcen:

kubectl delete deploy -n kube-system metrics-server 

helm uninstall retail-store-app

kubectl delete pvc/data-retail-store-app-catalog-mysql-0

eksctl delete cluster --name eks-auto-mode-demo

Fazit

Amazon EKS Auto Mode bietet sofort einsatzbereite Rechen-, Speicher- und Netzwerkfunktionen und beseitigt damit die Komplexität, die mit der Anwendungsbereitstellung verbunden ist. Ob Sie einen neuen Cluster erstellen oder einen bestehenden aktualisieren – EKS Auto Mode bietet eine optimierte Erfahrung, die nicht nur die Cluster-Infrastruktur verwaltet, sondern auch zentrale Cluster-Funktionen bereitstellt und gleichzeitig konform mit dem Upstream-Kubernetes bleibt.

EKS Auto Mode ergänzt die bestehenden Amazon EKS-Angebote und bietet Flexibilität für unterschiedliche Workloads. Benutzer mit speziellen Anforderungen können weiterhin traditionelle Amazon EKS-Rechenoptionen nutzen, die benutzerdefinierte Kubernetes-Cluster-Konfigurationen, manuelle Bereitstellung und Verwaltung der Cluster-Infrastruktur sowie detaillierte Kontrolle über die Kubernetes-Umgebung ermöglichen. Die Unterstützung sowohl des Auto Mode als auch der traditionellen Optionen bedeutet, dass Amazon EKS ein breites Spektrum an Anwendungsfällen abdeckt – sowohl für diejenigen, die Einfachheit und reduzierten Betriebsaufwand suchen, als auch für jene, die eine angepasste/detaillierte Kontrolle über ihre Kubernetes-Umgebung benötigen.

Weitere Informationen zu den Funktionen von EKS Auto Mode finden Sie in der Amazon EKS-Dokumentation. Um EKS Auto Mode in Aktion zu sehen und Ihre Fragen von AWS-Experten beantwortet zu bekommen, registrieren Sie sich für unsere kommende Webinar-Reihe „Simplifying Kubernetes operations with Amazon EKS Auto Mode“.