Udostępnij za pośrednictwem


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.

Diagram przedstawiający przebieg uaktualnienia zawierający dwa etapy aktualizacji, z których każdy zawiera dwie grupy aktualizacji z dwoma klastrami składowymi.

  • 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