Problemi di connettività del tunnel
Microsoft servizio Azure Kubernetes (AKS) usa un componente specifico per la comunicazione sicura 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 nodi del cluster. Questo articolo illustra come risolvere i problemi correlati alla connettività del tunnel nel servizio Azure Kubernetes.
Note
In precedenza, il componente tunnel del servizio Azure Kubernetes era tunnel-front. È stata ora eseguita la migrazione al servizio Konnectivity, un componente Kubernetes upstream. Per altre informazioni su questa migrazione, vedere le note sulla versione del servizio Azure Kubernetes e il log delle modifiche.
Prerequisiti
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 del server: errore di composizione back-end: dial tcp <aks-node-ip>:10250: i/o timeout
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 del 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à come le seguenti non funzioneranno come previsto:
Webhook del controller di ammissione
Possibilità di recupero dei log (usando il comando kubectl logs )
Esecuzione di un comando in un contenitore o all'interno di un contenitore (usando il comando kubectl exec )
Inoltro di una o più porte locali di un pod (usando il comando kubectl port-forward )
Causa 1: un gruppo di sicurezza di rete (NSG) blocca la porta 10250
Note
Questa causa è applicabile a tutti i componenti del tunnel 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 funzioneranno perché i 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 netcat (nc) o i comandi telnet. È possibile eseguire il comando az vmss run-command invoke per eseguire il test di connettività e verificare se ha esito positivo, raggiunge il 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.
Note
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 priorità più alta). Per altre informazioni sulla priorità, vedere Regole di sicurezza.
Se non viene visualizzata alcuna modifica comportamentale dopo l'applicazione di questa soluzione, è possibile ricreare i pod dei componenti del tunnel. Se si eliminano questi pod, questi vengono ricreati.
Causa 2: Lo strumento UFW (Uncomplicated Firewall) blocca la porta 10250
Note
Questa causa si applica a qualsiasi componente del tunnel presente nel cluster del servizio Azure Kubernetes.
Firewall non replicato (UFW) è un programma da riga di comando per la gestione di un firewall netfilter . I nodi del servizio Azure Kubernetes usano Ubuntu. Di conseguenza, 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 accade se i risultati indicano che UFW è abilitato e non consente specificamente 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 dei nodi e l'accesso) per impedire che il cluster entri in uno scenario non supportato.
Note
Se non viene visualizzata alcuna modifica comportamentale dopo l'applicazione di una soluzione, è possibile ricreare i pod dei componenti del tunnel. L'eliminazione di questi pod causerà la ricreazione.
Soluzione 2a: Disabilitare il firewall non replicato
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 non replicato per consentire l'accesso alla porta 10250
Per forzare UFW a consentire l'accesso 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
Note
Questa causa si applica a qualsiasi componente del 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)targetprot(protocollo)optsourcedestination
La INPUT 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 sulla 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 lo scenario esatto o potenziale, è consigliabile controllare il manuale delle tabelle ip 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 dei nodi e l'accesso) per impedire che il cluster entri in uno scenario non supportato.
Causa 4: la porta in uscita 1194 o 9000 non viene aperta
Note
Questa causa si applica solo tunnel-front ai pod e aks-link .
Esistono restrizioni sul traffico in uscita, ad esempio da un firewall del servizio Azure Kubernetes? In caso affermativo, la porta 9000 è necessaria per abilitare la funzionalità corretta del tunnel-front pod. Analogamente, per il pod è necessaria la aks-link porta 1194.
Konnectivity si basa sulla porta 443. Per impostazione predefinita, questa porta è aperta. Di conseguenza, non è necessario preoccuparsi dei problemi di connettività su tale porta.
Soluzione 4: Aprire la porta 9000
Anche se tunnel-front è stato spostato nel servizio Konnectivity, alcuni cluster del servizio Azure Kubernetes usano tunnel-frontancora , che si basa sulla porta 9000. Assicurarsi che l'appliance virtuale o qualsiasi dispositivo di rete o software consenta l'accesso alla porta 9000. Per altre informazioni sulle regole e sulle dipendenze necessarie, vedere Regole di rete necessarie a livello globale di Azure.
Causa 5: Esaurimento delle porte SNAT (Source Network Address Translation)
Note
Questa causa si applica a qualsiasi componente del 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 le comunicazioni pubbliche. Per i cluster del servizio Azure Kubernetes privati, il server API si trova all'interno della rete virtuale o della subnet 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 di tunnel si trova sul lato server API. Di conseguenza, la connettività del tunnel non verrà stabilita.
Se le risorse della porta SNAT vengono 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 inattive.
È possibile visualizzare le porte SNAT dalle metriche 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:
Nella portale di Azure cercare e selezionare Servizi Kubernetes.
Nell'elenco dei servizi Kubernetes selezionare il nome del cluster.
Nel riquadro dei menu del cluster individuare l'intestazione Impostazioni e quindi selezionare Proprietà.
Selezionare il nome elencato in Gruppo di risorse infrastruttura.
Selezionare il servizio di bilanciamento del carico kubernetes .
Nel riquadro dei menu del servizio di bilanciamento del carico individuare l'intestazione Monitoraggio e quindi selezionare Metriche.
Per il tipo di metrica selezionare SNAT Connection Count (Conteggio connessioni SNAT).
Selezionare Applicare separazione.
Impostare Split by (Divisione per ) su Connection State (Stato connessione).
Diagnostica del servizio
Per usare la diagnostica del servizio per visualizzare le porte SNAT, seguire questa procedura:
Nella portale di Azure cercare e selezionare Servizi Kubernetes.
Nell'elenco dei servizi Kubernetes selezionare il nome del cluster.
Nel riquadro dei menu del cluster selezionare Diagnostica e risoluzione dei problemi.
Selezionare Problemi di connettività.
In SNAT Connection and Port Allocation (Connessione SNAT) e Port Allocation (Allocazione porte) selezionare Visualizza dettagli.
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 può verificarsi perché un'applicazione non riutilizza le connessioni esistenti. È consigliabile non creare una connessione in uscita per ogni richiesta. Una configurazione di questo tipo può causare l'esaurimento della connessione. Controllare se il codice dell'applicazione segue le procedure consigliate e l'uso del 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.