Limitazione della CPU di Kubernetes: il killer silenzioso del tempo di risposta

Oggi, la maggior parte delle organizzazioni aziendali che eseguono applicazioni mission-critical su Kubernetes lo fa in ambienti multitenant. Questi ambienti multitenant si basano sull'impostazione di limiti per regolare il consumo dei workload degli inquilini o per utilizzare i limiti per i chargeback. Alcuni sviluppatori sceglieranno di impostare limiti di CPU o GPU per i test di benchmark delle loro applicazioni.

La limitazione della CPU, in base alla quale la velocità di pianificazione delle attività sui core fisici viene inavvertitamente ridotta, spesso con conseguente aumento indesiderato dei tempi di risposta delle applicazioni, è la conseguenza involontaria di questo design. Dai un'occhiata a questo esempio:

Nella figura precedente, l'utilizzo della CPU di un container è solo del 25%, il che lo rende un candidato naturale per il ridimensionamento:

Ma dopo aver ridimensionato il container (l'utilizzo della CPU è ora del 50%, ancora non elevato), il tempo di risposta è quadruplicato.

Quindi, cosa sta succedendo qui? La limitazione della CPU si verifica quando configura un limite di CPU su un container, il che può rallentare il tempo di risposta della tua applicazione e causare un problema di limitazione. Anche se disponi di risorse più che sufficienti sul nodo sottostante, il workload del container sarà comunque limitato perché non è stato configurato correttamente. Inoltre, l'impatto della limitazione sulle prestazioni può variare a seconda del processore fisico sottostante (Intel vs. AMD vs. NVIDIA). Gli elevati tempi di risposta sono direttamente correlati ai periodi di elevata limitazione della CPU, ed è esattamente così che Kubernetes è stato progettato per funzionare.

Per dare un po' di colore alla situazione, immagina di impostare un limite della CPU di 200 ms e che tale limite venga tradotto in una quota di gruppo nel sistema Linux sottostante. Il container è in grado di utilizzare solo 20 ms di CPU alla volta (l'intervallo di tempo della CPU) perché il periodo di imposizione predefinito è di soli 100 ms. Se la tua attività è più lunga di 20 ms, a causa del throttling ci vorrà 4 volte più tempo per completare l'attività.

In base a questo comportamento, le prestazioni dell'applicazione ne risentiranno a causa dell'aumento dei tempi di risposta causato dalla limitazione e inizierai la risoluzione dei problemi per cercare di individuare il problema.

Se si esegue una distribuzione di piccole dimensioni, potrebbe essere possibile risolvere manualmente i problemi di limitazione.

Per prima cosa, dovresti identificare il pod interessato utilizzando strumenti come kubectl. Successivamente, rivedi le richieste e i limiti delle risorse del pod per assicurarti che siano impostati correttamente. Verifica eventuali processi ad alto consumo di risorse in esecuzione all'interno del contenitore che potrebbero causare la limitazione e analizza l'utilizzo e i limiti della CPU.

Se la limitazione della CPU persiste, prendi in considerazione la scalabilità automatica orizzontale dei pod per distribuire il workload su più pod o regolare le risorse dei nodi del cluster per soddisfare le richieste. Monitorare costantemente e mettere a punto le impostazioni delle risorse per ottimizzare le prestazioni e prevenire ulteriori problemi di limitazione.

In una distribuzione più ampia, è improbabile che questo approccio sia scalabile o persistente man mano che si aggiungono altri pod.

La limitazione della CPU è una metrica chiave per le prestazioni delle applicazioni a causa della correlazione diretta tra tempo di risposta e limitazione della CPU. Questa è un'ottima notizia per te, poiché puoi ottenere questa metrica direttamente da Kubernetes e OpenShift.

Per garantire che i tempi di risposta dell'applicazione rimangano bassi, che la CPU non venga limitata e che l'applicazione continui a funzionare ad alte prestazioni, è necessario innanzitutto comprendere che, quando si verifica una limitazione della CPU, non puoi fare affidamento esclusivamente sull'utilizzo dei core della CPU. Devi tenere conto di tutte le analytics e delle risorse che influiscono sulle prestazioni dell'applicazione. IBM® turbonomic ha integrato queste considerazioni nella sua piattaforma di analytics.

Quando si determinano le azioni di ottimizzazione dei container, Turbonomic analizza costantemente quattro dimensioni:

1. Limiti CPU
2. Richieste CPU
3. Limiti della memoria
4. Richieste di memoria

Turbonomic può determinare i limiti della CPU che mitigheranno il rischio di limitazione e consentiranno alle tue applicazioni di funzionare senza problemi. Tutto questo grazie alla potenza dell'aggiunta del throttling della CPU come dimensione per la piattaforma per analizzare e gestire i compromessi che appaiono. Aggiungendo la dimensione della limitazione della CPU si garantiranno tempi di risposta ridotti per le applicazioni.

Oltre a ciò, Turbonomic sta generando azioni per spostare i tuoi pod e scalare i tuoi cluster: come tutti sappiamo, si tratta di una sfida full-stack. I clienti hanno la possibilità di visualizzare i KPI e chiedere: "Quale dei miei servizi è soggetto a limitazioni?" Inoltre, consente loro di comprendere la cronologia della limitazione della CPU per ogni servizio e ricordare che ogni servizio è direttamente correlato al tempo di risposta delle applicazioni, fornendo agli utenti preziose finestre sulle prestazioni del loro sistema.

Nel contesto di Kubernetes, uno dei principali vantaggi di Turbonomic è la sua capacità di identificare e porre rimedio rapidamente alle conseguenze indesiderate di una strategia di piattaforma anziché far ridisegnare al cliente la propria strategia di piattaforma multitenant. Turbonomic non è solo in grado di monitorare le metriche di throttling della CPU, ma la piattaforma può anche ridimensionare automaticamente il limite della CPU e ridurre il throttling a un livello gestibile.

IBM Turbonomic può aiutare a ottimizzare contemporaneamente la spesa e le prestazioni del cloud. Puoi automatizzare continuamente le azioni di ottimizzazione in tempo reale, senza intervento umano, che offrono in modo proattivo l'uso più efficiente delle risorse di calcolo, memoria, storage e rete alle app a ogni livello dello stack.