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 Stabilität bei Netzwerkunterbrechungen

Hochverfügbare Netzwerke

Der beste Ansatz, um Netzwerkunterbrechungen zwischen Hybridknoten und der Kubernetes-Steuerungsebene 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 und in der Site-to-Site AWS-VPN-Dokumentation.

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 Verwaltung von Anwendungsreplikaten in Knoten-, Zonen- und regionalen Domänen. Die Verwendung dieser Mechanismen hängt von Ihrer Anwendungsarchitektur, Ihren Umgebungen und den Verfügbarkeitsanforderungen ab. Beispielsweise können statusfreie Anwendungen häufig mit mehreren Replikaten bereitgestellt werden und sich über beliebige Hosts und Infrastrukturkapazitäten hinweg bewegen. Sie können Node-Selektoren und Topologie-Spreizing-Beschränkungen verwenden, um Instanzen der Anwendung in verschiedenen Domänen auszuführen. Einzelheiten zu Techniken auf Anwendungsebene zum Erstellen robuster Anwendungen auf Kubernetes finden Sie im EKS-Leitfaden mit Best Practices. 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-Steuerungsebene 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 laufen, weisen Sie jedem Knoten eine Zone zu, die auf seinem Rechenzentrum oder physischen Standort basiert. Wenn Sie EKS mit Knoten in der Cloud ausführen, wird diese Zonenbezeichnung automatisch vom AWS Cloud-Controller-Manager angewendet. Ein Cloud-Controller-Manager wird jedoch nicht mit 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 ist unten dargestellt. Die Konfiguration wird übergeben, wenn Sie Ihre Hybridknoten mit der Hybridknoten-CLI (nodeadm) mit Ihrem Cluster verbinden. Weitere Informationen zum topology.kubernetes.io/zone Label finden Sie in der Kubernetes-Dokumentation. Weitere Informationen zur Hybrid Nodes CLI finden Sie in der Nodeadm-Referenz für Hybridknoten.

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 Hybridkonnektivitä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 Überwachung von AWS Direct Connect-Ressourcen und Überwachen einer Site-to-Site AWS-VPN-Verbindung.

Es wird empfohlen, Alarme für NodeNotReady Ereignisse zu erstellen, die vom Node-Lifecycle-Controller gemeldet werden, der auf der EKS-Steuerungsebene läuft und die darauf hinweisen, dass es bei einem Hybridknoten möglicherweise zu einer Netzwerkunterbrechung kommt. Sie können diesen Alarm auslösen, indem Sie die EKS-Protokollierung auf Steuerungsebene für den Controller Manager aktivieren und einen Metrikfilter für die Meldung „Aufzeichnung einer Statusänderungsereignismeldung CloudWatch für den Knoten“ mit dem Status= „“ erstellen. NodeNotReady Nachdem Sie einen Metrikfilter erstellt haben, können Sie basierend auf Ihren gewünschten Schwellenwerten einen Alarm für diesen Filter erstellen. Weitere Informationen finden Sie in der Dokumentation unter Alarme für Protokolle. 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 Metriken 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.

Sie können CloudWatch Network Monitor auch verwenden, um einen tieferen Einblick in Ihre Hybridverbindungen zu erhalten, um die durchschnittliche Zeit bis zur Wiederherstellung zu verkürzen und festzustellen, ob Netzwerkprobleme ihren Ursprung in AWS oder Ihrer Umgebung haben. CloudWatch Network Monitor kann verwendet werden, um den Paketverlust und die 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 https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html verwenden.

EKS bietet mehrere Optionen zur Überwachung des Zustands Ihrer Cluster und Anwendungen. Für den Cluster-Zustand 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 Cluster-Leistung und Anzeigen von Protokollen.

Lokale Problembehandlung

Zur Vorbereitung auf Netzwerkunterbrechungen zwischen Hybridknoten und der EKS-Steuerungsebene können Sie sekundäre Überwachungs- und Protokollierungs-Backends einrichten, um die Beobachtbarkeit von Anwendungen aufrechtzuerhalten, wenn regionale AWS-Services nicht erreichbar sind. Beispielsweise können Sie den AWS Distro for Open Telemetry (ADOT) -Collector so konfigurieren, dass er Metriken und Protokolle an mehrere Back-Ends sendet. Sie können auch lokale Tools wie die crictl CLI verwenden, um lokal mit Pods und Containern als Ersatz für kubectl oder andere API-compatible Kubernetes-Clients zu interagieren, die normalerweise den Kubernetes-API-Serverendpunkt abfragen. Weitere Informationen dazu finden Sie in der crictl crictl Dokumentation in den Cri-Tools. GitHub Einige nützliche crictl Befehle sind unten aufgeführt.

Listet die Pods auf, die auf dem Host ausgeführt werden:

crictl pods

Listet Container auf, die auf dem Host laufen:

crictl ps

Listet Bilder auf, die auf dem Host laufen:

crictl images

Ruft die Protokolle eines Containers ab, der auf dem Host läuft:

crictl logs CONTAINER_NAME

Holen Sie sich Statistiken der 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 Anwendungsdatenverkehrs und die Technologien, mit denen Sie Ihre Anwendungen extern für Ihren Cluster verfügbar machen, zu berücksichtigen und zu verstehen. Verschiedene Technologien für den Anwendungslastenausgleich und den eingehenden Zugriff verhalten sich bei Netzwerkunterbrechungen unterschiedlich. Wenn Sie beispielsweise die BGP Control Plane-Funktion von Cilium für den Anwendungslastenausgleich verwenden, ist die BGP-Sitzung für Ihre Pods und Dienste möglicherweise während der Netzwerkunterbrechung ausgefallen. Dies liegt daran, dass die BGP-Lautsprecherfunktion in den Cilium-Agenten integriert ist und der Cilium-Agent kontinuierlich neu gestartet wird, wenn er von der Kubernetes-Steuerungsebene getrennt wird. Der Grund für den Neustart ist, dass der Health Check von Cilium fehlgeschlagen ist, da sein Zustand mit dem Zugriff auf die Kubernetes-Steuerungsebene verbunden ist (siehe CFP: #31702 mit einer Opt-In-Verbesserung in Cilium v1.17). Wenn Sie Application Load Balancers (ALB) oder Network Load Balancers (NLB) für den Region-originated AWS-Anwendungsdatenverkehr verwenden, könnte 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 GitHub Repo aws- samples/eks -hybrid-examples verwendet MetalLB für den Lastausgleich im L2-Modus, der auch bei Netzwerkunterbrechungen zwischen Hybridknoten und der EKS-Steuerungsebene stabil bleibt.

Überprüfen Sie die Abhängigkeiten von AWS-Remotediensten

Wenn Sie Hybridknoten verwenden, sollten Sie sich der Abhängigkeiten bewusst sein, die Sie von regionalen AWS-Services außerhalb Ihrer lokalen oder Edge-Umgebung eingehen. 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 Balancers für den Region-originated Datenverkehr und das Abrufen von Containern aus Amazon Elastic Container Registry. Auf diese Dienste kann nicht zugegriffen werden, wenn die Netzwerkverbindung zwischen Ihrer lokalen Umgebung und AWS unterbrochen wird. 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 einer Verbindung zu diesen Diensten die statische Stabilität Ihrer Anwendungen nicht beeinträchtigt.

Optimieren Sie das Kubernetes-Pod-Failover-Verhalten

Es gibt Optionen zur Optimierung des Pod-Failover-Verhaltens bei Netzwerkunterbrechungen für Anwendungen, die nicht auf mehrere Hosts übertragbar sind, oder für Umgebungen mit beschrä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 Knotens auf einen anderen Host ausweichen können.

Im Folgenden finden Sie ein Beispiel für die Konfiguration einer Bereitstellung tolerationSeconds für den nicht erreichbaren Fehler. Im Beispiel tolerationSeconds ist es 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