{"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 reserveerimine: see eksisteerib","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Minu nimi on Sergei, olen ITSumma ettev\u00f5ttest ja tahan r\u00e4\u00e4kida, kuidas me l\u00e4heneme Kuberneteses varukoopiate tegemisele. Viimasel ajal olen palju tegelenud konsultatsioonitegevusega erinevate DevOps lahenduste juurutamisel erinevatele meeskondadele ning eriti olen t\u00f6\u00f6tanud K8s projektidega. Uptime p\u00e4eva 4. konverentsil, mis oli p\u00fchendatud keeruliste arhitektuuride varukoopiatele, esitasin ettekande varukohtade kohta \"kuubikus\", ja siin on selle vabalt koostatud kokkuv\u00f5te. Kuid enne mainin, et see ei ole otsene tegevusjuhend, vaid pigem \u00fclevaade m\u00f5tetest antud teema kohta.<\/p>\n

\"Kuberneteses
\n
\nP\u00f5him\u00f5tteliselt on monitorimine ja reserveerimine kaks peamist t\u00f6\u00f6riista, et suurendada iga projekti talitlush\u00e4irekindlust. Aga te \u00fctlete, et Kubernetesis toimub k\u00f5ik tasakaalustamine automaatselt, k\u00f5ik skaleerub iseseisvalt ja kui midagi juhtub, t\u00f5useb see iseenesest... Esimese, pinnapealse teema uurimise k\u00e4igus vastas internet k\u00fcsimusele, kuidas keegi l\u00e4heneb K8s-i reserveerimisele, et \"miks?\" Paljud arvavad, et Kubernetes on maagiline lahendus, mis vabastab k\u00f5ikidest infrastruktuursetest probleemidest ja tagab, et projekt ei kuku kunagi kokku. Aga... maailm ei ole see, mida see n\u00e4ib.
\n<\/a><\/noindex>
\nKuidas me l\u00e4henesime reserveerimise protsessile varem? Meil olid identsed platvormid, kas virtuaalmasinad v\u00f5i f\u00fc\u00fcsilised serverid, serverid<\/a>, millele me rakendasime kolme p\u00f5hipraktikat: <\/p>\n

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

    \nJa voil\u00e0: igal hetkel saame vahetada varuplaatvormile, k\u00f5ik on \u00f5nnelikud, t\u00f5usime ja lahkume. <\/p>\n

    \"Kuberneteses
    \n
    \nMida pakutakse meie Kubernetes rakenduse pideva k\u00e4ttesaadavuse suurendamiseks? Esimene asi, millest \u00fctleb mitteformaalse dokumentatsiooni j\u00e4rgi \u2014 on paigutada palju masinaid, luua palju mastereid \u2014 nende arv peab vastama kvoorumi n\u00f5uetele klastris, ja igal masteril peab olema \u00fcles t\u00f5stetud etcd, api, MC, scheduler\u2026 Ja nagu k\u00f5ik oleks suurep\u00e4rane: kui mitu t\u00f6\u00f6node v\u00f5i masterit eba\u00f5nnestub, siis meie klaster tasakaalustub \u00fcmber ja rakendus j\u00e4tkab t\u00f6\u00f6d. See k\u00f5ik tundub nagu v\u00f5lu! Kuid sageli asub meie klaster \u00fches andmekeskuses, mis v\u00f5ib tekitada teatud k\u00fcsimusi. Mis juhtub, kui ekshaator tuleb ja kaevab kaabli \u00fcles, kui l\u00f6\u00f6b v\u00e4lk, v\u00f5i toimub universaalne tulv? K\u00f5ik on l\u00f5ppenud, meie klastrit enam pole. Kuidas l\u00e4heneda varundamisele, arvestades selle probleemi k\u00fclge? <\/p>\n

    Esmalt, teil peab olema veel \u00fcks klaster kuumaks varuks, st klaster, millele saate igal hetkel \u00fcle minna. Sel juhul peavad infrastruktuurid Kubernetes'i seisukohalt olema t\u00e4ielikult identsed. See t\u00e4hendab, et kui teie failis\u00fcsteemil on mingeid ebatavalisi pluginaid, kohandatud lahendusi ingressi jaoks, siis peavad need olema t\u00e4ielikult identsed teie kahel (v\u00f5i kolmel, v\u00f5i k\u00fcmnel, s\u00f5ltuvalt sellest, kui palju raha ja adminnide j\u00f5udu on) klastril. Tuleb selgelt m\u00e4\u00e4ratleda kaks rakenduste (deploymentide, statefulsetide, daemonsetide, cronjobide jne) komplekti: millised neist v\u00f5ivad pidevalt t\u00f6\u00f6tada varuklastris, ja milliseid ei tasuks \u00fcldse k\u00e4ivitada enne \u00fcleminekut. <\/p>\n

    Kas meie varuklaster peab olema t\u00e4ielikult identne meie tootmisklastriga? Ei. Kui varem monoliitsete projektide ning rauainfrastruktuuri t\u00f6\u00f6 k\u00e4igus hoidsime praktiliselt t\u00e4ielikult identses keskkonnas, siis Kubernetes'i kontekstis ei peaks seda olema. Vaatame, miks.<\/p>\n

    N\u00e4iteks alustame Kubernetes'i p\u00f5hielementidest \u2014 deployments \u2014 need peavad olema identsed. Peavad olema aktiivsed rakendused, mis saavad igal hetkel liiklust juhtida ja v\u00f5imaldavad meie projektil j\u00e4tkata toimimist. Kui r\u00e4\u00e4gime konfigureerimisfailidest, tuleb vaadata, kas need peaksid olema identsed v\u00f5i mitte. Teisis\u00f5nu, kui me, targad inimesed, ei tarbi mingeid keelatud aineid ja ei hoia oma andmeid K8s, siis peavad meie configmap'id sisaldama juurdep\u00e4\u00e4su seadistusi tootmisbaasile (mille varundusprotsess on korraldatud eraldi). Vastavalt sellele, et tagada juurdep\u00e4\u00e4s varukoopia andmebaasile, peame omama eraldi konfigureerimisfaili (configmap). Just nii t\u00f6\u00f6tame ka secret\u2019itega: paroolide jaoks andmebaasile juurde p\u00e4\u00e4semiseks, API v\u00f5tmetega; igal hetkel v\u00f5ib meil olla kas tootmissecret v\u00f5i varukoopia. Seet\u00f5ttu on meil juba kaks Kubernetes'i elementi, mille varukoopiad ei tohi olla identsed tootmissektiga. J\u00e4rgmine element, millele tuleks t\u00e4helepanu p\u00f6\u00f6rata, on cronjob. Varukoopia cronjob'id ei tohi mingil juhul olla identsed tootmisklastri cronjob'idega! Kui t\u00f5stame varuklastri ja aktiveerime selle koos k\u00f5ikide cronjob'idega, siis n\u00e4iteks saavad inimesed teie k\u00e4est kaks kirja korraga, mitte \u00fchte. V\u00f5i andmete s\u00fcnkroniseerimine v\u00e4liste allikatega toimub kaks korda, mist\u00f5ttu hakkame haigeks j\u00e4\u00e4ma, nutma, karjuma ja vanduma. <\/p>\n

    \"Kuberneteses
    \n
    \nAga kuidas soovitavad inimesed internetis varundusklastri korraldada? Teine populaarne vastus peale \u201emiks?\u201d on Kubernetes Federation'i kasutamine. <\/p>\n

    Mis see on? See on, \u00fctleme nii, suur meta-klaster. Kui me kujutame ette Kuberneetside arhitektuuri \u2014 kus meil on juht ja mitmed s\u00f5lmed \u2014 siis f\u00f6deratsiooni vaates on meil samuti juht ja mitmed s\u00f5lmed, ainult et iga s\u00f5lm on eraldi klaster. See t\u00e4hendab, et me t\u00f6\u00f6tame nende samade elementide ja primitiividega nagu \u00fcksiku Kuberneetsi puhul, ainult et p\u00f6\u00f6rame ja keerame mitte meie f\u00fc\u00fcsilisi masinaid, vaid terveid klastreid. F\u00f6deratsiooni raames toimub meil t\u00e4ielik f\u00f6deratiivsete ressursside s\u00fcnkroniseerimine vanematelt j\u00e4rglastele. N\u00e4iteks, kui me k\u00e4ivitame m\u00f5ne juurutamise l\u00e4bi f\u00f6deratsiooni \u2014 see juurutatakse meie iga t\u00fctarklastrisse. Kui me v\u00f5tame mingi configmap\u2019i, salajase info, ja levitame selle f\u00f6deratsiooni kaudu \u2014 see laieneb k\u00f5igisse meie t\u00fctarklastreisse; samas v\u00f5imaldab f\u00f6deratsioon meie ressursside kohandamist lastes. See t\u00e4hendab, et me v\u00f5tsime mingi configmap'i, juurutame selle l\u00e4bi f\u00f6deratsiooni ja seej\u00e4rel, kui me peame midagi spetsiifilist t\u00fckkide j\u00e4rgi kohandama, l\u00e4heme ja muudame seda \u00fcksikusse klastrisse, ja see muudatus ei s\u00fcnkroniseeru enam kuskile. <\/p>\n

    Kubernetes Federation on vaid \u00fcsna uus t\u00f6\u00f6riist, mis ei toeta k\u00f5iki ressursse, mida K8s endaga kaasas kannab: dokumentatsiooni \u00fche esimeses v\u00e4ljaandes \u00fctles, et toetatakse ainult konfiguratsiooni kaarte, replika komplekti, ingressi. Salajasi ei toetatud, samuti ei olnud toeks volume t\u00f6\u00f6. Liialt piiratud valik. Eriti kui me armastame l\u00f5butseda, \u2014 n\u00e4iteks edastades oma ressursse Kubernetesesse l\u00e4bi custom resource definition \u2014 ei saa me neid f\u00f6deratsioonile suruda. Nii et\u2026 see on tulemusi andev lahendus, aga paneb meid aeg-ajalt endale jalga tulistama. Teiselt poolt v\u00f5imaldab f\u00f6deratsioon paindlikult hallata meie replicaset'i. N\u00e4iteks tahame, et meie rakenduse oleks 10 koopiat t\u00f6\u00f6le pandud, siis jagab f\u00f6deratsioon selle arvu automaatselt klastrite vahel. Ja seda k\u00f5ike saab veel ka konfigureerida! Saame m\u00e4\u00e4rata, et tootmisklastris peab olema 6 koopiat meie rakendusest, ja varuklastris, et ressursse s\u00e4\u00e4sta v\u00f5i oma l\u00f5bustuste nimel \u2014 ainult 4 koopiat meie rakendusest. Mis on samuti \u00fcsna mugav. Kuid f\u00f6deratsiooni puhul peame kasutama uusi lahendusi, midagi kohe paigaldama, sundima ennast natuke rohkem m\u00f5tlema\u2026 <\/p>\n

    Kas saaksime k\u00fcberprotsessi lihtsamalt l\u00e4heneda? Millised t\u00f6\u00f6riistad meil \u00fcldse olemas on?<\/p>\n

    Esiteks on meil alati mingi CI\/CD s\u00fcsteem, seega me ei l\u00e4he k\u00e4sitsi, ei kirjuta serverites create\/apply. S\u00fcsteem genereerib YAML-failid meie konteinerite jaoks. <\/p>\n

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

    \"Kuberneteses
    \n
    \nNii et: minu arvates on k\u00f5ige lihtsam ja t\u00f5husam lahendus varukoopia klastrite loomine primitiivne paralleelne juurutamine. On olemas mingi CI\/CD s\u00fcsteem, mille kaudu ehitame meie konteinerid, testime neid ja juurutame rakendusi l\u00e4bi kubectl mitmesse s\u00f5ltumatusse klastrisse. Me saame samal ajal luua v\u00e4ljaandeid mitmesse klastrisse. Vastavalt sellele lahendame ka konfigureerimise kohaletoimetamise sellel etapil. Saab ette m\u00e4\u00e4rata konfigureerimise kogumi meie tootmistgeh\u00fcsteemile, konfigureerimise komplekti varuklastrile ja CI\/CD s\u00fcsteemi tasandil juurutada tootmis\u00fcmbruse tootmisklastri, varuooperi varuklastrisse. Erinevalt f\u00f6deratsioonist ei pea p\u00e4rast f\u00f6deratiivse ressursi m\u00e4\u00e4ramist minema iga t\u00fctarklastri juurde ja midagi \u00fcmber m\u00e4\u00e4rama. Oleme selle eelnevalt valmis teinud. Kuidas me oleme kenad.<\/p>\n

    Aga... on... ma kirjutasin, et \"k\u00f5ikide kurjade alusteks\" on kaks asja. Esiteks, failis\u00fcsteem. On olemas mingi PV, kas me kasutame v\u00e4list salvestust. Kui hoiame faile klastris, siis tuleb j\u00e4rgida vanu praktikaid, mis on j\u00e4\u00e4nud meelevaldse infrastruktuuri ajast: n\u00e4iteks s\u00fcnkroonida lsync'iga. V\u00f5i m\u00f5ne muu isiklikult eelistatud lahendusega. Laotame k\u00f5ik teistele masinatele ja elame edasi.<\/p>\n

    Teiseks, ja tegelikult isegi olulisem takistuspunkt \u2014 andmebaas. Kui me oleme intelligentsed inimesed ja ei hoia andmebaasi kuber-networkis, siis andmete varundamine sama vana skeemi j\u00e4rgi \u2014 master-slave replikatsioon, siis vahetame ja rebime repliika j\u00e4rele ning elame h\u00e4sti. Kuid kui me hoiame oma DB-d klastris, siis on tegelikult palju valmis lahendusi sama master-slave repliika korraldamiseks, palju lahendusi DB k\u00e4ivitamiseks kuber-networkis.
    \n Andmebaaside varundamise teemal on juba miljard ettekannet peetud, miljard artiklit kirjutatud \u2014 siin pole midagi uut. \u00dches\u00f5naga, j\u00e4rgige oma unistusi, elage nagu soovite, leiutage endale ka keerulisi lahendusi, kuid m\u00f5elge kindlasti, kuidas k\u00f5ike seda varundada.<\/p>\n

    N\u00fc\u00fcd r\u00e4\u00e4gime sellest, kuidas meie hankeprotsess t\u00f6\u00f6keskkonda edaspidi seekord toimub, juhul kui peaks tulekahju. Esiteks turgutame me paralleelselt staatuseid rakendusi. Need ei m\u00f5juta meie rakenduste \u00e4riloogikat ega projekti, saame pidevalt hoida kahte komplekti t\u00f6\u00f6tavaid rakendusi, kusjuures m\u00f5lemad saavad hakata liiklust vastu v\u00f5tma. \u00dcks oluline aspekt, millest tuleb t\u00e4helepanu p\u00f6\u00f6rata, on see, et vahetusprotsessis peaksite kindlasti vaatama, kas on vaja konfigureerimist uuesti m\u00e4\u00e4rata. N\u00e4iteks meil on tootmiscluster Kubernetes, varuregister Kubernetes, v\u00e4lised andmebaasid master ja varuregister master. Meil on neli erinevat v\u00f5imalust, kuidas need rakendused tootes omavahel koost\u00f6\u00f6d saavad alustada. V\u00f5ib-olla vahetame andmebaasi ning selgub, et tuleb tootmisclusteris liiklus suunata uuele andmebaasile; v\u00f5i v\u00f5ib olla cluster katki \u2014 ja me oleme l\u00e4inud varurakendusse, kuid j\u00e4tkame t\u00f6\u00f6tamist tootmisandmebaasiga; ning kolmas variant on, et meil on katki see ja katki too, ning me vahetame m\u00f5lemad rakendused, m\u00e4\u00e4rame meie seadistuse \u00fcmber, et uued rakendused t\u00f6\u00f6taksid juba uue andmebaasi p\u00f5hjal. <\/p>\n

    Nii, millised j\u00e4reldused saab k\u00f5igest sellest teha? <\/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 teiselt teenusepakkujalt. Olen korduvalt selliseid olukordi kogenud. Kahjuks ei saa ma projekte nimetada, kui just siis, kui andmekeskuses tulekahju juhtus... Oli mul selline olukord: l\u00fclitame \u00fcle varule! Ja varu serverid olid just selles samas rack'is.<\/p>\n

    V\u00f5i kujutage ette, et Amazon on Venemaal keelatud (ja nii on juhtunud). Ja k\u00f5ik: mis kasu on sellest, et meie varu on teises amazon'is? See on samuti k\u00e4ttesaamatu. Nii et kordangi: hoidke varu v\u00e4hemalt teises andmekeskuses ja eelistatavalt \u2014 teisel teenusepakkujal. <\/p>\n

    Teine j\u00e4reldus: kui teil on kubernetes'is rakendus, mis suhtleb mingite v\u00e4liste allikatega (see v\u00f5ib olla nii andmebaas kui ka mingi v\u00e4line API), m\u00e4\u00e4rake see kindlasti teenusena koos v\u00e4lise l\u00f5pp-punktiga, et vahetamise hetkel ei peaks redeployima 15 teie rakendust, mis puutuvad kokku sama andmebaasiga. M\u00e4\u00e4rake andmebaas eraldi teenusena ja \u00fchendage sellega nagu oleks see teie klastris: kui teie andmebaas peaks alla minema, muudetakse IP-d \u00fches kohas ja elate rahulolevalt edasi. <\/p>\n

    Ja l\u00f5petuseks: mulle meeldib 'kuubik', samuti katsetused sellega. Samuti meeldib mulle jagada nende katsete tulemusi ja \u00fcldiselt oma isiklikke kogemusi. Seep\u00e4rast olen salvestanud seriaali veebinaridest K8s kohta, tere tulemast meie YouTube 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\udd47Kubernetes'is tellimine: see eksisteerib | ProHoster","description":"Minu nimi on Sergei, ma olen ettev\u00f5ttest ITSumma ja tahan teile r\u00e4\u00e4kida, kuidas me l\u00e4heneme varundamisele Kuberneteses. Viimasel ajal olen palju tegelenud konsultatsioonit\u00f6\u00f6dega erinevate devops-lahenduste rakendamisel erinevatele meeskondadele ja eelk\u00f5ige olen tihedalt seotud K8s'iga seotud projektidega. Uptime p\u00e4eva konverentsil, mis oli p\u00fchendatud keerulisele varundamisele.","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. \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","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"},"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}]}}