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. La rete pod, chiamata anche rete cluster, è il centro del networking Kubernetes. Kubernetes supporta i plugin Container Network Interface (CNI) per il networking in cluster.

Amazon EKS supporta ufficialmente il plug-in CNI Amazon Virtual Private Cloud (VPC) per implementare la rete Kubernetes Pod. Il VPC CNI fornisce un'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 introduce 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 ai diversi casi d'uso, modalità operative e sottocomponenti di VPC CNI, seguite dai consigli.

Amazon EKS esegue Kubernetes a monte ed è certificato conforme a Kubernetes. Sebbene sia possibile utilizzare plug-in 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 il networking in 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 i namespace di 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 plug-in per configurare le interfacce di rete in contenitori, insieme a una serie di plug-in 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 è abilitato passando a kubelet l'opzione della riga di comando. --network-plugin=cni Kubelet legge un file da --cni-conf-dir (defaultetc/cni/net.d) e utilizza la configurazione CNI di quel file per configurare la rete di ogni Pod. Il file di configurazione CNI deve corrispondere alle specifiche CNI (versione minima 0.4.0) e tutti i plugin CNI richiesti a cui fa riferimento la configurazione devono essere presenti nella directory (impostazione predefinita//bin). --cni-bin-dir opt/cni Se nella directory sono presenti più file di configurazione CNI, il kubelet utilizza il file di configurazione che viene prima 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. L'add-on VPC CNI viene installato di default quando si eseguono il provisioning dei cluster EKS. VPC CNI viene eseguito su nodi di lavoro Kubernetes. L'add-on 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 (ENI) a ciascun nodo Kubernetes e mantiene il pool caldo di IP. Il VPC CNI offre opzioni di configurazione per la preallocazione di ENI e indirizzi IP per tempi di avvio rapidi del Pod. Fai riferimento ad 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 assegna gli indirizzi IP ai Pods dalle sottoreti del nodo. Consigliamo vivamente di controllare le sottoreti per gli indirizzi IP disponibili. Prima di implementare i cluster EKS, ti consigliamo di prendere in considerazione le raccomandazioni relative a VPC e Subnet.

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 è denominata modalità IP secondaria. CNI di Amazon VPC Il numero di indirizzi IP e quindi il numero di Pod (densità 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 istanza 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 Pods 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 i log di flusso VPC, le politiche di routing VPC e i gruppi di sicurezza per l'isolamento del traffico di rete. Per impostazione predefinita, Amazon VPC CNI applica il gruppo di sicurezza associato all'ENI primario sul nodo ai Pods. Valuta la possibilità di abilitare i gruppi di sicurezza per i Pods quando desideri assegnare regole di rete diverse per 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. Rete personalizzata Potresti prendere in considerazione l'utilizzo di una rete personalizzata con un CIDR compreso nell'100.64.0.0/10intervallo (spazio di indirizzi condiviso, RFC 6598) per EKS. Ciò consente efficacemente di creare un ambiente in cui i Pods non consumino più alcun indirizzo IP RFC1918 dal tuo 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 i cluster IPv6 rispetto alle reti personalizzate. In particolare, ti consigliamo di migrare ai cluster IPv6 se hai esaurito completamente 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 nell'IPv6 potrebbe avere più valore a lungo termine.

Il supporto di EKS per IPv6 si concentra sulla risoluzione del problema dell'esaurimento degli indirizzi 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 In altre parole, i Pod possono accedere alle risorse IPv4, ma a loro non viene assegnato un indirizzo IPv4 compreso nell'intervallo CIDR di VPC. Il VPC CNI assegna gli indirizzi IPv6 ai Pods dal blocco CIDR VPC IPv6 gestito da AWS.

Calcolatore delle sottoreti

Questo progetto include un documento Excel di Subnet Calculator. 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 Il documento include due fogli, un primo per la modalità Warm ENI e un secondo per la modalità Warm IP. Consulta le linee guida CNI di VPC per ulteriori informazioni su queste modalità.

Ingressi:

Uscite: