{"id":77693,"date":"2020-04-13T01:42:39","date_gmt":"2020-04-12T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes"},"modified":"2020-04-13T01:42:39","modified_gmt":"2020-04-12T23:42:39","slug":"cpu-limity-i-agressivnyj-trottling-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","title":{"rendered":"Limiti CPU e throttling aggressivo in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota di traduzione.<\/b>: questa storia istruttiva di Omio \u2014 il aggregatore di viaggi europeo \u2014 guida i lettori dalla teoria di base alle affascinanti complessit\u00e0 pratiche nella configurazione di Kubernetes. Incontrare casi come questi aiuta non solo a espandere i propri orizzonti, ma anche a prevenire problemi non banali.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/1175c9df746e43b5a7d81476164929db.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTi \u00e8 mai capitato di affrontare un'applicazione che si \"bloccava\" e smetteva di rispondere alle richieste di controllo dello stato (health check) senza che tu potessi capire il motivo di tale comportamento? Una delle possibili spiegazioni riguarda il limite delle quote sulle risorse CPU. Di questo parleremo in questo articolo.<\/p>\n<p><b>TL;DR:<br \/>\nTi consigliamo vivamente di rinunciare ai limiti CPU in Kubernetes (o di disattivare le quote CFS in Kubelet) se stai utilizzando una versione del kernel Linux con un bug nelle quote CFS. Nel kernel <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">un meccanismo<\/a><\/noindex> c'\u00e8 un bug serio e <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">ben noto<\/a><\/noindex> che porta a uno throttling e a ritardi eccessivi<\/b>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>In Omio <b>tutta l'infrastruttura \u00e8 gestita da Kubernetes<\/b>. Tutici i nostri carichi stateful e stateless funzionano esclusivamente su Kubernetes (utilizziamo Google Kubernetes Engine). Negli ultimi sei mesi abbiamo iniziato a notare rallentamenti casuali. Le applicazioni si bloccano o smettono di rispondere agli health check, perdono la connessione alla rete, ecc. Questo comportamento ci ha messo a dura prova per un lungo periodo, e alla fine abbiamo deciso di affrontare il problema seriamente.<\/p>\n<p>Riepilogo dell'articolo:<\/p>\n<ul>\n<li> Qualche parola sui container e Kubernetes;<\/li>\n<li> Come sono implementati i request e i limit delle CPU;<\/li>\n<li> Come funziona il limite CPU in ambienti con pi\u00f9 core;<\/li>\n<li> Come monitorare il throttling della CPU;<\/li>\n<li> Soluzione del problema e dettagli.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Qualche parola sui container e Kubernetes<\/h2>\n<p>\nKubernetes, in sostanza, \u00e8 il standard moderno nel mondo dell'infrastruttura. Il suo compito principale \u00e8 l'orchestrazione dei container.<\/p>\n<h3>Contenitori<\/h3>\n<p>\nIn passato era necessario creare artefatti come JAR\/WAR di Java, pacchetti Python o file eseguibili da eseguire successivamente sui server. Tuttavia, per farli funzionare, era necessario svolgere un lavoro aggiuntivo: installare l'ambiente di esecuzione (Java\/Python), posizionare i file necessari nei luoghi appropriati, garantire la compatibilit\u00e0 con una versione specifica del sistema operativo, ecc. In altre parole, era necessario prestare molta attenzione alla gestione delle configurazioni (che spesso era causa di conflitti tra sviluppatori e amministratori di sistema).<\/p>\n<p><b>I container hanno cambiato tutto.<\/b> Ora l'artefatto \u00e8 un'immagine del contenitore. Pu\u00f2 essere visualizzato come un file eseguibile esteso, che contiene non solo il programma, ma anche un ambiente di esecuzione completo (Java\/Python\/\u2026), oltre ai file\/pacchetti necessari, preinstallati e pronti per l'uso. I contenitori possono essere distribuiti e avviati su diversi server senza ulteriori azioni.<\/p>\n<p>Inoltre, i contenitori operano in un proprio ambiente sandbox. Hanno il loro adattatore di rete virtuale, un proprio file system con accesso limitato, una propria gerarchia di processi, i propri limiti su CPU e memoria, ecc. Tutto ci\u00f2 \u00e8 reso possibile da un particolare sottosistema del kernel Linux \u2014 i namespaces.<\/p>\n<h3>Kubernetes<\/h3>\n<p>\nCome gi\u00e0 accennato, Kubernetes \u00e8 un orchestratore di contenitori. Funziona nel seguente modo: fornisci un pool di macchine e poi dici: \"Ehi, Kubernetes, avvia dieci istanze del mio contenitore con 2 processori e 3 GB di memoria ciascuno, e mantienili in esecuzione!\". Kubernetes si occuper\u00e0 del resto. Trover\u00e0 le risorse disponibili, avvier\u00e0 i contenitori e li riavvier\u00e0 se necessario, implementer\u00e0 aggiornamenti al cambio di versione, ecc. In sostanza, Kubernetes consente di astrarsi dall'hardware e rende tutte le diverse configurazioni di sistema adatte per il deployment e l'esecuzione delle applicazioni.<\/p>\n<p><img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/6509bb1b66a4a0f5e9a479d0bd6ececb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes dal punto di vista di un semplice cittadino<\/i><\/p>\n<h2>Cosa sono i request e i limit in Kubernetes<\/h2>\n<p>\nOk, abbiamo chiarito le cose sui contenitori e su Kubernetes. Sappiamo anche che pi\u00f9 contenitori possono essere ospitati su una sola macchina.<\/p>\n<p>Si pu\u00f2 fare un'analogia con un appartamento condiviso. Si prende uno spazio ampio (macchine\/nodi) e si affitta a vari inquilini (contenitori). Kubernetes funge da agente immobiliare. Si pone la questione: come mantenere gli inquilini senza conflitti tra di loro? E se uno di loro decidesse di occupare il bagno per mezza giornata?<\/p>\n<p>\u00c8 qui che entrano in gioco i request e i limit CPU. <b>Request<\/b> \u00e8 necessario esclusivamente per la pianificazione. \u00c8 una sorta di \"lista dei desideri\" del contenitore e viene utilizzata per trovare il nodo pi\u00f9 adatto. Allo stesso tempo, CPU <b>Limit<\/b> pu\u00f2 essere paragonato a un contratto di affitto: una volta trovato il nodo per il contenitore, esso <b>non potr\u00e0<\/b> superare i limiti stabiliti. Ed ecco che sorge un problema\u2026<\/p>\n<h3>Come sono implementati i request e i limit in Kubernetes<\/h3>\n<p>\nKubernetes utilizza un meccanismo di throttling integrato nel kernel per implementare i limiti CPU. Se l'applicazione supera il limite, viene attivato il throttling (cio\u00e8 riceve meno cicli CPU). I request e i limit per la memoria sono organizzati in modo diverso, quindi \u00e8 pi\u00f9 facile individuarli. \u00c8 sufficiente controllare lo stato dell'ultimo riavvio del pod: se non \u00e8 \"OOMKilled\". Con il throttling CPU le cose non sono cos\u00ec semplici, poich\u00e9 K8s rende disponibili solo metriche di utilizzo, non di cgroups.<\/p>\n<h4>CPU Request<\/h4>\n<p>\n<img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/fbc8bf3f775ffd9513374ce94b20535d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Come \u00e8 implementato il CPU request<\/i><\/p>\n<p>Per semplicit\u00e0, consideriamo il processo utilizzando un esempio di una macchina con CPU quad-core.<\/p>\n<p>K8s utilizza meccanismi di controllo delle risorse (cgroups) per gestire la distribuzione delle risorse (memoria e CPU). \u00c8 disponibile un modello gerarchico: un discendente eredita i limiti del gruppo genitore. I dettagli della distribuzione sono memorizzati in un file system virtuale (<code>\/sys\/fs\/cgroup<\/code>). Nel caso della CPU, questo <code>\/sys\/fs\/cgroup\/cpu,cpuacct\/*<\/code>.<\/p>\n<p>K8s utilizza il file <code>cpu.share<\/code> per il ripartimento delle risorse della CPU. Nel nostro caso, il gruppo di controllo radice riceve 4096 quote di risorse CPU \u2014 100% della potenza di CPU disponibile (1 core = 1024; questo \u00e8 un valore fisso). Il gruppo radice distribuisce le risorse in modo proporzionale in base alle quote dei figli, specificate in <code>cpu.share<\/code>, e questi, a loro volta, agiscono in modo analogo con i loro figli, e cos\u00ec via. In un nodo Kubernetes tipico, il gruppo di controllo radice ha tre figli: <code>system.slice<\/code>, <code>user.slice<\/code> e <code>kubepods<\/code>. Le prime due sottogruppi vengono utilizzati per distribuire le risorse tra i carichi di lavoro di sistema critici e i programmi user fuori K8s. L'ultimo \u2014 <code>kubepods<\/code> \u2014 creato da Kubernetes per la distribuzione delle risorse tra i pod.<\/p>\n<p>Nello schema sopra, si pu\u00f2 notare che il primo e il secondo sottogruppo hanno ricevuto entrambi <b>1024<\/b> quote, mentre al sottogruppo kubepod sono state assegnate <b>4096<\/b> quote. Come \u00e8 possibile: dato che al gruppo radice sono disponibili solo <b>4096<\/b> quote, mentre la somma delle quote dei suoi figli supera di gran lunga questo numero (<b>6144<\/b>)? Il fatto \u00e8 che il valore ha senso logico, per cui il pianificatore Linux (CFS) lo utilizza per la distribuzione proporzionale delle risorse CPU. Nel nostro caso, i primi due gruppi ricevono entrambi <b>680<\/b> quote reali (16,6% di 4096), mentre kubepod riceve quelle rimanenti <b>2736<\/b> quote. In caso di inattivit\u00e0, i primi due gruppi non utilizzeranno le risorse dedicate.<\/p>\n<p>Fortunatamente, nel pianificatore \u00e8 presente un meccanismo che consente di evitare la perdita delle risorse CPU non utilizzate. Esso trasferisce le capacit\u00e0 \"inattive\" in un pool globale, da cui vengono distribuite ai gruppi che necessitano di capacit\u00e0 aggiuntive di elaborazione (il trasferimento avviene per lotti per evitare perdite dovute all'arrotondamento). Un metodo simile viene applicato a tutti i discendenti di questi discendenti.<\/p>\n<p>Questo meccanismo garantisce una distribuzione equa delle capacit\u00e0 della CPU e si assicura che nessun processo \"rubando\" risorse ad altri.<\/p>\n<h4>Limite CPU<\/h4>\n<p>\nSebbene le configurazioni dei limiti e delle richieste in K8s possano sembrare simili, la loro implementazione \u00e8 radicalmente diversa: si tratta di <b>la parte pi\u00f9 fuorviante<\/b> e meno documentata.<\/p>\n<p>K8s utilizza <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">il meccanismo delle quote CFS<\/a><\/noindex> per implementare i limiti. Le loro impostazioni sono definite nei file <code>cfs_period_us<\/code> e <code>cfs_quota_us<\/code> nella directory cgroup (l\u00ec si trova anche il file <code>cpu.share<\/code>).<\/p>\n<p>A differenza di <code>cpu.share<\/code>, la quota si basa su <b>un periodo di tempo<\/b>, piuttosto che sulla potenza di CPU disponibile. <code>cfs_period_us<\/code> definisce la durata del periodo (era) \u2014 questo \u00e8 sempre 100000 microsecondi (100 ms). In K8s \u00e8 possibile modificare questo valore, ma attualmente \u00e8 accessibile solo nella versione alfa. Il pianificatore utilizza l'era per riavviare le quote utilizzate. Il secondo file, <code>cfs_quota_us<\/code>, definisce il tempo disponibile (quota) in ogni era. Si noti che \u00e8 anche indicato in microsecondi. La quota pu\u00f2 superare la durata dell'era; in altre parole, pu\u00f2 essere superiore a 100 ms.<\/p>\n<p>Consideriamo due scenari su macchine a 16 core (il tipo di computer pi\u00f9 comune da noi in Omio):<\/p>\n<p><img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/61c6105320af3a92a91cec1007da0d45.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenario 1: 2 flussi e limite di 200 ms. Senza throttling<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/c33993341d5395bb73dda1f4c8482a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenario 2: 10 flussi e limite di 200 ms. Il throttling inizia dopo 20 ms, l'accesso alle risorse della CPU riprende dopo ulteriori 80 ms<\/i><\/p>\n<p>Supponiamo di aver impostato un limite CPU su <b>2<\/b> core; Kubernetes convertir\u00e0 questo valore in 200 ms. Ci\u00f2 significa che il contenitore pu\u00f2 utilizzare al massimo 200 ms di tempo di CPU senza throttling.<\/p>\n<p>E qui inizia la parte pi\u00f9 interessante. Come detto sopra, la quota disponibile \u00e8 di 200 ms. Se stai eseguendo in parallelo <b>dieci<\/b> flussi su una macchina a 12 core (vedi l'illustrazione allo scenario 2); mentre tutti gli altri pod sono inattivi, la quota verr\u00e0 esaurita in soli 20 ms (dato che 10 * 20 ms = 200 ms), e tutti i flussi di questo pod 'si bloccano' <i>(throttle)<\/i> per i successivi 80 ms. La situazione \u00e8 ulteriormente aggravata dal gi\u00e0 menzionato <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">bug del pianificatore<\/a><\/noindex>, che provoca eccessivo throttling e il contenitore non pu\u00f2 produrre nemmeno la quota disponibile.<\/p>\n<h2>Come valutare il throttling nei pod?<\/h2>\n<p>\nBasta entrare nel pod e eseguire <code>cat \/sys\/fs\/cgroup\/cpu\/cpu.stat<\/code>.<\/p>\n<ul>\n<li> <code>nr_periods<\/code> \u2014 numero totale dei periodi di pianificazione;<\/li>\n<li> <code>nr_throttled<\/code> \u2014 numero di periodi throttled inclusi in <code>nr_periods<\/code>;<\/li>\n<li> <code>throttled_time<\/code> \u2014 tempo totale throttled in nanosecondi.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/a1818614914a8c31f7f7f1331cc02e8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cosa sta realmente accadendo?<\/h3>\n<p>\nDi conseguenza, otteniamo un alto throttling in tutte le applicazioni. A volte \u00e8 <b>una volta e mezza<\/b> pi\u00f9 forte di quanto calcolato!<\/p>\n<p>Questo porta a vari errori: fallimenti dei controlli di prontezza (readiness), blocchi dei contenitori, disconnessioni di rete, timeout all'interno delle chiamate ai servizi. In ultima analisi, si traduce in un aumento della latenza e del numero di errori.<\/p>\n<h2>Soluzione e conseguenze<\/h2>\n<p>\nQui \u00e8 semplice. Abbiamo abbandonato i limiti della CPU e ci siamo occupati di aggiornare il kernel del sistema operativo nei cluster all'ultima versione, in cui il bug \u00e8 stato corretto. Il numero di errori (HTTP 5xx) nei nostri servizi \u00e8 diminuito drasticamente:<\/p>\n<h3>Errori HTTP 5xx<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/86ab1694b952b5451a4ae075cbda2788.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Errori HTTP 5xx di un servizio critico<\/i><\/p>\n<h3>Tempo di risposta p95<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/63922c8eb468366a7d05154a3adf40e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ritardo delle richieste di un servizio critico, 95\u00b0 percentile<\/i><\/p>\n<h3>Costi di gestione<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limiti CPU e throttling aggressivo in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/8405c26fcbd82853e296fa7e3bcba131.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Numero di ore macchina spese<\/i><\/p>\n<h2>Qual \u00e8 il problema?<\/h2>\n<p>\nCome detto all'inizio dell'articolo:<\/p>\n<blockquote><p>Si pu\u00f2 fare un'analogia con un appartamento condiviso\u2026 Kubernetes funge da agente immobiliare. Ma come mantenere gli inquilini senza conflitti tra loro? Cosa succede se uno di loro, per esempio, decide di occupare il bagno per mezzo giorno?<\/p><\/blockquote>\n<p>\nEcco qual \u00e8 il problema. Un contenitore negligente pu\u00f2 assorbire tutte le risorse CPU disponibili sulla macchina. Se hai uno stack applicativo competente (ad esempio, JVM, Go, Node VM correttamente configurati), allora non \u00e8 un problema: \u00e8 possibile lavorare in tali condizioni per lungo tempo. Ma se le applicazioni sono ottimizzate male o non ottimizzate affatto (<code>FROM java:latest<\/code>), la situazione potrebbe sfuggire al controllo. In Omio abbiamo Dockerfile di base automatizzati con impostazioni predefinite adeguate per lo stack dei linguaggi principali, quindi non c'\u00e8 mai stata una tale problema.<\/p>\n<p>Ti consigliamo di monitorare le metriche <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">USARE<\/a><\/noindex> (utilizzo, saturazione e errori), ritardi delle API e frequenza degli errori. Assicurati che i risultati siano in linea con le aspettative.<\/p>\n<h2>Link<\/h2>\n<p>\nQuesta \u00e8 la nostra storia. I seguenti materiali hanno molto aiutato a chiarire ci\u00f2 che sta accadendo:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">kernel.org \u2192 CFS Scheduler<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-bwc.txt\">kernel.org \u2192 CFS Bandwidth Control<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.squarespace.com\/blog\/2017\/understanding-linux-container-scheduling\">Understanding Linux Container Scheduling<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linuxjournal.com\/content\/everything-you-need-know-about-linux-containers-part-i-linux-control-groups-and-process\">Tutto ci\u00f2 che devi sapere sui contenitori Linux, Parte I: Gruppi di controllo Linux e isolamento dei processi<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/k8s.af\/\">Kubernetes Failure Stories<\/a><\/noindex> \u2014 cerca \u00abcpu throttling\u00bb.<\/li>\n<\/ul>\n<p>\nReport di errore di Kubernetes:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/51135#issuecomment-373454012\">#51135: Avoid setting CPU limits for Guaranteed pods<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">#67577: CFS quotas can lead to unnecessary throttling<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gist.github.com\/bobrik\/2030ff040fad360327a5fab7a09c4ff1\">CFS eccessivamente aggressivo<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nHai mai affrontato problemi simili nella tua pratica o hai esperienza relativa al throttling in ambienti di produzione containerizzati? Condividi la tua storia nei commenti!<\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggi anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Auto-scaling e gestione delle risorse in Kubernetes (panoramica e video della presentazione)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/418269\/\">Come funziona il CPU Manager in Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/342822\/\">Cosa succede in Kubernetes quando esegui kubectl run? Parte 2<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes. \u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 \u0442\u0430\u043a\u0438\u043c\u0438 \u0441\u043b\u0443\u0447\u0430\u044f\u043c\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u044f\u0442\u044c \u043a\u0440\u0443\u0433\u043e\u0437\u043e\u0440, \u043d\u043e \u0438 \u043f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0430\u0442\u044c \u043d\u0435\u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b. \u0414\u043e\u0432\u043e\u0434\u0438\u043b\u043e\u0441\u044c \u043b\u0438 \u0432\u0430\u043c \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u00ab\u0437\u0430\u0441\u0442\u0440\u0435\u0432\u0430\u043b\u043e\u00bb \u043d\u0430 \u043c\u0435\u0441\u0442\u0435, \u043f\u0435\u0440\u0435\u0441\u0442\u0430\u0432\u0430\u043b\u043e \u043e\u0442\u0432\u0435\u0447\u0430\u0442\u044c \u043d\u0430 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u043e \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0435 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77694,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77693","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Limiti della CPU e throttling aggressivo in Kubernetes | ProHoster","description":"Nota del traduttore: questa storia istruttiva di Omio \u2014 un aggregatore di viaggi europeo \u2014 guida i lettori dalla teoria di base a dettagli pratici affascinanti nella configurazione di Kubernetes.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-12T23:42:39+00:00","article:modified_time":"2020-04-12T23:42:39+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77693","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:13:23","updated":"2022-09-29 12:06:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77693","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=77693"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77693\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/77694"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=77693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=77693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=77693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}