Uaktualnienia inicjowane przez platformę w Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) automatycznie uaktualnia wszystkie klastry, które pozostają w nieobsługiwanej wersji Kubernetes po zakończeniu okresu prolongaty wsparcia platformy. To automatyczne uaktualnianie jest nazywane uaktualnieniem inicjowanym przez platformę.

Klaster z nieobsługiwaną wersją platformy Kubernetes nie otrzymuje już poprawek od społeczności, poprawek błędów ani działań naprawczych dotyczących CVE. Uaktualnienia inicjowane przez platformę zapewniają, że każdy klaster usługi AKS powróci do obsługiwanej wersji, nawet jeśli nikt nie podejmie akcji.

Warning

W przeciwieństwie do uaktualnienia, które jest uruchamiane, gdy klaster jest w obsłudze, uaktualnienie zainicjowane przez platformę nie zatrzymuje się, gdy sprawdzanie zmian powodujących niezgodność dotyczących przestarzałych interfejsów API wykrywa użycie interfejsu API, który jest usuwany w docelowej wersji Kubernetes. Uaktualnienie będzie kontynuowane, a obciążenia, klienci lub kontrolery, które zależą od usuniętego interfejsu API, mogą przestać działać. Usługa AKS również nie weryfikuje dodatków zarządzanych samodzielnie pod kątem zgodności z wersją docelową. Zaktualizuj manifesty i uaktualnij lub zastąp niezgodne dodatki zarządzane samodzielnie przed rozpoczęciem uaktualniania zainicjowanego przez platformę. Aby uzyskać więcej informacji, zobacz Opcje uaktualniania usługi AKS i zalecenia.

Uaktualnienie zainicjowane przez platformę również nie jest zgodne z oknem konserwacji i może zignorować budżet zakłóceń zasobnika (PDB), który uniemożliwia opróżnianie węzła. Obciążenia robocze mogą zostać zakłócone.

Utrzymywanie klastra w obsługiwanej wersji jest jedynym sposobem uniknięcia uaktualnienia zainicjowanego przez platformę. Zobacz Jak uniknąć uaktualnień zainicjowanych przez platformę.

Uaktualnienia inicjowane przez platformę nie zmieniają warstwy rozliczeniowej, kanału uaktualniania ani warstwy pomocy technicznej. Mają one zastosowanie tylko do klastrów, które nie są już objęte wsparciem.

Przygotuj się, zanim usługa AKS rozpocznie uaktualnianie

Przed miesiącem aktualizacji inicjowanej przez platformę klastra wykonaj następujące kroki:

