{"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\/et\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Kuberneteses reservatsioon: see eksisteerib","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Minu nimi on Sergei, ma olen ettev\u00f5ttest ITSumma ja tahan r\u00e4\u00e4kida, kuidas me l\u00e4heneme varundamisele Kuberneteses. Viimasel ajal olen palju n\u00f5ustamist\u00f6\u00f6d teinud erinevate devops-lahenduste rakendamise nimel, t\u00f6\u00f6tades erinevate meeskondadega, sealhulgas projektides, mis kasutavad K8s-i. Uptime day 4 konverentsil, kus arutati keerukate arhitektuuride varundamist, esitlesin ettekannet \"kuubiku\" varundamisest ning see on selle vabalt t\u00f5lgendatud kokkuv\u00f5te. Avalikult tahan eelnevalt m\u00e4rkida, et see ei ole otsene juhend, vaid pigem toimetuslik kokkuv\u00f5te antud teemal.<\/p>\n

\"Kuberneteses
\n
\nP\u00f5him\u00f5tteliselt on j\u00e4lgimine ja varundamine kaks peamist t\u00f6\u00f6riista, mis suurendavad projekti t\u00f5rketaluvust. Aga kas Kubernetesis ei ole k\u00f5ik ise tasakaalus, k\u00fcsiksite te? K\u00f5ik skaleerub automaatselt ja kui midagi juhtub, siis t\u00f5useb see ise... See t\u00e4hendab, et esmapilgul teema uurimisel vastas internet mulle k\u00fcsimusele, kuidas l\u00e4henetakse K8s-i varundamisele, 'miks \u00fcldse?'. Paljud arvavad, et Kubernetes on nagu maagiline t\u00f6\u00f6riist, mis vabastab k\u00f5ikidest infrastruktuuri probleemidest ja tagab, et projekt ei kuku kunagi kokku. Kuid... maailm ei ole see, milleks see n\u00e4ib.
\n<\/a><\/noindex>
\nKuidas me varundamisprotsessi varem l\u00e4henesime? Meil olid identsed teenusepakkujad \u2013 kas see olid virtuaalmasinad v\u00f5i f\u00fc\u00fcsilised serverid, serverid<\/a>, millele rakendasime kolme p\u00f5hipraktikat: <\/p>\n

    \n
  1. koodi ja staatika s\u00fcnkroniseerimine<\/li>\n
  2. konfiguratsioonide s\u00fcnkroniseerimine<\/li>\n
  3. andmebaasi replikatsioon<\/li>\n<\/ol>\n

    \nJa voil\u00e0: igal ajal saame \u00fcle l\u00fclituda varuplatsile, k\u00f5ik on \u00f5nnelikud, t\u00f5usame ja lahkume. <\/p>\n

    \"Kuberneteses
    \n
    \nMida meile pakutakse meie kubernetes-rakenduse pideva k\u00e4ttesaadavuse suurendamiseks? Esimene asi, millest \u00fctleb mitteametlik dokumentatsioon, on paigaldada palju masinaid, luua palju meistreid - nende arv peaks rahuldama kvorumi saavutamise tingimusi klastris ja et iga meistri juures oleks t\u00f6\u00f6s etcd, api, MC, scheduler\u2026 Ja n\u00e4ib, et k\u00f5ik on suurep\u00e4rane: kui m\u00f5ned t\u00f6\u00f6noodid v\u00f5i meistrid rikki l\u00e4hevad, siis meie klaster tasakaalustatakse \u00fcmber ja rakendus t\u00f6\u00f6tab edasi. J\u00e4lle n\u00e4eb see v\u00e4lja nagu maagia! Kuid tihti on meie klaster \u00fche andmekeskuse raames ja see v\u00f5ib tekitada teatud k\u00fcsimusi. Mis juhtub, kui kaevur tuleb ja kaevab kaabli \u00fcles, v\u00e4lk l\u00f6\u00f6b, toimub universaalne uputus? K\u00f5ik on katki, meie klastrit enam pole. Kuidas l\u00e4heneda varundamisele arvestades seda probleemipoolt? <\/p>\n

    Esiteks peaks teil olema veel \u00fcks klaster sooja varuna, st klaster, millele saate igal ajal \u00fcle minna. Samuti peaksid infrastruktuuri poolest olema klastrid t\u00e4iesti identsed. See t\u00e4hendab, et kui on mingeid mitte-standardseid pluginaid failis\u00fcsteemiga t\u00f6\u00f6tamiseks, kohandatud lahendusi ingressiks, peavad need olema teie kahel (v\u00f5i kolmel, v\u00f5i k\u00fcmnel, siin on see juba raha ja administraatorite j\u00f5upingutuste k\u00fcsimus) klastril t\u00e4iesti identsed. Tuleb selgelt m\u00e4\u00e4ratleda kaks rakenduste (deployment\u2019ide, statefulset\u2019ide, daemonset\u2019ide, cronjob\u2019ide jne) komplekti: millised neist v\u00f5ivad pidevalt t\u00f6\u00f6tada varunduses ja milliseid on parem mitte k\u00e4ivitada enne otsest \u00fcleminekut. <\/p>\n

    Kas meie varundusklaster peaks olema t\u00e4iesti identne meie tootmisclusteriga? Ei. Kui varem monoliitsetes projektides, rauainfrastruktuuris hoidsime praktiliselt t\u00e4ielikult identset keskkonda, siis kubernekesis ma arvan, et seda ei tohiks olla. Vaatame, miks.<\/p>\n

    N\u00e4iteks alustame Kubernetes'i p\u00f5hielementidest - deployments - need peavad olema identsed. Rakendused peavad olema k\u00e4ivitatud ja olema valmis igal ajal liiklust \u00fcmber suunama, et meie projekt saaks j\u00e4tkata oma tegevust. Kui r\u00e4\u00e4gime konfiguratsioonifailidest, tuleb vaadata, kas need peavad olema identsed v\u00f5i mitte. See t\u00e4hendab, et kui me, arukad inimesed, ei tarbi mingeid keelatud aineid ja ei hoia andmebaasi K8s, siis meie configmaps'ides peavad olema juurdep\u00e4\u00e4suseaded tootmisandmebaasi (reservimiseks on see protsess eraldi loodud). Vastavalt peavad meil olema eraldi konfiguratsioonifail (configmap) varundatud andmebaasi juurdep\u00e4\u00e4sude tagamiseks. Samuti t\u00f6\u00f6tame secret'itega: andmebaasi juurdep\u00e4\u00e4supassword'id, API v\u00f5tmed; igal ajahetkel v\u00f5ib meil olla kas tootmis- v\u00f5i varukoopia secret. Seega omame juba kahte Kubernetes'e elementi, mille varukoopiad ei tohiks olla identsed tootmisversioonidega. J\u00e4rgmine element, milles tasub peatuda, on cronjob. Cronjob'id varukoopias ei tohiks mingil juhul olla identsed tootmisklastri cronjob'idega! Kui me t\u00f5stame varuklastri ja t\u00f5stame selle \u00fcles koos k\u00f5igi t\u00f6\u00f6tavate cronjob'idega, siis n\u00e4iteks saavad inimesed kaks e-kirja korraga, mitte \u00fchte. V\u00f5i toimub andmete s\u00fcnkroniseerimine v\u00e4liste allikatega kaks korda, mist\u00f5ttu hakkame haigeks j\u00e4\u00e4ma, nutma, karjuma ja vanduma. <\/p>\n

    \"Kuberneteses
    \n
    \nKuidas meedia teab, kuidas korraldada varuklastrit? Teine populaarne vastus peale \u201emiks?\u201d \u2014 Kubernetes Federationi kasutamine. <\/p>\n

    Mis see on? See on, \u00fctleme nii, suur meta-klaster. Kui me kujutame ette kube arhitektuuri \u2014 kus meil on meester, mitu s\u00f5lme \u2014 siis f\u00f6deratsiooni vaatenurgast on meil samuti meister ja mitu s\u00f5lme, ainult et iga s\u00f5lm on eraldi klaster. See t\u00e4hendab, et me t\u00f6\u00f6tame nende samade ents\u00fcklopediate ja primitiividega, nagu tavalise kube puhul, ainult et toimetame mitte meie f\u00fc\u00fcsiliste masinatega, vaid tervete klastritega. F\u00f6deratsiooni raames toimub t\u00e4ielik f\u00f6deratiivsete ressursside s\u00fcnkroonimine vanematest j\u00e4reltulijatele. N\u00e4iteks kui me k\u00e4ivitame mingi deployment'i l\u00e4bi f\u00f6deratsiooni \u2014 see paigaldatakse igasse meie t\u00fctarklastrisse. Kui me v\u00f5tame m\u00f5ne konfiguratsioonikaardi, salajase, ja rakendame seda f\u00f6deratsioonis \u2014 see levib k\u00f5igisse meie t\u00fctarklastritesse; samal ajal v\u00f5imaldab f\u00f6deratsioon meil kohandada meie ressursse lastes. See t\u00e4hendab, et me v\u00f5tsime m\u00f5ne konfiguratsioonikaardi, paigaldasime selle l\u00e4bi f\u00f6deratsiooni ja siis, kui meil on vaja midagi konkreetset, me muudame seda eraldi klastris ning see muudatus ei s\u00fcnkroonita enam kuhugi. <\/p>\n

    Kubernetes Federation on hiljuti v\u00e4ljakujunenud t\u00f6\u00f6riist, mis ei toeta kaugeltki kogu ressursside komplekti, mida K8s ise pakub: dokumentatsiooni \u00fche esimeses versioonis \u00f6eldi, et toetatakse ainult konfiguratsioonikaardid, replika-seeria all oleva juurutamise ja sissep\u00e4\u00e4su. Salajased andmed ei olnud toetatud, samuti ei olnud v\u00f5imalik t\u00f6\u00f6tada mahtudega. Liiga piiratud valik. Eriti kui me armastame katsetada, \u2014 n\u00e4iteks l\u00e4bi kohandatud ressurssi m\u00e4\u00e4ratlemise edastada oma ressursid Kubernetesesse, \u2014 ei saa me neid federaatsiooni suruda. Teisis\u00f5nu\u2026 see on nagu t\u00f5ele l\u00e4hedane lahendus, kuid sunnib meid aeg-ajalt endale jalga tulistama. Teisest k\u00fcljest v\u00f5imaldab federaatsioon paindlikult hallata meie replika-seeriat. N\u00e4iteks, kui me soovime k\u00e4ivitada 10 koopiat meie rakendusest, jagab federaatsioon selle numbri automaatselt proportsionaalselt klastrite arvuga. Ja seda on v\u00f5imalik veel konfigureerida! Saame m\u00e4\u00e4rata, et tootmisklastris peame hoidma 6 koopiat meie rakendusest, ja reservklastris, et ressursse s\u00e4\u00e4sta v\u00f5i oma l\u00f5buks \u2014 ainult 4 koopiat meie rakendusest. Mis on samuti piisavalt mugav. Kuid federaatsiooni kasutamisel peame rakendama uusi lahendusi, midagi juurutama jooksvalt, sunname end veidi rohkem m\u00f5tlema\u2026 <\/p>\n

    Kas saaksime l\u00e4heneda Kubernetes'i varundamisprotsessile kuidagi lihtsamalt? Millised t\u00f6\u00f6riistad meil \u00fcldse on?<\/p>\n

    Esiteks on meil alati mingisugune CI\/CD s\u00fcsteem, mis t\u00e4hendab, et me ei k\u00e4i k\u00e4sitsi, ega kirjuta serverites create\/apply. S\u00fcsteem genereerib YAML-failid meie konteinerite jaoks. <\/p>\n

    Teiseks on mitu klastrit, meil on kas \u00fcks v\u00f5i mitu (kui me oleme targad) registrit, mille oleme samuti reserveerinud. Ja meil on suurep\u00e4rane utiliit kubectl, mis oskab t\u00f6\u00f6tada mitme klastri jaoks samaaegselt. <\/p>\n

    \"Kuberneteses
    \n
    \nNii et: minu arvates on k\u00f5ige lihtsam ja \u00f5igem lahendus varukoopia klastrite \u00fclesehitamiseks primitiivne paralleelne deploy. Seal on mingi CI\/CD s\u00fcsteemis t\u00f6\u00f6tav pipeline; esmalt anname ehituse meie konteineritele, testime ja seadistame rakendusi kubectl kaudu mitmesse s\u00f5ltumatutesse klastrisse. Saame teha samal ajal v\u00e4ljalaskeid mitmesse klastrisse. Seega lahendame konfiguratsioonide edastamise ka sel hetkel. Saame eelnevalt m\u00e4\u00e4rata konfiguratsioonide kogumi meie tootmisklastri jaoks, varuklastri konfiguratsioonide kogumi ning CI\/CD s\u00fcsteemi tasemel levitada tootmisv\u00e4lja tootmisklastrisse, varuv\u00e4lja varuklastrisse. V\u00f5rreldes f\u00f6deratsiooniga pole p\u00e4rast f\u00f6deratiivse ressursi kindlaksm\u00e4\u00e4ramist vaja iga mahakantud klastrisse minna ja midagi \u00fcletada. Oleme selle eelnevalt teinud. Kui toredad me oleme.<\/p>\n

    Aga\u2026 on\u2026 ma olin kirjutanud, et on \"k\u00f5igi h\u00e4dade juur\", kuid neid on tegelikult kaks. Esiteks, failis\u00fcsteem. On mingi PV, v\u00f5i kasutame v\u00e4lisladust. Kui me salvestame faile klastris sees, siis tuleb siin j\u00e4rgida vanu praktikaid, mis on tulnud raudsete infrastruktuuride ajast: n\u00e4iteks s\u00fcnkroniseerida lsync’iga. V\u00f5i m\u00f5ne muu teie isiklikult eelistatud lahendusega. Laseme k\u00f5ik teistele masinatele ja elame edasi.<\/p>\n

    Teiseks, ja tegelikult isegi olulisem takistuspunkt \u2014 andmebaas. Kui me oleme targad inimesed ja ei hoia andmebaasi kuberenetes, siis andmete varundamise protsess on sama vana skeemi j\u00e4rgi \u2014 master-slave replikatsioon, siis l\u00fclitus ja replikatsioon, hoidke andmebaas k\u00e4imas ja elame h\u00e4sti. Kuid kui me hoiame oma andmebaasi klastris, siis on olemas palju valmis lahendusi master-slave replikatsiooni korraldamiseks, palju lahendusi andmebaasi k\u00e4ivitamiseks kuberenetes.
    \n Andmebaaside varundamisest on juba miljard ettekannet peetud, kirjutatud miljard artiklit, midagi uut siin tegelikult ei ole. \u00dcldiselt j\u00e4rgige oma unistusi, elage nagu soovite, leiutage endale ka m\u00f5ned keerulised abivahendid, kuid m\u00f5elge kindlasti, kuidas te k\u00f5ike seda varundate.<\/p>\n

    Ja n\u00fc\u00fcd r\u00e4\u00e4gime sellest, kuidas p\u00f5him\u00f5tteliselt toimub meie protsess varus\u00fcsteemile \u00fcleminek tulekahju korral. Esiteks paigaldame paralleelselt stateless-rakendusi. Need ei m\u00f5juta meie rakenduste, meie projekti \u00e4riloogikat. Saame pidevalt hoida kahte k\u00e4ivitatud rakenduste komplekti, mis v\u00f5ivad hakata liiklust vastu v\u00f5tma. \u00dclemineku protsessi k\u00e4igus on v\u00e4ga oluline j\u00e4lgida, kas konfiguratsioone on vaja \u00fcmber seadistada. N\u00e4iteks, meil on tootmiscluster Kuberneteses, meil on varucluster Kuberneteses, meil on v\u00e4line andmebaas master ja meil on varu andmebaas master. Meil on neli v\u00f5imalust, kuidas need rakendused tootmises saavad omavahel suhelda. Andmebaas v\u00f5ib minna vahetusse ja selgub, et tootmisclusteris tuleb liiklus suunata uuele andmebaasile, v\u00f5i meie cluster v\u00f5ib minna katki \u2014 ja me oleme \u00fcle l\u00e4inud varu peal, aga j\u00e4tkame t\u00f6\u00f6tamist tootmisandmebaasiga, ning kolmas variant on see, kui see on katki ja too on katki, ja me suuname m\u00f5lemad rakendused \u00fcmber, seadistame meie konfiguratsiooni nii, et uued rakendused t\u00f6\u00f6tavad juba uue andmebaasiga. <\/p>\n

    Ja mis j\u00e4reldused me k\u00f5ik sellest teha saame? <\/p>\n

    \"Kuberneteses
    \n
    \nEsimene j\u00e4reldus: varuga on hea elada. Aga see on kallis. Ideaalis ei tohiks elada ainult \u00fche varuga. Ideaalis peaks olema mitu varu. Esiteks peab varu olema v\u00e4hemalt mitte \u00fches andmekeskuses ja teiseks, v\u00e4hemalt teise teenusepakkuja juures. Sageli on olnud nii \u2014 ja minu praktikas on see t\u00f5esti juhtunud. Kahjuks ei saa ma projekte nimetada, kui just ajal, kui toimus tulekahju andmekeskuses\u2026 Ma \u00fctlesin: l\u00fclitame varule \u00fcle! Ja varu serverid olid sama rack'i sees...<\/p>\n

    V\u00f5i kujutage ette, et Amazon on Venemaal blokeeritud (ja see on juhtunud). Ja k\u00f5ik: mis kasu on sellest, et teises amazonis on meie varu? See ei ole ka ju k\u00e4tte saadav. Seega kordasin: hoidke varu v\u00e4hemalt teises andmekeskuses ja soovitavalt \u2014 teise teenusepakkuja juures. <\/p>\n

    Teine j\u00e4reldus: kui teie Kuberneteses rakendus suhtleb mingite v\u00e4liste allikatega (see v\u00f5ib olla kas andmebaas v\u00f5i m\u00f5ni v\u00e4line API), m\u00e4\u00e4rake see kindlasti teenusena koos v\u00e4lise l\u00f5pp-punktiga, et vahetamise hetkel ei peaks 15 teie rakendust uuesti juurutama, mis p\u00e4\u00e4sevad samasse andmebaasi. M\u00e4\u00e4rake andmebaas eraldi teenusena, p\u00f6\u00f6rduge selle poole nagu see oleks teie klastris: kui teie andmebaas peaks kokku kukkuma, muudate \u00fches kohas IP-d ja elate edasi \u00f5nnelikult. <\/p>\n

    Ja l\u00f5petuseks: ma armastan \"kuubikut\", nagu ka eksperimente selle alusel. Mulle meeldib jagada nende katsete tulemusi ja \u00fcldiselt oma isiklikku kogemust. Seet\u00f5ttu olen salvestanud K8si kohta veebiseminaride seeria, olete oodatud meie YouTube'i kanalile<\/a><\/noindex> lisainfot saama.
    \n
    Allikas:     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\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\udd47Varukoopiad Kuberneteses: need eksisteerivad | ProHoster","description":"Mina olen Sergei, olen ITSumma ettev\u00f5ttest ja tahan teile r\u00e4\u00e4kida, kuidas me l\u00e4heneme varukoopiate tegemisele Kuberneteses.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","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\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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/33773","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=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}