{"id":55712,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat"},"modified":"2020-02-18T14:03:51","modified_gmt":"2020-02-18T11:03:51","slug":"tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","title":{"rendered":"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente\" src=\"\/wp-content\/uploads\/2020\/01\/0b076d65db116cabdd1b4ae380d3777d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPer padroneggiare completamente Kubernetes, \u00e8 necessario conoscere i vari metodi di scalabilit\u00e0 delle risorse del cluster: secondo <noindex><a rel=\"nofollow\" href=\"https:\/\/speakerdeck.com\/thockin\/everything-you-ever-wanted-to-know-about-resource-scheduling-dot-dot-dot-almost\">gli sviluppatori del sistema<\/a><\/noindex>, questo \u00e8 uno dei compiti principali di Kubernetes. Abbiamo preparato una panoramica di alto livello dei meccanismi di autoscalabilit\u00e0 orizzontale e verticale e di ridimensionamento dei cluster, oltre a raccomandazioni su come utilizzarli in modo efficace.<\/p>\n<p>L'articolo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.magalix.com\/blog\/kubernetes-autoscaling-101\">Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler e Vertical Pod Autoscaler<\/a><\/noindex> \u00e8 stato tradotto da un team che ha implementato l'autoscalabilit\u00e0 in <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/containers\/\">Kubernetes aaS di Mail.ru<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Perch\u00e9 \u00e8 importante pensare alla scalabilit\u00e0 <\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/kubernetes-for-much-stuff\">Kubernetes<\/a><\/noindex> \u2014 uno strumento per la gestione delle risorse e l'orchestrazione. Certamente, non \u00e8 male sperimentare con le fantastiche funzioni di distribuzione, monitoraggio e gestione dei pod (un pod \u00e8 un gruppo di contenitori avviati in risposta a una richiesta). <\/p>\n<p>Tuttavia, \u00e8 importante considerare anche domande come:<\/p>\n<ol>\n<li>Come scalare i moduli e le applicazioni?\n<\/li>\n<li>Come mantenere i contenitori in uno stato operativo ed efficiente?\n<\/li>\n<li>Come rispondere ai continui cambiamenti nel codice e nei carichi di lavoro degli utenti?\n<\/li>\n<\/ol>\n<p>\nLa configurazione dei cluster Kubernetes per bilanciare le risorse e le prestazioni pu\u00f2 essere un compito complesso, richiede una conoscenza approfondita del funzionamento interno di Kubernetes. Il carico di lavoro della tua applicazione o dei tuoi servizi pu\u00f2 fluttuare durante il giorno o anche in un'ora, quindi la bilanciatura dovrebbe essere vista come un processo continuo.<\/p>\n<h2>Livelli di autoscalabilit\u00e0 di Kubernetes<\/h2>\n<p>\nUn'autoscalabilit\u00e0 efficace richiede coordinamento tra due livelli: <\/p>\n<ol>\n<li>Un livello di pod che include l'autoscaling orizzontale (Horizontal Pod Autoscaler, HPA) e verticale (Vertical Pod Autoscaler, VPA). Questo autoscaling utilizza le risorse esistenti per i tuoi contenitori.\n<\/li>\n<li>Il livello del cluster, gestito dal sistema di autoscalabilit\u00e0 del cluster (Cluster Autoscaler, CA), che aumenta o diminuisce il numero di nodi all'interno del cluster.\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Il modulo di autoscalabilit\u00e0 orizzontale (HPA)<\/h2>\n<p>\nCome suggerisce il nome, l'HPA scala il numero di repliche dei pod. Come trigger per modificare il numero di repliche, la maggior parte dei DevOps utilizza il carico della CPU e della memoria. Tuttavia, \u00e8 possibile scalare il sistema in base a <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/#support-for-custom-metrics\">metriche personalizzate<\/a><\/noindex>, la loro <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/#support-for-multiple-metrics\">combinazione<\/a><\/noindex> o addirittura <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/kubernetes-engine\/docs\/tutorials\/external-metrics-autoscaling\">metriche esterne<\/a><\/noindex>.<\/p>\n<p>Schema di funzionamento di alto livello dell'HPA:<\/p>\n<ol>\n<li>L'HPA controlla continuamente i valori delle metriche specificati durante l'installazione, con un intervallo predefinito di 30 secondi.\n<\/li>\n<li>L'HPA cerca di aumentare il numero di pod se viene raggiunta la soglia prevista.\n<\/li>\n<li>L'HPA aggiorna il numero di repliche all'interno del controller di distribuzione\/replica.\n<\/li>\n<li>Il controller di distribuzione\/replica quindi distribuisce tutti i pod aggiuntivi necessari.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente\" src=\"\/wp-content\/uploads\/2020\/01\/e98534431712eb3303668446b0fe567b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>L'HPA avvia il processo di distribuzione dei pod al raggiungimento della soglia delle metriche.<\/i><\/p>\n<p>Quando si utilizza l'HPA, tenere presente quanto segue:<\/p>\n<ul>\n<li>L'intervallo di controllo dell'HPA per impostazione predefinita \u00e8 di 30 secondi. \u00c8 impostato tramite il flag <i>horizontal-pod-autoscaler-sync-period<\/i> nel gestore del controller.\n<\/li>\n<li>L'errore relativo predefinito \u00e8 pari al 10%.\n<\/li>\n<li>Dopo l'ultimo aumento del numero di pod, l'HPA aspetta che le metriche si stabilizzino per tre minuti. Questo intervallo \u00e8 impostato tramite il flag <i>horizontal-pod-autoscaler-upscale-delay<\/i>.\n<\/li>\n<li>Dopo l'ultimo decremento del numero di pod, l'HPA attende la stabilizzazione per cinque minuti. Questo intervallo \u00e8 impostato tramite il flag <i>horizontal-pod-autoscaler-downscale-delay<\/i>.\n<\/li>\n<li>L'HPA funziona meglio con oggetti di distribuzione piuttosto che con i controller di replica. L'autoscaling orizzontale non \u00e8 compatibile con l'aggiornamento rolling, che manipola direttamente i controller di replica. Durante il deployment, il numero di repliche dipende direttamente dagli oggetti di distribuzione.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Autoscaling verticale dei pod<\/h2>\n<p>\nL'autoscaling verticale (VPA) assegna pi\u00f9 (o meno) tempo della CPU o memoria ai pod esistenti. \u00c8 adatto sia per pod stateful che stateless, ma \u00e8 principalmente progettato per servizi stateful. Tuttavia, puoi applicare il VPA anche ai moduli stateless, se hai bisogno di regolare automaticamente le risorse inizialmente allocate. <\/p>\n<p>Il VPA risponde anche agli eventi OOM (out of memory). Per modificare il tempo della CPU e la quantit\u00e0 di memoria \u00e8 necessario riavviare i pod. Durante il riavvio, il VPA rispetta il budget di distribuzione (<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/disruptions\/\">pods distribution budget, PDB<\/a><\/noindex>), per garantire il numero minimo necessario di pod. <\/p>\n<p>Puoi impostare una quantit\u00e0 minima e massima di risorse per ogni modulo. Ad esempio, puoi limitare la quantit\u00e0 massima di memoria allocata a 8 GB. Questo \u00e8 utile se i nodi attuali non possono allocare pi\u00f9 di 8 GB di memoria per il contenitore. Specifiche dettagliate e il meccanismo di funzionamento sono descritti in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/autoscaling\/vertical-pod-autoscaler.md\">wiki ufficiale di VPA<\/a><\/noindex>.<\/p>\n<p>Inoltre, VPA ha una funzionalit\u00e0 interessante di raccomandazione (VPA Recommender). Tiene traccia dell'utilizzo delle risorse e degli eventi OOM di tutti i moduli, per suggerire nuovi valori di memoria e tempo di CPU basati su un algoritmo intelligente che considera le metriche storiche. \u00c8 disponibile anche un'interfaccia API che accetta il descrittore del pod e restituisce i valori di risorse suggeriti.<\/p>\n<p>Vale la pena notare che VPA Recommender non tiene traccia del \"limite\" delle risorse. Questo pu\u00f2 portare a una monopolizzazione delle risorse all'interno dei nodi. \u00c8 meglio impostare un limite a livello di namespace per evitare un eccessivo consumo di memoria o tempo di CPU.<\/p>\n<p>Schema di funzionamento ad alto livello di VPA:<\/p>\n<ol>\n<li>VPA controlla continuamente i valori delle metriche specificati durante l'installazione, con un intervallo predefinito di 10 secondi.\n<\/li>\n<li>Se viene raggiunta la soglia impostata, VPA tenta di modificare la quantit\u00e0 di risorse allocate.\n<\/li>\n<li>VPA aggiorna la quantit\u00e0 di risorse all'interno del controller di distribuzione\/replicazione.\n<\/li>\n<li>Al riavvio dei moduli, tutte le nuove risorse vengono applicate alle istanze create.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente\" src=\"\/wp-content\/uploads\/2020\/01\/324702d5e36e9fcf45ced8b3f276db52.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>VPA aggiunge la quantit\u00e0 necessaria di risorse <\/i><\/p>\n<p>Considera i seguenti aspetti quando utilizzi VPA:<\/p>\n<ul>\n<li>Lo scaling richiede necessariamente il riavvio del pod. Questo \u00e8 necessario per evitare comportamenti instabili dopo aver apportato modifiche. Per affidabilit\u00e0, i moduli vengono riavviati e distribuiti sui nodi in base alle nuove risorse allocate.\n<\/li>\n<li>Il VPA e l'HPA non sono ancora compatibili tra loro e non possono funzionare sugli stessi pod. Se utilizzi entrambi i meccanismi di scaling in uno stesso cluster, assicurati che le configurazioni non consentano loro di attivarsi sugli stessi oggetti.\n<\/li>\n<li>VPA configura le richieste dei contenitori per le risorse basandosi solo sul loro utilizzo passato e attuale. Non imposta limiti all'utilizzo delle risorse. Possono sorgere problemi con il funzionamento delle applicazioni, che inizieranno a occupare sempre pi\u00f9 risorse, il che porter\u00e0 a una disattivazione del pod da parte di Kubernetes.\n<\/li>\n<li>VPA \u00e8 ancora in fase di sviluppo iniziale. Siate pronti a possibili cambiamenti nel sistema nei prossimi tempi. \u00c8 possibile leggere riguardo a <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler#known-limitations-of-the-alpha-version\">note limitazioni<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/autoscaling\/vertical-pod-autoscaler.md#future-work\">piani di sviluppo<\/a><\/noindex>. Pertanto, ci sono piani per implementare la cooperazione tra VPA e HPA, nonch\u00e9 il deployment dei moduli insieme a una politica di autoscaling verticale per loro (ad esempio, un'etichetta speciale 'requires VPA').\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Scalabilit\u00e0 automatica del cluster Kubernetes<\/h2>\n<p>\nL'autoscalabilit\u00e0 del cluster (Cluster Autoscaler, CA) modifica il numero di nodi in base al numero di moduli pod in attesa. Il sistema controlla periodicamente la presenza di moduli in attesa e aumenta le dimensioni del cluster se sono necessarie pi\u00f9 risorse e se il cluster non supera i limiti stabiliti. CA interagisce con il fornitore di servizi cloud, richiedendo nodi aggiuntivi o liberando quelli inattivi. La prima versione pubblica di CA \u00e8 stata presentata in Kubernetes 1.8.<\/p>\n<p>Schema di funzionamento ad alto livello di CA:<\/p>\n<ol>\n<li>CA controlla la presenza di moduli in stato di attesa con un intervallo di default di 10 secondi.\n<\/li>\n<li>Se uno o pi\u00f9 moduli sono in attesa a causa della mancanza di risorse disponibili nel cluster per la loro distribuzione, tenta di preparare uno o pi\u00f9 nodi aggiuntivi.\n<\/li>\n<li>Quando il fornitore di servizi cloud allocca il nodo necessario, esso si unisce al cluster e diventa pronto per gestire i moduli pod.\n<\/li>\n<li>Il pianificatore di Kubernetes distribuisce i moduli in attesa sul nuovo nodo. Se dopo ci\u00f2 alcuni moduli rimangono ancora in attesa, il processo si ripete e nuovi nodi vengono aggiunti al cluster.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente\" src=\"\/wp-content\/uploads\/2020\/01\/2cd3c97f5d1b040b813940a4e804365e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Assegnazione automatica di nodi del cluster nel cloud<\/i><\/p>\n<p>Tenete presente quanto segue quando utilizzate CA:<\/p>\n<ul>\n<li>CA garantisce che tutti i moduli nel cluster abbiano uno spazio per l'esecuzione, indipendentemente dal carico della CPU. Inoltre, cerca di garantire che nel cluster non ci siano nodi non necessari.\n<\/li>\n<li>CA registra la necessit\u00e0 di scalare dopo circa 30 secondi.\n<\/li>\n<li>Dopo che un nodo diventa non necessario, CA attende per impostazione predefinita 10 minuti prima di scalare il sistema.\n<\/li>\n<li>Nel sistema di autoscalabilit\u00e0 ci sono concetti di espansori (expanders). Queste sono diverse strategie per selezionare il gruppo di nodi a cui verranno aggiunti nuovi.\n<\/li>\n<li>Utilizza responsabilmente l'opzione <i>cluster-autoscaler.kubernetes.io\/safe-to-evict (true)<\/i>. Se si installano molti pod oppure se molti di essi sono distribuiti su diversi nodi, si perder\u00e0 in gran parte la capacit\u00e0 di ridurre lo scaling del cluster.\n<\/li>\n<li>Usa <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/disruptions\/\">PodDisruptionBudgets<\/a><\/noindex>, per evitare l'eliminazione dei pod, il che potrebbe portare a un'interruzione totale di una parte della tua applicazione.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Come i sistemi di autoscalabilit\u00e0 Kubernetes interagiscono tra loro<\/h2>\n<p>\nPer una perfetta armonia, \u00e8 opportuno applicare l'autoscaling sia a livello di pod (HPA\/VPA) che a livello di cluster. Interagiscono relativamente facilmente tra loro:<\/p>\n<ol>\n<li>HPA o VPA aggiornano le repliche dei pod o le risorse allocate per i pod esistenti.\n<\/li>\n<li>Se non ci sono nodi sufficienti per la scalabilit\u00e0 pianificata, il CA rileva la presenza di pod in stato di attesa.\n<\/li>\n<li>CA assegna nuovi nodi.\n<\/li>\n<li>I moduli vengono distribuiti sui nuovi nodi.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscalamento in Kubernetes: come utilizzarli efficacemente\" src=\"\/wp-content\/uploads\/2020\/01\/09379f30f349a235bb26a670ad0d0bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sistema di scaling collaborativo di Kubernetes<\/i><\/p>\n<h2>Errori comuni nell'autoscalabilit\u00e0 di Kubernetes<\/h2>\n<p>\nCi sono diversi problemi comuni che i DevOps affrontano quando cercano di implementare l'autoscalabilit\u00e0.<\/p>\n<p>HPA e VPA dipendono da metriche e alcune informazioni storiche. Se non sono disponibili risorse sufficienti, i moduli verranno ridotti e non saranno in grado di generare metriche. In questo caso, l'autoscalabilit\u00e0 non avverr\u00e0 mai.<\/p>\n<p>L'operazione di scalabilit\u00e0 \u00e8 sensibile al tempo. Vogliamo che i moduli e il cluster si scalino rapidamente, prima che gli utenti notino problemi o interruzioni. Pertanto, \u00e8 importante considerare il tempo medio per la scalabilit\u00e0 dei pod e del cluster.<\/p>\n<p>Lo scenario ideale \u00e8 di 4 minuti:<\/p>\n<ol>\n<li>30 secondi. Aggiornamento delle metriche target: 30\u221260 secondi.\n<\/li>\n<li>30 secondi. HPA controlla i valori delle metriche: 30 secondi.\n<\/li>\n<li>Meno di 2 secondi. I moduli pod vengono creati e passano allo stato di attesa: 1 secondo.\n<\/li>\n<li>Meno di 2 secondi. CA vede i moduli in attesa e invia richieste per preparare i nodi: 1 secondo.\n<\/li>\n<li>3 minuti. Il fornitore di cloud sta allocando nodi. K8s aspetta che siano pronti: fino a 10 minuti (dipende da diversi fattori).\n<\/li>\n<\/ol>\n<p>\nLo scenario peggiore (pi\u00f9 realistico) \u00e8 di 12 minuti:<\/p>\n<ol>\n<li>30 secondi. Aggiornamento delle metriche target.\n<\/li>\n<li>30 secondi. L'HPA verifica i valori delle metriche.\n<\/li>\n<li>Meno di 2 secondi. I moduli pod sono stati creati e passano allo stato di attesa.\n<\/li>\n<li>Meno di 2 secondi. Il CA vede i moduli in attesa e invia richieste per preparare i nodi.\n<\/li>\n<li>10 minuti. Il fornitore di cloud sta allocando nodi. K8s aspetta che siano pronti. Il tempo di attesa dipende da diversi fattori, come la latenza del fornitore, la latenza del sistema operativo e il funzionamento degli strumenti ausiliari.\n<\/li>\n<\/ol>\n<p>\nNon confondete i meccanismi di scalabilit\u00e0 dei fornitori di cloud con il nostro CA. Quest'ultimo opera all'interno del cluster Kubernetes, mentre il meccanismo del fornitore cloud lavora sulla base della distribuzione dei nodi. Non sa cosa succede ai vostri pod o alle vostre applicazioni. Questi sistemi funzionano in parallelo. <\/p>\n<h2>Come gestire lo scalamento in Kubernetes<\/h2>\n<p><\/p>\n<ol>\n<li>Kubernetes \u00e8 uno strumento di gestione delle risorse e di orchestrazione. Le operazioni di gestione dei pod e delle risorse del cluster sono un passo fondamentale per padroneggiare Kubernetes.\n<\/li>\n<li>Comprendere la logica di scalabilit\u00e0 dei pod in relazione all'HPA e al VPA.\n<\/li>\n<li>Il CA dovrebbe essere utilizzato solo se comprendete bene le esigenze dei vostri pod e dei vostri contenitori.\n<\/li>\n<li>Per una configurazione ottimale del cluster, \u00e8 necessario capire come i vari sistemi di scaling lavorano insieme.\n<\/li>\n<li>Quando valutate il tempo di scaling, tenete a mente gli scenari migliori e peggiori.\n<\/li>\n<\/ol>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/484344\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e \u043e\u0441\u0432\u043e\u0435\u043d\u0438\u044f Kubernetes \u043d\u0443\u0436\u043d\u043e \u0437\u043d\u0430\u0442\u044c \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0441\u043f\u043e\u0441\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043d\u044b\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432: \u043f\u043e \u0441\u043b\u043e\u0432\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u044d\u0442\u043e \u043e\u0434\u043d\u0430 \u0438\u0437 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0437\u0430\u0434\u0430\u0447 Kubernetes. \u041c\u044b \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0443\u0440\u043e\u0432\u043d\u0435\u0432\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u043e\u0432 \u0433\u043e\u0440\u0438\u0437\u043e\u043d\u0442\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0438 \u0432\u0435\u0440\u0442\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0440\u0430\u0437\u043c\u0435\u0440\u0430 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u0421\u0442\u0430\u0442\u044c\u044e Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, and Vertical Pod Autoscaler \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55712","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.\" \/>\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\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\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\udd47\u0422\u0440\u0438 \u0443\u0440\u043e\u0432\u043d\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes: \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat\" \/>\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-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:51+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\udd47Tre livelli di autoscaling in Kubernetes: come utilizzarli efficacemente | ProHoster","description":"Per intero.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","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\udd47\u0422\u0440\u0438 \u0443\u0440\u043e\u0432\u043d\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes: \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c | ProHoster","og:description":"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","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-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55712","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 19:38:31","updated":"2022-09-29 14:33:55","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\/55712","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=55712"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55712\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=55712"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=55712"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=55712"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}