Dovresti impostare i limiti della CPU di Kubernetes?

La gestione delle risorse disponibili per i tuoi pod e container è una procedura consigliata per l'amministrazione di Kubernetes. Devi impedire ai pod di consumare avidamente la CPU e la memoria del tuo cluster. L'eccessivo utilizzo da parte di un set di pod può causare conflitti di risorse che rallentano i container vicini e destabilizzano i tuoi host.

La gestione delle risorse di Kubernetes è spesso fraintesa. Sono previsti due meccanismi per controllare le allocazioni: richieste e limiti. Ciò porta a quattro possibili impostazioni per pod, se imposti una richiesta e un limite sia per la CPU che per la memoria.

Seguendo questo semplice percorso di solito non è ottimale: è meglio omettere i limiti della CPU perché danneggiano le prestazioni e sprecano capacità di riserva. Questo articolo spiegherà il problema in modo da poter eseguire un cluster più efficace.

Come funzionano le richieste e i limiti

Le richieste vengono utilizzate per la programmazione. I nuovi pod verranno assegnati solo ai nodi in grado di soddisfare le loro richieste. Se non esiste un nodo corrispondente, il pod resterà nello stato In attesa fino a quando le risorse non saranno disponibili.

I limiti definiscono l'utilizzo massimo delle risorse consentito dal pod. Quando viene raggiunto il limite, il pod non può più utilizzare la risorsa, anche se sul suo nodo è presente capacità inutilizzata. L'effetto effettivo del raggiungimento del limite dipende dalla risorsa in questione: il superamento di un vincolo della CPU comporta un throttling, mentre il superamento di un limite di memoria farà sì che il killer Pod OOM termini i processi del contenitore.

Nell'esempio seguente, un pod con questi vincoli sarà soloprogrammare a nodi che possono fornire 500 m (equivalenti a 0,5 core CPU). Il suo consumo massimo di runtime può arrivare fino a 1000 m prima del throttling se il nodo ha capacità disponibile.

risorse: richieste: cpu: 500m limiti: cpu : 1000m

Perché i limiti della CPU sono pericolosi

Per capire perché i limiti della CPU sono problematici, considera cosa succede se un pod con le impostazioni delle risorse mostrate sopra (richiesta di 500 m, limite di 1000 m) viene distribuito a un nodo quad-core con una capacità di CPU totale di 4000 m. Per semplicità, non ci sono altri pod in esecuzione sul nodo.

$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE demo-pod 1/1 Running 0 1m 10.244.0.185 quad- nodo-core

Il Pod si programma subito sul Nodo perché la richiesta di 500m viene immediatamente soddisfatta. Il pod passa allo stato In esecuzione. Il carico potrebbe essere basso con un utilizzo della CPU di circa poche centinaia di millicore.

Poi si verifica un improvviso picco di traffico: le richieste si riversano in massa e l'utilizzo effettivo della CPU del pod sale fino a 2000 m. A causa del limite della CPU, questo viene ridotto a 1000 m. Tuttavia, il nodo non esegue altri pod, quindi potrebbe fornire tutti i 2000 m, se il pod non fosse limitato dal suo limite.

La capacità del nodo è stata sprecata e le prestazioni del pod sono state ridotte inutilmente. L'omissione del limite della CPU consentirebbe al pod di utilizzare tutti i 4000 m, soddisfacendo potenzialmente tutte le richieste fino a quattro volte più velocemente.

No Il limite impedisce comunque l'hogging delle risorse del pod

L'omissione dei limiti della CPU non compromette la stabilità, a condizione che tu abbia impostato le richieste appropriate su ciascun pod. Quando vengono implementati più pod, la quota di tempo della CPU di ciascun pod viene ridimensionata in proporzione alla sua richiesta.

Ecco un esempio di ciò che accade a due pod senza limiti quando 8217;re implementato su un nodo a 8 core (8000 m) e ciascuno contemporaneamente richiede il 100% di consumo della CPU:

Richiesta CPU pod % utilizzo CPU richiesto Utilizzo effettivo CPU (m) 1 500 m 100% 2000m 2 1500m 100% 6000m

