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

CNI di Amazon VPC

Amazon EKS implementa il networking di cluster tramite il plug-in Amazon VPC Container Network Interface, noto anche come VPC CNI. Il plug-in CNI consente ai Kubernetes Pods di avere lo stesso indirizzo IP della rete VPC. Più specificamente, tutti i contenitori all'interno del Pod condividono uno spazio dei nomi di rete e possono comunicare tra loro utilizzando porte locali.

Amazon VPC CNI è composto da due componenti:

Quando viene creata un'istanza, EC2 crea e collega un ENI primario associato a una sottorete primaria. La sottorete principale può essere pubblica o privata. I Pod eseguiti in modalità HostNetwork utilizzano l'indirizzo IP primario assegnato al nodo ENI primario e condividono lo stesso spazio dei nomi di rete dell'host.

Il plugin CNI gestisce le interfacce di rete elastiche (ENI) sul nodo. Quando viene eseguito il provisioning di un nodo, il plug-in CNI alloca automaticamente un pool di slot (IP o prefissi) dalla sottorete del nodo all'ENI primario. Questo pool è noto come pool caldo e la sua dimensione è determinata dal tipo di istanza del nodo. A seconda delle impostazioni CNI, uno slot può essere un indirizzo IP o un prefisso. Quando è stato assegnato uno slot su un ENI, il CNI può collegare ai nodi ENI aggiuntivi con un pool di slot caldo. Questi ENI aggiuntivi sono denominati ENI secondari. Ogni ENI può supportare solo un certo numero di slot, in base al tipo di istanza. Il CNI assegna più ENI alle istanze in base al numero di slot necessari, che di solito corrisponde al numero di Pod. Questo processo continua fino a quando il nodo non è più in grado di supportare ENI aggiuntivi. Il CNI prealloca inoltre gli ENI e gli slot «caldi» per velocizzare l'avvio del Pod. Nota che ogni tipo di istanza ha un numero massimo di ENI che possono essere allegati. Questo è un vincolo alla densità dei Pod (numero di Pod per nodo), oltre alle risorse di calcolo.

Il numero massimo di interfacce di rete e il numero massimo di slot utilizzabili variano in base al tipo di istanza EC2. Poiché ogni Pod utilizza un indirizzo IP su uno slot, il numero di Pod che è possibile eseguire su una particolare istanza EC2 dipende dal numero di ENI che possono essere collegati e dal numero di slot supportati da ciascun ENI. Suggeriamo di impostare il numero massimo di Pods per EKS nella guida per l'utente per evitare l'esaurimento della CPU e delle risorse di memoria dell'istanza. L'uso hostNetwork dei pod è escluso da questo calcolo. Per ulteriori informazioni, consulta Come viene determinato MaxPods nella Amazon EKS User Guide.

Panoramica di

La modalità IP secondaria è la modalità predefinita per VPC CNI. Questa guida fornisce una panoramica generica del comportamento di VPC CNI quando la modalità IP secondaria è abilitata. La funzionalità di ipamd (allocazione degli indirizzi IP) può variare a seconda delle impostazioni di configurazione per VPC CNI, ad esempio, e. Prefix Mode per Linux Gruppi di sicurezza per pod Rete personalizzata

Amazon VPC CNI viene distribuito come demone Kubernetes denominato aws-node sui nodi di lavoro. Quando viene eseguito il provisioning di un nodo di lavoro, ad esso è collegato un ENI predefinito, chiamato ENI primario. Il CNI alloca un pool caldo di ENI e indirizzi IP secondari dalla sottorete collegata all'ENI primario del nodo. Per impostazione predefinita, ipamd tenta di allocare un ENI aggiuntivo al nodo. L'IPAMD alloca ENI aggiuntivi quando viene pianificato un singolo Pod e viene assegnato un indirizzo IP secondario dall'ENI primario. Questo ENI «caldo» consente una rete Pod più veloce. Man mano che il pool di indirizzi IP secondari si esaurisce, il CNI aggiunge un altro ENI per assegnarne altri.

Il numero di ENI e indirizzi IP in un pool sono configurati tramite variabili di ambiente denominate WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET. Il Daemonset controllerà periodicamente che sia allegato un numero sufficiente di ENI. aws-node Viene allegato un numero sufficiente di ENI quando tutte le condizioni o WARM_IP_TARGET e MINIMUM_IP_TARGET sono WARM_ENI_TARGET soddisfatte. Se gli ENI allegati sono insufficienti, il CNI effettuerà una chiamata API a EC2 per allegarne altri fino MAX_ENI al raggiungimento del limite.

Questo progetto include un documento Excel di Subnet Calculator. https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx Questo documento di calcolo simula il consumo di indirizzi IP di un carico di lavoro specificato in diverse opzioni di configurazione ENI, come e. WARM_IP_TARGET WARM_ENI_TARGET

Quando Kubelet riceve una richiesta di aggiunta di Pod, il binario CNI interroga ipamd per un indirizzo IP disponibile, che ipamd fornisce quindi al Pod. Il binario CNI collega l'host e la rete Pod.

I pod distribuiti su un nodo sono, per impostazione predefinita, assegnati agli stessi gruppi di sicurezza dell'ENI primario. In alternativa, i pod possono essere configurati con diversi gruppi di sicurezza.

Man mano che il pool di indirizzi IP si riduce numericamente, il plug-in allega automaticamente un'altra interfaccia di rete elastica all'istanza e alloca un altro set di indirizzi IP secondari a tale interfaccia. Questo processo continua finché il nodo non è più in grado di supportare altre interfacce di rete elastiche.

Quando un Pod viene eliminato, VPC CNI inserisce l'indirizzo IP del Pod in una cache di raffreddamento di 30 secondi. Gli IP in una cache di raffreddamento non vengono assegnati ai nuovi Pod. Al termine del periodo di raffreddamento, VPC CNI riporta l'IP del Pod nella piscina calda. Il periodo di riflessione impedisce il riciclaggio prematuro degli indirizzi IP del Pod e consente a kube-proxy su tutti i nodi del cluster di completare l'aggiornamento delle regole di iptables. Quando il numero di IP o ENI supera il numero di impostazioni warm pool, il plug-in ipamd restituisce IP ed ENI al VPC.

Come descritto sopra in modalità IP secondario, ogni Pod riceve un indirizzo IP privato secondario da uno degli ENI collegati a un'istanza. Poiché ogni Pod utilizza un indirizzo IP, il numero di Pod che è possibile eseguire su una particolare istanza EC2 dipende dal numero di ENI che possono essere collegati e da quanti indirizzi IP supporta. Il VPC CNI controlla il file dei limiti per scoprire quanti ENI e indirizzi IP sono consentiti per ogni tipo di istanza.

Puoi utilizzare la seguente formula per determinare il numero massimo di Pod che puoi distribuire su un nodo.

(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2

Il +2 indica i pod che richiedono una rete host, come kube-proxy e VPC CNI. Amazon EKS richiede che kube-proxy e VPC CNI funzionino su ciascun nodo e questi requisiti vengono presi in considerazione nel valore max-pods. Se desideri eseguire pod di rete host aggiuntivi, valuta la possibilità di aggiornare il valore max-pods. È possibile specificare --kubelet-extra-args "—max-pods=110" come dati utente nel modello di avvio.

Ad esempio, in un cluster con 3 nodi c5.large (3 ENI e massimo 10 IP per ENI), quando il cluster si avvia e ha 2 pod CoreDNS, il CNI consumerà 50 indirizzi IP e manterrà 43 IP in warm pool. Il warm pool consente un avvio più rapido del Pod quando l'applicazione viene distribuita.

Nodo 1 (con pod CoreDNS): 2 ENI, 20 IP assegnati

Nodo 2 (con pod CoreDNS): 2 ENI, 20 IP assegnati

Nodo 3 (senza pod): 1 ENI. 10 IP assegnati.

Per il nodo 1 e il nodo 2 (configurazione identica):

Per il nodo 3:

Calcolo del pool caldo totale: - 17 (Nodo 1) + 17 (Nodo 2) + 9 (Nodo 3) = 43 IP

Tieni presente che i pod di infrastruttura, spesso eseguiti come set di demoni, contribuiscono ciascuno al numero massimo di pod. Questi possono includere:

Ti suggeriamo di pianificare la tua infrastruttura combinando le capacità di questi pod. Per un elenco del numero massimo di Pod supportati da ogni tipo di istanza, consulta eni-max-pods.txt su. GitHub

Raccomandazioni

Implementa il cluster EKS con la modalità automatica

Quando utilizzi EKS Auto Mode per creare un cluster, AWS gestisce la configurazione VPC Container Network Interface (CNI) per il cluster. Con la modalità automatica di Amazon EKS, non devi installare o aggiornare componenti aggiuntivi di rete. Tuttavia, assicurati che i carichi di lavoro siano compatibili con la configurazione CNI VPC gestita.

Implementa VPC CNI Managed Add-On

Quando esegui il provisioning di un cluster, Amazon EKS installa VPC CNI automaticamente. Amazon EKS supporta tuttavia componenti aggiuntivi gestiti che consentono al cluster di interagire con le risorse AWS sottostanti come elaborazione, archiviazione e rete. Consigliamo vivamente di distribuire cluster con componenti aggiuntivi gestiti, tra cui VPC CNI.

Il componente aggiuntivo gestito di Amazon EKS offre l'installazione e la gestione di VPC CNI per i cluster Amazon EKS. I componenti aggiuntivi di Amazon EKS includono le ultime patch di sicurezza e correzioni di bug e sono convalidati da AWS per funzionare con Amazon EKS. Il componente aggiuntivo VPC CNI ti consente di garantire continuamente la sicurezza e la stabilità dei tuoi cluster Amazon EKS e di ridurre la quantità di sforzi necessari per installare, configurare e aggiornare i componenti aggiuntivi. Inoltre, un componente aggiuntivo gestito può essere aggiunto, aggiornato o eliminato tramite l'API Amazon EKS, la Console di gestione AWS, l'interfaccia a riga di comando AWS ed eksctl.

Puoi trovare i campi gestiti di VPC CNI usando flag con il comando. --show-managed-fields kubectl get

kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml

I componenti aggiuntivi gestiti impediscono la deriva della configurazione sovrascrivendo automaticamente le configurazioni ogni 15 minuti. Ciò significa che qualsiasi modifica ai componenti aggiuntivi gestiti, apportata tramite l'API Kubernetes dopo la creazione del componente aggiuntivo, verrà sovrascritta mediante il processo automatico di prevenzione della deriva e inoltre impostata sui valori predefiniti durante il processo di aggiornamento dei componenti aggiuntivi.

I campi gestiti da EKS sono elencati in ManagedFields con manager come EKS. I campi gestiti da EKS includono account di servizio, immagine, URL dell'immagine, sonda di vivacità, sonda di prontezza, etichette, volumi e supporti di volume.

Ti consigliamo di testare il comportamento del componente aggiuntivo nei cluster non di produzione per una configurazione specifica prima di aggiornare i cluster di produzione. Inoltre, segui i passaggi indicati nella guida per l'utente EKS per le configurazioni dei componenti aggiuntivi. https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html

Esegui la migrazione a Managed Add-On

Gestirai la compatibilità delle versioni e aggiornerai le patch di sicurezza del VPC CNI autogestito. Per aggiornare un componente aggiuntivo autogestito, è necessario utilizzare le API e le istruzioni di Kubernetes descritte nella guida per l'utente EKS. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on Consigliamo di migrare a un componente aggiuntivo gestito per i cluster EKS esistenti e consigliamo vivamente di creare un backup delle impostazioni CNI correnti prima della migrazione. Per configurare i componenti aggiuntivi gestiti, puoi utilizzare l'API Amazon EKS, la Console di gestione AWS o l'interfaccia a riga di comando AWS.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Amazon EKS sostituirà le impostazioni di configurazione CNI se il campo è indicato come gestito con impostazioni predefinite. Facciamo attenzione a non modificare i campi gestiti. L'add-on non riconcilia i campi di configurazione come le variabili di ambiente warm e le modalità CNI. I pod e le applicazioni continueranno a funzionare durante la migrazione a un CNI gestito.

Effettua il backup delle impostazioni CNI prima dell'aggiornamento

VPC CNI viene eseguito sul piano dati del cliente (nodi), pertanto Amazon EKS non aggiorna automaticamente il componente aggiuntivo (gestito e autogestito) quando vengono rilasciate nuove versioni o dopo l'aggiornamento del cluster a una nuova versione secondaria di Kubernetes. Per aggiornare il componente aggiuntivo per un cluster esistente, devi attivare un aggiornamento tramite l'API update-addon o facendo clic sul link aggiorna ora nella console EKS per i componenti aggiuntivi. Se hai implementato un componente aggiuntivo autogestito, segui i passaggi indicati nella sezione Aggiornamento del componente aggiuntivo CNI VPC autogestito. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on

Ti consigliamo vivamente di aggiornare una versione minore alla volta. Ad esempio, se la versione secondaria corrente è 1.9 e si desidera aggiornarla a 1.11, è necessario prima eseguire l'aggiornamento alla versione più recente della patch di 1.10, quindi, eseguire l'aggiornamento alla patch più recente di 1.11.

Esegui un'ispezione del daemonset di aws-node prima di aggiornare Amazon VPC CNI. Effettua un backup delle impostazioni esistenti. Se utilizzi un componente aggiuntivo gestito, conferma di non aver aggiornato alcuna impostazione che Amazon EKS potrebbe sovrascrivere. Ti consigliamo di inserire un hook successivo all'aggiornamento nel flusso di lavoro di automazione o una fase di applicazione manuale dopo l'aggiornamento di un componente aggiuntivo.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Per un componente aggiuntivo autogestito, confronta il backup con releases on GitHub per vedere le versioni disponibili e acquisire familiarità con le modifiche nella versione a cui desideri eseguire l'aggiornamento. Ti consigliamo di utilizzare Helm per gestire i componenti aggiuntivi autogestiti e sfruttare i file di valori per applicare le impostazioni. Qualsiasi operazione di aggiornamento che comporti l'eliminazione di Daemonset comporterà tempi di inattività dell'applicazione e deve essere evitata.

Comprendi il contesto di sicurezza

Ti consigliamo vivamente di comprendere i contesti di sicurezza configurati per gestire VPC CNI in modo efficiente. Amazon VPC CNI ha due componenti: CNI binary e ipamd (aws-node) Daemonset. Il CNI viene eseguito come binario su un nodo e ha accesso al file system root del nodo, inoltre ha un accesso privilegiato in quanto gestisce iptables a livello di nodo. Il binario CNI viene richiamato dal kubelet quando Pods viene aggiunto o rimosso.

L'aws-node Daemonset è un processo di lunga durata responsabile della gestione degli indirizzi IP a livello di nodo. L'aws-node funziona in hostNetwork modalità e consente l'accesso al dispositivo di loopback e all'attività di rete di altri pod sullo stesso nodo. L'init-container aws-node funziona in modalità privilegiata e monta il socket CRI che consente a Daemonset di monitorare l'utilizzo dell'IP da parte dei Pod in esecuzione sul nodo. Amazon EKS sta lavorando per rimuovere il requisito privilegiato del contenitore di inizializzazione aws-node. Inoltre, aws-node deve aggiornare le voci NAT e caricare i moduli iptables e quindi viene eseguito con i privilegi NET_ADMIN.

Amazon EKS consiglia di implementare le politiche di sicurezza definite dal manifesto aws-node per la gestione degli IP per i Pods e le impostazioni di rete. Prendi in considerazione l'aggiornamento alla versione più recente di VPC CNI. Inoltre, considera la possibilità di aprire un GitHub problema se hai un requisito di sicurezza specifico.

Usa un ruolo IAM separato per CNI

L'AWS VPC CNI richiede le autorizzazioni AWS Identity and Access Management (IAM). La policy CNI deve essere impostata prima di poter utilizzare il ruolo IAM. Puoi usare AmazonEKS_CNI_Policy, che è una policy gestita da AWS per i cluster IPv4. La policy gestita da Amazon EKS CNI dispone di autorizzazioni solo per i cluster IPv4. È necessario creare una policy IAM separata per i cluster IPv6 con le autorizzazioni elencate qui. https://docs.aws.amazon.com/eks/latest/userguide/cni-iam-role.html#cni-iam-role-create-ipv6-policy

Per impostazione predefinita, VPC CNI eredita il ruolo IAM del nodo Amazon EKS (gruppi di nodi gestiti e autogestiti).

Si consiglia vivamente di configurare un ruolo IAM separato con le politiche pertinenti per Amazon VPC CNI. In caso contrario, i pod di Amazon VPC CNI ottengono l'autorizzazione assegnata al ruolo IAM del nodo e hanno accesso al profilo di istanza assegnato al nodo.

Il plugin VPC CNI crea e configura un account di servizio chiamato aws-node. Per impostazione predefinita, l'account di servizio si lega al ruolo IAM del nodo Amazon EKS con la policy CNI di Amazon EKS allegata. Per utilizzare il ruolo IAM separato, ti consigliamo di creare un nuovo account di servizio con la policy CNI di Amazon EKS allegata. Per utilizzare un nuovo account di servizio è necessario ridistribuire i pod CNI. Prendi in considerazione la possibilità di specificare un componente aggiuntivo gestito --service-account-role-arn da VPC CNI durante la creazione di nuovi cluster. Assicurati di rimuovere la policy CNI di Amazon EKS per IPv4 e IPv6 dal ruolo del nodo Amazon EKS.

È consigliabile bloccare i metadati delle istanze di accesso per ridurre al minimo il rischio di violazione della sicurezza.

Gestire i guasti della sonda Liveness/Readiness

Consigliamo di aumentare i valori di timeout della sonda di vitalità e prontezza (impostazione predefinitatimeoutSeconds: 10) per i cluster EKS 1.20 e successivi per evitare che i guasti della sonda causino il blocco del Pod dell'applicazione nello stato ContainerCreating. Questo problema è stato riscontrato nei cluster ad alta intensità di dati e di elaborazione in batch. L'elevato utilizzo della CPU causa problemi di integrità della sonda aws-node, con conseguenti richieste di CPU Pod non soddisfatte. Oltre a modificare il timeout della sonda, assicurati che le richieste di risorse CPU (predefinite) per aws-node siano configurate correttamente. CPU: 25m Non consigliamo di aggiornare le impostazioni a meno che il nodo non abbia problemi.

Ti consigliamo vivamente di eseguire sudo bash /opt/cni/bin/aws-cni-support.sh su un nodo mentre utilizzi il supporto di Amazon EKS. Lo script ti aiuterà a valutare i log di Kubelet e l'utilizzo della memoria sul nodo. Prendi in considerazione l'installazione di SSM Agent sui nodi di lavoro di Amazon EKS per eseguire lo script.

Configura la policy di inoltro di IPtables su istanze AMI non ottimizzate per EKS

Se utilizzi un'AMI personalizzata, assicurati di impostare la policy di inoltro di iptables su ACCEPT in kubelet.service. https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/rootfs/etc/systemd/system/kubelet.service Molti sistemi impostano la policy forward di iptables su DROP. Puoi creare AMI personalizzate utilizzando HashiCorp Packer e una specifica di compilazione con risorse e script di configurazione dal repository AMI Amazon EKS su AWS. GitHub Puoi aggiornare kubelet.service e seguire le istruzioni qui specificate per creare un'AMI personalizzata.

Aggiorna regolarmente la versione CNI

Il VPC CNI è retrocompatibile. L'ultima versione funziona con tutte le versioni Kubernetes supportate da Amazon EKS. Inoltre, il VPC CNI è offerto come componente aggiuntivo EKS (vedi «Deploy VPC CNI Managed" sopra). Add-On Sebbene i componenti aggiuntivi EKS orchestrino gli aggiornamenti dei componenti aggiuntivi, non aggiorneranno automaticamente i componenti aggiuntivi come il CNI perché vengono eseguiti sul piano dati. L'utente è responsabile dell'aggiornamento del componente aggiuntivo VPC CNI in seguito agli aggiornamenti gestiti e autogestiti dei nodi di lavoro.