Aktualizowanie orkiestracji w wielu klastrach członkowskich

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

• 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. Strategię można ponownie użyć w przebiegach aktualizacji zamiast wielokrotnie definiować sekwencję w każdym przebiegu.

Obecnie obsługiwane operacje aktualizacji w klastrze 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).
• Uaktualnianie wersji platformy Kubernetes tylko dla płaszczyzn 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ładnych wersji obrazu węzła docelowego, ponieważ najnowsze dostępne wersje obrazów węzłów mogą się różnić w zależności od regionu klastra (sprawdź monitor wersji, 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 klastra po uruchomieniu uaktualnienia klastra. W związku z tym różne wersje obrazów mogą być używane w zależności od regionu, w którym znajduje się klaster i kiedy faktycznie zostanie uruchomione jego uaktualnienie.
• Consistent: Po uruchomieniu przebiegu aktualizacji wybierane są najnowsze typowe wersje obrazów w regionach 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:

1. Element członkowski z otwartym trwającym oknem obsługi.
2. Element członkowski z otwarciem okna obsługi w ciągu najbliższych czterech godzin.
3. Element członkowski bez okna obsługi.
4. 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: stan uruchomienia aktualizacji przed jego uruchomieniem.

• Uruchomione: uaktualnianie jest w toku dla co najmniej jednego z klastrów w przebiegu aktualizacji.

• Oczekująca:

  • Klaster członkowski: klaster członkowski może znajdować się w stanie oczekiwania z dowolnego z następujących powodów i jest wyświetlany 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 elementu członkowskiego. 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 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 w grupach 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 są w Pending stanie, grupa zostanie przeniesiona do Pending stanu. Wszystkie grupy muszą być w stanie terminalu przed przejściem do następnego etapu. Oznacza to, że jeśli grupa jest w Pending stanie, uruchomienie aktualizacji czeka na ukończenie przed przejściem do następnego etapu wykonywania.
  • Etap: etap znajduje się, Pending jeśli wszystkie grupy na 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. Może to być wykryte przez system lub zainicjowane przez użytkownika.

  • Członek:
    • Pominięto uaktualnienie dla członka lub jednego z jego rodziców.
    • 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. Przykładową sytuacją jest dodanie nowej puli węzłów z nową jednostkę SKU maszyny wirtualnej 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 wchodzi w stan zatrzymania i nie są obsługiwane dla żadnego kolejnego klastra w przebiegu aktualizacji.

• Niepowodzenie: Niepowodzenie uaktualnienia klastra spowoduje 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.

Następne kroki

• Organizowanie aktualizacji w wielu klastrach członkowskich.