View a markdown version of this page

Gateway-Betrieb von Amazon EKS Hybrid Nodes - Amazon EKS
Hohe Verfügbarkeit und FailoverVerwaltung VPC VPC-RoutentabellenÜberwachenÜberlegungen zur SkalierungLebenszyklus des VXLAN-TunnelsNächste Schritte

Unterstützung für die Verbesserung dieser Seite beitragen

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.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

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.

Gateway-Betrieb von Amazon EKS Hybrid Nodes

Diese Seite behandelt die Abläufe am zweiten Tag für das Amazon EKS Hybrid Nodes Gateway, einschließlich Hochverfügbarkeit, Failover-Verhalten, Überwachung, Skalierung und VXLAN-Tunnellebenszyklus. Installationsanweisungen finden Sie unter Erste Schritte mit dem EKS Hybrid Nodes Gateway.

Hohe Verfügbarkeit und Failover

Das Hybrid Nodes Gateway verwendet ein Active-Standby-Modell, bei dem Lease-based Kubernetes zum Marktführer gewählt wird. Zwei Gateway-Pods werden auf separaten EC2-Knoten ausgeführt, was durch Pod-Anti-Affinität erzwungen wird. Beide Pods erstellen beim Start eine VXLAN-Schnittstelle und führen einen Node Reconciler aus, der VTEP-Einträge für alle Hybridknoten verwaltet. Nur der Leader-Pod verwaltet die VPC-Routing-Tabellen und die CiliumVTEPConfig CRD. Der Standby-Pod ist bei einem Failover immer bereit, den Datenverkehr innerhalb von 3—5 Sekunden weiterzuleiten, da er bereits über einen vollständigen Satz von Tunneleinträgen verfügt.

Failover-Sequenz

Wenn die aktive Gateway-Instanz ausfällt, tritt die folgende Sequenz auf:

  1. Der Standby-Pod erkennt, dass das Leader-Lease abgelaufen ist.

  2. Der Standby-Pod erwirbt den Leasingvertrag und wird zum neuen Leader.

  3. Der neue Leader führt die Leader-Einrichtungssequenz aus:

    • Aktualisiert die Einträge in der VPC-Routentabelle, sodass Hybrid-Pod-CIDRs auf die primäre ENI des neuen Marktführers verweisen.

    • CiliumVTEPConfigÄndert die benutzerdefinierte Ressource mit der Knoten-IP und der VXLAN-MAC-Adresse des neuen Leaders.

  4. Der Datenverkehr fließt wieder über den neuen Leader.

Da beide Pods jederzeit VXLAN-Schnittstellen und VTEP-Einträge beibehalten, muss der neue Leader während des Failovers weder die VXLAN-Schnittstelle neu erstellen noch Tunneleinträge neu programmieren. Nur die VPC-Routentabelle und CiliumVTEPConfig Updates sind erforderlich.

Die erwartete Failover-Zeit beträgt etwa 3—5 Sekunden. Während des Failovers wird der Verkehr zwischen der VPC und den Hybrid-Pods unterbrochen.

Empfehlung für die Availability Zone

Verteilen Sie die Gateway-Knoten auf zwei Availability Zones, sodass bei einem AZ-Ausfall nicht sowohl der Leader als auch der Standby ausgeschaltet werden. Wenn Sie den automatischen EKS-Modus verwenden, konfigurieren Sie Ihre NodeClass mit Subnetz-Selektoren für mehrere AZs. Wählen Sie für verwaltete Knotengruppen oder selbstverwaltete Knoten bei der Kennzeichnung Knoten in verschiedenen AZs aus.

Anmerkung

Cross-AZ Für den Verkehr zwischen dem Gateway und anderen Ressourcen in der VPC fallen standardmäßige AWS AZ-übergreifende Datenübertragungsgebühren an.

Parameter für die Wahl eines Führers

Die Standardparameter für die Wahl von Führungskräften sind auf ein schnelles Failover ausgelegt:

Parameter Standard Description

