Umieszczanie zasobów w usłudze Azure Operator Nexus Kubernetes

Wystąpienia operatora Nexus są wdrażane w środowisku klienta. Każde wystąpienie składa się z co najmniej jednego stojaka serwerów bez systemu operacyjnego.

Gdy użytkownik tworzy klaster Kubernetes Nexus (NKS), określa liczbę i jednostkę magazynową (SKU) dla maszyn wirtualnych tworzących płaszczyznę sterowania Kubernetes i co najmniej jedną pulę agentów. Pule agentów to zestaw węzłów roboczych, na których są uruchamiane konteneryzowane funkcje sieciowe klienta.

Platforma Nexus jest odpowiedzialna za podjęcie decyzji o serwerze bez systemu operacyjnego, na którym uruchamia się każda maszyna wirtualna NKS.

Jak platforma Nexus planuje maszynę wirtualną klastra Kubernetes Nexus

Nexus najpierw identyfikuje zestaw potencjalnych serwerów bez systemu operacyjnego, które spełniają wszystkie wymagania dotyczące zasobów jednostki SKU maszyny wirtualnej NKS. Jeśli na przykład użytkownik określił NC_G48_224_v1 jednostkę SKU maszyny wirtualnej dla puli agentów, Nexus zbiera serwery bez systemu operacyjnego, które mają dostępną pojemność dla 48 procesorów wirtualnych, 224Gi pamięci RAM itp.

Nexus następnie sprawdza AvailabilityZones pole dla zaplanowanej puli agentów lub płaszczyzny sterowania. Jeśli to pole nie jest puste, Nexus filtruje listę potencjalnych serwerów bez systemu operacyjnego tylko do tych serwerów w określonych strefach dostępności (stojaki). To zachowanie jest twardym ograniczeniem planowania. Jeśli na liście filtrowanej nie ma serwerów bez systemu operacyjnego, nexus nie planuje aprowizacji maszyny wirtualnej NKS i klaster nie może aprowizować.

Gdy Nexus zidentyfikuje listę potencjalnych serwerów bez systemu operacyjnego, na których można umieścić maszynę wirtualną NKS, Nexus wybiera jeden z serwerów bez systemu operacyjnego po zastosowaniu następujących reguł sortowania:

1. Preferuj serwery bez systemu operacyjnego w strefach dostępności (stojakach), które nie mają maszyn wirtualnych NKS z tego klastra NKS. Innymi słowy, rozłóż maszyny wirtualne NKS dla klastra NKS w różnych strefach dostępności.

2. Preferuj serwery bez systemu operacyjnego w jednej strefie dostępności (stojaku), które nie mają innych maszyn wirtualnych NKS z tego samego klastra NKS. Innymi słowy, rozłóż maszyny wirtualne NKS dla klastra NKS na serwery bez systemu operacyjnego w strefie dostępności.

3. Jeśli jednostka SKU maszyny wirtualnej NKS jest albo NC_G48_224_v1 lub NC_P46_224_v1, preferuj serwery bez systemu operacyjnego, które już znajdują NC_G48_224_v1 się lub NC_P46_224_v1 maszyny wirtualne NKS z innych klastrów NKS. Innymi słowy, grupuj dodatkowe duże maszyny wirtualne z różnych klastrów NKS na tych samych serwerach bez systemu operacyjnego. Ta reguła "bin pakuje" dodatkowe duże maszyny wirtualne w celu zmniejszenia fragmentacji dostępnych zasobów obliczeniowych.

Przykładowe scenariusze umieszczania

W poniższych sekcjach opisano zachowanie, którego użytkownicy Nexus powinni oczekiwać podczas tworzenia klastrów NKS w środowisku Operator Nexus.

Wskazówka: Możesz sprawdzić, na którym serwerze bez systemu operacyjnego zaplanowano maszyny wirtualne NKS, sprawdzając właściwość zasobu NKS KubernetesCluster lub wyświetlając nodes.bareMetalMachineId kolumnę "Host" w witrynie Azure Portal dla węzłów klastra Kubernetes.

