{"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 lavorativi di 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 lavorativi configurare e di che tipo? Cosa \u00e8 meglio per un cluster on-premise: acquistare alcuni server potenti o utilizzare una dozzina di vecchie macchine nel tuo data center? E nel cloud \u00e8 meglio optare per otto istanze a un nucleo o due a quattro nuclei? <\/p>\n

Le risposte a queste domande sono nell'articolo di Daniel Weibel, ingegnere software e docente del progetto di formazione 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 visto come un grande \"super nodo\". La sua potenza computazionale totale \u00e8 la somma delle potenze di tutti i nodi componenti. <\/p>\n

Ci sono diversi modi per raggiungere la capacit\u00e0 target desiderata del cluster. Ad esempio, abbiamo bisogno di un cluster con una capacit\u00e0 totale di 8 core CPU e 32 GB di RAM, perch\u00e9 la suite di applicazioni richiede tale quantit\u00e0 di risorse. Possiamo quindi installare due nodi da 16 GB di memoria o quattro nodi da 8 GB di memoria, due processori a quattro nuclei o quattro a due nuclei.<\/p>\n

Questi sono solo due modi possibili per creare un cluster:<\/p>\n

\"Nodi
\nEntrambe le opzioni forniscono 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

Quale opzione \u00e8 migliore?<\/h3>\n

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

Pochi nodi grandi<\/p>\n

Molti nodi piccoli<\/p>\n

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

Scalabilit\u00e0 automatica fluida<\/p>\n

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

Il prezzo \u00e8 poco diverso (nel cloud) <\/p>\n

Possono essere eseguite applicazioni assetate di risorse <\/p>\n

Replica completa<\/p>\n

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

Nota che parliamo solo dei nodi lavorativi. La scelta del numero e della dimensione dei nodi master \u00e8 un argomento completamente diverso.<\/p>\n

Dunque, esaminiamo pi\u00f9 dettagliatamente ogni punto della tabella.<\/p>\n

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

\nL'opzione pi\u00f9 estrema \u00e8 un nodo lavorativo per tutta la capacit\u00e0 del cluster. Nell'esempio precedente, sarebbe un nodo lavorativo 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 facile gestire pi\u00f9 macchine rispetto a un'intera flotta. \u00c8 pi\u00f9 veloce applicare aggiornamenti e correzioni, pi\u00f9 semplice sincronizzare. Anche il numero di guasti in cifre assolute \u00e8 inferiore.<\/p>\n

Si noti 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. L'amministrazione \u00e8 gestita dal fornitore di servizi cloud. Pertanto, gestire dieci nodi in cloud non \u00e8 particolarmente diverso dal gestire un solo nodo.<\/p>\n

Il routing del traffico e il bilanciamento del carico tra i pod nel cloud viene eseguito automaticamente<\/a><\/noindex>: il traffico proveniente da Internet viene indirizzato al bilanciatore di carico principale, che reindirizza il traffico alla porta di uno dei nodi (il servizio NodePort espone una porta nell'intervallo 30000-32767 su ciascun nodo del cluster). Le regole stabilite da kube-proxy reindirizzano il traffico dal nodo al pod. Ecco come appare per dieci pod su due nodi:<\/p>\n

\"Nodi
\nVantaggio n. 2. Meno costi per nodo<\/b>
\nUna macchina potente \u00e8 pi\u00f9 costosa, ma l'aumento del prezzo non \u00e8 necessariamente lineare. In altre parole, un server con dieci core e 10 GB di RAM \u00e8 generalmente pi\u00f9 economico di dieci server mononucleari con la stessa memoria.<\/p>\n

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

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

Vantaggio n. 3. \u00c8 possibile eseguire applicazioni ad alta intensit\u00e0 di risorse<\/b>
\nAlcune applicazioni richiedono server potenti nel cluster. Ad esempio, se un sistema di machine learning richiede 8 GB di memoria, non sar\u00e0 possibile eseguirlo su nodi da 1 GB, ma solo in presenza di almeno un nodo di lavoro grande.<\/p>\n

Contro <\/h3>\n

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

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

Il motivo \u00e8 che ogni modulo introduce alcune sovraccarichi nell'ambiente di esecuzione del contenitore (ad esempio, Docker), cos\u00ec come kubelet e cAdvisor.<\/p>\n

Ad esempio, kubelet controlla regolarmente la salute di tutti i contenitori su un nodo: pi\u00f9 contenitori ci sono, pi\u00f9 lavoro ha kubelet.<\/p>\n

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

Se il numero di moduli aumenta, questo pu\u00f2 rallentare il sistema e persino minare la sua 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 contenitori del nodo richiedono troppo tempo.
\nPer questa ragione, Kubernetes si raccomanda di non collocare pi\u00f9 di 110 pod su un nodo<\/a><\/noindex>. A seconda delle prestazioni del nodo, \u00e8 possibile eseguire pi\u00f9 pod per nodo, ma \u00e8 difficile prevedere se si verificheranno problemi o se tutto funzioner\u00e0 bene. \u00c8 consigliabile testare in anticipo il funzionamento. <\/p>\n

Svantaggio n. 2. Limitazione alla replica<\/b>
\nUn numero troppo ridotto di nodi limita l'efficacia del grado di replicazione delle applicazioni. Ad esempio, se hai un'applicazione ad alta disponibilit\u00e0 composta da cinque repliche, ma solo due nodi, il grado effettivo di replicazione dell'applicazione si riduce a due.<\/p>\n

Cinque repliche possono essere distribuite solo su due nodi e, se uno di essi si guasta, vengono immediatamente messe fuori uso pi\u00f9 repliche.<\/p>\n

Se hai cinque nodi o pi\u00f9, ogni 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. Conseguenze peggiori del guasto<\/b>
\nCon un numero ridotto di nodi, ogni guasto comporta conseguenze pi\u00f9 gravi. Ad esempio, se hai solo due nodi e uno di essi si guasta, sparisce immediatamente met\u00e0 dei tuoi moduli.<\/p>\n

Certo, Kubernetes trasferir\u00e0 il carico di lavoro dal nodo guasto ad altri. Ma se sono pochi, potrebbe non esserci abbastanza capacit\u00e0 libera. Di conseguenza, parte delle tue applicazioni saranno inaccessibili finch\u00e9 non riavvii il nodo guasto.<\/p>\n

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

Svantaggio n. 4. Maggiori passaggi per l'autoscaling<\/b>
\nIn Kubernetes, esiste un sistema di autoscalamento del cluster per l'infrastruttura cloud, che consente di aggiungere o rimuovere automaticamente i nodi in base alle attuali esigenze. Con nodi pi\u00f9 grandi, l'autoscalamento diventa pi\u00f9 brusco e goffo. Ad esempio, su due nodi, l'aggiunta di un nodo supplementare aumenter\u00e0 la capacit\u00e0 del cluster immediatamente del 50%. E dovrete pagare per queste risorse, anche se non vi servono.<\/p>\n

Pertanto, se prevedete di utilizzare l'autoscalamento del cluster, pi\u00f9 piccoli sono i nodi, pi\u00f9 flessibile ed economico sar\u00e0 lo scaling che otterrete.<\/p>\n

Ora consideriamo i vantaggi e gli svantaggi di avere un gran numero di piccoli nodi.<\/p>\n

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

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

Pro<\/h3>\n

\nVantaggio n. 1. Minori conseguenze in caso di guasto<\/b>
\nPi\u00f9 nodi ci sono, meno pod ci sono su ciascun nodo. Ad esempio, se hai cento moduli distribuiti su dieci nodi, in media ci saranno dieci moduli per nodo.<\/p>\n

Pertanto, se uno dei nodi si guasta, perdete 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, sui nodi rimanenti, probabilmente ci saranno risorse libere sufficienti per il carico di lavoro del nodo guasto, quindi Kubernetes pu\u00f2 riprogrammare liberamente i pod e le tue applicazioni torneranno relativamente rapidamente in uno stato funzionante.<\/p>\n

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

Contro <\/h3>\n

\nSvantaggio n. 1. Gestione pi\u00f9 difficile<\/b>
\nGestire un gran numero di nodi \u00e8 pi\u00f9 complicato. Ad esempio, ogni nodo di Kubernetes deve interagire con tutti gli altri, il che significa che il numero di collegamenti cresce in modo quadratico e tutti questi collegamenti devono essere monitorati.<\/p>\n

Il controller dei nodi nel gestore di controller di Kubernetes controlla regolarmente tutti i nodi nel cluster per verificarne la funzionalit\u00e0: 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 chiama watcher<\/a><\/noindex> per etcd (tramite API), a cui 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 gran numero di nodi di lavoro, \u00e8 consigliabile scegliere nodi principali pi\u00f9 performanti. Ad esempio, kube-up installa automaticamente<\/a><\/noindex> la dimensione corretta della VM per il nodo principale in base al numero di nodi di lavoro. Cio\u00e8, pi\u00f9 nodi di lavoro ci sono, pi\u00f9 performanti devono essere i nodi principali. <\/p>\n

Per affrontare questi problemi specifici, ci sono sviluppi speciali, come Virtual Kubelet<\/a><\/noindex>. Questo sistema consente di aggirare le limitazioni e costruire cluster con un numero enorme di nodi di lavoro.<\/p>\n

Problema n. 2. Maggiore overhead<\/b>
\nSu ogni nodo di lavoro, Kubernetes avvia un insieme di demoni di sistema \u2013 tra questi ci sono l'ambiente di esecuzione dei container (ad es. Docker), kube-proxy e kubelet, compreso cAdvisor. Insieme, consumano una certa quantit\u00e0 fissa di risorse.<\/p>\n

Se hai molti nodi piccoli, la proporzione di questi overhead su ogni nodo \u00e8 maggiore. Ad esempio, immagina che tutti i demoni di sistema di un nodo utilizzino insieme 0,1 core di CPU e 0,1 GB di RAM. Se hai un nodo da dieci core con 10 GB di RAM, i demoni consumano l'1% della capacit\u00e0 del cluster. D'altra parte, su dieci nodi a un core ciascuno con 1 GB di RAM, i demoni porteranno via il 10% della capacit\u00e0 del cluster.<\/p>\n

Quindi, meno nodi hai, pi\u00f9 efficacemente viene utilizzata l'infrastruttura.<\/p>\n

Problema n. 3. Utilizzo inefficiente delle risorse<\/b>
\nSu nodi piccoli pu\u00f2 verificarsi la situazione in cui i frammenti rimanenti di risorse sono troppo piccoli per assegnare loro 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 ha 1 GB di memoria, puoi avviare dieci pod \u2014 alla fine, ciascun nodo avr\u00e0 0,25 GB di memoria inutilizzata.<\/p>\n

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

Su un nodo grande con 10 GB di RAM puoi avviare 13 di questi moduli \u2013 e rimarr\u00e0 solo un frammento non utilizzato di 0,25 GB.<\/p>\n

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

Cos\u00ec, nelle grandi nodi si ottimizzano meglio le risorse.<\/p>\n

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

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

Ad esempio, se un'applicazione richiede 10 GB di memoria, la scelta dei grandi nodi \u00e8 ovvia. Ma se l'applicazione richiede una replica dieci volte per alta disponibilit\u00e0, \u00e8 poco saggio rischiare posizionando le repliche su soli due nodi: ci devono essere almeno dieci nodi nel cluster.<\/p>\n

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

Non \u00e8 affatto necessario avere tutti i nodi della stessa dimensione. Niente ti impedisce di sperimentare inizialmente con nodi della stessa dimensione e poi aggiungere nodi di dimensioni diverse, combinandoli nel cluster. I nodi di lavoro di un cluster Kubernetes possono essere completamente eterogenei. Quindi puoi provare a combinare i vantaggi di entrambi gli approcci.<\/p>\n

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

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

Ancora su Kubernetes: 25 strumenti utili per la gestione e lo sviluppo 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: molti piccoli o pochi grandi? | ProHoster","description":"Durante la creazione di un cluster.","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.","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","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\/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}]}}