{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"Le migliori pratiche di Kubernetes. Creazione di piccoli contenitori","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Le
\n
\nIl primo passo per il deployment su Kubernetes \u00e8 posizionare la tua applicazione in un contenitore. In questa serie, esamineremo come creare un'immagine di un piccolo e sicuro contenitore.
\nCon Docker, creare immagini di contenitori non \u00e8 mai stato cos\u00ec semplice. Specifica l'immagine di base, aggiungi le tue modifiche e crea il contenitore.<\/p>\n

\"Le
\n
\nAnche se questa tecnica \u00e8 perfetta per iniziare, l'uso delle immagini di base predefinite pu\u00f2 portare a operazioni insicure con immagini grandi e piene di vulnerabilit\u00e0.<\/a><\/noindex><\/p>\n

Inoltre, la maggior parte delle immagini Docker utilizza Debian o Ubuntu come immagine di base e, sebbene ci\u00f2 garantisca grande compatibilit\u00e0 e semplice adattamento (un file Docker richiede solo due righe di codice), le immagini di base possono aggiungere centinaia di megabyte di sovraccarico al tuo contenitore. Ad esempio, un semplice file di un'applicazione Node.js 'hello-world' occupa circa 700 megabyte, mentre la dimensione effettiva della tua applicazione \u00e8 solo di pochi megabyte.<\/p>\n

\"Le
\n
\nPertanto, tutto questo carico aggiuntivo rappresenta un'eccellente perdita di spazio digitale e un perfetto nascondiglio per vulnerabilit\u00e0 e errori nel sistema di sicurezza. Dunque, vediamo due modi per ridurre le dimensioni dell'immagine del contenitore. <\/p>\n

Il primo modo riguarda l'uso di immagini di base di piccole dimensioni, il secondo \u00e8 l'uso del pattern progettuale Builder Pattern. L'utilizzo di immagini di base pi\u00f9 piccole \u00e8 probabilmente il metodo pi\u00f9 semplice per ridurre le dimensioni del tuo contenitore. \u00c8 molto probabile che il linguaggio o lo stack che stai utilizzando fornisca un'immagine dell'applicazione originale significativamente pi\u00f9 piccola rispetto all'immagine predefinita. Diamo un'occhiata al nostro contenitore node.js. <\/p>\n

\"Le
\n
\nPer impostazione predefinita, la dimensione dell'immagine di base node:8 in Docker \u00e8 di 670 MB, mentre la dimensione di node:8-alpine \u00e8 di solo 65 MB, ossia dieci volte inferiore. Utilizzando un'immagine di base pi\u00f9 piccola, come Alpine, ridurrai notevolmente la dimensione del tuo contenitore. Alpine \u00e8 una distribuzione Linux piccola e leggera, molto popolare tra gli utenti di Docker perch\u00e9 \u00e8 compatibile con molte applicazioni, mantenendo al contempo dimensioni ridotte. A differenza dell'immagine Docker standard \"node\", \"node:alpine\" rimuove numerosi file e programmi di servizio, mantenendo solo quelli necessari per eseguire la tua applicazione.<\/p>\n

Per passare a un'immagine di base pi\u00f9 piccola, basta aggiornare il file Docker per iniziare a lavorare con la nuova immagine di base:<\/p>\n

\"Le
\n
\nOra, a differenza della vecchia immagine onbuild, devi copiare il tuo codice nel contenitore e installare le dipendenze. Nel nuovo file Docker, il contenitore inizia con l'immagine node:alpine, quindi crea una directory per il codice, installa le dipendenze utilizzando il gestore di pacchetti NPM e, infine, esegue server.js.<\/p>\n

\"Le
\n
\nCon questo aggiornamento, si ottiene un container di dimensioni dieci volte inferiori. Se il tuo linguaggio di programmazione o stack non offre funzioni per ridurre l'immagine di base, utilizza Alpine Linux. Questo ti dar\u00e0 anche la possibilit\u00e0 di gestire completamente il contenuto del container. L'utilizzo di immagini base di piccole dimensioni \u00e8 un ottimo modo per creare rapidamente piccoli container. Ma si pu\u00f2 ottenere un ulteriore riduzione utilizzando il Builder Pattern.<\/p>\n

\"Le
\n
\nNei linguaggi interpretati, il codice sorgente viene prima passato all'interprete e poi eseguito direttamente. Nei linguaggi compilati, il codice sorgente viene innanzitutto trasformato in codice compilato. Durante questo processo, la compilazione utilizza spesso strumenti che in realt\u00e0 non sono necessari per eseguire il codice. Ci\u00f2 significa che puoi rimuovere completamente questi strumenti dal container finale. Per questo, puoi utilizzare il Builder Pattern.<\/p>\n

\"Le
\n
\nIl codice viene creato nel primo container e compilato. Successivamente, il codice compilato viene impacchettato nel container finale senza compilatori e strumenti necessari per compilare quel codice. Analizziamo questo processo con un'applicazione Go. Prima di tutto, passeremo dall'immagine onbuild a Alpine Linux.<\/p>\n

\"Le
\n
\nNel nuovo file Docker, il container inizia con l'immagine golang:alpine. Quindi crea una directory per il codice, copia il codice sorgente, compila questo codice e avvia l'applicazione. Questo container \u00e8 molto pi\u00f9 piccolo rispetto al container onbuild, ma contiene ancora il compilatore e altri strumenti Go che in realt\u00e0 non ci servono. Pertanto, estraiamo semplicemente il programma compilato e mettiamolo nel nostro container.<\/p>\n

\"Le
\n
\nPotresti notare qualcosa di strano in questo file Docker: contiene due righe FROM. La prima sezione, composta da 4 righe, appare identica al precedente file Docker, tranne per il fatto che utilizza la parola chiave AS per dare un nome a questo passaggio. Nella sezione successiva c'\u00e8 una nuova riga FROM che consente di avviare una nuova immagine, utilizzando Raw alpine come base invece dell'immagine golang:alpine.<\/p>\n

Raw Alpine Linux non ha certificati SSL installati, il che porter\u00e0 al fallimento della maggior parte delle chiamate API tramite HTTPS. Quindi, procediamo ad installare alcuni certificati root CA.<\/p>\n

E ora la parte pi\u00f9 interessante: per copiare il codice compilato dal primo contenitore al secondo, puoi semplicemente usare il comando COPY situato nella 5\u00aa riga della seconda sezione. Questo copier\u00e0 solo un file dell'applicazione, senza toccare gli strumenti ausiliari di Go. Il nuovo file Docker multi-stadio avr\u00e0 un'immagine del contenitore di soli 12 megabyte, rispetto ai 700 megabyte dell'immagine di origine, il che fa una grande differenza!
\nPertanto, utilizzare immagini di base di dimensioni ridotte e il Builder Pattern \u00e8 un ottimo modo per creare container di dimensioni significativamente inferiori senza un grande volume di lavoro.
\n\u00c8 possibile che, a seconda dello stack applicativo, ci siano ulteriori modi per ridurre le dimensioni dell'immagine e del container, ma \u00e8 davvero vero che container pi\u00f9 piccoli offrono un vantaggio misurabile? Esaminiamo due aspetti in cui i container piccoli sono estremamente efficaci: prestazioni e sicurezza.<\/p>\n

Per valutare l'aumento delle prestazioni, consideriamo la durata del processo di creazione del container, il suo push nel registro e il successivo pull da esso. \u00c8 evidente che un container di dimensioni minori ha un vantaggio indiscutibile rispetto a uno di dimensioni maggiori.<\/p>\n

\"Le
\n
\nDocker memorizzer\u00e0 i livelli, quindi le build successive verranno eseguite molto rapidamente. Tuttavia, in molti sistemi CI utilizzati per il build e il test dei contenitori, i livelli non vengono memorizzati, quindi c'\u00e8 un notevole risparmio di tempo. Come si pu\u00f2 vedere, il tempo di costruzione di un contenitore di grandi dimensioni, a seconda della potenza della tua macchina, varia da 34 a 54 secondi, mentre utilizzando un contenitore ridotto attraverso il Builder Pattern, si va da 23 a 28 secondi. Per operazioni di questo tipo, il guadagno di prestazioni sar\u00e0 del 40-50%. Quindi, pensa solo a quante volte crei e testi il tuo codice.<\/p>\n

Dopo che il contenitore \u00e8 stato creato, devi caricare la sua immagine (push container image) nel registro dei contenitori per poterla utilizzare nel tuo cluster Kubernetes. Ti consiglio di utilizzare il registro dei contenitori Google.<\/p>\n

\"Le
\n
\nUtilizzando Google Container Registry (GCR), paghi solo per lo storage e il traffico \u00abgrezzi\u00bb, senza costi aggiuntivi per la gestione dei container. \u00c8 una soluzione riservata, sicura e molto veloce. GCR utilizza molte tecniche per accelerare l'operazione di pull. Come puoi vedere, l'inserimento dell'immagine del container Docker Container Image usando go:onbuild, a seconda delle prestazioni del computer, richieder\u00e0 da 15 a 48 secondi, mentre la stessa operazione con un container pi\u00f9 piccolo richieder\u00e0 da 14 a 16 secondi, con un incremento della velocit\u00e0 delle operazioni che arriva fino a 3 volte per macchine meno performanti. Per macchine pi\u00f9 grandi, i tempi sono simili, poich\u00e9 GCR utilizza una cache globale per la base di immagini condivisa, quindi non \u00e8 necessario caricarle affatto. Nei computer a bassa potenza, la CPU \u00e8 il collo di bottiglia, quindi il vantaggio dell'uso di container pi\u00f9 piccoli \u00e8 molto pi\u00f9 evidente.<\/p>\n

Se utilizzi GCR, ti consiglio vivamente di impiegare Google Container Builder (GCB) come parte del tuo sistema di build.<\/p>\n

\"Le
\n
\nCome potete vedere, il suo utilizzo consente di ottenere risultati significativamente migliori nella riduzione della durata dell'operazione Build+Push, rispetto anche a una macchina performante: in questo caso, il processo di costruzione e invio dei contenitori si accelera quasi di due volte. Inoltre, ogni giorno ricevete 120 minuti di compilazione gratuita, che soddisfa la maggior parte delle esigenze di creazione dei contenitori. <\/p>\n

La metrica di performance pi\u00f9 importante \u00e8 la velocit\u00e0 di estrazione o download dei contenitori Pull. Se non vi preoccupa molto il tempo impiegato per l'operazione push, la durata del processo pull influisce seriamente sulle prestazioni complessive del sistema. Supponiamo di avere un cluster di tre nodi e che uno di essi fallisca. Se utilizzate un sistema di gestione come Google Kubernetes Engine, esso sostituir\u00e0 automaticamente il nodo non funzionante con uno nuovo. Tuttavia, questo nuovo nodo sar\u00e0 completamente vuoto e dovrete trasferire tutti i vostri contenitori su di esso affinch\u00e9 inizi a funzionare. Se l'operazione pull richiede troppo tempo, il vostro cluster funzioner\u00e0 con prestazioni ridotte per tutto quel tempo.<\/p>\n

Ci sono molte situazioni in cui ci\u00f2 pu\u00f2 verificarsi: l'aggiunta di un nuovo nodo al cluster, l'aggiornamento dei nodi o persino il passaggio a un nuovo container per il deployment. Pertanto, minimizzare il tempo di estrazione del pull diventa un fattore chiave. \u00c8 indiscutibile che un container di piccole dimensioni si scarica molto pi\u00f9 velocemente di uno grande. Se utilizzi pi\u00f9 container in un cluster Kubernetes, il risparmio di tempo pu\u00f2 essere molto significativo.<\/p>\n

\"Le
\n
\nGuarda il confronto fornito: l'operazione di pull con container piccoli richiede da 4 a 9 volte meno tempo, a seconda della potenza della macchina, rispetto alla stessa operazione utilizzando go:onbuild. L'uso di immagini di base comuni di piccole dimensioni accelera notevolmente il tempo e la velocit\u00e0 con cui nuovi nodi Kubernetes possono essere implementati e andare online.<\/p>\n

Affrontiamo la questione della sicurezza. Si ritiene che i container pi\u00f9 piccoli siano molto pi\u00f9 sicuri rispetto a quelli grandi, poich\u00e9 hanno una superficie di attacco minore. \u00c8 davvero cos\u00ec? Una delle funzionalit\u00e0 pi\u00f9 utili di Google Container Registry \u00e8 la possibilit\u00e0 di scansionare automaticamente i tuoi container per vulnerabilit\u00e0. Alcuni mesi fa ho creato container sia onbuild che multilivello, quindi vediamo se ci sono punti vulnerabili. <\/p>\n

\"Le
\n
\nIl risultato \u00e8 straordinario: nel piccolo container sono state trovate solo 3 vulnerabilit\u00e0 medie, mentre nel grande ce ne sono 16 critiche e 376 altre vulnerabilit\u00e0. Esaminando il contenuto del grande container, si pu\u00f2 vedere che la maggior parte dei problemi di sicurezza non ha nulla a che fare con la nostra applicazione, ma \u00e8 legata a programmi che non utilizziamo affatto. Pertanto, quando si parla di una grande superficie di attacco, si intende proprio questo. <\/p>\n

\"Le
\n
\nLa conclusione \u00e8 chiara: crea container piccoli, poich\u00e9 offrono reali vantaggi in termini di prestazioni e sicurezza per il tuo sistema. <\/p>\n

Le migliori pratiche di Kubernetes. Organizzazione di Kubernetes con gli spazi dei nomi<\/a><\/noindex><\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Un po' di pubblicit\u00e0 \ud83d\ude42<\/h3>\n

\nGrazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere pi\u00f9 contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, VPS cloud per sviluppatori a partire da $4,99<\/a><\/noindex>, un'alternativa unica ai server entry-level, che abbiamo creato per te:<\/b> Tutta la verit\u00e0 su VPS (KVM) E5-2697 v3 (6 Core) 10GB DDR4 480GB SSD 1Gbps a partire da $19. Come dividere il server correttamente?<\/a><\/noindex> (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).<\/p>\n

Dell R730xd a met\u00e0 prezzo nel data center Equinix Tier IV ad Amsterdam?<\/b> Solo da noi 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB a partire da $199<\/a><\/noindex> nei Paesi Bassi! Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 a partire da $99!<\/b><\/b> Scopri di pi\u00f9 su Come costruire un'infrastruttura di classe enterprise con server Dell R730xd E5-2650 v4 dal costo di 9000 euro a prezzi stracciati?<\/a><\/noindex>
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Le migliori pratiche di Kubernetes. Creazione di contenitori piccoli | ProHoster","description":"Il primo passo per il deployment in Kubernetes \u00e8 l'hosting della tua applicazione in un contenitore. In questa serie, esploreremo come creare un'immagine di un contenitore piccolo e sicuro. Con Docker, la creazione di immagini di contenitori non \u00e8 mai stata cos\u00ec semplice. Specifica un'immagine di base, aggiungi le tue modifiche e crea il contenitore. Sebbene questo approccio sia ideale per iniziare","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 | ProHoster","og:description":"\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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-05-20T11:42:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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 15:41:28","updated":"2022-09-28 11:52:01"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82244","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=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}