Znajdź klastry, które nie są już wspierane lub zbliżają się do końca życia. Użyj zapytania Azure Resource Graph i sprawdź kalendarz wydań.
Usuń zależności od przestarzałych interfejsów API. W portalu Azure przejdź do sekcji Diagnozowanie i rozwiązywanie problemów>. Zaktualizuj obciążenia, manifesty, klientów, kontrolery i dodatki zarządzane samodzielnie, które używają interfejsów API usuniętych z docelowej wersji platformy Kubernetes. Uaktualnienie zainicjowane przez platformę nie zatrzymuje się, gdy wykryje to użycie.
Zweryfikuj dodatki zarządzane samodzielnie. Sprawdź zgodność wersji Kubernetes dla każdego dodatku zarządzanego samodzielnie, w tym niestandardowe definicje zasobów i kontrolery. Uaktualnij lub zastąp dodatek niezgodny z docelową wersją rozwiązania Kubernetes przed uaktualnieniem klastra przez usługę AKS.
Zabezpiecz możliwość aktualizacji. Przejrzyj limit przydziału rodziny maszyn wirtualnych (VM), dostępność regionalnych jednostek SKU i pojemność puli adresów IP podsieci przed oczekiwanym miesiącem uaktualnienia. Zażądaj zwiększenia limitu przydziału lub odpowiednio wcześnie skontaktuj się z pomocą techniczną platformy Azure w przypadku regionalnych ograniczeń pojemności. Dostosuj maxSurge do pojemności, jaką można uzyskać. Jeśli dodatkowa przepustowość nie jest dostępna, rozważ maxUnavailable, które umożliwia miejscowe uaktualnienie kwalifikujących się pul węzłów użytkownika bez dodatkowych węzłów, ale może zmniejszyć pojemność obciążeń podczas uaktualniania.
Stosuj przewidywalny cykl aktualizacji. W przypadku pojedynczego klastra użyj kanałustable automatycznego uaktualniania klastra z zaplanowaną konserwacją, aby zachować klaster w obsługiwanej wersji podrzędnej i uruchomić uaktualnienia podczas wybranego okna. Kanał patch automatycznie stosuje poprawki w bieżącej wersji podrzędnej, ale nie przenosi klastra do nowszej wersji podrzędnej. W przypadku wielu klastrów należy rozważyć profil automatycznego uaktualniania programu Fleet Manager i strategię aktualizacji, aby etapowo wdrażać aktualizacje w grupach aktualizacji, z okresami oczekiwania między etapami. Takie podejście zapewnia powtarzalny rytm, zapewniając jednocześnie czas na zweryfikowanie każdego etapu przed rozpoczęciem następnego.
Przygotuj PDB do osuszania węzłów. Przetestuj, czy pliki PDB zezwalają na zakończenie drenażu węzła. Jeśli zarządzanie pdB jest trudne, rozważ automatyczne zarządzanie pdB (wersja zapoznawcza), które może tworzyć brakujące pliki PDB i tymczasowo dodawać repliki, gdy pdB blokuje opróżnianie.
Uaktualnij zgodnie z własnym harmonogramem. Zobacz Uaktualnianie płaszczyzny sterowania klastra usługi AKS lub zapoznaj się z artykułem Jak uniknąć uaktualnień zainicjowanych przez platformę, aby zachować kontrolę nad przyszłymi uaktualnieniami.
Rozważ długoterminowe wsparcie. Jeśli potrzebujesz określonej wersji podrzędnej obsługiwanej dłużej, oceń długoterminową pomoc techniczną usługi AKS.

Aby uaktualnić klaster przy użyciu Azure CLI:

# List the versions available in your region
az aks get-versions --location <region> --output table

# Upgrade the cluster
az aks upgrade --resource-group <resource-group> --name <cluster-name> --kubernetes-version <target-version>

Uaktualnienia inicjowane przez platformę w porównaniu z uaktualnieniami, które kontrolujesz

Każdy inny sposób uaktualniania klastra usługi AKS przestrzega skonfigurowanych mechanizmów kontroli. Uaktualnienia inicjowane przez platformę nie, ponieważ ich celem jest przywrócenie nieobsługiwanego klastra do wspieranej wersji.

Metoda uaktualniania	Zgodnie z oknem konserwacji	Uruchamia przestarzałe sprawdzanie interfejsu API	Honoruje pliki PDB i ustawienia skoku napięcia
Ręczne uaktualnianie za pomocą `az aks upgrade`	Nie dotyczy — wybierasz, kiedy uaktualnienie zostanie uruchomione	Yes	Yes
Kanał automatycznego uaktualniania klastra (`patch`, `stable`, `rapid`)	Yes	Yes	Yes
Uruchomienia aktualizacji Fleet Manager i profile automatycznego uaktualniania	Yes	Yes	Yes
Uaktualnienie inicjowane przez platformę	No	No	Tylko dołożenie wszelkich starań

Ponieważ zachowasz pełną kontrolę przy użyciu dowolnej z trzech pierwszych metod, uaktualnienie przed wyjściem klastra z pomocy technicznej jest zawsze preferowane niż dopuścić do uruchomienia uaktualnienia zainicjowanego przez platformę.

Okres karencji wsparcia platformy

Gdy wersja minor platformy Kubernetes osiągnie kres wsparcia, wsparcie społeczności dobiega końca, a wersja wchodzi w okres wsparcia platformy AKS. okres karencji wsparcia platformy to 60-dniowe okno, w którym nadal możesz przeprowadzić uaktualnienie na własnych warunkach.

Phase	Co się stanie
Pomoc społecznościowa	Wersja otrzymuje poprawki z projektu nadrzędnego, poprawki błędów i remediację podatności CVE.
Koniec życia	Wsparcie społeczności kończy się. Klaster przechodzi do etapu wsparcia platformy i rozpoczyna się 60-dniowy okres karencji.
Okres karencji (60 dni)	Azure obsługuje platformę — łączność klastra, kondycję węzła i wykonywanie uaktualniania — ale nie błędy Kubernetes ani CVE w nieobsługiwanej wersji. Uaktualnij w tym czasie, aby zachować kontrolę.
Koniec okresu prolongaty	Klaster kwalifikuje się do uaktualnienia zainicjowanego przez usługę AKS do obsługiwanej wersji.

Okres karencji rozpoczyna się dzień po dacie końca wsparcia i trwa 60 dni. Jeśli na przykład wersja platformy Kubernetes osiągnie koniec wsparcia 30 czerwca 2027 r., okres prolongaty trwa od 1 lipca do 29 sierpnia 2027 r. Klaster, który nadal pozostaje w tej wersji, kwalifikuje się do uaktualnienia zainicjowanego przez platformę po okresie prolongaty. Kalendarz wydania zawiera zaplanowany miesiąc wdrożenia, a nie datę uaktualnienia określonego klastra.

Aby wyświetlić miesiąc uaktualniania zainicjowanego przez platformę dla każdej wersji, zobacz kalendarz wydania usługi AKS Kubernetes.

Początkowe wdrożenie

Do 31 maja 2027 r. zidentyfikuj klastry z nieobsługiwaną wersją platformy Kubernetes i uaktualnij je we własnym tempie. To okno aktualizacji ustalane przez klienta to okres przejściowy dla początkowego wdrożenia.

Począwszy od 1 czerwca 2027 r., usługa AKS rozpoczyna uaktualnienia inicjowane przez platformę dla klastrów, które pozostają w nieobsługiwanych wersjach. Oczekuje się, że klastry objęte wsparciem społeczności w poziomie Standard będą uruchamiać platformę Kubernetes w wersji 1.36 lub nowszej, a klastry objęte programem LTS będą uruchamiać platformę Kubernetes 1.33 LTS lub nowszą. Usługa AKS nie zapisuje automatycznie klastrów do programu LTS.

Po początkowym wdrożeniu każde zdarzenie zakończenia wsparcia ma 60-dniowy okres prolongaty przed rozpoczęciem uaktualnień zainicjowanych przez platformę.

Pomiar czasu nie jest dokładny

AKS ogranicza tempo uaktualnień inicjowanych przez platformę według regionów, subskrypcji i wersji źródłowej, dzięki czemu uaktualnienia nie są uruchamiane wszędzie naraz. Klaster jest uaktualniany w trakcie miesiąca wskazanego w kalendarzu wydań lub po jego zakończeniu, a nie w określonym dniu.

Nie planuj działań w oparciu o dokładny czas aktualizacji. Zaplanuj korzystanie z obsługiwanej wersji przed zakończeniem okresu przejściowego.

Jak uniknąć uaktualnień zainicjowanych przez platformę

Uaktualnienie zainicjowane przez platformę jest uruchamiane tylko w klastrze, który jest już poza okresem wsparcia. Pozostawanie w ramach wsparcia pozwala uniknąć tej ścieżki, a także sprawia, że każde uaktualnienie mieści się w ramach okresu utrzymania.

Dla poszczególnych klastrów

