{"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\/nl\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Werknodes van Kubernetes: veel kleine of enkele grote?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Werknodes
\nBij het opzetten van een Kubernetes-cluster kunnen vragen opkomen: hoeveel werkknopen moeten we instellen en welk type? Wat is beter voor een on-premise cluster: enkele krachtige servers kopen of een dozijn oude machines in uw datacenter gebruiken? En in de cloud, moeten we dan acht enkel-core of twee vier-core instanties nemen? <\/p>\n

De antwoorden op deze vragen zijn te vinden in het artikel van Dani\u00ebl Weibel, engineer en docent van het leerproject Learnk8s<\/a><\/noindex> gepubliseerd door het team Kubernetes aaS van Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

De capaciteit van het cluster<\/h2>\n

\nIn het algemeen kan een Kubernetes-cluster worden beschouwd als een grote 'superknoop'. De totale rekenkracht is de som van de rekenkracht van alle componentknopen. <\/p>\n

Er zijn verschillende manieren om de gewenste doelcapaciteit van het cluster te bereiken. Stel dat we een cluster nodig hebben met een totale capaciteit van 8 CPU-kernen en 32 GB RAM, omdat de applicatiebundel zoveel middelen vereist. Dan kunnen we twee knopen van 16 GB geheugen installeren of vier knopen van 8 GB geheugen, met twee vier-core processors of vier twee-core processors.<\/p>\n

Hier zijn slechts twee mogelijke manieren om een cluster te cre\u00ebren:<\/p>\n

\"Werknodes
\nBeide opties geven een cluster met dezelfde capaciteit, maar in de onderste configuratie zijn er vier kleinere knopen ge\u00efnstalleerd, terwijl er in de bovenste configuratie twee grotere staan. <\/p>\n

Welke optie is beter?<\/h3>\n

\nOm deze vraag te beantwoorden, laten we de voordelen van beide opties bekijken. We hebben ze in een tabel samengebracht.<\/p>\n

Enkele grote knopen<\/p>\n

Veel kleine knopen<\/p>\n

Eenvoudiger clusterbeheer (als het on-premise is)<\/p>\n

Vloeiende autoscaling<\/p>\n

Goedkoper (als het on-premise is) <\/p>\n

Prijs verschilt nauwelijks (in de cloud) <\/p>\n

Kan middelenintensievere applicaties uitvoeren <\/p>\n

Volledige replicatie<\/p>\n

Middelen worden effici\u00ebnter gebruikt (minder overhead voor systeemdaemonen)
\nHogere beschikbaarheid van het cluster<\/p>\n

Let op dat we alleen over werkknopen spreken. De keuze van het aantal en de grootte van de hoofdknooppunten is een totaal ander onderwerp.<\/p>\n

Laten we elk punt in de tabel nader bespreken.<\/p>\n

Eerste optie: enkele grote knopen<\/h2>\n

\nDe meest extreme optie is \u00e9\u00e9n werkknop voor de volledige capaciteit van het cluster. In het bovenstaande voorbeeld zou dit \u00e9\u00e9n werkknop zijn met 16 CPU-kernen en 16 GB RAM.<\/p>\n

Voordelen <\/h3>\n

\nPluspunt #1. Eenvoudiger beheer<\/b>
\nHet is eenvoudiger om meerdere machines te beheren dan een hele vloot. Updates en patches sneller doorvoeren en eenvoudiger synchroniseren. Het aantal storingen in absolute cijfers is ook lager.<\/p>\n

Houd er rekening mee dat alles wat hierboven is gezegd betrekking heeft op je eigen hardware, je eigen servers, en niet op cloud-instanties.<\/p><\/blockquote>\n

\nIn de cloud is de situatie anders. Daar wordt het beheer uitgevoerd door de cloudprovider. Dus het beheren van tien knooppunten in de cloud verschilt niet veel van het beheren van \u00e9\u00e9n knooppunt.<\/p>\n

Het routeren van verkeer en het verdelen van de belasting tussen pods in de cloud wordt automatisch uitgevoerd<\/a><\/noindex>: binnenkomend verkeer van het internet wordt naar de hoofd-loadbalancer gestuurd, die het verkeer naar de poort van een van de knooppunten leidt (de NodePort-service stelt een poort in het bereik van 30000-32767 in op elk knooppunt van de cluster). De regels die door kube-proxy zijn ingesteld, leiden het verkeer van het knooppunt naar de pod. Zo ziet het eruit voor tien pods op twee knooppunten:<\/p>\n

\"Werknodes
\nPlus #2. Lagere kosten per knooppunt<\/b>
\nEen krachtige machine is duurder, maar de prijsstijging is niet noodzakelijk lineair. Met andere woorden, \u00e9\u00e9n tienkernige server met 10 GB geheugen is meestal goedkoper dan tien enkelkernige met hetzelfde aantal geheugen.<\/p>\n

Maar let op dat deze regel meestal niet geldt voor cloudservices. In de huidige prijsmodellen stijgen de prijzen bij alle grote cloudproviders lineair met de capaciteit.<\/p><\/blockquote>\n

\nDaarom is het in de cloud meestal niet mogelijk om te besparen op krachtigere servers.<\/p>\n

Plus #3. Je kunt resource-intensieve applicaties draaien<\/b>
\nSommige applicaties vereisen krachtige servers in de cluster. Als een machine learning-systeem bijvoorbeeld 8 GB geheugen nodig heeft, kun je het niet draaien op knooppunten met 1 GB, maar alleen als er ten minste \u00e9\u00e9n grote werkknop beschikbaar is.<\/p>\n

Nadelen <\/h3>\n

\nNadeel nr. 1. Veel pod's per knooppunt<\/b>
\nAls dezelfde taak op een kleiner aantal knooppunten wordt uitgevoerd, zullen er natuurlijk meer pod's op elk van hen zijn.<\/p>\n

Dit kan problematisch worden.<\/p>\n

De reden hiervoor is dat elke module enige overhead met zich meebrengt voor de container runtime-omgeving (bijvoorbeeld Docker), evenals kubelet en cAdvisor.<\/p>\n

Bijvoorbeeld, kubelet controleert regelmatig de levensvatbaarheid van alle containers op het knooppunt \u2013 hoe meer containers, hoe meer werk voor kubelet.<\/p>\n

CAdvisor verzamelt statistieken over het gebruik van bronnen van alle containers op de node, terwijl kubelet deze informatie regelmatig opvraagt en via de API beschikbaar stelt. Nogmaals, hoe meer containers, hoe meer werk voor zowel cAdvisor als kubelet.<\/p>\n

Als het aantal modules toeneemt, kan dit het systeem vertragen en zelfs de betrouwbaarheid aantasten.<\/p>\n

\"Werknodes
\nIn de Kubernetes-repository hebben sommigen geklaagd<\/a><\/noindex>, dat nodes tussen de status Ready\/NotReady springen, omdat de reguliere controles van kubelet op alle containers op de node te veel tijd in beslag nemen.
\nOm deze reden Het wordt aanbevolen om niet meer dan 110 pod's per knooppunt te plaatsen.<\/a><\/noindex>. Afhankelijk van de prestaties van de node, kunt u meer pods per node draaien, maar het is moeilijk te voorspellen of er problemen optreden of dat alles goed zal werken. Het is verstandig om dit van tevoren te testen. <\/p>\n

Minpunt nummer 2. Beperking van replicatie<\/b>
\nEen te klein aantal nodes beperkt de effectieve replicatiegraad van applicaties. Bijvoorbeeld, als u een applicatie met hoge beschikbaarheid heeft van vijf replicas, maar slechts twee nodes, dan vermindert de effectieve replicatiegraad van de applicatie tot twee.<\/p>\n

Vijf replicas kunnen alleen over twee nodes worden verdeeld, en als een van hen uitvalt, gaan er onmiddellijk meerdere replicas verloren.<\/p>\n

Als je vijf of meer nodes hebt, zal elke replica op een aparte node draaien, en de storing van een node zorgt ervoor dat er niet meer dan \u00e9\u00e9n replica wordt verwijderd.<\/p>\n

Daarom kunnen de eisen voor hoge beschikbaarheid een bepaald minimumaantal nodes in het cluster vereisen.<\/p>\n

Minpunt nummer 3. Slechtere gevolgen van falen<\/b>
\nBij een klein aantal nodes heeft elke storing ernstigere gevolgen. Als u bijvoorbeeld maar twee nodes hebt en een van hen uitvalt, verliest u meteen de helft van uw modules.<\/p>\n

Natuurlijk zal Kubernetes de belasting van de defecte node naar andere nodes verplaatsen. Maar als er maar weinig zijn, kan de beschikbare capaciteit ontoereikend zijn. Als gevolg hiervan zullen sommige van uw applicaties niet beschikbaar zijn totdat u de defecte node opnieuw opstart.<\/p>\n

Hoe meer nodes er zijn, hoe minder impact hardwarestoringen hebben.<\/p>\n

Minpunt nummer 4. Grotere stappen in autoscaling<\/b>
\nIn Kubernetes, there is an automatic cluster scaling system for cloud infrastructure that allows for the automatic addition or removal of nodes based on current needs. With larger nodes, scaling becomes more abrupt and clumsy. For example, adding an additional node to a two-node setup increases the cluster capacity by 50% immediately. You will have to pay for these resources even if they're not needed.<\/p>\n

Thus, if you plan to use automatic cluster scaling, the smaller the nodes, the more flexible and cost-effective your scaling will be.<\/p>\n

Now let's consider the advantages and disadvantages of having many small nodes.<\/p>\n

The second option: many small nodes<\/h2>\n

\nThe advantages of this approach essentially stem from the disadvantages of the opposite option with several large nodes.<\/p>\n

Voordelen<\/h3>\n

\nAdvantage No. 1. Lower impact of failure<\/b>
\nHoe meer knooppunten, des te minder pod's op elk knooppunt. Bijvoorbeeld, als je honderd modules op tien knooppunten hebt, dan zullen er gemiddeld tien modules op elk knooppunt zijn.<\/p>\n

Thus, if one of the nodes goes down, you only lose 10% of the workload. There\u2019s a chance that only a small number of replicas will be affected, and the applications overall will remain operational.<\/p>\n

Daarnaast is de kans groot dat de resterende knooppunten voldoende vrije middelen hebben voor de werklast van het defecte knooppunt, zodat Kubernetes de pod's opnieuw kan plannen en je toepassingen relatief snel weer operationeel zijn.<\/p>\n

Advantage No. 2. Good replication<\/b>
\nIf there are enough nodes, the Kubernetes scheduler can assign different nodes to all replicas. Thus, in the event of a node failure, only one replica will be affected, and the application will remain accessible.<\/p>\n

Nadelen <\/h3>\n

\nDisadvantage No. 1. More difficult management<\/b>
\nManaging a large number of nodes is more challenging. For example, each Kubernetes node must interact with all the others, meaning the number of connections grows quadratically, and all those connections must be monitored.<\/p>\n

The node controller in the Kubernetes controller manager regularly checks the health of all nodes in the cluster \u2014 the more nodes there are, the greater the load on the controller.<\/p>\n

The load on the etcd database also increases \u2014 every kubelet and kube-proxy calls watcher<\/a><\/noindex> voor etcd (via API), waarnaar etcd objectupdates moet vertalen.<\/p>\n

Over het algemeen legt elke werkende node extra belasting op de systeemcomponenten van de hoofdknopen.<\/p>\n

\"Werknodes
\nOfficieel ondersteunt Kubernetes clusters met tot 5000 knopen.<\/a><\/noindex>Echter, in de praktijk kunnen al 500 knopen niet-triviale problemen veroorzaken.<\/a><\/noindex>.<\/p>\n

Voor het beheer van een groot aantal werkende knopen moeten krachtigere hoofdknopen worden gekozen. Bijvoorbeeld, kube-up installeert automatisch<\/a><\/noindex> de juiste VM-grootte voor de hoofdknop afhankelijk van het aantal werkende knopen. Dit betekent dat hoe meer werkende knopen, hoe krachtiger de hoofdknopen moeten zijn. <\/p>\n

Om deze specifieke problemen op te lossen, zijn er speciale ontwikkelingen, zoals Virtual Kubelet.<\/a><\/noindex>Dit systeem maakt het mogelijk om beperkingen te omzeilen en clusters te bouwen met een enorm aantal werkende knopen.<\/p>\n

Nadeel #2. Meer overhead.<\/b>
\nOp elke werkende node draait Kubernetes een reeks systeemdaemonen - dit omvat een container-runtime (zoals Docker), kube-proxy en kubelet, inclusief cAdvisor. Samen verbruiken ze een bepaalde vaste hoeveelheid middelen.<\/p>\n

Als je veel kleine knopen hebt, is het aandeel van deze overhead per node groter. Stel je bijvoorbeeld voor dat alle systeemdaemonen van \u00e9\u00e9n node samen 0,1 CPU-kern en 0,1 GB geheugen gebruiken. Als je \u00e9\u00e9n deca-core node met 10 GB geheugen hebt, verbruiken de daemon 1% van de clustercapaciteit. Aan de andere kant, op tien single-core knopen met elk 1 GB geheugen, nemen de daemon 10% van de clustercapaciteit in beslag.<\/p>\n

Dus, hoe minder knopen, hoe effici\u00ebnter de infrastructuur wordt benut.<\/p>\n

Nadeel #3. Ineffici\u00ebnt gebruik van middelen.<\/b>
\nOp kleine knopen kan het voorkomen dat de resterende fragmenten van middelen te klein zijn om enige werklast aan toe te wijzen, waardoor ze ongebruikt blijven.<\/p>\n

Bijvoorbeeld, elke pod vereist 0,75 GB geheugen. Als je tien knooppunten hebt en elk heeft 1 GB geheugen, kun je tien pod's draaien \u2014 uiteindelijk blijft er 0,25 GB ongebruikt geheugen op elk knooppunt over.<\/p>\n

Dit betekent dat 25% van het geheugen van de totale cluster nutteloos wordt besteed.<\/p>\n

Op een grote node met 10 GB geheugen kun je 13 van dergelijke modules draaien - en dan blijft er slechts \u00e9\u00e9n ongebruikte fragment van 0,25 GB over.<\/p>\n

In dit geval wordt slechts 2,5% van het geheugen verspild.<\/p>\n

Op deze manier worden resources effici\u00ebnter gebruikt op grote knooppunten.<\/p>\n

Meerdere grote knooppunten of veel kleine?<\/h2>\n

\nWat is beter: meerdere grote knooppunten in een cluster of veel kleine? Zoals altijd is er geen eenduidig antwoord. Veel hangt af van het type applicatie.<\/p>\n

Bijvoorbeeld, als een applicatie 10 GB geheugen nodig heeft, is de keuze voor grote knooppunten overduidelijk. Maar als de applicatie tienvoudige replicatie voor hoge beschikbaarheid vereist, is het onwaarschijnlijk dat het verstandig is om replica's op slechts twee knooppunten te plaatsen \u2014 er moeten minimaal tien knooppunten in het cluster zijn.<\/p>\n

In tussenliggende situaties moet je kiezen op basis van de voor- en nadelen van elk alternatief. Misschien zijn sommige argumenten relevanter voor jouw situatie dan andere.<\/p>\n

Het is helemaal niet nodig om alle knooppunten dezelfde grootte te geven. Niets staat je in de weg om eerst met knooppunten van dezelfde grootte te experimenteren en daarna knooppunten van andere grootte toe te voegen, waardoor je ze in het cluster combineert. Werkende knooppunten in een Kubernetes-cluster kunnen volledig heterogeen zijn. Dus je kunt proberen de voordelen van beide benaderingen te combineren.<\/p>\n

Er bestaat geen universeel recept, en elke situatie heeft zijn eigen nuances, alleen de productie zal de waarheid onthullen.<\/p>\n

Vertaling verzorgd door het cloudplatformteam. Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Meer over Kubernetes: 25 handige tools voor het beheren en uitrollen van clusters.<\/a><\/noindex>.<\/p>\n

Bron: 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 Werkende knooppunten van Kubernetes: veel kleine of enkele grote? | ProHoster","description":"Bij het opzetten van een cluster.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}