{"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\/sv\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Backup i Kubernetes: det existerar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jag heter Sergey, jag kommer fr\u00e5n f\u00f6retaget ITSumma och jag vill ber\u00e4tta f\u00f6r er hur vi n\u00e4rmar oss reservkopiering i Kubernetes. P\u00e5 senare tid har jag arbetat mycket med konsultation kring implementering av olika devops-l\u00f6sningar f\u00f6r olika team, specifikt inom projekt som anv\u00e4nder K8s. P\u00e5 konferensen Uptime day 4, som handlade om reservkopiering inom komplexa arkitekturer, h\u00f6ll jag en presentation om reservkopiering av \"kubik\", och h\u00e4r \u00e4r en fri sammanfattning. Jag varnar dock i f\u00f6rv\u00e4g att detta inte \u00e4r en direkt handbok, utan snarare en sammanst\u00e4llning av tankar kring \u00e4mnet.<\/p>\n

\"Backup
\n
\nI princip \u00e4r \u00f6vervakning och reservkopiering tv\u00e5 grundl\u00e4ggande verktyg f\u00f6r att \u00f6ka drifts\u00e4kerheten i varje projekt. Men i Kubernetes balanseras allt automatiskt, s\u00e4ger ni, allt skalas automatiskt, och om n\u00e5got h\u00e4nder kommer det automatiskt att \u00e5terst\u00e4llas... Vid en f\u00f6rsta ytlig unders\u00f6kning av \u00e4mnet svarade internet p\u00e5 fr\u00e5gan om hur olika tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r reservkopiering i K8s hanteras med \"varf\u00f6r?\" M\u00e5nga tror att Kubernetes \u00e4r en magisk l\u00f6sning som befriar en fr\u00e5n alla infrastrukturella problem och ser till att projektet aldrig faller. Men ... v\u00e4rlden \u00e4r inte vad den ser ut att vara.
\n<\/a><\/noindex>
\nHur n\u00e4rmade vi oss reservkopieringsprocessen tidigare? Vi hade identiska plattformar f\u00f6r hosting - antingen virtuella maskiner eller fysiska servrar, servrar<\/a>, som vi till\u00e4mpade tre grundl\u00e4ggande metoder p\u00e5: <\/p>\n

    \n
  1. kod- och statiksynkronisering<\/li>\n
  2. konfigurationssynkronisering<\/li>\n
  3. databas\u00e5tervinning<\/li>\n<\/ol>\n

    \nOch voil\u00e0: n\u00e4r som helst kan vi byta \u00f6ver till en reservplattform, alla \u00e4r glada, vi reser oss och g\u00e5r. <\/p>\n

    \"Backup
    \n
    \nVad erbjuder vi f\u00f6r att \u00f6ka den permanenta tillg\u00e5ngen till v\u00e5r Kubernetes-applikation? Det f\u00f6rsta som den inofficiella dokumentationen n\u00e4mner \u00e4r att installera m\u00e5nga maskiner, g\u00f6ra m\u00e5nga master-noder \u2014 antalet m\u00e5ste uppfylla kraven f\u00f6r att uppn\u00e5 quorum inom klustret, och att varje master-nod ska k\u00f6ra etcd, API, MC, schemal\u00e4ggare... Och allt verkar fantastiskt: om flera arbetande noder eller master-noder g\u00e5r s\u00f6nder, kommer v\u00e5rt kluster att ombalanseras och applikationen kommer att forts\u00e4tta att fungera. Det ser \u00e5terigen ut som magi! Men ofta befinner sig v\u00e5rt kluster inom en enda datacenter och detta kan orsaka vissa fr\u00e5gor. Vad h\u00e4nder om en gr\u00e4vmaskin gr\u00e4ver upp en kabel, blixten sl\u00e5r ner, eller en universell \u00f6versv\u00e4mning intr\u00e4ffar? Allt \u00e4r f\u00f6rst\u00f6rt, v\u00e5rt kluster finns inte l\u00e4ngre. Hur ska vi hantera redundans med tanke p\u00e5 denna sida av problemet? <\/p>\n

    F\u00f6rst och fr\u00e4mst m\u00e5ste ni ha ett annat kluster som \u00e4r i varm reserv, det vill s\u00e4ga ett kluster som ni kan v\u00e4xla \u00f6ver till n\u00e4r som helst. Ur Kubernetes-perspektiv m\u00e5ste infrastrukturen vara helt identisk. Om det finns n\u00e5gra icke-standardiserade plugins f\u00f6r filsystemet, anpassade l\u00f6sningar f\u00f6r ingress, m\u00e5ste de vara helt identiska p\u00e5 era tv\u00e5 (eller tre, eller tio, beroende p\u00e5 hur mycket pengar och administrat\u00f6rernas tid ni har) kluster. Det \u00e4r n\u00f6dv\u00e4ndigt att tydligt definiera tv\u00e5 upps\u00e4ttningar applikationer (deployment, statefulsets, daemonsets, cronjobs etc.): vilka av dem kan vara aktiva i reservkontot hela tiden och vilka \u00e4r b\u00e4ttre att inte starta f\u00f6rr\u00e4n vid omkopplingen. <\/p>\n

    S\u00e5, ska v\u00e5rt reservkluster vara helt identiskt med v\u00e5rt produktionskluster? Nej. Tidigare, n\u00e4r vi arbetade med monolitiska projekt och h\u00e5rdvaruinfrastruktur, h\u00f6ll vi n\u00e4stan helt identiska milj\u00f6er, men inom Kubernetes, anser jag, ska detta inte vara fallet. L\u00e5t oss titta p\u00e5 varf\u00f6r.<\/p>\n

    Till exempel, l\u00e5t oss b\u00f6rja med de grundl\u00e4ggande enheterna i Kubernetes \u2013 deployments \u2013 de m\u00e5ste vara identiska. Applikationer m\u00e5ste k\u00f6ras som n\u00e4r som helst kan ta \u00f6ver trafikhanteringen och l\u00e5ta v\u00e5rt projekt forts\u00e4tta att leva. N\u00e4r vi pratar om konfigurationsfiler m\u00e5ste vi se till om de b\u00f6r vara identiska eller inte. Det vill s\u00e4ga, om vi, kloka m\u00e4nniskor, inte anv\u00e4nder n\u00e5gra f\u00f6rbjudna \u00e4mnen och inte har databasen i K8s, s\u00e5 m\u00e5ste vi ha inst\u00e4llningar f\u00f6r \u00e5tkomst till produktionsdatabasen i v\u00e5ra configmaps (processen f\u00f6r reservkopiering av den byggs separat). D\u00e4rf\u00f6r, f\u00f6r att s\u00e4kerst\u00e4lla \u00e5tkomst till den reservdatabasen, m\u00e5ste vi ha en separat konfigurationsfil (configmap). P\u00e5 samma s\u00e4tt arbetar vi med secrets: l\u00f6senord f\u00f6r \u00e5tkomst till databasen, API-nycklar; vid vilken tidpunkt som helst kan vi antingen ha det aktiva secretet eller det reserv. S\u00e5 vi har redan tv\u00e5 Kubernetes-enheter vars reservversioner inte ska vara identiska med produktionsversionerna. Den n\u00e4sta enheten att fokusera p\u00e5 \u00e4r cronjob. Cronjob \u00e4r aldrig n\u00e5gonsin ska vara identiska med upps\u00e4ttningen cronjob i produktionsklustret! Om vi s\u00e4tter upp ett reservkluster och aktiverar det fullst\u00e4ndigt med alla aktiva cronjob \u2013 d\u00e5 kommer m\u00e4nniskor till exempel att f\u00e5 tv\u00e5 mejl samtidigt ist\u00e4llet f\u00f6r ett. Eller n\u00e5gon datasyntonisering med externa k\u00e4llor kommer att ske tv\u00e5 g\u00e5nger, vilket g\u00f6r att vi b\u00f6rjar m\u00e5 d\u00e5ligt, gr\u00e5ta, skrika och sl\u00e5ss. <\/p>\n

    \"Backup
    \n
    \nOch hur f\u00f6resl\u00e5r folk p\u00e5 internet att organisera en reservkluster? Det n\u00e4st mest popul\u00e4ra svaret efter \"varf\u00f6r?\" \u2014 anv\u00e4ndning av Kubernetes Federation. <\/p>\n

    Vad \u00e4r det h\u00e4r? Det \u00e4r, l\u00e5t oss s\u00e4ga, en stor meta-kluster. Om vi f\u00f6rest\u00e4ller oss Kubernetes-arkitekturen \u2014 d\u00e4r vi har en master och flera noder \u2014 s\u00e5 har vi ur federationssynpunkt ocks\u00e5 en master och flera noder, men varje nod \u00e4r en separat kluster. Det betyder att vi arbetar med samma entiteter, med samma primitiva som med en enskild Kubernetes, men vi hanterar inte v\u00e5ra fysiska maskiner utan hela kluster. Inom federationen sker det en fullst\u00e4ndig synkronisering av federerade resurser fr\u00e5n f\u00f6r\u00e4ldrar till avkommor. Till exempel, om vi har lanserat en deployment via federation \u2014 s\u00e5 kommer den att deployeras p\u00e5 varje av v\u00e5ra underkluster. Om vi tar en configmap eller en hemlighet och distribuerar den via federation \u2014 s\u00e5 kommer den att spridas \u00f6ver alla v\u00e5ra underkluster; samtidigt till\u00e5ter federation oss att anpassa v\u00e5ra resurser p\u00e5 barnen. Det vill s\u00e4ga, vi tog en configmap, deployerade den via federation och sedan, om vi beh\u00f6ver justera n\u00e5got p\u00e5 specifika kluster, g\u00e5r vi och justerar p\u00e5 det specifika klustret, och den \u00e4ndringen kommer inte att synkroniseras n\u00e5gonstans. <\/p>\n

    Kubernetes Federation \u00e4r ett relativt nytt verktyg och st\u00f6der inte hela upps\u00e4ttningen av resurser som K8s erbjuder: vid tidpunkten f\u00f6r publicering av en av de tidigaste versionerna av dokumentationen n\u00e4mndes det att endast konfigurationskartor, distributioner under replika-set och ingress st\u00f6djdes. Hemligheter st\u00f6ddes inte, och arbete med volymer st\u00f6ddes inte heller. Det \u00e4r en f\u00f6r begr\u00e4nsad upps\u00e4ttning. S\u00e4rskilt om vi tycker om att experimentera \u2014 till exempel, att \u00f6verf\u00f6ra v\u00e5ra egna resurser till Kubernetes via anpassad resursdefinition \u2014 kan vi inte pressa in dem i federation. Det \u00e4r som om\u2026 en l\u00f6sning som n\u00e4stan \u00e4r sann, men som ibland f\u00e5r oss att skjuta oss sj\u00e4lva i foten. \u00c5 andra sidan m\u00f6jligg\u00f6r federation flexibel hantering av v\u00e5rt replicaset. Till exempel, om vi vill ha 10 repliker av v\u00e5r applikation ig\u00e5ng, kommer federationen som standard att f\u00f6rdela detta antal proportionellt mellan antalet kluster. Och allt detta kan ocks\u00e5 konfigureras! Det vill s\u00e4ga, vi kan ange att vi ska ha 6 repliker av v\u00e5r applikation i produktionsklustret, och p\u00e5 reservklustret, f\u00f6r att spara resurser, eller f\u00f6r egna n\u00f6jen \u2014 bara 4 repliker av v\u00e5r applikation. Vilket ocks\u00e5 \u00e4r ganska bekv\u00e4mt. Men med federationen m\u00e5ste vi anv\u00e4nda nya l\u00f6sningar, n\u00e5got m\u00e5ste distribueras p\u00e5 spr\u00e5ng, vi tvingas t\u00e4nka lite mer... <\/p>\n

    Finns det ett enklare s\u00e4tt att n\u00e4rma sig kubernetes reservering? Vilka verktyg har vi \u00f6verhuvudtaget?<\/p>\n

    F\u00f6r det f\u00f6rsta har vi alltid n\u00e5got slags ci\/cd-system, det vill s\u00e4ga vi g\u00e5r inte manuellt in och skriver create\/apply p\u00e5 servrarna. Systemet genererar yaml-filer f\u00f6r v\u00e5ra containrar. <\/p>\n

    F\u00f6r det andra har vi flera kluster, vi har antingen ett eller flera (om vi \u00e4r kloka) registry som vi ocks\u00e5 har tagit och reserverat. Och det finns ett fantastiskt verktyg, kubectl, som kan arbeta med flera kluster samtidigt. <\/p>\n

    \"Backup
    \n
    \nS\u00e5 h\u00e4r \u00e4r det: enligt min \u00e5sikt \u00e4r den enklaste och mest korrekta l\u00f6sningen f\u00f6r att bygga en backupkluster en primitiv parallell distribution. Det finns n\u00e5gon pipeline i ci\/cd-systemet; f\u00f6rst bygger vi v\u00e5ra containrar, testar och distribuerar applikationerna via kubectl till flera oberoende kluster. Vi kan g\u00f6ra samtidigt distributioner p\u00e5 flera kluster. D\u00e4rmed hanterar vi \u00e4ven leveransen av konfigurationer i detta steg. Vi kan i f\u00f6rv\u00e4g definiera en upps\u00e4ttning konfigurationer f\u00f6r v\u00e5rt produktionskluster, en upps\u00e4ttning konfigurationer f\u00f6r backupklustret och p\u00e5 ci\/cd-systemniv\u00e5 distribuera produktionsmilj\u00f6n till produktionsklustret, backupmilj\u00f6n till backupklustret. J\u00e4mf\u00f6rt med federationen beh\u00f6ver vi inte g\u00e5 till varje underkluster efter att ha definierat den federativa resursen och \u00e4ndra n\u00e5got. Vi har gjort detta i f\u00f6rv\u00e4g. Vad duktiga vi \u00e4r.<\/p>\n

    Men\u2026 det finns\u2026 jag hade skrivit, det finns \"ondskapens rot\", men det finns faktiskt tv\u00e5. F\u00f6r det f\u00f6rsta, filsystemet. Det finns n\u00e5gon PV, eller s\u00e5 anv\u00e4nder vi extern lagring. Om vi lagrar filer inne i klustret m\u00e5ste vi agera enligt gamla metoder, sparade fr\u00e5n tiden med fysiska infrastrukturer: till exempel, synkronisera med lsync. Eller med vilket annat krux som du f\u00f6redrar. Vi distribuerar allt till andra maskiner och lever.<\/p>\n

    F\u00f6r det andra, och faktiskt ett mer kritiskt bekymmer \u2014 databasen. Om vi \u00e4r kloka m\u00e4nniskor och inte har databasen i Kubernetes, s\u00e5 \u00e4r processen f\u00f6r datareservering enligt den gamla modellen \u2014 master-slave-replikering, sedan omst\u00e4llning, vi kommer att h\u00e4mta replikatet och leva gott. Men om vi h\u00e5ller v\u00e5r databas inom klustret finns det faktiskt m\u00e5nga f\u00e4rdiga l\u00f6sningar f\u00f6r att organisera samma master-slave-replikation, m\u00e5nga l\u00f6sningar f\u00f6r att konfigurera en databas inom Kubernetes.
    \n Om databass\u00e4kring har det redan h\u00e5llits miljarder presentationer, skrivits miljarder artiklar, det finns inget nytt h\u00e4r, f\u00f6r att vara \u00e4rlig. Sammanfattningsvis, f\u00f6lj dina dr\u00f6mmar, lev som du vill, uppfinna n\u00e5gra komplexa l\u00f6sningar f\u00f6r dig sj\u00e4lv, men t\u00e4nk definitivt p\u00e5 hur du kommer att s\u00e4kra allt detta.<\/p>\n

    Och nu om hur vi i princip kommer att genomf\u00f6ra processen f\u00f6r att v\u00e4xla till en reservanl\u00e4ggning i h\u00e4ndelse av en brand. F\u00f6r det f\u00f6rsta distribuerar vi stateless-applikationer parallellt. De p\u00e5verkar inte aff\u00e4rslogiken f\u00f6r v\u00e5ra applikationer, v\u00e5rt projekt. Vi kan hela tiden ha tv\u00e5 upps\u00e4ttningar av k\u00f6rande applikationer, och de kan b\u00f6rja ta emot trafik. Det \u00e4r mycket viktigt i processen att v\u00e4xla till reservanl\u00e4ggningen att alltid kolla \u2014 beh\u00f6ver vi omdefiniera konfigurationerna? Till exempel har vi en produktionskluster av Kubernetes, en reservkluster av Kubernetes, en extern masterdatabas och en reserv masterdatabas. Vi har fyra alternativ f\u00f6r hur dessa applikationer i produktion kan b\u00f6rja interagera med varandra. Vi kan v\u00e4xla databasen, vilket inneb\u00e4r att vi beh\u00f6ver styra om trafiken i produktionsklustret till den nya databasen, eller s\u00e5 kan klustret fallera \u2014 och vi har flyttat till reserv men forts\u00e4tter att arbeta med produktionsdatabasen. Den tredje varianten \u00e4r n\u00e4r vi har haft problem med det ena och det andra, och vi v\u00e4xlar b\u00e5da applikationerna, omdefinierar v\u00e5r konfiguration s\u00e5 att de nya applikationerna redan arbetar med den nya databasen. <\/p>\n

    Och vilka slutsatser kan vi dra av allt detta? <\/p>\n

    \"Backup
    \n
    \nF\u00f6rsta slutsats: Det \u00e4r bra att ha en reserv. Men det \u00e4r dyrt. Men i idealfallet b\u00f6r man inte bara ha en reserv. Man b\u00f6r i sj\u00e4lva verket ha flera reserver. F\u00f6r det f\u00f6rsta b\u00f6r reservet vara minst inte i en och samma datacenter, och f\u00f6r det andra, minst hos en annan hostingleverant\u00f6r. Det har ofta h\u00e4nt \u2014 och det har jag faktiskt varit med om. Tyv\u00e4rr kan jag inte n\u00e4mna n\u00e5gra projekt, s\u00e4rskilt n\u00e4r det intr\u00e4ffade en brand i datacentret... Jag t\u00e4nkte: vi v\u00e4xlar till reserv! Och de reservservrarna stod i samma rack...<\/p>\n

    Eller t\u00e4nk dig att Amazon blir f\u00f6rbjudet i Ryssland (och det har h\u00e4nt). Och allt: vad hj\u00e4lper det att v\u00e5r reserv ligger hos en annan Amazon? Den \u00e4r ocks\u00e5 otillg\u00e4nglig. S\u00e5 jag upprepar: vi b\u00f6r h\u00e5lla reserv, minst i ett annat datacenter, och helst \u2014 hos en annan hostingleverant\u00f6r. <\/p>\n

    Den andra slutsatsen: om du har en applikation i Kubernetes som kommunicerar med externa k\u00e4llor (som en databas eller ett externt API), definiera den alltid som en tj\u00e4nst med en extern endpoint, s\u00e5 att du inte beh\u00f6ver distribuera 15 av dina applikationer som sl\u00e5r p\u00e5 samma databas vid en omkoppling. Definiera databasen som en egen tj\u00e4nst, kommunicera med den som om den var inuti ditt kluster: om din databas kraschar \u00e4ndrar du IP-adressen p\u00e5 ett st\u00e4lle och forts\u00e4tter att leva lyckligt. <\/p>\n

    Och till sist: Jag \u00e4lskar \"kubik\", precis som jag \u00e4lskar att experimentera med det. Jag gillar ocks\u00e5 att dela resultaten av dessa experiment och min personliga erfarenhet. D\u00e4rf\u00f6r har jag spelat in en serie webbinarier om K8s, v\u00e4lkommen till v\u00e5r youtube-kanal<\/a><\/noindex> f\u00f6r mer information.
    \n
    K\u00e4lla:     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\udd47Reservkopiering i Kubernetes: det existerar | ProHoster","description":"Mitt namn \u00e4r Sergey, jag kommer fr\u00e5n f\u00f6retaget ITSumma, och jag vill ber\u00e4tta hur vi hanterar reservkopiering i Kubernetes.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}