Posizionamento delle risorse in Nexus Kubernetes per operatori di Azure
Le istanze Nexus dell'operatore vengono distribuite nell'ambiente locale del cliente. Ogni istanza comprende uno o più rack di server bare metal.
Quando un utente crea un cluster Nexus Kubernetes (NKS), specifica un conteggio e un'unità di mantenimento delle scorte (SKU) per le macchine virtuali (VM) che costituiscono il piano di controllo Kubernetes e uno o più pool di agenti. I pool di agenti sono il set di nodi di lavoro in cui vengono eseguite le funzioni di rete in contenitori di un cliente.
La piattaforma Nexus è responsabile della decisione del server bare metal in cui viene avviata ogni macchina virtuale NKS.
Come la piattaforma Nexus pianifica una macchina virtuale del cluster Nexus Kubernetes
Nexus identifica innanzitutto il set di potenziali server bare metal che soddisfano tutti i requisiti delle risorse dello SKU della macchina virtuale NKS. Ad esempio, se l'utente ha specificato uno NC_G48_224_v1 SKU di macchina virtuale per il pool di agenti, Nexus raccoglie i server bare metal con capacità disponibile per 48 vCPU, 224Gi di RAM e così via.
Nexus esamina quindi il AvailabilityZones campo relativo al pool di agenti o al piano di controllo pianificato. Se questo campo non è vuoto, Nexus filtra l'elenco di potenziali server bare metal solo per tali server nelle zone di disponibilità specificate (rack). Questo comportamento è un vincolo di pianificazione rigido. Se nell'elenco filtrato non sono presenti server bare metal, Nexus non pianifica la macchina virtuale NKS e il cluster non esegue il provisioning.
Dopo che Nexus identifica un elenco di potenziali server bare metal su cui posizionare la macchina virtuale NKS, Nexus seleziona uno dei server bare metal dopo aver applicato le regole di ordinamento seguenti:
Preferisce server bare metal in zone di disponibilità (rack) che non dispongono di macchine virtuali NKS da questo cluster NKS. In altre parole, distribuire le macchine virtuali NKS per un cluster NKS tra zone di disponibilità.
Preferisce server bare metal all'interno di una singola zona di disponibilità (rack) che non hanno altre macchine virtuali NKS dello stesso cluster NKS. In altre parole, distribuire le macchine virtuali NKS per un cluster NKS tra server bare metal all'interno di una zona di disponibilità.
Se lo SKU della macchina virtuale NKS è
NC_G48_224_v1,NC_P46_224_v1NC_G56_224_v1oNC_P54_224_v1preferisce server bare metal che ospitanoNC_G48_224_v1già macchine virtuali ,NC_P46_224_v1NC_G56_224_v1oNC_P54_224_v1NKS da altri cluster NKS. In altre parole, raggruppare le macchine virtuali di grandi dimensioni di cluster NKS diversi negli stessi server bare metal. Questa regola "bin pack" le macchine virtuali di grandi dimensioni per ridurre la frammentazione delle risorse di calcolo disponibili.La regola "bin packaging" menzionata in precedenza si applica anche alle macchine virtuali più piccole oltre alle macchine virtuali di grandi dimensioni. Ciò consente di "comprimere" macchine virtuali più piccole di cluster diversi nelle stesse macchine baremetali, aumentando l'efficienza complessiva del posizionamento. Ad esempio, nodi del piano di controllo e nodi small-SKU (pool di agenti) da cluster diversi affine insieme.
Scenari di posizionamento di esempio
Le sezioni seguenti evidenziano il comportamento previsto dagli utenti di Nexus durante la creazione di cluster NKS in un ambiente Operator Nexus.
Suggerimento: è possibile vedere quale server bare metal sono state pianificate le macchine virtuali NKS esaminando la
nodes.bareMetalMachineIdproprietà della risorsa KubernetesCluster NKS o visualizzando la colonna "Host" nella visualizzazione dei nodi del cluster Kubernetes del portale di Azure.
L'ambiente Operator Nexus di esempio presenta queste specifiche:
- Otto rack di 16 server bare metal
- Ogni server bare metal contiene due celle NUMA (Non-Uniform Memory Access )
- Ogni cella NUMA fornisce 48 CPU e 224Gi RAM
Ambiente vuoto
Dato un ambiente Operator Nexus vuoto con la capacità specificata, vengono creati tre cluster Nexus Kubernetes di dimensioni diverse.
I cluster NKS hanno queste specifiche e si presuppone che ai fini di questo esercizio l'utente crei i tre cluster nell'ordine seguente:
Cluster A
- Piano di controllo,
NC_G12_56_v1SKU, tre conteggio - Pool di agenti n. 1,
NC_P46_224_v1SKU, 24 conteggio - Pool di agenti n. 2,
NC_G6_28_v1SKU, sei conteggio
Cluster B
- Piano di controllo,
NC_G24_112_v1SKU, cinque conteggio - Pool di agenti n. 1,
NC_P46_224_v1SKU, 48 conteggio - Pool di agenti n. 2,
NC_P22_112_v1SKU, 24 conteggio
Cluster C
- Piano di controllo,
NC_G12_56_v1SKU, tre conteggio - Pool di agenti n. 1,
NC_P46_224_v1SKU, 12 conteggio,AvailabilityZones = [1,4]
Ecco una tabella che riepiloga ciò che l'utente dovrebbe visualizzare dopo l'avvio di Cluster A, B e C in un ambiente Operator Nexus vuoto.
| Cluster | Pool | SKU | Conteggio totale | Rack # previsti | Rack # effettivi | Vm # previste per rack | Vm # effettive per rack |
|---|---|---|---|---|---|---|---|
| Un | Piano di controllo | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| Un | Pool di agenti n. 1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| Un | Pool di agenti n. 2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | Piano di controllo | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | Pool di agenti n. 1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| G | Pool di agenti n. 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | Piano di controllo | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | Pool di agenti n. 1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Ci sono otto rack, quindi le macchine virtuali per ogni pool vengono distribuite su un massimo di otto rack. I pool con più di otto macchine virtuali richiedono più macchine virtuali per rack distribuite tra server bare metal diversi.
Il pool di agenti C del cluster n. 1 ha 12 macchine virtuali limitate alle zone di disponibilità [1, 4] quindi ha 12 macchine virtuali su 12 server bare metal, sei in ognuno dei rack 1 e 4.
Le macchine virtuali extra-large ( NC_P46_224_v1 SKU) di cluster diversi vengono posizionate negli stessi server bare metal (vedere la regola 3 in Come la piattaforma Nexus pianifica una macchina virtuale del cluster Nexus Kubernetes).
Ecco una visualizzazione di un layout che l'utente potrebbe visualizzare dopo la distribuzione di cluster A, B e C in un ambiente vuoto.
Ambiente semi-completo
Viene ora eseguito un esempio di avvio di un altro cluster NKS quando l'ambiente di destinazione è pieno. L'ambiente di destinazione è metà completo dopo che i cluster A, B e C vengono distribuiti nell'ambiente di destinazione.
Il cluster D presenta le specifiche seguenti:
- Piano di controllo,
NC_G24_112_v1SKU, cinque conteggio - Pool di agenti n. 1,
NC_P46_224_v1SKU, 24 conteggio,AvailabilityZones = [7,8] - Pool di agenti n. 2,
NC_P22_112_v1SKU, 24 conteggio
Ecco una tabella che riepiloga ciò che l'utente dovrebbe vedere dopo l'avvio del cluster D nell'ambiente Operator Nexus half-full esistente dopo l'avvio di Cluster A, B e C.
| Cluster | Pool | SKU | Conteggio totale | Rack # previsti | Rack # effettivi | Vm # previste per rack | Vm # effettive per rack |
|---|---|---|---|---|---|---|---|
| D | Piano di controllo | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Pool di agenti n. 1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Pool di agenti n. 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
Il pool di agenti cluster D #1 ha 12 macchine virtuali limitate alle zone di disponibilità [7, 8] in modo da avere 12 macchine virtuali su 12 server bare metal, sei in ognuno dei rack 7 e 8. Tali macchine virtuali si usano su server bare metal che ospitano anche macchine virtuali di grandi dimensioni di altri cluster a causa della regola di ordinamento che raggruppa macchine virtuali di grandi dimensioni da cluster diversi negli stessi server bare metal.
Se una macchina virtuale del piano di controllo Cluster D raggiunge il rack 7 o 8, è probabile che una macchina virtuale cluster D Agent Pool n. 1 venga inserita nello stesso server bare metal della macchina virtuale del piano di controllo Cluster D. Questo comportamento è dovuto al fatto che il pool di agenti n. 1 è stato "aggiunto" ai rack 7 e 8. I vincoli di capacità in tali rack determinano l'collocazione di una macchina virtuale del piano di controllo e di una macchina virtuale pool di agenti #1 dallo stesso cluster NKS.
Il pool di agenti di Cluster D #2 include tre macchine virtuali in server bare metal diversi in ognuno dei otto rack. I vincoli di capacità derivano dal pool di agenti di Cluster D #1 aggiunto ai rack 7 e 8. Di conseguenza, le macchine virtuali del pool di agenti del cluster D #1 e il pool di agenti n. 2 vengono collocate negli stessi server bare metal nei rack 7 e 8.
Ecco una visualizzazione di un layout che l'utente potrebbe visualizzare dopo la distribuzione del cluster D nell'ambiente di destinazione.
Ambiente quasi completo
Nell'ambiente di destinazione di esempio, quattro degli otto rack sono vicini alla capacità. Si proverà ora ad avviare un altro cluster NKS.
Il cluster E presenta le specifiche seguenti:
- Piano di controllo,
NC_G24_112_v1SKU, cinque conteggio - Pool di agenti n. 1,
NC_P46_224_v1SKU, 32 conteggio
Ecco una tabella che riepiloga ciò che l'utente dovrebbe visualizzare dopo l'avvio del cluster E nell'ambiente di destinazione.
| Cluster | Pool | SKU | Conteggio totale | Rack # previsti | Rack # effettivi | Vm # previste per rack | Vm # effettive per rack |
|---|---|---|---|---|---|---|---|
| E | Piano di controllo | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Pool di agenti n. 1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 o 5 |
Il pool di agenti del cluster E n. 1 si distribuirà in modo non uniforme su tutti e otto i rack. I rack 7 e 8 avranno tre macchine virtuali NKS dal pool di agenti n. 1 invece delle quattro macchine virtuali NKS previste perché non esiste più capacità per le macchine virtuali SKU di grandi dimensioni in tali rack dopo la pianificazione dei cluster A tramite D. Poiché i rack 7 e 8 non hanno capacità per il quarto SKU extra-large nel pool di agenti n. 1, cinque macchine virtuali NKS verranno spostate sui due rack meno usati. In questo esempio, i rack meno utilizzati erano rack 3 e 6.
Ecco una visualizzazione di un layout che l'utente potrebbe visualizzare dopo la distribuzione del cluster E nell'ambiente di destinazione.
Posizionamento durante un aggiornamento di runtime
A partire da aprile 2024 (versione network cloud 2304.1), gli aggiornamenti di runtime vengono eseguiti usando una strategia rack-by-rack. I server bare metal nel rack 1 vengono ricreati contemporaneamente. Il processo di aggiornamento viene sospeso fino a quando tutti i server bare metal non vengono riavviati correttamente e indicano a Nexus che sono pronti per ricevere i carichi di lavoro.
Nota
È possibile indicare a Operator Nexus di eseguire l'immagine di una sola parte dei server bare metal in un rack contemporaneamente, ma l'impostazione predefinita consiste nel reimage di tutti i server bare metal in un rack in parallelo.
Quando viene ricreata l'immagine di un singolo server bare metal, tutti i carichi di lavoro in esecuzione in tale server bare metal, incluse tutte le macchine virtuali NKS, perdono alimentazione e connettività. I contenitori del carico di lavoro in esecuzione in macchine virtuali NKS a loro volta perderanno alimentazione e connettività. Dopo un minuto di non essere in grado di raggiungere tali contenitori del carico di lavoro, il piano di controllo Kubernetes del cluster NKS contrassegnerà i pod corrispondenti come non integri. Se i pod sono membri di una distribuzione o di un oggetto StatefulSet, il piano di controllo Kubernetes del cluster NKS tenta di avviare pod sostitutivi per riportare il conteggio delle repliche osservato del valore Deployment o StatefulSet al numero di repliche desiderato.
I nuovi pod vengono avvio solo se è disponibile capacità per il pod nelle macchine virtuali NKS integre rimanenti. A partire da aprile 2024 (versione network cloud 2304.1), le nuove macchine virtuali NKS non vengono create per sostituire le macchine virtuali NKS presenti nel server bare metal di cui viene ricreata l'immagine.
Una volta ricreata l'immagine del server bare metal e la possibilità di accettare nuove macchine virtuali NKS, le macchine virtuali NKS originariamente nello stesso server bare metal vengono riavviate nel server bare metal appena ricreato. I contenitori del carico di lavoro possono quindi essere pianificati in tali macchine virtuali NKS, ripristinando potenzialmente le distribuzioni o i set con stato che disponevano di pod in macchine virtuali NKS presenti nel server bare metal.
Nota
Questo comportamento può sembrare all'utente come se le macchine virtuali NKS non si spostassero dal server bare metal, quando in realtà una nuova istanza di una macchina virtuale NKS identica è stata avviata sul server bare metal appena ricreato che ha mantenuto lo stesso nome del server bare metal come prima della ricreazione dell'immagine.
Procedure consigliate
Quando si lavora con Operator Nexus, tenere presenti le procedure consigliate seguenti.
- Evitare di specificare per un pool di
AvailabilityZonesagenti. - Avviare cluster NKS più grandi prima di quelli più piccoli.
- Ridurre il numero di pool di agenti prima di ridurre le dimensioni dello SKU della macchina virtuale.
Evitare di specificare zone di disponibilità per un pool di agenti
Come si può capire dagli scenari di posizionamento precedenti, specificare AvailabilityZones per un pool di agenti è il motivo principale per cui le macchine virtuali NKS dello stesso cluster NKS finirebbero nello stesso server bare metal. Specificando AvailabilityZones, si "aggiunge" il pool di agenti a un subset di rack e quindi si limita il numero di potenziali server bare metal in tale set di rack per altri cluster NKS e altre macchine virtuali del pool di agenti nello stesso cluster NKS.
Pertanto, la prima procedura consigliata consiste nell'evitare di specificare AvailabilityZones per un pool di agenti. Se è necessario aggiungere un pool di agenti a un set di zone di disponibilità, impostarlo il più grande possibile per ridurre al minimo lo squilibrio che può verificarsi.
L'unica eccezione a questa procedura consigliata è quando si ha uno scenario con solo due o tre macchine virtuali in un pool di agenti. È consigliabile impostare AvailabilityZones il pool di agenti su [1,3,5,7] o [0,2,4,6] aumentare la disponibilità durante gli aggiornamenti di runtime.
Avviare cluster NKS più grandi prima di quelli più piccoli
A partire da aprile 2024 e dalla versione network cloud 2403.1, i cluster NKS vengono pianificati nell'ordine in cui vengono creati. Per comprimere in modo più efficiente l'ambiente di destinazione, è consigliabile creare cluster NKS più grandi prima di quelli più piccoli. Analogamente, è consigliabile pianificare pool di agenti più grandi prima di quelli più piccoli.
Questa raccomandazione è importante per i pool di agenti che usano lo SKU o NC_P46_224_v1 di dimensioni NC_G48_224_v1 aggiuntive. La pianificazione dei pool di agenti con il maggior numero di queste macchine virtuali SKU extra-large crea un set più ampio di server bare metal su cui possono essere collocate altre macchine virtuali SKU di grandi dimensioni dai pool di agenti in altri cluster NKS.
Ridurre il numero di pool di agenti prima di ridurre le dimensioni dello SKU della macchina virtuale
Se si verificano vincoli di capacità quando si avvia un cluster o un pool di agenti NKS, ridurre il numero del pool di agenti prima di modificare le dimensioni dello SKU della macchina virtuale. Ad esempio, se si tenta di creare un cluster NKS con un pool di agenti con le dimensioni dello SKU della NC_P46_224_v1 macchina virtuale e un conteggio di 24 e ottenere un errore di provisioning del cluster NKS a causa di risorse insufficienti, è possibile che si sia tentati di usare una DIMENSIONE SKU della macchina virtuale di NC_P36_168_v1 e continuare con un conteggio di 24. Tuttavia, a causa dei requisiti per le macchine virtuali del carico di lavoro da allineare a una singola cella NUMA in un server bare metal, è probabile che la stessa richiesta generi errori di risorse insufficienti simili. Invece di ridurre le dimensioni dello SKU della macchina virtuale, è consigliabile ridurre il numero di pool di agenti a 20. È possibile che la richiesta si adatti meglio alla capacità delle risorse dell'ambiente di destinazione e che la distribuzione complessiva abbia più core CPU che se è stato ridotto lo SKU della macchina virtuale.
SKU di macchine virtuali ottimizzate per la memoria
NC_E110_448_v1 (in esecuzione su nodi Hardware Zaffiro Rapids) o NC_E94_448_v1 utilizzare tutte le risorse disponibili dal cliente del computer fisico. NC_E70_336_v1 consumare il 75% delle risorse disponibili dal cliente, tuttavia, non è garantito che questa sarà esattamente una cella NUMA completa e una metà.
Ciò significa che un NC_G24_112_v1 può o non essere in grado di pianificare in un computer che esegue un NC_E70_336_v1 oggetto a seconda della pianificazione della NC_E70_336_v1 macchina virtuale tra le celle NUMA.