{"id":33773,"date":"2019-10-31T21:54:36","date_gmt":"2019-10-31T18:54:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervirovanie-v-kubernetes-ono-sushhestvuet\/"},"modified":"2019-10-31T21:54:36","modified_gmt":"2019-10-31T18:54:36","slug":"rezervirovanie-v-kubernetes-ono-sushhestvuet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Reservede i Kubernetes: det findes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mit navn er Sergey, jeg er fra ITSumma, og jeg vil gerne fort\u00e6lle dig, hvordan vi h\u00e5ndterer reservede i Kubernetes. I den seneste tid har jeg arbejdet meget med r\u00e5dgivning om implementering af forskellige devops-l\u00f8sninger for forskellige teams, og jeg arbejder is\u00e6r t\u00e6t med projekter, der bruger K8s. P\u00e5 konferencen Uptime day 4, der var dedikeret til reservede i komplekse arkitekturer, holdt jeg et opl\u00e6g om reservede af \"terningen\", og her er en fritst\u00e5ende genfort\u00e6lling. Jeg vil kun advare p\u00e5 forh\u00e5nd om, at det ikke er en direkte handlingsvejledning, men snarere en opsummering af tanker om emnet.<\/p>\n

\"Reservede
\n
\nGenerelt set er overv\u00e5gning og reservede to grundl\u00e6ggende v\u00e6rkt\u00f8jer til at \u00f8ge fejlmodstandsdygtigheden i ethvert projekt. Men i Kubernetes balancerer alt af sig selv, vil du sige, alt skaleres af sig selv, og hvis noget sker, vil det rejse sig af sig selv\u2026 S\u00e5 ved en f\u00f8rste overfladisk unders\u00f8gelse af emnet svarede internettet mig p\u00e5 sp\u00f8rgsm\u00e5let om, hvordan man tilg\u00e5r reservede i K8s: \u00abhvorfor?\u00bb Mange mener, at Kubernetes er en magisk ting, der fjerner alle infrastrukturproblemer og sikrer, at projektet aldrig falder. Men... verden er ikke, hvad den ser ud til.
\n<\/a><\/noindex>
\nHvordan tilgik vi reservedeprocessen f\u00f8r? Vi havde identiske platforme til hosting - enten virtuelle maskiner eller fysiske servere, servere<\/a>som vi anvendte tre grundl\u00e6ggende praksisser p\u00e5: <\/p>\n

    \n
  1. synkronisering af kode og statisk indhold<\/li>\n
  2. synkronisering af konfigurationer<\/li>\n
  3. replicering af databaser<\/li>\n<\/ol>\n

    \nOg voil\u00e0: p\u00e5 ethvert tidspunkt kan vi skifte til den reservede platform, alle er glade, vi rejser os og g\u00e5r hver til sit. <\/p>\n

    \"Reservede
    \n
    \nHvad tilbyder vi for at \u00f8ge den kontinuerlige tilg\u00e6ngelighed af vores Kubernetes-applikation? Det f\u00f8rste, som den uofficielle dokumentation n\u00e6vner, er at ops\u00e6tte mange maskiner og have mange mestre - antallet skal opfylde kravene til at opn\u00e5 quorum i klyngen, og p\u00e5 hver af mestrene skal etcd, api, MC, scheduler... v\u00e6re opsat. Og det ser ud til at fungere godt: n\u00e5r flere arbejdsnoder eller mestre fejler, vil vores klynge genbalanceres, og applikationen forts\u00e6tter med at fungere. Det ser igen ud som magi! Men ofte befinder vores klynge sig inden for en enkelt datacenter, og det kan rejse nogle sp\u00f8rgsm\u00e5l. Hvad hvis en gravemaskine ankommer og graver en kabel op, lynet sl\u00e5r ned, der opstod en universel oversv\u00f8mmelse? Alt er gone, vores klynge findes ikke l\u00e6ngere. Hvordan n\u00e6rmer vi os redundans med denne side af problemet i tankerne? <\/p>\n

    F\u00f8rst og fremmest skal du have en anden klynge i hot standby, det vil sige en klynge, som du kan skifte til p\u00e5 et hvilket som helst tidspunkt. Set fra Kubernetes' perspektiv skal infrastrukturen v\u00e6re fuldst\u00e6ndig identisk. Det vil sige, hvis der findes nogle ikke-standard plugins til filsystemet, brugerdefinerede l\u00f8sninger til ingress, skal de v\u00e6re fuldst\u00e6ndig identiske p\u00e5 dine to (eller tre, eller ti, alt efter hvor mange ressourcer og administratorer du har) klynger. Det er n\u00f8dvendigt klart at definere to s\u00e6t applikationer (deployments, statefulsets, daemonsets, cronjobs osv.): hvilke af dem kan k\u00f8re p\u00e5 standby konstant, og hvilke er bedre ikke at starte, f\u00f8r der er behov for skift. <\/p>\n

    Skal vores reserveklynge s\u00e5 v\u00e6re fuldst\u00e6ndig identisk med vores produktionsklynge? Nej. Hvis vi f\u00f8r i arbejdet med monolitiske projekter og fysisk infrastruktur holdt et praktisk set identisk milj\u00f8, s\u00e5 mener jeg, at dette ikke b\u00f8r v\u00e6re tilf\u00e6ldet i forbindelse med Kubernetes. Lad os se p\u00e5, hvorfor.<\/p>\n

    For example, let's start with the basic entities of Kubernetes \u2014 deployments \u2014 they must be identical. Applications should be running that can intercept traffic processing at any moment and allow our project to continue running. When it comes to configuration files, we need to determine whether they should be identical or not. This means that if we, smart people, do not use any prohibited substances and do not keep the database in K8s, then our configmaps must have access settings for the live database (the backup process is built separately). Accordingly, to ensure access to the backup database instance, we must have a separate configuration file (configmap). Similarly, we work with secrets: passwords for database access, API keys; at any moment, we can have either the live secret or the backup one active. Thus, we already have two Kubernetes entities whose backup versions should not be identical to the live ones. The next entity to focus on is the cronjob. Cronjobs in the backup must not be identical to the set of cronjobs in the production cluster! If we spin up a backup cluster and spin it up completely with all cronjobs enabled \u2014 then, for example, people will receive two emails from you simultaneously instead of one. Or some data synchronization with external sources will happen twice, leading us to start feeling ill, crying, screaming, and arguing. <\/p>\n

    \"Reservede
    \n
    \nHvordan foresl\u00e5r folk fra internettet, at vi organiserer et sikkerhedskopieringskluster? Det n\u00e6st mest popul\u00e6re svar efter \"hvorfor?\" \u2013 brug af Kubernetes Federation. <\/p>\n

    Hvad er det? Det er, lad os sige, et stort meta-kluster. Hvis vi forestiller os Kubernetes-arkitekturen \u2014 hvor vi har en master og flere noder \u2014 s\u00e5 har vi ogs\u00e5 en master og flere noder i forhold til federation, men hver node er et separat kluster. Det vil sige, at vi arbejder med de samme enheder, de samme primitive, som vi g\u00f8r med en enkelt Kubernetes, men vi h\u00e5ndterer ikke vores fysiske maskiner, men hele klynger. Inden for federationen har vi fuld synkronisering af de federerede ressourcer fra for\u00e6ldre til b\u00f8rn. For eksempel, hvis vi har startet en deployment gennem federation \u2014 vil den blive deployeret til hver af vores datterklustre. Hvis vi tager en configmap eller hemmelighed og ruller den ud gennem federation \u2014 s\u00e5 vil det blive udbredt til alle vores datterklustre; samtidig tillader federation at tilpasse vores ressourcer p\u00e5 b\u00f8rnene. Det vil sige, at vi tog en configmap, deployerede den gennem federation, og hvis vi derefter har brug for at \u00e6ndre noget p\u00e5 specifikke klustre, g\u00e5r vi ind og retter det p\u00e5 det enkelte kluster, og denne \u00e6ndring vil ikke blive synkroniseret noget sted. <\/p>\n

    Kubernetes Federation er et relativt nyt v\u00e6rkt\u00f8j, og det underst\u00f8tter ikke hele det ressourcem\u00e6ssige s\u00e6t, som K8s selv tilbyder: p\u00e5 tidspunktet for offentligg\u00f8relsen af en af de f\u00f8rste versioner af dokumentationen blev det n\u00e6vnt, at der kun var st\u00f8tte for konfigurationsmapper, deployment under replica-set og ingress. Secrets blev ikke underst\u00f8ttet, og arbejde med volume var heller ikke underst\u00f8ttet. S\u00e6ttet er for begr\u00e6nset. Is\u00e6r hvis vi godt kan lide at eksperimentere \u2014 for eksempel ved at sende vores egne ressourcer til Kubernetes via custom resource definition \u2014 s\u00e5 kan vi ikke presse dem ind i federation. S\u00e5 det er ligesom... en l\u00f8sning, der n\u00e6sten er sand, men som f\u00e5r os til nogle gange at tr\u00e6de p\u00e5 egne t\u00e6er. P\u00e5 den anden side g\u00f8r federation det muligt at styre vores replicaset fleksibelt. For eksempel \u00f8nsker vi, at der skal v\u00e6re 10 replikaer af vores applikation k\u00f8rende, og som standard vil federation fordele dette antal proportionalt mellem antallet af klynger. Og alt dette kan ogs\u00e5 konfigureres! Det vil sige, at vi kan angive, at vi skal have 6 replikaer af vores applikation p\u00e5 produktionsklyngen, mens vi p\u00e5 reservaklyngen, for at spare ressourcer eller for egne eksperimenter \u2014 kun \u00f8nsker 4 replikaer af vores applikation. Det er ogs\u00e5 temmelig praktisk. Men med federation m\u00e5 vi bruge nogle nye l\u00f8sninger, implementere noget on-the-fly og f\u00e5 os selv til at t\u00e6nke lidt mere... <\/p>\n

    Kan vi g\u00f8re processen med at reservere Kubernetes lidt enklere? Hvilke v\u00e6rkt\u00f8jer har vi overhovedet?<\/p>\n

    For det f\u00f8rste har vi altid et slags CI\/CD-system, s\u00e5 vi g\u00e5r ikke manuelt ind og skriver create\/apply p\u00e5 serverne. Systemet genererer yaml-filer til vores containere. <\/p>\n

    For det andet har vi flere klynger, vi har enten en enkelt eller flere (hvis vi er smarte) registries, som vi ogs\u00e5 har taget og reserveret. Og der er det fantastiske v\u00e6rkt\u00f8j kubectl, som kan arbejde med flere klynger samtidig. <\/p>\n

    \"Reservede
    \n
    \nS\u00e5 her er jeg: efter min mening er den enkleste og mest korrekte l\u00f8sning til opbygning af et backup-kluster en primitiv parallel deployment. Der er en eller anden pipeline i CI\/CD-systemet; f\u00f8rst bygger vi vores containere, tester dem og ruller applikationerne ud via kubectl p\u00e5 flere uafh\u00e6ngige klynger. Vi kan lave samtidige udrulninger til flere klynger. Derfor l\u00f8ser vi ogs\u00e5 leveringen af konfigurationer p\u00e5 dette trin. Vi kan p\u00e5 forh\u00e5nd definere et s\u00e6t konfigurationer til vores produktionskluster, et s\u00e6t konfigurationer til backup-klusteret og p\u00e5 niveauet af CI\/CD-systemet rulle produktionsmilj\u00f8et ud til produktionsklusteret og backup-milj\u00f8et til backup-klusteret. I forhold til federation beh\u00f8ver vi ikke at g\u00e5 ind p\u00e5 hver underordnet klynge og redefinere noget efter at have bestemt den f\u00f8derale ressource. Vi har gjort dette p\u00e5 forh\u00e5nd. For en god indsats.<\/p>\n

    Men... der er... jeg havde skrevet, der er 'roden til al ondskab', men der er faktisk to. For det f\u00f8rste, filsystemet. Der er en eller anden PV, eller ogs\u00e5 bruger vi et eksternt lager. Hvis vi gemmer filer inden for klyngen, s\u00e5 skal vi handle efter de gamle praksisser, der stammer fra tiden med hardwareinfrastrukturer: for eksempel synkronisere med lsync. Eller hvilken som helst anden metode, du personligt foretr\u00e6kker. Vi ruller alt ud p\u00e5 andre maskiner og lever videre.<\/p>\n

    For det andet, og faktisk en endnu vigtigere h\u00e6msko \u2014 databasen. Hvis vi er kloge mennesker og ikke holder databasen i Kubernetes, s\u00e5 er data-backup-processen efter den samme gamle skema \u2014 master-slave replikation, derefter skifter vi, replikatet indhenter vi, og s\u00e5 lever vi godt. Men hvis vi holder vores DB inde i klyngen, s\u00e5 er der faktisk mange f\u00e6rdige l\u00f8sninger til at organisere den samme master-slave replikation, mange l\u00f8sninger til at oprette DB inde i Kubernetes.
    \n Der er allerede l\u00e6st en milliard pr\u00e6sentationer om database-backup, skrevet en milliard artikler, der er ikke noget nyt her, faktisk. Generelt skal du f\u00f8lge din dr\u00f8m, leve som du vil, opfinde dig selv ogs\u00e5 nogle komplicerede l\u00f8sninger, men s\u00f8rg for at t\u00e6nke over, hvordan du vil backup alt dette.<\/p>\n

    Lad os nu tale om, hvordan vi generelt vil h\u00e5ndtere overgangen til den reserveplacering i tilf\u00e6lde af brand. For det f\u00f8rste implementerer vi stateless-applikationer parallelt. De p\u00e5virker ikke forretningslogikken i vores applikationer, vores projekt, vi kan konstant have to s\u00e6t applikationer k\u00f8rende, og de kan begynde at modtage trafik. Det er meget vigtigt under overgangen til den reserveplacering at se p\u00e5, om konfigurationerne skal omdefineres. For eksempel har vi et produktions Kubernetes-klynge, en reserve Kubernetes-klynge, en ekstern masterdatabase og en reserve masterdatabase. Vi har fire muligheder for, hvordan disse applikationer i produktion kan interagere med hinanden. Vores database kan skifte, og det viser sig, at vi skal skifte trafikken p\u00e5 produktionsklusteret til den nye database, eller vores klynge kan g\u00e5 ned \u2014 og vi skifter til reserve, men forts\u00e6tter med at arbejde med produktionsdatabasen, og s\u00e5 er der den tredje mulighed, hvor b\u00e5de dette og hint g\u00e5r ned, og vi skifter begge applikationer, omdefinerer vores konfiguration, s\u00e5 de nye applikationer arbejder med den nye database. <\/p>\n

    S\u00e5, hvad kan vi konkludere ud fra alt dette? <\/p>\n

    \"Reservede
    \n
    \nF\u00f8rste konklusion: det er godt at have en reserve. Men det er dyrt. Ideelt set b\u00f8r man ikke kun have \u00e9n reserve. Man b\u00f8r faktisk have flere reserver. For det f\u00f8rste skal reserverne v\u00e6re i mindst to forskellige datacentre, og for det andet, helst hos en anden udbyder. Jeg har ofte set det \u2014 og jeg kan desv\u00e6rre ikke n\u00e6vne projekter; netop da der var brand i datacentret... Jeg sagde: lad os skifte til reserven! Men de reservedatacenter-servere stod i det samme rack...<\/p>\n

    Eller forestil dig, at Amazon blev blokeret i Rusland (og det er sket). Og s\u00e5: hvad hj\u00e6lper det, at vores reserve ligger i en anden Amazon? Den er ogs\u00e5 utilg\u00e6ngelig. S\u00e5 lad mig gentage: Behold reservedele, mindst i et andet datacenter, og helst \u2014 hos en anden udbyder. <\/p>\n

    Den anden konklusion: hvis du har en applikation i Kubernetes, der kommunikerer med nogle eksterne kilder (det kan v\u00e6re b\u00e5de en database og et extern API), skal du bestemt definere den som en service med en ekstern Endpoint, s\u00e5 du ikke skal redeployere 15 af dine applikationer, der henvender sig til den samme database, n\u00e5r der sker en omstilling. Definer databasen som en separat service, og kommuniker med den, som om den er inden for klyngen: hvis din database g\u00e5r ned, \u00e6ndrer du IP'en \u00e9t sted og forts\u00e6tter med at leve happily ever after. <\/p>\n

    Og til sidst: Jeg elsker \"kuben\", ligesom jeg elsker eksperimenter med den. Jeg elsker ogs\u00e5 at dele resultaterne af disse eksperimenter og generelt min personlige erfaring. Derfor har jeg lavet en r\u00e6kke webinarer om K8s, velkommen til vores youtube-kanal<\/a><\/noindex> for yderligere detaljer.
    \n
    Kilde:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0421\u0435\u0440\u0433\u0435\u0439, \u044f \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 ITSumma, \u0438 \u044f \u0445\u043e\u0447\u0443 \u0432\u0430\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u043c \u043a \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 Kubernetes. \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043c\u043d\u043e\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u043a\u043e\u043d\u0441\u0443\u043b\u044c\u0442\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u043e\u0439 \u043f\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u044b\u0445 devops-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u043e\u043c\u0430\u043d\u0434, \u0438, \u0432 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043f\u043b\u043e\u0442\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u043f\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c K8s. \u041d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 Uptime day 4, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25449,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33773","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\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\udd47Backup i Kubernetes: det eksisterer | ProHoster","description":"Mit navn er Sergey, jeg er fra ITSumma, og jeg vil fort\u00e6lle jer, hvordan vi h\u00e5ndterer backup i Kubernetes.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","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\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043e\u043d\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 | ProHoster","og:description":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0421\u0435\u0440\u0433\u0435\u0439, \u044f \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 ITSumma, \u0438 \u044f \u0445\u043e\u0447\u0443 \u0432\u0430\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u043c \u043a \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 Kubernetes.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","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":"2019-10-31T18:54:36+00:00","article:modified_time":"2019-10-31T18:54:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33773","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":"2026-02-09 17:03:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:33:25","updated":"2026-02-09 17:03:20","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\/33773","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=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}