Jak działają uaktualnienia klastra usługi Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) wykonuje uaktualnienia stopniowe, aby zminimalizować zakłócenia działania obciążeń.

W przypadku większości obciążeń produkcyjnych usługa AKS Automatic jest zalecaną wartością domyślną, jeśli ma to zastosowanie. Usługa AKS Automatic obejmuje ustawienia domyślne gotowe do produkcji dla operacji uaktualniania, takie jak automatyczne uaktualnienia wersji platformy Kubernetes, aktualizacje obrazów systemu operacyjnego (OS), zarządzane operacje węzłów systemowych i wbudowane zabezpieczenia, które zmniejszają ręczne obciążenie. Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi AKS Automatic.

W tym artykule opisano mechanikę uaktualniania usługi AKS i wyróżniono różnice między usługami AKS Automatic i AKS Standard.

Wymagania wstępne

Model uaktualniania: AKS Automatic i AKS Standard

Tryby klastra AKS Automatic i AKS Standard opierają się na tych samych podstawowych mechanizmach uaktualniania Kubernetes, ale różnią się ustawieniami domyślnymi i zakresem odpowiedzialności operacyjnej.

Problem z aktualizacją Automatyczne usługi AKS AKS Standard
Pozycjonowanie produkcyjne Zalecana wartość domyślna dla większości obciążeń produkcyjnych, jeśli ma to zastosowanie Elastyczny model z bardziej ręczną konfiguracją domyślnie
Aktualizacje pomniejszych wersji Kubernetes Wstępnie skonfigurowany kanał automatycznej aktualizacji Domyślnie ręczny, opcjonalny kanał automatyczny
Uaktualnienia obrazu systemu operacyjnego Node Wstępnie skonfigurowany automatyczny kanał obrazu systemu operacyjnego węzła Domyślnie ręczny, opcjonalny kanał automatyczny
Operacje puli węzłów systemowych Zarządzane przez AKS Zarządzane przez klienta
Planowane terminy konserwacji Dostępne domyślnie Opcjonalna konfiguracja
Mechanizmy kontroli zakłóceń obciążeń Zarządzane przez klienta, w tym strategia replik, zachowanie gotowości i polityka zakłóceń Zarządzane przez klienta, w tym strategia replik, zachowanie gotowości i polityka zakłóceń

Note

Usługa AKS Automatic upraszcza operacje platformy, ale nadal ma zastosowanie wspólna odpowiedzialność. Projekt dostępności na poziomie obciążenia oraz działanie zasad eksmisji pozostają po stronie klienta.

Działanie aktualizacji stopniowej w usłudze AKS

Usługa AKS aktualizuje pule węzłów w sposób stopniowy, który utrzymuje dostępną pojemność podczas zastępowania lub ponownego obrazowania węzłów. To zachowanie jest takie samo we wszystkich trybach klastra AKS.

Ogólnie rzecz biorąc, AKS:

  1. Dodaje tymczasową dodatkową pojemność na podstawie ustawień aktualizacji.
  2. Cordons i opróżnia węzły w celu przenoszenia obciążeń.
  3. Ponownie tworzy obrazy węzłów lub zastępuje je docelową wersją.
  4. Usuwa tymczasowo zwiększoną wydajność po zakończeniu.

Przykład uaktualnienia stopniowego

W tym przykładzie pokazano uaktualnienie klastra z dwoma węzłami z Kubernetes 1.30 do 1.31, przy ustawieniu maxSurge na 1.

Krok 1. Konfiguracja początkowa

Klaster rozpoczyna się od dwóch węzłów z systemem w wersji 1.30, z których każdy hostuje zasobniki aplikacji.

Diagram przedstawiający początkową konfigurację klastra z dwoma węzłami w wersji 1.30, z których każda hostuje zasobniki aplikacji, oraz nowo utworzony węzeł Surge Node.

  • Węzeł 1: Pod A, Pod B
  • Węzeł 2: Pod C, Pod D
  • Surge Node: pusty (z wyjątkiem DaemonSets i nowych zasobników)

Krok 2. Zablokuj i opróżnij pierwszy węzeł

Usługa AKS cordonuje Node 1, aby zapobiec planowaniu nowych zasobników, a następnie odprowadza istniejące zasobniki.

Diagram pokazujący, że węzeł Node 1 jest kordonowany i opróżniany, z zasobnikami usuwanymi i zastępowanymi na innych dostępnych węzłach.

  • Pod A → usunięty i zastąpiony w węźle Surge Node
  • Pod B → usunięty i zastąpiony na węźle 2

Krok 3. Uaktualnianie pierwszego węzła

Węzeł 1 jest przeinstalowywany z wersją 1.31 systemu Kubernetes, podczas gdy zasobniki nadal działają na innych węzłach.

Diagram przedstawiający węzeł Node 1 ponownie utworzony z obrazu w wersji 1.31, podczas gdy pody aplikacji nadal działają na węźle Node 2 i na węźle Surge.

  • Węzeł 1: Uaktualniono do wersji 1.31
  • Węzeł 2: Pod B, Pod C, Pod D
  • Węzeł skokowy: Pod A

Krok 4. Cordon i opróżnianie drugiego węzła

AKS powtarza proces dla węzła 2, kontenery są eksmitowane, a harmonogram rozmieszcza je ponownie w odpowiednich dostępnych węzłach.

Diagram przedstawiający węzeł Node 2 wyłączony z harmonogramowania i opróżniany z zasobników, przy czym eksmitowane zasobniki są odtwarzane na zaktualizowanym węźle Node 1 oraz na węźle Surge Node.

  • Pod C, B → usunięty i zastąpiony na węźle 1
  • Zasobnik D → usunięty i zastąpiony na węźle Surge
  • Węzeł 2: odizolowany i zaktualizowany do obrazu wersji 1.31

Krok 5. Usuwanie węzła przepięcia

Po uaktualnieniu wszystkich stałych węzłów węzeł skokowy jest odprowadzany, opróżniany i usuwany.

Diagram przedstawiający osuszanie i usuwanie węzła Surge oraz eksmitowanie i zastępowanie zasobników na zaktualizowanych węzłach stałych.

  • Zasobnik A → eksmitowany i zastąpiony na węźle 1
  • Pod D → usunięty i zastąpiony na węźle 2
  • Węzeł rozruchowy: usunięty

Stan końcowy

Wszystkie węzły teraz działają na Kubernetes w wersji 1.31 z podami rozłożonymi w klastrze.

  • Węzeł 1 (wersja 1.31): Pod A, Pod C
  • Węzeł 2 (wersja 1.31): Pod B, Pod D

Zachowanie restrykcyjnego Pod Disruption Budget (PDB)

Jeśli restrykcyjne bloki PDB blokują eksmisję, opróżnianie węzłów może być opóźnione lub uniemożliwione. Usługa AKS może używać zachowania Cordon dla nieopróżnialnego węzła, aby kontynuować aktualizowanie innych węzłów spełniających warunki zgodnie ze skonfigurowanym ustawieniem. Zablokowane węzły mogą pozostać w starszej wersji do momentu rozwiązania warunku blokowania.

Przykład restrykcyjnego pliku PDB

W tym przykładzie pokazano aktualizację dwuwęzłowego klastra z Kubernetes 1.30 do 1.31 z ustawieniem maxSurge na 2, przy czym PDB blokuje operację opróżniania pierwszego węzła.

Krok 1. Początkowa konfiguracja z restrykcyjnym plikiem PDB

Klaster rozpoczyna się od dwóch węzłów działających na wersji 1.30, z Profilem Ochrony Przemieszczeń (PDB), chroniącym Pod A przed eksmisją.

Diagram przedstawiający początkowy klaster z dwoma węzłami, węzłem nadmiarowym i budżetem zakłóceń poda chroniącym pod A przed eksmisją.

  • Węzeł 1: Pod A (chroniony przez PDB), Pod B
  • Węzeł 2: Pod C, Pod D
  • Węzły skokowe: utworzono 2 nowe węzły
  • PDB: Uniemożliwia eksmisję Podu A

Krok 2. Próba opróżnienia pierwszego węzła (zablokowane)

AKS oznacza węzeł 1 jako niedostępny do planowania, ale nie może usunąć Poda A z węzła z powodu ograniczeń PDB.

Diagram pokazujący, że węzeł 1 jest oznaczony jako niedostępny, ale jego opróżnianie jest zablokowane przez budżet zakłóceń dla podów, przy czym pod A pozostaje zablokowany, a pod B zostaje eksmitowany do węzła nadmiarowego.

  • Węzeł 1: Odizolowany i oznaczony jako poddany kwarantannie (zasobnik A utknięty)
  • Pod B → Usunięty i zastąpiony na węźle Surge Node 1, podczas gdy węzeł Surge Node 2 tymczasowo nie jest używany
  • Stan: Aktualizacja węzła 1 zablokowana

Krok 3. Przejście do drugiego węzła

Po kwarantannie węzła 1 usługa AKS kontynuuje uaktualnianie węzła 2.

Diagram pokazujący, że węzeł 1 pozostaje poddany kwarantannie, podczas gdy węzeł 2 jest pomyślnie odprowadzony i opróżniany, z zasobnikami przeniesionymi do węzła Surge.

  • Węzeł 1: Pozostaje w kwarantannie (wersja 1.30)
  • Węzeł 2: Pomyślnie odizolowany i opróżniony
  • Pod C → Eksmitowany i zastąpiony na Surge Node 2
  • Pod D → usunięty i zastąpiony na węźle Surge 2

Krok 4. Uaktualnianie drugiego węzła

Węzeł 2 został pomyślnie zresetowany do wersji 1.31 na platformie Kubernetes.

Diagram przedstawiający pomyślnie uaktualniony węzeł Node 2 do wersji 1.31, podczas gdy węzeł 1 pozostaje poddany kwarantannie zasobnikowi A.

  • Węzeł 1: Nadal poddany kwarantannie (wersja 1.30) z Podem A
  • Węzeł 2: Uaktualniono do wersji 1.31
  • Węzeł awaryjny 1: Pod B
  • Węzeł sieciowy 2: Pod C, Pod D

Krok 5: Jeden węzeł Surge staje się trwałym zamiennikiem, gdy usuwany jest inny węzeł

Ponieważ węzeł 1 pozostaje w kwarantannie, węzeł Surge 1 staje się stałym zamiennikiem działającym w wersji 1.31, a węzeł Surge 2 zostaje usunięty.

Diagram pokazujący, że węzeł Surge staje się trwałym zamiennikiem w wersji 1.31, podczas gdy węzeł Node 1 pozostaje poddany kwarantannie.

  • Węzeł 1: Poddane kwarantannie (wersja 1.30) — wymaga interwencji ręcznej
  • Pod C, Pod D → usunięty z węzła Surge Node 2 i zastąpiony na Node 2
  • Węzeł Surge 1 (wersja 1.31): Zasobnik B (teraz stały)
  • Surge Node 2 (v1.31): Usunięty

Stan końcowy

Uaktualnienie kończy się z jednym węzłem poddanym kwarantannie, który wymaga interwencji ręcznej.

  • Węzeł 1: Poddany kwarantannie (wersja 1.30) z Podem A — klient musi rozwiązać problem ręcznie (zobacz Rozwiązywanie niezdrążalnych węzłów)
  • Węzeł 2 (wersja 1.31): Działa normalnie
  • Były węzeł skokowy (wersja 1.31): Teraz trwałe zastąpienie

Ważne

Węzeł poddany kwarantannie (Węzeł 1) pozostaje w obowiązkach klienta do obsługi. Musisz wykonać jedną z następujących czynności:

  • Dostosuj PDB, aby zezwolić na ewikcję Podu A.
  • Ręcznie usuń Pod A.
  • Usuń i utwórz ponownie węzeł po naprawieniu warunku blokowania.

Kluczowe zagadnienia dotyczące uaktualnień zablokowanych przez PDB

  • Niezrównane zachowanie węzła: ustaw wartość na Cordon dla puli węzłów, aby włączyć to zachowanie kwarantanny.
  • Odpowiedzialność klienta: Węzły poddane kwarantannie wymagają ręcznej interwencji w celu rozwiązania problemu.
  • Pojemność klastra: węzeł wzrostowy staje się trwały, potencjalnie wpływając na planowanie pojemności klastra.
  • Monitorowanie: śledź węzły poddane kwarantannie za pomocą Azure Monitor lub kubectl, aby zapewnić terminowe rozwiązanie.

Tip

Aby całkowicie uniknąć scenariusza kwarantanny, można użyć automatycznego zarządzania pdB do automatycznego skalowania replik wdrożenia w górę, aby ograniczenia pdB zostały spełnione przed rozpoczęciem opróżniania. Dzięki temu eksmisji można kontynuować bez blokowania, eliminując konieczność ręcznego rozwiązania kwarantanny.

Aktualizacje Blue-Green puli węzłów (sterowanie ręczne)

Uaktualnienia typu Blue-Green oferują bardziej kontrolowane podejście do aktualizacji, polegające na ręcznym utworzeniu pełnego zestawu nowych pul węzłów przed migracją obciążeń. Podejście manualne zapewnia pełną kontrolę nad procesem aktualizacji i harmonogramem.

Aby uzyskać więcej informacji, zobacz „Blue-Green” — uaktualnienia pul węzłów w usłudze AKS.

Kiedy należy używać uaktualnień Blue-Green

Ręczne uaktualnienia puli węzłów Blue-Green to zaawansowana strategia stosowana w przypadku specjalistycznych wymagań, takich jak jawne punkty kontrolne migracji, niestandardowe etapy walidacji lub ściśle kontrolowane przełączenia.

Jeśli potrzebujesz, użyj ręcznego Blue-Green:

  • Fazy migracji kontrolowane przez operatory.
  • Niestandardowe kryteria weryfikacji i akceptacji przed zatwierdzeniem.
  • Wyraźnie określona choreografia wycofywania zmian powiązana z wewnętrznymi runbookami.

W przypadku większości obciążeń produkcyjnych, tam gdzie ma to zastosowanie, domyślny sposób aktualizacji w AKS Automatic jest zalecanym punktem wyjścia, a ręczne wdrożenie Blue-Green stosuje się zwykle tylko w wyjątkowych przypadkach.

Najważniejsze pojęcia

  • Niebieska pula węzłów: istniejąca pula węzłów z bieżącą wersją platformy Kubernetes.
  • Zielona pula węzłów: nowa pula węzłów, którą tworzysz, uruchamia docelową wersję platformy Kubernetes.
  • Sterowanie ręczne: zarządzasz wszystkimi aspektami procesu migracji.
  • Punkty kontrolne weryfikacji: decydujesz, kiedy kontynuować, wstrzymać lub wycofać.

Korzyści wynikające z uaktualnień Blue-Green

  • Pełna kontrola: decydujesz dokładnie, kiedy wystąpi każdy krok.
  • Walidacja niestandardowa: zaimplementuj własne kryteria walidacji i chronometraż.
  • Migracja stopniowa: przenoszenie obciążeń w preferowanym tempie.
  • Łatwe wycofywanie: oryginalne węzły pozostają dostępne do momentu ich usunięcia.

Kluczowe zagadnienia dotyczące uaktualnień Blue-Green

  • Nakład pracy ręcznej: wymaga aktywnego zarządzania w całym procesie.
  • Wymagania dotyczące limitu przydziału: wymaga 2x pojemności węzła podczas uaktualniania.
  • Planowanie: udokumentowanie kryteriów weryfikacji i procedur wycofywania.

Przykład ręcznego procesu uaktualniania Blue-Green

W tym przykładzie pokazano ręczne uaktualnianie klastra dwuwęzłowego z Kubernetes 1.30 do 1.31 przy użyciu metody wdrażania Blue-Green.

Krok 1. Tworzenie puli zielonych węzłów

Zacznij od ręcznego utworzenia nowej puli węzłów z docelową wersją Kubernetes, obok istniejącej puli węzłów.

Diagram pokazujący początkową konfigurację wdrożenia Blue-Green z pulą węzłów Blue działającą w wersji 1.30 oraz nowo utworzoną pulą węzłów Green działającą w wersji 1.31.

  • Niebieska pula węzłów (wersja 1.30): Pod A, Pod B, Pod C, Pod D (istniejące)
  • Zielona pula węzłów (wersja 1.31): Pusta (utworzona ręcznie)
  • Twoja akcja: az aks nodepool add z nową wersją rozwiązania Kubernetes

