{"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 del traduttore.<\/b>: questa storia istruttiva di Omio \u2014 l\u2019aggregatore europeo di viaggi \u2014 guida i lettori dalla teoria di base alle affascinanti complessit\u00e0 pratiche nella configurazione di Kubernetes. Affrontare casi come questi non solo amplia le proprie prospettive ma aiuta 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 trovarti di fronte a un'applicazione che 'si bloccava', smettendo di rispondere alle richieste di controllo dello stato (health check) e non riuscivi a capire il motivo di tale comportamento? Una delle possibili spiegazioni \u00e8 legata al limite delle quote delle 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 disattivare le quote CFS in Kubelet), se stai utilizzando una versione del kernel Linux con bug nelle quote CFS. Nel kernel <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">c'\u00e8<\/a><\/noindex> Nel kernel <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">\u00e8 presente un bug serio e<\/a><\/noindex> ben noto<\/b>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>che porta a un throttling e a ritardi eccessivi. <b>In Omio<\/b>. Tutichi i nostri carichi stateful e stateless funzionano esclusivamente su Kubernetes (utilizziamo Google Kubernetes Engine). Negli ultimi sei mesi abbiamo iniziato a osservare rallentamenti casuali. Le applicazioni si bloccano o smettono di rispondere agli health check, perdono la connessione alla rete, ecc. Questo comportamento ci ha messo in difficolt\u00e0 per un lungo periodo e, infine, abbiamo deciso di affrontare il problema seriamente.<\/p>\n<p>Tutti i nostri carichi di lavoro 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 connessione alla rete e cos\u00ec via. Questo comportamento ci ha messo in difficolt\u00e0 per un po', e alla fine abbiamo deciso di affrontare il problema in modo diretto.<\/p>\n<ul>\n<li> Sommario dell\u2019articolo:<\/li>\n<li> Come sono implementati le richieste e i limiti CPU;<\/li>\n<li> Come sono implementati i CPU request e limit;<\/li>\n<li> Come funziona il CPU limit in ambienti con pi\u00f9 core;<\/li>\n<li> Come monitorare il throttling della CPU;<\/li>\n<\/ul>\n<p><\/p>\n<h2>Soluzioni al problema e le peculiarit\u00e0.<\/h2>\n<p>\nAlcune parole sui container e Kubernetes<\/p>\n<h3>Container<\/h3>\n<p>\nIn passato ci siamo trovati a creare artefatti come JAR\/WAR Java, Egg Python o file eseguibili da lanciare sui server. Tuttavia, per farli funzionare, era necessario fare del lavoro aggiuntivo: installare l'ambiente di runtime (Java\/Python), posizionare i file necessari nei luoghi giusti, garantire la compatibilit\u00e0 con una versione specifica del sistema operativo, ecc. In altre parole, era necessario prestare particolare attenzione alla gestione delle configurazioni (che spesso causava conflitti tra sviluppatori e amministratori di sistema).<\/p>\n<p><b>In passato dovevamo creare artefatti come JAR\/WAR di Java, Egg di Python o eseguibili da avviare successivamente sui server. Tuttavia, per farli funzionare, era necessario svolgere ulteriori attivit\u00e0: installare un ambiente di runtime (Java\/Python), posizionare i file richiesti nei luoghi giusti, garantire la compatibilit\u00e0 con una specifica versione del sistema operativo, ecc. In altre parole, dovevamo prestare particolare attenzione alla gestione delle configurazioni (che spesso era motivo di conflitto tra sviluppatori e amministratori di sistema).<\/b> I container hanno cambiato tutto.<\/p>\n<p>Ora l'artefatto \u00e8 un'immagine del container. Pu\u00f2 essere considerata come un file eseguibile esteso, contenente non solo il programma, ma anche un ambiente di runtime completo (Java\/Python\/\u2026) e i file\/pacchetti necessari, preinstallati e pronti per essere eseguiti. I container possono essere distribuiti e avviati su server diversi senza ulteriori azioni.<\/p>\n<h3>Kubernetes<\/h3>\n<p>\nInoltre, i container operano nel proprio ambiente sandbox. Hanno il proprio adattatore di rete virtuale, il proprio file system con accesso limitato, la propria gerarchia di processi, i propri limiti su CPU e memoria, e cos\u00ec via. Tutto ci\u00f2 \u00e8 realizzato grazie a una particolare sottosistema del kernel Linux \u2014 namespaces.<\/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>Come gi\u00e0 detto, Kubernetes \u00e8 un orchestratore di container. Funziona in questo modo: fornisci un pool di macchine e poi dici: \u2018Ehi, Kubernetes, avvia dieci istanze del mio container con 2 processori e 3 GB di memoria ciascuna, e mantienile in funzione!\u2019. Kubernetes si occuper\u00e0 di tutto il resto. Trover\u00e0 le risorse disponibili, avvier\u00e0 i container e li riavvier\u00e0 se necessario, eseguir\u00e0 l'aggiornamento in caso di cambio di versioni, e cos\u00ec via. In sostanza, Kubernetes consente di astrarsi dall'hardware e rende la variet\u00e0 dei sistemi idonea all'implementazione e al funzionamento delle applicazioni.<\/i><\/p>\n<h2>Cosa sono le richieste e i limiti in Kubernetes<\/h2>\n<p>\nChe cosa sono request e limit in Kubernetes<\/p>\n<p>Ok, abbiamo compreso i container e Kubernetes. Sappiamo anche che pi\u00f9 container possono risiedere su una singola macchina.<\/p>\n<p>\u00c8 qui che entrano in gioco le richieste e i limiti CPU. <b>Richiesta<\/b> \u00c8 qui che entrano in gioco request e limit. <b>Limite<\/b> \u00e8 necessaria esclusivamente per la pianificazione. \u00c8 una sorta di \u2018lista dei desideri\u2019 del container, utilizzata per selezionare il nodo pi\u00f9 adatto. Allo stesso tempo, la CPU <b>non sar\u00e0 in grado di<\/b> pu\u00f2 essere paragonata a un contratto d'affitto: una volta scelto un nodo per il container, questo<\/p>\n<h3>Come sono implementati le richieste e i limiti in Kubernetes<\/h3>\n<p>\nKubernetes utilizza un meccanismo di throttling integrato nel kernel per implementare i limiti CPU. Se un'applicazione supera il limite, viene attivato il throttling (cio\u00e8 riceve meno cicli CPU). Le richieste e i limiti per la memoria sono organizzati in modo diverso, quindi \u00e8 pi\u00f9 facile rilevarli. \u00c8 sufficiente controllare l'ultimo stato di riavvio del pod: non \u00e8 stato 'OOMKilled'. Con il throttling CPU non \u00e8 cos\u00ec semplice, poich\u00e9 K8s rende disponibili solo le metriche di utilizzo, non quelle dei cgroups.<\/p>\n<h4>Richiesta CPU<\/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 implementata una richiesta CPU<\/i><\/p>\n<p>Per semplicit\u00e0, consideriamo il processo su una macchina con CPU a 4 core.<\/p>\n<p>K8s utilizza meccanismi di controllo dei gruppi (cgroups) per gestire l'allocazione delle risorse (memoria e CPU). Per questo \u00e8 disponibile un modello gerarchico: un discendente eredita i limiti del gruppo genitore. I dettagli dell'allocazione sono memorizzati in un file system virtuale (<code>\/sys\/fs\/cgroup<\/code>). Nel caso della CPU questo \u00e8 <code>\/sys\/fs\/cgroup\/cpu,cpuacct\/*<\/code>.<\/p>\n<p>K8s utilizza il file <code>cpu.share<\/code> per la distribuzione delle risorse della CPU. Nel nostro caso, il gruppo di controllo principale riceve 4096 quote di risorse della CPU \u2014 il 100% della potenza disponibile della CPU (1 core = 1024; questo \u00e8 un valore fisso). Il gruppo principale distribuisce le risorse in modo proporzionale in base alle quote dei discendenti definite in <code>cpu.share<\/code>, e questi, a loro volta, agiscono in modo simile con i loro discendenti, e cos\u00ec via. In un tipico nodo Kubernetes, il gruppo di controllo principale ha tre discendenti: <code>system.slice<\/code>, <code>user.slice<\/code> e <code>kubepods<\/code>. Le prime due sottogruppi vengono utilizzati per distribuire risorse tra carichi di sistema critici e applicazioni utente al di fuori di K8s. L'ultimo \u2014 <code>kubepods<\/code> \u2014 creato da Kubernetes per distribuire risorse tra i pod.<\/p>\n<p>Nello schema sopra, si vede che le prime due sottogruppi hanno ricevuto ciascuno <b>1024<\/b> quote, con a kubepod assegnato <b>4096<\/b> quote. Com'\u00e8 possibile: poich\u00e9 il gruppo principale ha a disposizione solo <b>4096<\/b> quote, e la somma delle quote dei suoi discendenti supera di gran lunga questo numero (<b>6144<\/b>)? Il valore ha un significato logico, pertanto il pianificatore Linux (CFS) lo utilizza per la distribuzione proporzionale delle risorse della CPU. Nel nostro caso, i primi due gruppi ricevono ciascuno <b>680<\/b> quote reali (16,6% di 4096), e kubepod riceve le restanti <b>2736<\/b> quote. In caso di inattivit\u00e0, i primi due gruppi non utilizzeranno le risorse assegnate.<\/p>\n<p>Fortunatamente, il pianificatore ha un meccanismo che consente di evitare la perdita di risorse CPU inutilizzate. Trasferisce le potenze 'inattive' in un pool globale, da cui vengono distribuite ai gruppi che necessitano di potenza aggiuntiva della CPU (il trasferimento avviene a blocchi per evitare perdite dovute all'arrotondamento). Un metodo simile viene applicato anche a tutti i discendenti dei discendenti.<\/p>\n<p>Questo meccanismo garantisce una distribuzione equa delle potenze della CPU e si assicura che nessun processo 'ruba' risorse da altri.<\/p>\n<h4>Limite CPU<\/h4>\n<p>\nNonostante le configurazioni dei limiti e delle richieste in K8s sembrino simili, la loro implementazione \u00e8 radicalmente diversa: questo <b>la parte pi\u00f9 fuorviante<\/b> e meno documentata.<\/p>\n<p>K8s impiega <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 definiti 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 sul <b>periodo di tempo<\/b>, e non sulla potenza disponibile della CPU. <code>cfs_period_us<\/code> definisce la durata del periodo (epoca) \u2014 \u00e8 sempre 100000 microsecondi (100 ms). In K8s \u00e8 possibile modificare questo valore, ma al momento \u00e8 disponibile solo in versione alpha. Il pianificatore utilizza l'epoca per riavviare le quote utilizzate. Il secondo file, <code>cfs_quota_us<\/code>, definisce il tempo disponibile (quota) in ogni epoca. Si noti che \u00e8 anch'essa espressa in microsecondi. La quota pu\u00f2 superare la durata dell'epoca; in altre parole, pu\u00f2 essere superiore a 100 ms.<\/p>\n<p>Consideriamo due scenari su macchine a 16 core (il tipo pi\u00f9 comune di computer 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 thread 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 thread 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 che tu abbia impostato un limite CPU su <b>2<\/b> core; Kubernetes tradurr\u00e0 questo valore in 200 ms. Questo significa che il contenitore pu\u00f2 utilizzare al massimo 200 ms di tempo di CPU senza throttling.<\/p>\n<p>Ed \u00e8 qui che inizia la parte interessante. Come detto sopra, la quota disponibile \u00e8 di 200 ms. Se hai in esecuzione contemporaneamente <b>dieci<\/b> flussi su una macchina a 12 core (vedi l'illustrazione per lo scenario 2), mentre tutti gli altri pod rimangono inattivi, la quota verr\u00e0 esaurita in soli 20 ms (poich\u00e9 10 * 20 ms = 200 ms), e tutti i flussi di questo pod \"si bloccheranno\". <i>(throttle)<\/i> per i successivi 80 ms. La situazione \u00e8 gi\u00e0 complicata dal <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">bug dello scheduler<\/a><\/noindex>, che causa un throttling eccessivo e il contenitore non riesce nemmeno a produrre la quota prevista.<\/p>\n<h2>Come valutare il throttling nei pod?<\/h2>\n<p>\nBasta accedere al pod ed eseguire <code>cat \/sys\/fs\/cgroup\/cpu\/cpu.stat<\/code>.<\/p>\n<ul>\n<li> <code>nr_periods<\/code> \u2014 il numero totale di periodi dello scheduler;<\/li>\n<li> <code>nr_throttled<\/code> \u2014 il numero di periodi throttled; <code>nr_periods<\/code>;<\/li>\n<li> <code>throttled_time<\/code> \u2014 il tempo totale di throttling 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 succedendo realmente?<\/h3>\n<p>\nDi conseguenza, otteniamo un alto livello di throttling in tutte le applicazioni. A volte \u00e8 <b>una volta e mezzo<\/b> pi\u00f9 forte di quanto previsto!<\/p>\n<p>Questo porta a vari errori: fallimenti nei controlli di prontezza, blocchi nei contenitori, interruzioni nelle connessioni di rete, timeout all'interno delle chiamate ai servizi. Alla fine, si traduce in un aumento della latenza e in un incremento degli errori.<\/p>\n<h2>Soluzione e conseguenze<\/h2>\n<p>\nQui \u00e8 tutto semplice. Abbiamo abbandonato i limiti della CPU e ci siamo dedicati all'aggiornamento del 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 immediatamente diminuito notevolmente:<\/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>Latenza delle richieste di un servizio critico, 95\u00b0 percentile<\/i><\/p>\n<h3>Costi operativi<\/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 paragone con un appartamento in comune... Kubernetes agisce come un agente immobiliare. Ma come mantenere i coinquilini in buona armonia? Cosa succede se uno di loro decidesse di occupare il bagno per mezza giornata?<\/p><\/blockquote>\n<p>\nEcco il problema. Un contenitore problematico pu\u00f2 assorbire tutte le risorse CPU disponibili sulla macchina. Se hai uno stack applicativo ben progettato (ad esempio, JVM, Go, Node VM opportunamente configurati), questo non rappresenta un problema: \u00e8 possibile lavorare in tali condizioni per lungo tempo. Ma se le applicazioni sono malottimizzate o non ottimizzate affatto (<code>FROM java:latest<\/code>), la situazione pu\u00f2 sfuggire di mano. Noi di Omio abbiamo file Docker base automatizzati con impostazioni ragionevoli per default per i principali linguaggi, quindi tale problema non si \u00e8 mai verificato.<\/p>\n<p>Raccomandiamo di monitorare le metriche <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">USE<\/a><\/noindex> (utilizzo, saturazione ed errori), le latenze API e la frequenza degli errori. Assicurati che i risultati siano conformi alle aspettative.<\/p>\n<h2>Link<\/h2>\n<p>\nQuesta \u00e8 la nostra storia. I seguenti materiali ci hanno molto aiutato a capire cosa sta succedendo:<\/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\">Everything You Need to Know about Linux Containers, Part I: Linux Control Groups and Process Isolation<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/k8s.af\/\">Storie di fallimenti di Kubernetes<\/a><\/noindex> \u2014 cerca \u00abcpu throttling\u00bb.<\/li>\n<\/ul>\n<p>\nSegnalazioni di errori 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\">Overly aggressive CFS<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nHai mai affrontato problemi simili nella tua esperienza o hai un'esperienza in merito al throttling in ambienti di produzione containerizzati? Condividi la tua storia nei commenti!<\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Autoscaling 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.0.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.0.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 CPU e throttling aggressivo in Kubernetes | ProHoster","description":"Nota: questa storia istruttiva di Omio \u2014 un aggregatore di viaggi europeo \u2014 guida i lettori dalla teoria di base alle interessanti e pratiche sfumature della 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}]}}