Przykładowe środowisko Operator Nexus ma następujące specyfikacje:

• Osiem stojaków z 16 bez systemu operacyjnego
• Każdy serwer bez systemu operacyjnego zawiera dwie komórki nieumundurowego dostępu do pamięci (NUMA)
• Każda komórka NUMA zapewnia 48 procesorów CPU i 224Gi pamięci RAM

Puste środowisko

Biorąc pod uwagę puste środowisko Operator Nexus z daną pojemnością, tworzymy trzy różne rozmiary klastrów Nexus Kubernetes.

Klastry NKS mają te specyfikacje i zakładamy, że na potrzeby tego ćwiczenia użytkownik tworzy trzy klastry w następującej kolejności:

Klaster A

• Płaszczyzna sterowania, NC_G12_56_v1 jednostka SKU, trzy liczby
• Pula agentów nr 1, NC_P46_224_v1 jednostka SKU, 24 liczba
• Pula agentów nr 2, NC_G6_28_v1 jednostka SKU, sześć liczb

Klaster B

• Płaszczyzna sterowania, NC_G24_112_v1 jednostka SKU, pięć
• Pula agentów nr 1, NC_P46_224_v1 jednostka SKU, 48 liczba
• Pula agentów nr 2, NC_P22_112_v1 jednostka SKU, 24 liczba

Klaster C

• Płaszczyzna sterowania, NC_G12_56_v1 jednostka SKU, trzy liczby
• Pula agentów nr 1, NC_P46_224_v1 jednostka SKU, 12 liczba, AvailabilityZones = [1,4]

Oto tabela podsumowująca, co użytkownik powinien zobaczyć po uruchomieniu klastrów A, B i C w pustym środowisku Operator Nexus.

Klaster	Pula	SKU	Łączna liczba	Oczekiwano # stojaki	Rzeczywiste regały #	Oczekiwano # maszyn wirtualnych na stojak	Rzeczywista liczba maszyn wirtualnych na stojak
A	Płaszczyzna sterowania	NC_G12_56_v1	3	3	3	1	1
A	Pula agentów nr 1	NC_P46_224_v1	24	8	8	3	3
A	Pula agentów 2	NC_G6_28_v1	6	6	6	1	1
B	Płaszczyzna sterowania	NC_G24_112_v1	5	5	5	1	1
B	Pula agentów nr 1	NC_P46_224_v1	48	8	8	6	6
B	Pula agentów 2	NC_P22_112_v1	24	8	8	3	3
C	Płaszczyzna sterowania	NC_G12_56_v1	3	3	3	1	1
C	Pula agentów nr 1	NC_P46_224_v1	12	2	2	6	6

Istnieje osiem stojaków, więc maszyny wirtualne dla każdej puli są rozłożone na maksymalnie osiem stojaków. Pule z ponad ośmioma maszynami wirtualnymi wymagają wielu maszyn wirtualnych na stojak rozłożone na różne serwery bez systemu operacyjnego.

Pula agentów klastra C #1 ma 12 maszyn wirtualnych ograniczonych do stref dostępności [1, 4], więc ma 12 maszyn wirtualnych na 12 serwerach bez systemu operacyjnego, sześć w każdym stojaku 1 i 4.

Dodatkowe duże maszyny wirtualne ( NC_P46_224_v1 jednostka SKU) z różnych klastrów są umieszczane na tych samych serwerach bez systemu operacyjnego (zobacz regułę nr 3 w temacie Jak platforma Nexus planuje maszynę wirtualną klastra Nexus Kubernetes).

Oto wizualizacja układu, który użytkownik może zobaczyć po wdrożeniu klastrów A, B i C w pustym środowisku.

Półupełnie środowisko

Teraz przechodzimy przez przykład uruchamiania innego klastra NKS, gdy środowisko docelowe jest w połowie pełne. Środowisko docelowe jest w połowie pełne po wdrożeniu klastrów A, B i C w środowisku docelowym.

Klaster D ma następujące specyfikacje:

• Płaszczyzna sterowania, NC_G24_112_v1 jednostka SKU, pięć
• Pula agentów nr 1, NC_P46_224_v1 jednostka SKU, 24 liczba, AvailabilityZones = [7,8]
• Pula agentów nr 2, NC_P22_112_v1 jednostka SKU, 24 liczba

Poniżej przedstawiono tabelę podsumowującą, co użytkownik powinien zobaczyć po uruchomieniu klastra D w połowie pełnego środowiska Operator Nexus, które istnieje po uruchomieniu klastrów A, B i C.

Klaster	Pula	SKU	Łączna liczba	Oczekiwano # stojaki	Rzeczywiste regały #	Oczekiwano # maszyn wirtualnych na stojak	Rzeczywista liczba maszyn wirtualnych na stojak
D	Płaszczyzna sterowania	NC_G12_56_v1	5	5	5	1	1
D	Pula agentów nr 1	NC_P46_224_v1	24	2	2	12	12
D	Pula agentów 2	NC_P22_112_v1	24	8	8	3	3

Pula agentów klastra D #1 ma 12 maszyn wirtualnych ograniczonych do stref dostępności [7, 8], więc ma 12 maszyn wirtualnych na 12 serwerach bez systemu operacyjnego, sześć w każdym stojaku 7 i 8. Te maszyny wirtualne znajdują się na serwerach bez systemu operacyjnego, które również mają dodatkowe duże maszyny wirtualne z innych klastrów ze względu na regułę sortowania, która grupuje dodatkowe duże maszyny wirtualne z różnych klastrów na te same serwery bez systemu operacyjnego.

Jeśli maszyna wirtualna płaszczyzny sterowania klastra D znajduje się na stojaku 7 lub 8, prawdopodobnie jedna maszyna wirtualna klastra D Agent Pool #1 znajduje się na tym samym serwerze bez systemu operacyjnego co ta maszyna wirtualna płaszczyzny sterowania klastra D. To zachowanie jest spowodowane tym, że pula agentów #1 jest "przypięta" do stojaków 7 i 8. Ograniczenia pojemności w tych stojakach powodują, że harmonogram będzie kolidować maszynę wirtualną płaszczyzny sterowania i pulę agentów #1 z tego samego klastra NKS.

Pula agentów klastra D nr 2 ma trzy maszyny wirtualne na różnych serwerach bez systemu operacyjnego na każdym z ośmiu stojaków. Ograniczenia pojemności wynikały z przypiętej puli agentów klastra D nr 1 do stojaków 7 i 8. W związku z tym maszyny wirtualne z puli agentów klastra D #1 i puli agentów #2 są sortowane na tych samych serwerach bez systemu operacyjnego w stojakach 7 i 8.

Oto wizualizacja układu, który użytkownik może zobaczyć po wdrożeniu klastra D w środowisku docelowym.

Prawie pełne środowisko

W naszym przykładowym środowisku docelowym cztery z ośmiu stojaków znajdują się blisko pojemności. Spróbujmy uruchomić inny klaster NKS.

Klaster E ma następujące specyfikacje:

• Płaszczyzna sterowania, NC_G24_112_v1 jednostka SKU, pięć
• Pula agentów nr 1, NC_P46_224_v1 jednostka SKU, 32 liczba

Oto tabela podsumowująca, co użytkownik powinien zobaczyć po uruchomieniu klastra E w środowisku docelowym.

Klaster	Pula	SKU	Łączna liczba	Oczekiwano # stojaki	Rzeczywiste regały #	Oczekiwano # maszyn wirtualnych na stojak	Rzeczywista liczba maszyn wirtualnych na stojak
E	Płaszczyzna sterowania	NC_G24_112_v1	5	5	5	1	1
E	Pula agentów nr 1	NC_P46_224_v1	32	8	8	4	3, 4 lub 5

