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 Pod un indirizzo IP selezionato dalla sottorete principale. La sottorete principale è la sottorete CIDR a cui è collegato l'ENI primario, in genere la sottorete del nodo/host.
Se la sottorete CIDR è troppo piccola, il CNI potrebbe non essere in grado di acquisire un numero sufficiente di indirizzi IP secondari da assegnare ai Pod. Questa è una sfida comune per i cluster EKS. IPv4
La rete personalizzata è una soluzione a questo problema.
La rete personalizzata risolve il problema dell'esaurimento dell'IP assegnando il nodo e il pod IPs dagli spazi di indirizzi VPC secondari (CIDR). Il supporto di rete personalizzato supporta risorse personalizzate. 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 una rete secondaria nella sottorete definita ENIs in. ENIConfig Il CNI assegna ai Pods un indirizzo IP da un intervallo CIDR definito in un CRD. ENIConfig
Poiché l'ENI principale 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 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 CIDRs (/16) dallo spazio CG-NAT, ad esempio 100.64.0.0/10 o 198.19.0.0/16 poiché è meno probabile che vengano utilizzati in un ambiente aziendale rispetto ad altri intervalli. RFC1918 Per ulteriori informazioni sulle associazioni di blocchi CIDR consentite e limitate che puoi utilizzare con il tuo VPC, IPv4 consulta Restrizioni alle associazioni di blocchi CIDR nella sezione sul dimensionamento di VPC e sottorete della documentazione VPC.
Come illustrato nel diagramma seguente, l'interfaccia di rete elastica (ENI) principale del nodo di lavoro utilizza ancora l'intervallo CIDR VPC primario (in questo caso 10.0.0.0/16) ma il secondario utilizza l'intervallo CIDR VPC secondario (in questo caso ENIs 100.64.0.0/16). Ora, per fare in modo che i Pod utilizzino l'intervallo CIDR 100.64.0.0/16, è necessario configurare il plug-in CNI per utilizzare una rete personalizzata. Puoi seguire i passaggi come documentato qui.
Se desideri che il CNI utilizzi una rete personalizzata, imposta la AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG variabile di ambiente su. true
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 programmati 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 drenare i nodi esistenti. I nodi di lavoro e i Pod esistenti rimarranno inalterati.
Raccomandazioni
Usa reti personalizzate quando
Ti consigliamo di prendere in considerazione la possibilità di utilizzare una rete personalizzata se hai a che fare con IPv4 l'esaurimento e non puoi IPv6 ancora utilizzarla. Il supporto di Amazon EKS per RFC6598
Potresti prendere in considerazione una rete personalizzata se hai l'esigenza di sicurezza di eseguire i Pod su una rete diversa con requisiti di gruppo di sicurezza diversi. Quando è abilitata la rete personalizzata, i pod utilizzano sottoreti o gruppi di sicurezza diversi, come definito nell'interfaccia ENIConfig di rete principale del nodo.
La rete personalizzata è infatti l'opzione ideale per implementare più cluster e applicazioni EKS per connettere i servizi di datacenter locali. Puoi aumentare il numero di indirizzi privati (RFC1918) accessibili a EKS nel tuo VPC per servizi come Amazon Elastic Load Balancing e NAT-GW, utilizzando al contempo lo spazio CG-NAT non routabile per i tuoi pod su più cluster. La rete personalizzata con il gateway di transito
Evita le reti personalizzate quando
Pronto per l'implementazione IPv6
Le reti personalizzate possono mitigare i problemi di esaurimento dell'IP, ma richiedono un sovraccarico operativo aggiuntivo. Se attualmente stai implementando un IPv6 VPC dual-stack IPv4 (/) o se il tuo piano include il IPv6 supporto, ti consigliamo invece di implementare i cluster. IPv6 Puoi configurare i cluster IPv6 EKS e migrare le tue app. In un cluster IPv6 EKS, sia Kubernetes che Pods ricevono un IPv6 indirizzo e possono comunicare in entrata e in uscita verso entrambi gli endpoint. IPv4 IPv6 Consulta le best practice per l'esecuzione di cluster EKS. IPv6
Spazio CG-NAT esaurito
Inoltre, se attualmente utilizzi CIDRs lo spazio CG-NAT o non riesci a collegare un CIDR secondario al tuo VPC del cluster, potresti dover esplorare altre opzioni, come 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 CNI open source. Consulta la guida per l'utente dei plugin CNI alternativi per maggiori dettagli.
Usa Private NAT Gateway
Amazon VPC ora offre funzionalità di gateway NAT privati. Il gateway NAT privato di Amazon consente alle istanze in sottoreti private di connettersi ad altre VPCs reti locali con sovrapposizioni. CIDRs Prendi in considerazione l'utilizzo del metodo descritto in questo post del blog
L'architettura di rete utilizzata nell'implementazione di questo post di blog segue le raccomandazioni contenute nella documentazione di Amazon VPC in Abilita la comunicazione tra reti sovrapposte. Come dimostrato in questo post del blog, puoi ampliare l'utilizzo del gateway NAT privato insieme RFC6598 agli indirizzi per gestire i problemi di esaurimento degli IP privati dei clienti. I cluster EKS, i nodi di lavoro, vengono distribuiti nell'intervallo CIDR secondario VPC 100.64.0.0/16 non routabile, mentre il gateway NAT privato, il gateway NAT, viene distribuito negli intervalli CIDR routabili. RFC1918 Il blog spiega come viene utilizzato un gateway di transito per la connessione al fine di facilitare la comunicazione tra intervalli CIDR sovrapposti non instradabili. VPCs VPCs Per i casi d'uso in cui le risorse EKS nell'intervallo di indirizzi non instradabili di un VPC devono comunicare con altre VPCs che non hanno intervalli di indirizzi sovrapposti, i clienti hanno la possibilità di utilizzare il peering VPC per interconnettere tali risorse. VPCs Questo metodo potrebbe fornire potenziali risparmi sui costi poiché tutto il transito di dati all'interno di una zona di disponibilità tramite una connessione peering VPC è ora gratuito.
Rete unica per nodi e pod
Se è necessario isolare i nodi e i pod su una rete specifica per motivi di sicurezza, si consiglia di distribuire nodi e pod in 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 sui nuovi nodi di lavoro. Per ulteriori informazioni su come implementarlo, consulta questo post del blog.
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 attivo il cluster EKS (il piano di controllo rimarrà sull'originale). subnet/s), but the nodes and Pods will be moved to a secondary subnet/s 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 sui nuovi nodi di lavoro.
Automatizza la configurazione con le etichette delle zone di disponibilità
Puoi consentire a Kubernetes di applicare automaticamente la zona di disponibilità (AZ) corrispondente ENIConfig per il nodo di lavoro.
Kubernetes aggiunge automaticamente il tag ai nodi di lavoro. topology.kubernetes.io/zonefailure-domain.beta.kubernetes.io/zone è obsoleto e sostituito con il tag. topology.kubernetes.io/zone
-
Imposta il
namecampo sulla zona di disponibilità del tuo VPC. -
Abilita la configurazione automatica con questo comando:
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
se si dispone di più sottoreti secondarie per zona di disponibilità, è necessario crearne una specifica. ENI_CONFIG_LABEL_DEF Potresti prendere in considerazione la configurazione k8s.amazonaws.com/eniConfigENI_CONFIG_LABEL_DEF come e. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2
Sostituisci i pod durante la configurazione della rete secondaria
L'abilitazione della rete personalizzata non modifica i nodi esistenti. La rete personalizzata è un'azione dirompente. Anziché effettuare 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 EKS Getting Started Guide 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 del provisioning dei nodi di lavoro.
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
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 EC2 tipo di istanza. Per ovviare a questa limitazione, puoi utilizzare l'assegnazione dei prefissi con reti personalizzate. Con l'assegnazione del prefisso, ogni IP secondario viene sostituito con un prefisso /28 sul secondario. ENIs
Considerate 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
-
3 ENIs - 1) * (10 secondary IPs per ENI - 1 + 2 = 20
L'abilitazione degli allegati con prefisso aumenta il numero di Pod a 290.
-
(3 ENIs - 1) * ((10 secondary IPs per ENI - 1) * 16 + 2 = 290
Tuttavia, suggeriamo di impostare il numero massimo di pod su 110 anziché 290 perché l'istanza ha un numero piuttosto ridotto di virtual. CPUs Nelle istanze più grandi, EKS consiglia un valore massimo di 250 pod. Quando si utilizzano allegati di prefisso con tipi di istanze più piccoli (ad esempio m5.large), è possibile che si esauriscano le risorse di CPU e memoria dell'istanza ben prima degli indirizzi IP.
Nota
Quando il prefisso CNI assegna un prefisso /28 a un ENI, deve essere un blocco contiguo di indirizzi IP. Se la sottorete da cui viene generato il prefisso è altamente frammentata, l'allegato del prefisso potrebbe non riuscire. È possibile evitare che ciò accada creando un nuovo VPC dedicato per il cluster o riservando alla sottorete un set di CIDR esclusivamente per gli allegati del prefisso. Visita Subnet CIDR reservations per ulteriori informazioni su questo argomento.
Identifica l'uso esistente dello spazio CG-NAT
La rete personalizzata consente di mitigare il problema dell'esaurimento dell'IP, tuttavia non può risolvere tutte le sfide. Se utilizzi già lo spazio CG-NAT per il tuo cluster o semplicemente non hai la possibilità di associare un CIDR secondario al tuo VPC del cluster, ti suggeriamo di esplorare altre opzioni, come utilizzare un CNI alternativo o passare ai cluster. IPv6
