{"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\/hr\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Rezervacija u Kubernetesu: ona postoji","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zovem se Sergey, iz kompanije ITSumma, i \u017eelim vam ispri\u010dati kako pristupamo rezervaciji u Kubernetesu. U posljednje vrijeme puno se bavim konzultantskim radom na 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 rezervaciji u slo\u017eenim arhitekturama, imao sam izlaganje o rezervaciji \u201ekubika\u201c, i evo njegovog slobodnog prepri\u010davanja. Samo unaprijed upozoravam da to nije neposredni vodi\u010d za akciju, ve\u0107 vi\u0161e op\u0107enito razmatranje navedene teme.<\/p>\n

\"Rezervacija
\n
\nU principu, pra\u0107enje i rezervacija su dva osnovna alata za pove\u0107anje otpornosti bilo kojeg projekta. Ali, vi \u0107ete re\u0107i, u K8s se sve balansira samo, sve se samo skalira, i ako se ne\u0161to dogodi \u2013 to \u0107e se samo podi\u0107i... Dakle, prilikom prvog povr\u0161nog istra\u017eivanja teme, internet mi je odgovorio na pitanje kako se tko pribli\u017eava rezervaciji K8s s \"a za\u0161to?\" Mnogi misle da K8s predstavlja neku \u010darobnu stvar koja eliminira sve infrastrukturne probleme i osigurava da projekt nikada ne padne. Ali... svijet nije ono \u0161to izgleda.
\n<\/a><\/noindex>
\nKako smo pristupali procesu rezervacije ranije? Imali smo identi\u010dne platforme za hostanje \u2013 bile su to ili virtualne ma\u0161ine, ili fizi\u010dki serveri servere<\/a>, kojima smo primjenjivali tri osnovne prakse: <\/p>\n

    \n
  1. synchronize code and static files<\/li>\n
  2. synchronize configurations<\/li>\n
  3. replicate databases<\/li>\n<\/ol>\n

    \nI voil\u00e0: u svakom trenutku prebacujemo se na rezervnu platformu, svi su sretni, ustajemo i razilazimo se. <\/p>\n

    \"Rezervacija
    \n
    \n\u0160to nam se nudi za pove\u0107anje stalne dostupnosti na\u0161e Kubernetes aplikacije? Prvo, o \u010demu govori neformalne dokumentacija \u2014 to je postaviti vi\u0161e strojeva, napraviti vi\u0161e mastera \u2014 njihovo bi brojstvo trebalo zadovoljiti uslove za postizanje kvoruma unutar klastera, a da na svakom od mastera bude podignuto etcd, api, MC, scheduler\u2026 I, \u010dini se, sve je divno: kada nekoliko radnih \u010dvorova ili mastera izostane, na\u0161 klaster se preraspore\u0111uje, a aplikacija nastavlja raditi. Opet izgleda kao \u010darolija! No, \u010desto se na\u0161 klaster nalazi unutar jednog centra podataka i to mo\u017ee izazvati odre\u0111ena pitanja. \u0160to ako do\u0111e bager i iskopava kabel, udari munja, dogodi se univerzalna poplava? Sve je propalo, na\u0161eg klastera vi\u0161e nema. Kako pristupiti rezervaciji uzimaju\u0107i u obzir ovu stranu problema? <\/p>\n

    Prije svega, trebate imati jo\u0161 jedan klaster u vru\u0107oj rezervi, dakle klaster na koji se mo\u017eete prebaciti u bilo tren. S obzirom na Kubernetes, infrastrukture moraju biti potpuno identi\u010dne. Dakle, ako postoje nesstandardni pluginovi za rad s datote\u010dnim sustavom, prilago\u0111ena rje\u0161enja za ingress, ona moraju biti potpuno identi\u010dna na va\u0161im dva (ili tri, ili deset, tu ve\u0107 koliko ima novca i snage admina) klastera. Potrebno je jasno odrediti dva skupa aplikacija (deploymenta, statefulseta, daemonseta, cronjobova itd.): koje od njih mogu raditi na rezervi kontinuirano, a koje bi bolje bilo ne pokretati do neposrednog prebacivanja. <\/p>\n

    Treba li na\u0161 rezervni klaster biti potpuno identi\u010dan na\u0161em produkcijskom klasteru? Ne. Ako smo ranije u okviru rada s monolitnim projektima, s fizi\u010dkom infrastrukturom odr\u017eavali gotovo potpuno identi\u010dno okru\u017eenje, u okviru Kubernetesa, mislim da to ne bi trebalo biti tako. Poglejmo za\u0161to.<\/p>\n

    Na primjer, krenimo od osnovnih entiteta kubernetes-a \u2014 deployments \u2013 oni moraju biti identi\u010dni. Aplikacije trebaju biti pokrenute koje mogu u bilo kojem trenutku preuzeti obradu prometa i omogu\u0107iti na\u0161em projektu da nastavi s radom. Kada govorimo o datotekama s konfiguracijom, moramo obratiti pa\u017enju na to trebaju li one biti identi\u010dne ili ne. Dakle, ako mi, pametni ljudi, ne koristimo nikakve nedozvoljene supstance i ne dr\u017eimo bazu u K8s, tada bi u configmaps-ima trebale biti postavke pristupa produkcijskoj bazi (proces rezervacije \u043a\u043e\u0442\u043e\u0440\u043e\u0439 je izgra\u0111en zasebno). U skladu s tim, za osiguranje pristupa rezervnoj instanci baze podataka, moramo imati zasebnu datoteku s konfiguracijom (configmap). Isto tako radimo i sa secret-ima: lozinkama za pristup bazi, api-klju\u010devima; u bilo kojem trenutku mo\u017ee raditi ili produkcijski secret ili rezervni. U kona\u010dnici, ve\u0107 imamo dva entiteta kubernetes-a, \u010dije rezervne verzije ne bi trebale biti identi\u010dne produkcijskim. Sljede\u0107i entitet na kojem se trebamo zaustaviti \u2014 cronjob. Cronjob-ovi na rezervi nikako ne bi trebali biti identi\u010dni skupu cronjob-ova produkcijskog klastera! Ako podi\u017eemo rezervni klaster i di\u017eemo ga potpuno sa svim uklju\u010denim cronjob-ovima \u2014 na primjer, ljudi \u0107e od vas primati dva e-maila istovremeno umjesto jednog. Ili neka sinkronizacija podataka s vanjskim izvorima \u0107e se odvijati dva puta, u skladu s tim po\u010dinjemo bolovati, plakati, vri\u0161tati i psovati. <\/p>\n

    \"Rezervacija
    \n
    \nA kako nam predla\u017eu organizirati rezervni klaster ljudi s interneta? Drugi najpopularniji odgovor nakon \u201ea za\u0161to?\u201c \u2014 kori\u0161tenje Kubernetes Federation. <\/p>\n

    \u0160to je to? To je, recimo, veliki meta-klaster. Ako zamisliamo arhitekturu Kubernetesa \u2014 gdje imamo majstora, nekoliko \u010dvorova \u2014 s obzirom na federaciju, tako\u0111er imamo majstora i nekoliko \u010dvorova, samo \u0161to je svaki \u010dvor poseban klaster. Dakle, radimo s istim entitetima, s istim primitvima kao i s jedinstvenim Kubernetesom, samo \u0161to ne upravljamo na\u0161im fizi\u010dkim strojevima, ve\u0107 cijelim klasterima. U okviru federacije doga\u0111a se potpuna sinkronizacija federativnih resursa od roditelja prema potomcima. Na primjer, ako smo pokrenuli neku implementaciju putem federacije \u2014 ona \u0107e se implementirati na svaki na\u0161 pod-klaster. Ako uzmemo neki configmap, tajni klju\u010d i distribuiramo ga putem federacije \u2014 on \u0107e se pro\u0161iriti na sve na\u0161e pod-klastere; pritom federacija omogu\u0107ava prilagodbu na\u0161ih resursa na potomstvom. Dakle, uzeli smo neki configmap, implementirali ga putem federacije, a zatim, ako trebamo ne\u0161to prilagoditi na odre\u0111enim klasterima, idemo ga mijenjati na posebnom klasteru, i ta promjena se vi\u0161e ne\u0107e sinkronizirati. <\/p>\n

    Kubernetes Federacija \u2014 relativno nov alat koji ne podr\u017eava cijeli set resursa koje nudi K8s: u trenutku objave jedne od prvih verzija dokumentacije govorilo se o podr\u0161ci samo za config-mape, deployment u replicaset-u i ingress. Tajni podaci nisu bili podr\u017eani, a rad s volume-ima tako\u0111er nije bio podr\u017ean. Skup resursa je previ\u0161e ograni\u010den. Osobito ako volimo eksperimentirati \u2014 na primjer, kori\u0161tenjem custom resource definition-a za prijenos vlastitih resursa Kubernetes-u, u federaciju ih ne mo\u017eemo dodati. Drugim rije\u010dima, rje\u0161enje je donekle realno, ali nas \u010desto dovodi u neugodnu situaciju. S druge strane, federacija omogu\u0107ava fleksibilno upravljanje na\u0161im replicaset-om. Na primjer, \u017eelimo imati 10 replika na\u0161e aplikacije; federacija \u0107e po defaultu proporcionalno rasporediti taj broj me\u0111u klasterima. I to se mo\u017ee dodatno konfigurirati! Mo\u017eemo navesti da na produkcijskom klasteru treba dr\u017eati 6 replika na\u0161e aplikacije, dok na rezervnom klasteru, radi u\u0161tede resursa ili vlastitog u\u017eitka \u2014 samo 4 replike. To je tako\u0111er prili\u010dno zgodno. No, s federacijom moramo koristiti neka nova rje\u0161enja, ne\u0161to dodavati u hodu, prisiliti se na malo vi\u0161e razmi\u0161ljanja\u2026 <\/p>\n

    Mo\u017ee li se pristupiti procesu rezerviranja kubera na jednostavniji na\u010din? Koji alati su nam uop\u0107e dostupni?<\/p>\n

    Prvo, uvijek imamo neku ci\/cd sistem, \u0161to zna\u010di da ne idemo ru\u010dno, ne pi\u0161emo na serverima create\/apply. Sustav generira yaml fajlove za na\u0161e kontejnere. <\/p>\n

    Drugo, imamo nekoliko klastera, imamo ili jedan, ili vi\u0161e (ako smo pametni) registry, koji smo tako\u0111er uzeli i rezervirali. A tu je i izvrsna utilita kubectl koja mo\u017ee raditi s vi\u0161e klastera istovremeno. <\/p>\n

    \"Rezervacija
    \n
    \nDakle, po mom mi\u0161ljenju, najjednostavnije i najispravnije rje\u0161enje za izgradnju rezervnog klastera je primitivni paralelni deploy. Postoji neki pipeline u ci\/cd sustavu; prvo gradimo na\u0161e kontejnere, testiramo i raspore\u0111ujemo aplikacije putem kubectl na nekoliko neovisnih klastera. Mo\u017eemo ostavljati simultane izdanja na nekoliko klastera. Prema tome, dostavu konfiguracija tako\u0111er rje\u0161avamo u ovoj fazi. Mo\u017eemo unaprijed odrediti skup konfiguracija za na\u0161 proizvodni klaster, skup konfiguracija za rezervni klaster i na razini ci\/cd sustava rasporediti produkcijsko okru\u017eenje u proizvodni klaster, a rezervno okru\u017eenje u rezervni klaster. U usporedbi s federacijom, ne trebamo i\u0107i nakon odre\u0111ivanja federalnog resursa na svaki podre\u0111eni klaster i ne\u0161to ponovno definirati. To smo ve\u0107 uradili. Kakvi smo mi genijalci.<\/p>\n

    No... postoji... napisao sam ranije, postoji \u201ekorijen svih problema\u201c, ali ih zapravo ima dva. Prvo, datote\u010dni sustav. Postoji neki PV, ili koristimo vanjsko skladi\u0161te. Ako pohranjujemo datoteke unutar klastera, trebamo postupati prema starim praksama koje su preostale iz vremena fizi\u010dkih infrastruktura: na primjer, sinkronizirati lsync-om. Ili nekim drugim alatima koje osobno preferirate. Sve premjestiti na druge strojeve i \u017eivjeti.<\/p>\n

    Drugo, i, zapravo, jo\u0161 va\u017enija to\u010dka spora \u2014 baza podataka. Ako smo pametni ljudi i ne dr\u017eimo bazu unutar kubera, tada je proces rezervacije podataka prema istoj staroj shemi \u2014 master-slave replikacija, zatim prebacivanje, dostignemo replikaciju i \u017eivimo dobro. No ako \u0107emo dr\u017eati na\u0161 DB unutar klastera, onda u na\u010delu ima mnogo gotovih rje\u0161enja za organizaciju iste master-slave replikacije, mnogo rje\u0161enja za pokretanje DB unutar kubera.
    \n O rezervaciji baza podataka ve\u0107 je pro\u010ditano milijun izvje\u0161taja, napisano milijun \u010dlanaka, ni\u0161ta novo ovdje, zapravo, nije potrebno. U svakom slu\u010daju, slijedite svoje snove, \u017eivite kako \u017eelite, izmi\u0161ljajte si neke slo\u017eene mu\u010dne nijanse, ali svakako razmislite kako \u0107ete sve to rezervirati.<\/p>\n

    A sada o tome kako \u0107e se, u na\u010delu, odvijati proces prebacivanja na rezervnu lokaciju u slu\u010daju po\u017eara. Prvo, paralelno otvaramo stateless aplikacije. One ne utje\u010du na poslovnu logiku na\u0161ih aplikacija, na\u0161eg projekta, mo\u017eemo kontinuirano odr\u017eavati dva skupa pokrenutih aplikacija i one mogu po\u010deti primati promet. Veoma je va\u017eno tijekom prebacivanja na rezervnu lokaciju obavezno provjeriti \u2014 treba li redefinirati konfiguracije? Na primjer, imamo produkcijski Kubernetes klaster, imamo rezervni Kubernetes klaster, imamo vanjsku bazu podataka master i rezervnu bazu podataka master. Imamo \u010detiri opcije kako te aplikacije u produkciji mogu po\u010deti me\u0111usobno komunicirati. Mo\u017ee se prebaciti baza, a onda bi trebalo u produkcijskom klasteru preusmjeriti promet na novu bazu, ili se mo\u017ee dogoditi kvar klastera \u2014 i pre\u0161li smo na rezervu, ali nastavljamo raditi s produkcijskom bazom, i tre\u0107a opcija je kada se ovo i ono pokvari, i prebacujemo obje aplikacije, redefiniramo na\u0161u konfiguraciju, kako bi nove aplikacije radile s novom bazom podataka. <\/p>\n

    Dakle, kakve se zaklju\u010dke mo\u017ee iz toga izvu\u0107i? <\/p>\n

    \"Rezervacija
    \n
    \nPrvi zaklju\u010dak: imati rezervu je dobro. Ali skupo. Idealno je ne \u017eivjeti s jednom rezervom. Idealno je imati vi\u0161e rezervi. Prvo, rezerva ne bi trebala biti barem u jednom podatkovnom centru, i drugo, barem kod drugog hostera. \u010cesto se doga\u0111alo \u2014 i u mojoj praksi je tako bilo. Na\u017ealost, ne mogu nazivljati projekte, kao kad se dogodio po\u017ear u data centru\u2026 Rekao sam: prebacujemo se na rezervu! A rezervni serveri su stajali u istoj ormaru...<\/p>\n

    Ili zamislite da je Amazon zabranjen u Rusiji (a to se dogodilo). I sve: kakva je korist od toga \u0161to na\u0161 rezervni server le\u017ei u drugom Amazonu? I on je tako\u0111er nedostupan. Tako da \u0107u ponoviti: dr\u017eimo rezervu, barem u drugom podatkovnom centru, a po\u017eeljno \u2014 kod drugog hostera. <\/p>\n

    Drugi zaklju\u010dak: ako va\u0161e aplikacije u Kubernetes-u komuniciraju s nekim vanjskim izvorima (to mo\u017ee biti i baza podataka ili neki vanjski API), obavezno ga definirajte kao servis s vanjskim Endpoint-om, kako ne biste morali ponovno deployati 15 svojih aplikacija koje se povezuju na istu bazu prilikom prebacivanja. Definirajte bazu kao zaseban servis i povezujte se s njom kao da je unutar va\u0161eg klastera: ako vam baza propadne, samo promijenite IP na jednom mjestu i nastavite \u017eivjeti sretno. <\/p>\n

    I za kraj: volim 'kubik', kao i eksperimentiranje s njim. Tako\u0111er volim dijeliti rezultate tih eksperimenata i svoje osobno iskustvo. Zato sam snimio seriju webinara o K8s, dobrodo\u0161li na na\u0161 YouTube kanal<\/a><\/noindex> za detalje.
    \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 Sergey, iz kompanije ITSumma, i \u017eelim vam re\u0107i kako pristupamo rezerviranju u Kubernetesu.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}