Condividi tramite

Risolvere i problemi relativi allo stato non pronto di un nodo integro

  • Articolo

Questo articolo illustra uno scenario in cui lo stato di un nodo del cluster servizio Azure Kubernetes (servizio Azure Kubernetes) viene modificato 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 stato integro (tutti i servizi in esecuzione) viene modificato in modo imprevisto in Non pronto. Per visualizzare lo stato di un nodo, eseguire il comando kubectl describe seguente:

kubectl describe nodes

Causa

Il 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, nel campo Condizioni la message proprietà contiene la stringa "kubelet is posting ready status"?) In questo caso, se si dispone dell'accesso diretto di Secure Shell (SSH) al nodo, controllare gli eventi recenti per comprendere l'errore. Esaminare all'interno del file /var/log/messages . In alternativa, generare i file di log del daemon kubelet e del contenitore eseguendo i comandi della shell seguenti:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

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

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

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

  • Modifiche del sistema DNS (Domain Name System)
  • Modifiche alla porta del firewall
  • Aggiunta di gruppi di sicurezza di rete (NSG)

Se sono state apportate modifiche a livello di rete, apportare le correzioni necessarie. Arrestare e riavviare i nodi in esecuzione dopo aver risolto i problemi. Se i nodi rimangono integre dopo queste correzioni, è possibile ignorare i passaggi rimanenti.

Passaggio 2: Arrestare e riavviare i nodi

Se solo pochi nodi hanno regredito in uno stato Non pronto , è sufficiente arrestare e riavviare i nodi. Questa azione da sola potrebbe riportare 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 di SNAT (Network Address Translation) di origine
  • Problemi di prestazioni delle operazioni di input/output al secondo del nodo
  • Altri problemi

Se la diagnostica non rileva problemi sottostanti, è possibile ignorare i passaggi rimanenti.

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

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

  • Controllare se le connessioni rimangono inattive per un lungo periodo di tempo e si basano sul timeout di inattività predefinito per rilasciare 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, al contrario, indica che l'applicazione si sta comportando in modo errato. Usare metriche e log in Monitoraggio di Azure per creare un'istanza dei risultati. Ad esempio, è possibile usare la categoria Failed come metrica SNAT Connections.

  • Valutare se vengono seguiti i modelli appropriati.

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

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 I/O al secondo, eseguire alcune delle azioni seguenti, a seconda delle esigenze:

  • Per aumentare le operazioni di I/O al secondo nei set di scalabilità di macchine virtuali, modificare le dimensioni del disco distribuendo un nuovo pool di nodi.

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

  • Provare a usare il sistema operativo temporaneo.

  • Limitare l'utilizzo della CPU e della memoria per i pod. Questi limiti consentono di impedire l'utilizzo della CPU del nodo e le situazioni di memoria insufficiente.

  • Usare i metodi di topologia di pianificazione 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 kubelets e runtime in contenitori , si basano principalmente sul threading e generano regolarmente nuovi thread. Se l'allocazione di nuovi thread non riesce, questo errore può influire sull'idoneità del servizio, come indicato di seguito:

  • Lo stato del nodo viene modificato in Non pronto, ma viene riavviato da un agente di 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 riuscita: risorsa temporaneamente non disponibile da vari processi

    I processi citati includono contenitori e possibilmente 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 PID che un pod può usare potrebbe dipendere dal sistema operativo. Tuttavia, il numero predefinito è almeno 32.768. Questa quantità è più che sufficiente per la maggior parte delle situazioni. Sono presenti requisiti noti per le applicazioni per le risorse PID più elevate? In caso contrario, anche un aumento di otto volte a 262.144 ID potrebbe non essere sufficiente per supportare un'applicazione con risorse elevate.

Identificare invece l'applicazione danneggiata e quindi eseguire l'azione appropriata. Prendere in considerazione altre opzioni, ad esempio l'aumento delle dimensioni della macchina virtuale o l'aggiornamento del servizio Azure Kubernetes. Queste azioni possono attenuare temporaneamente il problema, ma non garantiscono che il problema non riapparirà.

Per monitorare il numero di thread per ogni gruppo di controllo (cgroup) e stampare gli otto cgroup principali, eseguire il comando della shell seguente:

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 del 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 lo sfratto basato su PID.

Nota

Per impostazione predefinita, nessuno di questi metodi è configurato. Inoltre, attualmente non è possibile configurare nessuno dei due metodi 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 Tempo di attività servizio Azure Kubernetes (AKS).

Ulteriori informazioni