{"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\/no\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Reservasjon i Kubernetes: det eksisterer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jeg heter Sergej, jeg er fra selskapet ITSumma, og jeg vil fortelle deg hvordan vi n\u00e6rmer oss reservasjon i Kubernetes. I det siste har jeg v\u00e6rt mye involvert i r\u00e5dgivning knyttet til implementering av forskjellige devops-l\u00f8sninger for ulike team, og jeg jobber spesielt med prosjekter som bruker K8s. P\u00e5 konferansen Uptime day 4, som var dedikert til reservasjon i komplekse arkitekturer, holdt jeg en presentasjon om reservasjon av 'kuben', og her er en fri gjengivelse av den. Jeg vil bare p\u00e5 forh\u00e5nd advare om at det ikke er en direkte h\u00e5ndbok til handling, men snarere en oppsummering av tanker om det aktuelle temaet.<\/p>\n

\"Reservasjon
\n
\nI prinsippet er overv\u00e5king og reservasjon de to hovedverkt\u00f8yene for \u00e5 \u00f8ke feiltoleransen til ethvert prosjekt. Men, men i Kubernetes balanseres alt automatisk, vil du si, alt skaleres automatisk, og hvis noe skjer, vil det vil l\u00f8fte seg selv... S\u00e5 ved f\u00f8rste overfladiske unders\u00f8kelse av temaet, svarte internett meg p\u00e5 sp\u00f8rsm\u00e5let om hvordan folk n\u00e6rmer seg reservasjon i K8s, med 'hvorfor?' Mange tror at Kubernetes er en magisk ting som l\u00f8ser alle infrastrukturproblemer og s\u00f8rger for at prosjektet aldri vil falle. Men... verden er ikke slik den ser ut.
\n<\/a><\/noindex>
\nHvordan n\u00e6rmet vi oss reservasjonsprosessen tidligere? Vi hadde identiske plattformer for hosting - enten virtuelle maskiner eller fysiske servere, servere<\/a>, der vi brukte tre grunnleggende praksiser: <\/p>\n

    \n
  1. kode- og statisk synkronisering<\/li>\n
  2. konfigurasjonssynkronisering<\/li>\n
  3. replikering av databaser<\/li>\n<\/ol>\n

    \nOg vips: i hvilket som helst \u00f8yeblikk kan vi bytte over til reservel\u00f8sningen, alle er lykkelige, vi reiser oss og g\u00e5r. <\/p>\n

    \"Reservasjon
    \n
    \nHva tilbyr vi for \u00e5 \u00f8ke den kontinuerlige tilgjengeligheten av Kubernetes-applikasjonen v\u00e5r? Det f\u00f8rste som ikke-offisiell dokumentasjon nevner, er \u00e5 sette opp mange maskiner, lage mange mestre \u2013 antallet m\u00e5 oppfylle kravene for \u00e5 oppn\u00e5 quorum innen klyngen, og p\u00e5 hver av de mesterne m\u00e5 etcd, API, MC, scheduler osv. v\u00e6re oppe. Og det ser egentlig flott ut: n\u00e5r flere arbeidsnoder eller mestre svikter, vil klyngen v\u00e5r ombalanseres, og applikasjonen fortsetter \u00e5 fungere. Det ser igjen ut som magi! Men ofte befinner klyngen v\u00e5r seg innenfor ett datasenter, noe som kan reise visse sp\u00f8rsm\u00e5l. Hva skjer hvis en gravemaskin kommer og graver opp en kabel, om lynet sl\u00e5r ned, eller om det skjer en stor oversv\u00f8mmelse? Alt g\u00e5r tapt, klyngen v\u00e5r er ikke lenger der. Hvordan n\u00e6rme seg reserven med denne siden av problemet i tankene? <\/p>\n

    Fremfor alt m\u00e5 du ha en annen klynge i varm reserve, det vil si en klynge som du kan bytte til n\u00e5r som helst. Fra Kuber-standpunktet m\u00e5 infrastrukturen v\u00e6re helt identisk. S\u00e5 hvis det finnes noen ikke-standard plugins for filsystemet, tilpassede l\u00f8sninger for ingress, m\u00e5 de v\u00e6re helt identiske p\u00e5 de to (eller tre, eller ti, alt etter hvor mye penger og krefter administratorene har) klusterne dine. Du m\u00e5 tydelig definere to sett med applikasjoner (deployment\u2019er, statefulsets, daemonsets, cronjobs osv.): hvilke av dem kan kj\u00f8re p\u00e5 reserven konstant, og hvilke er bedre \u00e5 ikke starte f\u00f8r det skjer en faktisk omkobling. <\/p>\n

    B\u00f8r v\u00e5r reserveklynge v\u00e6re helt identisk med v\u00e5r produksjonsklynge? Nei. Tidligere, i arbeidet med monolittiske prosjekter og fysisk infrastruktur, holdt vi praktisk talt et helt identisk milj\u00f8, men i Kubernetes synes jeg ikke dette er n\u00f8dvendig. La oss 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 at any moment, allowing our project to continue functioning. When it comes to configuration files, we need to consider whether they should be identical or not. In other words, if we are sensible people who do not use any prohibited substances and do not keep the database in K8s, then our configmaps should contain access settings to the production database (the backup process of which is built separately). Accordingly, to ensure access to the backup database instance, we must have a separate configuration file (configmap). We work in the exact same way with secrets: passwords for database access, API keys; at any given time, we may have either the production secret or the backup one. Thus, we already have two Kubernetes entities whose backup versions should not be identical to the production versions. The next entity to focus on is the cronjob. Backup cronjobs should never be identical to the set of cronjobs in the production cluster! If we raise a backup cluster and bring it up fully with all the included cronjobs, for example, people will receive two emails at the same time instead of one. Or some data synchronization with external sources will occur twice, which leads us to start getting sick, crying, shouting, and complaining. <\/p>\n

    \"Reservasjon
    \n
    \nSo how do people from the internet suggest we organize the backup cluster? The second most popular answer after 'why bother?' is the use of Kubernetes Federation. <\/p>\n

    Hva er dette? Det er, la oss si, en stor meta-klynge. Hvis vi forestiller oss arkitekturen av Kubernetes \u2013 der vi har en master og flere noder \u2013 s\u00e5 har vi, n\u00e5r det gjelder federasjon, ogs\u00e5 en master og flere noder, men hver node er en egen klynge. Det betyr at vi jobber med de samme enhetene, de samme primitivene, som med en enkelt Kubernetes, bare at vi roterer ikke med v\u00e5re fysiske maskiner, men med hele klynger. I forbundsrammen skjer det full synkronisering av f\u00f8derale ressurser fra foreldre til avkom. For eksempel, hvis vi har initiert en distribusjon gjennom federasjonen \u2013 vil den bli distribuert til hver av v\u00e5re underklynger. Hvis vi tar en hvilken som helst configmap, hemmelighet, og distribuerer den gjennom federasjonen \u2013 vil den spre seg til alle v\u00e5re underklynger; samtidig tillater federasjonen \u00e5 tilpasse v\u00e5re ressurser p\u00e5 barna. Det vil si at vi tok en hvilken som helst configmap, distribuerte den gjennom federasjonen, og deretter, hvis vi trenger \u00e5 justere noe p\u00e5 spesifikke klynger, g\u00e5r vi for \u00e5 redigere p\u00e5 den spesifikke klyngen, og denne endringen vil ikke bli synkronisert noe sted. <\/p>\n

    Kubernetes Federation er et relativt nytt verkt\u00f8y, og det st\u00f8tter ikke hele settet av ressurser som K8s tilbyr: ved publiseringen av en av de f\u00f8rste dokumentversjonene sto det at det kun var st\u00f8tte for konfigurasjonsmapper, distribusjon under replika-sett, ingress. Hemmeligheter ble ikke st\u00f8ttet, og arbeid med volum ble heller ikke st\u00f8ttet. Et altfor begrenset sett. Spesielt hvis vi liker \u00e5 ha det moro \u2014 for eksempel ved \u00e5 bruke custom resource definition til \u00e5 overf\u00f8re v\u00e5re egne ressurser til Kubernetes, s\u00e5 f\u00e5r vi dem ikke presset inn i federasjonen. Det vil si at\u2026 det er et ganske riktig, men likevel problematisk l\u00f8sning, som f\u00e5r oss til \u00e5 av og til skyte oss selv i foten. P\u00e5 den annen side gj\u00f8r federasjonen det mulig \u00e5 administrere v\u00e5r replicaset fleksibelt. For eksempel \u00f8nsker vi at det skal kj\u00f8re 10 repliker av applikasjonen v\u00e5r, og som standard vil federasjonen fordele dette tallet proporsjonalt mellom antallet klynger. Og alt dette kan ogs\u00e5 konfigureres! Det vil si at vi kan spesifisere at p\u00e5 produksjonsklyngen m\u00e5 vi ha 6 repliker av applikasjonen v\u00e5r, mens p\u00e5 den reservemassive klyngen, for \u00e5 spare ressurser eller for \u00e5 ha litt moro \u2014 bare 4 repliker av applikasjonen v\u00e5r. Dette er ogs\u00e5 ganske praktisk. Men med federasjonen m\u00e5 vi bruke noen nye l\u00f8sninger, noe m\u00e5 distribueres mens vi g\u00e5r, vi m\u00e5 tvinge oss til \u00e5 tenke litt mer\u2026 <\/p>\n

    Er det mulig \u00e5 n\u00e6rme seg prosessen med \u00e5 reservere kubernetes p\u00e5 en enklere m\u00e5te? Hvilke verkt\u00f8y har vi tilgjengelig?<\/p>\n

    For det f\u00f8rste har vi alltid et slags ci\/cd-system, det vil si vi g\u00e5r ikke manuelt inn og skriver create\/apply p\u00e5 servere. Systemet genererer yaml-filer for containerne v\u00e5re. <\/p>\n

    For det andre finnes det flere klynger, vi har enten en eller flere (hvis vi er smarte) registre, som vi ogs\u00e5 har reservert. Og vi har det fantastiske verkt\u00f8yet kubectl, som kan jobbe med flere klynger samtidig. <\/p>\n

    \"Reservasjon
    \n
    \nS\u00e5nn sett mener jeg at den enkleste og mest korrekte l\u00f8sningen for \u00e5 bygge et sikkerhetskluster, er en primitiv parallell distribusjon. Det finnes et eller annet pipeline i CI\/CD-systemet; f\u00f8rst bygger vi containerne v\u00e5re, tester dem og ruller ut applikasjonene via kubectl p\u00e5 flere uavhengige klynger. Vi kan lage samtidige utrullinger p\u00e5 flere klynger. F\u00f8lgelig l\u00f8ser vi ogs\u00e5 leveringen av konfigurasjoner p\u00e5 dette trinnet. Vi kan p\u00e5 forh\u00e5nd definere et sett med konfigurasjoner for v\u00e5r produksjonsklynge og et sett med konfigurasjoner for sikkerhetsklyngen, og p\u00e5 CI\/CD-niv\u00e5 rulle ut produksjonsmilj\u00f8et i produksjonsklyngen og sikkerhetsmilj\u00f8et i sikkerhetsklyngen. Sammenlignet med en f\u00f8derasjon trenger vi ikke \u00e5 g\u00e5 til hver underklynge etter \u00e5 ha definert den f\u00f8dererte ressursen for \u00e5 overstyrke noe. Vi har gjort dette p\u00e5 forh\u00e5nd. For et bra stykke arbeid.<\/p>\n

    Men\u2026 det er\u2026 jeg skrev, det er \u00abroten til alt ondt\u00bb, men det er faktisk to av dem. For det f\u00f8rste, filsystemet. Det finnes en eller annen PV, eller vi bruker ekstern lagring. Hvis vi lagrer filer inne i klyngen, m\u00e5 vi f\u00f8lge de gamle praksisene fra tidene med fysiske infrastrukturer: for eksempel synkronisere med lsync. Eller noen annen metode som du personlig foretrekker. Vi ruller alt ut til andre enheter og fortsetter som f\u00f8r.<\/p>\n

    For det andre, og faktisk et enda mer viktig hinder, er databasen. Hvis vi er smarte mennesker og ikke holder databasen i Kubernetes, s\u00e5 er prosessen med \u00e5 sikre data p\u00e5 den gamle m\u00e5ten \u2014 master-slave replikasjon, s\u00e5 bytter vi, og vi skal f\u00e5 replikatet oppdatert og leve godt. Men hvis vi holder databasen v\u00e5r inne i klyngen, finnes det i prinsippet mange klare l\u00f8sninger for \u00e5 organisere samme master-slave replikasjon, mange l\u00f8sninger for \u00e5 sette opp databasen inne i Kubernetes.
    \n Det er allerede skrevet milliarder av foredrag og artikler om databaseregistrering; det er egentlig ikke noe nytt her. Generelt, f\u00f8lg dr\u00f8mmene deres, lev som dere vil, oppfinn deres egne kompliserte l\u00f8sninger, men tenk n\u00f8ye gjennom hvordan dere vil gj\u00f8re sikkerhetskopieringen.<\/p>\n

    N\u00e5, la oss n\u00e5 se p\u00e5 hvordan prosessen med \u00e5 bytte til en reservel\u00f8sning vil foreg\u00e5 i tilfelle brann. F\u00f8rst og fremst distribuerer vi stateless-applikasjoner parallelt. De p\u00e5virker ikke forretningslogikken i applikasjonene v\u00e5re, prosjektet v\u00e5rt. Vi kan alltid ha to sett med kj\u00f8rende applikasjoner, og de kan begynne \u00e5 motta trafikk. Det er veldig viktig under overgangen til reservel\u00f8sningen \u00e5 sjekke om konfigurasjonene m\u00e5 overstyres. For eksempel har vi en produksjonsklynge i Kubernetes, en reservklynge i Kubernetes, en ekstern masterdatabase og en reservmasterdatabase. Vi har fire alternativer for hvordan disse applikasjonene i produksjonen kan begynne \u00e5 samhandle. Vi kan f\u00e5 en database til \u00e5 svikte, og da m\u00e5 vi omdirigere trafikken i produksjonsklyngen til den nye databasen, eller vi kan ha en klynge som svikter \u2013 og vi har g\u00e5tt over til reservel\u00f8sningen, men fortsetter \u00e5 jobbe med produksjonsdatabasen. Det tredje alternativet er n\u00e5r begge systemene svikter, og vi m\u00e5 omdirigere begge applikasjonene og overstyre konfigurasjonen v\u00e5r slik at de nye applikasjonene jobber med den nye databasen. <\/p>\n

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

    \"Reservasjon
    \n
    \nF\u00f8rste konklusjon: det er bra \u00e5 ha reservel\u00f8sning. Men det er dyrt. Ideelt sett b\u00f8r man ikke ha bare \u00e9n reservel\u00f8sning. Man b\u00f8r i realiteten ha flere reservel\u00f8sninger. For det f\u00f8rste, reservel\u00f8sningen b\u00f8r v\u00e6re minst i to forskjellige datasentre, og for det andre, helst hos en annen leverand\u00f8r. Dette har ofte skjedd \u2013 og i min erfaring har det v\u00e6rt tilfeller. Jeg kan dessverre ikke navngi prosjekter, spesielt da det brant i et datasenter... Jeg tenkte: n\u00e5 bytter vi til reservel\u00f8sning! Men de reserverte serverne sto i samme rack...<\/p>\n

    Eller tenk deg at Amazon blir sensurert i Russland (og det har skjedd). Og alt er \u00f8delagt: hva nyttig er det at reserven v\u00e5r ligger et annet sted hos Amazon? Det er ikke tilgjengelig heller. S\u00e5 la meg gjenta: hold reserve, minst i et annet datasenter, og helst \u2013 hos en annen leverand\u00f8r. <\/p>\n

    Den andre konklusjonen: hvis du i Kubernetes har en applikasjon som kommuniserer med eksterne kilder (det kan v\u00e6re en database eller et eksternt API), husk \u00e5 definere den som en tjeneste med ekstern endpoint, slik at n\u00e5r du skifter, slipper du \u00e5 distribuerer 15 applikasjoner som ber om den samme databasen. Definer databasen som en egen tjeneste, og kommuniser med den som om den var inne i klyngen: hvis databasen din krasjer, endrer du IP-en p\u00e5 ett sted og fortsetter \u00e5 leve lykkelig. <\/p>\n

    Og til slutt: jeg elsker 'kubikk', akkurat som jeg elsker eksperimenter med det. Jeg elsker ogs\u00e5 \u00e5 dele resultatene av disse eksperimentene og min personlige erfaring. Derfor har jeg laget en serie webinarer om K8s, velkommen til v\u00e5r YouTube-kanal<\/a><\/noindex> for mer informasjon.
    \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\udd47Reservasjon i Kubernetes: det eksisterer | ProHoster","description":"Jeg heter Sergey, jeg er fra selskapet ITSumma, og jeg vil fortelle dere hvordan vi tiln\u00e6rmer oss reservasjon i Kubernetes.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}