--leader-election-lease-duration

3s

Wie lange ein Nicht-Leader wartet, bevor er versucht, den Mietvertrag zu erwerben, nachdem der Leader die Verlängerung beendet hat.

--leader-election-renew-deadline

2s

Wie lange der Leader versucht, den Mietvertrag zu verlängern, bevor er aufgibt.

--leader-election-retry-period

1s

Wie oft versuchen Kandidaten erneut, den Mietvertrag zu erwerben.

Eine Senkung dieser Werte reduziert die Failover-Zeit, erhöht jedoch das Risiko falscher Failovers unter Netzwerkpartitionen. Für die meisten Bereitstellungen sind die Standardwerte angemessen. Weitere Informationen finden Sie unter Referenz zur Konfiguration des Amazon EKS Hybrid Nodes Gateways.

Verwaltung VPC VPC-Routentabellen

Das Gateway verwaltet die Einträge in der VPC-Routentabelle, sodass der für Hybrid-Pod-CIDRs bestimmte Datenverkehr die aktive Gateway-Instanz erreicht.

Wie werden Routen verwaltet

Wenn ein Gateway-Pod zum Leader wird, erstellt oder ersetzt er Routen in jeder konfigurierten VPC-Routentabelle. Bei jeder Route wird als Ziel-CIDR ein Hybrid-Pod-CIDR und als Ziel die primäre ENI des Leaders festgelegt. Wenn bereits eine Route vorhanden ist und auf die richtige ENI verweist, überspringt das Gateway die Aktualisierung.

Beim Failover ersetzt der neue Leader die vorhandenen Routen, sodass sie auf sein eigenes ENI verweisen. Dies ist der Mechanismus, der den VPC-Verkehr an das neue aktive Gateway umleitet.

Beispiel für einen Eintrag in eine Routentabelle

Nachdem das Gateway Routen konfiguriert hat, enthält Ihre VPC-Routentabelle Einträge, die den folgenden ähneln:

Bestimmungsort Target Status

10.0.0.0/16

local

aktiv

HYBRID_POD_CIDR

eni-LEADER_ENI_ID

aktiv

IAM-Berechtigungen

Das Gateway benötigt die folgenden IAM-Aktionen, um Routentabellen zu verwalten:

  • ec2:DescribeRouteTables

  • ec2:CreateRoute

  • ec2:ReplaceRoute

  • ec2:DescribeInstances

Ordnen Sie diese Berechtigungen der IAM-Rolle zu, die dem Instanzprofil, der Pod-Identität oder der IRSA-Konfiguration der Gateway-Knoten zugeordnet ist.

Überwachen

Endpunkte für Health und Einsatzbereitschaft

Das Gateway macht Integritäts- und Bereitschaftsendpunkte am Port verfügbar: 8088

Endpoint Pfad Description

Gesundheitscheck

/healthz

Gibt HTTP 200 zurück, wenn der Gateway-Prozess fehlerfrei ist. Wird von der Kubernetes Liveness Probe verwendet.

Prüfung der Bereitschaft

/readyz

Gibt HTTP 200 zurück, wenn das Gateway bereit ist, Datenverkehr zu verarbeiten. Wird von der Kubernetes Readiness Probe verwendet.

Sie können diese Endpunkte manuell zur Diagnose abfragen, indem Sie einen temporären Debug-Container ausführen oder eine Portweiterleitung durchführen:

kubectl port-forward -n eks-hybrid-nodes-gateway POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz
curl -s http://localhost:8088/readyz

Endpunkt der Messwerte

Das Gateway stellt Prometheus-compatible Metriken auf dem Port 10080 am /metrics Pfad zur Verfügung. Die folgenden benutzerdefinierten Metriken sind zusätzlich zu den standardmäßigen Controller-Runtime-Metriken verfügbar.

Gateway-Informationen:

Metrik Typ Description

hybrid_gateway_info

Messinstrument

Statische Informationen über die Gateway-Instanz. Immer 1. Etiketten: node_ipnode_name,vxlan_interface,vpc_cidr,pod_cidr.

Hybridknoten:

Metrik Typ Description

hybrid_gateway_hybrid_nodes_configured

Messinstrument

Aktuelle Anzahl von Hybridknoten mit konfigurierten VTEP-Einträgen.

VTEP-Operationen:

Metrik Typ Description

hybrid_gateway_vtep_add_total

Zähler

Gesamtzahl erfolgreicher VTEP-Hinzufügevorgänge.

hybrid_gateway_vtep_add_errors_total

Zähler

Gesamtzahl der fehlgeschlagenen VTEP-Hinzufügevorgänge.

hybrid_gateway_vtep_remove_total

Zähler

Gesamtzahl der erfolgreichen VTEP-Entfernungsvorgänge.

hybrid_gateway_vtep_remove_errors_total

Zähler

Gesamtzahl der fehlgeschlagenen VTEP-Entfernungsvorgänge.

Tabelle zur Wahl von Führungskräften und zur Routenplanung:

Metrik Typ Description

hybrid_gateway_leader_is_active

Messinstrument

1, wenn dieser Pod der aktive Leader ist, 0, wenn er im Standby-Modus ist.

hybrid_gateway_leader_setup_duration_seconds

Histogramm

Dauer der Leader-Setup-Operationen (Routentabellen + CiliumVTEPConfig) in Sekunden.

hybrid_gateway_aws_route_table_update_total

Zähler

Gesamtzahl der erfolgreichen AWS Aktualisierungsvorgänge für Routing-Tabellen.

hybrid_gateway_aws_route_table_update_errors_total

Zähler

Gesamtzahl der fehlgeschlagenen AWS Routentabellen-Aktualisierungsvorgänge.

hybrid_gateway_aws_route_table_update_duration_seconds

Histogramm

Dauer der AWS Routentabellen-Aktualisierungsvorgänge in Sekunden.

Netzwerkstatistiken (bei Bedarf pro Scrape gesammelt):

Metrik Typ Description

hybrid_gateway_vxlan_rx_bytes_total

Messinstrument

Gesamtzahl der auf der VXLAN-Schnittstelle empfangenen Bytes.

hybrid_gateway_vxlan_tx_bytes_total

Messinstrument

Gesamtzahl der auf der VXLAN-Schnittstelle übertragenen Bytes.

hybrid_gateway_vxlan_rx_packets_total

Messinstrument

Gesamtzahl der auf der VXLAN-Schnittstelle empfangenen Pakete.

hybrid_gateway_vxlan_tx_packets_total

Messinstrument

Gesamtzahl der über die VXLAN-Schnittstelle übertragenen Pakete.

hybrid_gateway_vxlan_rx_dropped_total

Messinstrument

Gesamtzahl der Pakete, die beim Empfang durch die VXLAN-Schnittstelle verworfen wurden.

hybrid_gateway_vxlan_tx_dropped_total

Messinstrument

Gesamtzahl der Pakete, die bei der Übertragung durch die VXLAN-Schnittstelle verworfen wurden.

hybrid_gateway_vxlan_rx_errors_total

Messinstrument

Gesamtzahl der Empfangsfehler auf der VXLAN-Schnittstelle.

hybrid_gateway_vxlan_tx_errors_total

Messinstrument

Gesamtzahl der Übertragungsfehler auf der VXLAN-Schnittstelle.

hybrid_gateway_vxlan_interface_up

Messinstrument

1, wenn die VXLAN-Schnittstelle UP ist, andernfalls 0.

hybrid_gateway_vxlan_fdb_entries

Messinstrument

Aktuelle Anzahl von FDB-Einträgen auf der VXLAN-Schnittstelle.

hybrid_gateway_vxlan_route_count

Messinstrument

Aktuelle Anzahl von Routen über die VXLAN-Schnittstelle.

hybrid_gateway_primary_nic_rx_bytes_total

Messinstrument

Gesamtzahl der auf der primären Netzwerkschnittstelle empfangenen Bytes.

hybrid_gateway_primary_nic_tx_bytes_total

Messinstrument

Gesamtzahl der auf der primären Netzwerkschnittstelle übertragenen Byte.

hybrid_gateway_primary_nic_rx_packets_total

Messinstrument

Gesamtzahl der auf der primären Netzwerkschnittstelle empfangenen Pakete.

hybrid_gateway_primary_nic_tx_packets_total

Messinstrument

Gesamtzahl der über die primäre Netzwerkschnittstelle übertragenen Pakete.

hybrid_gateway_primary_nic_rx_dropped_total

Messinstrument

Gesamtzahl der Pakete, die beim Empfang durch die primäre Netzwerkkarte verworfen wurden.

hybrid_gateway_primary_nic_tx_dropped_total

Messinstrument

Gesamtzahl der Pakete, die bei der Übertragung durch die primäre Netzwerkkarte verworfen wurden.

hybrid_gateway_primary_nic_rx_errors_total

Messinstrument

Gesamtzahl der Empfangsfehler auf der primären Netzwerkkarte.

hybrid_gateway_primary_nic_tx_errors_total

Messinstrument

Gesamtzahl der Übertragungsfehler auf der primären Netzwerkkarte.

hybrid_gateway_primary_nic_info

Messinstrument

Primärer NIC-Name. Immer 1. Etiketten:interface_name.

CloudWatch Add-on „Beobachtbarkeit“

Sie können das Amazon CloudWatch Observability-Add-on verwenden, um Gateway-Metriken und -Protokolle zu sammeln. Konfigurieren Sie das Add-on so, dass es den Gateway-Namespace (eks-hybrid-nodes-gateway) auf dem Port scrapt. 10080 Das richtige Konfigurationsformat finden Sie in der oben verlinkten Add-On-Dokumentation.

Überlegungen zur Skalierung

Das Hybrid Nodes Gateway verwendet ein Active-Standby-Modell mit Wahl des Leiters, sodass nur ein Pod den Datenverkehr zu einem bestimmten Zeitpunkt abwickelt. Die horizontale Skalierung des Gateways (durch Erhöhung der Anzahl der Replikate) kann die Verfügbarkeit verbessern, indem zusätzliche Standby-Pods bereitgestellt werden, die während eines Failovers zur Verfügung stehen. Dies verbessert jedoch weder die Leistung noch den Durchsatz, da der Datenverkehr nicht auf die Replikate verteilt wird. Um die Leistung zu skalieren, skalieren Sie vertikal, indem Sie einen EC2-Instance-Typ mit ausreichender Netzwerkbandbreite für Ihr Datenverkehrsvolumen wählen.

Hinweise zum Instance-Typ

Der Gateway-Durchsatz wird durch die Netzwerkleistung der EC2-Instance begrenzt. Beachten Sie bei der Auswahl eines Instance-Typs Folgendes:

  • Netzwerkbandbreite — Das Gateway leitet den gesamten Datenverkehr zwischen der VPC und den Hybrid-Pods weiter. Wählen Sie einen Instance-Typ, dessen Netzwerkbandbreite Ihren Anforderungen an den Spitzenverkehr entspricht.

  • Pakete pro Sekunde (PPS) — Die VXLAN-Kapselung erhöht den Overhead pro Paket. Workloads mit vielen kleinen Paketen (z. B. Microservices mit hohen Anforderungsraten) profitieren von Instance-Typen mit höheren PPS-Grenzwerten.

  • Anzahl der Hybridknoten — Jeder Hybridknoten fügt einen VXLAN-Tunnelendpunkt hinzu, über den das Gateway den Datenverkehr weiterleitet. Mit zunehmender Anzahl der Hybridknoten wächst der Gesamtdatenverkehr über das Gateway. Wählen Sie einen Instance-Typ mit ausreichender Netzwerkbandbreite aus, um den netzwerkübergreifenden Spitzenverkehr Ihres Clusters zu bewältigen.

