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

Rete personalizzata

Per impostazione predefinita, Amazon VPC CNI assegnerà ai Pods un indirizzo IP selezionato dalla sottorete primaria. La sottorete principale è il CIDR di sottorete a cui è collegato l'ENI primario, di solito la sottorete di. node/host

Se il CIDR della sottorete è troppo piccolo, il CNI potrebbe non essere in grado di acquisire un numero sufficiente di indirizzi IP secondari da assegnare ai tuoi Pod. Questa è una sfida comune per i cluster IPv4 EKS.

La rete personalizzata è una soluzione a questo problema.

La rete personalizzata risolve il problema dell'esaurimento degli IP assegnando gli IP del nodo e del Pod da spazi di indirizzi VPC secondari (CIDR). Il supporto di rete personalizzato supporta la risorsa personalizzata EniConfig. EniConfig include un intervallo CIDR di sottorete alternativo (ricavato da un CIDR VPC secondario), insieme ai gruppi di sicurezza a cui apparterranno i Pod. Quando la rete personalizzata è abilitata, il VPC CNI crea ENI secondari nella sottorete definita in eniConfig. Il CNI assegna ai Pods un indirizzo IP da un intervallo CIDR definito in un CRD EniConfig.

Poiché l'ENI primario non viene utilizzato da reti personalizzate, il numero massimo di Pod che è possibile eseguire su un nodo è inferiore. I Pod della rete host continuano a utilizzare l'indirizzo IP assegnato all'ENI primario. Inoltre, l'ENI primario viene utilizzato per gestire la traduzione della rete di origine e indirizzare il traffico dei Pods all'esterno del nodo.

Configurazione di esempio

Sebbene la rete personalizzata accetti un intervallo VPC valido per l'intervallo CIDR secondario, si consiglia di utilizzare i CIDR dallo spazio di indirizzi 100.64.0.0/10 condiviso (RFC 6598) poiché è meno probabile che vengano utilizzati in un ambiente aziendale rispetto ad altri intervalli RFC1918. Ad esempio, puoi utilizzarlo come CIDR secondario per il tuo VPC. 100.64.0.0/16 Per ulteriori informazioni sulle associazioni di blocchi CIDR consentite e limitate che puoi utilizzare con il tuo VPC, consulta le restrizioni alle associazioni di blocchi CIDR IPv4 nella sezione sul dimensionamento del VPC e delle sottoreti della documentazione VPC.

Come mostrato nel diagramma seguente, l'interfaccia di rete elastica principale (ENI) del nodo di lavoro utilizza ancora l'intervallo CIDR VPC primario (in questo caso 10.0.0). 0/16) ma gli ENI secondari utilizzano l'intervallo VPC CIDR secondario (in questo caso 100.64.0. 0/16). Ora, per avere i Pod usa il 100.64.0. 0/16 Intervallo CIDR, è necessario configurare il plug-in CNI per utilizzare reti personalizzate. Puoi seguire i passaggi come documentato qui.

Se desideri che il CNI utilizzi una rete personalizzata, imposta la variabile di AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG ambiente sutrue.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

QuandoAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, il CNI assegnerà l'indirizzo IP del Pod da una sottorete definita in. ENIConfig La risorsa ENIConfig personalizzata viene utilizzata per definire la sottorete in cui verranno pianificati i Pod.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

Dopo aver creato le risorse ENIconfig personalizzate, dovrai creare nuovi nodi di lavoro e svuotare i nodi esistenti. I nodi di lavoro e i pod esistenti rimarranno inalterati.

Raccomandazioni

Usa una rete personalizzata quando

Ti consigliamo di prendere in considerazione una rete personalizzata se hai a che fare con l'esaurimento dell'IPv4 e non puoi ancora utilizzare l'IPv6. Il supporto di Amazon EKS per lo spazio RFC6598 consente di scalare i pod oltre la norma RFC1918 per risolvere i problemi di esaurimento. https://datatracker.ietf.org/doc/html/rfc1918 Prendi in considerazione l'utilizzo della delega dei prefissi con reti personalizzate per aumentare la densità dei pod su un nodo.

Potresti prendere in considerazione una rete personalizzata se hai un requisito di sicurezza per eseguire Pods su una rete diversa con requisiti di gruppo di sicurezza diversi. Quando la rete personalizzata è abilitata, i pod utilizzano una sottorete o gruppi di sicurezza diversi, come definiti in EniConfig, rispetto all'interfaccia di rete principale del nodo.

