Ridimensionamento del nodo Kubernetes quando i nodi hanno poche risorse
È chiaro dalla documentazione che ogni volta che i pod si trovano nello stato In sospeso perché non esiste un nodo con risorse libere sufficienti per rispettare la richiesta di risorse dei pod, il gestore della scalabilità automatica del cluster creerà un altro nodo entro 30 secondi dalla creazione del pod (per cluster di dimensioni ragionevoli) .
Tuttavia, considera il caso in cui un nodo sia piuttosto compatto. Supponiamo che il nodo abbia 2 core CPU e contenga 4 pod che definiscono una richiesta di 0,5 CPU e un limite di 1,0 CPU. All'improvviso c'è un carico e tutti e 4 i pod richiedono improvvisamente una CPU aggiuntiva di 0,5 che il nodo non è in grado di fornire poiché tutta la sua CPU è già occupata dai 4 pod in esecuzione.
In questa situazione, mi aspetto che Kubernetes "capisca" che ci sono richieste di risorse in sospeso eseguendo pod che non possono essere serviti e "sposti" (distrugga e crei) quei pod su un altro nodo che possa rispettare la loro richiesta (più le risorse che attualmente in uso). Nel caso in cui non esista alcun nodo di questo tipo, mi aspettavo che Kubernetes creasse un nodo aggiuntivo e spostasse lì i pod.
Tuttavia, non vedo che ciò accada. Vedo che i pod sono in esecuzione sullo stesso nodo (immagino che quel nodo possa essere chiamato over-provisioning) indipendentemente dalle richieste di risorse che non possono essere rispettate e di conseguenza le prestazioni ne risentono.
La mia domanda è se questo comportamento sia evitabile con qualsiasi mezzo oltre a impostare il rapporto tra richieste di risorse pod e limiti su 1: 1 (dove un pod non può richiedere più risorse di quelle inizialmente assegnate). Ovviamente eviterei di impostare richieste e limiti uguali per evitare un provisioning insufficiente e pagare più del necessario.
Risposte
È importante riconoscere qui la distinzione tra la CPU requestin un PodSpec e la quantità di cpu che un processo sta tentando di utilizzare. Il provisioning di Kubernetes e la scalabilità automatica del cluster si basano esclusivamente sul requestPodSpec. L'uso effettivo è irrilevante per tali decisioni.
Nel caso che stai descrivendo, il pod richiede ancora solo 0,5 CPU: quel campo è immutabile. Il processo ora sta tentando di utilizzare 1 CPU, ma questo non viene esaminato.
I limiti della CPU superiori alle richieste consentono l'utilizzo ottimale di quella capacità, ma non è una garanzia, come vedi.
In questo scenario, sembra che tu voglia utilizzare sia Horizontal Pod Autoscaler, sia l'autoscaler del cluster. In una situazione con un carico maggiore (in cui i pod iniziano a utilizzare >80% della CPU request, ad esempio), l'HPA aumenterà il numero di pod per il servizio, per gestire la domanda. Se poi quei pod non hanno un posto in cui inserirsi, il programma di scalabilità automatica del cluster eseguirà il provisioning di più nodi. In questo modo, i tuoi pod possono ancora utilizzare fino al valore della richiesta ed è solo quando iniziano ad avvicinarsi ad esso che viene eseguito il provisioning di più nodi, in modo da non eseguire il provisioning eccessivo delle risorse in anticipo.