Come ripulire le vecchie attività di Kubernetes
Agenzia web » Notizie digitali » Come eseguire il debug degli errori "FailedScheduling" di Kubernetes

Come eseguire il debug degli errori "FailedScheduling" di Kubernetes

I problemi di pianificazione del pod sono uno degli errori Kubernetes più comuni. Ci sono diversi motivi per cui un nuovo pod può rimanere bloccato in un Pending stato con FailedScheduling come sua ragione. Un pod che mostra questo stato non avvierà alcun contenitore, quindi non sarai in grado di utilizzare la tua applicazione.

I pod in sospeso causati da problemi di pianificazione normalmente non si avviano senza l'intervento manuale. Dovrai trovare la causa principale e agire per riparare il tuo cluster. In questo articolo imparerai come diagnosticare e risolvere questo problema in modo da poter aumentare i tuoi carichi di lavoro.

Identificazione di un errore di pianificazione non riuscita

È normale che i pod visualizzino a Pending stato per un breve periodo dopo averli aggiunti al tuo cluster. Kubernetes deve pianificare le istanze del contenitore sui tuoi nodi e tali nodi devono estrarre l'immagine dal suo registro. Il primo segno di un errore di pianificazione del pod è quando si presenta sempre come Pending trascorso il consueto periodo di avviamento. Puoi controllare lo stato eseguendo Kubectl's get pods ordinato:

$ kubectl get pods NOME PRONTO STATO RIAVVIA ETÀ demo-pod 0/1 In sospeso 0 4m05s

demo-pod più di quattro minuti, ma è ancora nel Pending Stato. I pod di solito non impiegano molto tempo per avviare i container, quindi è tempo di iniziare a indagare su cosa si aspetta Kubernetes.

Il passaggio diagnostico successivo consiste nel recuperare la cronologia degli eventi del Pod utilizzando il describe pod ordinato:

$ kubectl describe pod demo-pod ... Eventi: Tipo Motivo Età Da Messaggio ---- ------ ---- ---- ------- ... Avviso Pianificazione non riuscita 4m predefinito- scheduler Sono disponibili 0/4 nodi: 1 Troppi pod, 3 CPU insufficiente.

Il registro eventi conferma a FailedScheduling l'errore è il motivo dell'estensione Pending Stato. Questo evento viene segnalato quando Kubernetes non è in grado di allocare il numero richiesto di pod a uno dei nodi di lavoro del tuo cluster.

Il messaggio dell'evento rivela perché la pianificazione non è attualmente possibile: ci sono quattro nodi nel cluster, ma nessuno di essi può prendere il pod. Tre dei nodi hanno una capacità CPU insufficiente mentre l'altro ha raggiunto un limite massimo al numero di pod che può accettare.

Comprensione degli errori di pianificazione non riuscita e di problemi simili

Kubernetes può pianificare i pod solo su nodi con risorse di riserva. I nodi che esauriscono la CPU o la memoria non possono più accettare i pod. I pod possono anche non riuscire nella pianificazione se richiedono esplicitamente più risorse di quelle che un nodo può fornire. Ciò mantiene stabile il tuo cluster.

Il piano di controllo Kubernetes sa quali pod sono già allocati ai nodi nel tuo cluster. Utilizza queste informazioni per determinare l'insieme di nodi che possono ricevere un nuovo pod. Si verifica un errore di pianificazione quando nessun candidato è disponibile, lasciando il pod bloccato Pending fino a quando l'abilità non viene rilasciata.

Kubernetes potrebbe anche non programmare i pod per altri motivi. I nodi possono essere ritenuti non idonei per ospitare un Pod in diversi modi, anche se dispongono di risorse di sistema adeguate:

  • Il nodo potrebbe essere stato bloccato da un amministratore per impedirgli di ricevere nuovi pod prima di un'operazione di manutenzione.
  • Il nodo potrebbe avere un effetto che impedisce la pianificazione dei pod. Il tuo pod non sarà accettato dal nodo a meno che non abbia una tolleranza di corrispondenza.
  • Il tuo pod potrebbe richiedere a hostPort che è già collegato al nodo. I nodi possono fornire un numero di porta particolare a un Pod alla volta.
  • Il tuo pod potrebbe utilizzare a nodeSelector questo significa che deve essere programmato su un nodo con una etichetta particolare. I nodi senza tag non saranno idonei.
  • Le affinità e le anti-affinità di pod e nodi possono essere insoddisfacenti, causando un conflitto di pianificazione che impedisce l'accettazione di nuovi pod.
  • Il Pod potrebbe avere a nodeName campo che identifica un nodo specifico da pianificare. Il pod sarà bloccato in attesa se questo nodo è offline o non pianificato.

È responsabilità di kube-scheduler, lo scheduler Kubernetes, per elaborare queste condizioni e identificare l'insieme di nodi che possono ospitare un nuovo pod. UN FailedScheduling L'evento si verifica quando nessuno dei nodi soddisfa i criteri.

Stato della pianificazione non riuscita

Il messaggio visualizzato accanto a FailedScheduling in genere rivelano perché ogni nodo nel tuo cluster non può prendere il pod. È possibile utilizzare queste informazioni per iniziare a risolvere il problema. Nell'esempio precedente, il cluster aveva quattro pod, tre in cui era stato raggiunto il limite della CPU e uno che aveva superato un limite di conteggio dei pod.

La capacità del cluster è la causa principale in questo caso. Puoi ridimensionare il tuo cluster con nuovi nodi per risolvere i problemi di consumo dell'hardware, aggiungendo risorse che forniranno ulteriore flessibilità. Poiché ciò aumenterà anche i tuoi costi, vale la pena controllare prima se hai pod ridondanti nel tuo cluster. La rimozione delle risorse inutilizzate libererà capacità per quelle nuove.

Puoi ispezionare le risorse disponibili su ciascuno dei tuoi nodi usando il describe node ordinato:

$ kubectl descrive il nodo demo-node ... Risorse allocate: (I limiti totali possono essere superiori al 100 percento, ad es. overcommitted.) Limiti delle richieste di risorse -------- -------- ---- -- CPU 812m (90%) 202m (22%) memoria 905Mi (57%) 715Mi (45%) memoria temporanea 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%)

I pod su questo nodo richiedono già il 57% della memoria disponibile. Se un nuovo pod richiedesse 1 Gi per sé, il nodo non sarebbe in grado di accettare la richiesta di pianificazione. Il monitoraggio di queste informazioni per ciascuno dei tuoi nodi può aiutarti a valutare se il tuo cluster sta subendo un provisioning eccessivo. È importante disporre di capacità di riserva nel caso in cui uno dei nodi si guasta e i suoi carichi di lavoro debbano essere riprogrammati su un altro.

Gli errori di pianificazione dovuti alla mancanza di nodi pianificabili visualizzeranno un messaggio simile al seguente in FailedScheduling Evento:

Sono disponibili 0/4 nodi: 4 nodi non erano programmabili

I nodi che non possono essere pianificati perché sono stati sottoposti a loop includeranno SchedulingDisabled nel loro campo di stato:

$ kubectl get nodes NOME STATO RUOLI ETÀ VERSIONE node-1 Ready,SchedulingDisabled control-plane,master 26m v1.23.3

Puoi scollegare il nodo per consentirgli di ricevere nuovi pod:

$ kubectl uncordon nodo-1 nodo/nodo-1 non cordonato

Quando i nodi non sono chiusi e dispongono di risorse sufficienti, gli errori di pianificazione sono generalmente causati da contaminazione o errore nodeSelector campo sul tuo Pod. Se usi nodeSelectorverifica di non aver commesso un errore di battitura e che ci siano pod nel tuo cluster che hanno le etichette che hai specificato.

Quando i nodi sono contaminati, assicurati di aver incluso la tolleranza corrispondente nel manifest del tuo pod. Ad esempio, ecco un nodo che è stato contaminato, quindi i pod non verranno programmati a meno che non abbiano un demo-taint: allow tolleranza:

$ kubectl contamina i nodi node-1 demo-taint=allow:NoSchedule

Modifica i manifesti del tuo pod in modo che possano pianificare sul nodo:

spec:
  tolleranze:
    - chiave: contaminazione dimostrativa
      operatore: Pari
      APPREZZIAMO: consentire
      effetto: Nessun programma

Risolvi il problema che causa il FailedScheduling lo stato consentirà a Kubernetes di riprendere la pianificazione dei pod in sospeso. Inizieranno a funzionare automaticamente poco dopo che il piano di controllo ha rilevato le modifiche ai tuoi nodi. Non è necessario riavviare o ricreare manualmente i pod a meno che il problema non sia causato da errori nel manifest del pod, come affinità errata o nodeSelector campi.

sommario

FailedScheduling si verificano errori quando Kubernetes non può posizionare un nuovo pod su un nodo nel tuo cluster. Ciò è spesso causato dai nodi esistenti che esauriscono le risorse hardware come CPU, memoria e disco. In questo caso, puoi risolvere il problema ridimensionando il tuo cluster per includere nodi aggiuntivi.

Gli errori di pianificazione si verificano anche quando i pod specificano affinità di nodo, anti-affinità e selettori che attualmente non possono essere soddisfatti dai nodi disponibili nel cluster. I nodi bloccati e contaminati riducono ulteriormente le opzioni disponibili per Kubernetes. Questo tipo di problema può essere risolto controllando i manifesti per errori di battitura nelle etichette e rimuovendo i vincoli che non ti servono più.

★ ★ ★ ★ ★