View a markdown version of this page

Operazioni del gateway Amazon EKS Hybrid Nodes - Amazon EKS
Disponibilità e failover elevatiGestione delle tabelle di routing in VPCMonitoraggioConsiderazioni sul dimensionamentoCiclo di vita del tunnel VXLANFasi successive

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Operazioni del gateway Amazon EKS Hybrid Nodes

Questa pagina descrive le operazioni del secondo giorno per il gateway Amazon EKS Hybrid Nodes, tra cui alta disponibilità, comportamento di failover, monitoraggio, scalabilità e ciclo di vita del tunnel VXLAN. Per le istruzioni di installazione, consulta Inizia a usare il gateway EKS Hybrid Nodes.

Disponibilità e failover elevati

Il gateway Hybrid Nodes utilizza un modello di standby attivo con l'elezione del leader di Kubernetes. Lease-based Due gateway pod funzionano su nodi EC2 separati, rafforzati dall'antiaffinità dei pod. Entrambi i pod creano un'interfaccia VXLAN all'avvio ed eseguono un riconciliatore di nodi che mantiene le voci VTEP per tutti i nodi ibridi. Solo il leader pod gestisce le tabelle di routing VPC e il CiliumVTEPConfig CRD. Il pod di standby è sempre pronto a inoltrare il traffico entro 3-5 secondi in caso di failover perché dispone già di un set completo di ingressi al tunnel.

Sequenza di failover

Quando l'istanza del gateway attivo fallisce, si verifica la seguente sequenza:

  1. Il pod di standby rileva che il lease leader è scaduto.

  2. Lo standby pod acquisisce il contratto di locazione e diventa il nuovo leader.

  3. Il nuovo leader esegue la sequenza di configurazione del leader:

    • Aggiorna le voci della tabella di routing VPC per indirizzare i pod CIDR ibridi verso l'ENI principale del nuovo leader.

    • Inverte la risorsa CiliumVTEPConfig personalizzata con l'IP del nuovo nodo leader e l'indirizzo MAC VXLAN.

  4. Il traffico riprende a fluire attraverso il nuovo leader.

Poiché entrambi i pod mantengono sempre le interfacce VXLAN e le voci VTEP, il nuovo leader non deve ricreare l'interfaccia VXLAN o riprogrammare le voci del tunnel durante il failover. Sono necessari solo la tabella di routing VPC e CiliumVTEPConfig gli aggiornamenti.

Il tempo di failover previsto è di circa 3-5 secondi. Durante il failover, il traffico tra il VPC e i pod ibridi viene interrotto.

Indicazione sulla zona di disponibilità

Distribuisci i nodi gateway su due zone di disponibilità in modo che un guasto della zona di disponibilità non comprometta sia il leader che lo standby. Quando usi la modalità automatica EKS, configurala NodeClass con selettori di sottorete su più AZ. Per gruppi di nodi gestiti o nodi autogestiti, scegli nodi in diverse AZ al momento di etichettarli.

Nota

Cross-AZ il traffico tra il gateway e altre risorse nel VPC comporta costi di trasferimento dati AWS Cross-AZ standard.

Parametri elettorali dei leader

I parametri predefiniti per l'elezione dei leader sono ottimizzati per un failover rapido:

Parametro Predefinita Description

--leader-election-lease-duration

3s

Quanto tempo attende un non leader prima di tentare di acquisire il contratto di locazione dopo che il leader ha interrotto il rinnovo.

--leader-election-renew-deadline

2s

Per quanto tempo il leader cerca di rinnovare il contratto di locazione prima di rinunciare.

--leader-election-retry-period

1s

Con quale frequenza i candidati tentano di riacquistare il contratto di locazione.

La riduzione di questi valori riduce i tempi di failover ma aumenta il rischio di falsi failover nelle partizioni di rete. Per la maggior parte delle distribuzioni, le impostazioni predefinite sono appropriate. Per ulteriori informazioni, consulta Riferimento alla configurazione del gateway Amazon EKS Hybrid Nodes.

Gestione delle tabelle di routing in VPC

Il gateway gestisce le voci della tabella di routing VPC in modo che il traffico destinato ai pod CIDR ibridi raggiunga l'istanza del gateway attivo.

