Problemi di connettività del tunneling

Microsoft servizio Azure Kubernetes usa un componente specifico per la comunicazione protetta e con tunneling tra i nodi e il piano di controllo. Il tunnel è costituito da un server sul lato del piano di controllo e da un client sul lato dei nodi del cluster. Questo articolo illustra come risolvere i problemi relativi alla connettività del tunnel nel servizio Azure Kubernetes.

Nota

Per impostazione predefinita, e a seconda dell'area, il componente del tunnel era tunnel-front. Durante l'aggiornamento alla funzionalità contratto di servizio (SLA) uptime, tunnel-front è stato sostituito dal aks-link componente tunnel che usava OpenVPN. Il servizio Azure Kubernetes sta eseguendo la migrazione a Konnectivity. Si tratta di un componente upstream kubernetes che sostituisce sia tunnel-front che aks-link. Per altre informazioni sulla migrazione a Konnectivity come componente tunnel, vedere le note sulla versione del servizio Azure Kubernetes e il log delle modifiche.

Prerequisiti

• Interfaccia della riga di comando di Azure

Sintomi

Viene visualizzato un messaggio di errore simile agli esempi seguenti sulla porta 10250:

Errore dal server: ottenere "https://< aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: i/o timeout

Errore dal server: errore durante la composizione del back-end: comporre tcp <aks-node-ip>:10250: timeout i/o

Il server API Kubernetes usa la porta 10250 per connettersi al kubelet di un nodo per recuperare i log. Se la porta 10250 è bloccata, i log kubectl e altre funzionalità funzioneranno solo per i pod eseguiti nei nodi in cui è pianificato il componente tunnel. Per altre informazioni, vedere Porte e protocolli Kubernetes: nodi di lavoro.

Poiché non è possibile stabilire i componenti del tunnel o la connettività tra il server e il client, le funzionalità seguenti non funzionano come previsto:

• Webhook del controller di ammissione

• Capacità di recupero dei log (tramite il comando kubectl logs )

• Esecuzione di un comando in un contenitore o recupero all'interno di un contenitore (tramite il comando kubectl exec )

• Inoltro di una o più porte locali di un pod (tramite il comando kubectl port-forward )

Causa 1: un gruppo di sicurezza di rete blocca la porta 10250

Nota

Questa causa è applicabile a tutti i componenti del tunnel che potrebbero essere presenti nel cluster del servizio Azure Kubernetes.

È possibile usare un gruppo di sicurezza di rete di Azure per filtrare il traffico di rete da e verso le risorse di Azure in una rete virtuale di Azure. Un gruppo di sicurezza di rete contiene regole di sicurezza che consentono o negano il traffico di rete in ingresso e in uscita tra diversi tipi di risorse di Azure. Per ogni regola, è possibile specificare origine e destinazione, porta e protocollo. Per altre informazioni, vedere Come i gruppi di sicurezza di rete filtrano il traffico di rete.

Se il gruppo di sicurezza di rete blocca la porta 10250 a livello di rete virtuale, le funzionalità del tunnel ,ad esempio i log e l'esecuzione del codice, funzioneranno solo per i pod pianificati nei nodi in cui sono pianificati i pod del tunnel. Gli altri pod non funzionano perché i relativi nodi non saranno in grado di raggiungere il tunnel e il tunnel è pianificato in altri nodi. Per verificare questo stato, è possibile testare la connettività usando i comandi netcat (nc) o telnet. È possibile eseguire il comando az vmss run-command invoke per eseguire il test di connettività e verificare se ha esito positivo, timeout o causa un altro problema:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

Soluzione 1: Aggiungere una regola del gruppo di sicurezza di rete per consentire l'accesso alla porta 10250

Se si usa un gruppo di sicurezza di rete e si hanno restrizioni specifiche, assicurarsi di aggiungere una regola di sicurezza che consenta il traffico per la porta 10250 a livello di rete virtuale. L'immagine portale di Azure seguente mostra una regola di sicurezza di esempio:

Se si vuole essere più restrittivi, è possibile consentire l'accesso alla porta 10250 solo a livello di subnet.

Nota

• Il campo Priorità deve essere regolato di conseguenza. Ad esempio, se si dispone di una regola che nega più porte (inclusa la porta 10250), la regola visualizzata nell'immagine deve avere un numero di priorità inferiore (i numeri inferiori hanno una priorità più alta). Per altre informazioni sulla priorità, vedere Regole di sicurezza.

• Se non vengono visualizzate modifiche comportamentali dopo l'applicazione di questa soluzione, è possibile ricreare i pod del componente tunnel. L'eliminazione di questi pod comporta la ricreazione di questi pod.

