Erfahren Sie mehr über Zonal Shift von Amazon Application Recovery Controller (ARC) in Amazon EKS

Hilf mit, diese Seite zu verbessern

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Hilf mit, diese Seite zu verbessern

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kubernetes verfügt über native Funktionen, mit denen Sie Ihre Anwendungen widerstandsfähiger gegen Ereignisse wie den verschlechterten Zustand oder die Beeinträchtigung einer Availability Zone (AZ) machen können. Wenn Sie Ihre Workloads in einem Amazon EKS-Cluster ausführen, können Sie die Fehlertoleranz und Anwendungswiederherstellung Ihrer Anwendungsumgebung mit Zonal Shift oder Zonal Autoshift von Amazon Application Recovery Controller (ARC) weiter verbessern. ARC Zonal Shift ist als vorübergehende Maßnahme konzipiert, mit der Sie den Verkehr für eine Ressource von einer beeinträchtigten AZ wegverlagern können, bis die Zonenverschiebung abläuft oder Sie sie stornieren. Sie können die Zonenverschiebung bei Bedarf verlängern.

Sie können eine Zonenverschiebung für einen EKS-Cluster starten, oder Sie können es für AWS sich selbst erledigen lassen, indem Sie Zonal Autoshift aktivieren. Durch diese Verschiebung wird der east-to-west Netzwerkdatenverkehr in Ihrem Cluster aktualisiert, sodass nur Netzwerkendpunkte für Pods berücksichtigt werden, die auf Worker-Knoten ausgeführt werden, die fehlerfrei sind. AZs Darüber hinaus leitet jeder ALB oder NLB, der den eingehenden Datenverkehr für Anwendungen in Ihrem EKS-Cluster verarbeitet, den Datenverkehr automatisch an fehlerfreie Ziele weiter. AZs Für Kunden, die die höchsten Verfügbarkeitsziele anstreben, kann es für den Fall, dass eine AZ beeinträchtigt wird, wichtig sein, den gesamten Datenverkehr von der beeinträchtigten AZ fernzuhalten, bis er wieder hergestellt ist. Zu diesem Zweck können Sie auch eine ALB oder NLB mit ARC-Zonenverschiebung aktivieren.

Grundlegendes zum Ost-West-Netzwerkdatenverkehr zwischen Pods

Das folgende Diagramm zeigt zwei Beispiele für Workloads: Bestellungen und Produkte. In diesem Beispiel soll gezeigt werden, wie Workloads und Pods in verschiedenen AZs Umgebungen miteinander kommunizieren.

Grundlegendes zu ARC Zonal Shift in Amazon EKS

Falls es in Ihrer Umgebung zu einer Beeinträchtigung der AZ-Verfügbarkeit kommt, können Sie eine Zonenverschiebung für Ihre EKS-Cluster-Umgebung einleiten. Alternativ können AWS Sie sich dies mit Zonal Autoshift selbst vornehmen lassen. Mit Zonal Autoshift AWS wird der gesamte Zustand der AZ überwacht und auf eine mögliche Beeinträchtigung der AZ reagiert, indem der Verkehr in Ihrer Cluster-Umgebung automatisch von der beeinträchtigten AZ weggeleitet wird.

Sobald Ihr Amazon EKS-Cluster Zonal Shift mit ARC aktiviert hat, können Sie mit der ARC-Konsole, der AWS CLI oder Zonal Shift und Zonal Autoshift eine Zonal Shift auslösen oder Zonal Autoshift aktivieren. APIs Während einer EKS-Zonenverschiebung findet automatisch Folgendes statt:

Die folgenden Diagramme zeigen auf grober Ebene, wie EKS Zonal Shift sicherstellt, dass nur funktionsfähige Pod-Endpunkte in Ihrer Cluster-Umgebung ins Visier genommen werden.

Anforderungen an EKS Zonal Shift

Damit Zonal Shift in EKS erfolgreich funktioniert, müssen Sie Ihre Cluster-Umgebung zuvor so einrichten, dass sie gegen eine Beeinträchtigung der AZ resistent ist. Im Folgenden finden Sie eine Liste der Schritte, die Sie befolgen müssen.

Stellen Sie Ihre EKS-Worker-Knoten auf mehreren bereit AZs

AWS Regionen haben mehrere, separate Standorte mit physischen Rechenzentren, die als Availability Zones (AZs) bezeichnet werden. AZs sind so konzipiert, dass sie physisch voneinander isoliert sind, um gleichzeitige Auswirkungen zu vermeiden, die sich auf eine gesamte Region auswirken könnten. Bei der Bereitstellung eines EKS-Clusters sollten Sie Ihre Worker-Knoten auf mehreren Knoten AZs in einer Region bereitstellen. Dadurch wird Ihre Cluster-Umgebung widerstandsfähiger gegen Beeinträchtigungen durch eine einzelne AZ und Sie können die Hochverfügbarkeit (HA) Ihrer Anwendungen, die in der anderen AZs ausgeführt werden, aufrechterhalten. Wenn Sie mit einer Zonenverlagerung weg von der betroffenen AZ beginnen, wird das Cluster-Netzwerk Ihrer EKS-Umgebung automatisch aktualisiert AZs, sodass es nur noch fehlerfrei verwendet und gleichzeitig eine hohe Verfügbarkeit für Ihren Cluster beibehält.

Wenn Sie sicherstellen, dass Sie über ein solches Multi-AZ-Setup für Ihre EKS-Umgebung verfügen, wird die allgemeine Zuverlässigkeit Ihres Systems verbessert. Multi-AZ-Umgebungen können jedoch eine wichtige Rolle bei der Übertragung und Verarbeitung von Anwendungsdaten spielen, was sich wiederum auf die Netzwerkgebühren Ihrer Umgebung auswirken wird. Insbesondere häufiger ausgehender zonenübergreifender Verkehr (zwischen den einzelnen Zonen verteilter Verkehr AZs) kann erhebliche Auswirkungen auf Ihre Netzwerkkosten haben. Sie können verschiedene Strategien anwenden, um den Umfang des zonenübergreifenden Datenverkehrs zwischen Pods in Ihrem EKS-Cluster zu kontrollieren und die damit verbundenen Kosten zu senken. Weitere Informationen zur Optimierung der Netzwerkkosten bei der Ausführung hochverfügbarer EKS-Umgebungen finden Sie in diesem Best-Practice-Leitfaden.

Das folgende Diagramm zeigt eine hochverfügbare EKS-Umgebung mit drei AZs fehlerfreien Umgebungen.

Das folgende Diagramm zeigt, wie eine EKS-Umgebung mit 3 AZs eine AZ-Beeinträchtigung aushält und aufgrund der beiden anderen AZs fehlerfreien Umgebungen weiterhin hochverfügbar ist.

Stellen Sie genügend Rechenkapazität bereit, um der Entfernung einer einzigen AZ standzuhalten

Um die Ressourcennutzung und die Kosten für Ihre Recheninfrastruktur in der EKS-Datenebene zu optimieren, empfiehlt es sich, die Rechenkapazität an Ihren Workload-Anforderungen auszurichten. Wenn jedoch alle Ihre Worker-Knoten voll ausgelastet sind, sind Sie darauf angewiesen, dass der EKS-Datenebene neue Worker-Knoten hinzugefügt werden, bevor neue Pods geplant werden können. Bei der Ausführung kritischer Workloads empfiehlt es sich im Allgemeinen immer, mit redundanter Kapazität online zu arbeiten, um Eventualitäten wie plötzlichen Lastanstieg, Probleme mit dem Zustand der Knoten usw. zu bewältigen. Wenn Sie planen, Zonal Shift zu verwenden, planen Sie, eine gesamte AZ an Kapazität zu entfernen, sodass Sie Ihre redundante Rechenkapazität anpassen müssen, sodass sie ausreicht, um die Last auch dann zu bewältigen, wenn eine AZ offline ist.

Bei der Skalierung Ihrer Rechenleistung wird der Prozess des Hinzufügens neuer Knoten zur EKS-Datenebene einige Zeit in Anspruch nehmen, was sich auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen auswirken kann, insbesondere im Falle einer zonalen Beeinträchtigung. Ihre EKS-Umgebung sollte widerstandsfähig sein, um die Belastung durch den Verlust einer AZ zu verkraften, um eine Beeinträchtigung der Benutzererfahrung für Ihre Endbenutzer oder Kunden zu vermeiden. Dies bedeutet, dass jegliche Verzögerung zwischen dem Zeitpunkt, zu dem ein neuer Pod benötigt wird, und dem Zeitpunkt, zu dem er tatsächlich auf einem Worker-Knoten geplant ist, minimiert oder beseitigt werden muss.

Darüber hinaus sollten Sie bei einer Beeinträchtigung der Zonen das Risiko einer möglichen Einschränkung der Rechenkapazität minimieren, die verhindern würde, dass neu benötigte Knoten in einem fehlerfreien Zustand zu Ihrer EKS-Datenebene hinzugefügt werden. AZs

Um dies zu erreichen, sollten Sie in einigen der Worker-Knoten in jedem der beiden Workerknoten zu viel Rechenkapazität bereitstellen, AZs sodass der Kubernetes Scheduler über bereits vorhandene Kapazität für neue Pod-Platzierungen verfügt, insbesondere wenn Sie eine AZ weniger in Ihrer Umgebung haben.

Führen Sie mehrere Pod-Repliken aus und verteilen Sie sie auf AZs

Mit Kubernetes können Sie Ihre Workloads vorab skalieren, indem Sie mehrere Instanzen (Pod-Repliken) einer einzigen Anwendung ausführen. Durch die Ausführung mehrerer Pod-Replikate für eine Anwendung wird ein einziger Fehlerpunkt vermieden und die Gesamtleistung erhöht, indem die Ressourcenbelastung für ein einzelnes Replikat reduziert wird. Um jedoch sowohl eine hohe Verfügbarkeit als auch eine bessere Fehlertoleranz für Ihre Anwendungen zu gewährleisten, sollten Sie in diesem Fall mehrere Replikate einer Anwendung ausführen und auf verschiedene Fehlerdomänen (auch als Topologiedomänen bezeichnet) verteilen. AZs Mit Einschränkungen der Topologieverteilung können Sie Ihre Anwendungen so einrichten, dass sie bereits über statische Stabilität verfügen, sodass Sie im Falle einer Beeinträchtigung der Verfügbarkeit von AZ über genügend Replikate verfügen, AZs um zusätzliche Datenverkehrsspitzen oder -anstiege, die bei ihnen auftreten könnten, sofort bewältigen zu können.

Das folgende Diagramm zeigt eine EKS-Umgebung mit east-to-west Datenverkehrsfluss, wenn alle fehlerfrei sind. AZs

Das folgende Diagramm zeigt eine EKS-Umgebung mit east-to-west Verkehrsfluss, wenn eine einzelne AZ ausfällt und Sie eine Zonenverschiebung einleiten.

Der folgende Codeausschnitt ist ein Beispiel dafür, wie Sie Ihren Workload mit dieser Kubernetes-Funktion einrichten.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 9
  selector:
    matchLabels:
      app:orders
  template:
    metadata:
      labels:
        app: orders
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: orders

Am wichtigsten ist, dass Sie mehrere Replikate Ihrer DNS-Serversoftware (CoreDNS/Kube-DNS) ausführen und ähnliche Einschränkungen für die Topologieverteilung anwenden sollten, falls sie nicht bereits standardmäßig konfiguriert sind. Auf diese Weise können Sie sicherstellen, dass genügend DNS-Pods fehlerfrei sind, AZs um weiterhin Service Discovery-Anfragen für andere kommunizierende Pods im Cluster bearbeiten zu können, falls eine einzelne AZ-Beeinträchtigung vorliegt. Das CoreDNS EKS-Add-On verfügt über Standardeinstellungen für die CoreDNS-Pods, die über die Availability Zones Ihres Clusters verteilt werden, wenn mehrere Knoten verfügbar sind. AZs Sie können diese Standardeinstellungen auch durch Ihre eigenen benutzerdefinierten Konfigurationen ersetzen.

Bei der Installation von CoreDNS mit Helm können Sie die Datei values.yaml aktualisieren, um sicherzustellen, dass Sie replicaCount in jeder AZ über eine ausreichende Anzahl von Replikaten verfügen. Um sicherzustellen, dass diese Replikate auf die verschiedenen Replikate AZs in Ihrer Cluster-Umgebung verteilt sind, sollten Sie außerdem die Eigenschaft in derselben values.yaml-Datei aktualisieren. topologySpreadConstraints Der folgende Codeausschnitt zeigt, wie CoreDNS dafür konfiguriert wird.

CoreDNS Helm-Werte.yaml

replicaCount: 6
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

Im Falle einer AZ-Beeinträchtigung können Sie die erhöhte Belastung der CoreDNS-Pods auffangen, indem Sie ein Autoscaling-System für CoreDNS verwenden. Die Anzahl der benötigten DNS-Instanzen hängt von der Anzahl der Workloads ab, die in Ihrem Cluster ausgeführt werden. CoreDNS ist CPU-gebunden, sodass es mithilfe des Horizontal Pod Autoscaler (HPA) je nach CPU skaliert werden kann. Im Folgenden finden Sie ein Beispiel, das Sie an Ihre Bedürfnisse anpassen können.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

Alternativ kann EKS die automatische Skalierung der CoreDNS-Bereitstellung in der EKS-Add-On-Version von CoreDNS verwalten. Dieser CoreDNS-Autoscaler überwacht kontinuierlich den Clusterstatus, einschließlich der Anzahl der Knoten und CPU-Kerne. Basierend auf diesen Informationen passt der Controller die Anzahl der Replikate der CoreDNS-Bereitstellung in einem EKS-Cluster dynamisch an.

Um die Autoscaling-Konfiguration im CoreDNS EKS-Add-On zu aktivieren, sollten Sie die folgenden optionalen Konfigurationseinstellungen hinzufügen:

{
  "autoScaling": {
    "enabled": true
  }
}

Sie können auch NodeLocal DNS oder den Cluster Proportional Autoscaler verwenden, um CoreDNS zu skalieren. Weitere Informationen zur horizontalen Skalierung von CoreDNS finden Sie hier.

Stellen Sie voneinander abhängige Pods in derselben AZ zusammen

In den meisten Fällen führen Sie möglicherweise unterschiedliche Workloads aus, die miteinander kommunizieren müssen, damit ein Prozess erfolgreich ausgeführt werden kann. end-to-end Wenn die einzelnen Anwendungen auf verschiedene Anwendungen verteilt sind, sich AZs aber nicht in derselben AZ befinden, kann sich eine einzelne AZ-Beeinträchtigung auf den zugrunde liegenden Prozess auswirken. end-to-end Wenn Anwendung A beispielsweise mehrere Replikate in AZ 1 und AZ 2 hat, Anwendung B jedoch alle Replikate in AZ 3 hat, wirkt sich der Verlust von AZ 3 auf alle end-to-end Prozesse zwischen diesen beiden Workloads aus (Anwendung A und B). Durch die Kombination von Einschränkungen bei der Topologieverteilung mit der Pod-Affinität kann die Stabilität Ihrer Anwendung verbessert werden, indem Pods auf alle verteilt werden und eine Beziehung zwischen bestimmten Pods konfiguriert wird AZs, um sicherzustellen, dass sie gemeinsam platziert werden.

Mit Pod-Affinitätsregeln können Sie Beziehungen zwischen Workloads definieren, um das Verhalten des Kubernetes-Schedulers so zu beeinflussen, dass er Pods auf demselben Workerknoten oder in derselben AZ zusammenstellt. Sie können auch konfigurieren, wie streng diese Zeitplanungsbeschränkungen sein sollen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: products
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"

    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"

Das folgende Diagramm zeigt Pods, die sich mithilfe von Pod-Affinitätsregeln auf demselben Knoten befinden.

Testen Sie, ob Ihre Cluster-Umgebung den Verlust einer AZ verkraften kann

Nachdem Sie die oben genannten Anforderungen erfüllt haben, besteht der nächste wichtige Schritt darin, zu testen, ob Sie über ausreichende Rechen- und Workload-Kapazität verfügen, um den Verlust einer AZ zu bewältigen. Sie können dies tun, indem Sie manuell eine Zonenverschiebung in EKS auslösen. Alternativ können Sie Zonal Autoshift aktivieren und Übungsläufe konfigurieren, um zu testen, ob Ihre Anwendungen mit einer AZ weniger in Ihrer Cluster-Umgebung erwartungsgemäß funktionieren.

Häufig gestellte Fragen

Warum sollte ich diese Funktion verwenden?

Durch die Verwendung von ARC Zonal Shift oder Zonal Autoshift in Ihrem EKS-Cluster können Sie die Verfügbarkeit von Kubernetes-Anwendungen besser aufrechterhalten, indem Sie den schnellen Wiederherstellungsprozess automatisieren, bei dem der Netzwerkverkehr innerhalb des Clusters weg von einer beeinträchtigten AZ verlagert wird. Mit ARC können Sie lange und komplizierte Schritte vermeiden, die bei beeinträchtigten AZ-Ereignissen häufig zu einer längeren Erholungsphase führen.

Wie funktioniert diese Funktion mit anderen AWS Diensten?

EKS ist in ARC integriert, das die primäre Schnittstelle für die Durchführung von Wiederherstellungsvorgängen darstellt AWS. Um sicherzustellen, dass der Datenverkehr innerhalb des Clusters ordnungsgemäß von einer beeinträchtigten AZ weggeleitet wird, werden Änderungen an der Liste der Netzwerkendpunkte für Pods vorgenommen, die auf der Kubernetes-Datenebene ausgeführt werden. Wenn Sie AWS Load Balancer für die Weiterleitung von externem Datenverkehr in den Cluster verwenden, können Sie Ihre Load Balancer bereits bei ARC registrieren und eine Zonenverschiebung auf ihnen auslösen, um zu verhindern, dass Datenverkehr in die degradierte Zone fließt. Diese Funktion interagiert auch mit Amazon EC2 Auto Scaling Groups (ASG), die von EKS Managed Node Groups (MNG) erstellt wurden. Um zu verhindern, dass eine beeinträchtigte AZ für neue Kubernetes-Pods oder Node-Starts verwendet wird, entfernt EKS die beeinträchtigte AZ aus der ASG.

Wie unterscheidet sich diese Funktion von den standardmäßigen Kubernetes-Schutzmaßnahmen?

Diese Funktion arbeitet mit mehreren systemeigenen integrierten Schutzmaßnahmen von Kubernetes zusammen, die Kunden dabei unterstützen, widerstandsfähig zu bleiben. Sie können Tests zur Bereitschaft und Aktualität eines Pods konfigurieren, die entscheiden, wann ein Pod Traffic aufnehmen soll. Wenn diese Tests fehlschlagen, entfernt Kubernetes diese Pods als Ziele für einen Service und der Datenverkehr wird nicht mehr an den Pod gesendet. Das ist zwar nützlich, aber es ist für Kunden nicht trivial, diese Integritätsprüfungen so zu konfigurieren, dass sie garantiert fehlschlagen, wenn eine Zone heruntergefahren ist. Die ARC-Zonenverschiebungsfunktion bietet Ihnen ein zusätzliches Sicherheitsnetz, das ihnen hilft, eine heruntergestufte AZ vollständig zu isolieren, wenn die systemeigenen Schutzmaßnahmen von Kubernetes nicht ausreichend waren. Es bietet Ihnen auch eine einfache Möglichkeit, die Betriebsbereitschaft und Belastbarkeit Ihrer Architektur zu testen.

Kann ich in meinem Namen eine Zonenverschiebung AWS auslösen?

Ja, wenn Sie ARC Zonal Shift vollautomatisch nutzen möchten, können Sie ARC Zonal Autoshift aktivieren. Mit Zonal Autoshift können Sie sich darauf verlassen, AWS dass Sie den Zustand Ihres EKS-Clusters überwachen und automatisch eine Verschiebung auslösen, wenn eine AZ-Beeinträchtigung festgestellt wird. AZs

Was passiert, wenn ich diese Funktion verwende und meine Worker-Knoten und Workloads nicht vorskaliert sind?