Come vengono gestiti i percorsi

Quando un gateway pod diventa il leader, crea o sostituisce le route in ogni tabella di routing VPC configurata. Ogni route imposta il CIDR di destinazione su un pod ibrido CIDR e l'obiettivo sull'ENI principale del leader. Se una rotta esiste già e punta all'ENI corretto, il gateway salta l'aggiornamento.

Durante il failover, il nuovo leader sostituisce le rotte esistenti in modo che indirizzino al proprio ENI. Questo è il meccanismo che reindirizza il traffico VPC al nuovo gateway attivo.

Esempio di immissione nella tabella delle rotte

Dopo che il gateway ha configurato le route, la tabella di routing VPC contiene voci simili alle seguenti:

Destinazione Target Stato

10.0.0.0/16

local

attiva

HYBRID_POD_CIDR

eni-LEADER_ENI_ID

attiva

autorizzazioni IAM

Il gateway richiede le seguenti azioni IAM per gestire le tabelle di routing:

  • ec2:DescribeRouteTables

  • ec2:CreateRoute

  • ec2:ReplaceRoute

  • ec2:DescribeInstances

Associa queste autorizzazioni al ruolo IAM associato al profilo di istanza, all'identità del pod o alla configurazione IRSA dei nodi gateway.

Monitoraggio

Endpoint Health and Readiness

Il gateway espone gli endpoint di integrità e prontezza sulla porta: 8088

Endpoint Path Description

Controllo dell’integrità

/healthz

Restituisce HTTP 200 quando il processo del gateway è integro. Utilizzato dalla sonda Liveness di Kubernetes.

Controllo di prontezza

/readyz

Restituisce HTTP 200 quando il gateway è pronto a servire il traffico. Utilizzato dalla sonda di prontezza Kubernetes.

Puoi interrogare questi endpoint manualmente per la diagnostica eseguendo un contenitore di debug temporaneo o tramite il port forwarding:

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

Endpoint di metriche

Il gateway espone le Prometheus-compatible metriche sulla porta 10080 lungo il percorso. /metrics Le seguenti metriche personalizzate sono disponibili in aggiunta alle metriche standard di controller-runtime.

Informazioni sul gateway:

Metrica Tipo Description

hybrid_gateway_info

Gauge

Informazioni statiche sull'istanza del gateway. Sempre 1. Etichette:node_ip,node_name,vxlan_interface,vpc_cidr,pod_cidr.

Nodi ibridi:

Metrica Tipo Description

hybrid_gateway_hybrid_nodes_configured

Gauge

Numero attuale di nodi ibridi con voci VTEP configurate.

Operazioni VTEP:

Metrica Tipo Description

hybrid_gateway_vtep_add_total

Contatore

Operazioni di aggiunta VTEP completate con successo.

hybrid_gateway_vtep_add_errors_total

Contatore

Totale delle operazioni di aggiunta VTEP non riuscite.

hybrid_gateway_vtep_remove_total

Contatore

Totale delle operazioni di rimozione VTEP riuscite.

hybrid_gateway_vtep_remove_errors_total

Contatore

Totale delle operazioni di rimozione VTEP non riuscite.

Elezione dei leader e tabelle dei percorsi:

Metrica Tipo Description

hybrid_gateway_leader_is_active

Gauge

1 se questo pod è il leader attivo, 0 se lo standby.

hybrid_gateway_leader_setup_duration_seconds

Istogramma

Durata delle operazioni di configurazione del leader (tabelle di routing+ ciliumVTEPConfig) in secondi.

hybrid_gateway_aws_route_table_update_total

Contatore

Operazioni di aggiornamento della tabella di routing completate con successo. AWS

hybrid_gateway_aws_route_table_update_errors_total

Contatore

Totale delle operazioni di aggiornamento della tabella delle AWS rotte non riuscite.

hybrid_gateway_aws_route_table_update_duration_seconds

Istogramma

Durata delle operazioni di aggiornamento della tabella delle AWS rotte in secondi.

Statistiche di rete (raccolte su richiesta per scrape):

Metrica Tipo Description

hybrid_gateway_vxlan_rx_bytes_total

Gauge

Byte totali ricevuti sull'interfaccia VXLAN.

hybrid_gateway_vxlan_tx_bytes_total

Gauge

Byte totali trasmessi sull'interfaccia VXLAN.

hybrid_gateway_vxlan_rx_packets_total

Gauge

Pacchetti totali ricevuti sull'interfaccia VXLAN.

hybrid_gateway_vxlan_tx_packets_total

Gauge

Pacchetti totali trasmessi sull'interfaccia VXLAN.

hybrid_gateway_vxlan_rx_dropped_total

Gauge

Pacchetti totali persi al momento della ricezione dall'interfaccia VXLAN.

hybrid_gateway_vxlan_tx_dropped_total

Gauge

Pacchetti totali persi durante la trasmissione dall'interfaccia VXLAN.

hybrid_gateway_vxlan_rx_errors_total

Gauge

Errori totali di ricezione sull'interfaccia VXLAN.

hybrid_gateway_vxlan_tx_errors_total

Gauge

Errori totali di trasmissione sull'interfaccia VXLAN.

hybrid_gateway_vxlan_interface_up

Gauge

1 se l'interfaccia VXLAN è attiva, 0 altrimenti.

hybrid_gateway_vxlan_fdb_entries

Gauge

Numero attuale di voci FDB sull'interfaccia VXLAN.

hybrid_gateway_vxlan_route_count

Gauge

Numero attuale di percorsi tramite l'interfaccia VXLAN.

hybrid_gateway_primary_nic_rx_bytes_total

Gauge

Byte totali ricevuti sull'interfaccia di rete principale.

hybrid_gateway_primary_nic_tx_bytes_total

Gauge

Byte totali trasmessi sull'interfaccia di rete principale.

hybrid_gateway_primary_nic_rx_packets_total

Gauge

Pacchetti totali ricevuti sull'interfaccia di rete principale.

hybrid_gateway_primary_nic_tx_packets_total

Gauge

Pacchetti totali trasmessi sull'interfaccia di rete principale.

hybrid_gateway_primary_nic_rx_dropped_total

Gauge

Pacchetti totali persi durante la ricezione dalla NIC principale.

hybrid_gateway_primary_nic_tx_dropped_total

Gauge

Pacchetti totali persi durante la trasmissione dalla NIC principale.

hybrid_gateway_primary_nic_rx_errors_total

Gauge

Errori totali di ricezione sulla NIC principale.

hybrid_gateway_primary_nic_tx_errors_total

Gauge

Errori totali di trasmissione sulla NIC principale.

hybrid_gateway_primary_nic_info

Gauge

Nome NIC primario. Sempre 1. Etichette:interface_name.

CloudWatch Componente aggiuntivo Observability

Puoi utilizzare il componente aggiuntivo Amazon CloudWatch Observability per raccogliere i parametri e i log del gateway. Configura il componente aggiuntivo per archiviare lo spazio dei nomi del gateway () sulla porta. eks-hybrid-nodes-gateway 10080 Per il formato di configurazione corretto, consultate la documentazione del componente aggiuntivo collegata sopra.

Considerazioni sul dimensionamento

Il gateway Hybrid Nodes utilizza un modello di standby attivo con elezione del leader, quindi solo un pod gestisce il traffico alla volta. La scalabilità orizzontale del gateway (aumentando il numero di repliche) può migliorare la disponibilità fornendo pod di standby aggiuntivi pronti per essere sostituiti durante il failover, ma non migliora le prestazioni o il throughput perché il traffico non è distribuito tra le repliche. Per scalare le prestazioni, esegui la scalabilità verticale scegliendo un tipo di istanza EC2 con una larghezza di banda di rete sufficiente per il volume di traffico.

Guida al tipo di istanza