Krok 2: Ręcznie odseparować niebieskie węzły

Oznacz niebieskie węzły jako niedostępne do planowania nowych podów, pozostawiając już uruchomione pody bez zmian.

  • Twoja akcja: kubectl cordon na każdym niebieskim węźle
  • Niebieskie węzły: Odgrodzone, brak zaplanowanych nowych podów
  • Zielone węzły: Gotowe do odbierania obciążeń

Krok 3. Ręczne opróżnianie niebieskich węzłów (kontrolowane tempo)

Tempo migracji można kontrolować przez ręczne opróżnianie węzłów pojedynczo lub w partiach.

Diagram pokazujący opróżnianie węzła Blue, z którego pody są usuwane i zastępowane w puli węzłów Green, oraz opróżnianie drugiego węzła Blue, z którego pozostałe pody są migrowane do puli węzłów Green.

  • Akcja: kubectl drain na wybranych niebieskich węzłach
  • Migracja podów: Pody są automatycznie ponownie przypisane do zielonych węzłów
  • Walidacja: Przed kontynuowaniem sprawdź obciążenia na zielonych węzłach

Krok 4. Weryfikowanie i podejmowanie decyzji

Po przeprowadzeniu migracji obciążeń zweryfikuj wydajność aplikacji w zielonych węzłach.

Diagram pokazujący fazę walidacji, w której wszystkie obciążenia robocze działają w zielonej puli węzłów, podczas gdy niebieska pula węzłów pozostaje gotowa do wycofania zmian.

W tej fazie można wykonywać następujące czynności:

  • Monitorowanie: sprawdzanie metryk i dzienników aplikacji
  • Test: Uruchom testy weryfikacyjne w zielonej puli węzłów
  • Zdecyduj: Zatwierdź na zielono lub wycofaj na niebieski

Krok 5. Zatwierdzanie lub wycofywanie

Na podstawie swojej weryfikacji ręcznie dokonujesz uaktualnienia lub wycofania.

Opcja A — zatwierdź (sukces):

Diagram przedstawiający pomyślne zatwierdzenie z usuniętą pulą niebieskich węzłów, a pula zielonych węzłów staje się pulą węzłów podstawowych.

  • Twoja akcja: Usuń niebieską pulę węzłów przy użyciu polecenia az aks nodepool delete
  • Wynik: Pula węzłów zielonych staje się główną

Opcja B — wycofanie (wykryto problemy):

Diagram przedstawiający wycofanie, w którym obciążenia wracają do niebieskiej puli węzłów, a zielona pula węzłów zostaje usunięta.

  • Twoja akcja: Odznacz niebieskie węzły jako niedostępne przy użyciu kubectl uncordon, wydrenuj zielone węzły przy użyciu kubectl drain i usuń zieloną pulę węzłów przy użyciu az aks nodepool delete
  • Wynik: Obciążenia wracają do węzłów niebieskich

Aspekty środowiska produkcyjnego przy planowaniu uaktualnienia

  • Konfiguracja nadmiaru (maxSurge): określa liczbę nadmiarowych węzłów tworzonych podczas aktualizacji. Wyższe wartości przyspieszają uaktualnienia, ale zużywają więcej zasobów.
  • Budżety zakłóceń podów (PDB): Skonfiguruj budżety PDB, aby zapewnić dostępność aplikacji podczas procesu aktualizacji.
  • Uaktualnienia puli węzłów: Każda pula węzłów uaktualnia się niezależnie. Odpowiednio zaplanuj strategię uaktualniania.
  • Pojemność i limit przydziału: przed uaktualnieniem okna sprawdź wymagania dotyczące pojemności tymczasowej i stałej.
  • Monitorowanie i alerty: skonfiguruj monitorowanie i alerty przed rozpoczęciem uaktualniania.

W usłudze AKS Automatic kilka opcji uaktualnienia na poziomie platformy jest wstępnie skonfigurowanych pod kątem gotowości produkcyjnej. W usłudze AKS Standard zespoły zazwyczaj jawnie podejmują te decyzje.

Treści powiązane

  • Last updated on