Ustaw kanał automatycznego uaktualniania. Kanałstable automatycznie utrzymuje klaster w obsługiwanej wersji podrzędnej. Kanał patch stosuje tylko poprawki w bieżącej wersji podrzędnej. Kanał none lub całkowity brak kanału sprawia, że klaster wypada ze wsparcia.
Skonfiguruj okno obsługi. Połącz kanał z planowanymi pracami konserwacyjnymi, aby uaktualnienia działały w okresach niskiego natężenia ruchu. Użyj okresu co najmniej czterech godzin.
Subskrybuj powiadomienia. Skonfiguruj AKS Communication Manager, aby otrzymywać powiadomienia o aktualizacjach, zanim zostaną przeprowadzone.
Utrzymuj obciążenia w gotowości do aktualizacji. Przetestuj obiekty PDB i rozważ automatyczne zarządzanie budżetem zakłóceń Podów, aby nie blokować opróżniania węzłów.

Dla flot

Jeśli zarządzasz wieloma klastrami, użyj usługi Azure Kubernetes Fleet Manager, aby zachować każdy klaster członkowski w obsłudze:

Utwórz profil automatycznego uaktualniania. Profil automatycznego uaktualniania programu Fleet Manager z kanałem Stable lub Rapid automatycznie utrzymuje klastry członkowskie w obsługiwanych wersjach.
Użyj przebiegów aktualizacji i grup aktualizacji.Orkiestracja aktualizacji aktualizuje klastry członkowskie w kontrolowanej sekwencji, dzięki czemu można etapować aktualizacje w różnych środowiskach.
Faza ze strategiami aktualizacji. Grupuj klastry na etapy — na przykład testy przed produkcją — i dodaj czas oczekiwania między etapami, aby zweryfikować poszczególne etapy.
Śledź wersje członków. Przejrzyj wersję platformy Kubernetes każdego klastra członkowskiego względem kalendarza wydania lub użyj zapytania Azure Resource Graph.

Important

Przebiegi aktualizacji programu Fleet Manager i grupy aktualizacji mają zastosowanie tylko do klastrów, które są nadal obsługiwane. Gdy klaster członkowski przestanie być wspierany, AKS podejmuje działania bezpośrednio wobec niego za pomocą zainicjowanego przez platformę uaktualnienia, które pomija sekwencjonowanie programu Fleet Manager. Utrzymuj obsługę klastrów członkowskich, aby sekwencjonowanie floty pozostawało w mocy.

Którą wersję Kubernetes wybiera usługa AKS

Usługa AKS uaktualnia klaster do najniższej obsługiwanej wersji w bieżącej warstwie pomocy technicznej:

Obecny poziom wsparcia	Wersja docelowa
Pomoc społecznościowa	Najniższa obsługiwana pomocnicza wersja Community.
Obsługa długoterminowa (LTS)	Odpowiednia wersja LTS.

Usługa AKS zawsze wybiera najnowszą dostępną wersję poprawki w docelowej wersji podrzędnej.

Uaktualnienia inicjowane przez platformę nigdy nie przekraczają poziomów wsparcia. Klaster obsługiwany przez społeczność nie jest objęty LTS, a klaster LTS nie jest obniżany do wersji społecznościowej. Ponieważ LTS jest opcją wymagającą warstwy Premium, usługa AKS nigdy nie rejestruje klastra w LTS w Twoim imieniu i nigdy nie zmienia warstwy rozliczeniowej. Aby uzyskać więcej informacji, zobacz Włączanie długoterminowej pomocy technicznej.

Klastry opóźnione o kilka wersji pomocniczych

Platforma Kubernetes nie zezwala na pomijanie wersji minor podczas uaktualniania control plane. Jeśli klaster jest opóźniony o kilka wersji pomocniczych, usługa AKS przenosi go jedną wersję pomocniczą naraz, dopóki nie osiągnie obsługiwanej wersji.

Klaster, który jest znacznie opóźniony, potrzebuje więcej czasu, aby powrócić do wspieranego stanu, i niesie ze sobą większe ryzyko problemów z obciążeniami roboczymi, ponieważ każda wersja pomocnicza może usunąć interfejsy API, od których zależą obciążenia robocze. Samodzielne uaktualnienie tych klastrów jest zdecydowanie zalecane.

Płaszczyzna sterowania i pule węzłów

Uaktualnienie zainicjowane przez platformę aktualizuje cały klaster do wersji docelowej. Usługa AKS uaktualni najpierw płaszczyznę sterowania, a następnie pule węzłów przy użyciu tej samej koordynacji aktualizacji co az aks upgrade.

Co usługa AKS zastępuje podczas uaktualniania zainicjowanego przez platformę

Aby zapewnić zakończenie uaktualniania, usługa AKS zastępuje niektóre mechanizmy kontrolne, które mają zastosowanie do każdej innej metody uaktualniania.

Control	Zachowanie podczas uaktualniania zainicjowanego przez platformę
Okno obsługi	Nie jest honorowany. Uaktualnienie można rozpocząć w dowolnym momencie od miesiąca uaktualnienia zainicjowanego przez platformę.
Kanał automatycznego uaktualniania	Ignorowane. Klastry bez skonfigurowanego kanału lub z kanałem `none` lub `patch` są nadal uaktualniane.
Przebiegi aktualizacji programu Fleet Manager i grupy aktualizacji	Nie akceptowane. Usługa AKS działa bezpośrednio na klastrze członkowskim.
Sprawdzenie przestarzałego interfejsu API	Ominięto. Uaktualnienie jest kontynuowane nawet gdy zostanie wykryte przestarzałe użycie interfejsu API.
Budżety zakłóceń Podów (PDB)	Honorowane w miarę możliwości. Usługa AKS próbuje najpierw przeprowadzić standardowe opróżnianie węzła i zastępuje PDB tylko wtedy, gdy opróżnianie przekroczy limit czasu lub zakończy się niepowodzeniem.
Ustawienia skoku węzła	Honorowane w miarę możliwości. Jeśli usługa AKS nie może utworzyć nadmiarowej liczby zasobów, przechodzi do aktualizowania jednego węzła naraz (`maxSurge=0`, `maxUnavailable=1`).
Uaktualnienia puli węzłów blue-green	Wykonano jako aktualizacja krocząca. Twoja zapisana strategia nie została zmieniona.

Ponieważ usługa AKS może zastąpić ustawienia PDB i może pominąć przestarzałe sprawdzanie interfejsu API, uaktualnienie zainicjowane przez platformę jest uaktualnieniem podejmowanym w miarę możliwości, bez gwarancji dostępności obciążenia. Obciążenia robocze mogą być zakłócane.

Nie można wycofać uaktualnień zainicjowanych przez platformę. Nie można przywrócić do nieobsługiwanej wersji, więc wersja uruchomiona przed uaktualnieniem nie jest dostępna.

Twoja konfiguracja nie jest zmieniana

Usługa AKS ignoruje te ustawienia w czasie wykonywania, ale nie modyfikuje ich. Po uaktualnieniu zainicjowanym przez platformę następujące ustawienia są niezmienione:

Profil automatycznej aktualizacji i kanał aktualizacji
Konfiguracja okna konserwacji
Strategia aktualizacji puli węzłów, w tym strategia blue-green
Maksymalny nadmiar i ustawienia maksymalnej niedostępności
Poziom rozliczeń i rejestracja LTS

Znajdź zagrożone klastry

Użyj tego zapytania Azure Resource Graph w portalu Azure lub z Azure CLI, aby wyświetlić listę klastrów usługi AKS w ramach Twoich subskrypcji wraz z ich bieżącą wersją platformy Kubernetes oraz warstwą pomocy technicznej:

resources
| where type =~ 'microsoft.containerservice/managedclusters'
| project
    clusterName = name,
    resourceGroup,
    subscriptionId,
    location,
    kubernetesVersion = properties.kubernetesVersion,
    tier = properties.sku.tier,
    supportPlan = properties.supportPlan,
    upgradeChannel = properties.autoUpgradeProfile.upgradeChannel,
    powerState = properties.powerState.code
| order by kubernetesVersion asc, clusterName asc

Aby uruchomić zapytanie przy użyciu Azure CLI:

az graph query -q "resources | where type =~ 'microsoft.containerservice/managedclusters' | project clusterName = name, resourceGroup, subscriptionId, kubernetesVersion = properties.kubernetesVersion, tier = properties.sku.tier, supportPlan = properties.supportPlan | order by kubernetesVersion asc" --output table

kubernetesVersion Porównaj te wartości z kalendarzem wydania usługi AKS Kubernetes, aby znaleźć klastry, które nie są obsługiwane lub zbliżają się do końca życia. Wartość supportPlanAKSLongTermSupport wskazuje, że klaster jest objęty programem LTS.

Jak otrzymywać powiadomienia

Usługa AKS wskazuje klastry zagrożone za pośrednictwem kilku kanałów przed uruchomieniem uaktualnienia zainicjowanego przez platformę:

Azure Resource Health: klaster w oknie pomocy technicznej platformy zgłasza stan kondycji Zdegradowany, który podaje bieżącą wersję i kiedy usługa AKS uaktualni klaster.
Azure portal: baner w zasobie klastra ostrzega, że wersja nie jest obsługiwana i usługa AKS automatycznie uaktualnia klaster.
Azure Advisor: Zalecenie identyfikuje klastry uruchamiające nieobsługiwane wersje.
AKS Communication Manager: wysyła powiadomienia e-mail dotyczące nadchodzących i ukończonych uaktualnień zainicjowanych przez platformę.
Diagnozowanie i rozwiązywanie problemów: pokazuje stan uaktualniania klastra i przestarzałe użycie interfejsu API w portalu Azure.

Te kanały współużytkują ten sam stan bazowy, więc nie są ze sobą sprzeczne. W przypadku zaplanowanego lub ponawianego uaktualnienia można zobaczyć stan cyklu życia, liczbę ponownych prób, czas następnej próby i ostatni błąd.

Audyt uaktualnienia zainicjowanego przez platformę

Uaktualnienia inicjowane przez platformę są wyświetlane w dzienniku aktywności Azure z metadanymi, które odróżniają je od wyzwalanych uaktualnień:

Property	Value
`initiatedBy`	`System`
`upgradeTrigger`	`PlatformInitiatedUnsupportedVersion`
`upgradeSource`	`PlatformInitiated`

Zdarzenie rejestruje również źródłowe i docelowe wersje platformy Kubernetes. Przefiltruj dziennik aktywności według tych właściwości, aby ustalić, komu przypisać zmianę podczas przeglądu zarządzania zmianami lub zgodności.

Gdy nie można ukończyć uaktualniania

Jeśli uaktualnienie zainicjowane przez platformę zakończy się niepowodzeniem, usługa AKS automatycznie ponawia próbę zgodnie z harmonogramem określonym przez system. Klaster działa w nieobsługiwanej wersji do momentu pomyślnego uaktualnienia.

Blokada nie zwalnia klastra z polityki; jedynie pozostawia klaster bez wsparcia na dłużej. Typowe blokady obejmują:

Dodatek lub funkcja, która nie jest obsługiwana w wersji docelowej. W przypadku klastrów LTS zobacz zagadnienia dotyczące cyklu życia dodatków i funkcji.
Rozmiar wycofanej maszyny wirtualnej w puli węzłów.
Niewystarczające adresy IP w podsieci węzła.
Ograniczenia pojemności regionalnej.
Blokada zasobu w klastrze lub grupie zasobów klastra.
Przypisanie Azure Policy, które blokuje zmiany wersji platformy Kubernetes.

Sprawdź przyczynę błędu w Azure Resource Health lub Diagnozowanie i rozwiązywanie problemów, rozwiąż bloker, a następnie samodzielnie uaktualnij klaster. Jeśli nie możesz zidentyfikować przyczyny, otwórz wniosek o pomoc techniczną.

Klastry pomijane przez usługę AKS

Usługa AKS nie przeprowadza aktualizacji inicjowanych przez platformę:

Zatrzymane klastry. Usługa AKS odracza uaktualnienie, gdy klaster jest zatrzymany. Po uruchomieniu klastra działa on normalnie i jest ponownie oceniany na potrzeby uaktualnienia zainicjowanego przez platformę w następnym cyklu. Uruchomienie klastra nie powoduje natychmiastowego uaktualnienia.
Klastry są usuwane.
Klastry w stanie nieudanego aprowizowania. Najpierw usuń błąd.

Availability

Uaktualnienia inicjowane przez platformę mają zastosowanie do usługi AKS w chmurze publicznej Azure. Dostępność na platformach Azure Government i Microsoft Azure obsługiwanym przez firmę 21Vianet odbywa się zgodnie z zasadami bezpiecznego wdrażania platformy Azure i jest ogłaszana oddzielnie.

AKS włączony przez Azure Arc i AKS w usłudze Azure lokalnie są poza zakresem. Te oferty mają własny cykl życia i modele uaktualniania.

Często zadawane pytania

Czy mogę zrezygnować z uaktualnień zainicjowanych przez platformę?

No. Nie ma ustawienia rezygnacji z udziału. Zachowaj kontrolę, utrzymując klaster w obsługiwanej pomocniczej wersji społeczności lub w wersji LTS, do której jawnie się zapisano. Uaktualnienia inicjowane przez platformę dotyczą tylko klastrów, które pozostają w nieobsługiwanej wersji po zakończeniu 60-dniowego okresu prolongaty pomocy technicznej platformy.

Czy mogę anulować zainicjowane już uaktualnienie zainicjowane przez platformę?

No. Nie można anulować uaktualnienia będącego w toku zainicjowanego przez platformę.

Czy to zmienia mój plan rozliczeniowy lub poziom usług?

No. Nie ma zmian w rozliczeniach ani poziomach taryfowych. Jeśli nie zdecydujesz się na korzystanie z wersji LTS, klaster zostanie uaktualniony do obsługiwanej wersji społeczności bez dodatkowych kosztów.

Czy usługa AKS rejestruje mój klaster w długoterminowym wsparciu?

No. LTS to oddzielnie wyceniona opcja, która wymaga planu Premium. Usługa AKS nigdy nie rejestruje klastra w LTS w Twoim imieniu. Aby zachować obsługiwaną przez dłuższy czas określoną wersję minor, zarejestruj klaster w programie LTS samodzielnie.

Mój klaster jest zarejestrowany w wersji LTS, a jego okres wsparcia LTS dobiegł końca. Jaka wersja jest wybrana przez usługę AKS?

Klaster pozostaje na ścieżce LTS i jest uaktualniany do następnej obsługiwanej wersji LTS. Nie jest on przenoszony do wersji wspieranej przez społeczność.

Czy moje obciążenia będą miały przestoje?

Ewentualnie. Usługa AKS próbuje normalnego opróżnienia węzła i honoruje mechanizmy PDB, gdzie może, ale zastępuje mechanizmy PDB, jeśli upłynął limit czasu opróżniania lub zakończy się ono niepowodzeniem. Uaktualnienie inicjowane przez platformę jest realizowane w miarę możliwości i nie gwarantuje dostępności obciążenia. Przetestuj pliki PDB i ustawienia uaktualniania przed miesiącem planowanej przez platformę aktualizacji klastra lub uaktualnij klaster samodzielnie, aby okno konserwacji i pliki PDB były w pełni uwzględnione.

Czy uaktualnienie honoruje moje okno serwisowe?

