Resursplacering i Azure Operator Nexus Kubernetes
Operatörens Nexus-instanser distribueras i kundens lokaler. Varje instans består av ett eller flera rack med bare metal-servrar.
När en användare skapar ett Nexus Kubernetes-kluster (NKS) anger de ett antal och en lagerhållningsenhet (SKU) för virtuella datorer (VM) som utgör Kubernetes-kontrollplanet och en eller flera agentpooler. Agentpooler är den uppsättning arbetsnoder som en kunds containerbaserade nätverksfunktioner körs på.
Nexus-plattformen ansvarar för att bestämma vilken bare metal-server som varje virtuell NKS-dator ska startas på.
Så schemalägger Nexus-plattformen en virtuell Nexus Kubernetes-klusterdator
Nexus identifierar först den uppsättning potentiella bare metal-servrar som uppfyller alla resurskrav för NKS VM SKU. Om användaren till exempel har angett en NC_G48_224_v1 VM SKU för sin agentpool samlar Nexus in bare metal-servrarna som har tillgänglig kapacitet för 48 vCPU, 224Gi RAM osv.
Nexus undersöker sedan fältet AvailabilityZones för agentpoolen eller kontrollplanet som schemaläggs. Om det här fältet inte är tomt filtrerar Nexus listan över potentiella servrar utan operativsystem till endast de servrarna i de angivna tillgänglighetszonerna (rack). Det här beteendet är en begränsning för hård schemaläggning. Om det inte finns några bare metal-servrar i den filtrerade listan schemalägger Nexus inte den virtuella NKS-datorn och klustret kan inte etableras.
När Nexus identifierar en lista över potentiella bare metal-servrar som NKS VM ska placeras på, väljer Nexus sedan en av servrarna utan operativsystem efter att ha tillämpat följande sorteringsregler:
Föredrar bare metal-servrar i tillgänglighetszoner (rack) som inte har virtuella NKS-datorer från det här NKS-klustret. Sprid med andra ord de virtuella NKS-datorerna för ett NKS-kluster mellan tillgänglighetszoner.
Föredrar bare metal-servrar i en enda tillgänglighetszon (rack) som inte har andra virtuella NKS-datorer från samma NKS-kluster. Sprid med andra ord de virtuella NKS-datorerna för ett NKS-kluster över bare metal-servrar i en tillgänglighetszon.
Om NKS VM SKU är antingen
NC_G48_224_v1ellerNC_P46_224_v1föredrar du servrar utan operativsystem som redan harNC_G48_224_v1ellerNC_P46_224_v1NKS-virtuella datorer från andra NKS-kluster. Gruppera med andra ord de extra stora virtuella datorerna från olika NKS-kluster på samma bare metal-servrar. Den här regeln "bin packar" de extra stora virtuella datorerna för att minska fragmenteringen av tillgängliga beräkningsresurser.Regeln "bin packing" som nämns ovan gäller även för mindre virtuella datorer utöver stora virtuella datorer. Detta hjälper till att "packa" mindre virtuella datorer från olika kluster på samma baremetala datorer, vilket ökar den övergripande placeringseffektiviteten. Till exempel kontrollplansnoder och små SKU-noder (agentpool) från olika kluster affinerar tillsammans.
Exempel på placeringsscenarier
I följande avsnitt beskrivs det beteende som Nexus-användare bör förvänta sig när de skapar NKS-kluster mot en Operator Nexus-miljö.
Tips: Du kan se vilken bare metal-server dina virtuella NKS-datorer schemalades till genom att undersöka
nodes.bareMetalMachineIdegenskapen för NKS KubernetesCluster-resursen eller visa kolumnen "Värd" i Azure-portalens visning av Kubernetes-klusternoder.
Exempelmiljön för Operator Nexus har följande specifikationer:
- Åtta rack med 16 bare metal-servrar
- Varje bare metal-server innehåller två NUMA-celler (Non-Uniform Memory Access )
- Varje NUMA-cell ger 48 CPU- och 224Gi RAM-minne
Tom miljö
Med tanke på en tom Operator Nexus-miljö med den angivna kapaciteten skapar vi tre Nexus Kubernetes-kluster med olika storlek.
NKS-klustren har dessa specifikationer, och vi antar i den här övningen att användaren skapar de tre klustren i följande ordning:
Kluster A
- Kontrollplan,
NC_G12_56_v1SKU, tre antal - Agentpool nr 1,
NC_P46_224_v1SKU, 24 antal - Agentpool nr 2,
NC_G6_28_v1SKU, sex antal
Kluster B
- Kontrollplan,
NC_G24_112_v1SKU, fem antal - Agentpool nr 1,
NC_P46_224_v1SKU, 48 antal - Agentpool nr 2,
NC_P22_112_v1SKU, 24 antal
Kluster C
- Kontrollplan,
NC_G12_56_v1SKU, tre antal - Agentpool nr 1,
NC_P46_224_v1SKU, 12 antal,AvailabilityZones = [1,4]
Här är en tabell som sammanfattar vad användaren bör se när klustren A, B och C har startats i en tom Operator Nexus-miljö.
| Kluster | Pool | SKU | Totalt antal | Förväntade # Rack | Faktiska # rack | Förväntade # virtuella datorer per rack | Faktiska # virtuella datorer per rack |
|---|---|---|---|---|---|---|---|
| A | Kontrollplanet | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | Agentpool nr 1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | Agentpool nr 2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| F | Kontrollplanet | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| F | Agentpool nr 1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| F | Agentpool nr 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| L | Kontrollplanet | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | Agentpool nr 1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Det finns åtta rack så de virtuella datorerna för varje pool är spridda över upp till åtta rack. Pooler med fler än åtta virtuella datorer kräver flera virtuella datorer per rack fördelat på olika servrar utan operativsystem.
Kluster C-agentpool nr 1 har 12 virtuella datorer begränsade till AvailabilityZones [1, 4] så den har 12 virtuella datorer på 12 servrar utan operativsystem, sex i var och en av racken 1 och 4.
Extra stora virtuella datorer ( NC_P46_224_v1 SKU) från olika kluster placeras på samma servrar utan operativsystem (se regel 3 i Hur Nexus-plattformen schemalägger en virtuell Nexus Kubernetes-klusterdator).
Här är en visualisering av en layout som användaren kan se efter att ha distribuerat kluster A, B och C till en tom miljö.
Halvfull miljö
Nu går vi igenom ett exempel på hur du startar ett annat NKS-kluster när målmiljön är halvfull. Målmiljön är halvfull när kluster A, B och C har distribuerats till målmiljön.
Kluster D har följande specifikationer:
- Kontrollplan,
NC_G24_112_v1SKU, fem antal - Agentpool nr 1,
NC_P46_224_v1SKU, 24 antal,AvailabilityZones = [7,8] - Agentpool nr 2,
NC_P22_112_v1SKU, 24 antal
Här är en tabell som sammanfattar vad användaren bör se efter att ha startat kluster D i den halvfulla Operator Nexus-miljön som finns när kluster A, B och C har startats.
| Kluster | Pool | SKU | Totalt antal | Förväntade # Rack | Faktiska # rack | Förväntade # virtuella datorer per rack | Faktiska # virtuella datorer per rack |
|---|---|---|---|---|---|---|---|
| D | Kontrollplanet | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Agentpool nr 1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Agentpool nr 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
Kluster D-agentpool nr 1 har 12 virtuella datorer begränsade till AvailabilityZones [7, 8] så den har 12 virtuella datorer på 12 servrar utan operativsystem, sex i var och en av racken 7 och 8. Dessa virtuella datorer hamnar på bare metal-servrar som också rymmer extra stora virtuella datorer från andra kluster på grund av sorteringsregeln som grupperar extra stora virtuella datorer från olika kluster på samma servrar utan operativsystem.
Om en virtuell dator med kluster D-kontrollplan hamnar på rack 7 eller 8 är det troligt att en virtuell dator med kluster D-agentpool nr 1 hamnar på samma bare metal-server som den virtuella dator med kluster D-kontrollplanet. Det här beteendet beror på att agentpool nr 1 "fästs" på rack 7 och 8. Kapacitetsbegränsningar i dessa rack gör att schemaläggaren sorterar en virtuell dator med kontrollplan och en virtuell dator med agentpool nr 1 från samma NKS-kluster.
Kluster D:s agentpool nr 2 har tre virtuella datorer på olika bare metal-servrar på vart och ett av de åtta racken. Kapacitetsbegränsningarna berodde på att Kluster D:s agentpool nr 1 fästs på rack 7 och 8. Därför är virtuella datorer från kluster D:s agentpool nr 1 och agentpool nr 2 sorterade på samma bare metal-servrar i rack 7 och 8.
Här är en visualisering av en layout som användaren kan se efter att ha distribuerat kluster D till målmiljön.
Nästan fullständig miljö
I vår exempelmålmiljö är fyra av de åtta racken nära kapacitet. Nu ska vi försöka starta ett annat NKS-kluster.
Kluster E har följande specifikationer:
- Kontrollplan,
NC_G24_112_v1SKU, fem antal - Agentpool nr 1,
NC_P46_224_v1SKU, 32 antal
Här är en tabell som sammanfattar vad användaren bör se när kluster E har startats i målmiljön.
| Kluster | Pool | SKU | Totalt antal | Förväntade # Rack | Faktiska # rack | Förväntade # virtuella datorer per rack | Faktiska # virtuella datorer per rack |
|---|---|---|---|---|---|---|---|
| E | Kontrollplanet | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Agentpool nr 1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 eller 5 |
Kluster E:s agentpool nr 1 sprids ojämnt över alla åtta rack. Rack 7 och 8 har tre virtuella NKS-datorer från agentpool nr 1 i stället för de förväntade fyra virtuella NKS-datorerna eftersom det inte finns mer kapacitet för de extra stora virtuella SKU-datorerna i dessa rack efter schemaläggning av kluster A till D. Eftersom rack 7 och 8 inte har kapacitet för den fjärde extra stora SKU:n i agentpool nr 1 hamnar fem virtuella NKS-datorer på de två minst använda racken. I vårt exempel var dessa rack med minst användning rack 3 och 6.
Här är en visualisering av en layout som användaren kan se efter att ha distribuerat kluster E till målmiljön.
Placering under en körningsuppgradering
Från och med april 2024 (Network Cloud 2304.1-versionen) utförs körningsuppgraderingar med hjälp av en rack-by-rack-strategi. Bare metal-servrar i rack 1 återskapas på samma gång. Uppgraderingsprocessen pausas tills alla servrar utan operativsystem startar om och meddelar Nexus att de är redo att ta emot arbetsbelastningar.
Kommentar
Det är möjligt att instruera Operator Nexus att endast återskapa en del av bare metal-servrarna i ett rack samtidigt, men standardvärdet är att återskapa alla bare metal-servrar i ett rack parallellt.
När en enskild bare metal-server har återskapats förlorar alla arbetsbelastningar som körs på den bare metal-servern, inklusive alla virtuella NKS-datorer, ström och anslutning. Arbetsbelastningscontainrar som körs på virtuella NKS-datorer förlorar i sin tur ström och anslutning. Efter en minut efter att NKS-klustrets Kubernetes-kontrollplan inte kan nå dessa arbetsbelastningscontainrar markeras motsvarande poddar som felaktiga. Om poddarna är medlemmar i en distribution eller StatefulSet försöker NKS-klustrets Kubernetes-kontrollplan starta ersättningspoddar för att få tillbaka det observerade replikantalet för distributionen eller StatefulSet till önskat replikantal.
Nya poddar startas bara om det finns tillgänglig kapacitet för podden på de återstående felfria virtuella NKS-datorerna. Från och med april 2024 (Network Cloud 2304.1-versionen) skapas inte nya virtuella NKS-datorer för att ersätta virtuella NKS-datorer som fanns på den bare metal-server som återskapades.
När bare metal-servern har återskapats och kan acceptera nya virtuella NKS-datorer återlanseras de virtuella NKS-datorerna som ursprungligen fanns på samma bare metal-server på den nyligen omskapade bare metal-servern. Arbetsbelastningscontainrar kan sedan schemaläggas till de virtuella NKS-datorerna, vilket kan återställa distributioner eller StatefulSets som hade poddar på virtuella NKS-datorer som fanns på bare metal-servern.
Kommentar
Det här beteendet kan tyckas för användaren som om de virtuella NKS-datorerna inte "flyttades" från bare metal-servern, när i själva verket en ny instans av en identisk virtuell NKS-dator startades på den nyligen omskapade bare metal-servern som behöll samma namn på bare metal-servern som innan den återskapades.
Bästa praxis
Tänk på följande metodtips när du arbetar med Operator Nexus.
- Undvik att
AvailabilityZonesange för en agentpool. - Starta större NKS-kluster före mindre.
- Minska antalet agentpooler innan du minskar storleken på vm-SKU:n.
Undvik att ange AvailabilityZones för en agentpool
Som du kan se från ovanstående placeringsscenarier är det AvailabilityZones den främsta orsaken till att NKS-virtuella datorer från samma NKS-kluster hamnar på samma bare metal-server. Genom att AvailabilityZonesange "fäster" du agentpoolen på en delmängd rack och begränsar därför antalet potentiella bare metal-servrar i den uppsättningen rack för andra NKS-kluster och andra virtuella agentpooldatorer i samma NKS-kluster att landa på.
Därför är vår första metod att undvika att ange AvailabilityZones för en agentpool. Om du behöver fästa en agentpool på en uppsättning Tillgänglighetszoner gör du den så stor som möjligt för att minimera den obalans som kan uppstå.
Ett undantag till den här bästa metoden är när du har ett scenario med bara två eller tre virtuella datorer i en agentpool. Du kan överväga att ange AvailabilityZones för agentpoolen till [1,3,5,7] eller [0,2,4,6] öka tillgängligheten under körningsuppgraderingar.
Starta större NKS-kluster före mindre
Från och med april 2024 och network cloud 2403.1-versionen schemaläggs NKS-kluster i den ordning de skapas. För att effektivt paketera målmiljön rekommenderar vi att du skapar större NKS-kluster före mindre. På samma sätt rekommenderar vi att du schemalägger större agentpooler före mindre.
Den här rekommendationen är viktig för agentpooler med hjälp av den extra stora NC_G48_224_v1 eller NC_P46_224_v1 SKU:n. Om du schemalägger agentpoolerna med störst antal extra stora virtuella SKU-datorer skapas en större uppsättning bare metal-servrar där andra extra stora virtuella SKU-datorer från agentpooler i andra NKS-kluster kan samverka.
Minska antalet agentpooler innan du minskar storleken på vm-SKU:n
Om du stöter på kapacitetsbegränsningar när du startar ett NKS-kluster eller en agentpool minskar du antalet agentpooler innan du justerar storleken på den virtuella datorns SKU. Om du till exempel försöker skapa ett NKS-kluster med en agentpool med VM SKU-storleken NC_P46_224_v1 och antalet 24 och får tillbaka ett misslyckande med att etablera NKS-klustret på grund av otillräckliga resurser, kan du frestas att använda en VM SKU-storlek på NC_P36_168_v1 och fortsätta med antalet 24. På grund av kraven för att arbetsbelastningens virtuella datorer ska justeras till en enskild NUMA-cell på en bare metal-server är det troligt att samma begäran resulterar i liknande otillräckliga resursfel. I stället för att minska storleken på den virtuella datorns SKU kan du överväga att minska antalet agentpooler till 20. Det finns en bättre chans att din begäran passar in i målmiljöns resurskapacitet och den övergripande distributionen har fler CPU-kärnor än om du har minskat den virtuella datorns SKU.
Minnesoptimerade VM-SKU:er
NC_E94_448_v1 förbrukar alla kundtillgängliga resurser på den fysiska datorn. NC_E70_336_v1 förbrukar 75 % av de kundtillgängliga resurserna är det dock inte utspädt att detta kommer att vara exakt en och en halv NUMA-celler. Det innebär att en NC_G24_112_v1 kanske inte kan schemaläggas på en dator som kör en NC_E70_336_v1 beroende på hur den NC_E70_336_v1 virtuella datorn schemaläggs i NUMA-cellerna.