Unterstützung für die Verbesserung dieser Seite beitragen

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.

Um zu diesem Benutzerhandbuch beizutragen, 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.

Weitere Informationen zur Zonenverschiebung von Amazon Application Recovery Controller (ARC) in Amazon EKS

Kubernetes verfügt über native Features, mit denen Sie Ihre Anwendungen stabiler gegenüber Ereignissen wie einer verschlechterten Verfügbarkeit oder 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 weiter verbessern, indem Sie Amazon Application Recovery Controller (ARC)-Zonenverschiebung oder automatische Zonenverschiebung einsetzen. ARC-Zonenverschiebung ist als vorübergehende Maßnahme konzipiert, mit der Sie den Datenverkehr für eine Ressource aus einer beeinträchtigten AZ verlagern können, bis die Zonenverschiebung abläuft oder Sie sie abbrechen. Bei Bedarf können Sie die Zonenverschiebung verlängern.

Sie können eine Zonenverschiebung für einen EKS-Cluster starten oder Sie können zulassen AWS , dass der Datenverkehr für Sie verschoben wird, indem Sie Zonal Autoshift aktivieren. Durch diese Verschiebung wird der east-to-west Netzwerkdatenverkehr in Ihrem Cluster so aktualisiert, dass 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 höchste Verfügbarkeit anstreben, kann es im Falle einer Beeinträchtigung einer AZ wichtig sein, den gesamten Datenverkehr von der beeinträchtigten AZ wegleiten zu können, bis diese wiederhergestellt ist. Hierzu können Sie auch einen ALB oder NLB mit ARC-Zonenverschiebung aktivieren.

Verständnis des Ost-West-Netzwerkdatenverkehrs zwischen Pods

Das folgende Diagramm veranschaulicht zwei Beispiel-Workloads: Bestellungen und Produkte. Der Zweck dieses Beispiels besteht darin, zu zeigen, wie Workloads und Pods in verschiedenen Umgebungen miteinander kommunizieren. AZs

Verständnis der ARC-Zonenverschiebung in Amazon EKS

Sollte in Ihrer Umgebung eine AZ-Beeinträchtigung vorliegen, können Sie eine Zonenverschiebung für Ihre EKS-Cluster-Umgebung initiieren. Alternativ können AWS Sie den wechselnden Verkehr mit zonaler Autoshift für Sie verwalten lassen. Mit Zonal Autoshift wird der gesamte Zustand der AZ AWS ü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.

Nachdem Ihr Amazon EKS-Cluster Zonal Shift mit ARC aktiviert hat, können Sie eine Zonal Shift starten oder Zonal Autoshift aktivieren, indem Sie die ARC-Konsole, die AWS CLI oder Zonal Shift und Zonal Autoshift verwenden. APIs Während einer EKS-Zonenverschiebung wird Folgendes automatisch durchgeführt:

Die folgenden Diagramme bieten einen allgemeinen Überblick darüber, wie die EKS-Zonenverschiebung sicherstellt, dass nur fehlerfreie Pod-Endpunkte in Ihrer Cluster-Umgebung angesteuert werden.

Anforderungen der EKS-Zonenverschiebung

Damit die Zonenverschiebung mit EKS erfolgreich funktioniert, müssen Sie Ihre Cluster-Umgebung im Voraus so einrichten, dass sie gegenüber einer AZ-Beeinträchtigung widerstandsfähig ist. Nachfolgend finden Sie eine Liste mit Konfigurationsoptionen, die zur Gewährleistung der Ausfallsicherheit beitragen.

Bereitstellung Ihrer EKS-Worker-Knoten über mehrere Availability Zones hinweg

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. Wenn Sie einen EKS-Cluster bereitstellen, empfehlen wir, dass Sie Ihre Worker-Knoten auf mehreren Knoten AZs in einer Region bereitstellen. Dies trägt dazu bei, dass Ihre Clusterumgebung widerstandsfähiger gegenüber Beeinträchtigungen durch eine einzelne AZ ist, und ermöglicht es Ihnen, die Hochverfügbarkeit Ihrer Anwendungen aufrechtzuerhalten, die in der anderen ausgeführt AZs werden. Wenn Sie mit einer Zonenverlagerung weg von der betroffenen AZ beginnen, wird das Cluster-interne Netzwerk Ihrer EKS-Umgebung automatisch aktualisiert, sodass es nur noch fehlerfrei verwendet wird AZs, um die Hochverfügbarkeit Ihres Clusters aufrechtzuerhalten.

