Rozwiązywanie problemów z błędami braku gotowości węzła spowodowanymi błędami CSE
Ten artykuł ułatwia rozwiązywanie problemów ze scenariuszami, w których klaster usługi Microsoft Azure Kubernetes Service (AKS) nie znajduje się 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
Ze względu na błędy 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 wdrożenie rozszerzenia węzła kończy się niepowodzeniem podczas aprowizacji narzędzia kubelet, wykonaj następujące kroki:
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
Sprawdź dane wyjściowe debugowania i komunikaty o błędach odebrane z
az resource update
polecenia na liście błędów w pliku wykonywalny pomocnika CSE w usłudze GitHub.
Jeśli którykolwiek z błędów obejmuje wdrożenie narzędzia kubelet CSE, sprawdzono, że scenariusz opisany w tym miejscu jest przyczyną błędu Nie gotowego węzła.
Ogólnie rzecz biorąc kody zakończenia identyfikują konkretny problem, który powoduje awarię. Na przykład są wyświetlane 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ż otrzymywać alerty o przekroczeniu limitu czasu sieci interfejsu API lub błędzie węzła, który wymaga zastąpienia.
Rozwiązanie 1. Upewnij się, że niestandardowy serwer DNS jest poprawnie skonfigurowany
Skonfiguruj niestandardowy serwer systemu nazw domen (DNS, Domain Name System), aby mógł poprawnie przeprowadzić rozpoznawanie nazw. 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 są dostępne za pośrednictwem sieci.
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ą one hostowane na platformie Azure.
Nie używaj adresu IP usługi Azure DNS z adresami IP niestandardowego serwera DNS. Takie działanie nie jest to zalecane.
Unikaj używania adresów IP zamiast serwera DNS w ustawieniach DNS. Polecenia interfejsu wiersza polecenia platformy Azure umożliwiają sprawdzenie tej sytuacji w zestawie skalowania maszyn wirtualnych 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 maszyn wirtualnych 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 szprychy z niestandardowym systemem DNS.
Rozwiązanie 2. Rozwiązywanie problemów z limitami czasu sieci interfejsu API
Upewnij się, że serwer interfejsu API jest osiągany i nie występują opóźnienia. W tym celu wykonaj następujące kroki:
Sprawdź podsieć usługi AKS, aby dowiedzieć się, czy przypisana sieciowa grupa zabezpieczeń (NSG) blokuje port 443 ruchu wychodzącego do serwera interfejsu API.
Sprawdź sam węzeł, aby dowiedzieć się, czy węzeł ma inną sieciową grupę zabezpieczeń blokującą ruch.
Sprawdź podsieć usługi AKS dla dowolnej przypisanej tabeli routingu. Jeśli tabela routingu 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 rozpoznaje nazwy, a interfejs API jest osiągalny, ale węzeł CSE zakończył się niepowodzeniem z powodu przekroczenia limitu czasu interfejsu API, podejmij odpowiednie działania, jak przedstawiono w poniższej tabeli.
Ustaw typ Akcja Zestaw dostępności maszyn wirtualnych Usuń węzeł z witryny 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 Utwórz ponownie obraz węzła z witryny Azure Portal lub usuń węzeł, a następnie ponownie przeskaluj klaster w górę. Aby usunąć określony węzeł, użyj polecenia az aks nodepool delete-machines . Najpierw cordon i opróżni go, a następnie usunie węzeł. Jeśli żądania są ograniczane przez serwer interfejsu API usługi AKS, przeprowadź uaktualnienie do wyższej warstwy usługi. Aby uzyskać więcej informacji, zobacz Warstwy cenowe dla usługi AKS.
Więcej informacji
- Ogólne kroki rozwiązywania problemów można znaleźć w temacie Podstawowe rozwiązywanie problemów z błędami Brak gotowości węzła.