La velocità effettiva del gateway è limitata dalle prestazioni della rete delle istanze EC2. Quando selezioni un tipo di istanza, considera quanto segue:

  • Larghezza di banda di rete: il gateway inoltra tutto il traffico tra il VPC e i pod ibridi. Scegli un tipo di istanza la cui larghezza di banda di rete soddisfi i requisiti di traffico di picco.

  • Pacchetti al secondo (PPS): l'incapsulamento VXLAN aggiunge un sovraccarico per pacchetto. I carichi di lavoro con molti pacchetti di piccole dimensioni (ad esempio, microservizi con tassi di richiesta elevati) traggono vantaggio dai tipi di istanze con limiti PPS più elevati.

  • Numero di nodi ibridi: ogni nodo ibrido aggiunge un endpoint del tunnel VXLAN attraverso il quale il gateway inoltra il traffico. Man mano che il numero di nodi ibridi aumenta, il traffico aggregato attraverso il gateway aumenta. Seleziona un tipo di istanza con una larghezza di banda di rete sufficiente per gestire i picchi di traffico interrete del cluster.

Tipi di istanze consigliati

Produzione (10—100 nodi ibridi, traffico moderato)

Adatto per carichi di lavoro di produzione standard con traffico interrete costante.

Tipo di istanza vCPUs Memoria Rete Note

c6i.xlarge

4

8 GiB

Fino a 12,5 Gb/s

Buon equilibrio tra costi e prestazioni

c6in.xlarge

4

8 GiB

Fino a 30 Gbps

Network-optimized; consigliato per la produzione

c7i.xlarge

4

8 GiB

Fino a 12,5 Gb/s

Ottimizzato per il calcolo di ultima generazione

m6i.xlarge

4

16 GiB

Fino a 12,5 Gb/s

Adatto per la co-localizzazione di altri carichi di lavoro su nodi gateway

High-throughput produzione (oltre 100 nodi ibridi, traffico intenso)

Per ambienti con requisiti significativi di larghezza di banda interrete, come carichi di lavoro a uso intensivo di dati o molte connessioni simultanee.

Tipo di istanza vCPUs Memoria Rete Note

c6in.2xlarge

8

16 GiB

Fino a 40 Gbps

Consigliato per produzioni ad alto rendimento

c5n.2xlarge

8

21 GiB

Fino a 25 Gb/s

Previous-generation ottimizzato per la rete, conveniente

c6in.4xlarge

16

32 GiB

Fino a 50 Gb/s

Velocità di trasmissione massima per carichi di lavoro molto pesanti

c5n.4xlarge

16

42 GiB

Fino a 25 Gb/s

Elevato numero di vCPU per velocità di pacchetto estreme

Monitora l'utilizzo della rete utilizzando le metriche del gateway (vediEndpoint di metriche) e regola il tipo di istanza in base alle esigenze.

Ciclo di vita del tunnel VXLAN

Il gateway gestisce automaticamente i tunnel VXLAN verso i nodi ibridi quando entrano o escono dal cluster.

Come vengono gestiti i tunnel

Un controller di nodi controlla CiliumNode gli oggetti nel cluster. Il controller funziona su ogni gateway pod (non solo su quello leader) in modo che sia il leader che lo standby abbiano lo stato del tunnel aggiornato. Quando si verifica un CiliumNode evento, il controller verifica se il nodo è un nodo ibrido cercando l'eks.amazonaws.com/compute-type: hybridetichetta.

Quando un nodo ibrido si unisce al cluster:

  1. Il controller rileva il nuovo CiliumNode oggetto.

  2. Estrae l'indirizzo IP interno del nodo e il pod CIDR dalle specifiche. CiliumNode

  3. Programma quanto segue sull'interfaccia VXLAN:

    • Un percorso per il pod CIDR del nodo tramite l'IP del nodo tramite l'interfaccia VXLAN.

    • Una voce ARP statica che mappa l'IP del nodo su un indirizzo MAC deterministico.

    • Una voce FDB che indica al modulo VXLAN di inviare pacchetti incapsulati all'IP del nodo.

Quando un nodo ibrido lascia il cluster:

  1. Il controller rileva l'CiliumNodeeliminazione.

  2. Rimuove il percorso, la voce ARP e la voce FDB per quel nodo dall'interfaccia VXLAN.

Questo ciclo di vita è completamente automatico. Non è necessario configurare manualmente i tunnel quando si aggiungono o si rimuovono nodi ibridi.

Fasi successive