Rozwiązywanie problemów z niepowodzeniami braku gotowości węzła spowodowanymi błędami CSE

  • Artykuł

Ten artykuł ułatwia rozwiązywanie problemów ze scenariuszami, w których klaster usługi Microsoft Azure Kubernetes Service (AKS) nie jest w Succeeded stanie, a węzeł usługi AKS nie jest gotowy w puli węzłów z powodu błędów rozszerzenia niestandardowego skryptu (CSE).

Wymagania wstępne

Symptomy

Z powodu błędów CSE węzeł klastra usługi AKS nie jest gotowy w puli węzłów, a klaster usługi AKS nie jest w Succeeded stanie.

Przyczyna

Wdrożenie rozszerzenia węzła kończy się niepowodzeniem i zwraca więcej niż jeden kod błędu podczas aprowizacji narzędzia kubelet i innych składników. Jest to najczęstsza przyczyna błędów. Aby sprawdzić, czy wdrażanie rozszerzenia węzła kończy się niepowodzeniem podczas aprowizacji polecenia kubelet, wykonaj następujące kroki:

  1. Aby lepiej zrozumieć bieżący błąd w klastrze, uruchom polecenia az aks show i az resource update , aby skonfigurować debugowanie:

    clusterResourceId=$(az aks show \
    --resource-group <resource-group-name> --name <cluster-name> --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

  2. Sprawdź dane wyjściowe debugowania i komunikaty o błędach otrzymane z az resource update polecenia względem listy błędów w pliku wykonywalnym pomocnika CSE w witrynie GitHub.

Jeśli którykolwiek z błędów dotyczy wdrożenia narzędzia kubelet w środowisku CSE, sprawdzono, że scenariusz opisany w tym miejscu jest przyczyną niepowodzenia Nie gotowe węzła.

Ogólnie rzecz biorąc, kody zakończenia identyfikują konkretny problem, który powoduje awarię. Na przykład zobaczysz komunikaty, takie jak "Nie można nawiązać komunikacji z serwerem interfejsu API" lub "Nie można nawiązać połączenia z Internetem". Kody zakończenia mogą też ostrzegać o przekroczeniach limitu czasu sieci interfejsu API lub błędzie węzła, który wymaga wymiany.

Rozwiązanie 1. Upewnij się, że niestandardowy serwer DNS jest poprawnie skonfigurowany

Skonfiguruj niestandardowy serwer systemu nazw domen (DNS), aby mógł poprawnie rozpoznać nazwy. Skonfiguruj serwer tak, aby spełniał następujące wymagania:

  • Jeśli używasz niestandardowych serwerów DNS, upewnij się, że serwery są w dobrej kondycji i osiągalne przez sieć.

  • Upewnij się, że niestandardowe serwery DNS mają wymagane warunkowe usługi przesyłania dalej do adresu IP usługi Azure DNS (lub usługi przesyłania dalej do tego adresu).

  • Upewnij się, że prywatna strefa DNS usługi AKS jest połączona z niestandardowymi sieciami wirtualnymi DNS, jeśli są hostowane na platformie Azure.

  • Nie używaj adresu IP usługi Azure DNS z adresami IP niestandardowego serwera DNS. Nie jest to zalecane.

  • Unikaj używania adresów IP zamiast serwera DNS w ustawieniach DNS. Możesz użyć poleceń interfejsu wiersza polecenia platformy Azure, aby sprawdzić tę sytuację na zestawie skalowania maszyny wirtualnej lub zestawie dostępności.

    • W przypadku węzłów zestawu skalowania maszyn wirtualnych użyj polecenia az vmss run-command invoke :

      az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --command-id RunShellScript \
    --instance-id 0 \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --instance-id 0 \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

    • W przypadku węzłów zestawu dostępności maszyny wirtualnej użyj polecenia az vm run-command invoke :

      az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

Aby uzyskać więcej informacji, zobacz Rozpoznawanie nazw dla zasobów w sieciach wirtualnych platformy Azure i centrum i szprychach z niestandardowym systemem DNS.

Rozwiązanie 2. Rozwiązywanie problemów z limitami czasu sieci interfejsu API

Upewnij się, że można uzyskać dostęp do serwera interfejsu API i nie podlega opóźnieniom. Aby to zrobić, wykonaj następujące kroki.

  • Sprawdź podsieć usługi AKS, aby sprawdzić, czy przypisana sieciowa grupa zabezpieczeń blokuje ruch wychodzący 443 do serwera interfejsu API.

  • Sprawdź sam węzeł, aby sprawdzić, czy węzeł ma inną sieciową grupę zabezpieczeń, która blokuje ruch.

  • Sprawdź podsieć usługi AKS pod kątem dowolnej przypisanej tabeli tras. Jeśli tabela tras ma wirtualne urządzenie sieciowe (WUS) lub zaporę, upewnij się, że port 443 jest dostępny dla ruchu wychodzącego. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze AKS.

  • Jeśli system DNS pomyślnie rozpozna nazwy, a interfejs API jest osiągalny, ale cse węzła nie powiodło się z powodu przekroczenia limitu czasu interfejsu API, wykonaj odpowiednią akcję, jak pokazano w poniższej tabeli.

    Ustaw typ Akcja
    Zestaw dostępności maszyn wirtualnych Usuń węzeł z Azure Portal i interfejsu API usługi AKS przy użyciu polecenia kubectl delete node, a następnie ponownie przeskaluj klaster w górę.
    Zestaw skalowania maszyn wirtualnych Zmień rozmiar węzła lub usuń węzeł, a następnie ponownie przeskaluj klaster w górę.

  • Jeśli żądania są ograniczane przez serwer interfejsu API usługi AKS, uaktualnij je do wyższej warstwy usługi. Aby uzyskać więcej informacji, zobacz Umowa SLA dotycząca czasu działania usługi AKS.

Więcej informacji