Die Sicherstellung einer Multi-AZ-Konfiguration für Ihre EKS-Umgebung erhöht die allgemeine Zuverlässigkeit Ihres Systems. Multi-AZ-Umgebungen beeinflussen jedoch die Art und Weise, wie Anwendungsdaten übertragen und verarbeitet werden, was sich wiederum auf die Netzwerkgebühren Ihrer Umgebung auswirkt. 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 die Menge des zonenübergreifenden Datenverkehrs zwischen Pods in Ihrem EKS-Cluster zu steuern und die damit verbundenen Kosten zu senken. Weitere Informationen zur Optimierung der Netzwerkkosten beim Betrieb hochverfügbarer EKS-Umgebungen finden Sie in diesen Bewährten Methoden.

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

Das folgende Diagramm zeigt, wie eine EKS-Umgebung mit drei AZs EKS-Umgebungen eine Beeinträchtigung der AZ aushält und hochverfügbar bleibt, da zwei davon noch intakt sind. AZs

Stellen Sie ausreichend Rechenkapazität bereit, um den Ausfall einer einzelnen Availability Zone zu kompensieren.

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 neue Worker-Knoten zur EKS-Datenebene hinzugefügt werden, bevor neue Pods geplant werden können. Wenn Sie wichtige Workloads ausführen, empfiehlt es sich im Allgemeinen, redundante Kapazitäten online zu betreiben, um Szenarien wie plötzliche Lastanstiege und Probleme mit der Knotenintegrität zu bewältigen. Wenn Sie eine Zonenverschiebung planen, beabsichtigen Sie, bei einer Wertminderung die gesamte Kapazität einer AZ zu entfernen. Das bedeutet, dass Sie Ihre redundante Rechenkapazität so anpassen müssen, dass sie ausreicht, um die Last auch dann zu bewältigen, wenn eine der Maschinen AZs offline ist.

Wenn Sie Ihre Rechenressourcen skalieren, dauert der Vorgang des Hinzufügens neuer Knoten zur EKS-Datenebene einige Zeit. Dies kann Auswirkungen auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen haben, insbesondere im Falle einer Beeinträchtigung der Zone. Ihre EKS-Umgebung sollte in der Lage sein, den Ausfall einer AZ zu kompensieren, ohne dass dies zu einer Beeinträchtigung der Benutzererfahrung für Ihre Endbenutzer oder Clients führt. Das heißt, die 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 wird, sollte minimiert oder ganz vermieden werden.

Darüber hinaus sollten Sie bei einer Beeinträchtigung der Zonen darauf achten, das Risiko zu minimieren, dass Rechenkapazitätsengpässe auftreten, die verhindern würden, dass neu benötigte Knoten im fehlerfreien Zustand zu Ihrer EKS-Datenebene hinzugefügt werden. AZs

Um das Risiko dieser potenziellen negativen Auswirkungen zu verringern, empfehlen wir, dass Sie in einigen Worker-Knoten in jedem der Workerknoten zu viel Rechenkapazität bereitstellen. AZs Auf diese Weise verfügt der Kubernetes Scheduler über bereits vorhandene Kapazitäten für neue Pod-Platzierungen. Dies ist besonders wichtig, wenn Sie einen Pod in Ihrer Umgebung verlieren. AZs

Ausführung und Verteilung mehrerer Pod-Replikate über Availability Zones hinweg

Mit Kubernetes können Sie Ihre Workloads vorab skalieren, indem Sie mehrere Instances (Pod-Replikate) einer einzelnen Anwendung ausführen. Durch die Ausführung mehrerer Pod-Replikate für eine Anwendung werden einzelne Fehlerquellen beseitigt und die Gesamtleistung gesteigert, da die Ressourcenbelastung eines einzelnen Replikats reduziert wird. Um jedoch sowohl eine hohe Verfügbarkeit als auch eine bessere Fehlertoleranz für Ihre Anwendungen zu erreichen, empfehlen wir Ihnen, mehrere Replikate Ihrer Anwendung auszuführen und die Replikate auf verschiedene Ausfall-Domains (auch Topologie-Domains genannt) zu verteilen. Die Ausfall-Domains in diesem Szenario sind die Availability Zones. Durch die Verwendung von Topologie-Verteilungsbeschränkungen können Sie Ihre Anwendungen so einrichten, dass sie über eine bereits vorhandene, statische Stabilität verfügen. Wenn es dann zu einer Beeinträchtigung der Verfügbarkeit kommt, verfügt Ihre Umgebung über genügend Replikate im fehlerfreien Zustand, um etwaige Datenverkehrsspitzen oder AZs -spitzen sofort zu bewältigen.

Das folgende Diagramm zeigt eine EKS-Umgebung, in der der east-to-west Datenverkehr fließt, wenn alle AZs fehlerfrei sind.

Das folgende Diagramm zeigt eine EKS-Umgebung mit einem east-to-west Verkehrsfluss, bei dem eine einzelne AZ ausgefallen ist und Sie eine Zonenverschiebung gestartet haben.

Der folgende Code-Ausschnitt ist ein Beispiel dafür, wie Sie Ihre Workload mit mehreren Replikaten in Kubernetes einrichten können.

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

Vor allem sollten Sie mehrere Replikate Ihrer DNS-Server-Software (CoreDNS/kube-dns) ausführen und ähnliche Topologie-Verteilungsbeschränkungen anwenden, sofern diese nicht standardmäßig konfiguriert sind. Auf diese Weise können Sie sicherstellen, dass bei einer einzelnen AZ-Beeinträchtigung genügend DNS-Pods fehlerfrei sind, AZs um weiterhin Service Discovery-Anfragen für andere kommunizierende Pods im Cluster bearbeiten zu können. Das CoreDNS EKS-Add-On verfügt über Standardeinstellungen für die CoreDNS-Pods, die sicherstellen, dass Knoten, die in mehreren AZs verfügbar sind, über die Availability Zones Ihres Clusters verteilt sind. Falls gewünscht, können Sie diese Standardeinstellungen durch Ihre eigenen benutzerdefinierten Konfigurationen ersetzen.

Wenn Sie CoreDNS mit Helm installieren, können Sie replicaCount in der Datei values.yaml anpassen, um sicherzustellen, dass Sie über ausreichend Replikate in jeder AZ verfügen. Um sicherzustellen, dass diese Replikate auf die verschiedenen Replikate AZs in Ihrer Clusterumgebung verteilt sind, stellen Sie außerdem sicher, dass Sie die topologySpreadConstraints Eigenschaft in derselben Datei aktualisieren. values.yaml Der folgende Code-Ausschnitt veranschaulicht, wie Sie CoreDNS entsprechend konfigurieren können.

CoreDNS Helm values.yaml

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

Bei einer AZ-Beeinträchtigung können Sie die erhöhte Belastung der CoreDNS-Pods durch den Einsatz eines Systems zur automatischen Skalierung für CoreDNS abfedern. Die Anzahl der erforderlichen DNS- Instances hängt von der Anzahl der in Ihrem Cluster ausgeführten Workloads ab. CoreDNS ist CPU-gebunden, wodurch es mithilfe des Horizontal Pod Autoscaler (HPA) basierend auf der CPU skaliert werden kann. Nachfolgend finden Sie ein Beispiel, das Sie an Ihre Anforderungen 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 Status des Clusters, 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 Konfiguration für die automatische Skalierung im CoreDNS-EKS-Add-On zu aktivieren, verwenden Sie die folgende Konfigurationseinstellung:

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

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

Co-Location voneinander abhängiger Pods in derselben Availability Zone

In der Regel haben Anwendungen unterschiedliche Workloads, die miteinander kommunizieren müssen, um einen Prozess erfolgreich abzuschließen. end-to-end Wenn diese unterschiedlichen Anwendungen auf verschiedene Bereiche verteilt sind AZs und sich nicht in derselben AZ befinden, kann sich eine einzelne Beeinträchtigung der AZ auf den 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 end-to-end Prozesse zwischen den beiden Workloads, Anwendung A und Anwendung B, aus. Wenn Sie Beschränkungen der Topologieverteilung mit Pod-Affinität kombinieren, können Sie die Ausfallsicherheit Ihrer Anwendung verbessern, indem Sie Pods über alle Pods verteilen. AZs Darüber hinaus wird dadurch eine Beziehung zwischen bestimmten Pods konfiguriert, um sicherzustellen, dass sie zusammen platziert sind.

Mit Pod-Affinitätsregeln können Sie Beziehungen zwischen Workloads definieren, um das Verhalten des Kubernetes-Schedulers so zu beeinflussen, dass Pods auf demselben Worker-Knoten oder in derselben AZ zusammengeführt werden. Sie können auch konfigurieren, wie streng die Planungsbeschrä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 mehrere Pods, die mithilfe von Pod-Affinitätsregeln auf demselben Knoten zusammen platziert wurden.

Testen Ihrer Cluster-Umgebung für die Bewältigung eines Ausfalls einer AZ

Nachdem Sie die in den vorherigen Abschnitten beschriebenen Anforderungen erfüllt haben, müssen Sie im nächsten Schritt überprüfen, ob Sie über ausreichende Rechen- und Workload-Kapazitäten verfügen, um den Ausfall einer AZ zu bewältigen. Dazu können Sie manuell eine Zonenverschiebung in EKS starten. Alternativ können Sie die automatische Zonenverschiebung aktivieren und Testläufe konfigurieren, mit denen ebenfalls überprüft wird, ob Ihre Anwendungen mit einer AZ weniger in Ihrer Cluster-Umgebung wie erwartet funktionieren.

Häufig gestellte Fragen

Warum sollte ich dieses Feature nutzen?

Durch die Verwendung von ARC-Zonenverschiebung oder automatischer Zonenverschiebung in Ihrem EKS-Cluster können Sie die Verfügbarkeit von Kubernetes-Anwendungen besser aufrechterhalten. Dazu wird der schnelle Wiederherstellungsprozess automatisiert, bei dem der Netzwerk-Datenverkehr innerhalb des Clusters von einer beeinträchtigten AZ weg verlagert wird. Mit ARC können Sie langwierige, komplizierte Schritte vermeiden, die bei Störungen in AZs zu einer verlängerten Wiederherstellungszeit führen können

Wie funktioniert diese Funktion mit anderen Diensten? AWS

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, nimmt EKS Änderungen an der Liste der Netzwerkendpunkte für Pods vor, die in der Kubernetes-Datenebene ausgeführt werden. Wenn Sie Elastic Load Balancing verwenden, um externen Datenverkehr in den Cluster zu leiten, können Sie Ihre Load Balancer bei ARC registrieren und eine Zonenverschiebung auf ihnen starten, um zu verhindern, dass Datenverkehr in die beeinträchtigte AZ gelangt. Zonal Shift funktioniert auch mit Amazon EC2 Auto Scaling Scaling-Gruppen, die von EKS verwalteten Knotengruppen erstellt werden. Um zu verhindern, dass eine beeinträchtigte AZ für neue Kubernetes-Pods oder Knoten-Starts verwendet wird, entfernt EKS die beeinträchtigte AZ aus den Auto-Scaling-Gruppen.

Inwiefern unterscheidet sich dieses Feature von den standardmäßigen Kubernetes-Schutzmaßnahmen?

Dieses Feature arbeitet mit mehreren in Kubernetes integrierten Schutzmaßnahmen zusammen, welche die Ausfallsicherheit von Kundenanwendungen verbessern Sie können Pod-Bereitschafts- und Aktivitätsprüfung konfigurieren, die entscheiden, wann ein Pod Datenverkehr aufnehmen soll. Wenn diese Prüfungen fehlschlagen, entfernt Kubernetes diese Pods als Ziele für einen Service, und es wird kein Datenverkehr mehr an den Pod gesendet. Dies ist zwar nützlich, für Kunden ist es jedoch nicht einfach, diese Integritätsprüfungen so zu konfigurieren, dass sie garantiert fehlschlagen, wenn eine AZ beeinträchtigt wird. Feature für die ARC-Zonenverschiebung bietet ein zusätzliches Sicherheitsnetz, mit dem Sie eine beeinträchtigte AZ vollständig isolieren können, wenn der native Schutz von Kubernetes nicht ausreicht. Durch Zonenverschiebung können Sie außerdem auf einfache Weise die Betriebsbereitschaft und Ausfallsicherheit Ihrer Architektur überprüfen.

Kann ich in meinem Namen eine Zonenverschiebung AWS starten?

Ja, wenn Sie eine vollständig automatisierte Nutzung der ARC-Zonenverschiebung wünschen, können Sie die automatische ARC-Zonenverschiebung aktivieren. Mit Zonal Autoshift können Sie sich AWS darauf verlassen, dass Sie den Zustand Ihres EKS-Clusters überwachen und automatisch eine Zonenverschiebung starten, wenn eine Beeinträchtigung der AZ festgestellt wird. AZs

Was geschieht, wenn ich dieses Feature verwende und meine Worker-Knoten und Workloads nicht vorab skaliert sind?

Wenn Sie nicht vorab skaliert haben und während einer Zonenverschiebung auf die Bereitstellung zusätzlicher Knoten oder Pods angewiesen sind, riskieren Sie eine verzögerte Wiederherstellung. Das Hinzufügen neuer Knoten zur Kubernetes-Datenebene nimmt einige Zeit in Anspruch, was sich auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen auswirken kann, insbesondere bei einer Beeinträchtigung der Zone. Darüber hinaus kann es bei einer Beeinträchtigung der Zonen zu einer potenziellen Einschränkung der Rechenkapazität kommen, die verhindern könnte, 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 Ausfalls der Verfügbarkeit Ihrer Anwendung zu mindern, verfügt EKS über eine Ausfallsicherung für den Datenverkehr, der an Pod-Endpunkte in einer beeinträchtigten Zone gesendet wird, wenn alle Endpunkte dieser Workload in der nicht funktionsfähigen AZ liegen. Wir empfehlen jedoch dringend, dass Sie Ihre Anwendungen vorab skalieren und auf alle verteilen, AZs um die Verfügbarkeit im Falle eines zonalen Problems aufrechtzuerhalten.

Wie funktioniert dies, wenn ich eine zustandsbehaftete Anwendung ausführe?

Wenn Sie eine zustandsbehaftete Anwendung ausführen, müssen Sie deren Fehlertoleranz auf der Grundlage Ihres Anwendungsfalls und Ihrer Architektur bewerten. Wenn Sie über eine active/standby Architektur oder ein Muster verfügen, kann es vorkommen, dass sich die aktive Komponente in einer beeinträchtigten AZ befindet. Auf Anwendungsebene kann es zu Problemen mit Ihrer Anwendung kommen, wenn der Standby-Modus nicht aktiviert ist. Möglicherweise treten auch Probleme auf, wenn neue Kubernetes-Pods im fehlerfreien Zustand gestartet werden AZs, da sie sich dann nicht mit den persistenten Volumes verbinden können, die auf die beeinträchtigte AZ beschränkt sind.

Ist dieses Feature mit Karpenter kompatibel?

Derzeit wird Karpenter nicht mit der ARC-Zonenverschiebung und Zonal Autoshift in EKS unterstützt. Wenn eine AZ beeinträchtigt ist, können Sie die entsprechende NodePool Karpenter-Konfiguration anpassen, indem Sie die fehlerhafte AZ entfernen, sodass neue Worker-Knoten nur in der anderen gestartet werden. AZs

Ist dieses Feature mit EKS Fargate kompatibel?

Dieses Feature ist mit EKS Fargate nicht kompatibel. 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 davon betroffen sein?

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. Die ARC-Zonenverschiebung und die automatische Zonenverschiebung wirken sich ausschließlich auf die Kubernetes-Datenebene aus.

Sind mit diesem neuen Feature Kosten verbunden?

Sie können ARC-Zonenverschiebung und automatische Zonenverschiebung in Ihrem EKS-Cluster ohne zusätzliche Kosten nutzen. Sie müssen jedoch weiterhin für bereitgestellte Instances bezahlen. Wir empfehlen Ihnen dringend, Ihre Kubernetes-Datenebene vor der Nutzung dieses Features vorab zu skalieren. Sie sollten ein Gleichgewicht zwischen Kosten und Anwendungsverfügbarkeit anstreben.

Weitere Ressourcen