Rozwiązywanie problemów ze stanem Nie gotowe węzła w dobrej kondycji

  • Artykuł

W tym artykule omówiono scenariusz, w którym stan węzła klastra Azure Kubernetes Service (AKS) zmieni się na Nie gotowe, gdy węzeł będzie w dobrej kondycji przez pewien czas. W tym artykule opisano konkretną przyczynę i przedstawiono możliwe rozwiązanie.

Wymagania wstępne

Symptomy

Stan węzła klastra o stanie dobrej kondycji (wszystkie uruchomione usługi) nieoczekiwanie zmienia się na Nie gotowe. Aby wyświetlić stan węzła, uruchom następujące polecenie kubectl describe :

kubectl describe nodes

Przyczyna

Narzędzie kubelet przestało publikować swój stan Gotowości .

Przeanalizuj dane wyjściowe polecenia, kubectl describe nodes aby znaleźć pole Warunki oraz bloki Pojemność i Możliwość przydzielania . Czy zawartość tych pól jest wyświetlana zgodnie z oczekiwaniami? (Na przykład w polu messageWarunki właściwość zawiera ciąg "kubelet is posting ready status"?) W takim przypadku, jeśli masz bezpośredni dostęp secure shell (SSH) do węzła, sprawdź ostatnie zdarzenia, aby zrozumieć błąd. Zajrzyj do pliku /var/log/messages . Możesz też wygenerować pliki dziennika demona kubelet i kontenera, uruchamiając następujące polecenia powłoki:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

Po uruchomieniu tych poleceń sprawdź pliki dziennika demona, aby uzyskać szczegółowe informacje o błędzie.

Krok 1. Sprawdzanie zmian na poziomie sieci

Jeśli wszystkie węzły klastra spadły do stanu Nie gotowe, sprawdź, czy jakiekolwiek zmiany wystąpiły na poziomie sieci. Przykłady zmian na poziomie sieci obejmują następujące elementy:

  • Zmiany systemu nazw domen (DNS)
  • Zmiany portów zapory
  • Dodano sieciowe grupy zabezpieczeń

Jeśli na poziomie sieci nastąpiły zmiany, wprowadź wszelkie niezbędne poprawki. Zatrzymaj i uruchom ponownie węzły uruchomione po rozwiązaniu problemów. Jeśli węzły pozostaną w dobrej kondycji po tych poprawkach, możesz bezpiecznie pominąć pozostałe kroki.

Krok 2. Zatrzymywanie i ponowne uruchamianie węzłów

Jeśli tylko kilka węzłów cofnie się do stanu Nie gotowe , po prostu zatrzymaj i uruchom ponownie węzły. Sama ta akcja może przywrócić stan węzłów w dobrej kondycji. Następnie sprawdź, Azure Kubernetes Service omówienie diagnostyki, aby ustalić, czy występują jakiekolwiek problemy, takie jak następujące problemy:

  • Błędy węzła
  • Błędy tłumaczenia adresów sieci źródłowej (SNAT)
  • Problemy z wydajnością operacji wejścia/wyjścia węzła na sekundę
  • Inne problemy

Jeśli diagnostyka nie odnajdzie żadnych podstawowych problemów, możesz bezpiecznie pominąć pozostałe kroki.

Krok 3. Rozwiązywanie problemów z SNAT dla publicznych klastrów interfejsu API usługi AKS

Czy diagnostyka usługi AKS wykryła problemy z usługą SNAT? Jeśli tak, w razie potrzeby wykonaj niektóre z następujących akcji:

  • Sprawdź, czy połączenia pozostają bezczynne przez długi czas i korzystaj z domyślnego limitu czasu bezczynności, aby zwolnić port. Jeśli połączenia wykazują takie zachowanie, może być konieczne skrócenie domyślnego limitu czasu wynoszącego 30 minut.

  • Określanie sposobu tworzenia łączności wychodzącej przez aplikację. Czy na przykład używa przeglądu kodu lub przechwytywania pakietów?

  • Określ, czy to działanie reprezentuje oczekiwane zachowanie, czy też pokazuje, że aplikacja źle się zachowuje. Użyj metryk i dzienników w usłudze Azure Monitor, aby uzasadnić swoje wyniki. Na przykład można użyć kategorii Niepowodzenie jako metryki Connections SNAT.

  • Oceń, czy są stosowane odpowiednie wzorce.

  • Oceń, czy należy ograniczyć wyczerpanie portów SNAT przy użyciu dodatkowych wychodzących adresów IP i większej liczby przydzielonych portów wychodzących. Aby uzyskać więcej informacji, zobacz Skalowanie liczby zarządzanych wychodzących publicznych adresów IP i Konfigurowanie przydzielonych portów wychodzących.

Krok 4. Rozwiązywanie problemów z wydajnością operacji we/wy na sekundę

Jeśli diagnostyka usługi AKS odkryje problemy, które zmniejszają wydajność operacji we/wy na sekundę, w razie potrzeby wykonaj niektóre z następujących akcji:

  • Aby zwiększyć liczbę operacji we/wy na sekundę w zestawach skalowania maszyn wirtualnych, zmień rozmiar dysku, wdrażając nową pulę węzłów.

  • Zwiększ rozmiar jednostki SKU węzła, aby uzyskać większą ilość pamięci i możliwości przetwarzania procesora CPU.

  • Rozważ użycie efemerycznego systemu operacyjnego.

  • Ogranicz użycie procesora CPU i pamięci dla zasobników. Te limity pomagają zapobiegać zużyciu procesora CPU w węzłach i sytuacjom braku pamięci.

  • Użyj metod topologii planowania, aby dodać więcej węzłów i rozdzielić obciążenie między węzły. Aby uzyskać więcej informacji, zobacz Ograniczenia rozprzestrzeniania topologii zasobników.

Krok 5. Rozwiązywanie problemów z wątkami

Składniki platformy Kubernetes, takie jak kubelets i containerd runtimes , w dużym stopniu polegają na wątkowości i regularnie pojawiają nowe wątki. Jeśli alokacja nowych wątków zakończy się niepowodzeniem, ten błąd może wpłynąć na gotowość usługi w następujący sposób:

  • Stan węzła zmienia się na Nie gotowe, ale jest ponownie uruchamiany przez korygator i może zostać odzyskany.

  • W plikach dziennika /var/log/messages i /var/log/syslog występują powtarzające się wystąpienia następujących wpisów błędów:

    pthread_create nie powiodło się: zasób tymczasowo niedostępny przez różne procesy

    Procesy, które są cytowane obejmują konteneryzowane i prawdopodobnie kubelet.

  • Stan węzła zmieni się na Nie gotowe wkrótce po zapisaniu pthread_create wpisów błędów w plikach dziennika.

Identyfikatory procesów reprezentują wątki. Domyślna liczba identyfikatorów PID, których może używać zasobnik, może zależeć od systemu operacyjnego. Jednak domyślna liczba to co najmniej 32 768. Ta kwota jest większa niż wystarczająca liczba identyfikatorów PID w większości sytuacji. Czy istnieją znane wymagania dotyczące aplikacji dla wyższych zasobów PID? Jeśli tak nie jest, nawet ośmiokrotny wzrost do 262 144 identyfikatorów PID może nie wystarczyć do obsługi aplikacji o wysokim poziomie zasobów.

Zamiast tego zidentyfikuj aplikację powodującą przestępstwa, a następnie podejmij odpowiednie działania. Rozważ inne opcje, takie jak zwiększenie rozmiaru maszyny wirtualnej lub uaktualnienie usługi AKS. Te akcje mogą tymczasowo rozwiązać problem, ale nie gwarantują, że problem nie pojawi się ponownie.

Aby monitorować liczbę wątków dla każdej grupy kontrolek (cgroup) i wydrukować osiem pierwszych grup, uruchom następujące polecenie powłoki:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Aby uzyskać więcej informacji, zobacz Limity identyfikatorów procesów i rezerwacje.

Platforma Kubernetes oferuje dwie metody zarządzania wyczerpaniem PID na poziomie węzła:

  1. Skonfiguruj maksymalną liczbę identyfikatorów PID dozwolonych w zasobniku w ramach polecenia kubelet przy użyciu parametru --pod-max-pids . Ta konfiguracja pids.max ustawia ustawienie w grupie cgroup każdego zasobnika. Możesz również użyć --system-reserved parametrów i --kube-reserved , aby skonfigurować odpowiednio limity systemowe i kubelet.

  2. Konfigurowanie eksmisji opartej na protokole PID.

Uwaga

Domyślnie żadna z tych metod nie jest skonfigurowana. Ponadto obecnie nie można skonfigurować żadnej z metod przy użyciu konfiguracji węzła dla pul węzłów usługi AKS.

Krok 6. Używanie wyższej warstwy usługi

Możesz upewnić się, że serwer interfejsu API usługi AKS ma wysoką dostępność przy użyciu wyższej warstwy usługi. Aby uzyskać więcej informacji, zobacz Azure Kubernetes Service (AKS) Uptime SLA (Umowa SLA dotycząca czasu pracy usługi AKS).

Więcej informacji