Bezpiecznie aktualizuj Kubernetes oraz obrazy węzłów w wielu klastrach

Dotyczy: ✔️ Fleet Manager ✔️ Fleet Manager z klastrem koncentratora

Administratorzy platformy, którzy zarządzają dużą liczbą klastrów, często mają problemy z przejściowymi aktualizacjami dla wielu klastrów (na przykład uaktualnianie obrazu systemu operacyjnego węzła lub wersji rozwiązania Kubernetes) w bezpieczny i przewidywalny sposób. Aby sprostać temu wyzwaniu, Azure Kubernetes Fleet Manager umożliwia koordynowanie aktualizacji w wielu klastrach za pomocą uruchomień aktualizacji.

Przebiegi aktualizacji składają się z etapów, grup i strategii. Uruchomienia aktualizacji można stosować ręcznie w przypadku jednorazowych aktualizacji lub automatycznie w przypadku regularnie przeprowadzanych aktualizacji za pomocą profili automatycznego uaktualniania. Wszystkie uruchomienia aktualizacji, zarówno ręczne, jak i automatyczne, uwzględniają okna konserwacji klastra.

Opis przebiegów aktualizacji

Przebieg aktualizacji oznacza aktualizację stosowaną do zestawu klastrów AKS. Składa się z celu aktualizacji i sekwencji. Cel aktualizacji opisuje żądane aktualizacje. Na przykład uaktualnienie do określonej wersji platformy Kubernetes lub zastosowanie spójnego obrazu węzła we wszystkich klastrach.

Aby uzyskać najlepsze wyniki podczas korzystania z uruchomień aktualizacji, ważne jest zrozumienie następujących pojęć.

• Strategia aktualizacji: opisuje sekwencję aktualizacji wielokrotnego użytku składającą się z etapów i grup klastrów. Klaster jest wyświetlany w grupie na danym etapie na podstawie etykiet grupy aktualizacji lub etykiet członków, które są do niego przypisane. Aby uzyskać więcej informacji, zobacz Omówienie strategii aktualizacji.

  • Etap aktualizacji: strategia aktualizacji jest podzielona na etapy aktualizacji, które są stosowane sekwencyjnie. Na przykład klastry środowiska testowego znajdują się w pierwszym etapie aktualizacji, podczas gdy klastry środowiska produkcyjnego przechodzą w drugim etapie aktualizacji. Etap aktualizacji zawiera co najmniej jedną grupę aktualizacji. Możesz użyć dodatkowych kontrolek, takich jak maksymalna współbieżność, czas oczekiwania i bramy zatwierdzania, aby uzyskać większą kontrolę nad wykonywaniem etapu aktualizacji.

  • Grupa aktualizacji: każdy etap aktualizacji zawiera co najmniej jedną grupę aktualizacji, która wybiera klastry do aktualizacji. Przypisz klastry składowe do grup aktualizacji, używając albo właściwości Grupa aktualizacji klastra, albo dopasowywania opartego na etykietach, dostępnego obecnie w wersji zapoznawczej, przy użyciu etykiet członków. Grupy aktualizacji w etapie aktualizacji są aktualizowane równolegle.

  Uwaga

  Maksymalna liczba grup aktualizacji w każdym etapie aktualizacji to 50.

  • Dodatkowe mechanizmy sterowania przepływem: dostępne są dodatkowe opcje zapewniające elastyczność w zakresie tempa aktualizacji floty klastrów:

    • Maksymalna współbieżność (wersja zapoznawcza): użyj konfiguracji maksymalnej współbieżności , aby zmienić liczbę klastrów uaktualnianych równolegle. To zachowanie można skonfigurować zarówno na poziomie etapu, jak i grupy.

    • Maksymalna dozwolona liczba niepowodzeń (wersja zapoznawcza): użyj konfiguracji Maksymalna dozwolona awaria , aby kontrolować, ile awarii uaktualnienia klastra członkowskiego jest tolerowanych przed zatrzymanie przebiegu aktualizacji. To zachowanie można skonfigurować zarówno na poziomie etapu, jak i grupy.

    • Bramy: wstrzymaj przebieg aktualizacji do momentu spełnienia ich warunku.

      • Bramy zatwierdzania (wersja zapoznawcza): można skonfigurować przed lub po każdym etapie lub grupie. Zatwierdzenia powodują wstrzymanie przebiegu aktualizacji, umożliwiając Ci lub skonfigurowanym automatyzacjom sprawdzenie, czy można kontynuować. Po przyznaniu zatwierdzenia przez Ciebie lub automatyzację przebieg aktualizacji będzie kontynuowany.

      • Zaplanowane bramy uruchamiania (wersja zapoznawcza): można skonfigurować przed każdym etapem lub grupą. Zaplanowane punkty kontrolne rozpoczęcia wstrzymują uruchomienie aktualizacji do wskazanego dnia i godziny. Brama zostanie ukończona automatycznie po osiągnięciu zaplanowanego czasu lub można ją ręcznie ukończyć, aby kontynuować w dowolnym momencie.

