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

Migliori pratiche per il networking

È fondamentale comprendere le reti Kubernetes per gestire in modo efficiente il cluster e le applicazioni. Il Pod networking, chiamato anche cluster networking, è il fulcro del networking Kubernetes. Kubernetes supporta i plugin Container Network Interface (CNI) per le reti di cluster.

Amazon EKS supporta ufficialmente il plug-in CNI Amazon Virtual Private Cloud (VPC) per implementare il networking Kubernetes Pod. Il VPC CNI fornisce l'integrazione nativa con AWS VPC e funziona in modalità underlay. In modalità underlay, i pod e gli host si trovano sullo stesso livello di rete e condividono lo spazio dei nomi di rete. L'indirizzo IP del Pod è coerente dal punto di vista del cluster e del VPC.

Questa guida presenta l'Amazon VPC Container Network Interface (VPC CNI) nel contesto della rete di cluster Kubernetes. Il VPC CNI è il plug-in di rete predefinito supportato da EKS e quindi è al centro della guida. Il VPC CNI è altamente configurabile per supportare diversi casi d'uso. Questa guida include inoltre sezioni dedicate su diversi casi d'uso, modalità operative e sottocomponenti di VPC CNI, seguite dai consigli.

Amazon EKS esegue Kubernetes upstream ed è certificato conforme a Kubernetes. Sebbene sia possibile utilizzare plugin CNI alternativi, questa guida non fornisce consigli per la gestione dei plugin alternativi. CNIs Consulta la documentazione EKS Alternate CNI per un elenco di partner e risorse per una gestione efficace delle alternative. CNIs

Modello di rete Kubernetes

Kubernetes stabilisce i seguenti requisiti per le reti di cluster:

Consulta il modello di rete Kubernetes per i dettagli su ciò che Kubernetes si aspetta dalle implementazioni di rete compatibili. La figura seguente illustra la relazione tra gli spazi dei nomi della rete Pod e lo spazio dei nomi della rete host.

Container Networking Interface (CNI)

Kubernetes supporta le specifiche e i plugin CNI per implementare il modello di rete Kubernetes. Un CNI è costituito da una specifica (versione attuale 1.0.0) e da librerie per la scrittura di plugin per configurare le interfacce di rete nei contenitori, oltre a una serie di plugin supportati. Il CNI si occupa solo della connettività di rete dei contenitori e della rimozione delle risorse allocate quando il contenitore viene eliminato.

Il plugin CNI viene abilitato passando a kubelet l'opzione della riga di comando. --network-plugin=cni Kubelet legge un file da --cni-conf-dir (default /etc/cni/net.d) e utilizza la configurazione CNI di quel file per configurare la rete di ciascun Pod. Il file di configurazione CNI deve corrispondere alla specifica CNI (minimo v0.4.0) e tutti i plugin CNI richiesti a cui fa riferimento la configurazione devono essere presenti nella directory (). --cni-bin-dir default /opt/cni/bin Se nella directory sono presenti più file di configurazione CNI, kubelet utilizza il file di configurazione che viene visualizzato per primo per nome in ordine lessicografico.

Amazon Virtual Private Cloud (VPC) CNI

Il VPC CNI fornito da AWS è il componente aggiuntivo di rete predefinito per i cluster EKS. Il componente aggiuntivo VPC CNI viene installato per impostazione predefinita durante il provisioning dei cluster EKS. VPC CNI viene eseguito su nodi di lavoro Kubernetes. Il componente aggiuntivo VPC CNI è costituito dal binario CNI e dal plug-in IP Address Management (ipamd). Il CNI assegna un indirizzo IP dalla rete VPC a un Pod. ipamd gestisce AWS Elastic Networking Interfaces (ENIs) su ogni nodo Kubernetes e mantiene il pool caldo di. IPs Il VPC CNI offre opzioni di configurazione per la preallocazione ENIs e gli indirizzi IP per tempi di avvio rapidi dei Pod. Consulta Amazon VPC CNI per le best practice consigliate per la gestione dei plugin.

Amazon EKS consiglia di specificare le sottoreti in almeno due zone di disponibilità quando si crea un cluster. Amazon VPC CNI alloca gli indirizzi IP ai pod dalle sottoreti dei nodi. Consigliamo vivamente di verificare la presenza di indirizzi IP disponibili nelle sottoreti. Prendi in considerazione i consigli su VPC e Subnet prima di implementare i cluster EKS.

Amazon VPC CNI alloca un pool di indirizzi IP caldi ENIs e secondari dalla sottorete collegata all'ENI primario del nodo. Questa modalità di VPC CNI è chiamata modalità IP secondaria. Il numero di indirizzi IP e quindi il numero di Pod (densità dei Pod) è definito dal numero di indirizzi IP ENIs e dall'indirizzo IP per ENI (limiti) definito dal tipo di istanza. La modalità secondaria è quella predefinita e funziona bene per piccoli cluster con tipi di istanze più piccoli. Prendi in considerazione l'utilizzo della modalità prefisso se riscontri problemi di densità dei pod. Puoi anche aumentare gli indirizzi IP disponibili sul nodo per i Pod assegnando prefissi a. ENIs

Amazon VPC CNI si integra nativamente con AWS VPC e consente agli utenti di applicare le best practice di rete e sicurezza AWS VPC esistenti per la creazione di cluster Kubernetes. Ciò include la possibilità di utilizzare log di flusso VPC, politiche di routing VPC e gruppi di sicurezza per l'isolamento del traffico di rete. Per impostazione predefinita, il CNI di Amazon VPC applica ai Pods il gruppo di sicurezza associato all'ENI primario sul nodo. Valuta la possibilità di abilitare i gruppi di sicurezza per i Pod quando desideri assegnare regole di rete diverse a un Pod.

Per impostazione predefinita, VPC CNI assegna gli indirizzi IP ai Pod dalla sottorete assegnata all'ENI primario di un nodo. È comune riscontrare una carenza di IPv4 indirizzi quando si gestiscono cluster di grandi dimensioni con migliaia di carichi di lavoro. AWS VPC consente di estendere la disponibilità IPs assegnando un secondario CIDRs per ovviare all'esaurimento dei blocchi CIDR. IPv4 AWS VPC CNI consente di utilizzare un intervallo CIDR di sottorete diverso per i pod. Questa funzionalità di VPC CNI si chiama rete personalizzata. Potresti prendere in considerazione l'utilizzo di reti personalizzate da utilizzare 100.64.0.0/10 e 198.19.0.0/16 CIDRs (CG-NAT) con EKS. In questo modo puoi creare efficacemente un ambiente in cui i Pod non consumano più alcun RFC1918 indirizzo IP dal tuo VPC.

La rete personalizzata è un'opzione per risolvere il problema dell'esaurimento degli IPv4 indirizzi, ma richiede un sovraccarico operativo. Per risolvere questo problema, consigliamo di utilizzare IPv6 cluster anziché reti personalizzate. In particolare, ti consigliamo di effettuare la migrazione ai IPv6 cluster se hai completamente esaurito tutto lo spazio di IPv4 indirizzi disponibile per il tuo VPC. Valuta i piani di supporto IPv6 della tua organizzazione e valuta se investire in qualcosa IPv6 possa avere più valore a lungo termine.

Il supporto di EKS IPv6 si concentra sulla risoluzione del problema dell'esaurimento dell'IP causato da uno spazio di IPv4 indirizzi limitato. In risposta ai problemi di IPv4 esaurimento dei clienti, EKS ha dato la priorità ai IPv6 soli pod rispetto ai pod dual-stack. Cioè, i Pod possono essere in grado di accedere alle IPv4 risorse, ma a loro non viene assegnato un IPv4 indirizzo dall'intervallo CIDR VPC. Il VPC CNI assegna IPv6 gli indirizzi ai pod dal blocco CIDR VPC gestito da AWS. IPv6

Calcolatore di sottorete

Questo progetto include un documento Excel di Subnet Calculator. Questo documento di calcolo simula il consumo di indirizzi IP di un carico di lavoro specifico in diverse opzioni di configurazione ENI, come e. WARM_IP_TARGET WARM_ENI_TARGET Il documento include due fogli, il primo per la modalità Warm ENI e il secondo per la modalità Warm IP. Consulta la guida VPC CNI per ulteriori informazioni su queste modalità.

Ingressi:

Uscite: