{"id":56259,"date":"2020-02-08T00:00:00","date_gmt":"2020-02-07T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih"},"modified":"2020-02-18T14:04:30","modified_gmt":"2020-02-18T11:04:30","slug":"rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Nodi di lavoro Kubernetes: molti piccoli o pochi grandi?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nodi
\nQuando si crea un cluster Kubernetes, possono sorgere domande: quanti nodi di lavoro configurare e di che tipo? \u00c8 meglio per un cluster on-premise acquistare alcuni server potenti o utilizzare una decina di vecchine nel proprio data center? E nel cloud \u00e8 meglio optare per otto istanze a singolo core o due istanze a quattro core? <\/p>\n

Le risposte a queste domande sono nell'articolo di Daniel Weibel, ingegnere informatico e docente del progetto formativo Learnk8s<\/a><\/noindex> nella traduzione del team Kubernetes aaS di Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Capacit\u00e0 del cluster<\/h2>\n

\nIn generale, un cluster Kubernetes pu\u00f2 essere considerato come un grande \"supernodo\". La sua potenza di calcolo totale \u00e8 la somma delle potenze di tutti i nodi costituenti. <\/p>\n

Esistono diversi modi per raggiungere la capacit\u00e0 target desiderata del cluster. Ad esempio, se abbiamo bisogno di un cluster con una capacit\u00e0 totale di 8 core CPU e 32 GB di RAM, perch\u00e9 il set di applicazioni richiede quella quantit\u00e0 di risorse. Possiamo quindi installare due nodi da 16 GB di memoria o quattro nodi da 8 GB di memoria, due processori quad-core o quattro processori dual-core.<\/p>\n

Ecco solo due possibili modalit\u00e0 di creazione di un cluster:<\/p>\n

\"Nodi
\nEntrambe le opzioni offrono un cluster con la stessa capacit\u00e0, ma nella configurazione in basso ci sono quattro nodi pi\u00f9 piccoli, mentre nella configurazione in alto ci sono due nodi pi\u00f9 grandi. <\/p>\n

Qual \u00e8 l'opzione migliore?<\/h3>\n

\nPer rispondere a questa domanda, consideriamo i vantaggi di entrambe le opzioni. Li abbiamo riassunti in una tabella.<\/p>\n

Diversi nodi grandi<\/p>\n

Molti piccoli nodi<\/p>\n

Gestione del cluster pi\u00f9 semplice (se \u00e8 on-premise)<\/p>\n

Autoscaling fluido<\/p>\n

Pi\u00f9 economico (se on-premise) <\/p>\n

Il prezzo \u00e8 simile (in cloud) <\/p>\n

Possibilit\u00e0 di eseguire applicazioni intensive in termini di risorse <\/p>\n

Replica completa<\/p>\n

Le risorse vengono utilizzate in modo pi\u00f9 efficiente (meno overhead per i demoni di sistema)
\nMaggiore resilienza del cluster<\/p>\n

Si noti che stiamo parlando solo di nodi di lavoro. La scelta del numero e delle dimensioni dei nodi principali \u00e8 un argomento del tutto diverso.<\/p>\n

Quindi, esaminiamo pi\u00f9 da vicino ciascun punto della tabella.<\/p>\n

Prima opzione: diversi nodi grandi<\/h2>\n

\nL'opzione pi\u00f9 estrema \u00e8 avere un solo nodo di lavoro per l'intera capacit\u00e0 del cluster. Nell'esempio sopra, sarebbe un solo nodo di lavoro con 16 core CPU e 16 GB di RAM.<\/p>\n

Pro <\/h3>\n

\nVantaggio n. 1. Gestione pi\u00f9 semplice<\/b>
\n\u00c8 pi\u00f9 semplice gestire pi\u00f9 macchine che un'intera flotta. \u00c8 pi\u00f9 veloce applicare aggiornamenti e patch, ed \u00e8 pi\u00f9 facile sincronizzare. Anche il numero di guasti in termini assoluti \u00e8 inferiore.<\/p>\n

Si prega di notare che quanto sopra si riferisce all'hardware di propriet\u00e0, ai propri server, e non alle istanze cloud.<\/p><\/blockquote>\n

\nNel cloud la situazione \u00e8 diversa. La gestione \u00e8 a carico del fornitore di servizi cloud. Pertanto, gestire dieci nodi nel cloud non \u00e8 molto diverso dalla gestione di un singolo nodo.<\/p>\n

