Automatyczna naprawa węzła usługi Azure Kubernetes Service (AKS)

Usługa Azure Kubernetes Service (AKS) stale monitoruje stan kondycji węzłów roboczych i automatycznie przeprowadza naprawę węzła, jeśli będzie on w złej kondycji. Platforma maszyn wirtualnych Azure przeprowadza konserwację maszyn wirtualnych, które napotykają problemy. Usługi AKS i maszyny wirtualne platformy Azure współpracują ze sobą, aby zminimalizować przerwy w działaniu usługi dla klastrów.

W tym artykule dowiesz się, jak działa funkcja automatycznego naprawiania węzłów dla węzłów systemu Windows i Linux.

Jak usługa AKS sprawdza węzły "NotReady"

Usługa AKS używa następujących reguł, aby określić, czy węzeł jest w złej kondycji i wymaga naprawy:

• Węzeł zgłasza stan NotReady podczas kolejnych kontroli w ciągu 10-minutowego przedziału czasu.
• Węzeł nie zgłasza żadnego stanu przez 10 minut.

Stan kondycji węzłów można sprawdzić ręcznie za pomocą polecenia kubectl get nodes.

Jak działa automatyczna naprawa

Uwaga

AKS inicjuje operacje naprawy za pomocą konta użytkownika aks-remediator.

Jeśli usługa AKS identyfikuje węzeł w złej kondycji, który pozostaje w takim stanie przez co najmniej pięć minut, usługa AKS wykonuje następujące działania:

1. AKS ponownie uruchamia węzeł.
2. Jeśli węzeł pozostanie w złej kondycji po ponownym uruchomieniu, usługa AKS ponownie zobrazuje węzeł.
3. Jeśli węzeł pozostanie w złej kondycji po ponownym stworzeniu obrazu i jest węzłem systemu Linux, usługa AKS ponownie wdroży węzeł.

Usługa AKS podejmuje próbę ponownego uruchomienia, przywracania obrazu oraz ponownego wdrażania sekwencji maksymalnie trzy razy, jeśli węzeł pozostanie niezdrowy. Proces naprawy samochodowej może zająć do godziny.

Ograniczenia

Automatyczna naprawa węzła usługi AKS jest usługą o charakterze "best effort" i nie gwarantujemy przywrócenia węzła do stanu pełnej sprawności. Jeśli węzeł utrzymuje się w złym stanie, zdecydowanie zachęcamy do dokładnego przeprowadzenia ręcznego badania stanu węzła. Dowiedz się więcej o rozwiązywaniu problemów węzła o stanie NotReady.

Istnieją przypadki, w których AKS nie wykonuje automatycznej naprawy. Nie można automatycznie naprawić węzła zgodnie z projektem lub jeśli platforma Azure nie może wykryć, że problem istnieje. Przykłady, gdy automatyczna naprawa nie jest wykonywana, obejmują:

• Stan węzła nie jest zgłaszany z powodu błędu w konfiguracji sieci.
• Nie można początkowo zarejestrować węzła jako zdrowego węzła.
• Jeśli na węźle znajdują się którekolwiek z następujących wartości: node.cloudprovider.kubernetes.io/shutdown, ToBeDeletedByClusterAutoscaler.
• Węzeł jest w trakcie aktualizacji, co skutkuje następującą adnotacją na węźle "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" i "kubernetes.azure.com/azure-cluster-autoscaler-scale-down-disabled-reason": "upgrade"

Monitorowanie automatycznej naprawy węzła za pomocą zdarzeń Kubernetes

Gdy usługa AKS wykonuje automatyczną naprawę węzła w klastrze, usługa AKS emituje zdarzenia Kubernetes ze źródła aks-auto-repair dla zapewnienia widoczności. Podczas automatycznej naprawy są wyświetlane następujące zdarzenia w obiekcie węzła.