Causa 2: lo strumento UFW (Uncomplicated Firewall) blocca la porta 10250

Nota

Questa causa si applica a qualsiasi componente tunnel presente nel cluster del servizio Azure Kubernetes.

Uncomplicated Firewall (UFW) è un programma della riga di comando per la gestione di un firewall netfilter . I nodi del servizio Azure Kubernetes usano Ubuntu. Pertanto, UFW viene installato nei nodi del servizio Azure Kubernetes per impostazione predefinita, ma UFW è disabilitato.

Per impostazione predefinita, se UFW è abilitato, blocca l'accesso a tutte le porte, inclusa la porta 10250. In questo caso, è improbabile che sia possibile usare Secure Shell (SSH) per connettersi ai nodi del cluster del servizio Azure Kubernetes per la risoluzione dei problemi. Questo perché UFW potrebbe anche bloccare la porta 22. Per risolvere i problemi, è possibile eseguire il comando az vmss run-command invoke per richiamare un comando ufw che controlla se UFW è abilitato:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

Cosa succede se i risultati indicano che UFW è abilitato e non consente in modo specifico la porta 10250? In questo caso, le funzionalità del tunnel, ad esempio i log e l'esecuzione del codice, non funzioneranno per i pod pianificati nei nodi con UFW abilitato. Per risolvere il problema, applicare una delle soluzioni seguenti in UFW.

Importante

