Risolvere i problemi relativi al codice di errore OutboundConnFailVMExtensionError (50) in servizio Azure Kubernetes

Sommario

Questo articolo illustra come identificare e risolvere l'errore OutboundConnFailVMExtensionError (codice di errore ERR_OUTBOUND_CONN_FAIL, numero di errore 50) che può verificarsi quando si crea, si avvia, si ridimensiona o si aggiorna un cluster Servizio Azure Kubernetes (AKS). Seguire questa procedura per ripristinare la connettività in uscita in modo che il provisioning dei nodi abbia esito positivo.

Prerequisites

Prima di iniziare la risoluzione dei problemi, verificare che siano soddisfatti i prerequisiti seguenti:

• I seguenti strumenti da riga di comando. Eseguire questi strumenti nel nodo AKS in cui sono installati per impostazione predefinita, non nel computer locale:
  • Strumento URL client (cURL)
  • Strumento da riga di comando Netcat (nc)
  • Strumento della riga di comando dig
• interfaccia della riga di comando di Azure, se non è possibile connettersi al nodo usando SSH e si vogliono invece eseguire i comandi tramite run-command.

Symptoms

Quando si tenta di creare, ridimensionare o aggiornare un cluster del servizio Azure Kubernetes, viene visualizzato un messaggio di errore simile all'esempio seguente:

