Aktualizowanie obrazów platformy Kubernetes i węzłów w wielu klastrach członkowskich

Artykuł
11/05/2024

Administratorzy platformy zarządzający dużą liczbą klastrów często mają problemy z przemieszczaniem aktualizacji wielu klastrów (na przykład uaktualnianie obrazu systemu operacyjnego węzła lub wersji platformy Kubernetes) w bezpieczny i przewidywalny sposób. Aby rozwiązać to wyzwanie, usługa Azure Kubernetes Fleet Manager (Fleet) umożliwia organizowanie aktualizacji w wielu klastrach przy użyciu przebiegów aktualizacji.

Przebiegi aktualizacji składają się z etapów, grup i strategii i można je stosować ręcznie, w przypadku aktualizacji jednorazowych lub automatycznie, w przypadku bieżących regularnych aktualizacji przy użyciu profilów automatycznego uaktualniania. Wszystkie przebiegi aktualizacji (ręczne lub zautomatyzowane) honorowe okna obsługi klastra członkowskiego.

Opis przebiegów aktualizacji

Na poniższej ilustracji przedstawiono wizualizację przebiegu uaktualnienia zawierającego dwa etapy aktualizacji, z których każdy zawiera dwie grupy aktualizacji z dwoma klastrami składowymi. Okres oczekiwania jest konfigurowany między pierwszym i drugim etapem.

Przebieg aktualizacji: przebieg aktualizacji reprezentuje aktualizację stosowaną do kolekcji klastrów usługi AKS, składającej się z celu i sekwencji aktualizacji. Cel aktualizacji opisuje żądane aktualizacje (na przykład uaktualnienie do platformy Kubernetes w wersji 1.28.3). Sekwencja aktualizacji opisuje dokładną kolejność stosowania aktualizacji do wielu klastrów członkowskich wyrażonych przy użyciu etapów i grup. Jeśli nie określono, wszystkie klastry członkowskie są aktualizowane pojedynczo. Można zatrzymać i uruchomić przebieg aktualizacji.
Etap aktualizacji: przebiegi aktualizacji są podzielone na etapy, które są stosowane sekwencyjnie. Na przykład pierwszy etap aktualizacji może aktualizować klastry członkowskie środowiska testowego, a drugi etap aktualizacji spowoduje późniejsze zaktualizowanie klastrów członkowskich środowiska produkcyjnego. Można określić czas oczekiwania, aby opóźnić między zastosowaniem kolejnych etapów aktualizacji.
Grupa aktualizacji: każdy etap aktualizacji zawiera co najmniej jedną grupę aktualizacji, która służy do wybierania klastrów członkowskich do zaktualizowania. Grupy aktualizacji są również używane do zamawiania aplikacji aktualizacji do klastrów członkowskich. W ramach etapu aktualizacji aktualizacje są stosowane do wszystkich różnych grup aktualizacji równolegle; w grupie aktualizacji klastry członkowskie są aktualizowane sekwencyjnie. Każdy klaster członkowski floty może być tylko częścią jednej grupy aktualizacji.
Strategia aktualizacji: Strategia aktualizacji opisuje sekwencję aktualizacji z etapami i grupami i umożliwia ponowne użycie konfiguracji przebiegu aktualizacji zamiast definiowania sekwencji wielokrotnie w każdym przebiegu. Strategia aktualizacji nie obejmuje żądanych wersji obrazów platformy Kubernetes ani węzła.

Obecnie obsługiwane operacje aktualizacji w klastrze członkowskim są uaktualnieniami. Istnieją trzy typy uaktualnień, spośród których można wybrać:

Uaktualnij wersje platformy Kubernetes dla płaszczyzny sterowania kubernetes i węzłów (w tym uaktualnianie obrazów węzłów).
Uaktualnij wersje platformy Kubernetes tylko dla płaszczyzny sterowania klastrów.
Uaktualnij tylko obrazy węzłów.

Możesz określić docelową wersję platformy Kubernetes do uaktualnienia, ale nie można określić dokładnej wersji obrazu węzła docelowego. Dzieje się tak, ponieważ najnowsza dostępna wersja obrazu węzła może się różnić w zależności od regionu świadczenia usługi Azure klastra (sprawdź monitor wersji usługi AKS, aby uzyskać więcej informacji).

Wersje obrazu węzła docelowego są automatycznie wybierane na podstawie preferencji:

Latest: użyj najnowszych obrazów węzłów dostępnych w regionie świadczenia usługi Azure klastra podczas uaktualniania klastra. W związku z tym różne wersje obrazów mogą być używane w zależności od regionu świadczenia usługi Azure, w którym znajduje się klaster i kiedy faktycznie uruchamia się jego uaktualnienie.
Consistent: Po uruchomieniu przebiegu aktualizacji wybierane są najnowsze typowe wersje obrazów w regionach platformy Azure klastrów członkowskich w tym przebiegu, tak aby te same spójne wersje obrazów były używane w klastrach.

Latest Należy użyć nowszych wersji obrazów i zminimalizować zagrożenia bezpieczeństwa, a następnie wybrać Consistent zwiększenie niezawodności przy użyciu i zweryfikowaniu tych obrazów w klastrach we wcześniejszych etapach przed ich użyciem w późniejszych klastrach.

Planowana konserwacja

Przebiegi aktualizacji honoruje okna planowanej konserwacji ustawione na poziomie klastra usługi Azure Kubernetes Service (AKS).

W ramach przebiegu aktualizacji (zarówno dla jednego uruchomienia aktualizacji typu jeden, jak i etapy) przebieg aktualizacji określa priorytet uaktualniania klastrów w następującej kolejności:

Element członkowski z otwartym trwającym oknem obsługi.
Element członkowski z otwarciem okna obsługi w ciągu najbliższych czterech godzin.
Element członkowski bez okna obsługi.
Element członkowski z zamkniętym oknem obsługi.

Stany uruchamiania aktualizacji

Przebieg aktualizacji może być w jednym z następujących stanów:

NotStarted: uruchomienie aktualizacji nie zostało uruchomione.
Uruchomione: uaktualnienie jest w toku dla co najmniej jednego z klastrów członkowskich w przebiegu aktualizacji.
Oczekujące:
- Klaster członkowski: klaster członkowski może znajdować się w stanie oczekiwania z dowolnego z następujących powodów, które można wyświetlić w polu komunikatu.
  - Okno obsługi nie jest otwarte. Komunikat wskazuje następny czas otwarcia.
  - Docelowa wersja platformy Kubernetes nie jest jeszcze dostępna w regionie świadczenia usługi Azure członka. Komunikat zawiera linki do monitora wydań, aby można było sprawdzić stan wydania w różnych regionach.
  - Wersja obrazu węzła docelowego nie jest jeszcze dostępna w regionie świadczenia usługi Azure elementu członkowskiego. Komunikat zawiera linki do monitora wydań, aby można było sprawdzić stan wydania w różnych regionach.
- Grupa: grupa jest w Pending stanie, jeśli wszyscy członkowie grupy są w Pending stanie lub nie są uruchomione. Gdy członek przejdzie do Pendingelementu , uruchomienie aktualizacji podejmie próbę uaktualnienia następnego członka w grupie. Jeśli wszyscy członkowie to Pending, grupa zostanie przeniesiona do Pending stanu. Jeśli grupa jest w Pending stanie, uruchomienie aktualizacji czeka na ukończenie grupy przed przejściem do następnego etapu wykonywania.
- Etap: etap jest w Pending stanie, jeśli wszystkie grupy w tym etapie są w Pending stanie lub nie są uruchomione.
- Uruchom: przebieg jest w Pending stanie, jeśli bieżący etap, który powinien być uruchomiony, jest w Pending stanie.
Pominięto: można pominąć wszystkie poziomy przebiegu aktualizacji. Pomijanie może być inicjowane przez system lub użytkownika.
- Członek:
  - Pominięto uaktualnienie elementu członkowskiego, grupy lub etapu.
  - Klaster członkowski jest już w docelowej wersji platformy Kubernetes (jeśli tryb uruchamiania aktualizacji to Full lub ControlPlaneOnly).
  - Klaster członkowski jest już w docelowej wersji platformy Kubernetes, a wszystkie pule węzłów znajdują się w wersji obrazu węzła docelowego.
  - Jeśli na potrzeby uruchomienia uaktualnienia wybrano spójny obraz węzła, jeśli nie można odnaleźć wersji obrazu docelowego dla jednej z pul węzłów, uaktualnienie zostanie pominięte dla tego klastra. Na przykład może się to zdarzyć, gdy nowa pula węzłów z nową jednostkę SKU maszyny wirtualnej zostanie dodana po uruchomieniu aktualizacji.
- Grupa:
  - Wszystkie klastry członkowskie zostały wykryte przez Skipped system.
  - Zainicjowano pomijanie na poziomie grupy.
- Etap:
  - Wszystkie grupy na etapie zostały wykryte przez Skipped system.
  - Zainicjowano pomijanie na poziomie etapu.
- Uruchom polecenie:
  - Wszystkie etapy zostały wykryte przez Skipped system.
Zatrzymano: wszystkie poziomy przebiegu aktualizacji można zatrzymać. Istnieją dwie możliwości wprowadzenia stanu zatrzymania:
- Zatrzymasz przebieg aktualizacji, w którym momencie uruchomienie aktualizacji zatrzymuje śledzenie wszystkich operacji. Jeśli operacja została już zainicjowana przez uruchomienie aktualizacji (na przykład uaktualnienie klastra jest w toku), ta operacja nie została przerwana dla tego pojedynczego klastra.
- Jeśli podczas uruchamiania aktualizacji wystąpi błąd (na przykład uaktualnienia nie powiodły się w jednym z klastrów), cały przebieg aktualizacji przechodzi w stan zatrzymany. Operacje nie są podejmowane dla żadnego kolejnego klastra w przebiegu aktualizacji.
Niepowodzenie: Niepowodzenie uaktualniania klastra powoduje wykonanie następujących akcji:
- Oznacza element MemberUpdateStatus jako Failed w klastrze członkowskim.
- Oznacza wszystkie elementy nadrzędne (grupowanie —> etap —> przebieg) jako Failed z komunikatem o błędzie podsumowania.
- Uniemożliwia kontynuowanie działania aktualizacji.

Uwaga

Możesz ponownie uruchomić przebieg aktualizacji w dowolnym momencie, aby ponownie zastosować uaktualnienia, które mogły zostać pominięte lub zakończyły się niepowodzeniem.

Opis profilów automatycznego uaktualniania (wersja zapoznawcza)

Profile automatycznego uaktualniania są używane do automatycznego wyzwalania przebiegów aktualizacji po udostępnieniu nowych wersji obrazów platformy Kubernetes lub węzła dla usługi AKS.

Ważne

Funkcje usługi Azure Kubernetes Fleet Manager w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi Azure Kubernetes Fleet Manager są częściowo objęte pomocą techniczną w oparciu o najlepsze nakłady pracy. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego.

W profilu automatycznego uaktualniania można skonfigurować:

a Channel (Stable, Rapid, NodeImage), który określa typ automatycznego uaktualniania stosowanego do klastrów.
program UpdateStrategy , który konfiguruje sekwencję, w której klastry są uaktualniane. Jeśli strategia nie jest dostarczana, klastry są aktualizowane pojedynczo pojedynczo.
( NodeImageSelectionType Najnowsze, spójne) w celu określenia sposobu wybierania obrazu węzła podczas uaktualniania wersji platformy Kubernetes.

Kanał stabilny

Kanał Stable jest zawsze najnowszą wersją poprawki kubernetes obsługiwaną przez usługę AKS w wersji pomocniczej N-1, gdzie N jest najnowszą obsługiwaną wersją pomocniczą.

Przykłady:

Najnowsza obsługiwana wersja pomocnicza platformy Kubernetes to 1.30. Wszelkie wersje poprawek w zakresie pomocniczym 1.29 będą brane pod uwagę w przypadku aktualizacji kanału stabilnego.
Opublikowano nową pomocniczą wersję platformy Kubernetes w wersji 1.31 . Wszelkie wersje poprawek w zakresie pomocniczym 1.30 będą brane pod uwagę w przypadku aktualizacji kanału stabilnego. Każdy klaster, który wcześniej otrzymywał aktualizacje z wersji 1.29 , zostanie zaktualizowany do najnowszej poprawki dla wersji 1.30.

Szybki kanał

Szybki kanał jest zawsze najnowszą wersją pomocniczą platformy Kubernetes obsługiwaną przez usługę AKS.

Przykłady:

Najnowsza obsługiwana wersja pomocnicza to 1.30. Wszelkie wersje poprawek w zakresie pomocniczym 1.30 będą brane pod uwagę w przypadku aktualizacji szybkiego kanału.
Opublikowano nową pomocniczą wersję platformy Kubernetes w wersji 1.31 . 1.30 przechodzi do kanału Stabilne. Każdy klaster, który wcześniej odbierał aktualizacje z wersji 1.30 , zostanie zaktualizowany do najnowszej poprawki dla wersji 1.31 , która jest teraz kanałem Szybkie.

Kanał NodeImage

Węzły klastra członkowskiego są aktualizowane przy użyciu nowo poprawionego wirtualnego dysku twardego zawierającego poprawki zabezpieczeń i poprawki błędów co tydzień. Aktualizacja nowego dysku VHD jest destrukcyjna, zgodnie z ustawieniami okien konserwacji i przepięcia. Podczas wybierania tej opcji nie są naliczane żadne dodatkowe koszty dysku VHD.

Jeśli używasz tego kanału, uaktualnienia nienadzorowane systemu Linux są domyślnie wyłączone. Uaktualnienia obrazów węzłów obsługują przestarzałe wersje poprawek, o ile wersja pomocnicza kubernetes jest nadal obsługiwana. Obrazy węzłów są testowane przez usługę AKS, w pełni zarządzane i stosowane przy użyciu bezpiecznych praktyk wdrażania.

Węzły w różnych systemach operacyjnych zostaną zaktualizowane zgodnie z wersjami obrazów węzłów dopasowanymi do tych systemów operacyjnych.

Przykład:

Klaster ma węzły z węzłemImage AKSWindows-2022-containerd w wersji 20348.2582.240716. Zostanie wydany nowy węzeł NodeImage w wersji 20348.2582.240916 , a węzły klastra zostaną automatycznie uaktualnione do wersji 20348.2582.240916.

Zachowanie pomijania wersji pomocniczej

Automatyczne uaktualnianie nie przenosi klastrów między wersjami pomocniczymi kubernetes, gdy istnieje więcej niż jedna pomocnicza różnica wersji rozwiązania Kubernetes (na przykład 1.28 do 1.30). Jeśli administratorzy mają zróżnicowany zestaw wersji platformy Kuberenetes, zaleca się najpierw użycie jednego lub większej liczby przebiegów aktualizacji w celu wprowadzenia klastrów członkowskich do zestawu spójnych wersji wersji, dzięki czemu skonfigurowane Stable lub Rapid aktualizacje kanału zapewniają zachowanie spójności w przyszłości.