{"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\/sk\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Z\u00e1lohovanie v Kubernetes: existuje","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vol\u00e1m sa Sergej, som zo spolo\u010dnosti ITSumma a chcem v\u00e1m poveda\u0165, ako pristupujeme k z\u00e1lohovaniu v Kubernetes. V poslednej dobe sa ve\u013emi intenz\u00edvne zaober\u00e1m poradenskou pr\u00e1cou pri zav\u00e1dzan\u00ed r\u00f4znych devops rie\u0161en\u00ed pre r\u00f4zne t\u00edmy a konkr\u00e9tne sa zameriavam na projekty vyu\u017e\u00edvaj\u00face K8s. Na konferencii Uptime day 4, ktor\u00e1 bola zameran\u00e1 na z\u00e1lohovanie v zlo\u017eit\u00fdch architekt\u00farach, som vyst\u00fapil s predn\u00e1\u0161kou o z\u00e1lohovan\u00ed \u201ekocky\u201c, a tu je jej vo\u013en\u00fd preh\u013ead. Len v\u00e1s vopred upozorn\u00edm, \u017ee to nie je priama pr\u00edru\u010dka k akcii, ale sk\u00f4r s\u00fahrn zamyslen\u00ed na dan\u00fa t\u00e9mu.<\/p>\n

\"Z\u00e1lohovanie
\n
\nV z\u00e1sade je monitoring a z\u00e1lohovanie dvoma z\u00e1kladn\u00fdmi n\u00e1strojmi na zv\u00fd\u0161enie odolnosti ak\u00e9hoko\u013evek projektu. Ale ve\u010f v kubere sa v\u0161etko vyva\u017euje samo, poviete si, v\u0161etko sa \u0161k\u00e1luje samo, a ak sa nie\u010do stane, samo sa to obnov\u00ed\u2026 Teda pri prvotnom povrchnom sk\u00faman\u00ed t\u00e9my internet odpovedal na ot\u00e1zku, ako sa kto pr\u00edstupuje k z\u00e1lohovaniu K8s: \u201ea na\u010do?\u201c Mnoh\u00ed si myslia, \u017ee kuber je ak\u00e1si magick\u00e1 vec, ktor\u00e1 zbavuje v\u0161etk\u00fdch infra\u0161truktur\u00e1lnych probl\u00e9mov a zabezpe\u010duje, \u017ee projekt nikdy nepadne. Ale\u2026 svet nie je to, \u010d\u00edm sa zd\u00e1.
\n<\/a><\/noindex>
\nAko sme vo\u010di procesu z\u00e1lohovania predt\u00fdm pristupovali? Mali sme identick\u00e9 prostredia na umiestnenie \u2013 \u010di u\u017e to boli virtu\u00e1lne stroje alebo fyzick\u00e9 servery<\/a>, na ktor\u00e9 sme aplikovali tri z\u00e1kladn\u00e9 praktiky: <\/p>\n

    \n
  1. synchroniz\u00e1cia k\u00f3du a statiky<\/li>\n
  2. synchroniz\u00e1cia konfigur\u00e1ci\u00ed<\/li>\n
  3. replik\u00e1cia datab\u00e1z<\/li>\n<\/ol>\n

    \nA voil\u00e0: kedyko\u013evek prepneme na z\u00e1lo\u017en\u00e9 prostredie, v\u0161etci s\u00fa \u0161\u0165astn\u00ed, zdvihneme sa a roz\u00eddeme. <\/p>\n

    \"Z\u00e1lohovanie
    \n
    \n\u010co n\u00e1m pon\u00fakaj\u00fa na zv\u00fd\u0161enie trvalej dostupnosti na\u0161ej aplik\u00e1cie Kubernetes? Prv\u00e1 vec, o ktorej hovor\u00ed neofici\u00e1lna dokument\u00e1cia, je nasadi\u0165 ve\u013ea strojov, vytvori\u0165 ve\u013ea masterov \u2013 ich po\u010det by mal sp\u013a\u0148a\u0165 podmienky dosiahnutia kv\u00f3ra v r\u00e1mci klastra, a aby na ka\u017edom z masterov be\u017eal etcd, API, MC, scheduler\u2026 A, zd\u00e1 sa, v\u0161etko sa zd\u00e1 by\u0165 skvel\u00e9: ak vypadne nieko\u013eko pracovn\u00fdch uzlov alebo masterov, n\u00e1\u0161 klaster sa prebalansuje a aplik\u00e1cia bude pokra\u010dova\u0165 v \u010dinnosti. Znie to ako \u010darodejn\u00edctvo! Ale \u010dasto sa n\u00e1\u0161 klaster nach\u00e1dza v r\u00e1mci jedn\u00e9ho d\u00e1tov\u00e9ho centra a to m\u00f4\u017ee vyvola\u0165 ur\u010dit\u00e9 ot\u00e1zky. \u010co ak pr\u00edde bagrista a vykop\u00e1 k\u00e1bel, udrie blesk, nastane celosvetov\u00e1 povode\u0148? V\u0161etko sa pokaz\u00ed, n\u00e1\u0161 klaster u\u017e neexistuje. Ako sa pribl\u00ed\u017ei\u0165 k z\u00e1lohovaniu s oh\u013eadom na t\u00fato str\u00e1nku probl\u00e9mu? <\/p>\n

    Predov\u0161etk\u00fdm by ste mali ma\u0165 \u010fal\u0161\u00ed klaster v hor\u00facej z\u00e1lohe, teda klaster, na ktor\u00fd sa m\u00f4\u017eete kedyko\u013evek prepnu\u0165. Z poh\u013eadu Kubernetes musia by\u0165 infra\u0161trukt\u00fary \u00faplne identick\u00e9. Teda ak existuj\u00fa nejak\u00e9 nestandardn\u00e9 pluginy na pr\u00e1cu so s\u00faborov\u00fdm syst\u00e9mom, vlastn\u00e9 rie\u0161enia pre ingress, musia by\u0165 \u00faplne identick\u00e9 na va\u0161ich dvoch (alebo troch, alebo desiatich, tu u\u017e z\u00e1le\u017e\u00ed na tom, ko\u013eko pe\u0148az\u00ed a s\u00edl m\u00e1te) klastroch. Je potrebn\u00e9 jasne definova\u0165 dva s\u00fabory aplik\u00e1ci\u00ed (deploymentov, statefulsetov, daemonsetov, cronjobov at\u010f.): ktor\u00e9 z nich m\u00f4\u017eu pracova\u0165 na z\u00e1lohe nepretr\u017eite, a ktor\u00e9 by bolo lep\u0161ie nesp\u00fa\u0161\u0165a\u0165, k\u00fdm nenastane bezprostredn\u00e9 prepn\u00fa\u0165. <\/p>\n

    M\u00e1 by\u0165 n\u00e1\u0161 z\u00e1lo\u017en\u00fd klaster \u00faplne identick\u00fd s na\u0161\u00edm produk\u010dn\u00fdm klastrom? Nie. Ak sme sk\u00f4r pri pr\u00e1ci s monolitn\u00fdmi projektmi, so \u017eeleznou infra\u0161trukt\u00farou udr\u017eiavali prakticky \u00faplne identick\u00e9 prostredie, tak v r\u00e1mci Kubernetes to pova\u017eujem za nepotrebn\u00e9. Po\u010fme sa pozrie\u0165, pre\u010do.<\/p>\n

    Napr\u00edklad, za\u010dneme s z\u00e1kladn\u00fdmi entitami Kubernetes \u2013 deployments \u2013 ktor\u00e9 by mali by\u0165 identick\u00e9. Mus\u00ed by\u0165 spusten\u00e1 aplik\u00e1cia, ktor\u00e1 m\u00f4\u017ee kedyko\u013evek zachyti\u0165 spracovanie prev\u00e1dzky a umo\u017en\u00ed n\u00e1\u0161mu projektu pre\u017e\u00edva\u0165. Ak hovor\u00edme o konfigura\u010dn\u00fdch s\u00faboroch, mus\u00edme sa pozrie\u0165 na to, \u010di by mali by\u0165 identick\u00e9 alebo nie. To znamen\u00e1, \u017ee ak my, inteligentn\u00ed \u013eudia, neu\u017e\u00edvame \u017eiadne zak\u00e1zan\u00e9 l\u00e1tky a nem\u00e1me datab\u00e1zu v K8s, musia by\u0165 v configmaps nastavenia pr\u00edstupu do produk\u010dne verzie datab\u00e1zy (proces z\u00e1lohovania, ktor\u00fd je postaven\u00fd samostatne). Zodpovedaj\u00face zabezpe\u010denie pr\u00edstupu k z\u00e1lo\u017en\u00e9mu exempl\u00e1ru datab\u00e1zy vy\u017eaduje samostatn\u00fd konfigura\u010dn\u00fd s\u00fabor (configmap). Presne takto pracujeme aj so secretmi: heslami na pr\u00edstup do datab\u00e1zy, api-k\u013e\u00fa\u010dmi; kedyko\u013evek m\u00f4\u017ee fungova\u0165 bu\u010f produk\u010dn\u00fd secret, alebo z\u00e1lo\u017en\u00fd. Tak\u017ee u\u017e m\u00e1me dve entity Kubernetes, ktor\u00fdch z\u00e1lo\u017en\u00e9 verzie by nemali by\u0165 identick\u00e9 s produk\u010dn\u00fdmi. \u010eal\u0161ou entitou, na ktorej by sme sa mali zastavi\u0165, s\u00fa cronjoby. Cronjoby na z\u00e1lohe nesm\u00fa by\u0165 v \u017eiadnom pr\u00edpade identick\u00e9 s mno\u017einou cronjobov produk\u010dn\u00e9ho klastre! Ak sp\u00fa\u0161\u0165ame z\u00e1lo\u017en\u00fd klaster a sp\u00fa\u0161\u0165ame ho \u00faplne so v\u0161etk\u00fdmi zapnut\u00fdmi cronjobmi \u2013 napr\u00edklad, \u013eudia od v\u00e1s dostan\u00fa dve e-maily naraz namiesto jedn\u00e9ho. Alebo nejak\u00e1 synchroniz\u00e1cia d\u00e1t z extern\u00fdch zdrojov prebehne dvakr\u00e1t, a tak za\u010dneme ochorie\u0165, pla\u010da\u0165, kri\u010da\u0165 a nad\u00e1va\u0165. <\/p>\n

    \"Z\u00e1lohovanie
    \n
    \nA ako n\u00e1m navrhuj\u00fa zorganizova\u0165 z\u00e1lo\u017en\u00fd cluster \u013eudia z internetu? Druh\u00e1 najpopul\u00e1rnej\u0161ia odpove\u010f po \"a na \u010do?\" \u2014 pou\u017eitie Kubernetes Federation. <\/p>\n

    \u010co to je? Je to, povedzme, ve\u013ek\u00fd meta-klaster. Ak si predstav\u00edme architekt\u00faru kuber \u2014 kde m\u00e1me mastera a nieko\u013eko uzlov, \u2014 tak z poh\u013eadu feder\u00e1cie m\u00e1me tie\u017e mastera a nieko\u013eko uzlov, len ka\u017ed\u00e1 uzol je samostatn\u00fd klaster. To znamen\u00e1, \u017ee pracujeme s t\u00fdmi ist\u00fdmi entitami, s t\u00fdmi ist\u00fdmi primit\u00edvami ako s jedn\u00fdm kuberom, len namiesto na\u0161ich fyzick\u00fdch strojov pou\u017e\u00edvame cel\u00e9 klastre. V r\u00e1mci feder\u00e1cie prebieha \u00fapln\u00e1 synchroniz\u00e1cia federat\u00edvnych zdrojov od rodi\u010dov k potomkom. Napr\u00edklad, ak sme spustili nejak\u00fd deployment cez feder\u00e1ciu \u2014 nasad\u00ed sa na ka\u017ed\u00fd n\u00e1\u0161 dc\u00e9rsky klaster. Ak vezmeme ak\u00fdko\u013evek configmap, tajomstvo, rozlo\u017e\u00edme ho na feder\u00e1cii \u2014 roz\u0161\u00edri sa do v\u0161etk\u00fdch na\u0161ich dc\u00e9rskych klastrov; pritom feder\u00e1cia umo\u017e\u0148uje prisp\u00f4sobi\u0165 na\u0161e zdroje na de\u0165och. To znamen\u00e1, \u017ee sme vzali nejak\u00fd configmap, nasadili ho cez feder\u00e1ciu a potom, ak potrebujeme nie\u010do upravi\u0165 na konkr\u00e9tnych klastroch, ideme upravova\u0165 na jednotlivom klastre a t\u00e1to zmena sa u\u017e nikam nebude synchronizova\u0165. <\/p>\n

    Kubernetes Federation je n\u00e1stroj, ktor\u00fd sa objavil relat\u00edvne ned\u00e1vno a nepodporuje v\u0161etky typy zdrojov, ktor\u00e9 pon\u00faka samotn\u00fd K8s: v \u010dase publikovania jednej z prv\u00fdch verzi\u00ed dokument\u00e1cie sa uv\u00e1dzalo, \u017ee podporuje iba config mapy, deploymenty pod replica set, a ingress. Tajomstv\u00e1 neboli podporovan\u00e9, pr\u00e1ca s volume tie\u017e nebola podporovan\u00e1. Sada n\u00e1strojov je pr\u00edli\u0161 obmedzen\u00e1. Najm\u00e4 ak sa radi zab\u00e1vame, napr\u00edklad pren\u00e1\u0161an\u00edm na\u0161ich vlastn\u00fdch zdrojov do Kubernetes prostredn\u00edctvom custom resource definition, u\u017e ich do feder\u00e1cie nedostaneme. To znamen\u00e1, \u017ee je to\u2026 ve\u013emi podobn\u00e9 pravde, ale ob\u010das n\u00e1s to n\u00fati strie\u013ea\u0165 si do n\u00f4h. Na druhej strane, feder\u00e1cia umo\u017e\u0148uje flexibilne spravova\u0165 n\u00e1\u0161 replicaset. Napr\u00edklad, ak chceme, aby bolo spusten\u00fdch 10 replik na\u0161ej aplik\u00e1cie, feder\u00e1cia t\u00fato hodnotu automaticky rozdel\u00ed medzi klastre. A to v\u0161etko m\u00f4\u017eeme aj konfigurova\u0165! M\u00f4\u017eeme ur\u010di\u0165, \u017ee na produk\u010dnom klastri m\u00e1 by\u0165 6 replik na\u0161ej aplik\u00e1cie, a na z\u00e1lo\u017enom klastri, aby sme \u0161etrili zdroje alebo pre vlastn\u00e9 z\u00e1bavy \u2014 iba 4 repliky na\u0161ej aplik\u00e1cie. \u010co je tie\u017e ve\u013emi pohodln\u00e9. Ale s feder\u00e1ciou mus\u00edme pou\u017e\u00edva\u0165 nejak\u00e9 nov\u00e9 rie\u0161enia, nie\u010do nov\u00e9 nasadzova\u0165 za pochodu, n\u00fati\u0165 sa trochu viac prem\u00fd\u0161\u013ea\u0165... <\/p>\n

    M\u00f4\u017eeme prist\u00fapi\u0165 k procesu rezervovania Kubernetes nejako jednoduch\u0161ie? Ak\u00e9 n\u00e1stroje m\u00e1me vlastne k dispoz\u00edcii?<\/p>\n

    Predov\u0161etk\u00fdm m\u00e1me v\u017edy nejak\u00fd ci\/cd syst\u00e9m, to znamen\u00e1, \u017ee manu\u00e1lne nechod\u00edme, nep\u00ed\u0161eme na serveroch create\/apply. Syst\u00e9m generuje yaml s\u00fabory pre na\u0161e kontajnery. <\/p>\n

    Po druh\u00e9, m\u00e1me nieko\u013eko klastrov; m\u00e1me bu\u010f jedno, alebo viac (ak sme inteligentn\u00ed) registry, ktor\u00e9 sme tie\u017e vzali a rezervovali. A m\u00e1me \u00fa\u017easn\u00fd n\u00e1stroj kubectl, ktor\u00fd m\u00f4\u017ee pracova\u0165 s viacer\u00fdmi klastrami s\u00fa\u010dasne. <\/p>\n

    \"Z\u00e1lohovanie
    \n
    \nPod\u013ea m\u00f4jho n\u00e1zoru je najjednoduch\u0161\u00edm a najpresnej\u0161\u00edm rie\u0161en\u00edm na vytvorenie z\u00e1lo\u017en\u00e9ho klasteru primit\u00edvny paraleln\u00fd deploy. Existuje nejak\u00fd pipeline v ci\/cd syst\u00e9me; najprv zostav\u00edme na\u0161e kontajnery, otestujeme ich a potom nasad\u00edme aplik\u00e1cie cez kubectl na nieko\u013eko nez\u00e1visl\u00fdch klastrov. M\u00f4\u017eeme vykon\u00e1va\u0165 s\u00fa\u010dasn\u00e9 nasadenia na viac klastrov. Rovnako sa na tejto \u00farovni rie\u0161ia aj dod\u00e1vky konfigur\u00e1ci\u00ed. M\u00f4\u017eeme vopred ur\u010di\u0165 s\u00fabor konfigur\u00e1ci\u00ed pre n\u00e1\u0161 produktov\u00fd klaster, s\u00fabor konfigur\u00e1ci\u00ed pre z\u00e1lo\u017en\u00fd klaster a na \u00farovni ci\/cd syst\u00e9mu nasadi\u0165 produk\u010dn\u00e9 prostredie do produk\u010dn\u00e9ho klasteru, z\u00e1lo\u017en\u00e9 prostredie \u2014 do z\u00e1lo\u017en\u00e9ho klasteru. V porovnan\u00ed s feder\u00e1ciou nemus\u00edme chodi\u0165 na ka\u017ed\u00fd podklaster a nie\u010do predefinova\u0165 po ur\u010den\u00ed federat\u00edvneho zdroja. Urobili sme to vopred. Ak\u00ed sme skvel\u00ed.<\/p>\n

    Ale\u2026 je\u2026 chcel som nap\u00edsa\u0165, \u017ee existuje \u201ekore\u0148 v\u0161etk\u00fdch zla\u201c, ale v skuto\u010dnosti ich s\u00fa dva. Po prv\u00e9, s\u00faborov\u00fd syst\u00e9m. Existuje nejak\u00fd PV, alebo pou\u017e\u00edvame extern\u00e9 \u00falo\u017eisko. Ak uchov\u00e1vame s\u00fabory vo vn\u00fatri klastra, mus\u00edme sa riadi\u0165 star\u00fdmi praktikami, ktor\u00e9 zostali z \u010dias hardv\u00e9rov\u00fdch infra\u0161trukt\u00far: napr\u00edklad, synchronizova\u0165 lsyncom. Alebo ak\u00fdmiko\u013evek in\u00fdmi preferovan\u00fdmi rie\u0161eniami. Rozprestierame v\u0161etko na in\u00e9 stroje a \u017eijeme.<\/p>\n

    Po druh\u00e9, a to, pravdupovediac, je e\u0161te d\u00f4le\u017eitej\u0161\u00ed bod \u2014 datab\u00e1za. Ak sme m\u00fadri \u013eudia a nedr\u017e\u00edme datab\u00e1zu v kube, proces z\u00e1lohovania d\u00e1t funguje pod\u013ea tej istej starej sch\u00e9my \u2014 master-slave replik\u00e1cia, potom prepneme, replik\u00e1ciu dobehne a budeme \u017ei\u0165 dobre. Ale ak budeme dr\u017ea\u0165 na\u0161u DB v r\u00e1mci klasteru, existuje ve\u013ea hotov\u00fdch rie\u0161en\u00ed na organiz\u00e1ciu tej istej master-slave repliky, ve\u013ea rie\u0161en\u00ed na zdv\u00edhanie DB vo vn\u00fatri kube.
    \n O z\u00e1lohovan\u00ed datab\u00e1z u\u017e bolo pre\u010d\u00edtan\u00fdch mili\u00f3n predn\u00e1\u0161ok, nap\u00edsan\u00fdch mili\u00f3n \u010dl\u00e1nkov, ni\u010d nov\u00e9 tu vlastne nie je. V skratke, nasledova\u0165 svoje sny, \u017ei\u0165 ako chcete, vym\u00fd\u0161\u013ea\u0165 si nejak\u00e9 komplikovan\u00e9 obstrukcie, ale ur\u010dite prem\u00fd\u0161\u013ea\u0165 o tom, ako to cel\u00e9 budete z\u00e1lohova\u0165.<\/p>\n

    A teraz o tom, ako bude prebieha\u0165 prechod na z\u00e1lo\u017en\u00fa lokalitu v pr\u00edpade po\u017eiaru. Po prv\u00e9, paralelne nasadzujeme stateless aplik\u00e1cie. Nep\u00f4sobia na obchodn\u00fa logiku na\u0161ich aplik\u00e1ci\u00ed, n\u00e1\u0161ho projektu, m\u00f4\u017eeme neust\u00e1le ma\u0165 dve sady spusten\u00fdch aplik\u00e1ci\u00ed a tie m\u00f4\u017eu za\u010da\u0165 prij\u00edma\u0165 prenos. Je ve\u013emi d\u00f4le\u017eit\u00e9 pri prechode na z\u00e1lo\u017en\u00fa lokalitu nevyhnutne skontrolova\u0165 \u2014 je potrebn\u00e9 predefinova\u0165 konfigur\u00e1cie? Napr\u00edklad m\u00e1me produk\u010dn\u00fd cluster Kubernetes, m\u00e1me z\u00e1lo\u017en\u00fd cluster Kubernetes, m\u00e1me extern\u00fa datab\u00e1zu master, m\u00e1me z\u00e1lo\u017en\u00fa datab\u00e1zu master. M\u00e1me \u0161tyri mo\u017enosti, ako m\u00f4\u017eu tieto aplik\u00e1cie v produkcii za\u010da\u0165 medzi sebou interagova\u0165. M\u00f4\u017ee sa prenies\u0165 datab\u00e1za, a tak sa m\u00f4\u017ee sta\u0165, \u017ee mus\u00edme v produk\u010dnom clustri prepn\u00fa\u0165 prenos na nov\u00fa datab\u00e1zu, alebo m\u00f4\u017ee zlyha\u0165 cluster \u2014 a presunuli sme sa na z\u00e1lo\u017en\u00fa lokalitu, ale pokra\u010dujeme v pr\u00e1ci s produk\u010dnou datab\u00e1zou, a tret\u00ed variant, ke\u010f zlyhal to aj to, a prepneme obe aplik\u00e1cie, predefinujeme na\u0161u konfigur\u00e1ciu, aby nov\u00e9 aplik\u00e1cie u\u017e pracovali s novou datab\u00e1zou. <\/p>\n

    Ak\u00e9 z\u00e1very m\u00f4\u017eeme z toho v\u0161etk\u00e9ho urobi\u0165? <\/p>\n

    \"Z\u00e1lohovanie
    \n
    \nPrv\u00fd z\u00e1ver: so z\u00e1lohou sa \u017eije dobre. Ale je to drah\u00e9. Ide\u00e1lne by sme nemali ma\u0165 iba jednu z\u00e1lohu. Ide\u00e1lne by sme mali ma\u0165 viacero z\u00e1loh. Po prv\u00e9, z\u00e1loha by mala by\u0165 minim\u00e1lne na inom d\u00e1tovom centre, a po druh\u00e9, minim\u00e1lne u in\u00e9ho poskytovate\u013ea. \u010casto sa stalo \u2014 a na mojej praxi to bolo. Projekty nem\u00f4\u017eem, \u017eia\u013e, pomenova\u0165, presne ke\u010f do\u0161lo k po\u017eiaru v d\u00e1tovom centre... A ja hovor\u00edm: prech\u00e1dzame na z\u00e1lohu! A z\u00e1lo\u017en\u00e9 servery boli v tej istej skrini...<\/p>\n

    Alebo si predstavte, \u017ee Amazon bol zak\u00e1zan\u00fd v Rusku (a nie\u010do tak\u00e9 sa stalo). A v\u0161etko: ak\u00fd m\u00e1 v\u00fdznam, \u017ee na inom Amazone m\u00e1me na\u0161u z\u00e1lohu? T\u00e1to je tie\u017e nedostupn\u00e1. Tak\u017ee opakujem: dr\u017eme z\u00e1lohu minim\u00e1lne v inom d\u00e1tovom centre, a ide\u00e1lne \u2014 u in\u00e9ho poskytovate\u013ea. <\/p>\n

    Druh\u00fdm z\u00e1verom je: ak va\u0161a aplik\u00e1cia v Kubernetes komunikuje s nejak\u00fdmi extern\u00fdmi zdrojmi (m\u00f4\u017ee to by\u0165 datab\u00e1za alebo nejak\u00e9 extern\u00e9 API), ur\u010dite ju definujte ako slu\u017ebu s extern\u00fdm Endpointom, aby ste pri prep\u00ednan\u00ed nemuseli nasadzova\u0165 15 va\u0161ich aplik\u00e1ci\u00ed, ktor\u00e9 sa prip\u00e1jaj\u00fa k tej istej datab\u00e1ze. Definujte datab\u00e1zu ako samostatn\u00fa slu\u017ebu a prip\u00e1jajte sa k nej, akoby bola vo vn\u00fatri v\u00e1\u0161ho klastra: ak sa datab\u00e1za pokaz\u00ed, men\u00edte IP v jednom mieste a pokra\u010dujete \u0161\u0165astne \u010falej. <\/p>\n

    A nakoniec: \u2018kub\u00edk\u2019 m\u00e1m r\u00e1d, rovnako ako experimenty s n\u00edm. A tie\u017e r\u00e1d zdie\u013eam v\u00fdsledky t\u00fdchto experimentov a svoj osobn\u00fd z\u00e1\u017eitok. Preto som zaznamenal s\u00e9riu webin\u00e1rov o K8s, v\u00edtam v\u00e1s na na\u0161om youtube kan\u00e1li<\/a><\/noindex> pre podrobnosti.
    \n
    Zdroj:     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\udd47Rezerv\u00e1cia v Kubernetes: existuje | ProHoster","description":"Vol\u00e1m sa Sergey, som z ITSumma a chcem v\u00e1m poveda\u0165, ako pristupujeme k rezerv\u00e1cii v Kubernetes.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}