Aby dowiedzieć się więcej na temat uzyskiwania dostępu do zdarzeń kubernetes, przechowywania i konfigurowania alertów, zobacz Używanie zdarzeń kubernetes do rozwiązywania problemów w usłudze Azure Kubernetes Service.

Przyczyna	Wiadomość zdarzenia	opis
NodeRebootStart	Automatyczna naprawa węzła inicjuje akcję ponownego uruchamiania z powodu stanu NotReady utrzymującego się przez ponad 5 minut.	To zdarzenie jest emitowane w celu powiadomienia Cię, gdy ponowne uruchomienie ma zostać wykonane na twoim węźle. Ta akcja jest pierwszą w ogólnej sekwencji automatycznej naprawy węzła.
NodeRebootEnd	Akcja ponownego rozruchu po automatycznej naprawie węzła została ukończona.	Emitowane po zakończeniu ponownego rozruchu w węźle. To zdarzenie nie wskazuje stanu zdrowia (zdrowy lub niezdrowy) węzła po wykonaniu ponownego uruchomienia.
NodeReimageStart	Automatyczna naprawa węzła inicjuje akcję przywracania obrazu ze względu na stan NotReady trwający ponad 5 minut.	To zdarzenie jest emitowane w celu powiadomienia cię, gdy ponowne obrazowanie ma być wykonane na twoim węźle.
NodeReimageEnd	Akcja przywracania obrazu z automatycznego naprawy węzła została ukończona.	Emitowane po zakończeniu ponownego obrazu w węźle. To zdarzenie nie wskazuje, czy węzeł jest zdrowy czy niezdrowy po ponownym wgraniu obrazu.
NodeRedeployStart	Automatyczna naprawa węzła inicjuje akcję ponownego wdrażania z powodu statusu "NotReady", który utrzymuje się dłużej niż 5 minut.	To zdarzenie jest emitowane w celu powiadomienia Cię, gdy ponowna instalacja ma zostać wykonana na twoim węźle. Ponowne wdrożenie to ostatnia akcja w sekwencji automatycznej naprawy węzła.
NodeRedeployEnd	Zakończono ponowne wdrożenie akcji automatycznej naprawy węzła.	Emitowane po zakończeniu ponownego wdrażania w węźle. To zdarzenie nie wskazuje stanu (zdrowy lub chory) węzła po przeprowadzeniu ponownego wdrożenia.

Jeśli podczas procesu automatycznego naprawiania węzła wystąpią jakiekolwiek błędy, następujące zdarzenia są emitowane z komunikatem o błędzie dosłownym. Dowiedz się więcej o rozwiązywaniu typowych błędów automatycznego naprawiania węzłów.

Uwaga

Kod błędu w następujących komunikatach o zdarzeniach różni się w zależności od zgłoszonego błędu.

Przyczyna	Wiadomość zdarzenia	opis
NodeRebootError	Akcja restartu automatycznej naprawy węzła nie powiodła się z powodu błędu operacji. Zobacz szczegóły błędu tutaj: Kod błędu	Emitowane w przypadku wystąpienia błędu z akcją ponownego uruchamiania.
NodeReimageError	Akcja automatycznego naprawiania obrazu węzła nie powiodła się z powodu błędu operacji. Zobacz szczegóły błędu tutaj: Kod błędu	Emitowane w przypadku wystąpienia błędu przy operacji ponownego obrazowania.
NodeRedeployError	Akcja ponownego wdrażania węzła nie powiodła się z powodu niepowodzenia operacji. Zobacz szczegóły błędu tutaj: Kod błędu	Emitowane w przypadku wystąpienia błędu w akcji ponownego wdrażania.

Następne kroki

Domyślnie możesz uzyskać dostęp do zdarzeń Kubernetes i dzienników na klastrze AKS z ostatniej godziny. Aby przechowywać i wykonywać zapytania dotyczące zdarzeń i dzienników z ostatnich 90 dni, włącz usługę Container Insights , aby uzyskać bardziej szczegółowe informacje na temat rozwiązywania problemów w klastrze usługi AKS.