{"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\/ro\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Rezervarea \u00een Kubernetes: aceasta exist\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u0103 numesc Serghei, sunt de la compania ITSumma \u0219i vreau s\u0103 v\u0103 vorbesc despre cum abord\u0103m rezerv\u0103rile \u00een Kubernetes. \u00cen ultima vreme, m-am dedicat mult consultan\u021bei pentru implementarea diverselor solu\u021bii devops pentru diferite echipe, \u0219i, \u00een special, am lucrat la proiecte cu utilizarea K8s. La conferin\u021ba Uptime Day 4, care a fost dedicat\u0103 rezerv\u0103rii \u00een arhitecturi complexe, am sus\u021binut o prezentare despre rezervarea \u00abcubului\u00bb, iar aici este o reluare liber\u0103 a acesteia. V\u0103 avertizez din capul locului c\u0103 nu este un ghid direct de ac\u021biune, ci mai degrab\u0103 o sintez\u0103 a g\u00e2ndurilor pe aceast\u0103 tem\u0103.<\/p>\n

\"Rezervarea
\n
\n\u00cen principiu, monitorizarea \u0219i rezervarea sunt cele dou\u0103 instrumente principale de cre\u0219tere a rezilien\u021bei oric\u0103rui proiect. Dar, bine\u00een\u021beles, \u00een K8s totul se echilibreaz\u0103 de la sine, ve\u021bi spune, totul se scaleaz\u0103 de la sine, \u0219i dac\u0103 se \u00eent\u00e2mpl\u0103 ceva \u2014 se va ridica de la sine\u2026 Asta \u00eenseamn\u0103 c\u0103, la o prim\u0103 cercetare superficial\u0103 a subiectului, internetul mi-a r\u0103spuns la \u00eentrebarea, cine cum se apropie de rezervarea K8s, cu \u201ede ce?\u201d Multe persoane cred c\u0103 K8s este un fel de lucru magic care scute\u0219te de toate problemele de infrastructur\u0103 \u0219i face ca proiectul s\u0103 nu se pr\u0103bu\u0219easc\u0103 niciodat\u0103. Dar\u2026 lumea nu este ceea ce pare.
\n<\/a><\/noindex>
\nCum ne abordam procesul de rezervare \u00eenainte? Aveam site-uri identice pentru g\u0103zduire \u2014 fie erau ma\u0219ini virtuale, fie erau servere fizice servere<\/a>, la care aplicam trei practici de baz\u0103: <\/p>\n

    \n
  1. sincronizarea codului \u0219i a statelor<\/li>\n
  2. sincronizarea configura\u021biilor<\/li>\n
  3. replicarea bazelor de date<\/li>\n<\/ol>\n

    \n\u0218i voil\u00e0: \u00een orice moment ne comutam pe site-ul de rezerv\u0103, to\u021bi sunt ferici\u021bi, ne ridic\u0103m \u0219i ne \u00eempr\u0103\u0219tiem. <\/p>\n

    \"Rezervarea
    \n
    \nCe ne ofer\u0103 pentru a cre\u0219te disponibilitatea constant\u0103 a aplica\u021biei noastre Kubernetes? Primul lucru despre care vorbe\u0219te documenta\u021bia neoficial\u0103 este s\u0103 avem multe ma\u0219ini, s\u0103 avem mul\u021bi masteri - num\u0103rul lor trebuie s\u0103 satisfac\u0103 cerin\u021bele pentru atingerea cvorumului \u00een interiorul clusterului, \u0219i s\u0103 avem etcd, api, MC, scheduler... pe fiecare dintre masteri. \u0218i, p\u0103rea c\u0103 totul este minunat: c\u00e2nd mai multe noduri de lucru sau masteri ies din func\u021biune, clusterul nostru se reechilibreaz\u0103 \u0219i aplica\u021bia continu\u0103 s\u0103 func\u021bioneze. Din nou, pare magie! Dar adesea, clusterul nostru se afl\u0103 \u00eentr-un singur centru de date \u0219i acest lucru poate ridica anumite \u00eentreb\u0103ri. Ce se \u00eent\u00e2mpl\u0103 dac\u0103 un excavator vine \u0219i dezgrop\u0103 un cablu, dac\u0103 a lovit fulgerul, dac\u0103 a avut loc un potop universal? Totul s-a dus, clusterul nostru nu mai exist\u0103. Cum ar trebui s\u0103 abord\u0103m rezervarea av\u00e2nd \u00een vedere aceast\u0103 problem\u0103? <\/p>\n

    \u00cen primul r\u00e2nd, ar trebui s\u0103 ave\u021bi un alt cluster \u00een rezerv\u0103, adic\u0103 un cluster la care pute\u021bi comuta \u00een orice moment. Din acest punct de vedere, infrastructura trebuie s\u0103 fie complet identic\u0103. Adic\u0103 dac\u0103 exist\u0103 pluginuri non-standard pentru lucrul cu sistemul de fi\u0219iere, solu\u021bii personalizate pentru ingress, acestea trebuie s\u0103 fie complet identice pe cele dou\u0103 (sau trei, sau zece, depinde de c\u00e2t ave\u021bi bani \u0219i for\u021b\u0103 de munc\u0103) clustere. Trebuie s\u0103 defini\u021bi clar dou\u0103 seturi de aplica\u021bii (deployment-uri, statefulset-uri, daemonset-uri, cronjob-uri etc.): care dintre ele pot func\u021biona permanent \u00een rezerv\u0103, iar care ar fi mai bine s\u0103 nu fie lansate p\u00e2n\u0103 la comutarea efectiv\u0103. <\/p>\n

    Ar trebui ca clusterul nostru de rezerv\u0103 s\u0103 fie complet identic cu clusterul nostru de produc\u021bie? Nu. Dac\u0103 anterior, \u00een cadrul proiectelor monolitice, am men\u021binut o mediu aproape complet identic \u00een cadrul infrastructurii hardware, consider c\u0103 \u00een cadrul Kubernetes nu ar trebui s\u0103 fie a\u0219a. S\u0103 examin\u0103m de ce.<\/p>\n

    De exemplu, s\u0103 \u00eencepem cu entit\u0103\u021bile de baz\u0103 ale Kubernetes - deployments - acestea trebuie s\u0103 fie identice. Aplica\u021biile care pot prelua procesarea traficului \u00een orice moment trebuie s\u0103 fie active, astfel \u00eenc\u00e2t proiectul nostru s\u0103 continue s\u0103 existe. C\u00e2nd vorbim despre fi\u0219ierele de configurare, trebuie s\u0103 ne \u00eentreb\u0103m dac\u0103 acestea trebuie s\u0103 fie identice sau nu. A\u0219adar, dac\u0103 noi, oameni inteligen\u021bi, nu consum\u0103m substan\u021be interzise \u0219i nu p\u0103str\u0103m baza \u00een K8s, configura\u021biile din configmaps ar trebui s\u0103 con\u021bin\u0103 set\u0103rile de acces la baza de date de produc\u021bie (procesul de rezervare fiind structurat separat). Prin urmare, pentru a asigura accesul la instan\u021ba de rezerv\u0103 a bazei de date, trebuie s\u0103 avem un fi\u0219ier de configurare separat (configmap). Exact la fel proced\u0103m \u0219i cu secret-urile: parole de acces la baz\u0103, chei API; \u00een orice moment, avem activ fie secret-ul de produc\u021bie, fie cel de rezerv\u0103. Astfel, avem deja dou\u0103 entit\u0103\u021bi Kubernetes, versiunile de rezerv\u0103 ale c\u0103rora nu trebuie s\u0103 fie identice cu cele de produc\u021bie. Urm\u0103toarea entitate la care trebuie s\u0103 ne oprim este cronjob-ul. Cronjob-urile de rezerv\u0103 nu trebuie sub nicio form\u0103 s\u0103 fie identice cu setul de cronjob-uri ale cluster-ului de produc\u021bie! Dac\u0103 ridic\u0103m un cluster de rezerv\u0103 \u0219i \u00eel activ\u0103m complet cu toate cronjob-urile incluse - de exemplu, oamenii vor primi de la noi dou\u0103 e-mailuri simultan \u00een loc de unul. Sau o sincronizare a datelor cu surse externe va avea loc de dou\u0103 ori, ceea ce \u00eenseamn\u0103 c\u0103 vom \u00eencepe s\u0103 ne sim\u021bim r\u0103u, s\u0103 pl\u00e2ngem, s\u0103 url\u0103m \u0219i s\u0103 ne cert\u0103m. <\/p>\n

    \"Rezervarea
    \n
    \n\u0218i cum ne propun oamenii de pe internet s\u0103 organiz\u0103m un cluster de rezerv\u0103? Al doilea r\u0103spuns ca popularitate, dup\u0103 \u201ede ce?\u201d \u2013 utilizarea Kubernetes Federation. <\/p>\n

    Ce este asta? S\u0103 spunem c\u0103 este un mare meta-cluster. Dac\u0103 ne imagin\u0103m arhitectura Kubernetes \u2014 unde avem un master, mai multe noduri \u2014 din perspectiva federa\u021biei avem \u0219i un master \u0219i mai multe noduri, doar c\u0103 fiecare nod este un cluster separat. Adic\u0103 lucr\u0103m cu acelea\u0219i entit\u0103\u021bi, cu acelea\u0219i primitive, ca \u0219i cu un Kubernetes unic, doar c\u0103 gestion\u0103m nu ma\u0219inile noastre fizice, ci clustere \u00eentregi. \u00cen cadrul federa\u021biei, avem o sincronizare complet\u0103 a resurselor federative de la p\u0103rin\u021bi la copii. De exemplu, dac\u0103 am lansat un anumit deployment prin federa\u021bie \u2014 acesta se va desf\u0103\u0219ura pe fiecare dintre clusterele noastre copil. Dac\u0103 lu\u0103m un configmap, un secret, \u0219i \u00eel desf\u0103\u0219ur\u0103m prin federa\u021bie \u2014 acesta se va r\u0103sp\u00e2ndi \u00een toate clusterele noastre copil; \u00een acela\u0219i timp, federa\u021bia permite personalizarea resurselor noastre pe copii. Adic\u0103 am luat un configmap, l-am desf\u0103\u0219urat prin federa\u021bie \u0219i apoi, dac\u0103 avem nevoie s\u0103 ajust\u0103m ceva pe clusterele specifice, ne \u00eendrept\u0103m s\u0103 modific\u0103m pe un cluster separat, iar aceast\u0103 modificare nu se va mai sincroniza nic\u0103ieri. <\/p>\n

    Kubernetes Federation \u2014 un instrument care exist\u0103 de cur\u00e2nd \u0219i nu suport\u0103 un set complet de resurse pe care le ofer\u0103 K8s: la momentul public\u0103rii uneia dintre primele versiuni ale documenta\u021biei, se men\u021biona c\u0103 suportul era disponibil doar pentru config-mapuri, deployment pentru replica-set \u0219i ingress. Secretele nu erau suportate, iar lucrul cu volumele, de asemenea, nu era acceptat. Un set de func\u021bii prea restr\u00e2ns. Mai ales dac\u0103 ne place s\u0103 ne distr\u0103m \u2014 de exemplu, prin utilizarea custom resource definition pentru a transmite propriile resurse c\u0103tre Kubernetes \u2014 \u00een federa\u021bie nu le putem integra. Cu alte cuvinte\u2026 este o solu\u021bie destul de apropiat\u0103 de realitate, dar ne face s\u0103 ne \u00eempu\u0219c\u0103m \u00een picior din c\u00e2nd \u00een c\u00e2nd. Pe de alt\u0103 parte, federa\u021bia permite gestionarea flexibil\u0103 a replica-setului nostru. De exemplu, dorim s\u0103 avem 10 replici ale aplica\u021biei noastre, iar federa\u021bia va \u00eemp\u0103r\u021bi \u00een mod propor\u021bional acest num\u0103r \u00eentre clusterele existente. \u0218i acest lucru este configurabil! Adic\u0103 putem specifica c\u0103 pe clusterul de produc\u021bie trebuie s\u0103 avem 6 replici ale aplica\u021biei noastre, iar pe clusterul de rezerv\u0103, pentru a economisi resurse sau pentru divertismentul personal \u2014 doar 4 replici ale aplica\u021biei noastre. Un lucru destul de convenabil. Dar cu federa\u021bia, trebuie s\u0103 folosim solu\u021bii noi, s\u0103 implement\u0103m ceva pe parcurs, s\u0103 ne for\u021b\u0103m s\u0103 g\u00e2ndim pu\u021bin mai mult... <\/p>\n

    Exist\u0103 o modalitate mai simpl\u0103 de a aborda procesul de rezervare a Kubernetes-ului? Ce instrumente avem la dispozi\u021bie?<\/p>\n

    \u00cen primul r\u00e2nd, avem \u00eentotdeauna un sistem ci\/cd, adic\u0103 nu mergem manual, nu scriem pe servere create\/aplicate. Sistemul genereaz\u0103 yaml-uri pentru containerele noastre. <\/p>\n

    \u00cen al doilea r\u00e2nd, exist\u0103 mai multe clustere, fie avem unul, fie mai multe (dac\u0103 suntem de\u0219tep\u021bi) registre, pe care le-am rezervat \u0219i pe acestea. \u0218i exist\u0103 o utilitar\u0103 minunat\u0103, kubectl, care poate lucra cu mai multe clustere simultan. <\/p>\n

    \"Rezervarea
    \n
    \nAsta este: din punctul meu de vedere, cea mai simpl\u0103 \u0219i eficient\u0103 solu\u021bie pentru construirea unui cluster de rezerv\u0103 este un deployment paralel primitiv. Exist\u0103 un pipeline \u00een sistemul ci\/cd; mai \u00eent\u00e2i construim containerele noastre, le test\u0103m \u0219i desf\u0103\u0219ur\u0103m aplica\u021biile prin kubectl pe mai multe clustere independente. Putem realiza desf\u0103\u0219ur\u0103ri simultane pe mai multe clustere. Prin urmare, livrarea configura\u021biilor o solu\u021bion\u0103m \u0219i \u00een aceast\u0103 etap\u0103. Putem defini dinainte un set de configura\u021bii pentru clusterul nostru de produc\u021bie, un set de configura\u021bii pentru clusterul de rezerv\u0103 \u0219i la nivelul sistemului ci\/cd desf\u0103\u0219ur\u0103m mediu de produc\u021bie \u00een clusterul de produc\u021bie, mediu de rezerv\u0103 - \u00een clusterul de rezerv\u0103. Spre deosebire de federa\u021bie, nu trebuie s\u0103 mergem dup\u0103 ce am definit resursa federal\u0103 pe fiecare cluster secundar \u0219i s\u0103 redefinim ceva. Am f\u0103cut asta dinainte. Suntem foarte d\u0103\u0219tep\u021bi.<\/p>\n

    Dar\u2026 exist\u0103\u2026 m-am g\u00e2ndit, exist\u0103 un \u201er\u0103d\u0103cin\u0103 a tuturor relelor\u201d, dar de fapt sunt dou\u0103. \u00cen primul r\u00e2nd, sistemul de fi\u0219iere. Exist\u0103 un anumit PV, sau folosim un stoc extern. Dac\u0103 stoc\u0103m fi\u0219iere \u00een interiorul clusterului, trebuie s\u0103 ac\u021bion\u0103m conform vechilor practici mo\u0219tenite din vremurile infrastructurilor hardware: de exemplu, s\u0103 sincroniz\u0103m cu lsync. Sau cu orice alt\u0103 solu\u021bie preferat\u0103 de tine. Ne desf\u0103\u0219ur\u0103m totul pe alte ma\u0219ini \u0219i continu\u0103m s\u0103 tr\u0103im.<\/p>\n

    \u00cen al doilea r\u00e2nd, \u0219i, de fapt, chiar \u0219i mai important\u0103, este baza de date. Dac\u0103 suntem oameni de\u0219tep\u021bi \u0219i nu p\u0103str\u0103m baza \u00een kubernetes, atunci procesul de rezervare a datelor conform acelea\u0219i scheme vechi - replicare master-slave, apoi comutare, vom prinde replica \u0219i vom tr\u0103i bine. Dar dac\u0103 p\u0103str\u0103m baza noastr\u0103 de date \u00een interiorul clusterului, atunci exist\u0103 multe solu\u021bii gata preg\u0103tite pentru organizarea acelea\u0219i replici master-slave, multe solu\u021bii pentru ridicarea bazei de date \u00een interiorul kubernetes.
    \n Despre rezervarea bazelor de date s-au scris miliarde de prezent\u0103ri, s-au scris miliarde de articole, nu este nimic nou aici, de fapt. \u00cen general, urma\u021bi-v\u0103 visul, tr\u0103i\u021bi cum dori\u021bi, inventa\u021bi-v\u0103 \u0219i voi solu\u021bii complicate, dar g\u00e2ndi\u021bi-v\u0103 \u00eentotdeauna cum ve\u021bi rezerva toate acestea.<\/p>\n

    \u0218i acum, s\u0103 discut\u0103m despre cum va decurge procesul de comutare la un site de rezerv\u0103 \u00een caz de incendiu. \u00cen primul r\u00e2nd, desf\u0103\u0219ur\u0103m aplica\u021bii stateless \u00een paralel. Acestea nu afecteaz\u0103 logica de afaceri a aplica\u021biilor noastre \u0219i a proiectului nostru; putem men\u021bine constant dou\u0103 seturi de aplica\u021bii rulante, iar acestea pot \u00eencepe s\u0103 primeasc\u0103 trafic. Este foarte important, \u00een cadrul procesului de comutare la site-ul de rezerv\u0103, s\u0103 verific\u0103m dac\u0103 trebuie s\u0103 redefinim configura\u021biile. De exemplu, avem un cluster Kubernetes de produc\u021bie, un cluster Kubernetes de rezerv\u0103, o baz\u0103 de date extern\u0103 principal\u0103 \u0219i o baz\u0103 de date principal\u0103 de rezerv\u0103. Avem patru op\u021biuni pentru modul \u00een care aceste aplica\u021bii de produc\u021bie pot \u00eencepe s\u0103 interac\u021bioneze \u00eentre ele. Poate fi comutat\u0103 baza de date \u0219i se poate \u00eent\u00e2mpla s\u0103 fie necesar\u0103 comutarea traficului \u00een clusterul de produc\u021bie c\u0103tre noua baz\u0103 de date. Alternativ, clusterul poate s\u0103 se pr\u0103bu\u0219easc\u0103 \u2014 \u0219i atunci ne mut\u0103m pe rezerv\u0103, dar continu\u0103m s\u0103 lucr\u0103m cu baza de date de produc\u021bie; \u0219i a treia op\u021biune este atunci c\u00e2nd s-au pr\u0103bu\u0219it ambele \u2014 \u0219i comut\u0103m ambele aplica\u021bii, redefinind configura\u021bia noastr\u0103 astfel \u00eenc\u00e2t noile aplica\u021bii s\u0103 lucreze cu noua baz\u0103 de date. <\/p>\n

    A\u0219adar, care sunt concluziile pe care le putem trasa din toate acestea? <\/p>\n

    \"Rezervarea
    \n
    \nPrima concluzie: a tr\u0103i cu un rezerv este bine, dar costisitor. \u00cen ideal, nu ar trebui s\u0103 avem doar un singur rezerv. Ideal ar fi s\u0103 avem mai multe rezerve. \u00cen primul r\u00e2nd, rezervul nu trebuie s\u0103 fie \u00een acela\u0219i centru de date, iar \u00een al doilea r\u00e2nd, ideal ar fi s\u0103 fie la un alt furnizor. Am avut peste 10 asemenea cazuri \u00een practica mea. Proiectele nu le pot numi, dar c\u00e2nd a avut loc incendiul \u00een centrul de date\u2026 Eu am spus: comut\u0103m pe rezerv! Iar serverele de rezerv\u0103 se aflau \u00een acela\u0219i rack...<\/p>\n

    Sau imagina\u021bi-v\u0103 c\u0103 Amazon a fost interzis \u00een Rusia (a\u0219a s-a \u00eent\u00e2mplat). \u0218i gata: ce rost are c\u0103 rezerva noastr\u0103 se afl\u0103 \u00een alt Amazon? Este, de asemenea, inaccesibil. A\u0219a c\u0103 repet: trebuie s\u0103 avem rezerve, cel pu\u021bin \u00eentr-un alt centru de date, dar ideal \u2014 la un alt furnizor. <\/p>\n

    A doua concluzie: dac\u0103 aplica\u021bia ta din Kubernetes comunic\u0103 cu anumite surse externe (poate fi o baz\u0103 de date sau un API extern), este esen\u021bial s\u0103 o define\u0219ti ca un serviciu cu un Endpoint extern, astfel \u00eenc\u00e2t, \u00een momentul comut\u0103rii, s\u0103 nu fie necesar s\u0103 redeployezi 15 aplica\u021bii care acceseaz\u0103 aceea\u0219i baz\u0103. Define\u0219te baza ca un serviciu separat, acceseaz\u0103-o ca \u0219i cum ar fi \u00een interiorul clusterului: dac\u0103 baza ta d\u0103 un rateu, schimbi IP-ul \u00eentr-un singur loc \u0219i continui s\u0103 tr\u0103ie\u0219ti fericit. <\/p>\n

    \u0218i, \u00een final: \u00eemi place \u00abcubul\u00bb, la fel cum \u00eemi plac experimentele cu el. De asemenea, \u00eemi place s\u0103 \u00eemp\u0103rt\u0103\u0219esc rezultatele acestor experimente \u0219i, \u00een general, experien\u021ba mea personal\u0103. De aceea, am \u00eenregistrat o serie de webinarii despre K8s, v\u0103 invit pe canalul nostru de youtube<\/a><\/noindex> pentru detalii.
    \n
    Sursa:     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\udd47Rezervarea \u00een Kubernetes: exist\u0103 | ProHoster","description":"Numele meu este Serghei, sunt de la compania ITSumma \u0219i vreau s\u0103 v\u0103 povestesc despre cum abord\u0103m rezervarea \u00een Kubernetes.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}