Udostępnij za pośrednictwem


Wskazówki dotyczące poprawek i uaktualniania usługi Azure Kubernetes Service

W tej sekcji przewodnika operacyjnego usługi Azure Kubernetes Service (AKS) 2 opisano strategie stosowania poprawek i uaktualniania węzłów roboczych usługi AKS oraz wersji rozwiązania Kubernetes. Jako operator klastra musisz mieć plan aktualizowania klastrów i monitorowania zmian i wycofywania interfejsu API kubernetes w czasie.

Tło i typy aktualizacji

Istnieją trzy typy aktualizacji usługi AKS, z których każda jest oparta na następnej:

Typ aktualizacji Częstotliwość uaktualniania Obsługiwana planowana konserwacja Obsługiwane metody operacji Obiekt docelowy Link do dokumentacji
Poprawki zabezpieczeń systemu operacyjnego Node Nocny Tak Automatyczne (co tydzień), ręczne/niezarządzane (w nocy) Węzeł Automatyczne uaktualnianie obrazów węzłów
Uaktualnienia wersji obrazu węzła Linux: Co tydzień
Windows: miesięczny
Tak Automatyczne, ręczne Pula węzłów Uaktualnianie obrazu węzła usługi AKS
Uaktualnienia wersji platformy Kubernetes (klastra) Co kwartał Tak Automatyczne, ręczne Pula klastrów i węzłów Uaktualnianie klastra usługi AKS

Typy aktualizacji

  • Poprawki zabezpieczeń systemu operacyjnego Node (tylko system Linux). W przypadku węzłów systemu Linux systemy Canonical Ubuntu i Azure Linux udostępniają poprawki zabezpieczeń systemu operacyjnego raz dziennie. Firma Microsoft testuje i pakuje te poprawki w cotygodniowych aktualizacjach obrazów węzłów.

  • Cotygodniowe aktualizacje obrazów węzłów. Usługa AKS udostępnia cotygodniowe aktualizacje obrazów węzłów. Te aktualizacje obejmują najnowsze poprawki zabezpieczeń systemu operacyjnego i usługi AKS, poprawki błędów i ulepszenia. Aktualizacje węzła nie zmieniają wersji rozwiązania Kubernetes. Wersje są formatowane według daty (na przykład 202311.07.0) dla systemu Linux oraz według daty i kompilacji systemu operacyjnego Windows Server (na przykład 20348.2113.231115) dla systemu Windows. Aby uzyskać więcej informacji, zobacz Stan wydania usługi AKS.

  • Kwartalne wersje platformy Kubernetes. Usługa AKS udostępnia kwartalne aktualizacje dla wydań platformy Kubernetes. Te aktualizacje umożliwiają użytkownikom usługi AKS korzystanie z najnowszych funkcji i ulepszeń platformy Kubernetes. Obejmują one poprawki zabezpieczeń i aktualizacje obrazu węzła. Aby uzyskać więcej informacji, zobacz Obsługiwane wersje platformy Kubernetes w usłudze AKS.

Zagadnienia dotyczące przed uaktualnieniem

Ogólny wpływ klastra

  • Uaktualnienia w miejscu (zarówno węzeł, jak i klaster) wpływają na wydajność środowiska Kubernetes, gdy są one w toku. Ten efekt można zminimalizować poprzez właściwą konfigurację budżetów zakłóceń zasobników, konfigurację skoków węzłów i odpowiednie planowanie.
  • Użycie strategii niebieskiej/zielonej aktualizacji zamiast uaktualniania w miejscu eliminuje wpływ na wydajność klastra, ale zwiększa koszt i złożoność.
  • Niezależnie od strategii uaktualniania i stosowania poprawek musisz mieć niezawodny proces testowania i walidacji dla klastra. Najpierw popraw i uaktualnij niższe środowiska oraz przeprowadź weryfikację po konserwacji, aby sprawdzić kondycję klastra, węzła, wdrożenia i aplikacji.

Najlepsze rozwiązania dotyczące obciążeń usługi AKS

Aby zapewnić bezproblemową obsługę klastra usługi AKS podczas konserwacji, postępuj zgodnie z następującymi najlepszymi rozwiązaniami:

  • Zdefiniuj budżety zakłóceń zasobników (PDB). Konfigurowanie budżetów zakłóceń zasobników dla wdrożeń jest niezbędne. Pliki PDB wymuszają minimalną liczbę dostępnych replik aplikacji w celu zapewnienia ciągłej funkcjonalności podczas zakłóceń. Pliki PDB pomagają zachować stabilność klastra podczas konserwacji lub awarii węzła.

    Ostrzeżenie

    Błędnie skonfigurowane pliki PDB mogą blokować proces uaktualniania, ponieważ interfejs API Kubernetes zapobiega niezbędnemu kordonowi i opróżnianiu, które występuje podczas uaktualniania obrazu węzła stopniowego. Ponadto jeśli zbyt wiele zasobników zostanie przeniesionych jednocześnie, może wystąpić awaria aplikacji. Konfiguracja pliku PDB ogranicza to ryzyko.

  • Sprawdź dostępne limity zasobów obliczeniowych i sieciowych. Sprawdź dostępne limity obliczeniowe i sieciowe w subskrypcji platformy Azure za pośrednictwem strony limitu przydziału w witrynie Azure Portal lub za pomocą polecenia az quota . Sprawdź zasoby obliczeniowe i sieciowe, zwłaszcza procesory wirtualne maszyn wirtualnych dla węzłów oraz liczbę maszyn wirtualnych i zestawów skalowania maszyn wirtualnych. Jeśli zbliżasz się do limitu, przed uaktualnieniem zażądaj zwiększenia limitu przydziału.
  • Sprawdź dostępną przestrzeń IP w podsieciach węzłów. Podczas aktualizacji dodatkowe węzły przepięcia są tworzone w klastrze, a zasobniki są przenoszone do tych węzłów. Ważne jest, aby monitorować przestrzeń adresów IP w podsieciach węzłów, aby zapewnić wystarczającą przestrzeń adresową dla tych zmian. Różne konfiguracje sieci Kubernetes mają różne wymagania dotyczące adresów IP. Na początek zapoznaj się z następującymi zagadnieniami:
    • Podczas uaktualniania liczba adresów IP węzłów zwiększa się zgodnie z wartością wzrostu. (Minimalna wartość skoku wynosi 1).
    • Klastry oparte na usłudze Azure CNI przypisują adresy IP do poszczególnych zasobników, więc musi być wystarczająca ilość miejsca na adres IP do przenoszenia zasobników.
    • Klaster nadal działa podczas uaktualniania. Upewnij się, że pozostało wystarczająco dużo miejsca na adres IP, aby umożliwić skalowanie węzłów (jeśli jest włączone).
  • Konfigurowanie wielu środowisk. Zalecamy skonfigurowanie oddzielnych środowisk, takich jak programowanie, przemieszczanie i produkcja, aby umożliwić testowanie i weryfikowanie zmian przed ich wdrożeniem w środowisku produkcyjnym.
  • Dostrajanie wartości uaktualniania skoków. Domyślnie usługa AKS ma wartość wzrostu 1, co oznacza, że jeden dodatkowy węzeł jest tworzony jednocześnie w ramach procesu uaktualniania. Szybkość uaktualniania usługi AKS można zwiększyć, zwiększając tę wartość. 33% wzrost jest zalecaną maksymalną wartością dla obciążeń, które są wrażliwe na zakłócenia. Aby uzyskać więcej informacji, zobacz Dostosowywanie uaktualniania skoków węzłów.
  • Dostrajanie limitu czasu opróżniania węzła. Limit czasu opróżniania węzła określa maksymalny czas oczekiwania klastra podczas próby ponownego utworzenia zasobników w węźle, który jest aktualizowany. Wartość domyślna dla tej wartości to 30 minut. W przypadku obciążeń, które mają trudności ze zmianą harmonogramów zasobników, warto dostosować tę wartość domyślną.
  • Planowanie i planowanie okien obsługi. Procesy uaktualniania mogą mieć wpływ na ogólną wydajność klastra Kubernetes. Planowanie procesów uaktualniania w miejscu poza szczytowym użyciem i monitorowanie wydajności klastra w celu zapewnienia odpowiedniego rozmiaru, szczególnie podczas procesów aktualizacji.
  • Sprawdź inne zależności w klastrze. Operatory kubernetes często wdrażają inne narzędzia w klastrze Kubernetes w ramach operacji, takich jak moduły skalowania KEDA, narzędzia Dapr i siatki usług. Podczas planowania procesów uaktualniania sprawdź informacje o wersji dla wszystkich składników, których używasz, aby zapewnić zgodność z wersją docelową.

Zarządzanie cotygodniowymi aktualizacjami obrazów węzłów

Firma Microsoft tworzy nowy obraz węzła dla węzłów usługi AKS około raz w tygodniu. Obraz węzła zawiera aktualne poprawki zabezpieczeń systemu operacyjnego, aktualizacje jądra systemu operacyjnego, aktualizacje zabezpieczeń platformy Kubernetes, zaktualizowane wersje plików binarnych, takie jak kubelet i aktualizacje wersji składników wymienione w informacjach o wersji.

Po zaktualizowaniu obrazu węzła akcja cordonu i opróżniania jest wyzwalana w węzłach puli węzłów docelowych:

  • Węzeł ze zaktualizowanym obrazem jest dodawany do puli węzłów. Liczba węzłów dodanych w tym samym czasie jest określana przez wartość skoku.
  • W zależności od wartości skoku partia istniejących węzłów jest odprowadzana i opróżniana. Cordoning gwarantuje, że węzeł nie planuje zasobników. Opróżnianie usuwa jego zasobniki i planuje je do innych węzłów.
  • Po pełnym opróżnieniu tych węzłów zostaną one usunięte z puli węzłów. Zaktualizowane węzły dodane przez przepięcia zastępują je.
  • Ten proces jest powtarzany dla każdej pozostałej partii węzłów, które muszą zostać zaktualizowane w puli węzłów.

Podobny proces występuje podczas uaktualniania klastra.

Automatyczne uaktualnienia obrazu węzła

Mówiąc ogólnie, większość klastrów powinna używać kanału NodeImage aktualizacji. Ten kanał udostępnia co tydzień zaktualizowany dysk VHD obrazu węzła i jest aktualizowany zgodnie z oknem obsługi klastra.

Dostępne kanały obejmują następujące elementy:

  • None. Aktualizacje nie są automatycznie stosowane.
  • Unmanaged. Aktualizacje systemu Ubuntu i Azure Linux są stosowane przez system operacyjny w nocy. Ponowne rozruchy muszą być zarządzane oddzielnie. Usługa AKS nie może tego przetestować ani kontrolować tempa tego.
  • SecurityPatch. Poprawki zabezpieczeń systemu operacyjnego, które są testowane przez usługę AKS, w pełni zarządzane i stosowane przy użyciu bezpiecznych praktyk wdrażania. Nie zawiera żadnych poprawek błędów systemu operacyjnego tylko aktualizacji zabezpieczeń.
  • NodeImage. Usługa AKS aktualizuje węzły przy użyciu nowo poprawionego wirtualnego dysku twardego zawierającego poprawki zabezpieczeń i poprawki błędów co tydzień. Jest to w pełni przetestowane i wdrożone przy użyciu bezpiecznych praktyk wdrażania. Aby uzyskać informacje o aktualnie wdrożonych obrazach węzłów w czasie rzeczywistym, zobacz Aktualizacje obrazu węzła usługi AKS.

Aby zrozumieć domyślne cykle bez ustalonego okna obsługi, zobacz aktualizowanie własności i kadencji.

Jeśli wybierzesz Unmanaged kanał aktualizacji, musisz zarządzać procesem ponownego uruchamiania przy użyciu narzędzia takiego jak kured. Unmanaged nie jest dostarczany z praktykami bezpiecznego wdrażania zapewnianymi przez usługę AKS i nie będzie działać w oknach obsługi. Jeśli wybierzesz SecurityPatch kanał aktualizacji, aktualizacje można stosować tak często, jak co tydzień. Ten poziom poprawek wymaga przechowywania wirtualnych dysków twardych w grupie zasobów, co powoduje naliczanie nominalnej opłaty. Kontroluj SecurityPatch , kiedy element jest stosowany, ustawiając odpowiedni aksManagedNodeOSUpgradeSchedule element, który jest zgodny z cyklem, który najlepiej sprawdza się w przypadku obciążenia. Aby uzyskać więcej informacji, zobacz Tworzenie okna obsługi. Jeśli potrzebujesz również poprawek błędów, które są zwykle dostarczane z nowymi obrazami węzłów (VHD), musisz wybrać NodeImage kanał zamiast SecurityPatch.

Najlepszym rozwiązaniem jest użycie kanału NodeImage aktualizacji i skonfigurowanie aksManagedNodeOSUpgradeSchedule okna obsługi do czasu, gdy klaster znajduje się poza oknami szczytowego użycia. Zobacz Tworzenie okna obsługi dla atrybutów, których można użyć do skonfigurowania okna obsługi klastra. Kluczowe atrybuty to:

  • name. Służy aksManagedNodeOSUpgradeSchedule do aktualizacji systemu operacyjnego węzła.
  • utcOffset. Skonfiguruj strefę czasową.
  • startTime. Ustaw godzinę rozpoczęcia okna obsługi.
  • dayofWeek. Ustaw dni tygodnia dla okna. Na przykład Saturday.
  • schedule. Ustaw częstotliwość okna. W przypadku NodeImage aktualizacji zalecamy .weekly
  • durationHours. Ustaw ten atrybut na co najmniej cztery godziny.

W tym przykładzie ustawiono tygodniowe okno obsługi na 8:00 czasu wschodniego w soboty:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Aby uzyskać więcej przykładów, zobacz Dodawanie konfiguracji okna obsługi za pomocą interfejsu wiersza polecenia platformy Azure.

Ta konfiguracja zostałaby najlepiej wdrożona w ramach wdrożenia infrastruktury jako kodu klastra.

Możesz sprawdzić skonfigurowane okna obsługi przy użyciu interfejsu wiersza polecenia platformy Azure:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Możesz również sprawdzić szczegóły określonego okna obsługi przy użyciu interfejsu wiersza polecenia:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Jeśli okno obsługi klastra nie jest skonfigurowane, aktualizacje obrazu węzła są wykonywane dwutygodnie. Jak najwięcej, konserwacja usługi AKS odbywa się w skonfigurowanym oknie, ale czas konserwacji nie jest gwarantowany.

Ważne

Jeśli masz pulę węzłów z dużą liczbą węzłów, ale nie jest ona skonfigurowana ze wzrostem węzła, zdarzenie automatycznego uaktualniania może nie być wyzwalane. Obrazy węzłów w puli węzłów zostaną uaktualnione tylko wtedy, gdy szacowany całkowity czas uaktualniania wynosi 24 godziny.

W takiej sytuacji można rozważyć jedną z następujących kwestii:

  • dzielenie węzłów na różne pule węzłów, jeśli limit przydziału procesorów wirtualnych jest prawie pełny i nie można zwiększyć limitu przydziału procesorów wirtualnych
  • konfigurowanie wzrostu węzła w celu zmniejszenia szacowany czas uaktualniania, jeśli limit przydziału procesorów wirtualnych jest wystarczający

Stan zdarzeń uaktualniania można sprawdzić za pomocą dzienników aktywności platformy Azure lub przeglądając dzienniki zasobów w klastrze.

Możesz subskrybować zdarzenia usługi Azure Kubernetes Service (AKS) za pomocą usługi Azure Event Grid , która obejmuje zdarzenia uaktualniania usługi AKS. Te zdarzenia mogą otrzymywać alerty, gdy jest dostępna nowa wersja rozwiązania Kubernetes i pomaga śledzić zmiany stanu węzła podczas procesów uaktualniania.

Możesz również zarządzać cotygodniowym procesem aktualizacji przy użyciu funkcji GitHub Actions. Ta metoda zapewnia bardziej szczegółową kontrolę procesu aktualizacji.

Proces ręcznej aktualizacji węzła

Za pomocą polecenia kubectl describe nodes można określić wersję jądra systemu operacyjnego i wersję obrazu systemu operacyjnego węzłów w klastrze:

kubectl describe nodes <NodeName>

Przykładowe dane wyjściowe (obcięte):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Użyj polecenia az aks nodepool list interfejsu wiersza polecenia platformy Azure, aby określić wersje obrazów węzłów w klastrze:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Przykładowe wyjście:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Użyj polecenia az aks nodepool get-upgrades , aby określić najnowszą dostępną wersję obrazu węzła dla określonej puli węzłów:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Przykładowe wyjście:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Uaktualnienia klastra

Społeczność platformy Kubernetes udostępnia wersje pomocnicze platformy Kubernetes mniej więcej co trzy miesiące. Aby informować Cię o nowych wersjach i wydaniach usługi AKS, strona informacji o wersji usługi AKS jest regularnie aktualizowana. Możesz również subskrybować kanał informacyjny RSS usługi GitHub AKS, który zapewnia aktualizacje w czasie rzeczywistym dotyczące zmian i ulepszeń.

Usługa AKS jest zgodna z zasadami obsługi N-2 , co oznacza, że pełna obsługa jest zapewniana dla najnowszej wersji (N) i dwóch poprzednich wersji pomocniczych. Ograniczona obsługa platformy jest oferowana dla trzeciej wcześniejszej wersji pomocniczej. Aby uzyskać więcej informacji, zobacz Zasady pomocy technicznej usługi AKS.

Aby zapewnić, że klastry usługi AKS pozostaną obsługiwane, należy ustanowić proces ciągłego uaktualniania klastra. Ten proces obejmuje testowanie nowych wersji w niższych środowiskach i planowanie uaktualnienia do środowiska produkcyjnego, zanim nowa wersja stanie się domyślna. Takie podejście może zachować przewidywalność w procesie uaktualniania i zminimalizować zakłócenia w aplikacjach. Aby uzyskać więcej informacji, zobacz Uaktualnianie klastra usługi AKS.

Jeśli klaster wymaga dłuższego cyklu uaktualniania, użyj wersji usługi AKS, które obsługują opcję długoterminowej pomocy technicznej (LTS). Jeśli włączysz opcję LTS, firma Microsoft zapewnia rozszerzoną pomoc techniczną dla wersji Kubernetes przez dwa lata, co umożliwia bardziej długotrwały i kontrolowany cykl uaktualniania. Aby uzyskać więcej informacji, zobacz Obsługiwane wersje platformy Kubernetes w usłudze AKS.

Uaktualnienie klastra obejmuje uaktualnienie węzła i używa podobnego procesu kordonu i opróżniania.

Przed uaktualnieniem

Najlepszym rozwiązaniem jest zawsze uaktualnianie i testowanie w niższych środowiskach w celu zminimalizowania ryzyka zakłóceń w środowisku produkcyjnym. Uaktualnienia klastrów wymagają dodatkowego testowania, ponieważ obejmują one zmiany interfejsu API, które mogą mieć wpływ na wdrożenia platformy Kubernetes. Następujące zasoby mogą pomóc w procesie uaktualniania:

  • Skoroszyt usługi AKS dla przestarzałych interfejsów API. Na stronie przeglądu klastra w witrynie Azure Portal możesz wybrać pozycję Diagnozowanie i rozwiązywanie problemów, przejdź do kategorii Tworzenie, uaktualnianie, usuwanie i skalowanie , a następnie wybierz pozycję Wycofywanie interfejsu API Kubernetes. Spowoduje to uruchomienie skoroszytu sprawdzającego przestarzałe wersje interfejsu API, które są używane w klastrze. Aby uzyskać więcej informacji, zobacz Usuwanie użycia przestarzałych interfejsów API.
  • Strona informacji o wersji usługi AKS. Ta strona zawiera kompleksowe informacje o nowych wersjach i wydaniach usługi AKS. Przejrzyj te uwagi, aby być na bieżąco z najnowszymi aktualizacjami i zmianami.
  • Strona informacji o wersji rozwiązania Kubernetes. Ta strona zawiera szczegółowe informacje na temat najnowszych wersji platformy Kubernetes. Zwróć szczególną uwagę na pilne uwagi dotyczące uaktualnienia, które podkreślają krytyczne informacje, które mogą mieć wpływ na klaster usługi AKS.
  • Zmiany powodujące niezgodność składników usługi AKS według wersji. Ta tabela zawiera kompleksowe omówienie zmian powodujących niezgodność w składnikach usługi AKS według wersji. Korzystając z tego przewodnika, możesz aktywnie rozwiązać wszelkie potencjalne problemy ze zgodnością przed procesem uaktualniania.

Oprócz tych zasobów firmy Microsoft rozważ użycie narzędzi typu open source w celu zoptymalizowania procesu uaktualniania klastra. Jednym z takich narzędzi jest pluton Fairwinds, który może skanować wdrożenia i wykresy Helm pod kątem przestarzałych interfejsów API platformy Kubernetes. Te narzędzia mogą pomóc w zapewnieniu zgodności aplikacji z najnowszymi wersjami rozwiązania Kubernetes.

Proces uaktualniania

Aby sprawdzić, kiedy klaster wymaga uaktualnienia, użyj polecenia az aks get-upgrades , aby uzyskać listę dostępnych wersji uaktualnienia dla klastra usługi AKS. Ustal wersję docelową klastra z wyników.

Oto przykład:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Przykładowe wyjście:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Sprawdź wersje węzłów platformy Kubernetes w pulach węzłów, aby określić pule, które należy uaktualnić:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Przykładowe wyjście:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Ręczne uaktualnianie

Aby zminimalizować zakłócenia i zapewnić bezproblemowe uaktualnianie klastra usługi AKS, postępuj zgodnie z tym podejściem uaktualniania:

  1. Uaktualnij płaszczyznę sterowania usługi AKS. Zacznij od uaktualnienia płaszczyzny sterowania usługi AKS. Ten krok obejmuje uaktualnienie składników płaszczyzny sterowania, które są odpowiedzialne za zarządzanie klastrem i organizowanie go. Uaktualnienie płaszczyzny sterowania najpierw pomaga zapewnić zgodność i stabilność przed uaktualnieniem poszczególnych pul węzłów.
  2. Uaktualnij pulę węzłów systemowych. Po uaktualnieniu płaszczyzny sterowania uaktualnij pulę węzłów systemowych w klastrze usługi AKS. Pule węzłów składają się z wystąpień maszyn wirtualnych, które uruchamiają obciążenia aplikacji. Uaktualnienie pul węzłów oddzielnie umożliwia kontrolowane i systematyczne uaktualnianie podstawowej infrastruktury obsługującej aplikacje.
  3. Uaktualnij pule węzłów użytkownika. Po uaktualnieniu puli węzłów systemowych uaktualnij wszystkie pule węzłów użytkownika w klastrze usługi AKS.

Stosując to podejście, można zminimalizować zakłócenia w procesie uaktualniania i zachować dostępność aplikacji. Oto szczegółowe kroki:

  1. Uruchom polecenie az aks upgrade z flagą --control-plane-only , aby uaktualnić tylko płaszczyznę sterowania klastra, a nie pule węzłów klastra:

    az aks upgrade \
       --resource-group <ResourceGroupName> --name <AKSClusterName> \
       --control-plane-only \
       --kubernetes-version <KubernetesVersion>
    
  2. Uruchom polecenie az aks nodepool upgrade , aby uaktualnić pule węzłów do wersji docelowej:

    az aks nodepool upgrade \
       --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
       --no-wait --kubernetes-version <KubernetesVersion>
    

    Podczas uaktualniania puli węzłów usługa AKS tworzy węzeł skokowy, kordony i opróżniania zasobników w węźle, który jest uaktualniany, odtwarza obraz węzła, a następnie odłącza zasobniki. Następnie ten proces jest powtarzany dla wszystkich innych węzłów w puli węzłów.

Stan procesu uaktualniania można sprawdzić, uruchamiając polecenie kubectl get events. Aby uzyskać informacje na temat rozwiązywania problemów z uaktualnianiem klastra, zobacz dokumentację rozwiązywania problemów z usługą AKS.

Rejestrowanie klastrów w kanałach wydania automatycznego uaktualniania

Usługa AKS oferuje również automatyczne rozwiązanie do uaktualniania klastra, aby zapewnić aktualność klastra. Jeśli używasz tego rozwiązania, należy powiązać je z oknem obsługi, aby kontrolować czas uaktualniania. Okno uaktualniania musi zawierać co najmniej cztery godziny. Po zarejestrowaniu klastra w kanale wydania firma Microsoft automatycznie zarządza wersją i cyklem uaktualniania klastra i jego pul węzłów.

Automatyczne uaktualnianie klastra oferuje różne opcje kanału wydania. Oto zalecana konfiguracja środowiska i kanału wydania:

Środowisko Kanał uaktualniania opis
Produkcyjne stable W celu zapewnienia stabilności i dojrzałości wersji użyj stabilnego lub regularnego kanału dla obciążeń produkcyjnych.
Przemieszczanie, testowanie, programowanie Tak samo jak w środowisku produkcyjnym Aby upewnić się, że testy wskazują na wersję, do której uaktualnisz środowisko produkcyjne, użyj tego samego kanału wydania co środowisko produkcyjne.
Kanarkowe rapid Aby przetestować najnowsze wersje platformy Kubernetes i nowe funkcje lub interfejsy API usługi AKS, użyj kanału rapid . Możesz poprawić czas obrotu, gdy wersja w rapid programie jest promowana do kanału, którego używasz w środowisku produkcyjnym.

Kwestie wymagające rozważenia

W poniższej tabeli opisano charakterystykę różnych scenariuszy uaktualniania i stosowania poprawek w usłudze AKS:

Scenariusz Zainicjowane przez użytkownika Uaktualnianie rozwiązania Kubernetes Uaktualnienie jądra systemu operacyjnego Uaktualnienie obrazu systemu węzła
Stosowanie poprawek zabezpieczeń Nie Nie. Tak, po ponownym uruchomieniu Tak
Tworzenie klastra Tak Być może Tak, jeśli zaktualizowany obraz węzła używa zaktualizowanego jądra Tak, w stosunku do istniejącego klastra, jeśli jest dostępna nowa wersja
Uaktualnianie platformy Kubernetes płaszczyzny sterowania Tak Tak Nie. Nie.
Uaktualnianie platformy Kubernetes puli węzłów Tak Tak Tak, jeśli zaktualizowany obraz węzła używa zaktualizowanego jądra Tak, jeśli jest dostępna nowa wersja
Skalowanie puli węzłów w górę Tak Nie. Nie. Nie.
Uaktualnienie obrazu systemu węzła Tak Nie. Tak, jeśli zaktualizowany obraz węzła używa zaktualizowanego jądra Tak
Automatyczne uaktualnianie klastra Nie. Tak Tak, jeśli zaktualizowany obraz węzła używa zaktualizowanego jądra Tak, jeśli jest dostępna nowa wersja
  • Poprawka zabezpieczeń systemu operacyjnego zastosowana w ramach uaktualnienia obrazu węzła może zainstalować nowszą wersję jądra niż utworzenie nowego klastra.
  • Skalowanie puli węzłów w górę korzysta z modelu, który jest obecnie skojarzony z zestawem skalowania maszyn wirtualnych. Jądra systemu operacyjnego są uaktualniane po zastosowaniu poprawek zabezpieczeń i ponownym uruchomieniu węzłów.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Inni współautorzy:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki