Timeout TCP quando kubectl o altri strumenti di terze parti si connettono al server API

Questo articolo illustra come risolvere i timeout TCP che si verificano quando kubectl o altri strumenti di terze parti vengono usati per connettersi al server API in Microsoft servizio Azure Kubernetes (servizio Azure Kubernetes). Per garantire gli obiettivi del livello di servizio e i contratti di servizio , il servizio Azure Kubernetes usa piani di controllo a disponibilità elevata che vengono ridimensionati verticalmente e orizzontalmente, in base al numero di core.

Sintomi

Si verificano timeout di connessione ripetuti.

Causa 1: I pod responsabili della comunicazione tra nodi e piano di controllo non sono in esecuzione

Se solo alcuni comandi DELL'API si verificano in modo coerente, i pod seguenti potrebbero non trovarsi in uno stato di esecuzione:

• konnectivity-agent
• tunnelfront
• aks-link

Note

Nelle versioni tunnelfront più recenti del servizio Azure Kubernetes e aks-link vengono sostituiti con konnectivity-agent, quindi verrà visualizzato konnectivity-agentsolo .

Questi pod sono responsabili della comunicazione tra un nodo e il piano di controllo.

Soluzione: ridurre l'utilizzo o lo stress degli host del nodo

Assicurarsi che i nodi che ospitano questi pod non vengano usati eccessivamente o sotto stress. Prendere in considerazione lo spostamento dei nodi nel proprio pool di nodi di sistema.

Per verificare il nodo in cui è ospitato il konnectivity-agent pod e l'utilizzo del nodo, eseguire i comandi seguenti:

# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
    
# Check the usage of the node hosting the pod
$ kubectl top node

Causa 2: l'accesso è bloccato in alcune porte, FQDN e indirizzi IP necessari

Se le porte necessarie, i nomi di dominio completi (FQDN) e gli indirizzi IP non sono tutti aperti, è possibile che diverse chiamate di comando non riescano. La comunicazione sicura e sottoposta a tunneling nel servizio Azure Kubernetes tra il server API e il kubelet (tramite il konnectivity-agent pod) richiede che alcuni di questi elementi funzionino correttamente.

Soluzione: aprire le porte, i nomi di dominio completi e gli indirizzi IP necessari

Per altre informazioni sulle porte, i nomi di dominio completi e gli indirizzi IP da aprire, vedere Regole di rete in uscita e FQDN per cluster servizio Azure Kubernetes (servizio Azure Kubernetes).

Causa 3: L'estensione TLS di negoziazione protocollo a livello di applicazione è bloccata

Per stabilire una connessione tra il piano di controllo e i nodi, il konnectivity-agent pod richiede l'estensione TLS (Transport Layer Security) per application-layer protocol negotiation (ALPN). Questa estensione potrebbe essere stata bloccata in precedenza.

Soluzione: abilitare l'estensione ALPN

Abilitare l'estensione ALPN nel konnectivity-agent pod per evitare timeout TCP.

Causa 4: gli intervalli ip autorizzati del server API non coprono l'indirizzo IP corrente

Se si usano intervalli di indirizzi IP autorizzati nel server API, le chiamate API verranno bloccate se l'INDIRIZZO IP non è incluso negli intervalli autorizzati.

Soluzione: Modificare gli intervalli di indirizzi IP autorizzati in modo da coprire l'indirizzo IP

Modificare gli intervalli di indirizzi IP autorizzati in modo che l'indirizzo IP sia coperto. Per altre informazioni, vedere Aggiornare gli intervalli IP autorizzati del server API di un cluster.

Causa 5: un client o un'applicazione perde chiamate al server API

Le chiamate GET frequenti possono accumulare ed eseguire l'overload del server API.

Soluzione: usare watches invece di chiamate GET, ma assicurarsi che l'applicazione non trapeli tali chiamate

Assicurarsi di usare watches anziché frequenti chiamate GET al server API. È anche necessario assicurarsi che le applicazioni di terze parti non perdono connessioni di controllo o chiamate GET. Nell'architettura del microservizio Istio, ad esempio, un bug nell'applicazione mixer crea una nuova connessione di controllo server API ogni volta che un segreto viene letto internamente. Poiché questo comportamento si verifica a intervalli regolari, le connessioni di controllo si accumulano rapidamente. Queste connessioni alla fine causano l'overload del server API indipendentemente dal modello di ridimensionamento.

Causa 6: Troppe versioni nelle distribuzioni Helm

Se si usano troppe versioni nelle distribuzioni di Helm (gestione pacchetti Kubernetes), i nodi iniziano a usare troppa memoria. Genera anche una grande quantità di oggetti (dati di configurazione), che potrebbero causare picchi di ConfigMap utilizzo non necessari nel server API.

Soluzione: limitare il numero massimo di revisioni per ogni versione

Poiché il numero massimo di revisioni per ogni versione è infinito per impostazione predefinita, è necessario eseguire un comando per impostare questo numero massimo su un valore ragionevole. Per Helm 2, il comando è helm init. Per Helm 3, il comando è helm upgrade. Impostare il --history-max <value> parametro quando si esegue il comando .

Versione	Comando
Helm 2	helm init --history-max <maximum-number-of-revisions-per-release> ...
Helm 3	helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ...

Causa 7: Il traffico interno tra nodi viene bloccato

Potrebbero esserci blocchi di traffico interni tra i nodi del cluster del servizio Azure Kubernetes.

Soluzione: risolvere l'errore "dial tcp <Node_IP>:10250: i/o timeout"

Vedere Risolvere i timeout TCP, ad esempio "dial tcp <Node_IP>:10250: i/o timeout".

Causa 8: Il cluster è privato

Il cluster è un cluster privato, ma il client da cui si sta tentando di accedere al server API si trova in una rete pubblica o diversa che non può connettersi alla subnet usata dal servizio Azure Kubernetes.

Soluzione: usare un client che possa accedere alla subnet del servizio Azure Kubernetes

Poiché il cluster è privato e il relativo piano di controllo si trova nella subnet del servizio Azure Kubernetes, non può essere connesso al server API a meno che non si trova in una rete in grado di connettersi alla subnet del servizio Azure Kubernetes. Si tratta di un comportamento previsto.

In questo caso, provare ad accedere al server API da un client in una rete in grado di comunicare con la subnet del servizio Azure Kubernetes. Verificare inoltre che i gruppi di sicurezza di rete (NSG) o altri appliance tra reti non blocchino i pacchetti.

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

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.