No. Uaktualnienia inicjowane przez platformę nie są zgodne z oknami konserwacji i mogą być uruchamiane w dowolnym momencie od miesiąca aktualizacji inicjowanej przez platformę. Okna konserwacji nadal obowiązują w przypadku ręcznych aktualizacji, automatycznej aktualizacji klastra i przebiegów aktualizacji programu Fleet Manager.

Czy mój kanał automatycznego uaktualniania ma wpływ na to?

No. Ustawienie kanału nie zwalnia klastra. Klastry bez skonfigurowanego kanału lub z kanałem none lub patch są nadal uaktualniane, gdy nie są już objęte wsparciem. Konfiguracja kanału nie jest modyfikowana.

Kanał stable pomaga zachować klaster w obsługiwanej wersji minor. Kanał patch stosuje poprawki w bieżącej wersji minor, ale nie przenosi klastra do nowszej wersji minor. Aby uzyskać więcej informacji, zobacz Jak uniknąć uaktualnień zainicjowanych przez platformę.

Czy usługa Fleet Manager chroni klastry członkowskie przed uaktualnieniami zainicjowanymi przez platformę?

Usługa Fleet Manager pomaga utrzymać klastry członkowskie w stanie objętym wsparciem, co pozwala uniknąć uaktualnień inicjowanych przez platformę. Jednak gdy klaster członkowski wypadnie z obsługi, AKS podejmuje działania bezpośrednio wobec niego i nie uwzględnia uruchomień aktualizacji Fleet Manager, grup aktualizacji ani okien obsługi. Aby uzyskać więcej informacji, zobacz Dla flot.

Czy uaktualnienie aktualizuje również obrazy węzłów lub SKU systemu operacyjnego?

Uaktualnienia inicjowane przez platformę dotyczą wersji Kubernetes. Węzły są ponownie obrazowane w ramach uaktualniania i uruchamiają się z bieżącym obrazem węzła dla wersji docelowej. Jednostka SKU systemu operacyjnego nie została zmieniona. Aby oddzielnie zarządzać obrazami węzłów, zobacz Uaktualnianie obrazów węzłów usługi AKS.

Co jeśli moje pule węzłów znajdują się daleko za płaszczyzną sterowania?

Usługa AKS najpierw uaktualnia płaszczyznę sterowania, a następnie uaktualnia pule węzłów do wersji docelowej w ramach reguł uaktualniania wersji platformy Kubernetes. Jeśli pula węzłów jest zbyt opóźniona, usługa AKS uaktualnia ją etapami wraz z płaszczyzną sterowania.

Czy mogę cofnąć aktualizację po uaktualnieniu zainicjowanym przez platformę?

No. Usługa AKS nie obsługuje obniżania wersji i nie można cofnąć do nieobsługiwanej wersji. Aby uzyskać więcej informacji, zobacz Wycofanie puli węzłów usługi AKS.

Czy problem z obciążeniem spowodowany uaktualnieniem zainicjowanym przez platformę może być obsługiwany?

Możesz otworzyć zgłoszenie do pomocy technicznej dotyczące klastra i samego uaktualnienia. Jednak uaktualnienie zainicjowane przez platformę jest realizowane w miarę możliwości i nie gwarantuje dostępności obciążenia, a klastry z nieobsługiwaną wersją nie mają żadnych gwarancji działania w czasie wykonywania. Zweryfikuj zgodność obciążenia z wersją docelową przed miesiącem planowanej aktualizacji inicjowanej przez platformę klastra.

Z jakim wyprzedzeniem zostanę poinformowany(-a)?

Klaster przechodzi do okresu wsparcia platformy po zakończeniu cyklu życia, co daje 60-dniowy okres prolongaty, zanim będzie kwalifikował się do uaktualnienia zainicjowanego przez platformę. kalendarz wydań publikuje z wyprzedzeniem planowane miesiące wdrożenia, a Azure Resource Health, Azure Advisor i AKS Communication Manager powiadamiają Cię w okresie karencji.

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-10-10