Lavorare con il componente aggiuntivo Kubernetes kube-proxy

Importante

Consigliamo di aggiungere al cluster il componente aggiuntivo del tipo Amazon EKS anziché quello del tipo autogestito. Se non conosci bene le differenze tra i due tipi, consulta la pagina Componenti aggiuntivi Amazon EKS. Per ulteriori informazioni sull'aggiunta di un componente aggiuntivo di Amazon EKS al cluster, consulta Creazione di un componente aggiuntivo. Se non riesci a utilizzare il componente aggiuntivo di Amazon EKS, ti invitiamo a segnalare il problema in Roadmap dei container GitHub .

Il componente aggiuntivo kube-proxy viene implementato su ogni nodo Amazon EC2 del cluster Amazon EKS. Mantiene le regole di rete sui nodi e consente la comunicazione di rete con i tuoi Pods. Il componente aggiuntivo non viene implementato sui nodi Fargate nel cluster. Per ulteriori informazioni, consulta kube-proxy nella documentazione Kubernetes.

La tabella seguente elenca la versione più recente del componente aggiuntivo di Amazon EKS disponibile per ogni versione Kubernetes.

Versione Kubernetes	1.29	1.28	1.27	1.26	1.25	1.24	1.23
	v1.29.1-eksbuild.2	v1.28.6-eksbuild.2	v1.27.10-eksbuild.2	v1.26.13-eksbuild.2	v1.25.16-eksbuild.3	v1.24.17-eksbuild.8	v1.23.17-eksbuild.9

Importante

Una versione precedente della documentazione non era corretta. kube-proxyversioni v1.28.5v1.27.9, e v1.26.12 non sono disponibili.

Se gestisci autonomamente questo componente aggiuntivo, le versioni nella tabella potrebbero non essere le stesse delle versioni autogestite disponibili.

Esistono due tipi di immagine di container kube-proxy disponibili per ogni versione del cluster Amazon EKS:

• Default (Predefinito): questo tipo è basato su un'immagine Docker basata su Debian mantenuta dalla comunità upstream Kubernetes.

• Minimal (Minimo): questo tipo è basato su un'immagine di base minima mantenuta da Amazon EKS Distro che contiene pacchetti minimi senza shell (interprete di comandi). Per ulteriori informazioni, consultare Amazon EKS Distro.

Ultima versione dell'immagine di container kube-proxy autogestita disponibile per ogni versione del cluster Amazon EKS
Image type (Tipo di immagine)	1.29	1.28	1.27	1.26	1.25	1.24	1.23
kube-proxy (tipo predefinito)	È disponibile solo il tipo minimo	È disponibile solo il tipo minimo	È disponibile solo il tipo minimo	È disponibile solo il tipo minimo	È disponibile solo il tipo minimo	v1.24.10-eksbuild.2	v1.23.16-eksbuild.2
kube-proxy (tipo minimo)	v1.29.1-minimal-eksbuild.2	v1.28.6-minimal-eksbuild.2	v1.27.10-minimal-eksbuild.2	v1.26.13-minimal-eksbuild.2	v1.25.16-minimal-eksbuild.3	v1.24.17-minimal-eksbuild.4	v1.23.17-minimal-eksbuild.5

Importante

• Il tipo di immagine predefinito non è disponibile per Kubernetes versione 1.25 e successive. È necessario utilizzare il tipo di immagine minimo.

• Quando aggiorni un tipo di componente aggiuntivo Amazon EKS, specifichi una versione del componente aggiuntivo Amazon EKS valida, che potrebbe non essere una versione elencata in questa tabella. Questo accade perché le versioni dei componenti aggiuntivi di Amazon EKS non sempre corrispondono alle versioni delle immagini del container specificate durante l'aggiornamento del componente aggiuntivo del tipo autogestito. Quando si aggiorna il componente aggiuntivo del tipo autogestito, si specifica una versione valida dell'immagine di container indicata in questa tabella.

Prerequisiti

• Un cluster Amazon EKS esistente. Per implementarne uno, consulta Guida introduttiva ad Amazon EKS.

Considerazioni

• Kube-proxy su un cluster Amazon EKS ha la stessa policy di compatibilità e disallineamento di Kubernetes.

• Kube-proxy deve essere alla stessa versione secondaria di kubelet sui nodi Amazon EC2.

• Kube-proxy non può essere successivo alla versione secondaria del piano di controllo (control plane) del tuo cluster.

• La versione kube-proxy sui nodi Amazon EC2 non può essere di più di due versioni secondarie successiva rispetto al piano di controllo. Ad esempio, se il piano di controllo utilizza la versione Kubernetes 1.29, la versione kube-proxy secondaria non può essere precedente alla 1.27.

• Se hai aggiornato recentemente il cluster a una nuova versione secondaria di Kubernetes, aggiorna i nodi EC2 Amazon alla medesima versione secondaria prima di eseguire l'aggiornamento di kube-proxy alla stessa versione secondaria dei nodi.

Aggiornamento del componente aggiuntivo autogestito kube-proxy

1. Verifica che sul cluster sia installato il componente aggiuntivo del tipo autogestito. Sostituisci my-cluster con il nome del tuo cluster.

   aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text
   

   Se viene restituito un messaggio di errore, sul cluster è installato il componente aggiuntivo del tipo autogestito. I passaggi rimanenti di questo argomento riguardano l'aggiornamento del componente aggiuntivo del tipo autogestito. Se viene restituito il numero di versione, sul cluster è installato il componente aggiuntivo del tipo Amazon EKS. Per aggiornarlo, utilizza la procedura descritta nell'argomento Aggiornamento di un componente aggiuntivo anziché quella descritta in questo argomento. Se non conosci bene le differenze tra i due tipi di componente aggiuntivo, consulta la pagina Componenti aggiuntivi Amazon EKS.

2. Scopri qual è la versione dell'immagine di container attualmente installata sul cluster.

   kubectl describe daemonset kube-proxy -n kube-system | grep Image
   

   Di seguito viene riportato un output di esempio:

   Image:    602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.25.6-minimal-eksbuild.2

   Nell'output di esempio, v1.25.6-minimal-eksbuild.2 è la versione installata sul cluster.

3. Aggiorna il componente aggiuntivo kube-proxy sostituendo 602401143452 e region-code con i valori del tuo output. Nel passaggio precedente, sostituisci v1.26.2-minimal-eksbuild.2 con la versione di kube-proxy elencata nella tabella Ultima versione di immagine di container di kube-proxy disponibile per ogni versione del cluster Amazon EKS. Puoi specificare il numero di versione per il tipo di immagine predefinito o minimo.

   kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.26.2-minimal-eksbuild.2
   

   Di seguito viene riportato un output di esempio:

   daemonset.apps/kube-proxy image updated

4. Verifica che la nuova versione sia ora installata nel cluster.

   kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3
   

   Di seguito viene riportato un output di esempio:

   v1.26.2-minimal-eksbuild.2

5. Se utilizzi nodi x86 e Arm nello stesso cluster e il cluster è stato implementato il prima del 17 agosto 2020. Modificare, il manifesto kube-proxy attraverso il seguente comando, per includere un selettore di nodi per più architetture hardware. Questa è un'operazione da compiere una sola volta. Dopo aver aggiunto il selettore al manifesto, non occorrerà aggiungerlo ogni volta che aggiorni il componente aggiuntivo. Se il cluster è stato implementato in data 17 agosto 2020 o successiva, il kube-proxy è già in grado di supportare una multi-architettura.

   kubectl edit -n kube-system daemonset/kube-proxy
   

   Aggiungere il seguente selettore di nodo al file nell'editor, quindi salvare il file. Per un esempio di dove includere questo testo nell'editor, consulta File manifesto CNI su GitHub. Ciò consente a Kubernetes di estrarre l'immagine hardware corretta in base all'architettura hardware del nodo.

   - key: "kubernetes.io/arch"
     operator: In
     values:
     - amd64
     - arm64

6. Se il cluster è stato originariamente creato con Kubernetes versione 1.14 o successiva, puoi saltare questo passaggio perché kube-proxy include già questo Affinity Rule. Se in origine hai creato un cluster Amazon EKS con la versione 1.13 di Kubernetes o precedente e intendi utilizzare nodi Fargate nel tuo cluster, modifica il manifesto kube-proxy in modo da includere una regola NodeAffinity per impedire ai Pods kube-proxy la pianificazione su nodi Fargate. Questa modifica si applica una sola volta. Dopo aver aggiunto Affinity Rule al manifesto, non occorrerà aggiungerlo ogni volta che aggiorni il componente aggiuntivo. Modifica il DaemonSet kube-proxy.

   kubectl edit -n kube-system daemonset/kube-proxy
   

   Aggiungi i seguenti elementi Affinity Rule alle sezioni DaemonSet spec del file nell'editor e salvare il file. Per un esempio di dove includere questo testo nell'editor, consulta File manifesto CNI su GitHub.

   - key: eks.amazonaws.com/compute-type
     operator: NotIn
     values:
     - fargate