Zasada zakłóceń węzłów w Azure Kubernetes Service (AKS) (wersja zapoznawcza)

Podczas zarządzania klastrami AKS i ich utrzymywania niektóre zmiany konfiguracji wymagają ponownego utworzenia obrazu węzłów. Ta operacja ponownego tworzenia obrazu powoduje aktualizację stopniową, w ramach której węzły są odtwarzane. Podczas operacji ponownego tworzenia obrazu usługa AKS oznacza węzeł jako niedostępny do planowania nowych zasobników, usuwa z niego istniejące zasobniki (usuwając je i planując ponownie na innych dostępnych węzłach z uwzględnieniem budżetów zakłóceń podów (Pod Disruption Budgets)), a następnie ponownie tworzy obraz węzła ze zaktualizowaną konfiguracją. Ten proces to pełne odtworzenie węzła, a nie restart — bazowa maszyna wirtualna jest ponownie obrazowana przy użyciu nowego obrazu systemu operacyjnego. Chociaż prawidłowo skonfigurowane woluminy trwałe (korzystające z dysków Azure, Azure Files lub innej zewnętrznej pamięci masowej) pozostają bez zmian, wszelkie dane przechowywane w lokalnej efemerycznej pamięci masowej węzła (takie jak woluminy EmptyDir lub ścieżki lokalne) zostaną trwale utracone. Te operacje są niezbędne do stosowania ważnych aktualizacji, ale mogą zakłócać uruchamianie obciążeń i wpływać na dostępność aplikacji. Zasady przerw w działaniu węzła umożliwiają precyzyjną kontrolę nad tym, kiedy te operacje zakłócające mogą być kontynuowane, co ułatwia zrównoważenie potrzeb aktualizacji ze stabilnością operacyjną.

Ważna

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi i wymagają zapisania się. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów, świadczoną w miarę możliwości. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Czym jest polityka zakłóceń węzła?

Zasady zakłóceń węzłów to konfiguracja na poziomie klastra, która określa, kiedy można wykonywać operacje wymagające ponownego tworzenia obrazu węzła i jego ponownego wdrożenia. Działa jako brama sterowa, umożliwiając:

  • Dopasuj operacje powodujące zakłócenia do okien serwisowych.
  • Blokuj zmiany konfiguracji w krytycznych okresach biznesowych, jednocześnie zezwalając na kontynuowanie uaktualniania obrazów węzłów i poprawek zabezpieczeń.
  • Zachowaj przewidywalne zachowanie klastra podczas zdarzeń o dużym natężeniu ruchu.

Zasady dotyczą zmian konfiguracji zainicjowanych przez użytkownika, które wymagają odtworzenia węzła, takich jak aktualizowanie niestandardowych certyfikatów zaufania urzędu certyfikacji, modyfikowanie ustawień profilu zabezpieczeń lub zmiana konfiguracji systemu operacyjnego węzła.

Note

Co ważne, zasada nie blokuje aktualizacji wersji obrazu węzła (w tym kanałów aktualizacji SecurityPatch i NodeImage) ani aktualizacji wersji Kubernetes. Te operacje nadal są kontynuowane zgodnie ze skonfigurowanymi harmonogramami nawet wtedy, gdy zasady są ustawione na Block. Aby uzyskać szczegółowe informacje, zobacz Operacje aktualizacji nieobjęte zasadą zakłóceń węzłów. Ponadto niektóre operacje odzyskiwania nie są kontrolowane przez te zasady w celu zapewnienia kondycji i dostępności klastra. Szczegółowe informacje znajdują się w sekcji Operacje przywracania niekontrolowane przez zasady zakłóceń węzłów.

Jak działa polityka zakłóceń węzła

Politykę zakłóceń węzłów można skonfigurować na poziomie klastra za pomocą właściwości nodeDisruptionProfile. Podczas próby wykonania operacji wymagającej ponownego utworzenia obrazu węzła usługa AKS sprawdza aktualne ustawienie zasad:

  • Ocena zasad: AKS ocenia, czy operacja jest dozwolona na podstawie bieżących zasad.
  • Sprawdzanie okna konserwacji (jeśli dotyczy): Jeśli używasz AllowDuringMaintenanceWindow, usługa AKS sprawdza, czy bieżący czas mieści się w skonfigurowanym oknie konserwacji.
  • Wykonanie operacji lub jej zablokowanie: operacja zakłócająca pracę węzła jest wykonywana, jeśli jest dozwolona, lub odrzucana z komunikatem o błędzie, jeśli zostanie zablokowana.

Opcje zasad

Zasada zakłóceń węzłów obsługuje trzy konfiguracje zasad:

Policy Description Przypadek użycia
Allow Umożliwia wykonywanie operacji wymagających ponownego obrazu węzła w dowolnym momencie. Jest to zachowanie domyślne. Używaj, gdy chcesz nadać priorytet szybkiemu stosowaniu aktualizacji i możesz zaakceptować zakłócenia obciążenia.
AllowDuringMaintenanceWindow Blokuje operacje wymagające ponownego utworzenia obrazu węzła, chyba że odbywają się w aksManagedNodeOSUpgradeSchedule oknie konserwacji. Użyj tej opcji, jeśli chcesz ograniczyć zakłócenia do określonych okien konserwacyjnych zgodnych z harmonogramem operacyjnym.
Block Blokuje wszystkie operacje wymagające ponownego obrazu węzła. Użyj tej opcji, gdy musisz zapobiec wszelkim zakłóceniom w działaniu węzłów, na przykład w krytycznych okresach biznesowych lub podczas zdarzeń o dużym natężeniu ruchu.

Note

Jeśli używasz AllowDuringMaintenanceWindow, musisz skonfigurować okno konserwacji aksManagedNodeOSUpgradeSchedule. Aby uzyskać więcej informacji na temat konfigurowania okien obsługi, zobacz Planowanie i kontrolowanie uaktualnień klastra Azure Kubernetes Service przy użyciu planowanej konserwacji. Jeśli okno obsługi nie zostanie skonfigurowane, operacje zakłócające działanie węzła będą dozwolone.

Considerations

Podczas korzystania z funkcji Node Disruption Policy należy pamiętać o następujących kwestiach:

  • Zakres: zasady dotyczą operacji inicjowanych przez użytkownika, które wymagają ponownego obrazu węzła, a nie konserwacji systemu inicjowanej przez usługę AKS. Szczegółowe informacje znajdują się w sekcji Operacje przywracania niekontrolowane przez zasady zakłóceń węzłów.
  • Zablokowane operacje: po zablokowaniu operacji zakłócania wywołanie interfejsu API kończy się niepowodzeniem z komunikatem o błędzie. Musisz zmienić zasady lub poczekać na okno obsługi.
  • Konserwacja awaryjna: Azure zastrzega sobie prawo do przeprowadzania pilnych lub krytycznych prac konserwacyjnych niezależnie od ustawień zasad.
  • Planowanie aktualizacji: ustawienie zasady na Block uniemożliwia niektóre aktualizacje klastra. Aby uzyskać szczegółowe informacje, zobacz Operacje objęte zasadami zakłóceń węzłów. Zaplanuj odpowiednio, aby w razie potrzeby zastosować niezbędne aktualizacje.
  • Zależność od okna obsługi: AllowDuringMaintenanceWindow zasada wymaga skonfigurowania aksManagedNodeOSUpgradeSchedule okna obsługi. Aby uzyskać szczegółowe informacje, zobacz Planowanie i kontrolowanie uaktualnień klastra Azure Kubernetes Service przy użyciu planowanej konserwacji.

Operacje objęte zasadami zakłóceń węzłów

Operacje na poziomie klastra

Włączanie zasad sieciowych i uaktualnianie nakładki CNI Azure

Aby zainstalować wymagane składniki sieciowe i skonfigurować reguły sieciowe, które zabezpieczają komunikację między zasobnikami i zarządzają nią, należy przeprowadzić ponowne obrazowanie węzłów.

W poniższej tabeli przedstawiono uaktualnienia zasad sieciowych, które wyzwalają reimage:

Od Do
Brak (brak zasad sieciowych) Azure zasady sieciowe
Brak (brak zasad sieciowych) Kaliko
Azure CNI Nakładka Azure CNI
Azure zasady sieciowe Brak (brak zasad sieciowych)
Kaliko Brak (brak zasad sieciowych)

Note

Przełączanie między zasadami sieci Azure i Calico, gdy jedna z nich jest już włączona, nie wymaga ponownego utworzenia obrazu.

Zmiany kanału uaktualniania systemu operacyjnego Node

Każdy kanał używa innej infrastruktury poprawek systemu operacyjnego i konfiguracji, której nie można modyfikować w uruchomionych węzłach.

Poniższa tabela przedstawia zmiany kanału aktualizacji systemu operacyjnego węzła, które powodują ponowne utworzenie obrazu:

Od Do
Niezarządzany Żadne
Nieokreślony Niezarządzany
ZabezpieczeniaPatch Niezarządzany
NodeImage Niezarządzany
Żadne Niezarządzany
Nieokreślony Niezarządzany
Niezarządzany ZabezpieczeniaPatch
Niezarządzany NodeImage

Włączanie dwustosu IPv6

Aby obsługiwać komunikację w trybie dual-stack, węzły muszą mieć konfigurację adresów IPv4 i IPv6 oraz aktualizacje w stosie sieciowym (takie jak reguły nftables).

W poniższej tabeli przedstawiono konfigurację adresu IP i aktualizacje stosu sieciowego, które wyzwalają reimage:

Od Do
Tylko protokół IPv4 IPv4 + IPv6 (podwójny stos)

Zmiany w płaszczyźnie danych Cilium

Należy zainstalować lub usunąć programy eBPF obsługujące przetwarzanie pakietów na poziomie jądra.

W poniższej tabeli przedstawiono zmiany w płaszczyźnie danych Cilium, które powodują ponowne obrazowanie:

Od Do
Żadne Cilium
Cilium Żadne

Aktualizacje konfiguracji serwera proxy HTTP

Wszystkie składniki węzła (containerd, kubelet, usługi systemowe) wymagają zastosowania w całym systemie zaktualizowanej konfiguracji serwera proxy. Gdy zaktualizujesz konfigurację serwera proxy HTTP, usługa AKS automatycznie ponownie tworzy obrazy wszystkich pul węzłów w klastrze.

Zasady zakłóceń węzłów powodują ponowne utworzenie węzła z obrazu podczas modyfikowania dowolnej z następujących właściwości konfiguracji serwera proxy HTTP lub wykonywania dowolnej z następujących operacji:

  • httpProxy: Adres URL serwera proxy dla połączeń HTTP
  • httpsProxy: Adres URL serwera proxy dla połączeń HTTPS
  • noProxy: Lista adresów docelowych wykluczonych z użycia serwera proxy
  • trustedCa: Alternatywny certyfikat CA zakodowany w standardzie Base64
  • Włącz serwer proxy HTTP w klastrze (z użyciem --enable-http-proxy)
  • Wyłącz serwer proxy HTTP w klastrze (--disable-http-proxy)
  • Ponowne włączanie serwera proxy HTTP w klastrze, który wcześniej był wyłączony

Aktualizacje niestandardowych certyfikatów CA

Aby wpłynąć na weryfikację TLS dla usług wewnętrznych i prywatnych rejestrów, należy zainstalować nowe certyfikaty CA w magazynie zaufania systemu operacyjnego.

Zasady zakłócania węzłów powodują ponowne utworzenie obrazu, gdy dodajesz, usuwasz lub aktualizujesz niestandardowe certyfikaty CA.

Tożsamość Kubelet ulega zmianie

Do konfiguracji węzła należy zastosować nowe poświadczenia tożsamości. Obejmuje to początkowe przypisanie tożsamości, aktualizacje tożsamości i resetowanie profilu jednostki usługi.

Node Disruption Policy powoduje ponowne utworzenie obrazu po zaktualizowaniu tożsamości zarządzanej lub tożsamości zarządzanej przypisanej przez użytkownika dla kubeletu.

Zmiany w prywatnej strefie DNS

Należy zaktualizować ustawienia resolvera DNS, aby rozpoznawać prywatny punkt końcowy serwera API przy użyciu nowej strefy DNS.

Zasada zakłóceń węzła powoduje ponowne utworzenie obrazu po zmodyfikowaniu konfiguracji prywatnej strefy DNS w klastrze prywatnym.

Włączanie funkcji integracji serwera API z siecią VNet

Należy ponownie skonfigurować węzły, aby komunikowały się z serwerem interfejsu API za pośrednictwem adresu IP wewnętrznego modułu równoważenia obciążenia przypisanego do delegowanej podsieci.

Zasada zakłóceń węzłów powoduje ponowne utworzenie obrazu po włączeniu integracji serwera API z siecią wirtualną w istniejącym klastrze, który wcześniej z niej nie korzystał. Ta zmiana polega na zmianie właściwości apiServerAccessProfile.enableVnetIntegration (wewnętrznie: pola privateConnectProfile.enabled) z false (lub braku wartości) na true:

Od Do
apiServerAccessProfile.enableVnetIntegration: false lub nieustawiony apiServerAccessProfile.enableVnetIntegration: true

Zmiany routingu hosta eBPF

Należy zainstalować lub usunąć programy eBPF, które zapewniają przekazywanie pakietów o wysokiej wydajności (tryb przyspieszania BpfVeth).

W poniższej tabeli przedstawiono zmiany routingu hosta eBPF, które wyzwalają reimage:

Od Do
Routing standardowy Włączono routing hosta eBPF
Włączono routing hosta eBPF Routing standardowy

Operacje na poziomie puli węzłów

Te operacje mają wpływ tylko na określone pule węzłów, w których wprowadzasz zmiany. Uruchamiają stopniowe ponowne obrazowanie w obrębie tych pul węzłów:

Aktualizacje lokalnego profilu DNS

Należy zastosować zmiany do demona buforowania DNS i reguł przekazywania DNS na poziomie węzła.

Zasada zakłóceń węzła powoduje ponowne utworzenie obrazu, gdy modyfikujesz konfigurację profilu LocalDNS.

Trusted Launch — zmiany w zabezpieczeniach

Nie można zmienić konfiguracji oprogramowania układowego maszyny wirtualnej i ustawień procesu rozruchu na uruchomionych maszynach wirtualnych. Te zmiany wymagają ponownego utworzenia maszyn wirtualnych.

W poniższej tabeli przedstawiono zmiany w zabezpieczeniach Trusted Launch, które powodują ponowne utworzenie obrazu:

Konfiguracja Od Do
vTPM (wirtualny moduł zaufanej platformy) Disabled Enabled
vTPM (wirtualny moduł zaufanej platformy) Enabled Disabled
Bezpieczny rozruch Disabled Enabled
Bezpieczny rozruch Enabled Disabled

Zmiany w przesyłaniu strumieniowym artefaktów

Musisz zainstalować lub odinstalować składniki strumieniowego przesyłania artefaktów, aby umożliwić szybsze pobieranie obrazów kontenerów dzięki strumieniowemu przesyłaniu warstw obrazu na żądanie.

W poniższej tabeli przedstawiono zmiany w strumieniowaniu artefaktów, które powodują ponowne obrazowanie:

Od Do
Disabled Enabled
Enabled Disabled

Aktualizacje profilów Windows GMSA (tylko pule węzłów systemu Windows)

Należy zastosować nowe ustawienia usługi GMSA, konfigurację serwera DNS i poświadczenia przyłączania do domeny na potrzeby integracji Active Directory w węzłach Windows.

Zasada zakłóceń węzłów powoduje ponowne utworzenie obrazu pul węzłów systemu Windows, gdy zmiana GMSA wymaga zastosowania nowej konfiguracji węzła:

Od Do Uruchamia ponowne obrazowanie
Usługa GMSA jest wyłączona Włączono usługę GMSA Yes
Włączono GMSA (ustawiono lub zmieniono serwer DNS / domenę główną) Usługa GMSA włączona ze zaktualizowanym serwerem DNS lub domeną główną Yes
Włączono GMSA (ustawiono serwer DNS) Usługa GMSA jest wyłączona Yes
Włączono GMSA (nie ustawiono serwera DNS) Usługa GMSA jest wyłączona Nie (nie ma konfiguracji węzła do zastosowania)

Załącznik grupy rezerwacji pojemności

Należy ponownie utworzyć bazowe maszyny wirtualne, aby były przydzielane z zarezerwowanej pojemności w grupie rezerwacji pojemności (CRG). Istniejące węzły nie zostały wdrożone z użyciem grupy CRG, więc usługa AKS musi ponownie utworzyć obraz puli węzłów, aby skojarzyć te węzły z rezerwacją.

Zasady zakłócania pracy węzłów powodują ponowne utworzenie obrazu po dołączeniu grupy rezerwacji pojemności do istniejącej puli węzłów, która nie ma jeszcze przypisanej takiej grupy.

Od Do Uruchamia ponowne obrazowanie
Nie dołączono żadnej grupy rezerwacji zasobów Dołączona grupa rezerwacji pojemności Yes

Operacje objęte zasadą zakłóceń węzłów w Kubernetes 1.37 i nowszych wersjach

W Kubernetes 1.37 i nowszych wersjach zasady zakłóceń węzłów obejmują następujące zmiany konfiguracji, które wymagają ponownego utworzenia obrazu węzła. Na platformie Kubernetes w wersji 1.36 lub starszej należy ręcznie uruchomić polecenie az aks nodepool upgrade z poleceniem --node-image-only po wprowadzeniu tych zmian konfiguracji, aby zastosować je do węzłów.

  • Zmiany konfiguracji protokołu SSH: zmiana metod dostępu SSH (wyłączone SSH, Entra ID oparte na protokole SSH lub SSH użytkownika lokalnego) lub aktualizowanie kluczy publicznych SSH w pulach węzłów.
  • Zmiany ograniczeń usługi IMDS: włączanie lub wyłączanie ograniczenia usługi metadanych wystąpienia (IMDS) w celu blokowania dostępu zasobnika do punktu końcowego usługi IMDS.
  • Zmiany profilu bootstrap: zmiana profilu bootstrap, na przykład przełączanie elementu artifactSource między Direct a Cache lub zmiana elementu containerRegistryId (Azure Container Registry używanego na potrzeby klastrów z izolacją sieciową).
  • Zmiany typu ruchu wychodzącego: modyfikowanie typu łączności wychodzącej klastra (loadBalancer, userDefinedRouting, managedNATGateway lub userAssignedNATGateway).

Operacje aktualizacji nie są objęte polityką zakłóceń węzłów

Zasada zakłóceń węzła nie kontroluje następujących operacji aktualizacji. Te operacje uaktualniania są kontynuowane niezależnie od ustawienia zasad. Uaktualnienia są inicjowane przez klienta lub inicjowane przez usługę AKS w ramach planowanych okien konserwacji. Aby umożliwić wykonywanie tych operacji zgodnie z harmonogramem, celowo pozostaw je poza zakresem zasady zakłóceń węzłów. Dodatkowo, jeśli operacje objęte zasadami zakłóceń węzłów są ujęte w tych samych zmianach konfiguracji co uaktualnienia, nie będą podlegać zasadom zakłóceń węzłów.

  • Wersja obrazu węzła — aktualizacje: przechodzenie na nową wersję obrazu systemu operacyjnego węzła (ręcznie lub za pośrednictwem kanałów automatycznej aktualizacji). Ta operacja jest najczęstszą operacją ponownego tworzenia obrazu i obejmuje poprawki zabezpieczeń, aktualizacje systemu operacyjnego oraz nowe wersje obrazów węzłów AKS.
  • Aktualizacje wersji Kubernetes: aktualizowanie wersji Kubernetes w puli węzłów, co powoduje zastosowanie nowych plików binarnych Kubernetes, zaktualizowanej konfiguracji kubeletu oraz zmian na poziomie systemu operacyjnego.

Operacje odzyskiwania nie są kontrolowane przez zasady zakłóceń węzłów

Zasada zakłóceń węzła nie kontroluje następujących operacji automatycznego odzyskiwania. Te operacje mogą wystąpić niezależnie od ustawienia zasad w celu zapewnienia kondycji i odzyskiwania klastra.

  • Wycofanie konfiguracji puli węzłów: jeśli operacja aktualizacji puli węzłów zakończy się niepowodzeniem z powodu nieprawidłowej konfiguracji lub problemów z infrastrukturą, usługa AKS automatycznie przywróci ostatni znany prawidłowy stan i ponownie utworzy obrazy węzłów, aby cofnąć zmiany konfiguracji.
  • Operacje przywracania klastra administracyjnego: gdy inżynierowie pomoc techniczna platformy Azure wykonują przywracanie klastra administracyjnego podczas rozwiązywania zdarzeń, węzły są odtwarzane w celu zapewnienia spójności między stanem płaszczyzny sterowania i konfiguracją węzła.
  • Aktualizacje poświadczeń tożsamości węzłów: usługa AKS regularnie aktualizuje poświadczenia tożsamości węzłów ze względów bezpieczeństwa i zgodności. Te aktualizacje inicjowane przez system wyzwalają ponowne tworzenie obrazów węzłów, aby zastosować nowe poświadczenia we wszystkich pulach węzłów.

Integracja z planowaną konserwacją

Zasada dotycząca zakłóceń węzłów współdziała bezproblemowo z oknami planowanej konserwacji w AKS. Po ustawieniu zasady na wartość AllowDuringMaintenanceWindow operacje powodujące zakłócenia są dostosowane do okna obsługi aksManagedNodeOSUpgradeSchedule, co zapewnia, że:

  • Zmiany występują tylko w zatwierdzonych oknach czasowych.
  • Operacje koordynują inne zaplanowane prace konserwacyjne.
  • Zespoły wiedzą, kiedy mogą wystąpić zakłócenia.

Ta integracja zapewnia kompleksowe podejście do zarządzania zmianami klastra i minimalizowania wpływu na uruchomione obciążenia.

Note

Jeśli używasz AllowDuringMaintenanceWindow, musisz skonfigurować okno konserwacji aksManagedNodeOSUpgradeSchedule. Korzystanie z default okna konserwacyjnego lub z aksManagedAutoUpgradeSchedule (automatycznej aktualizacji klastra) nie spełnia tego wymagania. Jeśli ustawisz AllowDuringMaintenanceWindow bez skonfigurowanego okna aksManagedNodeOSUpgradeSchedule, wszystkie operacje powodujące zakłócenia będą dozwolone (zasada nie ma okna, które mogłoby je ograniczać). Aby uzyskać więcej informacji na temat konfigurowania okien obsługi, zobacz Planowanie i kontrolowanie uaktualnień klastra Azure Kubernetes Service przy użyciu planowanej konserwacji.

Najlepsze rozwiązania

Podczas wdrażania zasady zakłóceń węzłów należy wziąć pod uwagę następujące zalecenia:

  • Użyj AllowDuringMaintenanceWindow w środowisku produkcyjnym: połącz z planowanymi oknami konserwacyjnymi, aby kontrolować, kiedy dochodzi do zakłóceń w środowiskach produkcyjnych.
  • Ustaw Block w krytycznych okresach: Tymczasowo blokuj zakłócające operacje podczas okresów wzmożonego ruchu, premier produktów lub reagowania na incydenty. Nie używaj Block w nieskończoność. Chociaż Block jest odpowiedni w przypadku krótkoterminowych wstrzymań (planowanych zdarzeń, reagowania na incydenty).
  • Zezwalaj na elastyczność w środowisku nieprodukcyjnym: używaj Allow w środowiskach deweloperskich i testowych, w których szybka iteracja jest ważniejsza niż stabilność.
  • Przekazywanie zmian zasad: Upewnij się, że zespół rozumie bieżące zasady i wie, kiedy operacje mogą być blokowane.
  • Odpowiednio zaplanuj okna konserwacji: Zaplanuj okna konserwacji tak, aby uwzględnić operacje, które należy wykonać.
  • Przetestuj działanie zasad: zweryfikuj ustawienia zasad w środowiskach nieprodukcyjnych przed zastosowaniem ich w klastrach produkcyjnych.
  • Monitorowanie zablokowanych operacji: śledź, kiedy operacje są blokowane w celu zoptymalizowania harmonogramu konserwacji.

Treści powiązane

  • Last updated on