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-Pod-Failover durch Netzwerkunterbrechungen
Wir beginnen mit einem Überblick über die wichtigsten Konzepte, Komponenten und Einstellungen, die das Verhalten von Kubernetes bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerungsebene beeinflussen. EKS ist Upstream-Kubernetes-konform, sodass alle hier beschriebenen Kubernetes-Konzepte, -Komponenten und -Einstellungen für EKS- und EKS-Hybrid-Nodes-Bereitstellungen gelten.
Weitere Informationen zum Failover-Verhalten von Upstream-Kubernetes-Pods bei Netzwerkunterbrechungen finden Sie in den Problemen #131294 und #131481 im Upstream-Kubernetes-Repository. GitHub https://github.com/kubernetes/kubernetes/pull/131294
Konzepte
Taints and Tolerations: Taints und Tolerations werden in Kubernetes verwendet, um die Planung von Pods auf Knoten zu steuern. Taints werden vom Node-Lifecycle-Controller gesetzt, um anzuzeigen, dass Knoten nicht für die Planung in Frage kommen oder dass Pods auf diesen Knoten entfernt werden sollten. Wenn Knoten aufgrund einer Netzwerkunterbrechung nicht erreichbar sind, wendet der Node-Lifecycle-Controller die Node.Kubernetes an. io/unreachable Verderben mit einer Wirkung, und zwar mit einer Wirkung, wenn bestimmte Bedingungen erfüllt sind. NoSchedule NoExecute Der Node.Kubernetes. io/unreachable Taint entspricht Ready Being Unknown. NodeCondition Benutzer können Toleranzen für Taints auf Anwendungsebene in der angeben. PodSpec
-
NoSchedule: Auf dem Tainted-Knoten sind keine neuen Pods geplant, es sei denn, sie haben eine entsprechende Toleranz. Pods, die bereits auf dem Knoten laufen, werden nicht entfernt.
-
NoExecute: Pods, die den Taint nicht tolerieren, werden sofort entfernt. Pods, die den Taint tolerieren (ohne TolerationSeconds anzugeben), bleiben für immer gebunden. Pods, die den Taint mit einer bestimmten TolerationSeconds tolerieren, bleiben für die angegebene Zeit gebunden. Nach Ablauf dieser Zeit entfernt der Node Lifecycle Controller die Pods aus dem Knoten.
Node-Leases: Kubernetes verwendet die Lease-API, um die Heartbeats der Kubelet-Knoten an den Kubernetes-API-Server zu übermitteln. Für jeden Knoten gibt es ein Lease-Objekt mit einem passenden Namen. Intern aktualisiert jeder Kubelet-Heartbeat das Feld spec.RenewTime des Lease-Objekts. Die Kubernetes-Steuerungsebene verwendet den Zeitstempel dieses Felds, um die Knotenverfügbarkeit zu ermitteln. Wenn Knoten von der Kubernetes-Steuerungsebene getrennt sind, können sie spec.RenewTime für ihren Lease nicht aktualisieren, und die Steuerungsebene interpretiert dies so, dass Ready Unknown ist. NodeCondition
Komponenten
| Komponente | Sub-component | Description |
|---|---|---|
|
Kubernetes-Steuerungsebene |
Kube-API-Server |
Der API-Server ist eine Kernkomponente der Kubernetes-Steuerungsebene, die die Kubernetes-API verfügbar macht. |
|
Kubernetes-Steuerungsebene |
Knoten-Lebenszyklus-Controller |
Einer der Controller, die der Kube-Controller-Manager ausführt. Es ist dafür verantwortlich, Knotenprobleme zu erkennen und darauf zu reagieren. |
|
Kubernetes-Steuerungsebene |
Kube-Scheduler |
Eine Komponente der Steuerungsebene, die nach neu erstellten Pods ohne zugewiesenen Knoten Ausschau hält und einen Knoten auswählt, auf dem sie ausgeführt werden sollen. |
|
Kubernetes-Knoten |
kubelet |
Ein Agent, der auf jedem Knoten im Cluster ausgeführt wird. Das Kubelet überwacht PodSpecs und stellt sicher, dass die darin beschriebenen Container laufen und PodSpecs fehlerfrei sind. |
Konfigurationseinstellungen
| Komponente | Einstellung | Description | K8 ist Standard | EKS-Standard | Konfigurierbar in EKS |
|---|---|---|---|---|---|
|
Kube-API-Server |
Standard−Unerreichbar−Toleranz−Sekunden |
Gibt an, ob |
300 |
300 |
Nein |
|
Node-Lifecycle-Controller |
Node-Monitor-Grace-Period |
Die Zeitspanne, für die ein Knoten nicht reagiert, bevor er als fehlerhaft markiert wird. Muss N-mal höher sein als die von Kubelet |
40 |
40 |
Nein |
|
Node-Lifecycle-Controller |
Schwellenwert für große Clustergröße |
Die Anzahl der Knoten, bei denen der Node-Lifecycle-Controller den Cluster für die Löschlogik als groß behandelt. |
50 |
100 000 |
Nein |
|
Node-Lifecycle-Controller |
Schwellenwert für eine ungesunde Zone |
Der Prozentsatz der Knoten in einer Zone, die nicht bereit sein müssen, damit diese Zone als fehlerhaft behandelt wird. |
55% |
55% |
Nein |
|
kubelet |
Häufigkeit der Aktualisierung des Knotenstatus |
Wie oft sendet das Kubelet den Knotenstatus an die Steuerungsebene. Muss mit dem Node-Lifecycle-Controller |
10 |
10 |
Ja |
|
kubelet |
Knoten-Labels |
Labels, die bei der Registrierung des Knotens im Cluster hinzugefügt werden sollen. Das Label |
Keine |
Keine |
Ja |
Kubernetes-Pod-Failover durch Netzwerkunterbrechungen
Das hier beschriebene Verhalten geht davon aus, dass Pods als Kubernetes-Bereitstellungen mit Standardeinstellungen ausgeführt werden und dass EKS als Kubernetes-Anbieter verwendet wird. Das tatsächliche Verhalten kann je nach Umgebung, Art der Netzwerktrennung, Anwendungen, Abhängigkeiten und Clusterkonfiguration unterschiedlich sein. Der Inhalt dieses Handbuchs wurde anhand einer bestimmten Anwendung, Clusterkonfiguration und einer Untergruppe von Plug-ins überprüft. Es wird dringend empfohlen, das Verhalten in Ihrer eigenen Umgebung und mit Ihren eigenen Anwendungen zu testen, bevor Sie zur Produktion übergehen.
Wenn Netzwerkverbindungen zwischen Knoten und der Kubernetes-Steuerungsebene unterbrochen werden, kann das Kubelet auf jedem getrennten Knoten nicht mit der Kubernetes-Steuerungsebene kommunizieren. Folglich kann das Kubelet keine Pods auf diesen Knoten entfernen, bis die Verbindung wiederhergestellt ist. Das bedeutet, dass Pods, die vor der Netzwerktrennung auf diesen Knoten ausgeführt wurden, während der Trennung weiterlaufen, vorausgesetzt, sie werden nicht durch andere Fehler heruntergefahren. Zusammenfassend lässt sich sagen, dass Sie bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerungsebene statische Stabilität erreichen können. Sie können jedoch keine mutierenden Operationen an Ihren Knoten oder Workloads ausführen, bis die Verbindung wiederhergestellt ist.
Es gibt fünf Hauptszenarien, die je nach Art der Netzwerkunterbrechung zu unterschiedlichen Pod-Failover-Verhaltensweisen führen. In allen Szenarien wird der Cluster ohne Eingreifen des Bedieners wieder funktionsfähig, sobald die Knoten wieder eine Verbindung zur Kubernetes-Steuerungsebene herstellen. In den folgenden Szenarien werden die erwarteten Ergebnisse auf der Grundlage unserer Beobachtungen beschrieben. Diese Ergebnisse gelten jedoch möglicherweise nicht für alle möglichen Anwendungs- und Clusterkonfigurationen.
Szenario 1: Vollständige Cluster-Störung
Erwartetes Ergebnis: Pods auf nicht erreichbaren Knoten werden nicht entfernt und laufen auf diesen Knoten weiter.
Eine vollständige Clusterunterbrechung bedeutet, dass alle Knoten im Cluster von der Kubernetes-Steuerungsebene getrennt sind. In diesem Szenario erkennt der Node-Lifecycle-Controller auf der Steuerungsebene, dass alle Knoten im Cluster nicht erreichbar sind, und storniert alle Pod-Räumungen.
Cluster-Administratoren werden während der Verbindungsunterbrechung alle Knoten mit Status sehen. Not Ready Der Pod-Status ändert sich nicht, und während der Verbindungsunterbrechung und der anschließenden Wiederverbindung sind keine neuen Pods auf den Knoten geplant.
Szenario 2: Vollständige Zonenunterbrechung
Erwartetes Ergebnis: Das Verhalten hängt davon ab, ob die betroffene Zone die einzige Zone des Clusters ist.
Eine vollständige Zonenunterbrechung bedeutet, dass alle Knoten in der Zone von der Kubernetes-Steuerungsebene getrennt sind.
Single-zone Cluster (oder Cluster, bei denen Knoten das topology.kubernetes.io/zone Label fehlt): Wenn die betroffene Zone die einzige Zone des Clusters ist, entspricht eine vollständige Zonenunterbrechung einer vollständigen Clusterunterbrechung (Szenario 1). Der Node-Lifecycle-Controller wechselt in den „Master-Disruption-Modus“, da jede Zone über keine Ready-Nodes verfügt, und storniert alle Pod-Räumungen. Pods laufen weiterhin auf nicht erreichbaren Knoten.
Multi-zone Cluster: Wenn ein Cluster Knoten in mehreren Zonen hat und eine Zone vollständig ausfällt, haben die verbleibenden Zonen immer noch Ready-Knoten. In diesem Fall laufen die Räumungen normal ab — Pods auf nicht erreichbaren Knoten in der ausgefallenen Zone werden nach Ablauf der default-unreachable-toleration-seconds (5 Minuten) und node-monitor-grace-period (40 Sekunden) gelöscht, und neue Pods werden auf funktionierenden Knoten in den verbleibenden Zonen geplant. Weitere Informationen zu diesem Verhalten finden Sie unter Grundlegendes zur Räumung von Pods bei zonalen Unterbrechungen.
Anmerkung
Knoten ohne das topology.kubernetes.io/zone Label werden zu einer einzigen impliziten Zone zusammengefasst. Wenn alle Knoten in einem Multi-AZ-Cluster dieses Label nicht haben, verhält sich der Cluster so, als ob er nur eine Zone hätte, und eine vollständige Zonenunterbrechung löst unabhängig von der Anzahl der physischen Availability Zones das Verhalten von Szenario 1 aus.
Szenario 3: Störung in den meisten Zonen
Erwartetes Ergebnis: Pods auf nicht erreichbaren Knoten werden nicht entfernt und laufen auf diesen Knoten weiter.
Eine Störung der meisten Zonen bedeutet, dass die meisten Knoten in einer bestimmten Zone von der Kubernetes-Steuerungsebene getrennt sind. Zonen in Kubernetes werden durch Knoten mit derselben Bezeichnung definiert. topology.kubernetes.io/zone Wenn im Cluster keine Zonen definiert sind, bedeutet eine mehrheitliche Störung, dass die Mehrheit der Knoten im gesamten Cluster getrennt ist. Standardmäßig wird eine Mehrheit durch den Node-Lifecycle-Controller definiert, der sowohl in Kubernetes als auch in unhealthy-zone-threshold EKS auf 55% festgelegt ist. Weil in EKS auf 100.000 gesetzt large-cluster-size-threshold ist, werden Pod-Räumungen abgebrochen, wenn 55% oder mehr der Knoten in einer Zone nicht erreichbar sind (vorausgesetzt, dass die meisten Cluster weitaus kleiner als 100.000 Knoten sind).
Cluster-Administratoren sehen, dass die Mehrheit der Knoten in der Zone Not Ready während der Verbindungsunterbrechung den Status hat, aber der Status der Pods ändert sich nicht, und sie werden nicht auf anderen Knoten neu geplant.
Beachten Sie, dass das oben beschriebene Verhalten nur für Cluster gilt, die größer als drei Knoten sind. In Clustern mit drei Knoten oder weniger ist die Entfernung von Pods auf nicht erreichbaren Knoten geplant, und neue Pods werden auf intakten Knoten geplant.
Während der Tests haben wir gelegentlich beobachtet, dass Pods bei Netzwerkunterbrechungen von genau einem nicht erreichbaren Knoten entfernt wurden, selbst wenn die Mehrheit der Knoten der Zone nicht erreichbar war. Dies ist ein bekanntes Verhalten (siehe #131481unreachable:NoExecute bevor der Wert unhealthy-zone-threshold (55%) erreicht ist, wird dieser Makel nicht entfernt, sobald der Schwellenwert überschritten ist und die Reduzierung der Räumungsrate wirksam wird. Pods, die sich auf diesem bereits verseuchten Knoten befinden, werden immer noch nach ihrem Status entfernt. tolerationSeconds
Szenario 4: Störung der Minderheitenzone
Erwartetes Ergebnis: Pods werden von nicht erreichbaren Knoten entfernt, und neue Pods werden auf verfügbaren, geeigneten Knoten geplant.
Eine geringfügige Störung bedeutet, dass ein kleinerer Prozentsatz der Knoten in einer Zone von der Kubernetes-Steuerungsebene getrennt wird. Wenn im Cluster keine Zonen definiert sind, bedeutet eine Störung einer Minderheit, dass die Minderheit der Knoten im gesamten Cluster getrennt wird. Wie bereits erwähnt, wird die Minderheit durch die unhealthy-zone-threshold Einstellung Node-Lifecycle-Controller definiert, die standardmäßig bei 55% liegt. Wenn in diesem Szenario die Netzwerktrennung länger als die default-unreachable-toleration-seconds (5 Minuten) und node-monitor-grace-period (40 Sekunden) dauert und weniger als 55% der Knoten in einer Zone nicht erreichbar sind, werden neue Pods auf intakten Knoten eingeplant, während Pods auf nicht erreichbaren Knoten für die Entfernung markiert werden.
Cluster-Administratoren sehen, dass neue Pods auf intakten Knoten erstellt wurden, und die Pods auf getrennten Knoten werden als angezeigt. Terminating Denken Sie daran, dass Pods auf getrennten Knoten zwar einen Terminating Status haben, sie aber erst vollständig entfernt werden, wenn der Knoten wieder eine Verbindung zur Kubernetes-Steuerungsebene herstellt.
Szenario 5: Node-Neustart während einer Netzwerkunterbrechung
Erwartetes Ergebnis: Pods auf nicht erreichbaren Knoten werden erst gestartet, wenn die Knoten wieder eine Verbindung zur Kubernetes-Steuerungsebene herstellen. Das Pod-Failover folgt der in den Szenarien 1—3 beschriebenen Logik, abhängig von der Anzahl der nicht erreichbaren Knoten.
Ein Node-Neustart während einer Netzwerkunterbrechung bedeutet, dass ein weiterer Ausfall (z. B. ein Stromausfall, Speichermangel oder ein anderes Problem) auf einem Knoten gleichzeitig mit einer Netzwerkunterbrechung aufgetreten ist. Die Pods, die auf diesem Knoten liefen, als die Netzwerktrennung begann, werden während der Trennung nicht automatisch neu gestartet, wenn das Kubelet ebenfalls neu gestartet wurde. Das Kubelet fragt beim Start den Kubernetes-API-Server ab, um zu erfahren, welche Pods ausgeführt werden sollen. Wenn das Kubelet den API-Server aufgrund einer Netzwerkunterbrechung nicht erreichen kann, kann es die zum Starten der Pods erforderlichen Informationen nicht abrufen.
In diesem Szenario können lokale Tools zur Problembehandlung wie die crictl CLI nicht verwendet werden, um Pods manuell zu starten, um eine „glasklare“ Maßnahme zu sein. Kubernetes entfernt in der Regel ausgefallene Pods und erstellt neue, anstatt bestehende Pods neu zu starten (Einzelheiten finden Sie unter #10213