Pula agentów klastra E #1 będzie rozłożona nierównomiernie na wszystkie osiem stojaków. Stojaki 7 i 8 będą miały trzy maszyny wirtualne NKS z puli agentów #1 zamiast oczekiwanych czterech maszyn wirtualnych NKS, ponieważ nie ma więcej pojemności dla dodatkowych dużych maszyn wirtualnych jednostki SKU w tych stojakach po zaplanowaniu klastrów od D. Ponieważ stojaki 7 i 8 nie mają pojemności dla czwartej dodatkowej dużej jednostki SKU w puli agentów nr 1, pięć maszyn wirtualnych NKS wylądowa na dwóch najmniej wykorzystywanych stojakach. W naszym przykładzie te najmniej używane stojaki były stojakami 3 i 6.

Oto wizualizacja układu, który użytkownik może zobaczyć po wdrożeniu klastra E w środowisku docelowym.

Umieszczanie podczas uaktualniania środowiska uruchomieniowego

Od kwietnia 2024 r. (wersja Network Cloud 2304.1) uaktualnienia środowiska uruchomieniowego są wykonywane przy użyciu strategii stojaka po stojaku. Serwery bez systemu operacyjnego w stojaku 1 są odtwarzane naraz. Proces uaktualniania zostanie wstrzymany do momentu pomyślnego ponownego uruchomienia wszystkich serwerów bez systemu operacyjnego i poinformuj Nexusa, że są one gotowe do odbierania obciążeń.

Uwaga

Można poinstruować Operator Nexus, aby odtworzyć tylko część serwerów bez systemu operacyjnego w stojaku jednocześnie, jednak domyślnie jest odtworzenie wszystkich bez systemu operacyjnego serwerów w stojaku równolegle.

Gdy pojedynczy serwer bez systemu operacyjnego jest odtwarzany, wszystkie obciążenia uruchomione na tym serwerze bez systemu operacyjnego, w tym wszystkie maszyny wirtualne NKS, utrata zasilania i łączność. Kontenery obciążeń uruchomione na maszynach wirtualnych NKS z kolei utracą zasilanie i łączność. Po upływie jednej minuty, gdy nie będzie można uzyskać dostępu do tych kontenerów obciążeń, płaszczyzna sterowania Kubernetes klastra NKS oznaczy odpowiednie zasobniki jako w złej kondycji. Jeśli zasobniki są członkami wdrożenia lub statefulSet, płaszczyzna sterowania Kubernetes klastra NKS próbuje uruchomić zastępcze zasobniki, aby przywrócić zaobserwowaną liczbę replik wdrożenia lub statefulSet z powrotem do żądanej liczby replik.

Nowe zasobniki są uruchamiane tylko wtedy, gdy w pozostałych maszynach wirtualnych NKS jest dostępna pojemność zasobnika. Od kwietnia 2024 r. (wersja Network Cloud 2304.1) nowe maszyny wirtualne NKS nie są tworzone w celu zastąpienia maszyn wirtualnych NKS, które znajdowały się na serwerze bez systemu operacyjnego, które są odtwarzane.

Gdy serwer bez systemu operacyjnego zostanie pomyślnie odtworzonych i będzie mógł zaakceptować nowe maszyny wirtualne NKS, maszyny wirtualne NKS, które pierwotnie znajdowały się na tym samym serwerze bez systemu operacyjnego, ponownie uruchom na nowo odtworzonych maszynach wirtualnych bez systemu operacyjnego. Kontenery obciążeń mogą być następnie zaplanowane do tych maszyn wirtualnych NKS, co może potencjalnie przywrócić wdrożenia lub stanowe zestawy z zasobnikami na maszynach wirtualnych NKS, które znajdowały się na serwerze bez systemu operacyjnego.

Uwaga

To zachowanie może wydawać się użytkownikowi tak, jakby maszyny wirtualne NKS nie "przenosiły się" z serwera bez systemu operacyjnego, gdy w rzeczywistości nowe wystąpienie identycznej maszyny wirtualnej NKS zostało uruchomione na nowo odtworzonych komputerach bez systemu operacyjnego, który zachował tę samą nazwę serwera bez systemu operacyjnego, co przed ponownym utworzeniem obrazu.

Najlepsze rozwiązania

Podczas pracy z operatorem Nexus należy pamiętać o następujących najlepszych rozwiązaniach.