Wenn Sie nicht vorskaliert sind und darauf angewiesen sind, während einer Zonenverschiebung zusätzliche Knoten oder Pods bereitzustellen, besteht die Gefahr einer verzögerten Wiederherstellung. Das Hinzufügen neuer Knoten zur Kubernetes-Datenebene wird einige Zeit in Anspruch nehmen, was sich auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen auswirken kann, insbesondere im Falle einer zonalen Beeinträchtigung. Darüber hinaus kann es bei einer Beeinträchtigung der Zonen zu einer potenziellen Einschränkung der Rechenkapazität kommen, die verhindern würde, dass neu benötigte Knoten zu den fehlerfreien Knoten hinzugefügt werden. AZs

Wenn Ihre Workloads nicht vorab skaliert und auf alle Bereiche Ihres Clusters verteilt sind, kann sich eine zonale Beeinträchtigung auf die Verfügbarkeit einer Anwendung auswirken, die nur auf Worker-Knoten AZs in einer betroffenen AZ ausgeführt wird. Um das Risiko eines vollständigen Verfügbarkeitsausfalls für Ihre Anwendung zu minimieren, verfügt EKS über eine Ausfallsicherung für den Datenverkehr, der an Pod-Endpunkte in einer beeinträchtigten Zone gesendet wird, falls sich alle Endpunkte des Workloads in der fehlerhaften AZ befinden. Es wird jedoch dringend empfohlen, Ihre Anwendungen vorab zu skalieren und auf alle AZs zu verteilen, um die Verfügbarkeit im Falle eines zonalen Problems aufrechtzuerhalten.

Was passiert, wenn ich eine statusbehaftete Anwendung ausführe?

Wenn Sie eine statusbehaftete Anwendung ausführen, müssen Sie ihre Fehlertoleranz je nach Anwendungsfall und Architektur bewerten. Wenn Sie über eine Aktiv-/Standby-Architektur oder ein Muster verfügen, kann es Fälle geben, in denen sich die aktive Komponente in einer beeinträchtigten AZ befindet. Wenn der Standby-Modus auf Anwendungsebene nicht aktiviert ist, können Probleme mit Ihrer Anwendung auftreten. Probleme können auch auftreten, wenn neue Kubernetes-Pods im fehlerfreien Zustand gestartet werden, AZs da sie dann nicht in der Lage sind, eine Verbindung zu den persistenten Volumes herzustellen, die auf die beeinträchtigte AZ beschränkt sind.

Funktioniert diese Funktion mit Karpenter?

Die Unterstützung von Karpenter ist derzeit für ARC Zonal Shift und Zonal Autoshift in EKS nicht verfügbar. Wenn eine AZ beeinträchtigt ist, können Sie die entsprechende NodePool Konfiguration von Karpenter anpassen, indem Sie die fehlerhafte AZ entfernen, sodass neue Worker-Knoten nur im fehlerfreien Zustand gestartet werden. AZs

Funktioniert diese Funktion mit EKS Fargate?

Diese Funktion funktioniert nicht mit EKS Fargate. Wenn EKS Fargate ein zonales Gesundheitsereignis erkennt, ziehen es Pods standardmäßig vor, in dem anderen System ausgeführt zu werden. AZs

Wird die von EKS verwaltete Kubernetes-Steuerebene beeinträchtigt?

Nein, Amazon EKS führt standardmäßig die Kubernetes-Steuerebene aus und skaliert sie über mehrere, AZs um eine hohe Verfügbarkeit zu gewährleisten. ARC Zonal Shift und Zonal Autoshift wirken nur auf der Kubernetes-Datenebene.

Sind mit dieser neuen Funktion irgendwelche Kosten verbunden?

Sie können ARC Zonal Shift und Zonal Autoshift in Ihrem EKS-Cluster ohne zusätzliche Kosten verwenden. Sie zahlen jedoch weiterhin für bereitgestellte Instances. Es wird dringend empfohlen, Ihre Kubernetes-Datenebene vorab zu skalieren, bevor Sie diese Funktion nutzen. Sie sollten das richtige Gleichgewicht zwischen Kosten und Anwendungsverfügbarkeit in Betracht ziehen.

Weitere Ressourcen