Il networking personalizzato è infatti un'opzione ideale per implementare più cluster e applicazioni EKS per connettere i servizi di datacenter on-premise. Puoi aumentare il numero di indirizzi privati (RFC1918) accessibili a EKS nel tuo VPC per servizi come Amazon Elastic Load Balancing e, allo stesso tempo NAT-GW, utilizzare lo spazio non instradabile per i tuoi pod su più cluster. CG-NAT Il networking personalizzato con il gateway di transito e uno Shared Services VPC (inclusi i gateway NAT in diverse zone di disponibilità per l'alta disponibilità) consente di fornire flussi di traffico scalabili e prevedibili. Questo post del blog descrive uno schema architetturale che è uno dei modi più consigliati per connettere EKS Pods a una rete di datacenter utilizzando reti personalizzate.

Evita la rete personalizzata quando

Pronto per implementare IPv6

La rete personalizzata può mitigare i problemi di esaurimento degli IP, ma richiede un sovraccarico operativo aggiuntivo. Se stai attualmente implementando un VPC dual-stack (IPv4/IPv6) o se il tuo piano include il supporto IPv6, ti consigliamo invece di implementare i cluster IPv6. Puoi configurare cluster EKS IPv6 e migrare le tue app. In un cluster EKS IPv6, sia Kubernetes che Pods ottengono un indirizzo IPv6 e possono comunicare in entrata e in uscita con gli endpoint IPv4 e IPv6. Consulta le best practice per l'esecuzione di cluster EKS IPv6.

CG-NAT Spazio esaurito

Inoltre, se attualmente stai utilizzando CIDR dallo CG-NAT spazio o non riesci a collegare un CIDR secondario al tuo cluster VPC, potresti dover esplorare altre opzioni, ad esempio l'utilizzo di un CNI alternativo. Ti consigliamo vivamente di ottenere supporto commerciale o di possedere le conoscenze interne per eseguire il debug e inviare patch al progetto di plug-in open source CNI. Consulta la guida utente di Alternate CNI Plugins per maggiori dettagli.

Usa Private NAT Gateway

Amazon VPC offre ora funzionalità di gateway NAT privati. Il NAT Gateway privato di Amazon consente alle istanze in sottoreti private di connettersi ad altri VPC e reti locali con CIDR sovrapposti. Prendi in considerazione l'utilizzo del metodo descritto in questo post del blog per utilizzare un gateway NAT privato per risolvere i problemi di comunicazione dei carichi di lavoro EKS causati dalla sovrapposizione di CIDR, una lamentela significativa espressa dai nostri clienti. La rete personalizzata non può risolvere da sola le difficoltà CIDR che si sovrappongono e si aggiunge alle sfide di configurazione.

L'architettura di rete utilizzata nell'implementazione di questo post del blog segue i consigli riportati nella sezione Abilita la comunicazione tra reti sovrapposte nella documentazione di Amazon VPC. Come illustrato in questo post del blog, puoi espandere l'uso del gateway NAT privato insieme agli indirizzi RFC6598 per gestire i problemi di esaurimento degli IP privati dei clienti. I cluster EKS, i nodi di lavoro, sono distribuiti nel formato non instradabile 100.64.0. 0/16 L'intervallo CIDR secondario VPC, mentre il gateway NAT privato, il gateway NAT, viene distribuito negli intervalli CIDR RFC1918 instradabili. Il blog spiega come viene utilizzato un gateway di transito per connettere i VPC al fine di facilitare la comunicazione tra VPC con intervalli CIDR non indirizzabili sovrapposti. Per i casi d'uso in cui le risorse EKS nell'intervallo di indirizzi non instradabili di un VPC devono comunicare con altri VPC che non hanno intervalli di indirizzi sovrapposti, i clienti hanno la possibilità di utilizzare VPC Peering per interconnettere tali VPC. Questo metodo potrebbe fornire potenziali risparmi sui costi poiché tutti i transiti di dati all'interno di una zona di disponibilità tramite una connessione peering VPC sono ora gratuiti.

Rete unica per nodi e pod

Se hai bisogno di isolare nodi e pod in una rete specifica per motivi di sicurezza, ti consigliamo di distribuire nodi e pod su una sottorete da un blocco CIDR secondario più grande (ad esempio 100.64.0). 0/8). Dopo l'installazione del nuovo CIDR nel tuo VPC, puoi distribuire un altro gruppo di nodi utilizzando il CIDR secondario e drenare i nodi originali per ridistribuire automaticamente i pod nei nuovi nodi di lavoro. Per ulteriori informazioni su come implementarlo, consulta questo post del blog. https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/

La rete personalizzata non viene utilizzata nella configurazione rappresentata nel diagramma seguente. Piuttosto, i nodi di lavoro Kubernetes vengono distribuiti su sottoreti dell'intervallo CIDR VPC secondario del VPC, ad esempio 100.64.0. 0/10. È possibile mantenere il cluster EKS in esecuzione (il piano di controllo rimarrà sull'originale subnet/s), ma i nodi e i pod verranno spostati in un secondo subnet/s piano. Questa è un'altra tecnica, anche se non convenzionale, per mitigare il pericolo di esaurimento dell'IP in un VPC. Proponiamo di svuotare i vecchi nodi prima di ridistribuire i pod nei nuovi nodi di lavoro.

Automatizza la configurazione con le etichette delle zone di disponibilità

Puoi abilitare Kubernetes ad applicare automaticamente la corrispondente eniConfig per la zona di disponibilità (AZ) del nodo di lavoro.

Kubernetes aggiunge automaticamente il tag ai nodi di lavoro. topology.kubernetes.io/zone Amazon EKS consiglia di utilizzare la zona di disponibilità come nome di configurazione ENI quando si dispone di una sola sottorete secondaria (CIDR alternativo) per AZ. È quindi possibile impostare l'etichetta utilizzata per scoprire il nome della configurazione ENI su. topology.kubernetes.io/zone Nota che il tag failure-domain.beta.kubernetes.io/zone è obsoleto e sostituito con il tag. topology.kubernetes.io/zone

kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"

Se sono presenti più sottoreti secondarie per zona di disponibilità, è necessario crearne una specifica. ENI_CONFIG_LABEL_DEF Potresti prendere in considerazione la possibilità di configurare i nodi ENI_CONFIG_LABEL_DEF as k8s.amazonaws.com/eniConfig ed label con nomi eniConfig personalizzati, come e. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Sostituisci i pod durante la configurazione della rete secondaria

L'attivazione della rete personalizzata non modifica i nodi esistenti. Il networking personalizzato è un'azione dirompente. Anziché eseguire una sostituzione progressiva di tutti i nodi di lavoro del cluster dopo aver abilitato la rete personalizzata, suggeriamo di aggiornare il CloudFormation modello AWS nella Guida introduttiva di EKS con una risorsa personalizzata che richiami una funzione Lambda per aggiornare il aws-node Daemonset con la variabile di ambiente per abilitare il networking personalizzato prima che i nodi di lavoro vengano assegnati.

Se nel cluster erano presenti nodi con Pod in esecuzione prima di passare alla funzionalità di rete CNI personalizzata, è necessario isolare e drenare i nodi per chiudere correttamente i Pod e quindi terminare i nodi. Solo i nuovi nodi che corrispondono all'etichetta o alle annotazioni EniConfig utilizzano una rete personalizzata, e quindi ai Pod pianificati su questi nuovi nodi può essere assegnato un IP dal CIDR secondario.

Calcola il numero massimo di pod per nodo

Poiché l'ENI primario del nodo non viene più utilizzato per assegnare gli indirizzi IP dei Pod, si verifica una diminuzione del numero di Pod che è possibile eseguire su un determinato tipo di istanza EC2. Per ovviare a questa limitazione è possibile utilizzare l'assegnazione dei prefissi con reti personalizzate. Con l'assegnazione del prefisso, ogni IP secondario viene sostituito con un prefisso /28 sugli ENI secondari.

Considera il numero massimo di Pod per un'istanza m5.large con rete personalizzata.

Il numero massimo di Pod che puoi eseguire senza l'assegnazione di un prefisso è 29

L'attivazione degli allegati con prefisso aumenta il numero di Pod a 290.

Tuttavia, suggeriamo di impostare max-pods su 110 anziché 290 perché l'istanza ha un numero piuttosto ridotto di CPU virtuali. Nelle istanze più grandi, EKS consiglia un valore massimo di pods di 250. Quando si utilizzano allegati di prefisso con tipi di istanza più piccoli (ad esempio m5.large), è possibile che si esauriscano le risorse di CPU e memoria dell'istanza ben prima dei relativi indirizzi IP.

Identifica l'utilizzo esistente dello spazio CG-NAT

La rete personalizzata consente di mitigare il problema dell'esaurimento degli IP, ma non è in grado di risolvere tutte le sfide. Se stai già utilizzando CG-NAT lo spazio per il tuo cluster o semplicemente non hai la possibilità di associare un CIDR secondario al tuo cluster VPC, ti suggeriamo di esplorare altre opzioni, come utilizzare un CNI alternativo o passare a cluster IPv6.