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.
Lokaler EKS-Cluster auf Outposts
Wenn es zu Verbindungsabbrüchen zwischen Outposts und der übergeordneten Region kommt, kann es zu Problemen mit Diensten wie EKS Extended Cluster kommen, bei denen sich die Kontrollebene in der Region befindet. Zu den Herausforderungen gehört der Verlust der Kommunikation zwischen der EKS-Steuerebene und den Worker-Knoten und. PODs Obwohl beide Worker-Nodes weiterhin Anwendungen betreiben und warten PODs können, die sich lokal auf Outposts befinden, kann es sein, dass die Kubernetes-Kontrollebene sie als fehlerhaft einstuft und ihren Austausch einplant, wenn die Verbindung zur Kontrollebene wiederhergestellt ist. Dies kann zu Anwendungsausfällen führen, wenn die Konnektivität wiederhergestellt ist.
Um dies zu vereinfachen, besteht die Möglichkeit, Ihren gesamten EKS-Cluster auf Outposts zu hosten. In dieser Konfiguration werden sowohl die Kubernetes-Steuerebene als auch Ihre Worker-Knoten lokal vor Ort auf der Rechenkapazität Ihrer Outposts ausgeführt. Auf diese Weise funktioniert Ihr Cluster auch bei einem vorübergehenden Ausfall Ihrer Service Link-Verbindung und nach deren Wiederherstellung weiter.
Lokaler Amazon EKS-Cluster auf Outposts
Überlegungen zum lokalen EKS-Cluster auf Outposts
Es gibt einige Überlegungen, wenn ein lokaler EKS-Cluster in Outposts bereitgestellt wird:
-
Während einer Verbindungsunterbrechung gibt es keine Optionen, um Änderungen am Cluster selbst vorzunehmen, die das Hinzufügen neuer Worker-Knoten oder die automatische Skalierung einer Knotengruppe erfordern, solange dies von der übergeordneten Region abhängt EC2 und die AWS ASG-API-Aufrufe an sie richten.