Empfohlene Instance-Typen

Produktion (10—100 Hybridknoten, mäßiger Verkehr)

Geeignet für Standard-Produktionsworkloads mit stetigem netzwerkübergreifendem Datenverkehr.

Instance-Typ vCPUs Arbeitsspeicher Netzwerk Hinweise

c6i.xlarge

4

8 GiB

Bis zu 12,5 GBit/s

Gute Balance zwischen Kosten und Leistung

c6in.xlarge

4

8 GiB

Bis zu 30 Gbit/s

Network-optimized; für die Produktion empfohlen

c7i.xlarge

4

8 GiB

Bis zu 12,5 GBit/s

Computeroptimiert der neuesten Generation

m6i.xlarge

4

16 GiB

Bis zu 12,5 GBit/s

Geeignet für die gemeinsame Nutzung anderer Workloads auf Gateway-Knoten

High-throughput Produktion (mehr als 100 Hybridknoten, starker Verkehr)

Für Umgebungen mit erheblichen netzwerkübergreifenden Bandbreitenanforderungen, wie z. B. datenintensive Workloads oder viele gleichzeitige Verbindungen.

Instance-Typ vCPUs Arbeitsspeicher Netzwerk Hinweise

c6in.2xlarge

8

16 GiB

Bis zu 40 Gbit/s

Empfohlen für die Produktion mit hohem Durchsatz

c5n.2xlarge

8

21 GiB

Bis zu 25 Gbit/s

Previous-generation netzwerkoptimiert, kostengünstig

c6in.4xlarge

16

32 GiB

Bis zu 50 GBit/s

Maximaler Durchsatz für sehr schwere Workloads

c5n.4xlarge

16

42 GiB

Bis zu 25 Gbit/s

Hohe vCPU-Anzahl für extreme Paketraten

Überwachen Sie die Netzwerkauslastung anhand der Gateway-Metriken (sieheEndpunkt der Messwerte) und passen Sie den Instanztyp nach Bedarf an.

Lebenszyklus des VXLAN-Tunnels

Das Gateway verwaltet automatisch VXLAN-Tunnel zu Hybridknoten, wenn diese dem Cluster beitreten oder ihn verlassen.

Wie werden Tunnel verwaltet

Ein Node-Controller überwacht CiliumNode Objekte im Cluster. Der Controller läuft auf jedem Gateway-Pod (nicht nur auf dem Leader), sodass sowohl der Leader als auch der Standby-Pod über einen aktuellen Tunnelstatus verfügen. Wenn ein CiliumNode Ereignis eintritt, prüft der Controller anhand des eks.amazonaws.com/compute-type: hybrid Labels, ob es sich bei dem Knoten um einen Hybridknoten handelt.

Wenn ein Hybridknoten dem Cluster beitritt:

  1. Der Controller erkennt das neue CiliumNode Objekt.

  2. Er extrahiert die interne IP-Adresse und das Pod-CIDR des Knotens aus der CiliumNode Spezifikation.

  3. Es programmiert Folgendes auf der VXLAN-Schnittstelle:

    • Eine Route für den Pod-CIDR des Knotens über die IP des Knotens über die VXLAN-Schnittstelle.

    • Ein statischer ARP-Eintrag, der die IP des Knotens einer deterministischen MAC-Adresse zuordnet.

    • Ein FDB-Eintrag, der das VXLAN-Modul anweist, gekapselte Pakete an die IP-Adresse des Knotens zu senden.

Wenn ein Hybridknoten den Cluster verlässt:

  1. Der Controller erkennt das CiliumNode Löschen.

  2. Es entfernt die Route, den ARP-Eintrag und den FDB-Eintrag für diesen Knoten aus der VXLAN-Schnittstelle.

Dieser Lebenszyklus ist vollautomatisch. Sie müssen Tunnel nicht manuell konfigurieren, wenn Sie Hybridknoten hinzufügen oder entfernen.

Nächste Schritte