• Profil automatycznej aktualizacji: automatycznie tworzy i rozpoczyna proces aktualizacji, gdy usługa AKS udostępni nowe wersje Kubernetes lub obrazu węzła. Aby uzyskać więcej informacji, zobacz Omówienie profilów automatycznego uaktualniania.

Opcje przebiegu aktualizacji

Przebiegi aktualizacji mogą obejmować trzy typy aktualizacji:

• Uaktualnij wersje platformy Kubernetes dla płaszczyzny sterowania i węzłów. To uaktualnienie obejmuje uaktualnianie obrazu węzła.
• Uaktualnij wersje platformy Kubernetes tylko dla płaszczyzny sterowania klastrów.
• Uaktualnij tylko obrazy węzłów.

Możesz określić docelową wersję Kubernetes, na którą chcesz uaktualnić, ale nie możesz wybrać docelowych wersji obrazu węzła. System automatycznie wybiera wersje obrazu węzła docelowego na podstawie preferencji:

• Najnowsze: użyj najnowszych obrazów węzłów dostępnych w regionie Azure każdego klastra po uruchomieniu uaktualnienia tego klastra. W związku z tym różne wersje obrazów mogą być używane w całej flocie, w zależności od regionu Azure, w którym znajduje się klaster i kiedy faktycznie uruchamia się jego uaktualnienie.
• Spójność: Po rozpoczęciu przebiegu aktualizacji wybierz wersje obrazów, które są obecnie dostępne we wszystkich regionach platformy Azure, w których znajdują się klastry objęte tym przebiegiem. W związku z tym spójne wersje obrazów są używane we wszystkich klastrach.

Wybierz pozycję Najnowsze , aby używać nowszych wersji obrazów i zminimalizować zagrożenia bezpieczeństwa. Wybierz pozycję Spójna , aby zwiększyć niezawodność, używając i weryfikując te obrazy w klastrach we wcześniejszych etapach przed ich użyciem w późniejszych klastrach.

Stany przebiegu aktualizacji

Aby zrozumieć cykl życia przebiegu aktualizacji, musisz znać każdy stan, akcje, które można wykonać i jak jest obliczany stan.

Status oczekujący

• Uruchomienie aktualizacji: jeśli bieżący etap znajduje się w stanie Pending.
• Etap aktualizacji: jeśli wszystkie grupy aktualizacji w etapie są Pending lub nie zostały uruchomione, albo jeśli etap ma bramę Pending.
• Grupa aktualizacji: jeśli wszystkie klastry w grupie są Pending lub nie zostały uruchomione, albo jeśli ma bramkę Pending. Gdy klaster przechodzi do stanu Pending, proces aktualizacji próbuje zaktualizować następny klaster w grupie. Jeśli wszyscy członkowie są Pending, grupa przeniesie się do Pending. Proces aktualizacji czeka, aż wszystkie grupy w danym etapie zostaną ukończone, zanim przejdzie do następnego etapu.
• Klaster członkowski: 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 Kubernetes lub wersja obrazu węzła nie jest jeszcze dostępna w regionie platformy Azure klastra. Komunikat zawiera link do trackera wydań usługi AKS, aby sprawdzić status wydania.

Stan pominięty