• Unikaj określania AvailabilityZones puli agentów.
• Uruchom większe klastry NKS przed mniejszymi.
• Zmniejsz liczbę puli agentów przed zmniejszeniem rozmiaru jednostki SKU maszyny wirtualnej.

Unikaj określania stref dostępności dla puli agentów

Jak można stwierdzić w powyższych scenariuszach umieszczania, określenie AvailabilityZones puli agentów jest głównym powodem, dla którego maszyny wirtualne NKS z tego samego klastra NKS będą znajdować się na tym samym serwerze bez systemu operacyjnego. Określając AvailabilityZoneswartość , należy przypiąć pulę agentów do podzestawu stojaków, a tym samym ograniczyć liczbę potencjalnych serwerów bez systemu operacyjnego w tym zestawie stojaków dla innych klastrów NKS i innych maszyn wirtualnych puli agentów w tym samym klastrze NKS, na które mają wylądować.

W związku z tym naszym pierwszym najlepszym rozwiązaniem jest unikanie określania AvailabilityZones puli agentów. Jeśli wymagane jest przypięcie puli agentów do zestawu Strefy dostępności, ustaw go jak najwięcej, aby zminimalizować dysproporcję, która może wystąpić.

Jedynym wyjątkiem od tego najlepszego rozwiązania jest sytuacja, w której w puli agentów istnieje tylko dwa lub trzy maszyny wirtualne. Możesz rozważyć ustawienie AvailabilityZones dla tej puli agentów na [1,3,5,7] lub [0,2,4,6] zwiększenie dostępności podczas uaktualniania środowiska uruchomieniowego.

Uruchom większe klastry NKS przed mniejszymi

Od kwietnia 2024 r. i wersja Network Cloud 2403.1 klastry NKS są zaplanowane w kolejności, w której są tworzone. Aby najefektywniej spakować środowisko docelowe, zalecamy utworzenie większych klastrów NKS przed mniejszymi. Podobnie zalecamy zaplanowanie większych pul agentów przed mniejszymi pulami.

To zalecenie jest ważne w przypadku pul agentów korzystających z dodatkowych dużych NC_G48_224_v1 lub NC_P46_224_v1 dodatkowych jednostek SKU. Planowanie pul agentów z największą liczbą tych dodatkowych dużych maszyn wirtualnych jednostki SKU tworzy większy zestaw serwerów bez systemu operacyjnego, na których inne dodatkowe duże maszyny wirtualne jednostki SKU z pul agentów w innych klastrach NKS mogą się kolokować.

Zmniejsz liczbę puli agentów przed zmniejszeniem rozmiaru jednostki SKU maszyny wirtualnej

Jeśli wystąpią ograniczenia pojemności podczas uruchamiania klastra NKS lub puli agentów, przed dostosowaniem rozmiaru jednostki SKU maszyny wirtualnej zmniejsz liczbę puli agentów. Jeśli na przykład spróbujesz utworzyć klaster NKS z pulą agentów o rozmiarze jednostki SKU maszyny wirtualnej i liczbą 24, a następnie wrócić do niepowodzenia aprowizacji klastra NKS z powodu niewystarczającej ilości zasobów, może być kuszony użycie rozmiaru NC_P46_224_v1 NC_P36_168_v1 jednostki SKU maszyny wirtualnej i kontynuowania z liczbą 24. Jednak ze względu na wymagania dotyczące maszyn wirtualnych obciążeń, które mają być dopasowane do pojedynczej komórki NUMA na serwerze bez systemu operacyjnego, prawdopodobnie to samo żądanie spowoduje podobne niewystarczające błędy zasobów. Zamiast zmniejszać rozmiar jednostki SKU maszyny wirtualnej, rozważ zmniejszenie liczby puli agentów do 20. Istnieje większe prawdopodobieństwo, że twoje żądanie mieści się w pojemności zasobu środowiska docelowego, a ogólne wdrożenie ma więcej rdzeni procesora CPU niż w przypadku awarii jednostki SKU maszyny wirtualnej.