{"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\/sl\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u044d\u0442\u043e \u0440\u0435\u0430\u043b\u044c\u043d\u043e","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Moje ime je Sergey, iz tvrtke ITSumma, i \u017eelim vam ispri\u010dati kako pristupamo rezerviranju u Kubernetesu. U posljednje vrijeme puno sam se bavio savjetovanjem o implementaciji raznih devops rje\u0161enja za razli\u010dite timove, a posebno radim na projektima koji koriste K8s. Na konferenciji Uptime day 4, koja je bila posve\u0107ena rezerviranju u slo\u017eenim arhitekturama, odr\u017eao sam izlaganje o rezerviranju 'kubika', i evo njegovog slobodnog sa\u017eetka. Samo unaprijed \u017eelim upozoriti da to nije neposredni vodi\u010d za akciju, ve\u0107 vi\u0161e zbirka razmi\u0161ljanja o navedenoj temi.<\/p>\n

\"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435
\n
\nU osnovi, pra\u0107enje i rezerviranje su dva osnovna alata za pove\u0107anje otpornosti bilo kojeg projekta. No, kako vi ka\u017eete, u K8s se sve samo balansira, sve se samo skalira, i ako se ne\u0161to dogodi - samo \u0107e se pokrenuti... Dakle, na prvo povr\u0161no istra\u017eivanje teme, internet mi je odgovorio na pitanje kako tko pristupa rezerviranju K8s sa 'za\u0161to?'. Mnogi misle da K8s predstavlja neku \u010darobnu stvar koja osloba\u0111a od svih infrastrukturnih problema i \u010dini da projekt nikada ne propadne. Ali... svijet nije ono \u0161to se \u010dini.
\n<\/a><\/noindex>
\nKako smo ranije pristupali procesu rezerviranja? Imali smo identi\u010dne platforme za hosting - bile su to ili virtualne ma\u0161ine ili fizi\u010dki serveri servere<\/a>, na koje smo primjenjivali tri osnovne prakse: <\/p>\n

    \n
  1. synchronizacija koda i statike<\/li>\n
  2. synchronizacija konfiguracija<\/li>\n
  3. replikacija baza podataka<\/li>\n<\/ol>\n

    \nI voila: u svakom trenutku prebacujemo se na rezervnu platformu, svi su sretni, ustajem-i-odlazimo. <\/p>\n

    \"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435
    \n
    \nKaj nam ponujajo za pove\u010danje stalne dostopnosti na\u0161e aplikacije Kubernetes? Prvo, o \u010demer govori neformalna dokumentacija, je postaviti veliko naprav, ustvariti veliko master naprav \u2014 njihovo \u0161tevilo mora zadovoljiti pogoje za dosego quoruma znotraj klasterja, in da ima vsak od masterjev zagnan etcd, api, MC, scheduler\u2026 In, tako se zdi, je vse \u010dudovito: ko ve\u010d delovnih vozli\u0161\u010d ali master naprav ne deluje, se na\u0161 klaster preuredi in aplikacija \u0161e naprej deluje. Spet zgleda kot \u010darovnija! Ampak pogosto se na\u0161 klaster nahaja v okviru enega podatkovnega centra, kar lahko povzro\u010di dolo\u010dene te\u017eave. Kaj pa, \u010de pride buldo\u017eer in izkoplje kabel, udari strela, pride do potopa? Vse je propadlo, na\u0161ega klasterja ni ve\u010d. Kako pristopiti k rezervaciji ob upo\u0161tevanju te plati problema? <\/p>\n

    Najprej morate imeti \u0161e en klaster v vro\u010di rezervi, torej klaster, na katerega se lahko kadarkoli preklopite. Pri tem morata biti z vidika Kubera infrastruktura popolnoma enaka. Torej, \u010de obstajajo kak\u0161ni nestandardni vti\u010dniki za delo z datote\u010dnim sistemom, prilagojene re\u0161itve za ingress, morajo biti popolnoma enake na va\u0161ih dveh (ali treh, ali desetih, koliko denarja in truda upraviteljev zado\u0161\u010da) klasterjih. Potrebno je jasno opredeliti dva sklopa aplikacij (deploymentov, statefulsetov, daemonsetov, cronjobov itd.): katere od njih lahko neprekinjeno delujejo na rezervi, in katere je bolje ne zagnati do neposrednega preklopa. <\/p>\n

    Ali mora biti na\u0161 rezervni klaster popolnoma identi\u010den na\u0161emu produkcijskemu klasterju? Ne. \u010ce smo prej v okviru dela z monolitnimi projekti, z \u017eelezno infrastrukturo, ohranjali skoraj popolnoma identi\u010dno okolje, pa v okviru Kubera menim, da to ne bi smelo biti. Poglejmo, zakaj.<\/p>\n

    Na primer, za\u010dnimo z osnovnimi entitetami Kubernetes-a \u2014 deployments \u2013 morali bi biti identi\u010dni. Morajo biti zagnane aplikacije, ki lahko kadar koli prevzamejo obdelavo prometa in omogo\u010dijo, da na\u0161 projekt \u0161e naprej \u017eiv\u00ed. Ko govorimo o konfiguracijskih datotekah, moramo presoditi, ali morajo biti identi\u010dne ali ne. To pomeni, da \u010de smo, pametni ljudje, ne uporabljamo nobenih prepovedanih substanc in ne hranimo baze v K8s, potem bi morale biti v configmaps-ih nastavitve dostopov do produkcijske baze (postopek rezervacije katere je zgrajen lo\u010deno). Ustrezno, da bi zagotovili dostop do rezervnega primera podatkovne baze, moramo imeti lo\u010deno konfiguracijsko datoteko (configmap). Na enak na\u010din delamo tudi s secret-i: gesli za dostop do baze, api-klju\u010di; kadarkoli lahko deluje bodisi produkcijski secret bodisi rezervni. Tako imamo \u017ee dve entiteti Kubernetes, katerih rezerva ne bi smela biti identi\u010dna produkcijski. Naslednja entiteta, na katero se moramo ustaviti, je cronjob. Cronjob-i na rezervi nikakor ne bi smeli biti identi\u010dni naboru cronjob-ov produkcijskega grozda! \u010ce dvignemo rezervni grozd in ga dvignemo popolnoma z vsemi vklju\u010denimi cronjob-i \u2014 potem, na primer, ljudje prejemajo od vas dve sporo\u010dili hkrati namesto enega. Ali pa bo kak\u0161na sinhronizacija podatkov z zunanjimi viri potekala dvakrat, zato za\u010denjemo obolevati, jokati, kri\u010dati in se kregati. <\/p>\n

    \"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435
    \n
    \nKako pa nam predlagajo, da organiziramo rezervni klaster ljudje s spleta? Drugi najbolj priljubljen odgovor po \"zakaj?\" \u2013 uporaba Kubernetes Federation. <\/p>\n

    Kaj je to? To je, recimo, velika meta-klaster. \u010ce si zamislimo arhitekturo Kuber, kjer imamo master in ve\u010d nod, imamo z vidika federacije tudi master in ve\u010d nod, le da je vsaka nod lo\u010den klaster. To pomeni, da delamo z istimi entitetami, z istimi primitivi kot pri enotnem Kuberju, le da ne delamo s fizi\u010dnimi stroji, ampak s celotnimi klasterji. V okviru federacije poteka popolna sinhronizacija federativnih virov od star\u0161ev do potomcev. Na primer, \u010de smo zagnali kak\u0161en deployment preko federacije \u2014 ta se bo namestil na vsak na\u0161 podklaster. \u010ce vzamemo kak\u0161en configmap, skrivnost in ga raz\u0161irimo po federaciji \u2014 se bo raz\u0161iril na vse na\u0161e podklastre; pri tem pa federacija omogo\u010da prilagajanje na\u0161ih virov na otrocih. Torej smo vzeli kak\u0161en configmap, ga namestili preko federacije in nato, \u010de moramo kaj popraviti na dolo\u010denih klasterjih, gremo popraviti na posameznem klasterju, in ta sprememba se ne bo sinhronizirala nikamor. <\/p>\n

    Kubernetes Federation je relativno nov alat koji ne podr\u017eava potpuni skup resursa koji pru\u017ea sam K8s: u trenutku objavljivanja jedne od prvih verzija dokumentacije navedeno je da podr\u017eava samo config-mape, deployment pod replica-set, ingress. Tajni podaci nisu podr\u017eani, rad sa volume-ima tako\u0111e nije podr\u017ean. Izuzetno ograni\u010den set. Pogotovo kada volimo da se zabavljamo, \u2014 na primer, koriste\u0107i custom resource definition za prenos sopstvenih resursa u Kubernetes, \u2014 ve\u0107 ih ne mo\u017eemo gurnuti u federaciju. Odnosno, kao i\u2026 re\u0161enje koje izgleda kao istina, ali nas povremeno natera da si pucamo u nogu. S druge strane, federacija omogu\u0107ava fleksibilno upravljanje na\u0161im replicaset-om. Na primer, \u017eelimo da imamo pokrenutih 10 replika na\u0161e aplikacije, a po defaultu federacija \u0107e podeliti taj broj proporcionalno izme\u0111u broja klastera. I to sve mo\u017eemo dodatno konfigurisati! Tako da mo\u017eemo odrediti da na produkcionom klasteru treba da imamo 6 replika na\u0161e aplikacije, a na rezervnom klasteru, radi u\u0161tede resursa, ili zbog na\u0161ih sopstvenih zabava \u2014 samo 4 replike na\u0161e aplikacije. \u0160to je tako\u0111e prili\u010dno zgodno. Ali sa federacijom moramo koristiti neka nova re\u0161enja, ne\u0161to dodatno deploy-ovati u hodu, naterati sebe da malo vi\u0161e razmi\u0161ljamo... <\/p>\n

    Ali lahko do procesa rezerviranja kubernetes pristopimo na kak\u0161en enostavnej\u0161i na\u010din? Kateri na\u010dini so nam na voljo?<\/p>\n

    Najprej imamo vedno neko ci\/cd sistem, torej ne hodimo ro\u010dno, ne pi\u0161emo na stre\u017enikih create\/apply. Sistem generira yaml datoteke za na\u0161e kontejnere. <\/p>\n

    Drugi\u010d, obstaja ve\u010d grozdov, imamo ali enega ali ve\u010d (\u010de smo pametni) registry, ki smo ga prav tako rezervirali. In obstaja \u010dudovita utilita kubectl, ki lahko deluje z ve\u010d grozdi hkrati. <\/p>\n

    \"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435
    \n
    \nTako da, po mom mi\u0161ljenju, najjednostavnije i ispravno re\u0161enje za izgradnju rezervnog klastera je jednostavan paralelni deploy. Postoji neki pipeline u ci\/cd sistemu; prvo gradimo na\u0161e kontejnere, testiramo i postavljamo aplikacije preko kubectl na nekoliko nezavisnih klastera. Mo\u017eemo praviti istovremena izdanja na vi\u0161e klastera. Samim tim, isporuku konfiguracija tako\u0111e re\u0161avamo u ovoj fazi. Mo\u017eemo unapred definisati set konfiguracija za na\u0161 borbeni klaster, set konfiguracija za rezervni klaster i na nivou ci\/cd sistema postavljati produkciono okru\u017eenje u produkcijski klaster, a rezervno okru\u017eenje u rezervni klaster. U pore\u0111enju s federacijom, ne moramo i\u0107i nakon definisanja federiranog resursa na svaki podklaster i ne\u0161to predefinisati. To smo uradili unapred. Kakvi smo majstori.<\/p>\n

    Ali\u2026 postoji\u2026 bio sam napisao, postoji \u201ekor\u0435\u043d svih zala\u201c, ali ih zapravo ima dva. Prvo, datote\u010dni sistem. Postoji neki PV, ili koristimo spolja\u0161nje skladi\u0161te. Ako \u010duvamo datoteke unutar klastera, tada treba delovati po starim praksama koje su ostale iz vremena \u010dvrste infrastrukture: na primer, sinhronizovati lsync-om. Pa ili bilo kojim drugim re\u0161enjem koje li\u010dno preferirate. Raspore\u0111ujemo sve na druge ma\u0161ine i \u017eivimo.<\/p>\n

    Drugo, i zapravo, \u010dak i va\u017enija ta\u010dka sporenja \u2014 baza podataka. Ako smo pametni ljudi i ne dr\u017eimo bazu u kuberu, onda je proces rezervisanja podataka po istoj staroj \u0161emi \u2014 master-slave replikacija, pa prebacivanje, replikaciju \u0107emo uhvatiti i \u017eiveti dobro. Ali ako \u0107emo dr\u017eati na\u0161u DB unutar klastera, onda zapravo ima mnogo spremnih re\u0161enja za organizovanje iste master-slave replikacije, mnogo re\u0161enja za pokretanje DB unutar kubera.
    \n O rezervisanju baza podataka je ve\u0107 pro\u010ditano milijardu izlaganja, napisano milijardu \u010dlanaka, ni\u0161ta novo ovde, u stvari, nije potrebno. U su\u0161tini, sledite svoje snove, \u017eivite kako \u017eelite, izmi\u0161ljajte sebi tako\u0111e neke slo\u017eene re\u0161itse, ali obavezno razmislite kako \u0107ete sve to rezervisati.<\/p>\n

    In this section, we will discuss how the process of switching to a backup site will take place in the event of a fire. First of all, we deploy stateless applications in parallel. They do not affect the business logic of our applications and our project, allowing us to maintain two sets of running applications that can start receiving traffic. It is crucial to check during the switching process to the backup site whether configuration needs to be overridden. For example, we have a production Kubernetes cluster, a backup Kubernetes cluster, an external master database, and a backup master database. There are four options for how these applications in production can start interacting with each other. The database may switch, and traffic may need to be redirected to the new database in the production cluster, or the cluster could fail, causing us to switch to backup but continue operating with the production database. The third scenario involves both the application and the cluster failing, requiring us to switch both applications and redefine our configuration so that the new applications work with the new database. <\/p>\n

    So, what conclusions can we draw from all of this? <\/p>\n

    \"\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435
    \n
    \nFirst conclusion: having a backup is good, but it\u2019s expensive. Ideally, one shouldn\u2019t rely on a single backup. It\u2019s best to have multiple backups. First, the backup should not be located in just one data center, and second, it should ideally be with a different host. I have encountered situations like this in my experience. Unfortunately, I can't name the projects, but there was a fire in a data center... and I was like: we are switching to the backup! Only to find out that the backup servers were in the same rack.<\/p>\n

    Or imagine if Amazon was banned in Russia (and that has happened). What\u2019s the point of having our backup stored in another Amazon if it\u2019s also inaccessible? So once again: we should have a backup, at least in a different data center, and preferably with another host. <\/p>\n

    Drugi zaklju\u010dak: ako va\u0161a aplikacija u Kubernetes-u komunicira sa nekim spoljim izvorima (to mo\u017ee biti i baza podataka i neko spoljno API), obavezno je defini\u0161ite kao servis sa spoljnim EndPoint-om, kako biste u trenutku.prebacivanja izbegli ponovni deploy 15 va\u0161ih aplikacija koje se povezuju na istu bazu. Defini\u0161ite bazu kao poseban servis, pove\u017eite se sa njom kao da vam je unutar klastera: ako vam se baza sru\u0161i, menjate IP na jednom mestu i nastavljate da \u017eivite sre\u0107no. <\/p>\n

    I na kraju: volim 'kocku', kao i eksperimentiranje s njom. Tako\u0111er volim dijeliti rezultate tih eksperimenta i svoja osobna iskustva. Stoga sam snimio seriju webinara o K8s, dobrodo\u0161li na na\u0161 youtube kanal<\/a><\/noindex> za vi\u0161e informacija.
    \n
    Izvor:     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\udd47Rezerviranje u Kubernetesu: postoji | ProHoster","description":"Zovem se Sergej, iz kompanije ITSumma, i \u017eelim vam ispri\u010dati kako pristupamo rezerviranju u Kubernetesu.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}