Condividi tramite

Risolvere i problemi relativi a una modifica in un nodo integro su Non pronto

  • Articolo

Questo articolo illustra uno scenario in cui lo stato di un nodo del cluster servizio Azure Kubernetes (servizio Azure Kubernetes) cambia in Non pronto dopo che il nodo è in uno stato integro per un certo periodo di tempo. Questo articolo descrive la causa specifica e fornisce una possibile soluzione.

Prerequisiti

Sintomi

Lo stato di un nodo del cluster con uno stato integro (tutti i servizi in esecuzione) cambia in modo imprevisto in Non pronto. Per visualizzare lo stato di un nodo, eseguire il comando kubectl describe seguente:

kubectl describe nodes

Causa

Kubelet ha interrotto la pubblicazione dello stato Pronto.

Esaminare l'output del kubectl describe nodes comando per trovare il campo Condizioni e i blocchi Capacity e Allocatable . Il contenuto di questi campi viene visualizzato come previsto? (Ad esempio, in Campo Condizioni , la message proprietà contiene la stringa "kubelet sta pubblicando lo stato pronto?) In questo caso, se si ha accesso diretto a Secure Shell (SSH) al nodo, controllare gli eventi recenti per comprendere l'errore. Esaminare il file /var/log/messages . In alternativa, generare i file di log del daemon di contenitori e kubelet eseguendo i comandi della shell seguenti:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

Dopo aver eseguito questi comandi, esaminare i messaggi e i file di log del daemon per altre informazioni sull'errore.

Soluzione

Passaggio 1: Verificare la presenza di modifiche a livello di rete

Se tutti i nodi del cluster sono regrediti a uno stato Non pronto , verificare se sono state apportate modifiche a livello di rete. Esempi di modifiche a livello di rete includono:

  • Modifiche al Domain Name System (DNS)
  • La regola del firewall cambia, ad esempio porta, nomi di dominio completi (FQDN) e così via.
  • Gruppi di sicurezza di rete aggiunti
  • Configurazioni della tabella di route applicate o modificate per il traffico del servizio Azure Kubernetes

Se sono state apportate modifiche a livello di rete, apportare eventuali correzioni necessarie. Se si ha accesso diretto a Secure Shell (SSH) al nodo, è possibile usare il curl comando o telnet per controllare la connettività ai requisiti in uscita del servizio Azure Kubernetes. Dopo aver risolto i problemi, arrestare e riavviare i nodi. Se i nodi rimangono in uno stato integro dopo queste correzioni, è possibile ignorare in modo sicuro i passaggi rimanenti.

Passaggio 2: Arrestare e riavviare i nodi

Se solo alcuni nodi sono regrediti a uno stato Non pronto , è sufficiente arrestare e riavviare i nodi. Già solo questa operazione potrebbe far passare i nodi a uno stato integro. Controllare quindi servizio Azure Kubernetes panoramica della diagnostica per determinare se sono presenti problemi, ad esempio i problemi seguenti:

  • Errori del nodo
  • Errori SNAT (Source Network Address Translation)
  • Problemi di prestazioni delle operazioni di input/output al secondo del nodo (IOPS)
  • Altri problemi

Se la diagnostica non rileva problemi sottostanti e i nodi tornano allo stato Pronto, è possibile ignorare in modo sicuro i passaggi rimanenti.

Passaggio 3: Risolvere i problemi SNAT per i cluster API del servizio Azure Kubernetes pubblici

La diagnostica del servizio Azure Kubernetes ha scoperto eventuali problemi di SNAT? In tal caso, eseguire alcune delle azioni seguenti, in base alle esigenze:

  • Controllare se le connessioni rimangono inattive per molto tempo e si basano sul timeout di inattività predefinito per rilasciarne la porta. Se le connessioni presentano questo comportamento, potrebbe essere necessario ridurre il timeout predefinito di 30 minuti.

  • Determinare il modo in cui l'applicazione crea la connettività in uscita. Ad esempio, usa la revisione del codice o l'acquisizione di pacchetti?

  • Determinare se questa attività rappresenta il comportamento previsto o, invece, mostra che l'applicazione non funziona correttamente. Usare le metriche e i log in Monitoraggio di Azure per convalidare i risultati. Ad esempio, è possibile usare la categoria Non riuscito come metrica Connessioni SNAT.

  • Valutare se vengono seguiti i modelli appropriati.

  • Valutare se è necessario ridurre l'esaurimento delle porte SNAT usando indirizzi IP in uscita aggiuntivi e allocando più porte in uscita. Per altre informazioni, vedere Ridimensionare il numero di indirizzi IP pubblici in uscita gestiti e Configurare le porte in uscita allocate.

Per altre informazioni su come risolvere i problemi di exhaution delle porte SNAT, vedere Risolvere i problemi di esaurimento delle porte SNAT nei nodi del servizio Azure Kubernetes.

Passaggio 4: Risolvere i problemi di prestazioni delle operazioni di I/O al secondo

Se la diagnostica del servizio Azure Kubernetes rileva problemi che riducono le prestazioni di IOPS, eseguire alcune delle azioni seguenti, in base alle esigenze:

  • Per aumentare le operazioni di I/O al secondo nei set di scalabilità di macchine virtuali , scegliere una dimensione del disco più grande che offre prestazioni di I/O al secondo migliori distribuendo un nuovo pool di nodi. Il ridimensionamento diretto dei set di scalabilità di macchine virtuali direttamente non è supportato. Per altre informazioni sul ridimensionamento dei pool di nodi, vedere Ridimensionare i pool di nodi in servizio Azure Kubernetes (servizio Azure Kubernetes).

  • Aumentare le dimensioni dello SKU del nodo per una maggiore capacità di memoria ed elaborazione della CPU.

  • Prendere in considerazione l'uso del sistema operativo temporaneo.

  • Limitare l'utilizzo della CPU e della memoria da parte dei pod. Questi limiti consentono di evitare l'utilizzo della CPU del nodo e situazioni in cui la memoria risulta insufficiente.

  • Usare i metodi di pianificazione della topologia per aggiungere altri nodi e distribuire il carico tra i nodi. Per altre informazioni, vedere Vincoli di distribuzione della topologia pod.

Passaggio 5: Risolvere i problemi di threading

I componenti Kubernetes, ad esempio kubelet e runtime in contenitori , si basano principalmente sul threading e generano regolarmente nuovi thread. Se l'allocazione dei nuovi thread non riesce, questo errore può influire sull'idoneità del servizio, come mostrato in seguito:

  • Lo stato del nodo cambia in Non pronto, ma viene riavviato da un correzione ed è in grado di eseguire il ripristino.

  • Nei file di log /var/log/messages e /var/log/syslog sono presenti occorrenze ripetute delle voci di errore seguenti:

    pthread_create non riuscito: risorsa temporaneamente non disponibile in vari processi

    I processi citati includono containerd e kubelet.

  • Lo stato del nodo diventa Non pronto subito dopo che le voci di pthread_create errore vengono scritte nei file di log.

Gli ID processo (PID) rappresentano i thread. Il numero predefinito di ID che un pod può usare dipende dal sistema operativo. Tuttavia, il numero predefinito è almeno 32.768. Questa quantità è maggiore di quanto serve per la maggior parte delle situazioni. Esistono requisiti dell'applicazione noti per le risorse PID più esigenti? In caso contrario, anche aumentando il numero di otto volte, a 262.144 PID potrebbe non essere sufficiente a supportare un'applicazione con risorse esigenti.

Identificare l'applicazione che causa il problema e quindi eseguire l'azione appropriata. Prendere in considerazione altre opzioni, ad esempio l'aumento delle dimensioni della macchina virtuale o l'upgrade del servizio Azure Kubernetes. Queste azioni possono attenuare temporaneamente il problema, ma non sono una garanzia che il problema non si ripresenti.

Per monitorare il numero di thread per ogni gruppo di controlli (cgroup) e stampare i primi otto cgroup, eseguire questo comando shell:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Per altre informazioni, vedere Limiti e prenotazioni dell'ID processo.

Kubernetes offre due metodi per gestire l'esaurimento di PID a livello di nodo:

  1. Configurare il numero massimo di PID consentiti in un pod all'interno di un kubelet usando il --pod-max-pids parametro . Questa configurazione imposta l'impostazione pids.max all'interno del cgroup di ogni pod. È anche possibile usare i --system-reserved parametri e --kube-reserved per configurare rispettivamente i limiti di sistema e kubelet.

  2. Configurare la rimozione basata su PID.

Note

Per impostazione predefinita, nessuno di questi metodi è configurato. Inoltre, non è attualmente possibile configurare alcun metodo usando la configurazione del nodo per i pool di nodi del servizio Azure Kubernetes.

Passaggio 6: Usare un livello di servizio superiore

È possibile assicurarsi che il server API del servizio Azure Kubernetes abbia disponibilità elevata usando un livello di servizio superiore. Per altre informazioni, vedere il contratto di servizio con tempo di attività del servizio Azure Kubernetes servizio Azure Kubernetes (AKS).

Ulteriori informazioni

  • Per visualizzare l'integrità e le prestazioni del server API del servizio Azure Kubernetes e dei kubelet, vedere Componenti del servizio Azure Kubernetes gestiti.

  • Per i passaggi generali per la risoluzione dei problemi, vedere Risoluzione dei problemi di base dei nodi non pronti.