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

W tym artykule opisano sposób identyfikowania i rozwiązywania błędu (znanego OutboundConnFailVMExtensionError również jako kod ERR_OUTBOUND_CONN_FAILbłędu , błąd o numerze 50), który może wystąpić w przypadku próby uruchomienia lub utworzenia i wdrożenia klastra usługi Microsoft Azure Kubernetes Service (AKS).

Wymagania wstępne

  • Narzędzie wiersza polecenia Netcat (nc)

  • Narzędzie wiersza polecenia dig

  • Narzędzie Adres URL klienta (cURL)

Symptomy

Podczas próby uruchomienia lub utworzenia klastra usługi AKS zostanie wyświetlony następujący komunikat o błędzie:

Nie można nawiązać połączenia wychodzącego od 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: "Nie można włączyć: nie można wykonać polecenia: polecenie zakończone ze stanem zakończenia=50\n[stdout]\n\n[stderr]\nnc: połączenie z portem 443 (tcp) mcr.microsoft.com nie powiodło się: upłynął limit czasu połączenia\npolecenie zostało zakończone ze stanem innym niż zero

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

Przyczyna

Rozszerzenie skryptu niestandardowego, które pobiera składniki niezbędne do aprowizowania węzłów, nie może 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) (mcr.microsoft.com) na porcie 443.

Istnieje wiele powodów, dla których ruch może zostać zablokowany. W każdej z tych sytuacji najlepszym sposobem przetestowania łączności jest użycie protokołu SSH (Secure Shell) do nawiązania połączenia z węzłem. Aby nawiązać połączenie, postępuj zgodnie z instrukcjami w temacie Łączenie z węzłami klastra Azure Kubernetes Service (AKS) w celu 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
    

    Uwaga

    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
    

    Uwaga

    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"
    

Rozwiązanie

W poniższej tabeli wymieniono konkretne przyczyny zablokowania ruchu oraz odpowiednie rozwiązanie z każdego powodu.

Problem Rozwiązanie
Ruch jest blokowany przez reguły zapory lub serwer proxy W tym scenariuszu zapora lub serwer proxy przeprowadza filtrowanie ruchu wychodzącego. Aby sprawdzić, czy wszystkie wymagane domeny i porty są dozwolone, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w Azure Kubernetes Service (AKS).
Ruch jest blokowany przez sieciową grupę zabezpieczeń klastra W przypadku sieciowych grup zabezpieczeń dołączonych do klastra sprawdź, czy nie ma blokowania na porcie 443, porcie 53 lub innym porcie, który może wymagać połączenia z punktem końcowym. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze Azure Kubernetes Service (AKS).
Rekord AAAA (IPv6) jest zablokowany w zaporze W zaporze sprawdź, czy nie ma żadnych elementów, które uniemożliwiałyby 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) musi zostać dodany 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, które ułatwiają znalezienie dodatkowych informacji na ten temat. 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 lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.