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 migliori pratiche per il networking

È fondamentale comprendere il networking Kubernetes per gestire il cluster e le applicazioni in modo efficiente. 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 di CNI alternativi. Consulta la documentazione EKS Alternate CNI per un elenco di partner e risorse per gestire efficacemente i CNI alternativi.

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 usa la configurazione CNI da quel file per configurare la rete di ogni Pod. Il file di configurazione CNI deve corrispondere alle specifiche CNI (minimo v0.4.0) e tutti i plugin CNI richiesti a cui fa riferimento la configurazione devono essere presenti nella directory (default//bin). --cni-bin-dir opt/cni 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 AWS-provided VPC CNI è 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. L'ipamd gestisce AWS Elastic Networking Interfaces (ENIS) su ogni nodo Kubernetes e mantiene il pool di IP caldi. Il VPC CNI offre opzioni di configurazione per la preallocazione di ENI e 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 caldo di ENI e indirizzi IP 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 ENI e dall'indirizzo IP per ENI (limiti), come 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 agli ENI.

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 indirizzi IPv4 quando si eseguono cluster di grandi dimensioni con migliaia di carichi di lavoro. AWS VPC consente di estendere gli IP disponibili assegnando un CIDR secondario 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 100.64.0.0/10 e 198.19.0.0/16 CIDR () CG-NAT con EKS. Ciò consente in modo efficace di creare un ambiente in cui i Pod non consumano più alcun indirizzo IP RFC1918 dal VPC.

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

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

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: