{"id":34596,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zhivut-li-bazy-dannyh-v-kubernetes\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"zhivut-li-bazy-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Elavad andmebaasid Kuberneteses?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Elavad
\n
\nAjalooliselt on IT-t\u00f6\u00f6stus jagunenud kaheks tinglikuks leeriks: need, kes on \"pool\" ja need, kes on \"vastu\". Ja teemad, mille \u00fcle vaieldakse, v\u00f5ivad olla t\u00e4iesti ettearvamatud. Milline operatsioonis\u00fcsteem on parem: Win v\u00f5i Linux? Kas nutitelefon peab olema Android v\u00f5i iOS? Kas hoida k\u00f5ik pilves v\u00f5i laadida need k\u00fclmade RAID-hoidlatele ja panna k\u00f5vakettad seifi? Kas PHP arendajad v\u00f5ivad end programmeerijateks nimetada? Need vaidlused on m\u00f5nikord rangelt eksistentsiaalsed ja neil ei ole mingit muud, peale spordihuvitava, alust.<\/p>\n

Nii ongi juhtunud, et koos konteinerite tekkimisega ja kogu selle armastatud Docker'i ja j\u00e4tkuva k8s'iga, algasid vaidlused \"poolte\" ja \"vastu\" uute v\u00f5imaluste kasutamise \u00fcle erinevates tagaridade valdkondades. (Enne algust tasub mainida, et kuigi antud arutelus kasutatakse orkestrimise t\u00f6\u00f6riistana sageli Kubernetes, ei ole selle t\u00f6\u00f6riista valik p\u00f5him\u00f5tteliselt oluline. Selle asemel v\u00f5ib kasutada mis tahes muud, mis tundub teile k\u00f5ige mugavam ja tuttavam.)<\/p>\n

Ja tundub, et see oleks lihtsalt vaidlus kahe poole vahel nagu kahepoolne m\u00fcnt. Niisama m\u00f5ttetu ja halastamatu, nagu igavene vastasseis Win vs Linux, kus adekvaatsed inimesed eksisteerivad kuskil keskel. Kuid konteineriseerimise osas ei ole k\u00f5ik nii lihtne. Tavalistes vaidlustes ei ole enamasti \u00f5igustavat poolt, kuid seisukohal \"kas rakendada\" v\u00f5i \"mitte rakendada\" konteinerid andmebaaside hoidmiseks p\u00f6\u00f6ratakse k\u00f5ik tagurpidi. Sest teatud m\u00f5ttes on nii pooldajad kui ka vastased selle l\u00e4henemise suhtes \u00f5iged.
\n<\/a><\/noindex><\/p>\n

Hea Pool<\/h4>\n

\nHea Poole argumendi l\u00fchike kirjeldamine v\u00f5ib mahtuda \u00fchte lausesse: \u201cHalloo, 2k19 on m\u00f6\u00f6das!\u201d See k\u00f5lab kahtlemata populistlikuna, kuid kui olukorraga p\u00f5hjalikult tutvuda, siis seal on oma eelised. N\u00fc\u00fcd vaatame neid l\u00e4hemalt.<\/p>\n

Oletame, et sul on suur veebiprojekt. See v\u00f5is algselt olla rajatud mikroteenuste l\u00e4henemisel v\u00f5i j\u00f5uda selleni evolutsioonilise tee kaudu \u2013 see pole tegelikult oluline. Sa jagasid oma projekti eraldi mikroteenusteks, seadistasid orkestreerimise, koormuse jaotamise, skaleeritavuse. Ja n\u00fc\u00fcd naudid rahuliku s\u00fcdamega m\u00e4hkides maltet, mitte ei t\u00f5sta maha kukkunud servereid. Kuid k\u00f5igis tegudes tuleb olla j\u00e4rjepidev. V\u00e4ga sageli konteineriseeritakse ainult rakendus ise \u2013 kood. Mis meil veel koodi k\u00f5rval on?<\/p>\n

\u00d5ige, andmed. Iga projekti s\u00fcda on selle andmed: need v\u00f5ivad olla nagu t\u00fc\u00fcpiline andmebaasis\u00fcsteem \u2013 MySQL, Postgre, MongoDB, samuti ladustamislahendused, mida kasutatakse otsinguks (ElasticSearch), key-value ladustamislahendused vahem\u00e4luks \u2013 n\u00e4iteks Redis jne. Praegu ei hakka me r\u00e4\u00e4kima kummalistest tagasiside lahendustest, kus andmebaas kukub alla halvasti kirjutatud p\u00e4ringute t\u00f5ttu, vaid r\u00e4\u00e4gime sellest, kuidas tagada selle andmebaasi t\u00f6\u00f6kindlus kliendi koormuse all. Sest kui me konteineriseerime oma rakenduse ja lubame sellel vabalt skaleeruda, et t\u00f6\u00f6delda mis tahes arvu sisendeid, suureneb paratamatult ka koormus andmebaasile.<\/p>\n

Tegelikult muutuvad andmebaasi ja serveri, kus see t\u00f6\u00f6tab, \u00fchenduspunktiks kitsaskoha meie kaunis konteineriseeritud tagaplaanis. Samal ajal on konteinerite virtualiseerimise p\u00f5hieesm\u00e4rk \u00fclesehituse liikuvus ja paindlikkus, mis v\u00f5imaldavad koormuse jaotamist meie kogu kergesti k\u00e4tte saadavas infrastruktuuris maksimaalselt efektiivselt. See t\u00e4hendab, et kui me ei konteineriseeri ja ei laota k\u00f5iki s\u00fcsteemi komponente klastrisse \u2013 teeme me v\u00e4ga t\u00f5sise vea.<\/p>\n

On logiilisem klasterdada mitte ainult rakendust, vaid ka teenuseid, mis vastutavad andmete salvestamise eest. Klasterdamisel ja iseseisvalt t\u00f6\u00f6tavate veebiserverite juurutamisel k8s-is lahendame me juba andmete s\u00fcnkroonimise probleemi \u2014 n\u00e4iteks kommentaaride postitustele, kui tuua n\u00e4itena m\u00f5ni meedia v\u00f5i blogiplatvorm. Meil on igal juhul loodud siseklaster, olgu see isegi virtuaalne, andmebaasi kujutis kui ExternalService. K\u00fcsimus on selles, et ise andmebaas ei ole hetkel klasterdatud \u2014 kubises juurutatud veebiserverid v\u00f5tavad teavet muudatuste kohta meie staatilisest tootmisandmebaasist, mis t\u00f6\u00f6tab eraldi.<\/p>\n

Kas tunnetad ohtu? Me kasutame k8s-i v\u00f5i Swarm'i koormuse jaotamiseks ning peamise langemise v\u00e4ltimiseks, veebiserver<\/a>, kuid me ei tee seda andmebaasi jaoks. Kuid kui andmebaas kukub, siis pole meie klasterdatud infrastruktuuri m\u00f5tet - mis kasu on meil t\u00fchi veebileht, mis tagastab andmebaasi juurdep\u00e4\u00e4suviga?<\/p>\n

Seet\u00f5ttu tuleb klasterdada mitte ainult veebiserverid, nagu tavaliselt tehakse, vaid ka andmebaasi infrastruktuur. Ainult sel viisil saame tagada, et k\u00f5ik funktsioneerib \u00fches paaris, kuid omavahel iseseisvana. Ja isegi kui meie tagaplaanist poole koormusega \u00abkukub\u00bb, j\u00e4\u00e4b \u00fclej\u00e4\u00e4nud ellu ning andmebaaside s\u00fcnkroonimise s\u00fcsteem klastris ja l\u00f5pmatu skaleerimise ja uute klastrite juurutamise v\u00f5imalus aitab kiiresti saavutada n\u00f5utavad v\u00f5imed - olgu andmehoidlatele andmekeskuses.<\/p>\n

Lisaks v\u00f5imaldab klasterdatud andmebaasimudel viia andmebaasi sinna, kus seda on vajalik; kui me r\u00e4\u00e4gime globaalset teenusest, on \u00fcsna ebaotstarbekas hoida veebiklaster kusagil San Franciscos ja samal ajal saata paketid andmebaasi poole Moskvas ja tagasi.<\/p>\n

Samuti v\u00f5imaldab andmebaasi konteinerimine t\u00f5sta k\u00f5ik s\u00fcsteemi elemendid \u00fchele abstraktsioonitasemele. See omakorda v\u00f5imaldab arendajatel seda s\u00fcsteemi otse koodist hallata, ilma et oleks vaja aktiivset administraatorite kaasamist. Arendajatel tuli m\u00f5te, et uut ala projekti jaoks on vaja eraldi andmebaasi - kergesti! Kirjutasid yaml-faili, laadisid selle klastrisse ja valmis.<\/p>\n

Ja loomulikult, sisemine haldamine lihtsustub mitmekordseks. \u00d6elge, kui sageli olete silmad kinni pigistanud hetkel, kui uus meeskonnaliige ulatab k\u00e4ed tootmisandmebaasi? Mis teil, t\u00f5eliselt, on olemas ja millega te praegu t\u00f6\u00f6tate? Loomulikult, me k\u00f5ik oleme t\u00e4iskasvanud inimesed ja kuskil on meil v\u00e4rske varukoopia, ning veel kaugemal \u2014 vanade kurkide ja suuskade taga \u2014 veel \u00fcks varukoopia, v\u00f5ib-olla isegi k\u00fclmhoidlas, sest teie kontor on juba kord p\u00f5lenud. Kuid ikkagi, iga uue meeskonnaliikme liitumine, kes p\u00e4\u00e4seb tootmisinfrastruktuuri ja loomulikult tootmisandmebaasi \u2014 see on k\u00f5ikidele \u00fcmbritsevatele \u00fcks suur rahustav tablett. Kes teab seda uuest tulijat? V\u00f5ib-olla on ta oskamatu? See on hirmutav, n\u00f5ustute.<\/p>\n

Konteineriseerimine ja sisuliselt teie projekti andmebaasi jaotatud f\u00fc\u00fcsiline topoloogia aitab selliseid rahustavaid olukordi v\u00e4ltida. Ei usalda uut t\u00f6\u00f6tajat? Pole probleemi! Loome talle iseseisva klastrit\u00f6\u00f6stuse ja lahutame selle \u00fclej\u00e4\u00e4nud andmebaasiklasteritest \u2014 s\u00fcnkroniseerimine ainult k\u00e4sitsi edastamise ja kahe v\u00f5tme s\u00fcnkroonse p\u00f6\u00f6ramise kaudu (\u00fcks tiimijuhile, teine administraatorile). Ja k\u00f5ik on \u00f5nnelikud.<\/p>\n

Ja n\u00fc\u00fcd on aeg astuda vastu andmebaasi klasteriseerimise vastastele.<\/p>\n

Tume Pool<\/h4>\n

\nM\u00f5eldes, miks ei peaks andmebaasi konteineriseerima ja seda \u00fchel kesksel seadmel t\u00f6\u00f6le panema, serveris<\/a>, ei lasku me ortodokside retoorikasse ja v\u00e4idete tasemeni, nagu \u201evanaemad t\u00f6\u00f6tasid andmebaasidega rauast, ja me teeme ka!\u201d Selle asemel proovime arendada olukorda, kus konteineriseerimine t\u00f5eliselt toob kaubal tugevat kasu.<\/p>\n

N\u00f5ustute, et projekte, mis t\u00f5eliselt vajavad andmebaasi konteineris, saab lugeda \u00fche halvima freesija s\u00f5rmedel. Enamikul juhtudel on lausa k8s v\u00f5i Docker Swarmi kasutamine liig, kuna neid t\u00f6\u00f6riistu kasutatakse \u00fcsna sageli ainult tehnoloogia ja seadmete \u201ek\u00f5rgemate\u201d soovituste t\u00f5ttu, et k\u00f5ik viia pilve ja konteineritesse. Noh, kuna see on praegu moes ja k\u00f5ik teevad seda.<\/p>\n

Poolha arvavad, et Kubernetes v\u00f5i Docker kasutamine projektis on enamasti \u00fcleliigne. K\u00fcsimus on selles, et mitte k\u00f5ik meeskonnad v\u00f5i infrastruktuuri hooldamiseks palgatud v\u00e4lisfirmad ei teadvusta seda. Halvem on see, kui konteinerid on sunnitud kasutusele, kuna see toob kliendile kaasa teatud kulud.<\/p>\n

\u00dcldiselt levinud arvamus on, et Docker\/K8s mafias lihtsalt allutab endale kliente, kes usaldavad need infrastruktuuri k\u00fcsimused v\u00e4lismaistele teenusepakkujatele. L\u00f5ppude l\u00f5puks, klastritega t\u00f6\u00f6tamiseks on vaja insenere, kes suudavad seda teha ja kes \u00fcldse m\u00f5istavad rakendatud lahenduse arhitektuuri. Oleme juba kirjeldanud oma juhtumit v\u00e4ljaande Republiciga \u2014 seal koolitasime kliendi meeskonda t\u00f6\u00f6tama Kubernetesese tingimustes, ja k\u00f5ik j\u00e4id rahule. See oli korralik. Kuid tihti v\u00f5tavad \u201erakendajad\u201c K8s-i kliendi infrastruktuuri pantvangi \u2014 sest n\u00fc\u00fcd m\u00f5istavad seda ainult nemad, kliendi poolel spetsialiste pole.<\/p>\n

Ja n\u00fc\u00fcd kujutage ette, et sel viisil anname mitte ainult veebiserveri osa v\u00e4liseks teenuseks, vaid ka andmebaasi hoolduse. Oleme \u00f6elnud, et andmebaas on s\u00fcda ja s\u00fcdame kaotus on fataalne igasuguste elusolendite jaoks. \u00dches\u00f5naga, perspektiivid pole k\u00f5ige paremad. Seega, hype'liku Kubernetes'e asemel peaks paljusid projekte lihtsalt mitte kokku hoidma normaalse AWS-i hinnataseme pealt, mis lahendab k\u00f5ik nende veebisaidi\/projekti koormusprobleemid. Kuid AWS ei ole enam moes, ja uhkus maksab rohkem kui raha \u2014 kahjuks ka IT-valdkonnas.<\/p>\n

Okei. V\u00f5ib-olla on projekti jaoks klasterdamine t\u00f5eliselt vajalik, kuid kui stateless-rakendustega on k\u00f5ik selge, siis kuidas korraldada korralikku v\u00f5rgukonne klasterdatud andmebaasi jaoks?<\/p>\n

Kui me r\u00e4\u00e4gime sujuvast insenerlahendusest, millega kaasneb \u00fcleminek k8s-ile, siis peamine mure on andmete replikatsioon klasterdatud andmebaasis. M\u00f5ned andmebaasid suhtuvad algselt suhteliselt leebelt andmete jaotamisse oma individuaalsete instantside vahel. Paljud teised ei ole siiski nii lahked. Ja \u00fcsna sageli ei ole peamine argument andmebaasi valikul meie projekti jaoks sugugi mitte suutlikkus replitseerida minimaalseid ressursi- ja insenerikulusid. Eriti kui projekt ei olnud algselt m\u00f5eldud mikroteenustena, vaid arenes lihtsalt sinna suunas. <\/p>\n

Arvatavasti ei ole vaja r\u00e4\u00e4kida v\u00f5rgudiskide t\u00f6\u00f6kiirusest \u2014 need on aeglased. See t\u00e4hendab, et meil ei ole reaalset v\u00f5imalust, kui midagi juhtub, tuua andmebaasi instants kuskile, kus on rohkem n\u00e4iteks protsessori v\u00f5imekust v\u00f5i vaba operatiivm\u00e4lu. Me j\u00f5uame v\u00e4ga kiiresti virtuaalsete distsipliinide tootlikkuse piiridesse. Seega peab andmebaas olema seotud oma isikliku masina komplektiga, mis asub otseses l\u00e4heduses. V\u00f5i tuleb kuidagi eraldi luua piisavalt kiire andmete s\u00fcnkroonimise lahendus kavandatud reservide jaoks. <\/p>\n

J\u00e4tkates teemat virtuaalsetest failis\u00fcsteemidest: Docker Volume'ide probleemid ei ole kahjuks kadunud. \u00dcldiselt oleks soovitav pikaajalise usaldusv\u00e4\u00e4rse andmete s\u00e4ilitamise osas kasutada maksimaalselt lihtsaid tehnilisi skeeme. Uue abstraktsioonikihi lisamine konteineri failis\u00fcsteemist vanema hosti failis\u00fcsteemi \u2014 on juba ise risk. Kuid kui s\u00fcsteemis, mis tagab konteinerit, tekivad keerukused andmete edastamisel nende kihtide vahel, siis on asi t\u00f5eliselt hull. Praeguseks on enamik tuntud progressiivsete probleemide lahendatud. Kuid te m\u00f5istate, et mida keerulisem on mehhanism, seda t\u00f5en\u00e4olisem on, et see puruneb.<\/p>\n

K\u00f5ikide nende \"seikluste\" valguses on palju kasulikum ja lihtsam hoida andmebaasi \u00fches kohas, ning isegi kui teil on vaja rakenduse konteineriseerimist \u2014 las see t\u00f6\u00f6tab iseseisvalt ja p\u00e4\u00e4seb jaotuss\u00fcsteemi kaudu samal ajal andmebaasiga, mis loetakse ja kirjutatakse vaid \u00fcks kord ja \u00fches kohas. Selline l\u00e4henemine v\u00e4hendab vigade ja des\u00fcnkroniseerimise t\u00f5en\u00e4osust minimaalseteks v\u00e4\u00e4rtusteks.<\/p>\n

Kuhu me j\u00f5uame? T\u00f5demuseni, et andmebaasi konteineriseerimine on asjakohane seal, kus see on t\u00f5eliselt vajalik. Te ei saa mahutada andmebaasi t\u00e4israkenduse ja k\u00e4itada seda nii, nagu teil oleks kaks tosinat mikroteenust \u2014 see ei t\u00f6\u00f6ta nii. Ja seda tuleb selgelt m\u00f5ista.<\/p>\n

V\u00e4ljundi asemel<\/h4>\n

\nKui te ootate arusaadavat vastust k\u00fcsimusele \"kas virtualiseerida andmebaas v\u00f5i mitte\", siis peame teid pettuma: sellist vastust siin ei tule. Sest iga infrastruktuuri lahenduse loomisel tuleb l\u00e4htuda mitte moest ja arengust, vaid eesk\u00e4tt terve m\u00f5istuse p\u00f5him\u00f5tetest.<\/p>\n

On projekte, kuhu p\u00f5him\u00f5tted ja t\u00f6\u00f6riistad, mis tulevad koos Kubernetesega, sobivad ideaalselt, ja sellistes projektides saavutatakse rahu v\u00e4hemalt tagumises osas. Kuid on projekte, mis vajavad mitte konteineriseerimist, vaid normaalset serveri infrastruktuuri, sest nad ei suuda p\u00f5him\u00f5tteliselt mikroteenuste klastrimudeli alla \u00fcmber skaaleerida, muidu kukuvad nad kokku.
\n
Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e \u043b\u044e\u0431\u043e\u043c\u0443 \u043f\u043e\u0432\u043e\u0434\u0443 \u0440\u0430\u0437\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u0443\u0441\u043b\u043e\u0432\u043d\u044b\u0445 \u043b\u0430\u0433\u0435\u0440\u044f: \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u0437\u0430\u00bb \u0438 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u043f\u0440\u043e\u0442\u0438\u0432\u00bb. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u0441\u043f\u043e\u0440\u043e\u0432 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u043c. \u041a\u0430\u043a\u0430\u044f \u041e\u0421 \u043b\u0443\u0447\u0448\u0435: Win \u0438\u043b\u0438 Linux? \u041d\u0430 \u0441\u043c\u0430\u0440\u0442\u0444\u043e\u043d\u0435 Android \u0438\u043b\u0438 iOS? \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u0432 \u043e\u0431\u043b\u0430\u043a\u0430\u0445 \u0438\u043b\u0438 \u0437\u0430\u043b\u0438\u0432\u0430\u0442\u044c \u043d\u0430 \u0445\u043e\u043b\u043e\u0434\u043d\u044b\u0435 RAID-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0438 \u043a\u043b\u0430\u0441\u0442\u044c \u0432\u0438\u043d\u0442\u044b \u0432 \u0441\u0435\u0439\u0444? \u0418\u043c\u0435\u044e\u0442 \u043b\u0438 PHP-\u0448\u043d\u0438\u043a\u0438 \u043f\u0440\u0430\u0432\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-34596","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\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\udd47Kas andmebaasid elavad Kuberneteses? | ProHoster","description":"Nii on ajaloos kujunenud, et IT-t\u00f6\u00f6stus on.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\u0416\u0438\u0432\u0443\u0442 \u043b\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Kubernetes? | ProHoster","og:description":"\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34596","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 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-02-09 21:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}