View a markdown version of this page

Referenz zur Konfiguration des Amazon EKS Hybrid Nodes Gateways - Amazon EKS
Werte des Helm-DiagrammsKonfiguration im automatischen Modus im Vergleich zu verwalteten KnotengruppenAbstimmung der Wahl der SpitzenpolitikerVerwandte Themen

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.

Referenz zur Konfiguration des Amazon EKS Hybrid Nodes Gateways

Auf dieser Seite werden alle konfigurierbaren Parameter für das Amazon EKS Hybrid Nodes Gateway dokumentiert. Installationsanweisungen finden Sie unter Erste Schritte mit dem EKS Hybrid Nodes Gateway. Eine Übersicht über das Gateway finden Sie unterAmazon EKS-Gateway für Hybridknoten.

Werte des Helm-Diagramms

In der folgenden Tabelle sind alle Werte im eks-hybrid-nodes-gateway Helm-Diagramm aufgeführt. Sie können diese Werte mithilfe von --set Flags oder einer benutzerdefinierten values.yaml Datei während helm install oder festlegenhelm upgrade.

Wert Typ Standard Erforderlich Beschreibung

image.repository

Zeichenfolge

public.ecr.aws/eks/eks-hybrid-nodes-gateway

Nein

Container-Image-Repository für das Gateway-Image. Standardmäßig wird die öffentliche Amazon ECR-Registrierung verwendet.

image.tag

Zeichenfolge

Diagramm appVersion

Nein

Bild-Tag. Standardmäßig ist der in appVersion Chart.yaml definierte Wert.

image.pullPolicy

Zeichenfolge

IfNotPresent

Nein

Richtlinie zum Abrufen von Bildern. Zulässige Werte: Always, IfNotPresent, Never.

replicas

Ganzzahl

2

Nein

Anzahl der Gateway-Pod-Replikate. Zwei Replikate sind die empfohlene Konfiguration für hohe Verfügbarkeit in Produktionsumgebungen.

nodeLabel

Zeichenfolge

hybrid-gateway-node

Nein

Knotenbezeichnungsschlüssel, der zur Auswahl von Gateway-Knoten verwendet wird. Für Knoten muss dieses Label auf gesetzt sein"true".

vpcCIDR

Zeichenfolge

""

Ja

VPC CIDR-Block, der für die Cilium VTEP-Konfiguration verwendet wird. Beispiel: 10.0.0.0/16.

podCIDRs

Zeichenfolge

""

Ja

Comma-separated Liste der Pod-CIDRs, die von Cilium auf Hybridknoten verwendet werden. Beispiel: 10.85.0.0/16,10.86.0.0/16.

routeTableIDs

Zeichenfolge

""

Ja

Comma-separated Liste der VPC-Routentabellen-IDs, die mit Hybrid-Pod-Routen programmiert werden sollen. Beispiel: rtb-0123456789abcdef0,rtb-0123456789abcdef1.

autoMode.enabled

boolesch

true

Nein

Aktivieren Sie die Integration im automatischen EKS-Modus. Wenntrue, fügt das Diagramm eine eks.amazonaws.com/compute-type: auto Knotenauswahl hinzu und verwendet eine Strategie für fortlaufende Updates ohne Ausfallzeiten. Ist false für verwaltete Knotengruppen oder selbstverwaltete Knoten auf eingestellt.

Beispiele für Installationsbefehle

Automatischer EKS-Modus (Standard):

helm install eks-hybrid-nodes-gateway oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

Verwaltete Knotengruppen oder selbstverwaltete Knoten:

helm install eks-hybrid-nodes-gateway oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set autoMode.enabled=false \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

Konfiguration im automatischen Modus im Vergleich zu verwalteten Knotengruppen

Der autoMode.enabled Helm-Wert steuert zwei Verhaltensweisen in der Deployment-Vorlage:

Behavior autoMode.enabled=true (Standard) autoMode.enabled=false

Knoten-Selektor

Fügt eks.amazonaws.com/compute-type: auto zusätzlich zur Gateway-Knotenbezeichnung hinzu.

Verwendet nur die Gateway-Knotenbezeichnung (hybrid-gateway-node: "true").

Strategie für fortlaufende Updates

maxSurge: 1, maxUnavailable: 0 — sorgt dafür, dass bei Upgrades keine Ausfallzeiten auftreten, indem ein neuer Pod gestartet wird, bevor der alte beendet wird.

maxSurge: 0, maxUnavailable: 1 — beendet den alten Pod, bevor ein neuer gestartet wird, da die Knotenkapazität vorab bereitgestellt wird.

Wenn Sie den automatischen EKS-Modus verwenden, müssen Sie NodeClass vor der Installation des Helm-Diagramms ein NodePool und erstellen. Dadurch werden NodePool EC2-Instances mit den richtigen Labels, Taints und der korrekten source/destination Prüfkonfiguration ausgestattet. Informationen zum erforderlichen YAML finden Sie unter. Erste Schritte mit dem EKS Hybrid Nodes Gateway Wenn Sie verwaltete Knotengruppen oder selbstverwaltete Knoten verwenden, müssen Sie die Knoten selbst bereitstellen und kennzeichnen, bevor Sie das Diagramm installieren.

Für alle Bereitstellungsziele verwendet hostNetwork: true und benötigt das Deployment die NET_ADMIN Funktion. Pod-Anti-Affinität stellt sicher, dass die beiden Gateway-Pods auf getrennten Knoten ausgeführt werden.

Abstimmung der Wahl der Spitzenpolitiker

Das Gateway verwendet die Wahl des Lease-based Kubernetes-Leaders, um ein Active-Standby-Modell aufrechtzuerhalten. Die Standardparameter sind auf schnelles Failover abgestimmt:

Parameter Standard Description

--leader-election-lease-duration

3s

Wie lange ein nicht führendes Unternehmen nach der letzten beobachteten Verlängerung des Leasingvertrags wartet, bevor er versucht, den Leasingvertrag zu erwerben. Niedrigere Werte erkennen den Ausfall eines Leaders schneller, erhöhen aber das Risiko falscher Failovers bei vorübergehenden Netzwerkproblemen.

--leader-election-renew-deadline

2s

Maximale Zeit, die der aktive Leiter damit verbringt, den Mietvertrag zu verlängern, bevor er die Führung aufgibt. Muss kürzer als die Leasingdauer sein.

--leader-election-retry-period

1s

Wie oft versuchen Kandidaten erneut, den Leasingvertrag zu erwerben oder zu verlängern.

Mit den Standardwerten beträgt die erwartete Failover-Zeit beim Ausfall des aktiven Gateways etwa 3—5 Sekunden. Dies beinhaltet die Zeit, die der Standby benötigt, um den Ablauf des Leases zu erkennen, das Lease zu erwerben und die Leader-Setup-Sequenz auszuführen (VPC-Routing-Tabellenaktualisierungen und Cilium VTEP-Konfiguration).

Wann müssen die Parameter für die Wahl des Leiters angepasst werden

  • Erhöhen Sie die Leasingdauer, wenn Sie häufige Leader-Übergänge beobachten, die durch vorübergehende Netzwerklatenz zwischen Gateway-Pods und dem Kubernetes-API-Server verursacht werden.

  • Reduzieren Sie die Leasingdauer, wenn Sie eine schnellere Failover-Erkennung benötigen und Ihr Netzwerk zwischen den Gateway-Knoten und dem API-Server zuverlässig und latenzarm ist.

  • Erhöhen Sie die Wiederholungszeit, um die API-Serverlast aufgrund der Wahl eines Leaders in großen Clustern zu reduzieren.

Anmerkung

Der --leader-election-renew-deadline muss immer kleiner sein als--leader-election-lease-duration. Wenn die Frist für die Verlängerung die Mietdauer überschreitet, kann es sein, dass der Leader den Mietvertrag verliert, bevor er verlängert werden kann.