Prima di usare questo strumento per apportare modifiche, esaminare i criteri di supporto del servizio Azure Kubernetes (in particolare la manutenzione e l'accesso ai nodi) per impedire al cluster di entrare in uno scenario non supportato.

Nota

Se non vengono visualizzate modifiche comportamentali dopo l'applicazione di una soluzione, è possibile ricreare i pod del componente tunnel. Se si eliminano questi pod, questi pod verranno ricreati.

Soluzione 2a: Disabilitare il firewall senza complicazioni

Eseguire il comando seguente az vmss run-command invoke per disabilitare UFW:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

Soluzione 2b: Configurare un firewall semplice per consentire l'accesso alla porta 10250

Per forzare l'accesso UFW alla porta 10250, eseguire il comando seguente az vmss run-command invoke :

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

Causa 3: lo strumento iptables blocca la porta 10250

Nota

Questa causa si applica a qualsiasi componente tunnel presente nel cluster del servizio Azure Kubernetes.

Lo strumento iptables consente a un amministratore di sistema di configurare le regole di filtro dei pacchetti IP di un firewall Linux. È possibile configurare le regole per bloccare la iptables comunicazione sulla porta 10250.

È possibile visualizzare le regole per i nodi per verificare se la porta 10250 è bloccata o se i pacchetti associati vengono eliminati. A tale scopo, eseguire il comando seguente iptables :

iptables --list --line-numbers

Nell'output i dati vengono raggruppati in diverse catene, inclusa la INPUT catena. Ogni catena contiene una tabella di regole nelle intestazioni di colonna seguenti:

• num (numero regola)
• target
• prot (protocollo)
• opt
• source
• destination

INPUT La catena contiene una regola in cui la destinazione è DROP, il protocollo è tcpe la destinazione è tcp dpt:10250? In caso affermativo, iptables blocca l'accesso alla porta di destinazione 10250.

Soluzione 3: Eliminare la regola iptables che blocca l'accesso alla porta 10250

Eseguire uno dei comandi seguenti per eliminare la iptables regola che impedisce l'accesso alla porta 10250:

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

Per risolvere il proprio scenario esatto o potenziale, è consigliabile controllare il manuale delle tabelle iptable eseguendo il iptables --help comando .

Importante

Prima di usare questo strumento per apportare modifiche, esaminare i criteri di supporto del servizio Azure Kubernetes (in particolare la manutenzione e l'accesso ai nodi) per impedire al cluster di entrare in uno scenario non supportato.

Causa 4: la porta in uscita 1194 o 9000 non viene aperta

Nota

Questa causa si applica solo tunnel-front ai pod e aks-link .

Sono presenti restrizioni sul traffico in uscita, ad esempio da un firewall del servizio Azure Kubernetes? In caso affermativo, è necessaria la porta 9000 per abilitare la funzionalità corretta del tunnel-front pod. Analogamente, la porta 1194 è necessaria per il aks-link pod.

La konnectivity si basa sulla porta 443. Per impostazione predefinita, questa porta è aperta. Pertanto, non è necessario preoccuparsi dei problemi di connettività su tale porta.

Soluzione 4: Aprire la porta 1194 o 9000

Assicurarsi che l'appliance virtuale consenta l'accesso alla porta 1194 o alla porta 9000. Per altre informazioni sulle regole e le dipendenze necessarie, vedere Regole di rete richieste globali di Azure.

Causa 5: Esaurimento delle porte SNAT (Network Address Translation) di origine

Nota

Questa causa si applica a qualsiasi componente tunnel presente nel cluster del servizio Azure Kubernetes. Tuttavia, non si applica ai cluster del servizio Azure Kubernetes privati. L'esaurimento delle porte SNAT (Source Network Address Translation) può verificarsi solo per la comunicazione pubblica. Per i cluster del servizio Azure Kubernetes privati, il server API si trova all'interno della subnet o della rete virtuale del servizio Azure Kubernetes.

Se si verifica l'esaurimento delle porte SNAT ( porte SNAT non riuscite), i nodi non possono connettersi al server API. Il contenitore del tunnel si trova sul lato server API. Pertanto, la connettività del tunnel non verrà stabilita.

Se le risorse della porta SNAT sono esaurite, i flussi in uscita hanno esito negativo fino a quando i flussi esistenti non rilasciano alcune porte SNAT. Azure Load Balancer recupera le porte SNAT alla chiusura del flusso. Usa un timeout di inattività di quattro minuti per recuperare le porte SNAT dai flussi inattivi.

È possibile visualizzare le porte SNAT dalle metriche del servizio di bilanciamento del carico del servizio Azure Kubernetes o dalla diagnostica del servizio, come descritto nelle sezioni seguenti. Per altre informazioni su come visualizzare le porte SNAT, vedere Ricerca per categorie controllare le statistiche di connessione in uscita?

Metriche del servizio di bilanciamento del carico del servizio Azure Kubernetes

Per usare le metriche del servizio di bilanciamento del carico del servizio Azure Kubernetes per visualizzare le porte SNAT, seguire questa procedura:

1. Nel portale di Azure cercare e selezionare Servizi Kubernetes.

2. Nell'elenco dei servizi Kubernetes selezionare il nome del cluster.

3. Nel riquadro dei menu del cluster individuare l'intestazione Impostazioni e quindi selezionare Proprietà.

4. Selezionare il nome elencato in Gruppo di risorse infrastruttura.

5. Selezionare il servizio di bilanciamento del carico kubernetes .

6. Nel riquadro dei menu del servizio di bilanciamento del carico individuare l'intestazione Monitoraggio e quindi selezionare Metriche.

7. Per il tipo di metrica selezionare Conteggio connessioni SNAT.

8. Selezionare Applica divisione.

9. Impostare Split by (Dividi per) su Connection State (Stato connessione).

Diagnostica del servizio

Per usare la diagnostica del servizio per visualizzare le porte SNAT, seguire questa procedura:

1. Nel portale di Azure cercare e selezionare Servizi Kubernetes.

2. Nell'elenco dei servizi Kubernetes selezionare il nome del cluster.

3. Nel riquadro dei menu del cluster selezionare Diagnosticare e risolvere i problemi.

4. Selezionare Problemi di connettività.

5. In Connessione SNAT e Allocazione porta selezionare Visualizza dettagli.

6. Se necessario, usare il pulsante Intervallo di tempo per personalizzare l'intervallo di tempo.

Soluzione 5a: assicurarsi che l'applicazione usi il pool di connessioni

Questo comportamento potrebbe verificarsi perché un'applicazione non riutilizza le connessioni esistenti. È consigliabile non creare una connessione in uscita per ogni richiesta. Tale configurazione può causare l'esaurimento della connessione. Controllare se il codice dell'applicazione segue le procedure consigliate e usa il pool di connessioni. La maggior parte delle librerie supporta il pool di connessioni. Pertanto, non è necessario creare una nuova connessione in uscita per ogni richiesta.

Soluzione 5b: modificare le porte in uscita allocate

Se tutto è ok all'interno dell'applicazione, sarà necessario modificare le porte in uscita allocate. Per altre informazioni sull'allocazione delle porte in uscita, vedere Configurare le porte in uscita allocate.

Soluzione 5c: usare un gateway NAT (Managed Network Address Translation) quando si crea un cluster

È possibile configurare un nuovo cluster per l'uso di un gateway NAT (Managed Network Address Translation) per le connessioni in uscita. Per altre informazioni, vedere Creare un cluster del servizio Azure Kubernetes con un gateway NAT gestito.

Dichiarazione di non responsabilità di contatti di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.