{"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\/da\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Arbejdsknuder i Kubernetes: mange sm\u00e5 eller f\u00e5 store?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Arbejdsknuder
\nN\u00e5r man opretter et Kubernetes-kluster, kan der opst\u00e5 sp\u00f8rgsm\u00e5l: hvor mange arbejdsnoder skal man konfigurere, og hvilken type? Hvad er bedst for et on-premise kluster: at k\u00f8be flere kraftige servere eller at bruge et dusin gamle maskiner i dit datacenter? Og i skyen er det bedre at tage otte enkeltkerne- eller to firekerne-instanser? <\/p>\n

Svarene p\u00e5 disse sp\u00f8rgsm\u00e5l findes i artiklen af Daniel Weibel, ingeni\u00f8r og underviser i det l\u00e6ringsprojekt, der hedder Learnk8s<\/a><\/noindex> i overs\u00e6ttelse af teamet Kubernetes aaS fra Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Klusterkapacitet<\/h2>\n

\nGenerelt kan et Kubernetes-kluster betragtes som en stor \"supernode\". Den samlede beregningskraft er summen af alle de individuelle noders kapaciteter. <\/p>\n

Der er flere m\u00e5der at opn\u00e5 den \u00f8nskede m\u00e5lkapacitet for klusteret. For eksempel, hvis vi har brug for et kluster med en samlet kapacitet p\u00e5 8 CPU-kerner og 32 GB RAM, fordi s\u00e6t af applikationer kr\u00e6ver s\u00e5 mange ressourcer. S\u00e5 kan vi installere to noder med 16 GB RAM eller fire noder med 8 GB RAM, to firekerne-processorer eller fire to-kerne-processorer.<\/p>\n

Her er kun to mulige m\u00e5der at oprette et kluster p\u00e5:<\/p>\n

\"Arbejdsknuder
\nBegge muligheder giver et kluster med samme kapacitet, men i konfigurationen nedenfor er der fire mindre noder, mens konfigurationen ovenfor har to st\u00f8rre. <\/p>\n

Hvilket valg er bedre?<\/h3>\n

\nFor at besvare dette sp\u00f8rgsm\u00e5l, lad os se p\u00e5 fordelene ved begge muligheder. Vi har opsummeret dem i en tabel.<\/p>\n

Flere store noder<\/p>\n

Mange sm\u00e5 noder<\/p>\n

Lettere administration af klusteret (hvis det er on-premise)<\/p>\n

Glidende automatisk skalering<\/p>\n

Billigere (hvis on-premise) <\/p>\n

Pris forskellen er lille (i skyen) <\/p>\n

Kan k\u00f8re ressourcekr\u00e6vende applikationer <\/p>\n

Fuldt replica<\/p>\n

Ressourcerne bruges mere effektivt (mindre overhead til systemd\u00e6moner)
\nH\u00f8jere tilg\u00e6ngelighed af klusteret<\/p>\n

Bem\u00e6rk, at vi kun taler om arbejdsnoder. Valget af antal og st\u00f8rrelse af master-noder er et helt andet emne.<\/p>\n

Lad os derfor se n\u00e6rmere p\u00e5 hvert punkt fra tabellen.<\/p>\n

F\u00f8rste mulighed: flere store noder<\/h2>\n

\nDen mest ekstreme mulighed er \u00e9n arbejdsnode, der d\u00e6kker hele kapaciteten af klusteret. I eksemplet ovenfor ville det v\u00e6re \u00e9n arbejdsnode med 16 CPU-kerner og 16 GB RAM.<\/p>\n

Fordele <\/h3>\n

\nFordel #1. Lettere administration<\/b>
\nDet er lettere at styre flere maskiner end et helt datacenter. Hurtigere at installere opdateringer og rettelser, nemmere at synkronisere. Antallet af fejl i absolutte tal er ogs\u00e5 mindre.<\/p>\n

Bem\u00e6rk, at alt det ovenst\u00e5ende vedr\u00f8rer dit eget udstyr, dine egne servere og ikke cloud-instanser.<\/p><\/blockquote>\n

\nI skyen er situationen en anden. Her h\u00e5ndterer cloud-leverand\u00f8ren administrationen. Derfor adskiller styringen af ti noder i skyen sig ikke v\u00e6sentligt fra styringen af \u00e9n node.<\/p>\n

Routing af trafik og belastningsfordeling mellem pods i skyen sker automatisk<\/a><\/noindex>: den indkommende trafik fra internettet dirigeres til den prim\u00e6re load balancer, som sender trafikken til porten p\u00e5 en af noderne (NodePort-tjenesten eksponerer en port i intervallet 30000-32767 p\u00e5 hver node i klyngen). De regler, der er fastsat af kube-proxy, omdirigerer trafikken fra noden til pod'en. S\u00e5dan ser det ud for ti pods p\u00e5 to noder:<\/p>\n

\"Arbejdsknuder
\nFordel nr. 2. Mindre omkostninger pr. node<\/b>
\nEn kraftig maskine er dyrere, men prisstigningen er ikke n\u00f8dvendigvis line\u00e6r. Med andre ord er \u00e9n ti-kerne server med 10 GB hukommelse normalt billigere end ti enkerne servere med den samme m\u00e6ngde hukommelse.<\/p>\n

Men bem\u00e6rk, at denne regel normalt ikke g\u00e6lder for cloud-tjenester. I de nuv\u00e6rende priss\u00e6tningsmodeller stiger priserne line\u00e6rt med kapaciteten hos alle de store cloud-leverand\u00f8rer.<\/p><\/blockquote>\n

\nDerfor kan man normalt ikke spare penge p\u00e5 mere kraftfulde servere i skyen.<\/p>\n

Fordel nr. 3. Ressourcetunge applikationer kan k\u00f8res<\/b>
\nNogle applikationer kr\u00e6ver kraftfulde servere i klyngen. For eksempel, hvis et maskinl\u00e6ringssystem kr\u00e6ver 8 GB hukommelse, kan du ikke k\u00f8re det p\u00e5 noder med 1 GB, men kun hvis der er mindst \u00e9n stor arbejdsnode.<\/p>\n

Ulemper <\/h3>\n

\nMinus nummer 1. Mange pods per node<\/b>
\nHvis den samme opgave udf\u00f8res p\u00e5 f\u00e6rre noder, vil der naturligvis v\u00e6re flere pods p\u00e5 hver af dem.<\/p>\n

Det kan blive et problem.<\/p>\n

\u00c5rsagen er, at hver modul bidrager med nogle overhead til containerens runtime-milj\u00f8 (f.eks. Docker) samt kubelet og cAdvisor.<\/p>\n

For eksempel unders\u00f8ger kubelet regelm\u00e6ssigt livsvilk\u00e5rene for alle containere p\u00e5 noden \u2013 jo flere containere, desto mere arbejde har kubelet.<\/p>\n

CAdvisor indsamler statistik om ressourceforbruget for alle containere p\u00e5 noden, og kubelet anmoder regelm\u00e6ssigt om denne information og stiller den til r\u00e5dighed via API'et. Jo flere containere, jo mere arbejde er der for b\u00e5de cAdvisor og kubelet.<\/p>\n

Hvis antallet af moduler vokser, kan det langsommeligt p\u00e5virke systemet og endda underminere dets p\u00e5lidelighed.<\/p>\n

\"Arbejdsknuder
\nI Kubernetes-repositoriet har nogle klaget<\/a><\/noindex>, over at noderne svinger mellem statusserne Ready\/NotReady, fordi kubelets regelm\u00e6ssige kontroller af alle containere p\u00e5 noden tager for lang tid.
\nAf denne grund anbefaler Kubernetes anbefaler at placere ikke flere end 110 pods per node<\/a><\/noindex>. Afh\u00e6ngigt af nodens ydelse kan du k\u00f8re flere pod'e per node, men det er sv\u00e6rt at forudsige, om der vil opst\u00e5 problemer, eller om alt vil fungere godt. Det er en god id\u00e9 at teste det p\u00e5 forh\u00e5nd. <\/p>\n

Ulempe nr. 2. Begr\u00e6nsning af replikering<\/b>
\nEt for lille antal noder begr\u00e6nser den effektive replikationsgrad af applikationer. For eksempel, hvis du har en h\u00f8jtilg\u00e6ngelighedsapplikation med fem replikaer, men kun to noder, falder den effektive replikationsgrad for applikationen til to.<\/p>\n

De fem replikaer kan kun fordeles p\u00e5 to noder, og hvis en af dem fejler, bringer det straks flere replikaer ud af drift.<\/p>\n

Hvis du har fem noder eller flere, vil hver replika k\u00f8re p\u00e5 en separat node, og en nodes fejl fjerner h\u00f8jst \u00e9n replika.<\/p>\n

P\u00e5 denne m\u00e5de kan krav til h\u00f8jtilg\u00e6ngelighed kr\u00e6ve et vist minimum antal noder i klyngen.<\/p>\n

Ulempe nr. 3. V\u00e6rre konsekvenser af fejl<\/b>
\nMed et lille antal noder b\u00e6rer hver fejl mere alvorlige konsekvenser. For eksempel, hvis du kun har to noder, og en af dem fejler, forsvinder halvdelen af dine moduler straks.<\/p>\n

Selvf\u00f8lgelig vil Kubernetes flytte belastningen fra den fejlmeldte node til andre. Men hvis der er f\u00e5, kan der mangle ledig kapacitet. Som f\u00f8lge heraf vil nogle af dine applikationer v\u00e6re utilg\u00e6ngelige, indtil du f\u00e5r den fejlmeldte node op at k\u00f8re igen.<\/p>\n

Jo flere noder, jo mindre indflydelse har hardwarefejlene.<\/p>\n

Ulempe nr. 4. St\u00f8rre skridt til automatisk skalering<\/b>
\nI Kubernetes fungerer der et system til automatisk skalering af klynger for cloudinfrastruktur, hvilket g\u00f8r det muligt automatisk at tilf\u00f8je eller fjerne noder afh\u00e6ngigt af de aktuelle behov. Med st\u00f8rre noder bliver automatisk skalering mere markant og klodset. For eksempel, ved to noder vil tilf\u00f8jelse af en ekstra node straks \u00f8ge kapaciteten af klyngen med 50%. Og du vil v\u00e6re n\u00f8dt til at betale for disse ressourcer, selvom du ikke har brug for dem.<\/p>\n

Derfor, hvis du planl\u00e6gger at bruge automatisk skalering af klynger, s\u00e5 jo mindre noderne er, desto mere fleksibel og \u00f8konomisk skalering vil du opn\u00e5.<\/p>\n

Lad os nu se p\u00e5 fordele og ulemper ved mange sm\u00e5 noder.<\/p>\n

Alternativ nummer to: mange sm\u00e5 noder<\/h2>\n

\nFordelene ved denne tilgang f\u00f8lger i bund og grund af ulemperne ved det modsatte valg med f\u00e5 store noder.<\/p>\n

Fordele<\/h3>\n

\nFordel nr. 1. Mindre konsekvenser ved nedbrud<\/b>
\nJo flere noder, jo f\u00e6rre pods p\u00e5 hver node. For eksempel, hvis du har hundrede moduler p\u00e5 ti noder, vil der i gennemsnit v\u00e6re ti moduler p\u00e5 hver node.<\/p>\n

S\u00e5ledes, hvis en af noderne fejler, mister du kun 10% af arbejdsbelastningen. Der er en chance for, at kun et lille antal replikaer bliver ber\u00f8rt, mens applikationerne generelt forbliver operationelle.<\/p>\n

Desuden vil de resterende noder sandsynligvis have tilstr\u00e6kkelige frie ressourcer til lasten fra den nedbrudte node, s\u00e5 Kubernetes frit kan omplanl\u00e6gge pods, og dine applikationer hurtigt kan komme tilbage i funktionelt stand.<\/p>\n

Fordel nr. 2. God replikation<\/b>
\nHvis der er tilstr\u00e6kkeligt med noder, kan Kubernetes-scheduler tildele forskellige noder til alle replikaer. S\u00e5ledes vil der kun blive ber\u00f8rt \u00e9n replika i tilf\u00e6lde af en nodesvigt, mens applikationen forbliver tilg\u00e6ngelig.<\/p>\n

Ulemper <\/h3>\n

\nUlempe nr. 1. Sv\u00e6rere at administrere<\/b>
\nDet er sv\u00e6rere at administrere mange noder. For eksempel skal hver Kubernetes-node interagere med alle de andre, hvilket betyder, at antallet af forbindelser vokser kvadratisk, og alle disse forbindelser skal overv\u00e5ges.<\/p>\n

Nodekontroll\u00f8ren i Kubernetes-controller-manageren gennemg\u00e5r regelm\u00e6ssigt alle noder i klyngen for at kontrollere deres tilstand \u2014 jo flere noder, desto st\u00f8rre belastning p\u00e5 kontroll\u00f8ren.<\/p>\n

Belastningen p\u00e5 etcd-databasen vokser ogs\u00e5 \u2014 hver kubelet og kube-proxy kalder watcher<\/a><\/noindex> for etcd (via API), to which etcd must relay object updates.<\/p>\n

In general, each worker node adds additional load on the system components of the master nodes.<\/p>\n

\"Arbejdsknuder
\nOfficially, Kubernetes supports clusters with up to 5000 nodes.<\/a><\/noindex>However, in practice, even 500 nodes can cause non-trivial issues.<\/a><\/noindex>.<\/p>\n

To manage a large number of worker nodes, more powerful master nodes should be chosen. For example, kube-up automatically installs<\/a><\/noindex> the correct size VM for the master node based on the number of worker nodes. That is, the more worker nodes there are, the more powerful the master nodes need to be. <\/p>\n

To address these specific issues, there are specialized developments such as Virtual Kubelet.<\/a><\/noindex>This system allows bypassing limitations and building clusters with an enormous number of worker nodes.<\/p>\n

Disadvantage #2. More overhead.<\/b>
\nOn each worker node, Kubernetes runs a set of system daemons\u2014these include the container runtime (e.g., Docker), kube-proxy, and kubelet, including cAdvisor. Together, they consume a certain fixed amount of resources.<\/p>\n

If you have many small nodes, the share of these overheads on each node is larger. For instance, imagine that all the system daemons of one node together use 0.1 CPU core and 0.1 GB of memory. If you have one ten-core node with 10 GB of memory, the daemons consume 1% of the cluster's capacity. On the other hand, on ten single-core nodes with 1 GB of memory each, the daemons would take 10% of the cluster's capacity.<\/p>\n

Thus, the fewer nodes there are, the more efficiently the infrastructure is utilized.<\/p>\n

Disadvantage #3. Inefficient resource utilization.<\/b>
\nOn small nodes, it may happen that the remaining fragments of resources are too small to be assigned any workload, so they remain unused.<\/p>\n

For eksempel kr\u00e6ver hver pod 0,75 GB hukommelse. Hvis du har ti noder, og hver har 1 GB hukommelse, kan du k\u00f8re ti pods \u2014 i alt vil der v\u00e6re 0,25 GB ubrugt hukommelse p\u00e5 hver node.<\/p>\n

This means that 25% of the total cluster memory is wasted.<\/p>\n

On a large node with 10 GB of memory, you can run 13 such modules\u2014and there will be only one unused fragment of 0.25 GB left.<\/p>\n

In this case, only 2.5% of the memory is wasted.<\/p>\n

Derfor udnyttes ressourcerne mere optimalt p\u00e5 store noder.<\/p>\n

Flere store noder eller mange sm\u00e5?<\/h2>\n

\nS\u00e5 hvad er bedst: flere store noder i et cluster eller mange sm\u00e5? Som altid er der ikke et entydigt svar. Meget afh\u00e6nger af typen af applikation.<\/p>\n

For eksempel, hvis applikationen kr\u00e6ver 10 GB hukommelse, er valget klart til fordel for store noder. Men hvis applikationen kr\u00e6ver ti gange replikering for h\u00f8j tilg\u00e6ngelighed, er det tvivlsomt, om man b\u00f8r tage chancer og placere replikaer p\u00e5 kun to noder \u2013 der skal v\u00e6re minimum ti noder i clustret.<\/p>\n

I mellemsituationer b\u00f8r du tr\u00e6ffe et valg baseret p\u00e5 fordele og ulemper ved hver mulighed. Nogle argumenter kan v\u00e6re mere relevante for din situation end andre.<\/p>\n

Det er slet ikke n\u00f8dvendigt at g\u00f8re alle noder samme st\u00f8rrelse. Der er intet, der forhindrer, at du f\u00f8rst eksperimenterer med noder af samme st\u00f8rrelse, for derefter at tilf\u00f8je noder af en anden st\u00f8rrelse og kombinere dem i clustret. Arbejdsnoderne i Kubernetes-clustret kan v\u00e6re helt heterogene. S\u00e5 du kan pr\u00f8ve at kombinere fordelene ved begge tilgange.<\/p>\n

Der findes ikke en universel opskrift, da hver situation har sine nuancer, og kun produktionen vil vise sandheden.<\/p>\n

Overs\u00e6ttelsen er udf\u00f8rt af cloudplatformteamet Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Mere om Kubernetes: 25 nyttige v\u00e6rkt\u00f8jer til administration og deployment af clusters<\/a><\/noindex>.<\/p>\n

Kilde: 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\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\udd47 Arbejdsnoder i Kubernetes: mange sm\u00e5 eller nogle f\u00e5 store? | ProHoster","description":"N\u00e5r du opretter et cluster.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}