Code: OutboundConnFailVMExtensionError
Message: Create or update virtual machine extension /subscriptions/<subscription-id>/resourceGroups/<node-resource-group>/providers/Microsoft.Compute/virtualMachines/<vm-name>/extensions/<extension-name> failed. VM has reported a user failure when processing extension '<extension-name>'. Please correct the error and try again. (publisher 'Microsoft.Azure.Extensions' and type 'CustomScript'). Error code: '2'. Error message: 'failed to execute command: command terminated with exit status=50
[stdout]
{ "ExitCode": "50", "Output": "...
+ retrycmd_if_failure 20 1 15 curl -v --insecure --proxy-insecure https://mcr.microsoft.com/v2/
...
+ exit 50", ... }

[stderr]
{"level":"ERROR","msg":"aks-node-controller failed","error":"provision failed: exitCode=50 ..."}
...
More information on troubleshooting is available at https://aka.ms/VMExtensionCSELinuxTroubleshoot.

Gli indicatori chiave di questo errore sono il codice OutboundConnFailVMExtensionError, il valore exit status=50 e il comando curl rispetto a https://mcr.microsoft.com/v2/ nell'output. Il nome dell'estensione dipende dal tipo di pool di nodi. Ad esempio, i pool di nodi di set di scalabilità di macchine virtuali usano vmssCSE, e i pool di nodi di Macchine virtuali usano nomi come cse-agent-<number>.

Questo errore potrebbe anche causare che i nodi in esecuzione diventino NotReady o causare errori di pull delle immagini perché la connettività in uscita è bloccata per alcuni o tutti i nodi del cluster.

Cause

Durante il provisioning dei nodi, Custom Script Extension (CSE) esegue un controllo di connettività sull'endpoint di Microsoft Container Registry (MCR) eseguendo curl -v --insecure --proxy-insecure https://mcr.microsoft.com/v2/. Il controllo viene ripetuto più volte. Se il nodo non riesce a raggiungere mcr.microsoft.com tramite HTTPS sulla porta 443, il CSE viene chiuso con codice 50 e il provisioning dei nodi ha esito negativo.

Questo requisito in uscita si applica a tutti i cluster AKS, indipendentemente dal fatto che il cluster sia pubblico o privato. L'impostazione pubblica o privata controlla solo la modalità di accesso al server API. Non modifica la connettività in uscita richiesta dai nodi. Per l'elenco completo degli endpoint e delle porte che i nodi di Servizio Azure Kubernetes (AKS) devono raggiungere, vedere Regole di rete in uscita e FQDN per i cluster Servizio Azure Kubernetes (AKS).

Molti motivi possono bloccare il traffico in uscita. Un buon punto di partenza consiste nell'eseguire un'analisi della connettività con Rete virtuale di Azure Verifier. Eseguendo un'analisi della connettività, è possibile visualizzare gli hop all'interno del flusso di traffico ed eventuali configurazioni errate nelle risorse di rete di Azure che bloccano il traffico. Per risolvere manualmente gli errori di connettività in uscita, è possibile usare il protocollo SSH (Secure Shell Protocol) per connettersi al nodo. Questa sezione illustra le istruzioni per entrambi i tipi di indagini.

Controllare se le risorse di rete di Azure bloccano il traffico verso l'endpoint

Per determinare se le risorse di rete di Azure bloccano il traffico verso l'endpoint, eseguire un'analisi della connettività dai nodi del cluster AKS all'endpoint usando lo strumento Rete virtuale di Azure Verifier.

1. Nel portale di Azure passare al cluster. Nella barra laterale passare a Impostazioni>Pool di nodi.
2. Trovare il pool di nodi da cui si vuole eseguire un'analisi della connettività. Selezionare il pool di nodi per impostarlo come ambito.
3. Selezionare Analisi della connettività (anteprima) sulla barra degli strumenti nella parte superiore della pagina. Se non lo vedi, seleziona i tre puntini (...) nella barra degli strumenti nella parte superiore della pagina per aprire il menu espanso.

1. Selezionare un'istanza del set di scalabilità di macchine virtuali (VMSS) come origine. Gli indirizzi IP di origine vengono popolati automaticamente.
2. Selezionare un nome di dominio pubblico/endpoint come destinazione per l'analisi, ad esempio mcr.microsoft.com. Anche gli indirizzi IP di destinazione vengono popolati automaticamente.
3. Eseguire l'analisi e attendere fino a 2 minuti per i risultati. Nel diagramma risultante identificare le risorse di rete di Azure associate e la posizione in cui viene bloccato il traffico. Per visualizzare l'output dettagliato dell'analisi, selezionare la scheda Output JSON o selezionare le frecce nel diagramma.

Risoluzione dei problemi manuali

Se lo strumento Rete virtuale di Azure Verifier non fornisce informazioni sufficienti sul problema, è possibile risolvere manualmente gli errori di connettività in uscita usando il protocollo SSH (Secure Shell Protocol) per connettersi al nodo. Per stabilire la connessione, seguire le istruzioni in Connettersi ai nodi del cluster di Servizio Azure Kubernetes (AKS) per la manutenzione o la risoluzione dei problemi. Testare quindi la connettività nel cluster seguendo questa procedura.

Passo 1: Testare la connettività in uscita verso MCR

Dopo la connessione al nodo, eseguire la stessa verifica della connettività eseguita dal CSE:

curl -v --insecure --proxy-insecure https://mcr.microsoft.com/v2/

Se il comando restituisce una risposta HTTP, ad esempio HTTP/2 200, il nodo può raggiungere MCR. Se il comando non riesce, usare l'errore nell'output dettagliato per identificare dove viene bloccato il traffico:

Per limitare ulteriormente il problema, è possibile testare separatamente la risoluzione DNS e la connettività TCP:

# Test DNS resolution.
dig mcr.microsoft.com

# Test TCP connectivity on port 443 (layer 4 only).
nc -vz mcr.microsoft.com 443

Se non è possibile accedere al nodo tramite SSH, è possibile testare la connettività in uscita eseguendo il comando az vmss run-command invoke sull'istanza del set di scalabilità di macchine virtuali:

# 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 "curl -v --insecure --proxy-insecure https://mcr.microsoft.com/v2/"

Passaggio 2: Testare la connettività tramite un proxy HTTP

Se il cluster AKS usa un proxy HTTP, eseguire i comandi nc, curl e dig dopo la connessione al nodo:

# Test connectivity to the proxy server from the AKS node.
nc -vz <http-s-proxy-address> <port>

# Test HTTPS traffic to MCR through an HTTP proxy server.
curl -v --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com/v2/

# Test HTTPS traffic to MCR through an HTTPS proxy server.
curl -v --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com/v2/

# Test DNS functionality.
dig mcr.microsoft.com

Se non è possibile accedere al nodo tramite SSH, è possibile eseguire gli stessi test usando il comando az vmss run-command invoke sull'istanza di Virtual Machine Scale Set (o il comando az vm run-command invoke per i pool di nodi di Macchine virtuali):

# 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 HTTPS traffic to MCR through an HTTP proxy server.
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 -v --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com/v2/"

# Use an instance ID to test HTTPS traffic to MCR through an HTTPS proxy server.
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 -v --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com/v2/"

# 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"

Solution

La tabella seguente elenca i motivi specifici per cui il traffico potrebbe essere bloccato e la soluzione corrispondente per ogni motivo:

Maggiori informazioni

• Risoluzione generale dei problemi di creazione del cluster di Azure Kubernetes Service