• Uruchomienie aktualizacji: system wykrył, że wszystkie etapy miały stan Skipped.
• Etap aktualizacji: użytkownik oznaczył etap lub wszystkie grupy na etapie jako Skipped.
• Aktualizuj grupę: użytkownik oznaczył grupę lub wszystkie klastry w grupie jako Skipped.
• Klaster członkowski: z dowolnego z następujących powodów, które można wyświetlić w polu komunikatu.
  • Użytkownik jawnie pominął klaster, grupę lub etap.
  • Klaster jest już w docelowej wersji platformy Kubernetes (jeśli tryb uruchamiania aktualizacji jest Full lub ControlPlaneOnly), a wszystkie pule węzłów znajdują się w wersji obrazu węzła docelowego.
  • Gdy wybrano spójny obraz węzłów i nie można znaleźć docelowej wersji obrazu dla jednej z pul węzłów. Taka sytuacja może wystąpić, gdy po rozpoczęciu przebiegu aktualizacji zostanie dodana nowa pula węzłów z nową jednostką SKU maszyny wirtualnej (VM).

Stan niepowodzenia

Stan błędu jest dziedziczony z klastrów, jak pokazano. Zbiorczy komunikat o błędzie wyświetla przyczynę nieudanej aktualizacji klastra.

• Przebieg aktualizacji: co najmniej jeden klaster w bieżącej grupie zakończył się niepowodzeniem.
• Etap aktualizacji: co najmniej jeden klaster w grupie na etapie zakończył się niepowodzeniem.
• Grupa aktualizacji: co najmniej jeden klaster w grupie nie powiódł się.
• Klaster członkowski: uaktualnienie nie powiodło się, a stan klastra jest ustawiony jako Failed.

Podczas konfigurowania maksymalnych dozwolonych niepowodzeń próg niepowodzenia wpływa na stan grupy aktualizacji, etap aktualizacji i przebieg aktualizacji. Nie ma to wpływu na stan pojedynczego klastra członkowskiego. Jeśli uaktualnienie klastra członkowskiego zakończy się niepowodzeniem, jego status jest nadal ustawiony na Failed.

• Jeśli liczba niepowodzeń dla grupy lub etapu przekroczy skonfigurowany maxAllowedFailures próg, grupa lub etap zostanie oznaczony jako Failed z komunikatem o błędzie podsumowania, a przebieg aktualizacji przestanie trwać. Jeśli nie skonfigurowano maxAllowedFailures (lub ustawiono wartość 0), pojedyncze niepowodzenie zatrzymuje całe uruchomienie.
• Jeśli liczba niepowodzeń mieści się w progu maxAllowedFailures, proces aktualizacji kontynuuje aktualizowanie kolejnych członków. Aby uzyskać więcej informacji, zobacz Maksymalna dozwolona liczba niepowodzeń.

Stan ukończony

Stan Completed oznacza, że przebieg aktualizacji osiągnął stan cyklu życia terminalu. Jeśli używasz opcji Maksymalna dozwolona liczba niepowodzeń, oznacza to, że skonfigurowany próg niepowodzenia nie został przekroczony, gdy usługa Fleet Manager zdecydowała, Completed czy kontynuować planowanie pracy. Nie gwarantuje to minimalnego współczynnika powodzenia ani zdrowych wyników. Zawsze sprawdzaj FailureCount, państwa członkowskie i komunikaty o błędach.

Planowane terminy konserwacji

Uruchomienia aktualizacji uwzględniają zaplanowane okna konserwacji ustawione na poziomie klastra AKS.

Klastry usługi AKS obsługują dwa odrębne okna obsługi — jeden dla uaktualnień platformy Kubernetes (płaszczyzny sterowania) i jeden dla uaktualnień obrazu węzła. Okna obsługi definiują okresy, w których można zastosować aktualizacje do klastra, ale nie są wyzwalaczem aktualizacji.

Aktualizacja programu Fleet Manager uwzględnia okna konserwacji usługi AKS w następujący sposób:

Przebieg aktualizacji określa priorytety uaktualniania klastrów w oparciu o planowaną konserwację w następującej kolejności:

1. Klaster z otwartym trwającym oknem obsługi.
2. Klaster z oknem konserwacji rozpoczynającym się w ciągu najbliższych czterech godzin.
3. Klaster bez okna konserwacyjnego.
4. Klaster z zamkniętym oknem obsługi.

Omówienie profili automatycznej aktualizacji

Użyj profili automatycznej aktualizacji, aby automatycznie uruchamiać aktualizacje, gdy w usłudze AKS są dostępne nowe wersje platformy Kubernetes lub obrazy węzłów.

W profilu automatycznego uaktualniania konfigurujesz:

• kanał (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (wersja zapoznawcza)), który określa typ aktualizacji zastosowany do klastrów.
• strategia UpdateStrategy, która określa kolejność aktualizacji klastrów. Jeśli nie podasz strategii, klastry aktualizują je sekwencyjnie.
• NodeImageSelectionType (Latest, Consistent) w celu określenia sposobu wybierania obrazu węzła podczas uaktualniania wersji rozwiązania Kubernetes.

Szybki kanał

Kanał Rapid jest zawsze najnowszą wersją podrzędną platformy Kubernetes obsługiwaną przez usługę AKS. Podrzędne wersje klastra zmieniają się automatycznie, gdy AKS udostępnia nową podrzędną wersję Kubernetes.

Przykłady:

• Najnowsza obsługiwana wersja pomocnicza to 1.30. Wszelkie wydania poprawek w linii wersji 1.30 są uwzględniane w aktualizacjach kanału Rapid.
• Opublikowano nową pomniejszą wersję Kubernetes 1.31. 1.30 przechodzi do kanału stabilnego. Każdy klaster, który wcześniej odbierał aktualizacje z wersji 1.30 , jest aktualizowany do najnowszej poprawki dla wersji 1.31 , która jest teraz kanałem Rapid.

Kanał stabilny

Kanał Stable jest zawsze wersją pomocniczą przed kanałem Rapid . Czasami Stable jest określany jako "N-1", gdzie "N" to najnowsza obsługiwana podrzędna wersja Kubernetes w kanale Rapid. Podrzędne wersje klastra zmieniają się automatycznie, gdy AKS udostępnia nową podrzędną wersję Kubernetes.

Przykłady:

• Najnowsza obsługiwana mniejsza wersja 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ą pomniejszą wersję Kubernetes 1.31. Kanał Stable bierze pod uwagę wszystkie wydania poprawek w ramach wersji pomocniczej 1.30 pod kątem aktualizacji. Każdy klaster, który wcześniej otrzymywał aktualizacje z wersji 1.29 , został zaktualizowany do najnowszej poprawki dla wersji 1.30.

Kanał TargetKubernetesVersion

Kanał TargetKubernetesVersion zapewnia kontrolę nad tym, kiedy przenieść klastry do następnej wersji pomocniczej platformy Kubernetes. Należy określić docelową wersję Kubernetes w formacie "{major}.{minor}" (na przykład „1.33”). Rozwiązanie Fleet Manager automatycznie uaktualnia klastry do najnowszej wersji poprawki określonej docelowej wersji rozwiązania Kubernetes, gdy poprawka jest dostępna. Fleet Manager nie zostanie zaktualizowany do kolejnej wersji pomocniczej, dopóki docelowa wersja Kubernetes w profilu automatycznej aktualizacji nie zostanie zaktualizowana.

Przykłady:

• Profil automatycznego uaktualniania można utworzyć przy użyciu kanału TargetKubernetesVersion i określić docelową wersję platformy Kubernetes "1.30". Opublikowano nową poprawkę w wersji 1.30.5. Przebieg aktualizacji jest tworzony automatycznie z wartością docelową 1.30.5.
• Profil automatycznego uaktualniania można utworzyć przy użyciu kanału TargetKubernetesVersion, określić docelową wersję platformy Kubernetes "1.29" i włączyć longTermSupport (LTS) w profilu automatycznego uaktualniania. Najnowsza wspierana przez społeczność wersja poboczna to "1.33". Opublikowano nową poprawkę w wersji 1.29.5. Przebieg aktualizacji jest tworzony automatycznie z wartością docelową 1.29.5. Jeśli wygenerowany przebieg aktualizacji zawiera klastry bez włączonego protokołu LTS, kończy się niepowodzeniem.

Zachowanie pomijania wersji mniejszej

Automatyczne uaktualnianie nie uaktualnia klastrów między wersjami mniejszymi Kubernetes, gdy istnieje więcej niż jedna różnica wersji mniejszej Kubernetes (na przykład: 1.28 do 1.30). Gdy administratorzy korzystają ze zróżnicowanych wersji Kubernetes, należy najpierw użyć jednego lub kilku uruchomień aktualizacji, aby doprowadzić klastry do spójnego zestawu wydań o jednolitych wersjach, tak aby skonfigurowane aktualizacje z kanału Stable lub Rapid zapewniały utrzymanie tej spójności w przyszłości.

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 związane z VHD. Uaktualnienia obrazów węzłów obsługują przestarzałe wersje poprawek, o ile wersja mniejsza 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 są aktualizowane zgodnie z wersjami obrazów węzłów dopasowanymi do tych systemów operacyjnych.

Przykład:

• Klaster ma węzły z NodeImage 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.

Zrozumienie uaktualnień i migawek obrazu węzła

Gdy klaster ma pule agentów utworzone z migawki puli węzłów, wynik aktualizacji obrazu węzła zależy od wybranego obrazu węzła w przebiegu aktualizacji Fleet Managera.

Kanał SecurityPatch (wersja zapoznawcza)

Aktualizowanie węzłów klastra członkowskiego z systemem Linuxprzy użyciu tylko poprawek zabezpieczeń co tydzień. Canonical Ubuntu i Azure Linux udostępniają poprawki zabezpieczeń systemu operacyjnego raz dziennie. Microsoft testuje te poprawki i umieszcza je w cotygodniowych aktualizacjach obrazów węzłów.

Kanał automatycznych uaktualnień SecurityPatch powoduje mniej zakłóceń, ponieważ w miarę możliwości wykorzystuje mechanizm live patchingu systemu operacyjnego, minimalizując zakłócenia w działaniu węzłów przy jednoczesnym zapewnieniu ochrony węzłów przed znanymi lukami w zabezpieczeniach. Jeśli stosowanie poprawek na żywo nie jest możliwe, zamiast tego zostanie wdrożony obraz węzła z poprawkami wstępnymi.

Tylko węzły oparte na systemie Linux są aktualizowane podczas korzystania z SecurityPatch, a węzły oparte na systemie Windows są automatycznie pomijane.

Jeśli potrzebujesz poprawek błędów dostarczanych z nowymi obrazami węzłów (VHD) lub chcesz zapewnić spójne działanie węzłów systemu Windows, zamiast tego wybierz kanał NodeImage.

Opis strategii aktualizacji

Administratorzy mogą kontrolować kolejność aktualizowania klastrów przez tworzenie strategii aktualizacji wielokrotnego użytku przy użyciu serii etapów aktualizacji i grup. Mogą konfigurować, kiedy w tych etapach i grupach powinny występować zatwierdzenia i przerwy. Całą konfigurację można zapisać jako strategię aktualizacji, która może być zarządzana niezależnie od przebiegów aktualizacji lub profilów automatycznego uaktualniania, co pozwala na ponowne użycie strategii zgodnie z potrzebami.

Grupowanie klastrów przy użyciu etykiet składowych (wersja zapoznawcza)

Etykiety składowe mogą służyć do grupowania klastrów i konfigurowania sekwencji aktualizacji za pomocą selektorów etykiet w stylu Kubernetes. Dzięki temu można przypisać wiele etykiet do klastrów członkowskich i używać ich do różnych strategii, zamiast ograniczać się do pojedynczej grupy aktualizacji na klaster. Klastry w swojej strategii można grupować za pomocą etykiet członków, konfigurując memberSelector na dwóch poziomach strategii:

• Poziom etapu: umożliwia wybór klastrów dla całego etapu. Jeśli żadne grupy nie są zdefiniowane, wszystkie pasujące klastry tworzą pojedynczą niejawną grupę. Gdy grupy są również zdefiniowane, selektor na poziomie etapu działa jako filtr wstępny przed zastosowaniem dopasowania na poziomie grupy.
• Poziom grupy: wybiera klastry dla określonej grupy w ramach etapu, włączając równoległe podzestawy z różnymi limitami współbieżności.

memberSelector używa selektora etykiet opartych na ciągach, który jest analizowany przy użyciu standardowej składni selektora etykiet Kubernetes. Obsługiwane operatory to: =, , ==, !=in, notin, exists, i !exists.

Aby uzyskać instrukcje dotyczące przypisywania etykiet składowych i używania memberSelector w strategii, zobacz Tworzenie strategii aktualizacji za pomocą selektorów składowych.

Maksymalna współbieżność (wersja zapoznawcza)

Maximum concurrency to opcjonalne ustawienie strategii aktualizacji, które kontroluje liczbę klastrów, które mogą być uaktualniane współbieżnie. Można ustawić Maximum concurrency na dwóch poziomach:

• Poziom etapu: definiuje maksymalną liczbę klastrów, które można uaktualnić w tym samym czasie we wszystkich grupach na etapie. Działa jako globalny pułap dla sceny.
• Poziom grupy: definiuje maksymalną liczbę klastrów, które mogą być uaktualniane współbieżnie w ramach określonej grupy.

Maksymalna współbieżność akceptuje dwie formy wartości:

• Stała liczba całkowita: na przykład "3" ogranicza współbieżność do dokładnie trzech klastrów.
• Procent: na przykład "25%" ogranicza współbieżność do wartości procentowej klastrów. W przypadku ustawień na poziomie etapu wartość procentowa jest obliczana ze wszystkich klastrów na etapie. W przypadku ustawień na poziomie grupy wartość procentowa jest obliczana z klastrów w tej grupie. Wartości procentowe są obliczane w czasie wykonywania, zaokrąglane w dół i wymuszane z minimalną końcową wartością 1.

Sugestie dotyczące kontroli współbieżności

Jeśli chcesz przeprowadzić aktualizację z zachowaniem bezpieczeństwa (mniejsza prędkość, ale mniejsze prawdopodobieństwo wystąpienia wielu uszkodzonych klastrów): ustaw maksymalną równoczesność na mniejszą wartość. Jeśli chcesz uaktualnić z większą szybkością, pamiętaj, że może to zwiększyć ryzyko wielu uszkodzonych klastrów. W takim przypadku ustaw maksymalną współbieżność na większą wartość.

Jak limity etapów i grup wpływają na siebie

Maksymalna współbieżność na poziomie etapu zawsze działa jako ogólny limit. Nawet jeśli poszczególne grupy zezwalają na większą współbieżność, limit etapu ma pierwszeństwo. Współbieżność na poziomie grupy może być niższa niż skonfigurowana dzięki limitowi na poziomie etapu, rozmiarowi grupy lub warunkom specyficznym dla użytkownika.

Przykład 1. Stałe limity

Wynik: łącznie do czterech klastrów z maksymalnie dwoma na grupę.

Przykład 2: Ograniczenia etapów ograniczają przepustowość grup

Wynik: Maksymalnie dwa klastry mogą być uaktualniane jednocześnie, ponieważ limit etapu ma pierwszeństwo.

Przykład 3. Wdrożenie oparte na procentach

Etap obejmuje 20 klastrów w dwóch grupach: grupę A (osiem klastrów) i grupę B (12 klastrów).

Wynik: Łącznie do pięciu współbieżnych uaktualnień dystrybuowanych między grupami zgodnie z ich poszczególnymi limitami.

Maksymalna dozwolona liczba niepowodzeń (wersja zapoznawcza)

Maximum allowed failures to opcjonalne ustawienie strategii aktualizacji, które steruje sposobem reagowania programu Fleet Manager na błędy podczas aktualizacji wieloklastrowych.

Domyślnie aktualizacje działają zgodnie z modelem szybkiego przerywania — awaria pojedynczego klastra zatrzymuje dalsze aktualizacje. Podczas konfigurowania maximum allowed failuresprzebieg aktualizacji staje się odporny na błędy, a aktualizacje będą kontynuowane w klastrach do momentu osiągnięcia określonego progu niepowodzenia.

To ustawienie zapewnia celową równowagę między wczesnym wykrywaniem błędów a utrzymaniem tempa wdrażania. Ustaw maximum allowed failures na dwóch poziomach:

• Poziom etapu: definiuje maksymalną liczbę tolerowanych niepowodzeń uaktualniania członków we wszystkich grupach w etapie, zanim etap zostanie oznaczony jako nieudany.
• Poziom grupy: Definiuje maksymalną liczbę tolerowanych niepowodzeń aktualizacji członków w określonej grupie, po przekroczeniu której grupa zostanie oznaczona jako zakończona niepowodzeniem.

Maximum allowed failures akceptuje dwie formy wartości:

• Stała liczba całkowita: na przykład "3" umożliwia maksymalnie trzy błędy klastra członkowskiego przed oznaczeniem grupy lub etapu jako niepowodzenie.
• Wartość procentowa: Na przykład "25%" dopuszcza awarie maksymalnie 25% klastrów członkowskich. W przypadku ustawień na poziomie etapu wartość procentowa jest obliczana ze wszystkich klastrów na etapie. W przypadku ustawień na poziomie grupy wartość procentowa jest obliczana z klastrów w tej grupie. Wartości procentowe są rozwiązywane podczas tworzenia przebiegu aktualizacji przy użyciu zaokrąglania limitu, na przykład 25% z 5 klastrów jest rozpoznawanych jako 2.

Usługa Fleet Manager ocenia maxAllowedFailures wyłącznie na podstawie liczby nieudanych aktualizacji członków. Nie ocenia ona współczynnika powodzenia i nie wymaga żadnej minimalnej liczby pomyślnych członków. Jeśli to ustawienie jest obecne, oznacza, Completed że skonfigurowany próg awarii nie został przekroczony w czasie, gdy menedżer Fleet Manager podjął decyzje dotyczące planowania. Completed nie oznacza, że wdrożenie przebiegło prawidłowo lub zakończyło się sukcesem.

Przykład: Ukończono z 0% skutecznością

Załóżmy, że grupa ma czterech członków i group.maxAllowedFailures jest ustawiona na wartość "4". Jeśli wszystkie cztery aktualizacje członków zakończą się niepowodzeniem, grupa nadal może zostać oznaczona Completed. Ten wynik jest oczekiwany i zamierzony, a nie usterka, ponieważ cztery błędy są równe skonfigurowanej tolerancji i dlatego nie przekraczają progu. Innymi słowy, grupa może być Completed nawet wtedy, gdy 100% jej członków nie powiodło się.

Używaj takiego progu tylko wtedy, jeśli takie działanie odpowiada Twoim oczekiwaniom dotyczącym wdrażania.

Starannie wybieraj wartości progowe

• Wartości bezwzględne są łatwe do zrozumienia, ale mogą generować sprzeczne wyniki w małych grupach. Na przykład dopuszczenie "2" niepowodzeń w grupie dwuosobowej oznacza, że grupa może zostać uznana za zakończoną Completed, nawet jeśli żaden z członków nie zakończył się pomyślnie.
• Wartości procentowe są lepiej skalowane w różnych rozmiarach grup, dlatego są zalecane dla większości użytkowników.
• Unikaj ustawiania wartości maxAllowedFailures na poziomie całkowitej liczby członków, chyba że celowo chcesz uzyskać zachowanie w praktyce oznaczające „nigdy nie kończ niepowodzeniem z powodu awarii członków”. Jeśli to zachowanie jest zamierzone, 100% zwykle skaluje się bardziej wyraźnie niż stała liczba.
• Należy zachować szczególną ostrożność w przypadku małych grup, w których pojedynczy błąd może reprezentować duży procent wdrożenia.
• Przeszacuj próg w miarę wzrostu floty. Wartość, która jest bezpieczna dla pięciu klastrów, może być zbyt ścisła lub zbyt restrykcyjna dla 500 klastrów.

Poznaj FailureCount

Pola FailureCount to metryki raportowania. Zliczają nieudane aktualizacje członków. Nie są one współczynnikami ani wartościami procentowymi i nie są takie same jak skonfigurowany próg wymuszania.

• UpdateRun.FailureCount: Łączna liczba nieudanych aktualizacji składowych we wszystkich etapach i wszystkich grupach w przebiegu.
• Stage.FailureCount: Łączna liczba nieudanych aktualizacji członków we wszystkich grupach na tym etapie.
• Group.FailureCount: Łączna liczba nieudanych aktualizacji członków w tej grupie.

Przed podjęciem decyzji, czy wynik wdrożenia jest akceptowalny, należy zawsze przeglądać te liczby wraz ze stanami, warunkami i komunikatami o błędach na poziomie członka.

Dlaczego parametr FailureCount może przekraczać wartość maxAllowedFailures

maxAllowedFailures steruje procesem decyzyjnym Fleet Managera dotyczącym tego, czy kontynuować planowanie nowych zadań. Nie jest to twarda górna granica końcowej zgłoszonej liczby awarii.

Jeśli zezwolisz na równoległe aktualizacje członków za pomocą maxConcurrency, kilku członków może zakończyć aktualizację niepowodzeniem niemal w tym samym czasie, zanim Fleet Manager zauważy, że próg został przekroczony, i przestanie planować kolejne zadania. W rezultacie jest możliwe i należy się spodziewać, że FailureCount będzie większe niż skonfigurowana wartość maxAllowedFailures.

Jak oddziałują na siebie limity niepowodzeń etapów i grup

Poziom grupy i poziom maxAllowedFailures etapu są oceniane niezależnie:

• Każda grupa śledzi własną liczbę niepowodzeń względem własnego progu.
• Te same awarie grupy są również agregowane na poziomie etapu FailureCount.
• Jeśli którykolwiek z progów zostanie przekroczony, usługa Fleet Manager przestanie planować nową pracę dla tego segmentu.
• Rozpoczęte aktualizacje członków mogą się jeszcze zakończyć, co może zwiększyć końcowo raportowaną wartość FailureCount po podjęciu decyzji o zatrzymaniu.

Poziom etapu maxAllowedFailures działa jako ogólny pułap tolerancji awarii na etapie. Nawet jeśli poszczególne grupy zezwalają na wyższe liczby niepowodzeń, limit etapu ma pierwszeństwo. Jeśli liczba niepowodzeń grupy przekracza własną maxAllowedFailureswartość , ta grupa jest oznaczona jako nieudana niezależnie od ustawienia na poziomie etapu.

Przykład 1: Stałe limity błędów

Wynik: Grupa A toleruje maksymalnie dwa błędy, a grupa B toleruje maksymalnie trzy. Jeśli łączna liczba niepowodzeń w całym etapie przekroczy pięć, etap zakończy się niepowodzeniem.

Przykład 2. Tolerancja procentowa

Etap obejmuje 19 klastrów w dwóch grupach: grupę A z 7 klastrami i grupę B z 12 klastrami.

Zalecane i nierozpoznane zastosowania

Stosuj wyższe lub procentowe progi, gdy uaktualniasz duże floty urządzeń, spodziewasz się przejściowych niepowodzeń albo gdy postęp wdrażania jest ważniejszy niż rygorystyczne przerywanie procesu po pierwszych błędach.

Używaj 0 lub bardzo małych wartości w przypadku wdrożeń o krytycznym znaczeniu dla bezpieczeństwa, ściśle kontrolowanych faz produkcyjnych lub wszędzie tam, gdzie po pierwszym niepowodzeniu trzeba się zatrzymać i przeprowadzić kontrolę.

Następne kroki

• Instrukcja: Aktualizacja wielu klastrów przy użyciu przebiegów aktualizacji w Azure Kubernetes Fleet Manager.
• Jak: automatyczne uaktualnianie wielu klastrów przy użyciu usługi Azure Kubernetes Fleet Manager.
• How-to: Monitorowanie przebiegów aktualizacji dla usługi Azure Kubernetes Fleet Manager.
• Często zadawane pytania dotyczące aktualizacji wielu klastrów.