Il routing del traffico e la distribuzione del carico tra i pod nel cloud avviene automaticamente<\/a><\/noindex>: il traffico in arrivo da Internet viene indirizzato al bilanciatore di carico principale, che reindirizza il traffico a una delle porte di uno dei nodi (il servizio NodePort espone porte nel range 30000-32767 su ogni nodo del cluster). Le regole stabilite da kube-proxy reindirizzano il traffico dal nodo al pod. Ecco come si presenta per dieci pod su due nodi:<\/p>\n

\"Nodi
\nVantaggio n. 2. Costi inferiori per nodo<\/b>
\nUna macchina potente costa di pi\u00f9, ma l'aumento del prezzo non \u00e8 necessariamente lineare. In altre parole, un server a dieci core con 10 GB di memoria \u00e8 solitamente pi\u00f9 economico di dieci server a un core con la stessa quantit\u00e0 di memoria.<\/p>\n

Ma tenete presente che questa regola di solito non si applica ai servizi cloud. Nei modelli di prezzo attuali, tutti i principali fornitori di servizi cloud aumentano i prezzi linearmente con l'aumento della capacit\u00e0.<\/p><\/blockquote>\n

\nDi conseguenza, nel cloud di solito non \u00e8 possibile risparmiare su server pi\u00f9 potenti.<\/p>\n

Vantaggio n. 3. \u00c8 possibile eseguire applicazioni esigenti in termini di risorse<\/b>
\nAlcune applicazioni richiedono server potenti nel cluster. Ad esempio, se un sistema di apprendimento automatico necessita di 8 GB di memoria, non \u00e8 possibile eseguirlo su nodi da 1 GB, ma solo avendone almeno uno grande all'interno del cluster.<\/p>\n

Svantaggi <\/h3>\n

\nMinus numero 1. Molti pod su nodo<\/b>
\nSe lo stesso compito viene eseguito su un minor numero di nodi, ci saranno naturalmente pi\u00f9 pod su ognuno di essi.<\/p>\n

Questo pu\u00f2 diventare un problema.<\/p>\n

La ragione \u00e8 che ogni modulo comporta alcune spese generali per l'ambiente di esecuzione del contenitore (ad esempio, Docker), oltre a kubelet e cAdvisor.<\/p>\n

Ad esempio, kubelet controlla regolarmente la vitalit\u00e0 di tutti i container su un nodo: pi\u00f9 container ci sono, maggiore \u00e8 il lavoro per kubelet.<\/p>\n

CAdvisor raccoglie statistiche sull'uso delle risorse di tutti i container su un nodo, mentre kubelet richiede regolarmente queste informazioni e le fornisce tramite API. Ancora una volta, pi\u00f9 container ci sono, maggiore \u00e8 il lavoro sia per cAdvisor che per kubelet.<\/p>\n

Se il numero di moduli aumenta, questo potrebbe rallentare il sistema e addirittura comprometterne l'affidabilit\u00e0.<\/p>\n

\"Nodi
\nNel repository di Kubernetes, alcuni si sono lamentati<\/a><\/noindex>, che i nodi oscillano tra gli stati Ready\/NotReady, poich\u00e9 i controlli regolari di kubelet su tutti i container su un nodo richiedono troppo tempo.
\nPer questo motivo, Kubernetes si raccomanda di non allocare pi\u00f9 di 110 pod per nodo<\/a><\/noindex>. A seconda delle prestazioni del nodo, potresti essere in grado di eseguire pi\u00f9 pod per nodo, ma \u00e8 difficile prevedere se ci saranno problemi o se tutto funzioner\u00e0 bene. \u00c8 consigliabile testare il funzionamento in anticipo. <\/p>\n

Svantaggio n. 2. Limiti sulla replica.<\/b>
\nUn numero insufficiente di nodi limita il livello di replica delle applicazioni. Ad esempio, se hai un'applicazione ad alta disponibilit\u00e0 con cinque repliche, ma solo due nodi, il livello di replica effettivo dell'applicazione si riduce a due.<\/p>\n

Le cinque repliche possono essere distribuite solo su due nodi e se uno di essi non funziona, si compromettono immediatamente pi\u00f9 repliche.<\/p>\n

Se hai cinque nodi o pi\u00f9, ciascuna replica verr\u00e0 eseguita su un nodo separato e il guasto di un nodo eliminer\u00e0 al massimo una replica.<\/p>\n

Pertanto, i requisiti di alta disponibilit\u00e0 possono richiedere un numero minimo di nodi nel cluster.<\/p>\n

Svantaggio n. 3. Peggiori conseguenze del guasto<\/b>
\nCon un numero ridotto di nodi, ogni guasto porta conseguenze pi\u00f9 gravi. Ad esempio, se hai solo due nodi e uno di essi fallisce, scompare immediatamente met\u00e0 dei tuoi moduli.<\/p>\n

Certo, Kubernetes sposter\u00e0 il carico di lavoro dal nodo guasto sugli altri. Ma se ce ne sono pochi, la capacit\u00e0 disponibile potrebbe non essere sufficiente. Di conseguenza, parte delle tue applicazioni sar\u00e0 non disponibile finch\u00e9 non riavvii il nodo guasto.<\/p>\n

Cos\u00ec, pi\u00f9 nodi ci sono, minore \u00e8 l'impatto dei guasti hardware.<\/p>\n

Contro numero 4. Maggiori passi nell'auto-scaling<\/b>
\nIn Kubernetes, \u00e8 attiva una sistema di auto-scaling dei cluster per l'infrastruttura cloud, che consente di aggiungere o rimuovere nodi automaticamente in base alle esigenze attuali. Con nodi pi\u00f9 grandi, l'auto-scaling diventa pi\u00f9 brusco e goffo. Ad esempio, con due nodi, l'aggiunta di un ulteriore nodo aumenter\u00e0 la capacit\u00e0 del cluster immediatamente del 50%. E dovrai pagare per queste risorse, anche se non ti servono.<\/p>\n

Pertanto, se prevedi di utilizzare l'auto-scaling del cluster, pi\u00f9 nodi hai, pi\u00f9 flessibile ed economico sar\u00e0 lo scaling.<\/p>\n

Ora vediamo i pro e contro di avere un gran numero di nodi piccoli.<\/p>\n

Seconda opzione: molti nodi piccoli<\/h2>\n

\nI vantaggi di questo approccio, in effetti, derivano dagli svantaggi dell'opzione opposta con pochi nodi grandi.<\/p>\n

Pro<\/h3>\n

\nPro numero 1. Meno conseguenze di un guasto<\/b>
\nPi\u00f9 nodi ci sono, meno pod ci sono su ciascun nodo. Ad esempio, se hai cento moduli su dieci nodi, in media ci saranno dieci moduli su ogni nodo.<\/p>\n

In questo modo, se uno dei nodi si guasta, perdi solo il 10% del carico di lavoro. \u00c8 probabile che vengano colpite solo poche repliche, e le applicazioni nel complesso rimarranno operative.<\/p>\n

Inoltre, i nodi restanti avranno probabilmente abbastanza risorse libere per il carico di lavoro del nodo guasto, consentendo a Kubernetes di riallocare liberamente i pod, e le tue applicazioni torneranno rapidamente a uno stato operativo.<\/p>\n

Vantaggio n. 2. Buona replicazione<\/b>
\nSe ci sono abbastanza nodi, il planner di Kubernetes pu\u00f2 assegnare tutte le repliche a nodi diversi. In questo modo, in caso di guasto di un nodo, verr\u00e0 colpita solo una replica e l'applicazione rimarr\u00e0 accessibile.<\/p>\n

Svantaggi <\/h3>\n

\nSvantaggio n. 1. Maggiore difficolt\u00e0 di gestione<\/b>
\nGestire un numero elevato di nodi \u00e8 pi\u00f9 complicato. Ad esempio, ogni nodo Kubernetes deve interagire con tutti gli altri, il che significa che il numero di connessioni cresce quadraticamente e tutte queste connessioni devono essere monitorate.<\/p>\n

Il controller dei nodi nel gestore dei controller Kubernetes esegue regolarmente il checkup di tutti i nodi nel cluster per verificarne il funzionamento: pi\u00f9 nodi ci sono, maggiore \u00e8 il carico sul controller.<\/p>\n

Aumenta anche il carico sul database etcd: ogni kubelet e kube-proxy richiamano watcher<\/a><\/noindex> per etcd (tramite API), al quale etcd deve trasmettere gli aggiornamenti dell'oggetto.<\/p>\n

In generale, ogni nodo di lavoro aggiunge ulteriore carico sui componenti di sistema dei nodi principali.<\/p>\n

\"Nodi
\nKubernetes supporta ufficialmente cluster con fino a 5000 nodi<\/a><\/noindex>. Tuttavia, nella pratica, gi\u00e0 500 nodi possono causare problemi non banali.<\/a><\/noindex>.<\/p>\n

Per gestire un numero elevato di nodi di lavoro, \u00e8 consigliabile scegliere nodi principali pi\u00f9 performanti. Ad esempio, kube-up installa automaticamente<\/a><\/noindex> la dimensione VM corretta per il nodo principale in base al numero di nodi di lavoro. Ci\u00f2 significa che pi\u00f9 nodi di lavoro ci sono, pi\u00f9 performanti devono essere i nodi principali. <\/p>\n

Per affrontare queste problematiche specifiche, sono disponibili soluzioni specializzate come Virtual Kubelet<\/a><\/noindex>. Questo sistema consente di superare i limiti e creare cluster con un numero enorme di nodi di lavoro.<\/p>\n

Svantaggio n. 2. Maggiori costi operativi<\/b>
\nSu ogni nodo di lavoro, Kubernetes avvia un insieme di demoni di sistema, tra cui l'ambiente di esecuzione dei contenitori (ad esempio, Docker), kube-proxy e kubelet, incluso cAdvisor. Insieme consumano una quantit\u00e0 fissa di risorse.<\/p>\n

Se hai molti nodi piccoli, la quota di questi costi operativi per ogni nodo \u00e8 maggiore. Ad esempio, immagina che tutti i demoni di sistema di un nodo insieme utilizzino 0,1 core CPU e 0,1 GB di memoria. Se hai un nodo con dieci core e 10 GB di memoria, i demoni consumano il 1% della capacit\u00e0 del cluster. D'altra parte, su dieci nodi con un core ciascuno e 1 GB di memoria, i demoni occuperanno il 10% della capacit\u00e0 del cluster.<\/p>\n

Pertanto, meno nodi hai, pi\u00f9 efficiente \u00e8 l'utilizzo dell'infrastruttura.<\/p>\n

Svantaggio n. 3. Utilizzo inefficiente delle risorse<\/b>
\nSu nodi piccoli, potrebbe capitare che i frammenti rimanenti di risorse siano troppo piccoli per assegnarvi un carico di lavoro, quindi rimangono inutilizzati.<\/p>\n

Ad esempio, ogni pod richiede 0,75 GB di memoria. Se hai dieci nodi e ciascuno di essi ha 1 GB di memoria, puoi avviare dieci pod \u2014 alla fine, ogni nodo avr\u00e0 0,25 GB di memoria inutilizzata.<\/p>\n

Ci\u00f2 significa che il 25% della memoria dell'intero cluster \u00e8 sprecato.<\/p>\n

Su un grande nodo con 10 GB di memoria, puoi eseguire 13 di questi moduli, rimanendo con un solo frammento inutilizzato di 0,25 GB.<\/p>\n

In questo caso, solo il 2,5% della memoria \u00e8 sprecato.<\/p>\n

Pertanto, su nodi pi\u00f9 grandi le risorse vengono utilizzate in modo pi\u00f9 efficiente.<\/p>\n

Diversi nodi grandi o molti piccoli?<\/h2>\n

\nQuindi, cosa \u00e8 meglio: diversi nodi grandi nel cluster o molti piccoli? Come sempre, non c'\u00e8 una risposta univoca. Molto dipende dal tipo di applicazione.<\/p>\n

Ad esempio, se l'applicazione richiede 10 GB di memoria, la scelta a favore dei nodi grandi \u00e8 evidente. Ma se l'applicazione richiede una replica dieci volte per alta disponibilit\u00e0, probabilmente non vale la pena rischiare di posizionare le repliche su soli due nodi: nel cluster devono esserci almeno dieci nodi.<\/p>\n

In situazioni intermedie, fai la scelta in base ai vantaggi e agli svantaggi di ciascuna opzione. \u00c8 possibile che alcuni argomenti siano pi\u00f9 rilevanti per la tua situazione rispetto ad altri.<\/p>\n

Non \u00e8 affatto necessario che tutti i nodi siano della stessa dimensione. Nulla ti impedisce prima di sperimentare con nodi di dimensioni identiche e poi di aggiungere nodi di dimensioni diverse, combinandoli in un cluster. I nodi di lavoro di un cluster Kubernetes possono essere completamente eterogenei. Quindi, puoi provare a mescolare i vantaggi di entrambi gli approcci.<\/p>\n

Non esiste una ricetta unica, e ogni situazione ha le sue sfumature. Solo il contesto di produzione riveler\u00e0 la verit\u00e0.<\/p>\n

Traduzione a cura del team della piattaforma cloud Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Ulteriori informazioni su Kubernetes: 25 strumenti utili per la gestione e il deployment di cluster<\/a><\/noindex>.<\/p>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes \u043c\u043e\u0433\u0443\u0442 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441\u044b: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u0443\u0437\u043b\u043e\u0432 \u0438 \u043a\u0430\u043a\u043e\u0433\u043e \u0442\u0438\u043f\u0430? \u0427\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 on-premise: \u043a\u0443\u043f\u0438\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0449\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438\u043b\u0438 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u043e\u043a \u0441\u0442\u0430\u0440\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u0432\u0430\u0448\u0435\u043c \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0435? \u0410 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435 \u043b\u0443\u0447\u0448\u0435 \u0432\u0437\u044f\u0442\u044c \u0432\u043e\u0441\u0435\u043c\u044c \u043e\u0434\u043d\u043e\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043b\u0438 \u0434\u0432\u0430 \u0447\u0435\u0442\u044b\u0440\u0435\u0445\u044a\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u0430? \u041e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u044d\u0442\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u2014 \u0432 \u0441\u0442\u0430\u0442\u044c\u0435 \u0414\u0430\u043d\u0438\u044d\u043b\u044f \u0412\u0430\u0439\u0431\u0435\u043b\u044f, \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430 \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044f \u043e\u0431\u0443\u0447\u0430\u044e\u0449\u0435\u0433\u043e […]<\/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-56259","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nodi di lavoro Kubernetes: tanti piccoli o pochi grandi? | ProHoster","description":"Quando si crea un cluster Kubernetes, possono sorgere domande: quanti nodi di lavoro configurare e di che tipo? \u00c8 meglio per un cluster on-premise acquistare alcuni server potenti o sfruttare una dozzina di vecchie macchine nel proprio data center? E nel cloud, \u00e8 meglio optare per otto istanze a un core o due a quattro core? Le risposte a queste domande si trovano nell'articolo di Daniel Weibler, ingegnere software e docente.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","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\u0420\u0430\u0431\u043e\u0447\u0438\u0435 \u0443\u0437\u043b\u044b Kubernetes: \u043c\u043d\u043e\u0433\u043e \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445 \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u043e\u043b\u044c\u0448\u0438\u0445? | ProHoster","og:description":"\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes \u043c\u043e\u0433\u0443\u0442 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441\u044b: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u0443\u0437\u043b\u043e\u0432 \u0438 \u043a\u0430\u043a\u043e\u0433\u043e \u0442\u0438\u043f\u0430? \u0427\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 on-premise: \u043a\u0443\u043f\u0438\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0449\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438\u043b\u0438 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u043e\u043a \u0441\u0442\u0430\u0440\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u0432\u0430\u0448\u0435\u043c \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0435? \u0410 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435 \u043b\u0443\u0447\u0448\u0435 \u0432\u0437\u044f\u0442\u044c \u0432\u043e\u0441\u0435\u043c\u044c \u043e\u0434\u043d\u043e\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043b\u0438 \u0434\u0432\u0430 \u0447\u0435\u0442\u044b\u0440\u0435\u0445\u044a\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u0430? \u041e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u044d\u0442\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u2014 \u0432 \u0441\u0442\u0430\u0442\u044c\u0435 \u0414\u0430\u043d\u0438\u044d\u043b\u044f \u0412\u0430\u0439\u0431\u0435\u043b\u044f, \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430 \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044f \u043e\u0431\u0443\u0447\u0430\u044e\u0449\u0435\u0433\u043e","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","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-02-07T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56259","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:28:23","updated":"2022-10-03 08:08:38"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/56259","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=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}