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

Modalità prefisso per Windows

In Amazon EKS, per impostazione predefinita, a ogni Pod eseguito su un host Windows viene assegnato un indirizzo IP secondario dal controller di risorse VPC. Questo indirizzo IP è un VPC-routable indirizzo allocato dalla sottorete dell'host. Su Linux, ogni ENI collegato all'istanza ha più slot che possono essere popolati da un indirizzo IP secondario o da un CIDR /28 (un prefisso). Gli host Windows, tuttavia, supportano solo un singolo ENI e i relativi slot disponibili. L'utilizzo solo di indirizzi IP secondari può limitare artificialmente il numero di pod che è possibile eseguire su un host Windows, anche quando sono disponibili numerosi indirizzi IP per l'assegnazione.

Per aumentare la densità dei pod sugli host Windows, specialmente quando si utilizzano tipi di istanza più piccoli, è possibile abilitare la delega dei prefissi per i nodi Windows. Quando la delega dei prefissi è abilitata, i prefissi IPv4 /28 vengono assegnati agli slot ENI anziché agli indirizzi IP secondari. La delega dei prefissi può essere abilitata aggiungendo la voce alla mappa di configurazione. enable-windows-prefix-delegation: "true" amazon-vpc-cni Questa è la stessa mappa di configurazione in cui è necessario impostare la enable-windows-ipam: "true" voce per abilitare il supporto di Windows.

Segui le istruzioni menzionate nella guida per l'utente di EKS per abilitare la modalità Prefix Delegation per i nodi Windows.

Figura: confronto tra la modalità IP secondaria e la modalità Prefix Delegation

Il numero massimo di indirizzi IP che è possibile assegnare a un'interfaccia di rete dipende dal tipo di istanza e dalla sua dimensione. Ogni prefisso assegnato a un'interfaccia di rete consuma uno slot disponibile. Ad esempio, un'c5.largeistanza ha un limite di 10 slot per interfaccia di rete. Il primo slot di un'interfaccia di rete viene sempre occupato dall'indirizzo IP primario dell'interfaccia, lasciando 9 slot per i prefissi e gli indirizzi IP and/or secondari. Se a questi slot vengono assegnati dei prefissi, il nodo può supportare (9 * 16) 144 indirizzi IP mentre se vengono assegnati indirizzi IP secondari può supportare solo 9 indirizzi IP. Per ulteriori informazioni, consulta la documentazione sugli indirizzi IP per interfaccia di rete per tipo di istanza e sull'assegnazione dei prefissi alle interfacce di rete.

Durante l'inizializzazione del nodo di lavoro, il VPC Resource Controller assegna uno o più prefissi all'ENI primario per velocizzare l'avvio del pod mantenendo un pool caldo di indirizzi IP. Il numero di prefissi da conservare nel warm pool può essere controllato impostando i seguenti parametri di configurazione in config map. amazon-vpc-cni

Man mano che sono programmati altri Pod sul nodo, verranno richiesti prefissi aggiuntivi per l'ENI esistente. Quando un Pod è pianificato sul nodo, VPC Resource Controller proverà innanzitutto ad assegnare un indirizzo IPv4 dai prefissi esistenti sul nodo. Se ciò non è possibile, verrà richiesto un nuovo prefisso IPv4 purché la sottorete abbia la capacità richiesta.

Figura: Flusso di lavoro durante l'assegnazione dell'indirizzo IPv4 al Pod

Raccomandazioni

Usa Prefix Delegation quando

Usa la delega del prefisso se riscontri problemi di densità dei pod sui nodi di lavoro. Per evitare errori, consigliamo di esaminare le sottoreti alla ricerca di blocchi contigui di indirizzi per il prefisso /28 prima di migrare alla modalità prefisso. Per i dettagli sulle prenotazioni delle sottoreti, consulta la sezione "Utilizza le prenotazioni delle sottoreti per evitare la frammentazione delle sottoreti (IPv4)».

Per impostazione predefinita, i nodi su Windows sono impostati max-pods su. 110 Per la maggior parte dei tipi di istanza, questo dovrebbe essere sufficiente. Se desideri aumentare o diminuire questo limite, aggiungi quanto segue al comando bootstrap nei tuoi dati utente:

-KubeletExtraArgs '--max-pods=example-value'

Per maggiori dettagli sui parametri di configurazione bootstrap per i nodi Windows, consulta la documentazione qui.

Evita la delega del prefisso quando

Se la sottorete è molto frammentata e non dispone di indirizzi IP disponibili per creare prefissi /28, evita di utilizzare la modalità prefisso. L'allegato del prefisso può avere esito negativo se la sottorete da cui viene prodotto il prefisso è frammentata (una sottorete molto utilizzata con indirizzi IP secondari sparsi). Questo problema può essere evitato creando una nuova sottorete e riservando un prefisso.

Configura i parametri per la delega dei prefissi per conservare gli indirizzi IPv4

warm-prefix-targetwarm-ip-target, e minimum-ip-target può essere utilizzato per ottimizzare il comportamento del pre-scaling e del ridimensionamento dinamico con prefissi. Per impostazione predefinita, vengono utilizzati i seguenti valori:

warm-ip-target: "1"
minimum-ip-target: "3"

Regolando con precisione questi parametri di configurazione, è possibile ottenere un equilibrio ottimale tra la conservazione degli indirizzi IP e la riduzione della latenza del Pod dovuta all'assegnazione dell'indirizzo IP. Per ulteriori informazioni su questi parametri di configurazione, consulta la documentazione qui. https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md

Utilizzate le prenotazioni di sottorete per evitare la frammentazione della sottorete (IPv4)

Quando EC2 assegna un prefisso IPv4 /28 a un ENI, deve trattarsi di un blocco contiguo di indirizzi IP della sottorete. Se la sottorete da cui viene generato il prefisso è frammentata (una sottorete molto utilizzata con indirizzi IP secondari sparsi), l'allegato del prefisso potrebbe fallire e verrà visualizzato il seguente evento di nodo:

InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

Per evitare la frammentazione e disporre di spazio contiguo sufficiente per la creazione dei prefissi, utilizzate le prenotazioni CIDR della sottorete VPC per riservare lo spazio IP all'interno di una sottorete per l'uso esclusivo dei prefissi. Una volta creata una prenotazione, gli indirizzi IP dei blocchi riservati non verranno assegnati ad altre risorse. In questo modo, VPC Resource Controller sarà in grado di ottenere i prefissi disponibili durante la chiamata di assegnazione al nodo ENI.

Si consiglia di creare una nuova sottorete, riservare spazio per i prefissi e abilitare l'assegnazione dei prefissi per i nodi di lavoro in esecuzione in quella sottorete. Se la nuova sottorete è dedicata solo ai pod in esecuzione nel cluster EKS con la delega dei prefissi abilitata, puoi saltare la fase di prenotazione del prefisso.

Sostituisci tutti i nodi durante la migrazione dalla modalità IP secondaria alla modalità Prefix Delegation o viceversa

Si consiglia vivamente di creare nuovi gruppi di nodi per aumentare il numero di indirizzi IP disponibili anziché eseguire la sostituzione progressiva dei nodi di lavoro esistenti.

Quando si utilizzano gruppi di nodi autogestiti, i passaggi per la transizione sarebbero:

Quando si utilizzano gruppi di nodi gestiti, i passaggi per la transizione sarebbero:

Per Windows, ti consigliamo di evitare di eseguire i Pods contemporaneamente in modalità IP secondaria e in modalità di delega dei prefissi. Una situazione del genere può verificarsi quando si esegue la migrazione dalla modalità IP secondaria alla modalità di delega dei prefissi o viceversa con carichi di lavoro Windows in esecuzione.

Sebbene ciò non influisca sui Pod in esecuzione, potrebbero esserci incoerenze rispetto alla capacità degli indirizzi IP del nodo. Ad esempio, consideriamo un nodo t3.xlarge con 14 slot per indirizzi IPv4 secondari. Se utilizzi 10 Pod, 10 slot sull'ENI verranno occupati da indirizzi IP secondari. Dopo aver abilitato la delega del prefisso, la capacità annunciata al server kube-api sarebbe (14 slot * 16 indirizzi IP per prefisso) 244 ma la capacità effettiva in quel momento sarebbe (4 slot rimanenti * 16 indirizzi per prefisso) 64. Questa incoerenza tra la quantità di capacità pubblicizzata e la quantità effettiva di capacità (slot rimanenti) può causare problemi se si utilizzano più Pod rispetto agli indirizzi IP disponibili per l'assegnazione.

Detto questo, puoi utilizzare la strategia di migrazione descritta sopra per trasferire in sicurezza i tuoi Pod dall'indirizzo IP secondario agli indirizzi ottenuti dai prefissi. Passando da una modalità all'altra, i Pod continueranno a funzionare normalmente e:

Problemi di debug con la delega dei prefissi

Puoi utilizzare la nostra guida al debug qui per approfondire il problema che stai riscontrando con la delega dei prefissi su Windows.