Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

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

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

Helfen Sie 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.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle 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.

Helfen Sie 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.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle 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.

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 EKS Amazon-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. ARCBei der Zonenverschiebung handelt es sich um eine vorübergehende Maßnahme, die es Ihnen ermöglicht, den Verkehr für eine Ressource von einer beeinträchtigten AZ wegzuverlagern, 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 so aktualisiert, dass nur Netzwerkendpunkte für Pods berücksichtigt werden, die auf Worker-Knoten im fehlerfreien Zustand ausgeführt werden. AZs Darüber hinaus leitet der gesamte eingehende Datenverkehr für Anwendungen in Ihrem EKS Cluster ALB oder die NLB Verarbeitung des eingehenden Datenverkehrs 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 ein 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.

Veranschaulichung des Netzwerkverkehrs
Veranschaulichung des Netzwerkverkehrs
  1. Damit Bestellungen mit Produkten kommunizieren können, muss zuerst der DNS Name des Zieldienstes aufgelöst werden. Bestellungen kommunizieren mit CoreDNS, um die virtuelle IP-Adresse (Cluster-IP) für diesen Dienst abzurufen. Sobald Orders den Servicenamen des Produkts aufgelöst hat, wird Datenverkehr an diese Ziel-IP gesendet.

  2. Der Kube-Proxy läuft auf jedem Knoten im Cluster und überwacht kontinuierlich nach Diensten. EndpointSlices Wenn ein Service erstellt wird, EndpointSlice wird ein Service im Hintergrund vom Controller erstellt und verwaltet. EndpointSlice Jeder EndpointSlice hat eine Liste oder Tabelle mit Endpunkten, die eine Teilmenge von Pod-Adressen zusammen mit den Knoten enthält, auf denen sie ausgeführt werden. Der Kube-Proxy richtet Routing-Regeln für jeden dieser Pod-Endpunkte ein, die auf den Knoten verwendet werden. iptables Der Kube-Proxy ist auch für eine grundlegende Form des Lastenausgleichs verantwortlich, indem er den an die Cluster-IP eines Dienstes gerichteten Datenverkehr umleitet, sodass er stattdessen direkt an die IP-Adresse eines Pods gesendet wird. Der Kube-Proxy tut dies, indem er die Ziel-IP auf der ausgehenden Verbindung neu schreibt.

  3. Die Netzwerkpakete werden dann über die jeweiligen Knoten an den Products-Pod in AZ 2 gesendet (wie in der Abbildung oben dargestellt). ENIs

Grundlegendes zu ARC Zonal Shift in 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 EKS Cluster Zonal Shift mit aktiviert istARC, können Sie mithilfe der ARC Konsole, der oder Zonal Shift und Zonal Autoshift eine Zonenverschiebung auslösen oder Zonal Autoshift aktivieren. AWS CLI APIs Während einer EKS Zonenverschiebung findet automatisch Folgendes statt:

  • Alle Knoten in der betroffenen AZ werden gesperrt. Dadurch wird verhindert, dass der Kubernetes Scheduler neue Pods auf den Knoten in der fehlerhaften AZ plant.

  • Wenn Sie verwaltete Knotengruppen verwenden, wird das Rebalancing der Availability Zone ausgesetzt und Ihre Auto Scaling Scaling-Gruppe (ASG) wird aktualisiert, um sicherzustellen, dass neue EKS Data Plane-Knoten nur im AZs fehlerfreien Zustand gestartet werden.

  • Die Knoten in der fehlerhaften AZ werden nicht beendet und die Pods werden nicht aus diesen Knoten entfernt. Auf diese Weise soll sichergestellt werden, dass Ihr Datenverkehr nach Ablauf oder Ausfall einer Zonenschicht sicher zur AZ zurückgeleitet werden kann, wo immer noch die volle Kapazität vorhanden ist

  • Der EndpointSlice Controller findet alle Pod-Endpunkte in der beeinträchtigten AZ und entfernt sie aus der entsprechenden Zone. EndpointSlices Dadurch wird sichergestellt, dass nur Pod-Endpunkte, die sich in einem fehlerfreien AZs Zustand befinden, gezielt Netzwerkverkehr empfangen. Wenn eine Zonenverschiebung storniert wird oder abläuft, aktualisiert der EndpointSlice Controller das so, dass die EndpointSlices Endpunkte in die wiederhergestellte AZ aufgenommen werden.

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

Veranschaulichung des Netzwerkverkehrs
Veranschaulichung des Netzwerkverkehrs

EKSAnforderungen an Zonenverschiebungen

Damit Zonal Shift erfolgreich funktionieren kannEKS, müssen Sie Ihre Cluster-Umgebung zuvor so einrichten, dass sie auch bei Beeinträchtigungen der AZ-Verfügbarkeit widerstandsfähig ist. Im Folgenden finden Sie eine Liste der Schritte, die Sie befolgen müssen.

  • Stellen Sie die Worker-Knoten Ihres Clusters über mehrere AZs

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

  • Skalieren Sie Ihre Pods (einschließlich CoreDNS) in jeder AZ vorab

  • Verteilen Sie mehrere Pod-Repliken auf alle, AZs um sicherzustellen, dass Sie durch die Umstellung von einer einzigen AZ über ausreichend Kapazität verfügen

  • Platzieren Sie voneinander abhängige oder verwandte Pods in derselben AZ

  • Testen Sie, ob Ihre Cluster-Umgebung mit weniger AZ erwartungsgemäß funktioniert, indem Sie manuell eine Zonenverschiebung starten. Alternativ können Sie zonales Autoshift aktivieren und auf die Autoshift-Übungsläufe antworten. Dies ist nicht erforderlich, damit Zonal Shift funktioniert, wird EKS aber dringend empfohlen.

Stellen Sie Ihre EKS Worker-Knoten für mehrere bereit AZs

AWS Regionen haben mehrere, separate Standorte mit physischen Rechenzentren, die als Availability Zones (AZs) bezeichnet werden. AZssind 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 aktualisiertAZs, sodass es nur noch fehlerfrei verwendet und gleichzeitig die Hochverfügbarkeit Ihres Clusters beibehalten wird.

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 VerkehrAZs) kann erhebliche Auswirkungen auf Ihre Netzwerkkosten haben. Sie können verschiedene Strategien anwenden, um den Umfang des zonenübergreifenden Datenverkehrs zwischen den Pods in Ihrem EKS Cluster zu kontrollieren und die damit verbundenen Kosten zu senken. Weitere Informationen zur Optimierung der Netzwerkkosten in EKS Umgebungen mit hoher Verfügbarkeit finden Sie in diesem Best-Practice-Leitfaden.

Das folgende Diagramm zeigt eine EKS Umgebung mit hoher Verfügbarkeit und drei AZs fehlerfreien Umgebungen.

Abbildung des Netzwerks

Das folgende Diagramm zeigt, wie eine EKS Umgebung mit 3 AZs eine Beeinträchtigung der AZ aushält und trotzdem hochverfügbar bleibt, weil die beiden anderen gesund AZs sind.

Abbildung des Netzwerks

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

Um die Ressourcennutzung und die Kosten für Ihre Recheninfrastruktur auf 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 das Hinzufügen neuer Knoten zur EKS Datenebene einige Zeit in Anspruch nehmen, was sich auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen auswirken kann, insbesondere bei einer Beeinträchtigung der Zonen. 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 im Falle 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 im 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 sofort bewältigen zu können.

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

Abbildung des Netzwerks

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

Abbildung des Netzwerks

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 (Core DNS /kube-dns) ausführen und ähnliche Beschränkungen für die Topologieverteilung anwenden sollten, sofern diese 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 DNSEKSCore-Add-on verfügt über Standardeinstellungen, sodass die DNS Core-Pods auf die Availability Zones Ihres Clusters verteilt werden, wenn mehrere Knoten AZs verfügbar sind. Sie können diese Standardeinstellungen auch durch Ihre eigenen benutzerdefinierten Konfigurationen ersetzen.

Bei der Installation von Core DNS with 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 topologySpreadConstraints Eigenschaft in derselben values.yaml-Datei aktualisieren. Der folgende Codeausschnitt zeigt, wie Core dafür konfiguriert wird. DNS

Core Helm-Werte.yaml DNS

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 Core DNS Pods auffangen, indem Sie ein Autoscaling-System für Core verwenden. DNS Die Anzahl der benötigten DNS Instances hängt von der Anzahl der Workloads ab, die in Ihrem Cluster ausgeführt werden. DNSDer Kern ist CPU gebunden, sodass er CPU mithilfe des Horizontal Pod Autoscaler () skaliert werden kann. HPA 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 EKS können Sie die automatische Skalierung der DNS Core-Deployment in der EKS Zusatzversion von Core DNS verwalten. Dieser DNS Core-Autoscaler überwacht kontinuierlich den Clusterstatus, einschließlich der Anzahl der Knoten und Kerne. CPU Auf der Grundlage dieser Informationen passt der Controller die Anzahl der Replikate der DNS Core-Bereitstellung in einem Cluster dynamisch an. EKS

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

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

Sie können Core auch mit dem proportionalen Cluster-Autoscaler skalieren. NodeLocal DNSDNS Weitere Informationen zur DNShorizontalen Skalierung von Core 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 wirdAZs, um sicherzustellen, dass sie gemeinsam platziert werden.

Mit Pod-Affinitätsregeln können Sie Beziehungen zwischen Workloads definieren, um das Verhalten des Kubernetes Scheduler so zu beeinflussen, dass er Pods auf demselben Workerknoten oder in derselben AZ zusammenstellt. Sie können auch konfigurieren, wie streng diese 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 Pods, die sich mithilfe von Pod-Affinitätsregeln auf demselben Knoten befinden.

Abbildung des Netzwerks

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 auslösen. EKS 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. Auf diese Weise können Sie lange und komplizierte Schritte vermeidenARC, die bei beeinträchtigten AZ-Ereignissen häufig zu einer längeren Erholungsphase führen.

Wie funktioniert diese Funktion mit anderen AWS Diensten?

EKSlässt sich in ARC das System integrieren, das die primäre Schnittstelle darstellt, über die Sie Wiederherstellungsvorgänge durchführen können 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 in 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 ihnen registrieren ARC und eine Zonenverschiebung auslösen, um zu verhindern, dass Datenverkehr in die degradierte Zone fließt. Diese Funktion interagiert auch mit Amazon EC2 Auto Scaling Scaling-Gruppen (ASG), die von EKS Managed Node Groups (MNG) erstellt wurden. Um zu verhindern, dass eine beeinträchtigte AZ für neue Kubernetes-Pods oder Knotenstarts verwendet wird, EKS entfernt 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 Zonal Shift-Funktion 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 Zonal Shift vollautomatisch nutzen möchten, können Sie ARC Zonal Autoshift aktivierenARC. Mit Zonal Autoshift können Sie sich AWS darauf verlassen, dass der Zustand Ihres EKS Clusters überwacht wird und dass automatisch ein Shift ausgelöst wird, wenn eine Beeinträchtigung der AZ erkannt 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, EKS ist ein Failsafe für das Senden von Datenverkehr an Pod-Endpunkte in einer beeinträchtigten Zone vorgesehen, wenn 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 keine Verbindung zu den persistenten Volumes herstellen können, die auf die beeinträchtigte AZ beschränkt sind.

Funktioniert diese Funktion mit Karpenter?

Die Unterstützung von Karpenter ist derzeit nicht verfügbar, wenn Zonal Shift und ARC Zonal Autoshift in aktiviert sind. EKS 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 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 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. ARCZonal 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

📝 Bearbeiten Sie diese Seite auf GitHub

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.