Udostępnij za pośrednictwem

Rozwiązywanie problemów ze zmianą w węźle w dobrej kondycji na stan Brak gotowości

  • Artykuł

W tym artykule omówiono scenariusz, w którym stan węzła klastra usługi Azure Kubernetes Service (AKS) zmienia się na Nie gotowe po tym, jak węzeł jest w dobrej kondycji przez jakiś czas. W tym artykule opisano konkretną przyczynę i przedstawiono możliwe rozwiązanie.

Wymagania wstępne

Symptomy

Stan węzła klastra, który ma stan 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ć stan Gotowe .

Sprawdź dane wyjściowe kubectl describe nodes polecenia, aby znaleźć pole Warunki oraz bloki Pojemność i Allocatable . Czy zawartość tych pól jest wyświetlana zgodnie z oczekiwaniami? (Na przykład w obiekcie Pole Warunki , czy message właściwość zawiera ciąg "kubelet publikuje gotowy stan"? W takim przypadku, jeśli masz bezpośredni dostęp protokołu 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 kubelet i demona kontenera, uruchamiając następujące polecenia powłoki:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

Po uruchomieniu tych poleceń sprawdź komunikaty i pliki dziennika demona, aby uzyskać więcej informacji na temat błędu.

Rozwiązanie

Krok 1. Sprawdzanie zmian na poziomie sieci

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

  • Zmiany w systemie nazw domen (DNS)
  • Zmiany reguły zapory, takie jak port, w pełni kwalifikowane nazwy domen (FQDN) itd.
  • Dodane sieciowe grupy zabezpieczeń (NSG)
  • Zastosowane lub zmienione konfiguracje tabeli tras dla ruchu usługi AKS

Jeśli nastąpiły zmiany na poziomie sieci, wprowadź niezbędne poprawki. Jeśli masz bezpośredni dostęp protokołu Secure Shell (SSH) do węzła, możesz użyć curl polecenia lub telnet , aby sprawdzić łączność z wymaganiami ruchu wychodzącego usługi AKS. Po rozwiązaniu problemów zatrzymaj i uruchom ponownie węzły. Jeśli węzły pozostają w dobrej kondycji po tych poprawkach, można bezpiecznie pominąć pozostałe kroki.

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

Jeśli tylko kilka węzłów ulegnie regresji do stanu Nie wszystko gotowe , po prostu zatrzymaj i uruchom ponownie węzły. Ta akcja może spowodować przywrócenie węzłów do dobrej kondycji. Następnie zapoznaj się z omówieniem diagnostyki usługi Azure Kubernetes Service, aby ustalić, czy występują jakieś problemy, takie jak następujące problemy:

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

Jeśli diagnostyka nie wykryje żadnych podstawowych problemów, a węzły powróciły do stanu Gotowe, możesz bezpiecznie pominąć pozostałe kroki.

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

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

  • 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ą to zachowanie, może być konieczne skrócenie domyślnego limitu czasu 30 minut.

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

  • Ustal, czy to działanie reprezentuje oczekiwane zachowanie, czy też pokazuje, że aplikacja działa nieprawidłowo. Użyj metryk i dzienników w usłudze Azure Monitor, aby uzasadnić wyniki. Na przykład możesz użyć kategorii Niepowodzenie jako metryki Połączenia SNAT.

  • Oceń, czy są przestrzegane odpowiednie wzorce.

  • Oceń, czy należy ograniczyć wyczerpywanie 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 publicznych adresów IP wychodzących i Konfigurowanie przydzielonych portów wychodzących.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z ekshaution portów SNAT, zobacz Rozwiązywanie problemów z wyczerpaniem portów SNAT w węzłach usługi AKS.

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ę, wykonaj niektóre z następujących akcji, odpowiednio:

  • Aby zwiększyć liczbę operacji we/wy na sekundę w zestawach skalowania maszyn wirtualnych, wybierz większy rozmiar dysku, który zapewnia lepszą wydajność operacji we/wy na sekundę, wdrażając nową pulę węzłów. Bezpośrednie zmienianie rozmiaru zestawu skalowania maszyn wirtualnych nie jest obsługiwane. Aby uzyskać więcej informacji na temat zmiany rozmiaru pul węzłów, zobacz Zmienianie rozmiaru pul węzłów w usłudze Azure Kubernetes Service (AKS).

  • Zwiększ rozmiar jednostki SKU węzła, aby uzyskać więcej 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żywaniu procesora CPU węzła i zbyt małej ilości pamięci.

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

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

Składniki platformy Kubernetes, takie jak kubelets i środowiska uruchomieniowe kontenerów , intensywnie korzystają z wątków i regularnie tworzą nowe wątki. Jeśli alokacja nowych wątków nie powiedzie się, ten błąd może mieć wpływ na gotowość usługi w następujący sposób:

  • Stan węzła zmienia się na Nie gotowe, ale jest ponownie uruchamiany przez narzędzie korygujące i jest w stanie odzyskać.

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

    pthread_create nie powiodło się: zasób tymczasowo niedostępny z powodu różnych procesów

    Cytowane procesy obejmują kontenery i ewentualnie kubelet.

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

Identyfikatory procesów (PID) reprezentują wątki. Domyślna liczba identyfikatorów PID, których może używać zasobnik, może być zależna od systemu operacyjnego. Jednak domyślna liczba to co najmniej 32 768. Jest ona większa niż wystarczająca liczba identyfikatorów PID w większości sytuacji. Czy istnieją znane wymagania aplikacji dotyczące wyższych zasobów piD? Jeśli tak nie jest, nawet ośmiokrotny wzrost do 262 144 PID może nie wystarczyć, aby pomieścić aplikację o wysokim zużyciu zasobów.

Zamiast tego zidentyfikuj aplikację sprawiającą problemy, a następnie podejmij odpowiednie działania. Rozważ inne opcje, takie jak zwiększenie rozmiaru maszyny wirtualnej lub uaktualnienie usługi AKS. Te działania mogą tymczasowo rozwiązać ten problem, ale nie są one gwarancją, że problem się nie powtórzy.

Aby monitorować liczbę wątków dla każdej grupy kontrolnej (cgroup) i wyświetlić osiem pierwszych grup cgroup, 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 procesu i rezerwacje.

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

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

  2. Konfigurowanie eksmisji opartej na usłudze PID.

Uwaga 16.

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

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

Upewnij 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 Umowa SLA dotycząca czasu działania usługi Azure Kubernetes Service (AKS).

Więcej informacji