{"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 autoscaling in Kubernetes: come usarli in modo efficace","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tre livelli di autoscaling in Kubernetes: come usarli in modo efficace\" 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 per scalare le risorse del cluster: <noindex><a rel=\"nofollow\" href=\"https:\/\/speakerdeck.com\/thockin\/everything-you-ever-wanted-to-know-about-resource-scheduling-dot-dot-dot-almost\">secondo gli sviluppatori del sistema,<\/a><\/noindex>, \u00e8 uno dei principali obiettivi di Kubernetes. Abbiamo preparato una panoramica ad alto livello dei meccanismi di autoscaling orizzontale e verticale e di come ridimensionare i 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'autoscaling 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 considerare lo scaling <\/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, \u00e8 interessante sperimentare le fantastiche funzionalit\u00e0 di distribuzione, monitoraggio e gestione dei pod (un modulo pod \u00e8 un gruppo di contenitori avviati in risposta a una richiesta). <\/p>\n<p>Tuttavia, \u00e8 importante considerare anche le seguenti questioni:<\/p>\n<ol>\n<li>Come scalare i moduli e le applicazioni?\n<\/li>\n<li>Come mantenere i contenitori funzionanti ed efficienti?\n<\/li>\n<li>Come rispondere alle costanti variazioni nel codice e nei carichi di lavoro degli utenti?\n<\/li>\n<\/ol>\n<p>\nConfigurare i cluster Kubernetes per bilanciare le risorse e le prestazioni pu\u00f2 essere una sfida complessa, richiedendo competenze esperte sul funzionamento interno di Kubernetes. Il carico di lavoro della tua applicazione o dei tuoi servizi pu\u00f2 variare durante il giorno o addirittura all'interno di un'ora, quindi \u00e8 meglio considerare il bilanciamento come un processo continuo.<\/p>\n<h2>Livelli di autoscaling di Kubernetes<\/h2>\n<p>\nUn autoscaling efficace richiede coordinamento tra due livelli: <\/p>\n<ol>\n<li>Livello dei pod, che include l'autoscaling orizzontale (Horizontal Pod Autoscaler, HPA) e verticale (Vertical Pod Autoscaler, VPA). Questo serve a scalare le risorse esistenti per i tuoi container.\n<\/li>\n<li>Il livello del cluster, gestito dal sistema di autoscaling 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>Modulo di autoscaling orizzontale (HPA)<\/h2>\n<p>\nCome suggerisce il nome, l'HPA scala il numero di repliche dei pod. Come trigger per cambiare il numero di repliche, la maggior parte dei DevOps utilizza il carico sulla CPU e la memoria. Tuttavia, \u00e8 possibile scalare il sistema sulla base di <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/#support-for-custom-metrics\">metriche personalizzate<\/a><\/noindex>, una 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 ad alto livello dell'HPA:<\/p>\n<ol>\n<li>L'HPA controlla continuamente i valori delle metriche specificate al momento dell'impostazione, con un intervallo predefinito di 30 secondi.\n<\/li>\n<li>L'HPA tenta di aumentare il numero di moduli se viene raggiunta la soglia impostata.\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 moduli aggiuntivi necessari.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscaling in Kubernetes: come usarli in modo efficace\" 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 moduli al raggiungimento della soglia delle metriche.<\/i><\/p>\n<p>Quando si utilizza l'HPA, considerare quanto segue:<\/p>\n<ul>\n<li>L'intervallo di controllo predefinito dell'HPA \u00e8 di 30 secondi. \u00c8 impostato dal flag <i>horizontal-pod-autoscaler-sync-period<\/i> nel gestore del controller.\n<\/li>\n<li>L'errore relativo predefinito \u00e8 del 10%.\n<\/li>\n<li>Dopo l'ultimo aumento del numero di moduli, l'HPA attende la stabilizzazione delle metriche per tre minuti. Questo intervallo \u00e8 impostato dal flag <i>horizontal-pod-autoscaler-upscale-delay<\/i>.\n<\/li>\n<li>Dopo l'ultimo abbassamento del numero di moduli, l'HPA attende la stabilizzazione per cinque minuti. Questo intervallo \u00e8 impostato dal flag <i>horizontal-pod-autoscaler-downscale-delay<\/i>.\n<\/li>\n<li>L'HPA funziona meglio con oggetti di distribuzione piuttosto che con i controllori di replica. L'autoscaling orizzontale non \u00e8 compatibile con l'aggiornamento continuo (rolling update), che manipola direttamente i controllori di replica. Durante la distribuzione, il numero di repliche dipende direttamente dagli oggetti di distribuzione.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Autoscalamento verticale dei pod<\/h2>\n<p>\nL'autoscalamento verticale (VPA) assegna pi\u00f9 (o meno) tempo della CPU o memoria ai pod esistenti. \u00c8 adatto per i pod stateful o stateless, ma principalmente progettato per i servizi stateful. Tuttavia, puoi applicare il VPA anche a moduli stateless se \u00e8 necessario regolare automaticamente la quantit\u00e0 di risorse inizialmente allocate. <\/p>\n<p>Il VPA risponde anche agli eventi OOM (out of memory, memoria insufficiente). 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 allocazione (<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 moduli. <\/p>\n<p>\u00c8 possibile impostare un volume minimo e massimo delle risorse per ogni modulo. Ad esempio, \u00e8 possibile limitare la memoria massima a 8 GB. Questo \u00e8 utile se i nodi attuali non possono allocare pi\u00f9 di 8 GB di memoria per il container. Le specifiche dettagliate e il 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 funzione interessante di raccomandazioni (VPA Recommender). Questa tiene traccia dell'uso delle risorse e degli eventi OOM di tutti i moduli, proponendo 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 un descrittore pod e restituisce i valori di risorse suggeriti.<\/p>\n<p>\u00c8 importante notare che VPA Recommender non tiene traccia del \"limite\" delle risorse. Questo pu\u00f2 portare a una monopolizzazione delle risorse da parte dei moduli all'interno dei nodi. \u00c8 meglio impostare un valore limite a livello di namespace per evitare un consumo eccessivo di memoria o tempo di CPU.<\/p>\n<p>Schema di alto livello del funzionamento di VPA:<\/p>\n<ol>\n<li>VPA controlla continuamente i valori delle metriche specificati al momento dell'installazione, con un intervallo predefinito di 10 secondi.\n<\/li>\n<li>Se viene raggiunta una soglia stabilita, VPA cerca di modificare la quantit\u00e0 di risorse allocate.\n<\/li>\n<li>VPA aggiorna il numero di risorse all'interno del controller di deployment\/replikazione.\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 autoscaling in Kubernetes: come usarli in modo efficace\" src=\"\/wp-content\/uploads\/2020\/01\/324702d5e36e9fcf45ced8b3f276db52.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>VPA aggiunge il numero necessario di risorse <\/i><\/p>\n<p>Prendi in considerazione i seguenti punti quando utilizzi VPA:<\/p>\n<ul>\n<li>Lo scaling richiede necessariamente il riavvio del pod. Questo \u00e8 necessario per evitare malfunzionamenti dopo aver apportato delle modifiche. Per garantire l'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 attualmente compatibili tra loro e non possono funzionare sugli stessi pod. Se stai utilizzando entrambi i meccanismi di scaling all'interno di uno stesso cluster, assicurati che le configurazioni non consentano loro di attivarsi sugli stessi oggetti.\n<\/li>\n<li>VPA imposta le richieste di risorse dei contenitori basandosi solo sull'uso passato e attuale. Non stabilisce limiti per l'uso delle risorse. Possono sorgere problemi con il funzionamento di applicazioni che iniziano a consumare sempre pi\u00f9 risorse, portando Kubernetes a spegnere il pod.\n<\/li>\n<li>VPA \u00e8 attualmente in fase di sviluppo. Preparati al fatto che nel prossimo futuro il sistema potrebbe subire alcune modifiche. Puoi leggere sulle <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler#known-limitations-of-the-alpha-version\">limiti noti<\/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>. Ci sono piani per implementare la compatibilit\u00e0 tra VPA e HPA, cos\u00ec come il deployment dei moduli con una politica di autoscaling verticale per loro (ad esempio, un'etichetta speciale 'requires VPA').\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Autoscalamento del cluster Kubernetes<\/h2>\n<p>\nL'autoscalamento del cluster (Cluster Autoscaler, CA) modifica il numero di nodi in base al numero di pod in attesa. Il sistema controlla periodicamente la presenza di pod in attesa \u2014 e aumenta la dimensione del cluster se sono necessarie pi\u00f9 risorse e se il cluster non supera i limiti impostati. 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 alto livello del funzionamento di CA:<\/p>\n<ol>\n<li>CA controlla la presenza di moduli in attesa con un intervallo predefinito 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, cerca di preparare uno o pi\u00f9 nodi aggiuntivi.\n<\/li>\n<li>Quando il fornitore di servizi cloud allocato il nodo necessario, questo si unisce al cluster e diventa pronto per gestire i pod.\n<\/li>\n<li>Il piano di Kubernetes distribuisce i moduli in attesa sul nuovo nodo. Se dopo questo alcuni moduli rimangono ancora in attesa, il processo si ripete, e vengono aggiunti nuovi nodi al cluster.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Tre livelli di autoscaling in Kubernetes: come usarli in modo efficace\" src=\"\/wp-content\/uploads\/2020\/01\/2cd3c97f5d1b040b813940a4e804365e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Assegnazione automatica dei nodi del cluster nel cloud<\/i><\/p>\n<p>Tieni presente quanto segue quando usi CA:<\/p>\n<ul>\n<li>CA garantisce che tutti i moduli nel cluster abbiano spazio per essere eseguiti, indipendentemente dal livello di utilizzo della CPU. Inoltre, cerca di garantire che nel cluster non ci siano nodi inutili.\n<\/li>\n<li>CA registra la necessit\u00e0 di scalare circa ogni 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 autoscalamento esistono concetti di espansori (expanders). Queste sono diverse strategie per scegliere il gruppo di nodi a cui verranno aggiunti nuovi nodi.\n<\/li>\n<li>Applicare responsabilmente l'opzione <i>cluster-autoscaler.kubernetes.io\/safe-to-evict (true)<\/i>. Se installi molti pod o se molti di loro sono distribuiti su diversi nodi, perderai in gran parte la capacit\u00e0 di ridurre le dimensioni del cluster.\n<\/li>\n<li>Usa <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/disruptions\/\">PodDisruptionBudgets<\/a><\/noindex>, per prevenire la rimozione dei pod, rischio che parte della tua applicazione possa interrompersi completamente.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Come interagiscono tra loro i sistemi di autoscaling di Kubernetes<\/h2>\n<p>\nPer un'armonia ideale, \u00e8 necessario 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 ci sono nodi insufficienti per lo scaling pianificato, il CA nota che ci sono pod in attesa.\n<\/li>\n<li>CA provisiona 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 autoscaling in Kubernetes: come usarli in modo efficace\" 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'autoscaling di Kubernetes<\/h2>\n<p>\nCi sono alcune problematiche comuni che i DevOps incontrano quando tentano di implementare l'autoscaling.<\/p>\n<p>HPA e VPA dipendono da metriche e da alcune informazioni storiche. Se non ci sono risorse sufficienti allocate, i moduli saranno ridotti e non potranno generare metriche. In questo caso, l'autoscaling non verr\u00e0 mai attuato.<\/p>\n<p>L'operazione di scaling \u00e8 sensibile al tempo. Vogliamo che i moduli e il cluster si scalino rapidamente \u2014 prima che gli utenti notino problemi o malfunzionamenti. Pertanto, \u00e8 importante considerare il tempo medio di scaling 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 rileva i moduli in attesa e invia le richieste per preparare i nodi: 1 secondo.\n<\/li>\n<li>3 minuti. Il fornitore cloud provisiona i nodi. K8s attende che siano pronti: fino a 10 minuti (dipende da vari 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. HPA controlla i valori delle metriche.\n<\/li>\n<li>Meno di 2 secondi. I moduli pod vengono creati e passano allo stato di attesa.\n<\/li>\n<li>Meno di 2 secondi. CA rileva i moduli in attesa e invia le richieste per preparare i nodi.\n<\/li>\n<li>10 minuti. Il fornitore cloud provisiona i nodi. K8s attende che siano pronti. I tempi di attesa variano in base a 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 confondere i meccanismi di scaling dei provider cloud con il nostro CA. Quest'ultimo funziona all'interno del cluster Kubernetes, mentre il meccanismo del provider cloud si basa sulla distribuzione dei nodi. Non sa cosa succede ai tuoi pod o alla tua applicazione. Questi sistemi operano in parallelo. <\/p>\n<h2>Come gestire lo scaling in Kubernetes<\/h2>\n<p><\/p>\n<ol>\n<li>Kubernetes \u00e8 uno strumento di gestione delle risorse e orchestrazione. Le operazioni di gestione dei pod e delle risorse del cluster sono un punto cruciale nell'apprendimento di Kubernetes.\n<\/li>\n<li>Apprendi la logica di scalabilit\u00e0 dei pod tenendo in considerazione HPA e VPA.\n<\/li>\n<li>Il CA dovrebbe essere utilizzato solo se comprendi bene le esigenze dei tuoi pod e container.\n<\/li>\n<li>Per una configurazione ottimale del cluster, \u00e8 necessario comprendere come i diversi sistemi di scaling lavorano insieme.\n<\/li>\n<li>Quando valuti i tempi di scaling, considera 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.0.1 - 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.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\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 in modo efficace | ProHoster","description":"Per completo.","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}]}}