Udostępnij przez


Rozwiązywanie problemów z kodem błędu OutboundConnFailVMExtensionError (50)

W tym artykule opisano sposób identyfikowania i rozwiązywania błędu OutboundConnFailVMExtensionError (znanego również jako kod błędu ERR_OUTBOUND_CONN_FAIL, numer błędu 50), który może wystąpić w przypadku tworzenia, uruchamiania, skalowania lub uaktualniania klastra usługi Microsoft Azure Kubernetes Service (AKS).

Prerequisites

  • Narzędzie wiersza polecenia Netcat (nc)

  • Narzędzie wiersza polecenia dig

  • Narzędzie Adres URL klienta (cURL)

Symptoms

Podczas próby utworzenia, skalowania lub uaktualnienia klastra usługi AKS może zostać wyświetlony następujący komunikat o błędzie:

Nie można ustanowić połączenia wychodzącego z agentów, zobacz https://aka.ms/aks-required-ports-and-addresses , aby uzyskać więcej informacji.

Szczegóły: Code="VMExtensionProvisioningError"

Message="Maszyna wirtualna zgłosiła błąd podczas przetwarzania rozszerzenia "vmssCSE".

Komunikat o błędzie: "Enable failed: failed to execute command: command terminated with exit status=50\n[stdout]\n\n[stderr]\nnc: connect to mcr.microsoft.com port 443 (tcp) failed: Connection timed out\nCommand exited with non-zero status

Szczegóły błędu: "vmssCSE error messages : {vmssCSE exit status=50, output=pt/apt.conf.d/95proxy...}

Ten błąd może również spowodować, że uruchomione węzły staną się NotReady lub może spowodować błędy pobierania obrazu, ponieważ łączność wychodząca jest zablokowana z niektórych lub wszystkich węzłów w klastrze.

Cause

Niestandardowe rozszerzenie skryptu, które pobiera niezbędne składniki do aprowizacji węzłów, nie mogło ustanowić niezbędnej łączności wychodzącej w celu uzyskania pakietów. W przypadku klastrów publicznych węzły próbują komunikować się z punktem końcowym usługi Microsoft Container Registry (mcr.microsoft.comMCR) na porcie 443.

Istnieje wiele powodów, dla których ruch wychodzący może zostać zablokowany. Najlepszym sposobem rozwiązywania problemów z błędami łączności wychodzącej jest uruchomienie analizy łączności za pomocą narzędzia Azure Virtual Network Verifier (wersja zapoznawcza). Uruchamiając analizę łączności, można wizualizować przeskoki w przepływie ruchu i wszelkie błędy konfiguracji w zasobach sieciowych platformy Azure, które blokują ruch. Aby ręcznie rozwiązać problemy z błędami łączności wychodzącej, możesz użyć protokołu SSH (Secure Shell Protocol), aby nawiązać połączenie z węzłem. W tej sekcji opisano instrukcje dotyczące obu typów badań:

Sprawdź, czy zasoby sieciowe platformy Azure blokują ruch do punktu końcowego

Aby ustalić, czy ruch jest blokowany do punktu końcowego z powodu zasobów sieciowych platformy Azure, uruchom analizę łączności z węzłów klastra usługi AKS do punktu końcowego przy użyciu narzędzia Azure Virtual Network Verifier (wersja zapoznawcza). Analiza łączności obejmuje następujące zasoby:

  • Azure Load Balancer
  • Azure Firewall
  • Brama translatora adresów sieciowych (NAT)
  • Sieciowa grupa zabezpieczeń
  • Zasady sieciowe
  • Trasy zdefiniowane przez użytkownika (tabele tras)
  • Peerowanie sieci wirtualnej

Note

Azure Virtual Network Verifier (wersja zapoznawcza) nie może uzyskać dostępu do żadnych zewnętrznych ani innych zasobów sieciowych firm trzecich, takich jak niestandardowa zapora. Jeśli analiza łączności nie wykryje żadnego zablokowanego ruchu, zalecamy przeprowadzenie ręcznego sprawdzenia dowolnej sieci zewnętrznej w celu pokrycia wszystkich przeskoków w przepływie ruchu.

Obecnie klastry korzystające z nakładki usługi Azure CNI nie są obsługiwane w przypadku tej funkcji. Obsługa nakładki CNI jest planowana na sierpień 2025 r.

  1. Przejdź do klastra w witrynie Azure Portal. Na pasku bocznym przejdź do sekcji Ustawienia -> pule węzłów.
  2. Zidentyfikuj pulę węzłów, z której chcesz uruchomić analizę łączności. Kliknij pulę węzłów, aby wybrać ją jako zakres.
  3. Wybierz pozycję "Analiza łączności (wersja zapoznawcza)" na pasku narzędzi w górnej części strony. Jeśli go nie widzisz, kliknij trzy kropki "..." na pasku narzędzi w górnej części strony, aby otworzyć rozwinięte menu. Użytkownik uruchamia analizę łączności w wybranej puli węzłów.
  4. Wybierz wystąpienie zestawu skalowania maszyn wirtualnych (VMSS) jako źródło. Źródłowe adresy IP są wypełniane automatycznie.
  5. Wybierz nazwę domeny publicznej/punkt końcowy jako miejsce docelowe analizy. Jednym z przykładów jest mcr.microsoft.com. Docelowe adresy IP są również wypełniane automatycznie.
  6. Uruchom analizę i poczekaj do 2 minut na wyniki. Na diagramie wynikowym zidentyfikuj skojarzone zasoby sieciowe platformy Azure i miejsce, w którym ruch jest blokowany. Aby wyświetlić szczegółowe dane wyjściowe analizy, kliknij kartę "Dane wyjściowe JSON" lub kliknij strzałki na diagramie.

Ręczne rozwiązywanie problemów

Jeśli narzędzie Azure Virtual Network Verifier (wersja zapoznawcza) nie zapewnia wystarczającego wglądu w problem, możesz ręcznie rozwiązywać problemy z błędami łączności wychodzącej przy użyciu protokołu SSH (Secure Shell Protocol), aby nawiązać połączenie z węzłem. Aby nawiązać połączenie, postępuj zgodnie z instrukcjami w temacie Nawiązywanie połączenia z węzłami klastra usługi Azure Kubernetes Service (AKS) na potrzeby konserwacji lub rozwiązywania problemów. Następnie przetestuj łączność w klastrze, wykonując następujące kroki:

  1. Po nawiązaniu połączenia z węzłem uruchom nc polecenia i dig :

    nc -vz mcr.microsoft.com 443 
    dig mcr.microsoft.com 443
    

    Note

    Jeśli nie możesz uzyskać dostępu do węzła za pośrednictwem protokołu SSH, możesz przetestować łączność wychodzącą, uruchamiając polecenie az vmss run-command invoke względem wystąpienia zestawu skalowania maszyn wirtualnych:

    # Get the VMSS instance IDs.
    az vmss list-instances --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --output table
    
    # Use an instance ID to test outbound connectivity.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "nc -vz mcr.microsoft.com 443"
    
  2. Jeśli spróbujesz utworzyć klaster usługi AKS przy użyciu serwera proxy HTTP, uruchom ncpolecenia , curli dig po nawiązaniu połączenia z węzłem:

    # Test connectivity to the HTTP proxy server from the AKS node.
    nc -vz <http-s-proxy-address> <port>
    
    # Test traffic from the HTTP proxy server to HTTPS.
    curl --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com
    
    # Test traffic from the HTTPS proxy server to HTTPS.
    curl --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com
    
    # Test DNS functionality.
    dig mcr.microsoft.com 443
    

    Note

    Jeśli nie możesz uzyskać dostępu do węzła za pośrednictwem protokołu SSH, możesz przetestować łączność wychodzącą, uruchamiając az vmss run-command invoke polecenie względem wystąpienia zestawu skalowania maszyn wirtualnych:

    # Get the VMSS instance IDs.
    az vmss list-instances --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --output table
    
    # Use an instance ID to test connectivity from the HTTP proxy server to HTTPS.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "curl --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com"
    
    # Use an instance ID to test connectivity from the HTTPS proxy server to HTTPS.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "curl --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com"
    
    # Use an instance ID to test DNS functionality.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "dig mcr.microsoft.com 443"
    

Solution

W poniższej tabeli wymieniono konkretne przyczyny, dla których ruch może być blokowany, oraz odpowiednie rozwiązanie z każdego powodu:

Issue Solution
Ruch jest blokowany przez reguły zapory, serwer proxy lub sieciową grupę zabezpieczeń Ten problem występuje, gdy wymagane porty usługi AKS lub w pełni kwalifikowane nazwy domen (FQDN) są blokowane przez zaporę, serwer proxy lub sieciową grupę zabezpieczeń. Upewnij się, że te porty i nazwy FQDN są dozwolone. Aby określić, co jest zablokowane, sprawdź łączność podaną w poprzedniej sekcji Przyczyna . Aby uzyskać więcej informacji na temat wymaganych portów i nazw FQDN usługi AKS, zobacz Reguły sieci wychodzącej i nazwy FQDN dla klastrów usługi Azure Kubernetes Service (AKS).
Rekord AAAA (IPv6) jest zablokowany w zaporze W zaporze sprawdź, czy w usłudze Azure DNS nie ma żadnych informacji, które uniemożliwią rozpoznawanie punktu końcowego w usłudze Azure DNS.
Klaster prywatny nie może rozpoznać wewnętrznych zasobów platformy Azure W klastrach prywatnych adres IP usługi Azure DNS (168.63.129.16) należy dodać jako nadrzędny serwer DNS, jeśli jest używany niestandardowy system DNS. Sprawdź, czy adres jest ustawiony na serwerach DNS. Aby uzyskać więcej informacji, zobacz Tworzenie prywatnego klastra usługi AKS i Co to jest adres IP 168.63.129.16?.

Więcej informacji

Wyłączenie odpowiedzialności za kontakty z osobami trzecimi

Firma Microsoft udostępnia informacje kontaktowe innych firm, aby uzyskać dodatkowe informacje na temat tego tematu. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania, możesz zadać pomoc techniczną społeczności platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.