Se il Pod 1 si trova in un periodo più tranquillo, il Pod 2 è libero di utilizzare ancora più cicli della CPU:

Richiesta CPU pod Utilizzo CPU richiesto % Utilizzo effettivo della CPU (m) 1 500 m 20% 400 m 2 1500 m 100% 7600 m

Le richieste della CPU sono ancora importanti

Questi esempi dimostrano perché le richieste della CPU sono importanti. L'impostazione di richieste appropriate previene la contesa garantendo che i pod vengano pianificati solo sui nodi che possono supportarli. Garantisce inoltre una distribuzione ponderata dei cicli CPU disponibili quando più pod registrano un aumento della domanda.

I limiti della CPU non offrono questi vantaggi. Sono utili solo in situazioni in cui desideri limitare un pod al di sopra di una determinata soglia di prestazioni. Questo è quasi sempre un comportamento indesiderabile; stai affermando che gli altri tuoi pod saranno sempre occupati, quando potrebbero essere inattivi e creare cicli di CPU di riserva nel cluster.

La mancata impostazione di limiti consente a tali cicli di essere utilizzati da qualsiasi carico di lavoro necessario loro. Ciò si traduce in migliori prestazioni complessive perché l'hardware disponibile non viene mai sprecato.

Che dire della memoria?

La memoria è gestita in Kubernetes utilizzando gli stessi concetti di richiesta e limite. Tuttavia la memoria è una risorsa fisicamente diversa dall'utilizzo della CPU che richiede un proprio metodo di allocazione. La memoria non è comprimibile: non può essere revocata una volta assegnata a un processo contenitore. I processi condividono la CPU non appena diventa disponibile, ma ricevono singole porzioni di memoria.

L'impostazione di una richiesta e di un limite identici è l'approccio best practice per la gestione della memoria Kubernetes. Ciò ti consente di prevedere in modo affidabile il consumo totale di memoria di tutti i pod nel tuo cluster.

Potrebbe sembrare logico impostare una richiesta relativamente bassa con un limite molto più alto. Tuttavia, l'utilizzo di questa tecnica per molti pod può avere un effetto destabilizzante: se diversi pod superano le loro richieste, la capacità di memoria del tuo cluster potrebbe essere esaurita. Il killer OOM interverrà per terminare i processi dei container, causando potenzialmente interruzioni ai carichi di lavoro. Qualsiasi tuo pod potrebbe essere preso di mira per lo sfratto, non solo quello che ha causato l'esaurimento della memoria.

L'utilizzo di richieste e limiti uguali impedisce la pianificazione di un pod a meno che il nodo non sia in grado di fornire la memoria di cui ha bisogno. Impone inoltre che il pod non possa utilizzare più memoria rispetto alla sua allocazione esplicita, eliminando il rischio di un utilizzo eccessivo quando più pod superano le loro richieste. L'eccessivo utilizzo risulterà evidente quando provi a pianificare un pod e nessun nodo è in grado di soddisfare la richiesta di memoria. L'errore si verifica prima e in modo più prevedibile, senza influire su altri pod.

Riepilogo

Kubernetes ti consente di distinguere tra la quantità di risorse richieste da un container e un limite superiore che è consentito scalare fino a ma non può superare. Tuttavia questo meccanismo è meno utile nella pratica di quanto possa sembrare a prima vista.

L'impostazione dei limiti della CPU impedisce ai processi di utilizzare la capacità di riserva della CPU non appena diventa disponibile. Ciò riduce inutilmente le prestazioni quando un pod potrebbe utilizzare temporaneamente cicli che nessun vicino richiede.

Utilizza una richiesta ragionevole della CPU per impedire ai pod di pianificare su nodi che sono già troppo occupati per fornire buone prestazioni. Non impostare il campo del limite in modo che i pod possano accedere a risorse aggiuntive durante l'esecuzione di attività impegnative nei momenti in cui la capacità è disponibile. Infine, assegna a ciascun pod una richiesta di memoria e un limite, assicurandoti di utilizzare lo stesso valore per entrambi i campi. Ciò impedirà l'esaurimento della memoria, creando un ambiente cluster più stabile e prevedibile.