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

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

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 przypadku większości obciążeń produkcyjnych rozwiązanie AKS Automatic jest zalecanym, domyślnym rozwiązaniem gotowym do użycia produkcyjnego w usłudze AKS. Zarówno klastry AKS Automatic, jak i AKS Standard są domyślnie skonfigurowane z funkcją automatycznego naprawiania węzłów.

W tym artykule dowiesz się, jak działa automatyczna naprawa węzłów, kiedy są uruchamiane działania naprawcze, jakie obowiązują ograniczenia oraz jak monitorować zdarzenia związane z naprawą.

Zachowanie automatycznego naprawiania węzła według trybu klastra

Oba tryby klastra AKS są domyślnie skonfigurowane do automatycznego samonaprawiania węzłów:

  • AKS Automatic: Wstępnie skonfigurowane w ramach domyślnych ustawień AKS Automatic gotowych do użycia w środowisku produkcyjnym.
  • AKS Standard: Skonfigurowany wstępnie w klastrach AKS Standard bez dodatkowej konfiguracji.

Oba tryby używają tych samych kontroli kondycji węzła i tej samej sekwencji naprawy opisanej w tym artykule.

Aby uzyskać więcej informacji na temat domyślnych ustawień platformy AKS Automatic, zobacz Co to jest Azure Kubernetes Service (AKS) Automatic?

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 wykryje węzeł w złym stanie, który pozostaje w złym stanie przez co najmniej pięć minut, 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 odtworzy węzeł.
  3. Jeśli węzeł pozostaje w stanie niezdrowym po ponownym utworzeniu obrazu, a jest to węzeł z systemem Linux, usługa AKS wdraża go ponownie.

Usługa AKS ponawia sekwencję ponownego uruchomienia, ponownego utworzenia obrazu i ponownego wdrożenia maksymalnie trzy razy, jeśli węzeł pozostaje w niezdrowym stanie. Całkowity proces automatycznego naprawiania może potrwać do jednej godziny.

Zagadnienia dotyczące środowiska produkcyjnego

Automatyczna naprawa węzłów to kluczowy mechanizm zapewniania odporności, ale należy ją połączyć z praktykami zwiększającymi odporność na poziomie obciążeń:

  • Uruchamiaj krytyczne obciążenia robocze z wieloma replikami.
  • Użyj modułu PodDisruptionBudgets i sond gotowości, aby zmniejszyć wpływ widoczny dla użytkownika.
  • Monitorowanie działań naprawy i zdarzeń błędów w celu wykrywania powtarzających się problemów z węzłem.
  • Uwzględnij czas automatycznej naprawy w SLO/SLA oraz w planowaniu reagowania na incydenty.

Ograniczenia

Automatyczna naprawa węzła usługi AKS to usługa, która jest najlepszym rozwiązaniem. AKS nie gwarantuje, że w każdym scenariuszu węzeł zostanie przywrócony do prawidłowego stanu. Jeśli węzeł pozostaje w złej kondycji, wykonaj ręczne badanie. Aby uzyskać więcej informacji, zobacz temat Rozwiązywanie problemów ze stanem NotReady węzła.

Usługa AKS może nie wykonywać automatycznej naprawy w następujących scenariuszach:

  • Błąd konfiguracji sieci uniemożliwia raportowanie stanu węzła.
  • Węzeł nie rejestruje się jako sprawny.
  • Węzeł ma jedno z następujących taintów:
    • node.cloudprovider.kubernetes.io/shutdown
    • ToBeDeletedByClusterAutoscaler
  • Trwa aktualizacja węzła, który ma następujące adnotacje:
    • "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"
    • "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łów, generuje zdarzenia Kubernetes ze źródła aks-auto-repair. Podczas automatycznej naprawy w obiekcie węzła pojawiają się następujące zdarzenia.

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

Przyczyna Komunikat zdarzenia opis
NodeRebootStart Automatyczna naprawa węzła inicjuje ponowne uruchomienie, ponieważ stan NotReady utrzymuje się przez ponad pięć minut. To zdarzenie powiadamia, że na twoim węźle wkrótce zostanie przeprowadzone ponowne uruchomienie. 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 Mechanizm automatycznej naprawy węzła inicjuje operację odtworzenia obrazu z powodu utrzymywania się stanu NotReady przez ponad pięć minut. To zdarzenie powiadamia użytkownika, gdy na Twoim węźle ma zostać przeprowadzone ponowne obrazowanie.
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 rozpoczyna ponowne wdrożenie z powodu utrzymywania się stanu NotReady przez ponad pięć minut. To zdarzenie powiadamia Cię, gdy na Twoim węźle ma zostać przeprowadzone ponowne wdrożenie. 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 automatycznej naprawy węzła wystąpią błędy, usługa AKS generuje następujące zdarzenia z dokładną treścią komunikatu o błędzie. Aby uzyskać więcej informacji, zobacz Rozwiązywanie 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 Komunikat 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.

Treści powiązane

  • Last updated on