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à.
Riferimento alla configurazione del gateway Amazon EKS Hybrid Nodes
Questa pagina documenta tutti i parametri configurabili per il gateway Amazon EKS Hybrid Nodes. Per le istruzioni di installazione, consulta Inizia a usare il gateway EKS Hybrid Nodes. Per una panoramica del gateway, consultaGateway Amazon EKS Hybrid Nodes.
Valori del grafico Helm
La tabella seguente elenca tutti i valori del diagramma di eks-hybrid-nodes-gateway Helm. È possibile impostare questi valori utilizzando i --set flag o un values.yaml file personalizzato durante helm install o. helm upgrade
| Valore | Tipo | Predefinita | Campo obbligatorio | Descrizione |
|---|---|---|---|---|
|
|
stringa |
|
No |
Archivio di immagini del contenitore per l'immagine del gateway. L'impostazione predefinita è il registro pubblico di Amazon ECR. |
|
|
stringa |
Grafico |
No |
Tag immagine. Il valore predefinito è |
|
|
stringa |
|
No |
Politica di estrazione delle immagini. Valori validi: |
|
|
numero intero |
|
No |
Numero di repliche dei pod gateway. La configurazione consigliata è costituita da due repliche per l'elevata disponibilità negli ambienti di produzione. |
|
|
stringa |
|
No |
Chiave di etichetta del nodo utilizzata per selezionare i nodi gateway. I nodi devono avere questa etichetta impostata su |
|
|
stringa |
|
Sì |
Blocco VPC CIDR utilizzato per la configurazione VTEP di Cilium. Esempio: |
|
|
stringa |
|
Sì |
Comma-separated elenco dei pod CIDR utilizzati da Cilium sui nodi ibridi. Esempio: |
|
|
stringa |
|
Sì |
Comma-separated elenco di ID delle tabelle di routing VPC da programmare con percorsi pod ibridi. Esempio: |
|
|
booleano |
|
No |
Abilita l'integrazione con EKS Auto Mode. Quando |
Esempi di comandi di installazione
Modalità automatica EKS (impostazione predefinita):
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
Gruppi di nodi gestiti o nodi autogestiti:
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
Configurazione automatica o configurazione del gruppo di nodi gestito
Il valore autoMode.enabled Helm controlla due comportamenti nel modello Deployment:
| Comportamento | autoMode.enabled=true (predefinito) |
autoMode.enabled=false
|
|---|---|---|
|
Selettore di nodi |
Aggiunge |
Utilizza solo l'etichetta del nodo gateway ( |
|
Strategia di aggiornamento continuo |
|
|
Quando si utilizza la modalità automatica EKS, è necessario creare un NodePool e NodeClass prima di installare il grafico Helm. Fornisce NodePool alle istanze EC2 le etichette e i colori corretti e verifica la configurazione. source/destination Per lo YAML richiesto, consulta. Inizia a usare il gateway EKS Hybrid Nodes Quando si utilizzano gruppi di nodi gestiti o nodi autogestiti, è necessario effettuare personalmente il provisioning e l'etichettatura dei nodi prima di installare il grafico.
Per tutti gli obiettivi di distribuzione, Deployment utilizza hostNetwork: true e richiede la NET_ADMIN funzionalità. L'antiaffinità dei pod garantisce che i due gateway pod funzionino su nodi separati.
Ottimizzazione delle elezioni dei leader
Il gateway utilizza Kubernetes Lease-based Leader Election per mantenere un modello di standby attivo. I parametri predefiniti sono ottimizzati per un failover rapido:
| Parametro | Predefinita | Description |
|---|---|---|
|
|
|
Quanto tempo attende una persona non leader dopo l'ultimo rinnovo del contratto di locazione osservato prima di provare ad acquistare il contratto di locazione. I valori più bassi rilevano più rapidamente i guasti del leader, ma aumentano il rischio di falsi failover durante problemi transitori di rete. |
|
|
|
Tempo massimo che il leader attivo impiega a cercare di rinnovare il contratto di locazione prima di rinunciare alla leadership. Deve essere inferiore alla durata del contratto di locazione. |
|
|
|
Con quale frequenza i candidati tentano di riacquistare o rinnovare il contratto di locazione. |
Con i valori predefiniti, il tempo di failover previsto in caso di guasto del gateway attivo è di circa 3-5 secondi. Ciò include il tempo impiegato dallo standby per rilevare la scadenza del leasing, acquisire il lease ed eseguire la sequenza di configurazione leader (aggiornamenti della tabella di routing VPC e configurazione Cilium VTEP).
Quando modificare i parametri di elezione dei leader
-
Aumenta la durata del leasing se osservi frequenti transizioni tra i leader causate dalla latenza di rete transitoria tra i gateway pod e il server API Kubernetes.
-
Riduci la durata del leasing se hai bisogno di un rilevamento più rapido del failover e la rete tra i nodi gateway e il server API è affidabile e a bassa latenza.
-
Aumenta il periodo di riprova per ridurre il carico del server API derivante dall'elezione del leader in cluster di grandi dimensioni.
Nota
--leader-election-renew-deadlineDeve essere sempre inferiore a. --leader-election-lease-duration Se la scadenza per il rinnovo supera la durata del contratto di locazione, il leader può perdere il contratto di locazione prima che possa rinnovarlo.
Argomenti correlati
