Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Esecuzione di kube-proxy in modalità IPVS

Modalità Focus
Esecuzione di kube-proxy in modalità IPVS - Amazon EKS

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à.

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à.

EKS in modalità IP Virtual Server (IPVS) risolve il problema di latenza di rete spesso riscontrato durante l'esecuzione di cluster di grandi dimensioni con oltre 1.000 servizi con kube-proxy in esecuzione nella modalità iptables precedente. Questo problema di prestazioni è il risultato dell'elaborazione sequenziale delle regole di filtraggio dei pacchetti iptables per ogni pacchetto. Questo problema di latenza è stato risolto in nftables, il successore di iptables. Tuttavia, al momento della stesura di questo documento, kube-proxy è ancora in fase di sviluppo per utilizzare nftables. Per ovviare a questo problema, puoi configurare il cluster per l'esecuzione in modalità IPVS. kube-proxy

Panoramica

IPVS, che è GA dalla versione 1.11 di Kubernetes, utilizza tabelle hash anziché la ricerca lineare per elaborare i pacchetti, garantendo l'efficienza dei cluster con migliaia di nodi e servizi. IPVS è stato progettato per il bilanciamento del carico, il che lo rende una soluzione adatta per i problemi di prestazioni di rete di Kubernetes.

IPVS offre diverse opzioni per la distribuzione del traffico verso i pod di backend. Informazioni dettagliate per ciascuna opzione sono disponibili nella documentazione ufficiale di Kubernetes, ma di seguito è riportato un semplice elenco. Round Robin e Least Connections sono tra le scelte più popolari per le opzioni di bilanciamento del carico IPVS in Kubernetes.

- rr (Round Robin)
- wrr (Weighted Round Robin)
- lc (Least Connections)
- wlc (Weighted Least Connections)
- lblc (Locality Based Least Connections)
- lblcr (Locality Based Least Connections with Replication)
- sh (Source Hashing)
- dh (Destination Hashing)
- sed (Shortest Expected Delay)
- nq (Never Queue)

Implementazione

Sono necessari solo pochi passaggi per abilitare IPVS nel cluster EKS. La prima cosa da fare è assicurarsi che sulle immagini dei nodi di lavoro EKS sia installato il ipvsadm pacchetto di amministrazione Linux Virtual Server. Per installare questo pacchetto su un'immagine basata su Fedora, come Amazon Linux 2023, puoi eseguire il seguente comando sull'istanza del nodo di lavoro.

sudo dnf install -y ipvsadm

Su un'immagine basata su Debian, come Ubuntu, il comando di installazione sarebbe simile al seguente.

sudo apt-get install ipvsadm

Successivamente, è necessario caricare i moduli del kernel per le opzioni di configurazione IPVS elencate sopra. Si consiglia di scrivere questi moduli in un file all'interno della /etc/modules-load.d/ directory in modo che sopravvivano al riavvio.

sudo sh -c 'cat << EOF > /etc/modules-load.d/ipvs.conf ip_vs ip_vs_rr ip_vs_wrr ip_vs_lc ip_vs_wlc ip_vs_lblc ip_vs_lblcr ip_vs_sh ip_vs_dh ip_vs_sed ip_vs_nq nf_conntrack EOF'

È possibile eseguire il comando seguente per caricare questi moduli su un computer già in esecuzione.

sudo modprobe ip_vs sudo modprobe ip_vs_rr sudo modprobe ip_vs_wrr sudo modprobe ip_vs_lc sudo modprobe ip_vs_wlc sudo modprobe ip_vs_lblc sudo modprobe ip_vs_lblcr sudo modprobe ip_vs_sh sudo modprobe ip_vs_dh sudo modprobe ip_vs_sed sudo modprobe ip_vs_nq sudo modprobe nf_conntrack
Nota

Si consiglia vivamente di eseguire questi passaggi del nodo di lavoro come parte del processo di avvio del nodo di lavoro tramite script di dati utente o in qualsiasi script di compilazione eseguito per creare un AMI del nodo di lavoro personalizzato.

Successivamente, configurerai i tuoi cluster kube-proxy DaemonSet per l'esecuzione in modalità IPVS. Questa operazione viene eseguita impostando kube-proxy mode su ipvs e su una delle opzioni di bilanciamento del carico sopra elencate, ad esempio: rr per Round Robin. ipvs scheduler

avvertimento

Si tratta di una modifica dirompente e deve essere eseguita al di fuori delle ore lavorative. Consigliamo di apportare queste modifiche durante la creazione iniziale del cluster EKS per ridurre al minimo gli impatti.

Puoi emettere un comando AWS CLI per abilitare IPVS aggiornando il kube-proxy componente aggiuntivo EKS.

aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \ --configuration-values '{"ipvs": {"scheduler": "rr"}, "mode": "ipvs"}' \ --resolve-conflicts OVERWRITE

Oppure puoi farlo modificando il file nel kube-proxy-config ConfigMap tuo cluster.

kubectl -n kube-system edit cm kube-proxy-config

Trova l'schedulerimpostazione sotto ipvs e imposta il valore su una delle opzioni di bilanciamento del carico ipvs elencate sopra, ad esempio: rr per Round Robin. Trova l'modeimpostazione, che è predefinita suiptables, e modifica il valore in. ipvs Il risultato di entrambe le opzioni dovrebbe essere simile alla configurazione riportata di seguito.

iptables: masqueradeAll: false masqueradeBit: 14 minSyncPeriod: 0s syncPeriod: 30s ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler: "rr" syncPeriod: 30s kind: KubeProxyConfiguration metricsBindAddress: 0.0.0.0:10249 mode: "ipvs" nodePortAddresses: null oomScoreAdj: -998 portRange: "" udpIdleTimeout: 250ms

Se i nodi di lavoro sono stati aggiunti al cluster prima di apportare queste modifiche, sarà necessario riavviare il kube-proxy DaemonSet.

kubectl -n kube-system rollout restart ds kube-proxy

Validation

Puoi verificare che il cluster e i nodi di lavoro siano in esecuzione in modalità IPVS emettendo il seguente comando su uno dei tuoi nodi di lavoro.

sudo ipvsadm -L

Come minimo, dovresti vedere un risultato simile a quello riportato di seguito, che mostra le voci relative al servizio Kubernetes API Server all'indirizzo e al servizio CoredNS 10.100.0.1 all'indirizzo. 10.100.0.10

IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP ip-10-100-0-1.us-east-1. rr -> ip-192-168-113-81.us-eas Masq 1 0 0 -> ip-192-168-162-166.us-ea Masq 1 1 0 TCP ip-10-100-0-10.us-east-1 rr -> ip-192-168-104-215.us-ea Masq 1 0 0 -> ip-192-168-123-227.us-ea Masq 1 0 0 UDP ip-10-100-0-10.us-east-1 rr -> ip-192-168-104-215.us-ea Masq 1 0 0 -> ip-192-168-123-227.us-ea Masq 1 0 0
Nota

Questo output di esempio proviene da un cluster EKS con un intervallo di indirizzi IP di servizio di. 10.100.0.0/16

In questa pagina

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.