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. # Bewährte Methoden für Hybridbereitstellungen Dieses Handbuch enthält Anleitungen zur Ausführung von Bereitstellungen in lokalen oder Edge-Umgebungen mit EKS Hybrid Nodes oder EKS Anywhere. Wir haben derzeit Leitfäden zu den folgenden Themen veröffentlicht: + [Bewährte Methoden für EKS-Hybridknoten und Netzwerkunterbrechungen](hybrid-nodes-network-disconnections.md) # EKS-Hybridknoten und Netzwerkunterbrechungen Die EKS-Hybridknoten-Architektur kann für Kunden, die es gewohnt sind, lokale Kubernetes-Cluster vollständig in ihren eigenen Rechenzentren oder Edge-Standorten auszuführen, neu sein. Bei EKS-Hybridknoten läuft die Kubernetes-Steuerebene in einer AWS-Region und nur die Knoten werden lokal ausgeführt, was zu einer „erweiterten“ oder „erweiterten“ Kubernetes-Clusterarchitektur führt. Dies führt zu einer häufig gestellten Frage: „Was passiert, wenn meine Knoten von der Kubernetes-Steuerebene getrennt werden?“ In diesem Leitfaden beantworten wir diese Frage anhand eines Überblicks über die folgenden Themen. Es wird empfohlen, die Stabilität und Zuverlässigkeit Ihrer Anwendungen durch Netzwerkunterbrechungen zu überprüfen, da sich jede Anwendung je nach ihren Abhängigkeiten, Konfiguration und Umgebung unterschiedlich verhalten kann. Im aws-samples/ eks-hybrid-examples GitHub repo finden Sie Test-Setup, Verfahren und Ergebnisse, auf die Sie zurückgreifen können, um Netzwerkunterbrechungen mit EKS-Hybridknoten und Ihren eigenen Anwendungen zu testen. Das GitHub Repo enthält auch zusätzliche Informationen zu den Tests, die zur Validierung des in diesem Handbuch erläuterten Verhaltens verwendet wurden. + [Bewährte Methoden für Stabilität bei Netzwerkunterbrechungen](hybrid-nodes-network-disconnection-best-practices.md) + [Failover-Verhalten von Kubernetes-Pods durch Netzwerkunterbrechungen](hybrid-nodes-kubernetes-pod-failover.md) + [Netzwerkverkehr von Anwendungen durch Netzwerkunterbrechungen](hybrid-nodes-app-network-traffic.md) + [Host-Anmeldeinformationen bei Netzwerkunterbrechungen](hybrid-nodes-host-creds.md) # Bewährte Methoden für Stabilität bei Netzwerkunterbrechungen ## Hochverfügbares Netzwerk Der beste Ansatz, um Netzwerkunterbrechungen zwischen Hybridknoten und der Kubernetes-Steuerebene zu vermeiden, besteht darin, redundante, belastbare Verbindungen von Ihrer lokalen Umgebung zu und von AWS zu verwenden. Weitere Informationen zur Architektur hochverfügbarer Hybridnetzwerke mit diesen Lösungen finden Sie im [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) [und in der AWS Site-to-Site VPN-Dokumentation](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html). ## Hochverfügbare Anwendungen Berücksichtigen Sie bei der Anwendungsarchitektur Ihre Fehlerdomänen und die Auswirkungen verschiedener Arten von Ausfällen. Kubernetes bietet integrierte Mechanismen zur Bereitstellung und Wartung von Anwendungsreplikaten über Knoten-, Zonen- und regionale Domänen hinweg. Die Verwendung dieser Mechanismen hängt von Ihrer Anwendungsarchitektur, Ihren Umgebungen und Ihren Verfügbarkeitsanforderungen ab. Beispielsweise können statuslose Anwendungen häufig mit mehreren Replikaten bereitgestellt werden und sich über beliebige Hosts und Infrastrukturkapazitäten bewegen. Außerdem können Sie mithilfe von Knotenselektoren und Beschränkungen der Topologieverteilung Instanzen der Anwendung in verschiedenen Domänen ausführen. [Einzelheiten zu Techniken auf Anwendungsebene zur Erstellung robuster Anwendungen auf Kubernetes finden Sie im EKS Best Practices Guide.](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/) Kubernetes wertet bei der Entscheidung, ob Pods auf andere Knoten verschoben werden sollen, zonale Informationen für Knoten aus, die von der Kubernetes-Steuerebene getrennt sind. Wenn alle Knoten in einer Zone nicht erreichbar sind, storniert Kubernetes die Pod-Räumung für die Knoten in dieser Zone. Als bewährte Methode gilt: Wenn Sie eine Bereitstellung mit Knoten haben, die in mehreren Rechenzentren oder physischen Standorten ausgeführt werden, weisen Sie jedem Knoten eine Zone auf der Grundlage seines Rechenzentrums oder physischen Standorts zu. Wenn Sie EKS mit Knoten in der Cloud ausführen, wird dieses Zonenlabel automatisch von AWS angewendet cloud-controller-manager. A cloud-controller-manager wird jedoch nicht für Hybridknoten verwendet, sodass Sie diese Informationen über Ihre Kubelet-Konfiguration weitergeben können. Ein Beispiel für die Konfiguration einer Zone in Ihrer Knotenkonfiguration für Hybridknoten finden Sie unten. Die Konfiguration wird übergeben, wenn Sie Ihre Hybridknoten mit der Hybridknoten-CLI (`nodeadm`) mit Ihrem Cluster verbinden. Weitere Informationen zu dem `topology.kubernetes.io/zone` Label finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone). Weitere Informationen zur CLI für Hybridknoten finden Sie in der [Nodeadm-Referenz zu Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html). ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster region: my-region kubelet: flags: - --node-labels=topology.kubernetes.io/zone=dc1 hybrid: ... ``` ## Netzwerk-Überwachung Wenn Sie AWS Direct Connect oder AWS Site-to-Site VPN für Ihre Hybrid-Konnektivität verwenden, können Sie CloudWatch Alarme, Protokolle und Metriken nutzen, um den Status Ihrer Hybridverbindung zu beobachten und Probleme zu diagnostizieren. Weitere Informationen finden Sie unter [Überwachen von AWS Direct Connect Connect-Ressourcen](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) und [Überwachen einer Site-to-Site AWS-VPN-Verbindung](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html). Es wird empfohlen, Alarme für `NodeNotReady` Ereignisse zu erstellen, die von der auf der EKS-Ebene node-lifecycle-controller ausgeführten Steuerungsebene gemeldet werden. Dies signalisiert, dass bei einem Hybridknoten möglicherweise eine Netzwerkunterbrechung auftritt. Sie können diesen Alarm erstellen, indem Sie die Protokollierung der EKS-Kontrollebene für den Controller Manager aktivieren und einen Metrikfilter CloudWatch für die Meldung „Statusänderungsereignis für Knoten aufzeichnen“ mit dem Status= „“ erstellen. NodeNotReady Nachdem Sie einen Metrikfilter erstellt haben, können Sie einen Alarm für diesen Filter erstellen, der auf Ihren gewünschten Schwellenwerten basiert. Weitere Informationen finden Sie [in der Dokumentation unter Alarming for Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html). CloudWatch Sie können die integrierten Metriken Transit Gateway (TGW) und Virtual Private Gateway (VGW) verwenden, um den Netzwerkverkehr zu und von Ihrem TGW oder VGW zu beobachten. Sie können Alarme für diese Messwerte erstellen, um Szenarien zu erkennen, in denen der Netzwerkverkehr unter das normale Niveau fällt, was auf ein potenzielles Netzwerkproblem zwischen Hybridknoten und der EKS-Steuerebene hindeutet. Die TGW- und VGW-Metriken werden in der folgenden Tabelle beschrieben. | Gateway | Metrik | Description | | --- | --- | --- | | Transit-Gateway | BytesIn | Die von TGW vom Anhang empfangenen Bytes (EKS-Steuerebene für Hybridknoten) | | Transit-Gateway | BytesOut | Die von TGW an den Anhang gesendeten Bytes (Hybridknoten an die EKS-Steuerebene) | | Virtual Private Gateway | TunnelDataIn | Die von der AWS-Seite der Verbindung durch den VPN-Tunnel zum Kunden-Gateway gesendeten Bytes (EKS-Kontrollebene zu Hybridknoten) | | Virtual Private Gateway | TunnelDataOut | Die auf der AWS-Seite der Verbindung durch den VPN-Tunnel vom Kunden-Gateway empfangenen Bytes (Hybridknoten zur EKS-Steuerebene) | Sie können [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) auch verwenden, um tiefere Einblicke in Ihre Hybridverbindungen zu erhalten, um die durchschnittliche Zeit bis zur Wiederherstellung zu reduzieren und festzustellen, ob Netzwerkprobleme auf AWS oder Ihre Umgebung zurückzuführen sind. CloudWatch Network Monitor kann verwendet werden, um Paketverlust und Latenz in Ihren hybriden Netzwerkverbindungen zu visualisieren, Warnmeldungen und Schwellenwerte festzulegen und dann Maßnahmen zur Verbesserung Ihrer Netzwerkleistung zu ergreifen. Weitere Informationen finden Sie unter [Amazon CloudWatch Network Monitor verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html). EKS bietet mehrere Optionen zur Überwachung des Zustands Ihrer Cluster und Anwendungen. Für den Clusterstatus können Sie das Observability-Dashboard in der EKS-Konsole verwenden, um Probleme schnell zu erkennen, zu beheben und zu beheben. Sie können auch Amazon Managed Service für Prometheus, AWS Distro for Open Telemetry (ADOT) und für die Cluster-, Anwendungs- und CloudWatch Infrastrukturüberwachung verwenden. Weitere Informationen zu den EKS-Observability-Optionen finden Sie unter [Überwachen der Clusterleistung und Anzeigen von Protokollen](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html). ## Lokale Problembehandlung Um Netzwerkunterbrechungen zwischen Hybridknoten und der EKS-Steuerebene vorzubereiten, können Sie sekundäre Überwachungs- und Protokollierungs-Backends einrichten, um die Beobachtbarkeit für Anwendungen aufrechtzuerhalten, wenn regionale AWS-Services nicht erreichbar sind. Sie können beispielsweise den AWS Distro for Open Telemetry (ADOT) Collector so konfigurieren, dass er Metriken und Protokolle an mehrere Backends sendet. Sie können auch lokale Tools wie die `crictl` CLI verwenden, um lokal mit Pods und Containern zu interagieren, als Ersatz für `kubectl` oder andere Kubernetes-API-kompatible Clients, die normalerweise den Kubernetes-API-Serverendpunkt abfragen. [Weitere Informationen dazu finden Sie in der Dokumentation in den `crictl` CRI-Tools. `crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) GitHub Im Folgenden sind einige nützliche `crictl` Befehle aufgeführt. Listet die Pods auf, die auf dem Host ausgeführt werden: ``` crictl pods ``` Listet die Container auf, die auf dem Host laufen: ``` crictl ps ``` Listet die auf dem Host laufenden Bilder auf: ``` crictl images ``` Ruft die Protokolle eines Containers ab, der auf dem Host läuft: ``` crictl logs CONTAINER_NAME ``` Holen Sie sich Statistiken über Pods, die auf dem Host ausgeführt werden: ``` crictl statsp ``` ## Netzwerkverkehr der Anwendung Bei der Verwendung von Hybridknoten ist es wichtig, die Netzwerkflüsse Ihres Anwendungsverkehrs und die Technologien, mit denen Sie Ihre Anwendungen extern in Ihrem Cluster bereitstellen, zu berücksichtigen und zu verstehen. Verschiedene Technologien für den Lastenausgleich und den eingehenden Datenverkehr von Anwendungen verhalten sich bei Netzwerkunterbrechungen unterschiedlich. Wenn Sie beispielsweise die BGP Control Plane-Funktion von Cilium für den Lastenausgleich von Anwendungen verwenden, kann es sein, dass die BGP-Sitzung für Ihre Pods und Dienste während Netzwerkunterbrechungen unterbrochen wird. Dies liegt daran, dass die BGP-Lautsprecherfunktion in den Cilium-Agent integriert ist und der Cilium-Agent kontinuierlich neu gestartet wird, wenn er von der Kubernetes-Steuerebene getrennt wird. Der Grund für den Neustart liegt darin, dass die Integritätsprüfung von Cilium fehlschlägt, weil sein Zustand mit dem Zugriff auf die Kubernetes-Steuerebene verknüpft ist (siehe [CFP:](https://github.com/cilium/cilium/issues/31702) \$131702 mit einer Opt-in-Verbesserung in Cilium v1.17). Wenn Sie Application Load Balancers (ALB) oder Network Load Balancers (NLB) für Anwendungsdatenverkehr aus der AWS-Region verwenden, kann dieser Datenverkehr ebenfalls vorübergehend ausfallen, wenn Ihre lokale Umgebung die Konnektivität zur AWS-Region verliert. Es wird empfohlen, vor der Bereitstellung in der Produktion zu überprüfen, ob die Technologien, die Sie für Load Balancing und Ingress verwenden, auch bei Netzwerkunterbrechungen stabil bleiben. Das Beispiel im [AWS-Samples/ eks-hybrid-examples](https://github.com/aws-samples/eks-hybrid-examples) GitHub Repo verwendet MetalB für den Lastenausgleich im [L2-Modus](https://metallb.universe.tf/concepts/layer2/), der auch bei Netzwerkunterbrechungen zwischen Hybridknoten und der EKS-Steuerebene stabil bleibt. ## Überprüfen Sie die Abhängigkeiten von AWS-Remote-Services Beachten Sie bei der Verwendung von Hybridknoten die Abhängigkeiten, die Sie von regionalen AWS-Services eingehen, die sich außerhalb Ihrer lokalen oder Edge-Umgebung befinden. Beispiele hierfür sind der Zugriff auf Amazon S3 oder Amazon RDS für Anwendungsdaten, die Verwendung von Amazon Managed Service für Prometheus oder CloudWatch für Metriken und Protokolle, die Verwendung von Application- und Network Load Balancern für regionalen Datenverkehr und das Abrufen von Containern aus Amazon Elastic Container Registry. Auf diese Services kann bei Netzwerkunterbrechungen zwischen Ihrer lokalen Umgebung und AWS nicht zugegriffen werden. Wenn Ihre lokale Umgebung anfällig für Netzwerkunterbrechungen mit AWS ist, überprüfen Sie Ihre Nutzung der AWS-Services und stellen Sie sicher, dass der Verlust der Verbindung zu diesen Services die statische Stabilität Ihrer Anwendungen nicht beeinträchtigt. ## Optimieren Sie das Failover-Verhalten von Kubernetes-Pods Es gibt Optionen zum Optimieren des Pod-Failover-Verhaltens bei Netzwerkunterbrechungen für Anwendungen, die nicht zwischen Hosts portierbar sind, oder für Umgebungen mit eingeschränkten Ressourcen, die keine freien Kapazitäten für Pod-Failover haben. Im Allgemeinen ist es wichtig, die Ressourcenanforderungen Ihrer Anwendungen zu berücksichtigen und über genügend Kapazität zu verfügen, damit eine oder mehrere Instanzen der Anwendung bei einem Ausfall eines Nodes ein Failover auf einen anderen Host durchführen können. + Option 1 — Verwendung DaemonSets: Diese Option gilt für Anwendungen, die auf allen Knoten im Cluster ausgeführt werden können und sollten. DaemonSets werden automatisch so konfiguriert, dass sie den unerreichbaren Makel tolerieren, der dafür sorgt, dass DaemonSet Pods auch bei Netzwerkunterbrechungen an ihre Knoten gebunden bleiben. + Option 2 — Auf unerreichbaren Makel einstellen `tolerationSeconds`: Sie können einstellen, wie lange Ihre Pods bei Netzwerkunterbrechungen an Knoten gebunden bleiben. Konfigurieren Sie dazu die Anwendungs-Pods so, dass sie den unerreichbaren Makel mit der `NoExecute` Wirkung für eine von Ihnen (`tolerationSeconds`in der Anwendungsspezifikation) festgelegte Dauer tolerieren. Mit dieser Option bleiben Ihre Anwendungs-Pods bei Netzwerkunterbrechungen an Knoten gebunden, bis sie ablaufen. `tolerationSeconds` Denken Sie sorgfältig darüber nach, denn wenn Sie den `tolerationSeconds` Fehler „Unerreichbar“ mit erhöhen, kann es länger `NoExecute` dauern, bis Pods, die auf nicht erreichbaren Hosts laufen, auf andere erreichbare, fehlerfreie Hosts verschoben werden. + Option 3: Benutzerdefinierter Controller: Sie können einen benutzerdefinierten Controller (oder eine andere Software) erstellen und ausführen, der Kubernetes auf den unerreichbaren Makel mit dem Effekt überwacht. `NoExecute` Wenn dieser Fehler erkannt wird, kann der benutzerdefinierte Controller anwendungsspezifische Metriken überprüfen, um den Zustand der Anwendung zu beurteilen. Wenn die Anwendung fehlerfrei ist, kann der benutzerdefinierte Controller den unerreichbaren Makel entfernen und so verhindern, dass bei Netzwerkunterbrechungen Pods von den Knoten entfernt werden. Im Folgenden finden Sie ein Beispiel dafür, wie Sie ein Deployment `tolerationSeconds` für den unerreichbaren Makel konfigurieren können. Im Beispiel `tolerationSeconds` ist auf `1800` (30 Minuten) gesetzt, was bedeutet, dass Pods, die auf nicht erreichbaren Knoten laufen, nur entfernt werden, wenn die Netzwerkunterbrechung länger als 30 Minuten dauert. ``` apiVersion: apps/v1 kind: Deployment metadata: ... spec: ... tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 1800 ``` # 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-Steuerebene beeinflussen. EKS ist Upstream-Kubernetes-konform, sodass alle hier beschriebenen Kubernetes-Konzepte, -Komponenten und -Einstellungen für EKS- und EKS-Hybridknoten-Bereitstellungen gelten. [https://github.com/kubernetes/kubernetes/pull/131294](https://github.com/kubernetes/kubernetes/pull/131294) ## Konzepte Taints and Tolerations: Taints and Tolerations werden in Kubernetes verwendet, um die Planung von Pods auf Knoten zu kontrollieren. Taints werden von der gesetzt, node-lifecycle-controller um darauf hinzuweisen, 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, gilt das für node.kubernetes. node-lifecycle-controller io/unreachable taint with a NoSchedule effect, and with a NoExecute effect if certain conditions are met. The node.kubernetes.io/unreachableTaint bedeutet, dass Ready Unknown ist. NodeCondition Benutzer können Toleranzen für Taints auf Anwendungsebene in angeben. PodSpec + NoSchedule: Auf dem fehlerhaften 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 Makel nicht vertragen, werden sofort entfernt. Pods, die den Taint tolerieren (ohne TolerationSeconds anzugeben), bleiben für immer gebunden. Pods, die den Taint mit einem bestimmten TolerationSeconds-Wert 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 des Kubelet-Knotens 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-Steuerebene verwendet den Zeitstempel dieses Felds, um die Verfügbarkeit des Knotens zu bestimmen. Wenn Knoten von der Kubernetes-Steuerebene getrennt werden, können sie Spec.RenewTime nicht für ihren Lease aktualisieren, und die Kontrollebene interpretiert dies als „Ready being Unknown“. NodeCondition ## Komponenten ![\[Kubernetes-Komponenten, die am Pod-Failover-Verhalten beteiligt sind\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png) | Komponente | Unterkomponente | Description | | --- | --- | --- | | Kubernetes-Steuerebene | kube-api-server | Der API-Server ist eine Kernkomponente der Kubernetes-Steuerebene, die die Kubernetes-API verfügbar macht. | | Kubernetes-Steuerebene | node-lifecycle-controller | Einer der Controller, die der ausführt. kube-controller-manager Er ist dafür verantwortlich, Knotenprobleme zu erkennen und darauf zu reagieren. | | Kubernetes-Steuerebene | Kube-Scheduler | Eine Komponente der Steuerungsebene, die nach neu erstellten Pods ohne zugewiesenen Knoten sucht 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 | Die Standardeinstellung von K8 | EKS-Standard | In EKS konfigurierbar | | --- | --- | --- | --- | --- | --- | | kube-api-server | default-unreachable-toleration-seconds | Gibt an, wie hoch die Toleranz `unreachable:NoExecute` dafür ist, die standardmäßig jedem Pod hinzugefügt wird, der noch nicht über eine solche Toleranz verfügt. `tolerationSeconds` | 300 | 300 | Nein | | node-lifecycle-controller | node-monitor-grace-period | Gibt an, wie lange ein Knoten nicht reagieren kann, bevor er als fehlerhaft markiert wird. Muss N-mal höher sein als der Wert von Kubelet`nodeStatusUpdateFrequency`, wobei N die Anzahl der Wiederholungen ist, die das Kubelet zum Post-Node-Status benötigt. | 40 | 40 | Nein | | node-lifecycle-controller | large-cluster-size-threshold | Die Anzahl der Knoten, bei denen der den Cluster aus Gründen der node-lifecycle-controller Räumungslogik als groß behandelt. `--secondary-node-eviction-rate`wird für Cluster dieser Größe oder kleiner auf 0 überschrieben. | 50 | 100 000 | Nein | | node-lifecycle-controller | unhealthy-zone-threshold | Der Prozentsatz der Knoten in einer Zone, die nicht bereit sein müssen, damit diese Zone als fehlerhaft behandelt wird. | 55% | 55% | Nein | | kubelet | node-status-update-frequency | Wie oft sendet das Kubelet den Knotenstatus an die Kontrollebene. Muss mit in kompatibel `nodeMonitorGracePeriod` sein. node-lifecycle-controller | 10 | 10 | Ja | | kubelet | Knotenbeschriftungen | Labels, die bei der Registrierung des Knotens im Cluster hinzugefügt werden sollen. Das Label `topology.kubernetes.io/zone` kann mit Hybridknoten angegeben werden, um Knoten in Zonen zu gruppieren. | Keine | Keine | Ja | ## Kubernetes-Pod-Failover durch Netzwerkunterbrechungen Das hier beschriebene Verhalten setzt voraus, 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, einer Clusterkonfiguration und einer Teilmenge von Plugins validiert. 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-Steuerebene unterbrochen werden, kann das Kubelet auf jedem getrennten Knoten nicht mit der Kubernetes-Steuerebene kommunizieren. Folglich kann das Kubelet keine Pods auf diesen Knoten entfernen, bis die Verbindung wiederhergestellt ist. Das bedeutet, dass Pods, die vor der Netzwerkunterbrechung auf diesen Knoten ausgeführt wurden, auch während der Verbindungsunterbrechung weiterlaufen, vorausgesetzt, sie werden nicht durch andere Fehler heruntergefahren. Zusammenfassend lässt sich sagen, dass Sie bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerebene statische Stabilität erreichen können, aber Sie können keine Mutationsoperationen an Ihren Knoten oder Workloads durchfü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 mit der Kubernetes-Steuerebene verbunden sind. 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 Unterbrechung des Clusters **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-Steuerebene getrennt sind. In diesem Szenario erkennt das System node-lifecycle-controller auf der Steuerungsebene, dass alle Knoten im Cluster nicht erreichbar sind, und bricht alle Pod-Räumungen ab. Clusteradministratoren sehen während der Verbindungsunterbrechung alle Knoten mit Status`Not Ready`. Der Pod-Status ändert sich nicht, und während der Verbindungsunterbrechung und der anschließenden Wiederverbindung sind auf keinem der Knoten neue Pods geplant. ### Szenario 2: Vollständige Zonenunterbrechung **Erwartetes Ergebnis**: Pods auf nicht erreichbaren Knoten werden nicht entfernt und laufen auf diesen Knoten weiter. Eine vollständige Zonenunterbrechung bedeutet, dass alle Knoten in der Zone von der Kubernetes-Steuerebene getrennt sind. In diesem Szenario erkennt die node-lifecycle-controller Kontrollebene, dass alle Knoten in der Zone nicht erreichbar sind, und storniert alle Pod-Räumungen. Clusteradministratoren sehen während der Verbindungsunterbrechung alle Knoten mit Status`Not Ready`. Der Pod-Status ändert sich nicht, und während der Verbindungsunterbrechung und der anschließenden Wiederverbindung sind auf keinem der Knoten neue Pods geplant. ### Szenario 3: Störung der meisten Zonen **Erwartetes Ergebnis**: Pods auf nicht erreichbaren Knoten werden nicht entfernt und laufen auf diesen Knoten weiter. Eine mehrheitliche Zonenunterbrechung bedeutet, dass die meisten Knoten in einer bestimmten Zone von der Kubernetes-Steuerebene 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 Unterbrechung, dass die meisten Knoten im gesamten Cluster getrennt sind. Standardmäßig wird eine Mehrheit durch den node-lifecycle-controller s definiert`unhealthy-zone-threshold`, der sowohl in Kubernetes als auch in EKS auf 55% festgelegt ist. Da in EKS auf 100.000 festgelegt `large-cluster-size-threshold` ist, werden Pod-Räumungen abgebrochen, wenn 55% oder mehr der Knoten in einer Zone nicht erreichbar sind (da die meisten Cluster weitaus kleiner als 100.000 Knoten sind). Clusteradministratoren werden sehen, dass die meisten Knoten in der Zone `Not Ready` während der Verbindungsunterbrechung einen Status haben, aber der Status der Pods wird sich nicht ändern, und sie werden nicht auf anderen Knoten neu geplant. Beachten Sie, dass das obige Verhalten nur für Cluster gilt, die größer als drei Knoten sind. In Clustern mit drei oder weniger Knoten wird die Räumung 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 ein Großteil der Knoten der Zone nicht erreichbar war. Wir untersuchen immer noch eine mögliche Rennbedingung in Kubernetes node-lifecycle-controller als Ursache für dieses Verhalten. ### Szenario 4: Störung der Minderheitenzonen **Erwartetes Ergebnis**: Pods werden von Knoten entfernt, die nicht erreichbar sind, 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-Steuerebene getrennt wird. Wenn im Cluster keine Zonen definiert sind, bedeutet eine Störung einer Minderheit, dass die Minderheit der Knoten im gesamten Cluster getrennt ist. Wie bereits erwähnt, wird die Minderheit durch die `unhealthy-zone-threshold` Einstellung von definiert node-lifecycle-controller, die standardmäßig 55% beträgt. Wenn in diesem Szenario die Netzwerkunterbrechung länger als `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 fehlerfreien Knoten geplant, während Pods auf nicht erreichbaren Knoten zur Räumung markiert werden. Clusteradministratoren werden sehen, dass neue Pods auf fehlerfreien 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, aber erst dann vollständig gelöscht werden, wenn der Knoten wieder eine Verbindung zur Kubernetes-Steuerebene herstellt. ## Szenario 5: Neustart des Knotens während einer Netzwerkunterbrechung **Erwartetes Ergebnis**: Pods auf nicht erreichbaren Knoten werden erst gestartet, wenn sich die Knoten wieder mit der Kubernetes-Steuerebene verbinden. Der Pod-Failover folgt der in den Szenarien 1—3 beschriebenen Logik, abhängig von der Anzahl der nicht erreichbaren Knoten. Ein Knotenneustart während einer Netzwerkunterbrechung bedeutet, dass gleichzeitig mit einer Netzwerkunterbrechung ein weiterer Fehler (z. B. ein Stromausfall, ein out-of-memory Ereignis oder ein anderes Problem) auf einem Knoten aufgetreten ist. Die Pods, die zu Beginn der Netzwerkunterbrechung auf diesem Knoten liefen, werden während der Verbindungsunterbrechung 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 es ausführen soll. 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 Fehlerbehebung wie die `crictl` CLI nicht verwendet werden, um Pods manuell als „Glasbruch“ zu starten. Kubernetes entfernt normalerweise fehlgeschlagene Pods und erstellt neue, anstatt bestehende Pods neu zu starten (weitere Informationen finden Sie unter [\$110213](https://github.com/containerd/containerd/pull/10213) containerd GitHub Containerd-Repo). Statische Pods sind das einzige Kubernetes-Workload-Objekt, das vom Kubelet gesteuert wird und in diesen Szenarien neu gestartet werden kann. Es wird jedoch generell nicht empfohlen, statische Pods für Anwendungsbereitstellungen zu verwenden. Stellen Sie stattdessen mehrere Replikate auf verschiedenen Hosts bereit, um die Anwendungsverfügbarkeit bei mehreren gleichzeitigen Ausfällen sicherzustellen, z. B. bei einem Knotenausfall und einer Netzwerkunterbrechung zwischen Ihren Knoten und der Kubernetes-Steuerebene. # Netzwerkverkehr von Anwendungen durch Netzwerkunterbrechungen Die Themen auf dieser Seite beziehen sich auf Kubernetes-Clusternetzwerke und den Anwendungsdatenverkehr bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerebene. ## Cilium Cilium bietet mehrere Modi für IP-Adressverwaltung (IPAM), Kapselung, Lastenausgleich und Cluster-Routing. Die in diesem Handbuch validierten Modi verwendeten Cluster Scope IPAM, VXLAN-Overlay, BGP-Loadbalancing und Kube-Proxy. Cilium wurde auch ohne BGP-Loadbalancing verwendet und durch MetalLB L2-Load Balancing ersetzt. Die Basis der Cilium-Installation besteht aus dem Cilium-Operator und den Cilium-Agenten. [Der Cilium-Operator wird als Deployment ausgeführt und registriert die Cilium Custom Resource Definitions (CRDs), verwaltet IPAM und synchronisiert Cluster-Objekte unter anderem mit dem Kubernetes-API-Server.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Die Cilium-Agenten laufen auf jedem Knoten als DaemonSet und verwalten die eBPF-Programme, um die Netzwerkregeln für Workloads zu kontrollieren, die auf dem Cluster ausgeführt werden. Im Allgemeinen bleibt das von Cilium konfigurierte In-Cluster-Routing auch bei Netzwerkunterbrechungen verfügbar und an Ort und Stelle. Dies kann anhand der Cluster-Datenflüsse und der IP-Tabellenregeln (iptables) für das Pod-Netzwerk bestätigt werden. ``` ip route show table all | grep cilium ``` ``` 10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450 10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 10.86.3.16 dev cilium_host proto kernel scope link ... ``` Bei Netzwerkunterbrechungen werden der Cilium-Operator und die Cilium-Agenten jedoch neu gestartet, da ihre Integritätsprüfungen mit dem Zustand der Verbindung mit dem Kubernetes-API-Server verknüpft sind. Bei Netzwerkunterbrechungen wird in den Protokollen des Cilium-Operators und der Cilium-Agenten voraussichtlich Folgendes angezeigt: Während der Netzwerkunterbrechungen können Sie Tools wie die `crictl` CLI verwenden, um die Neustarts dieser Komponenten einschließlich ihrer Protokolle zu beobachten. ``` msg="Started gops server" address="127.0.0.1:9890" subsys=gops msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s msg=Stopping msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon ``` Wenn Sie die BGP Control Plane-Funktion von Cilium für den Lastenausgleich von Anwendungen verwenden, kann es sein, dass die BGP-Sitzung für Ihre Pods und Dienste während Netzwerkunterbrechungen unterbrochen wird, da die BGP-Lautsprecherfunktion in den Cilium-Agent integriert ist und der Cilium-Agent kontinuierlich neu gestartet wird, wenn die Verbindung zur Kubernetes-Steuerebene getrennt wird. Weitere Informationen finden Sie im Cilium BGP Control Plane Operation Guide in der Cilium-Dokumentation. Außerdem werden die Cilium-Routen bei diesen Aktionen nicht beibehalten, wenn während einer Netzwerkunterbrechung, z. B. bei einem Netzwechsel oder einem Maschinenneustart, gleichzeitig ein Fehler auftritt. Die Routen werden jedoch neu erstellt, wenn der Knoten wieder eine Verbindung zur Kubernetes-Steuerebene herstellt und Cilium erneut gestartet wird. ## Calico *Kommt bald* ## Metall B [MetalLB hat zwei Modi für den Lastenausgleich: den [L2-Modus und den BGP-Modus](https://metallb.universe.tf/concepts/layer2/).](https://metallb.universe.tf/concepts/bgp/) Einzelheiten zur Funktionsweise dieser Lastenausgleichsmodi und zu ihren Einschränkungen finden Sie in der MetalLB-Dokumentation. Bei der Validierung dieses Handbuchs wurde MetalLB im L2-Modus verwendet, wobei ein Computer im Cluster den Besitz des Kubernetes-Dienstes übernimmt und ARP verwendet, um die IP-Adressen des Load Balancers im lokalen Netzwerk erreichbar IPv4 zu machen. Bei der Ausführung von MetalB gibt es einen Controller, der für die IP-Zuweisung verantwortlich ist, und Lautsprecher, die auf jedem Knoten laufen und für die Werbung von Diensten mit zugewiesenen IP-Adressen verantwortlich sind. Der MetalB-Controller läuft als Deployment und die MetalB-Lautsprecher laufen als. DaemonSet Bei Netzwerkunterbrechungen können der MetalB-Controller und die Lautsprecher den Kubernetes-API-Server nicht nach Cluster-Ressourcen durchsuchen, sondern laufen weiter. Am wichtigsten ist, dass die Dienste, die MetalB für externe Konnektivität verwenden, auch bei Netzwerkunterbrechungen verfügbar und zugänglich bleiben. ## kube-proxy In EKS-Clustern wird Kube-Proxy DaemonSet auf jedem Knoten als a ausgeführt und ist für die Verwaltung von Netzwerkregeln verantwortlich, um die Kommunikation zwischen Diensten und Pods zu ermöglichen, indem Dienst-IP-Adressen in die IP-Adressen der zugrunde liegenden Pods übersetzt werden. Die von kube-proxy konfigurierten Regeln für IP-Tabellen (iptables) werden bei Netzwerkunterbrechungen beibehalten, und das Routing innerhalb des Clusters funktioniert weiterhin und die Kube-Proxy-Pods werden weiterhin ausgeführt. Sie können die Kube-Proxy-Regeln mit den folgenden iptables-Befehlen einhalten. Der erste Befehl zeigt, dass Pakete, die die Kette durchlaufen, an die `PREROUTING` Kette weitergeleitet werden. `KUBE-SERVICES` ``` iptables -t nat -L PREROUTING ``` ``` Chain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */ ``` Wenn wir uns die `KUBE-SERVICES` Kette ansehen, können wir die Regeln für die verschiedenen Clusterdienste sehen. ``` Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP / KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP / KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP / KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP / KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP / KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP / KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP / KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP / KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP / KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP / KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP / KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ``` Wenn wir die Kette des Frontend-Dienstes für die Anwendung untersuchen, können wir die Pod-IP-Adressen sehen, die den Dienst unterstützen. ``` iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q ``` ``` Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references) target prot opt source destination KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349 KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000 KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */ ``` Die folgenden Kube-Proxy-Protokollmeldungen werden bei Netzwerkunterbrechungen erwartet, wenn versucht wird, den Kubernetes-API-Server auf Aktualisierungen der Knoten- und Endpunktressourcen zu überprüfen. ``` "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError" "Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError" ``` ## CoreDNS Standardmäßig verwenden Pods in EKS-Clustern die CoreDNS-Cluster-IP-Adresse als Nameserver für DNS-Abfragen im Cluster. In EKS-Clustern wird CoreDNS als Deployment auf Knoten ausgeführt. Mit Hybridknoten können Pods bei Netzwerkunterbrechungen weiterhin mit dem CoreDNS kommunizieren, wenn CoreDNS-Replikate lokal auf Hybridknoten ausgeführt werden. Wenn Sie einen EKS-Cluster mit Knoten in der Cloud und Hybridknoten in Ihrer lokalen Umgebung haben, wird empfohlen, in jeder Umgebung mindestens ein CoreDNS-Replikat zu haben. CoreDNS bedient weiterhin DNS-Abfragen für Datensätze, die vor der Netzwerkunterbrechung erstellt wurden, und führt aus Gründen der statischen Stabilität weiterhin die Netzwerkwiederverbindung durch. Die folgenden CoreDNS-Protokollmeldungen werden bei Netzwerkunterbrechungen erwartet, wenn versucht wird, Objekte vom Kubernetes-API-Server aufzulisten. ``` Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout ``` # Host-Anmeldeinformationen bei Netzwerkunterbrechungen EKS Hybrid Nodes ist in Hybridaktivierungen von AWS Systems Manager (SSM) und AWS IAM Roles Anywhere für temporäre IAM-Anmeldeinformationen integriert, die zur Authentifizierung des Knotens mit der EKS-Steuerebene verwendet werden. Sowohl SSM als auch IAM Roles Anywhere aktualisieren automatisch die temporären Anmeldeinformationen, die sie auf lokalen Hosts verwalten. Es wird empfohlen, für alle Hybridknoten in Ihrem Cluster einen einzigen Anmeldeinformationsanbieter zu verwenden — entweder SSM-Hybrid-Aktivierungen oder IAM Roles Anywhere, aber nicht beides. ## SSM-Hybrid-Aktivierungen Die von SSM bereitgestellten temporären Anmeldeinformationen sind eine Stunde lang gültig. Sie können die Gültigkeitsdauer der Anmeldeinformationen nicht ändern, wenn Sie SSM als Ihren Anmeldeinformationsanbieter verwenden. Die temporären Anmeldeinformationen werden von SSM automatisch rotiert, bevor sie ablaufen, und die Rotation hat keinen Einfluss auf den Status Ihrer Knoten oder Anwendungen. Wenn es jedoch zu Netzwerkunterbrechungen zwischen dem SSM-Agent und dem regionalen SSM-Endpunkt kommt, kann SSM die Anmeldeinformationen nicht aktualisieren, und die Anmeldeinformationen laufen möglicherweise ab. SSM verwendet exponentielles Backoff für Wiederholungsversuche bei der Aktualisierung der Anmeldeinformationen, wenn keine Verbindung zu den regionalen SSM-Endpunkten hergestellt werden kann. In der SSM-Agent-Version `3.3.808.0` und höher (veröffentlicht im August 2024) ist der exponentielle Backoff auf 30 Minuten begrenzt. Abhängig von der Dauer Ihrer Netzwerkunterbrechung kann es bis zu 30 Minuten dauern, bis SSM die Anmeldeinformationen aktualisiert hat, und Hybridknoten stellen erst wieder eine Verbindung zur EKS-Steuerebene her, wenn die Anmeldeinformationen aktualisiert wurden. In diesem Szenario können Sie den SSM-Agent neu starten, um eine Aktualisierung der Anmeldeinformationen zu erzwingen. Als Nebeneffekt des aktuellen Aktualisierungsverhaltens der SSM-Anmeldeinformationen können sich Knoten zu unterschiedlichen Zeiten erneut verbinden, je nachdem, wann der SSM-Agent auf jedem Knoten seine Anmeldeinformationen aktualisieren kann. Aus diesem Grund kann es zu einem Pod-Failover von Knoten, die noch nicht wieder verbunden wurden, zu Knoten kommen, die bereits wieder verbunden sind. Holen Sie sich die SSM-Agent-Version. Sie können auch den Fleet Manager-Bereich der SSM-Konsole überprüfen: ``` # AL2023, RHEL yum info amazon-ssm-agent # Ubuntu snap list amazon-ssm-agent ``` Starten Sie den SSM-Agenten neu: ``` # AL2023, RHEL systemctl restart amazon-ssm-agent # Ubuntu systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` SSM-Agent-Protokolle anzeigen: ``` tail -f /var/log/amazon/ssm/amazon-ssm-agent.log ``` Erwartete Protokollmeldungen bei Netzwerkunterbrechungen: ``` INFO [CredentialRefresher] Credentials ready INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials ``` ## IAM Roles Anywhere Die von IAM Roles Anywhere bereitgestellten temporären Anmeldeinformationen sind standardmäßig für eine Stunde gültig. Sie können die Gültigkeitsdauer der Anmeldeinformationen mit IAM Roles Anywhere über das [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object)Feld in Ihrem IAM Roles Anywhere-Profil konfigurieren. Die maximale Gültigkeitsdauer der Anmeldeinformationen beträgt 12 Stunden. Die [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html)Einstellung in Ihrer IAM-Rolle Hybrid Nodes muss größer sein als die `durationSeconds` Einstellung in Ihrem IAM Roles Anywhere-Profil. Wenn Sie IAM Roles Anywhere als Anmeldeinformationsanbieter für Ihre Hybridknoten verwenden, erfolgt die Wiederherstellung der Verbindung zur EKS-Steuerebene nach Netzwerkunterbrechungen in der Regel innerhalb von Sekunden nach der Netzwerkwiederherstellung, da das Kubelet anruft, um Anmeldeinformationen bei Bedarf abzurufen. `aws_signing_helper credential-process` Wenn Sie IAM Roles Anywhere verwenden, können Sie Benachrichtigungen und Warnmeldungen für den Ablauf von Zertifikaten konfigurieren, obwohl dies nicht direkt mit Hybridknoten oder Netzwerkunterbrechungen zusammenhängt. Weitere Informationen finden Sie unter [Anpassen der Benachrichtigungseinstellungen in IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html) Roles Anywhere.