{"id":34596,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zhivut-li-bazy-dannyh-v-kubernetes\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"zhivut-li-bazy-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Czy bazy danych \u017cyj\u0105 w Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Czy
\n
\nHistory has somewhat divided the IT industry into two camps: those 'for' and those 'against'. And the subject of disputes can be absolutely arbitrary. Which OS is better: Win or Linux? On a smartphone, Android or iOS? Store everything in the cloud or upload to cold RAID storage and put the drives in a safe? Do PHP developers have the right to call themselves programmers? These debates are sometimes purely existential and have no other basis than sports interest.<\/p>\n

It so happened that with the advent of containers and all this beloved Docker and conditional k8s kitchen, arguments 'for' and 'against' the use of new capabilities in various areas of the backend began. (Let\u2019s clarify in advance that although Kubernetes is most often mentioned as the orchestrator in this discussion, the choice of this particular tool is not crucial. You can replace it with any other tool you find most convenient and familiar.)<\/p>\n

And it would seem that this is just a simple debate between two sides of one coin. Just as senseless and ruthless as the eternal conflict of Win vs Linux, where reasonable people exist somewhere in between. But in the case of containerization, things are not so simple. Usually, there isn\u2019t a right side in such disputes, but in the case of 'to use' or 'not to use' containers for database storage, everything turns upside down. Because, in a certain sense, both supporters and opponents of such an approach are right.
\n<\/a><\/noindex><\/p>\n

The Light Side<\/h4>\n

\nThe argument of the Light Side can be briefly summarized in one phrase: 'Hello, 2k19 outside!' It sounds like populism, undoubtedly, but if you dive into the situation in detail, there are its advantages. Let\u2019s break them down now.<\/p>\n

Za\u0142\u00f3\u017cmy, \u017ce masz du\u017cy projekt internetowy. M\u00f3g\u0142 on by\u0107 pocz\u0105tkowo zbudowany na podstawie podej\u015bcia mikrous\u0142ugowego lub w pewnym momencie ewoluowa\u0142 w tym kierunku \u2014 to tak naprawd\u0119 nie jest istotne. Rozdzieli\u0142e\u015b nasz projekt na poszczeg\u00f3lne mikrous\u0142ugi, skonfigurowa\u0142e\u015b orkiestracj\u0119, r\u00f3wnowa\u017cenie obci\u0105\u017cenia, skalowanie. A teraz z czystym sumieniem popijasz mohito w hamaku podczas efekt\u00f3w Habr, zamiast podnosi\u0107 upad\u0142e serwery. Jednak w ka\u017cdym dzia\u0142aniu nale\u017cy by\u0107 konsekwentnym. Bardzo cz\u0119sto konteneryzuje si\u0119 tylko samo aplikacj\u0119 \u2014 kod. A co jeszcze mamy opr\u00f3cz kodu?<\/p>\n

Dok\u0142adnie, dane. Serce ka\u017cdego projektu \u2014 to jego dane: mog\u0105 to by\u0107 typowe systemy zarz\u0105dzania baz\u0105 danych \u2014 MySQL, Postgre, MongoDB, a tak\u017ce przechowalnie u\u017cywane do wyszukiwania (ElasticSearch), przechowalnie key-value do buforowania \u2014 na przyk\u0142ad redis, itd. Teraz nie b\u0119dziemy m\u00f3wi\u0107 o krzywych wariantach realizacji backendu, kiedy DB pada z powodu \u017ale napisanych zapyta\u0144, a zamiast tego porozmawiamy o zapewnieniu odporno\u015bci tej bazy danych pod obci\u0105\u017ceniem klient\u00f3w. Przecie\u017c gdy konteneryzujemy nasz\u0105 aplikacj\u0119 i pozwalamy jej swobodnie skalowa\u0107, aby obs\u0142ugiwa\u0107 dowoln\u0105 liczb\u0119 przychodz\u0105cych zapyta\u0144, to automatycznie zwi\u0119ksza obci\u0105\u017cenie bazy danych.<\/p>\n

Faktycznie, kana\u0142 dost\u0119pu do bazy danych i serwer, na kt\u00f3rym ona dzia\u0142a, staj\u0105 si\u0119 w\u0105skim gard\u0142em w naszym wspania\u0142ym konteneryzowanym backendzie. G\u0142\u00f3wnym motywem wirtualizacji kontener\u00f3w jest mobilno\u015b\u0107 i elastyczno\u015b\u0107 struktury, kt\u00f3re pozwalaj\u0105 na jak najbardziej efektywne roz\u0142o\u017cenie szczytowego obci\u0105\u017cenia w ca\u0142ej dost\u0119pnej infrastrukturze. Oznacza to, \u017ce je\u015bli nie konteneryzujemy i nie rozk\u0142adamy po klastrze wszystkich element\u00f3w systemu \u2014 pope\u0142niamy bardzo powa\u017cny b\u0142\u0105d.<\/p>\n

O wiele bardziej logiczne jest klastrowanie nie tylko samej aplikacji, ale tak\u017ce us\u0142ug odpowiedzialnych za przechowywanie danych. Podczas klastrowania i uruchamiania niezale\u017cnych dzia\u0142aj\u0105cych i rozdzielaj\u0105cych obci\u0105\u017cenie serwer\u00f3w WWW w k8s, rozwi\u0105zujemy ju\u017c problem synchronizacji danych \u2013 tych samych komentarzy do post\u00f3w, je\u015bli przywo\u0142amy przyk\u0142ad jakiego\u015b medium lub platformy blogowej. W ka\u017cdym razie tworzymy wewn\u0119trzn\u0105, nawet je\u015bli wirtualn\u0105, reprezentacj\u0119 bazy danych jako ExternalService. Problem polega na tym, \u017ce sama baza danych nie jest jeszcze sklastrowana \u2013 uruchomione w klastrze serwery WWW pobieraj\u0105 informacje o zmianach z naszej statycznej bazowej bazy danych, kt\u00f3ra dzia\u0142a osobno.<\/p>\n

Czujesz podst\u0119p? U\u017cywamy k8s lub Swarm, aby rozdzieli\u0107 obci\u0105\u017cenie i unikn\u0105\u0107 awarii g\u0142\u00f3wnej, serwer WWW<\/a>, ale nie robimy tego dla bazy danych. Ale przecie\u017c je\u015bli baza danych upadnie, to w ca\u0142ej naszej sklastrowanej infrastrukturze nie ma sensu \u2013 co nam po pustych stronach WWW, kt\u00f3re zwracaj\u0105 b\u0142\u0105d dost\u0119pu do bazy danych?<\/p>\n

Dok\u0142adnie dlatego nale\u017cy klastrowa\u0107 nie tylko serwery WWW, jak to zazwyczaj si\u0119 robi, ale tak\u017ce infrastruktur\u0119 bazy danych. Tylko w ten spos\u00f3b mo\u017cemy zapewni\u0107 w pe\u0142ni dzia\u0142aj\u0105c\u0105, ale jednocze\u015bnie niezale\u017cn\u0105 od siebie struktur\u0119. Nawet je\u015bli po\u0142owa naszego backendu \u201eprzewr\u00f3ci si\u0119\u201d pod obci\u0105\u017ceniem \u2013 reszta przetrwa, a system synchronizacji bazy danych w obr\u0119bie klastra oraz mo\u017cliwo\u015b\u0107 niesko\u0144czonego skalowania i uruchamiania nowych klastr\u00f3w pomo\u017ce szybko osi\u0105gn\u0105\u0107 wymagane moce \u2013 byleby by\u0142y serwery w centrum danych.<\/p>\n

Ponadto rozproszony w klastrach model bazy danych pozwala przenie\u015b\u0107 t\u0119 sam\u0105 baz\u0119 danych tam, gdzie jest potrzebna; je\u015bli m\u00f3wimy o globalnej us\u0142udze, to do\u015b\u0107 nielogiczne jest uruchamianie klastra WWW gdzie\u015b w rejonie San Francisco i jednoczesne przesy\u0142anie pakiet\u00f3w podczas zapyta\u0144 do bazy danych w Podmoskowie i z powrotem.<\/p>\n

Ponadto konteneryzacja bazy danych pozwala zbudowa\u0107 wszystkie elementy systemu na tym samym poziomie abstrakcji. Co z kolei umo\u017cliwia zarz\u0105dzanie tym systemem bezpo\u015brednio z kodu przez programist\u00f3w, bez aktywnego anga\u017cowania administrator\u00f3w. Programi\u015bci pomy\u015bleli, \u017ce potrzebna jest oddzielna baza danych dla nowego podprojektu \u2013 \u0142atwo! Napisali plik yaml, za\u0142adowali go do klastra i gotowe.<\/p>\n

Oczywi\u015bcie, wewn\u0119trzna eksploatacja znacznie si\u0119 upraszcza. Powiedzcie, ile razy zamykali\u015bcie oczy, gdy nowy cz\u0142onek zespo\u0142u wk\u0142ada\u0142 r\u0119ce do aktywnej bazy danych w pracy? Kt\u00f3ra jest, w rzeczywisto\u015bci, tylko jedna i w\u0142a\u015bnie teraz dzia\u0142a? Oczywi\u015bcie, wszyscy jeste\u015bmy doros\u0142ymi lud\u017ami i gdzie\u015b mamy \u015bwie\u017cy backup, a jeszcze dalej \u2014 za p\u00f3\u0142k\u0105 z og\u00f3rkami babci i starymi nartami \u2014 jeszcze jeden backup, by\u0107 mo\u017ce nawet w zimnym magazynie, poniewa\u017c wasze biuro ju\u017c kiedy\u015b si\u0119 spali\u0142o. Ale mimo to, wprowadzenie nowego cz\u0142onka zespo\u0142u, kt\u00f3ry ma dost\u0119p do aktywnej infrastruktury, a co za tym idzie, do aktywnej bazy danych \u2014 to prawdziwy sprawdzian dla wszystkich wok\u00f3\u0142. Kto wie, mo\u017ce on jest lewor\u0119czny? Straszne, zgadzacie si\u0119.<\/p>\n

Konteneryzacja i w zasadzie rozproszona fizyczna topologia bazy danych waszego projektu pomagaj\u0105 unikn\u0105\u0107 takich stresuj\u0105cych moment\u00f3w. Nie ufacie nowicjuszowi? W porz\u0105dku! Stworzymy mu w\u0142asny klaster do pracy i od\u0142\u0105czymy od pozosta\u0142ych klastr\u00f3w bazy danych \u2014 synchronizacja tylko przez r\u0119czne przesy\u0142anie i synchronizacj\u0119 dw\u00f3ch kluczy (jeden dla lidera zespo\u0142u, drugi dla administratora). I wszyscy s\u0105 zadowoleni.<\/p>\n

A teraz nadszed\u0142 czas, aby przej\u015b\u0107 na stron\u0119 przeciwnik\u00f3w klasteryzacji bazy danych.<\/p>\n

Ciemna Strona<\/h4>\n

\nRozwa\u017caj\u0105c, dlaczego nie warto konteneryzowa\u0107 bazy danych i kontynuowa\u0107 jej dzia\u0142ania na jednym centralnym serwerze<\/a>, nie zejd\u017amy do retoryki ortodoks\u00f3w i stwierdze\u0144 w stylu \u201edziadkowie u\u017cywali baz danych na sprz\u0119cie, a my te\u017c b\u0119dziemy!\u201d Zamiast tego spr\u00f3bujmy wymy\u015bli\u0107 sytuacj\u0119, w kt\u00f3rej konteneryzacja naprawd\u0119 przynosi\u0142aby odczuwalne korzy\u015bci.<\/p>\n

Zg\u00f3d\u017acie si\u0119, \u017ce projekty, kt\u00f3re naprawd\u0119 potrzebuj\u0105 bazy w kontenerze, mo\u017cna policzy\u0107 na palcach jednej r\u0119ki nieco gorszego frezera. W wi\u0119kszo\u015bci przypadk\u00f3w samo u\u017cycie k8s lub Docker Swarm bywa zb\u0119dne \u2014 do tych narz\u0119dzi cz\u0119sto si\u0119gaj\u0105 z powodu og\u00f3lnego rozg\u0142osu technologii i nacisku \u201ewszechmocnych\u201d w osobach mened\u017cer\u00f3w, aby wszystko przenie\u015b\u0107 do chmur i kontener\u00f3w. No bo teraz to modne i wszyscy tak robi\u0105.<\/p>\n

W po\u0142owie przypadk\u00f3w u\u017cycie Kubernetesa lub samego Dockera w projekcie jest przesad\u0105. Problem polega na tym, \u017ce nie wszystkie zespo\u0142y lub firmy outsourcingowe zatrudnione do obs\u0142ugi infrastruktury klienta zdaj\u0105 sobie z tego spraw\u0119. Gorzej, gdy kontenery s\u0105 narzucane, poniewa\u017c wi\u0105\u017ce si\u0119 to z dodatkowymi kosztami dla klienta.<\/p>\n

Og\u00f3lnie panuje przekonanie, \u017ce mafia Docker\/Kubernetes po prostu zdominowuje klient\u00f3w, kt\u00f3rzy powierzaj\u0105 te kwestie infrastrukturalne na outsourcing. Przecie\u017c do pracy z klasterami potrzebni s\u0105 in\u017cynierowie, kt\u00f3rzy potrafi\u0105 to zrobi\u0107 i rozumiej\u0105 w og\u00f3le architektur\u0119 wdro\u017conego rozwi\u0105zania. Opisywali\u015bmy ju\u017c nasz przypadek z publikacj\u0105 Republic \u2013 tam nauczyli\u015bmy zesp\u00f3\u0142 klienta pracowa\u0107 w warunkach Kubernetesa i wszyscy byli zadowoleni. I to by\u0142o solidne. Zazwyczaj jednak \u201ewdro\u017ceniowcy\u201d K8s bior\u0105 infrastruktur\u0119 klienta jako zak\u0142adnik\u00f3w \u2013 teraz tylko oni rozumiej\u0105, jak to wszystko dzia\u0142a, a po stronie klienta nie ma specjalist\u00f3w.<\/p>\n

A teraz wyobra\u017acie sobie, \u017ce w ten spos\u00f3b oddajemy nie tylko cz\u0119\u015b\u0107 serwera WWW w r\u0119ce outsourcingu, ale r\u00f3wnie\u017c obs\u0142ug\u0119 bazy danych. M\u00f3wili\u015bmy, \u017ce baza danych to serce, a jej utrata jest fatalna dla ka\u017cdego \u017cywego organizmu. Kr\u00f3tko m\u00f3wi\u0105c, perspektywy nie s\u0105 najlepsze. Tak wi\u0119c zamiast modnego Kubernetesa, wielu projektom powinno po prostu nie \u017ca\u0142owa\u0107 pieni\u0119dzy na normalny plan na AWS, kt\u00f3ry rozwi\u0105\u017ce wszystkie problemy z obci\u0105\u017ceniem ich strony\/projektu. Jednak AWS ju\u017c nie jest modne, a fajerwerki s\u0105 dro\u017csze od pieni\u0119dzy \u2013 niestety, tak\u017ce w bran\u017cy IT.<\/p>\n

Okej. Mo\u017ce klasteryzacja jest rzeczywi\u015bcie potrzebna projektowi, ale je\u015bli w przypadku aplikacji stateless wszystko jest jasne, to jak zorganizowa\u0107 odpowiednie zapewnienie \u0142\u0105czno\u015bci sieciowej dla klasteryzowanej bazy danych?<\/p>\n

Je\u015bli m\u00f3wimy o bezproblemowym in\u017cynieryjnym rozwi\u0105zaniu, jakim jest przej\u015bcie na k8s, to nasz\u0105 g\u0142\u00f3wn\u0105 bol\u0105czk\u0105 jest replikacja danych w skonsolidowanej bazie danych. Niekt\u00f3re systemy zarz\u0105dzania baz\u0105 danych pocz\u0105tkowo do\u015b\u0107 przyja\u017anie podchodz\u0105 do rozdzielania danych mi\u0119dzy swoimi instancjami. Wiele innych nie jest tak skore do wsp\u00f3\u0142pracy. Cz\u0119sto g\u0142\u00f3wnym argumentem przy wyborze systemu zarz\u0105dzania baz\u0105 danych do naszego projektu nie jest wcale zdolno\u015b\u0107 do replikacji przy minimalnych kosztach zasob\u00f3w i in\u017cynierii. Szczeg\u00f3lnie je\u015bli projekt nie by\u0142 pocz\u0105tkowo planowany jako mikrous\u0142uga, ale ewoluowa\u0142 w tym kierunku. <\/p>\n

My\u015bl\u0119, \u017ce nie musimy m\u00f3wi\u0107 o pr\u0119dko\u015bci dzia\u0142ania sieciowych dysk\u00f3w - s\u0105 wolne. To znaczy, w przypadku konieczno\u015bci, nie mamy realnej mo\u017cliwo\u015bci przeniesienia instancji systemu zarz\u0105dzania baz\u0105 danych gdzie indziej, gdzie na przyk\u0142ad jest wi\u0119cej mocy procesora lub wolnej pami\u0119ci RAM. Bardzo szybko napotykamy na ograniczenia wydajno\u015bci wirtualizowanego systemu dyskowego. W zwi\u0105zku z tym, system zarz\u0105dzania baz\u0105 danych musi by\u0107 przypisany do w\u0142asnego zestawu maszyn, znajduj\u0105cych si\u0119 w bezpo\u015bredniej blisko\u015bci. Albo trzeba jako\u015b oddzielnie zorganizowa\u0107 wystarczaj\u0105co szybk\u0105 synchronizacj\u0119 danych na przewidywane rezerwy. <\/p>\n

Kontynuuj\u0105c temat wirtualnych system\u00f3w plik\u00f3w: Woluminy Dockera niestety nie s\u0105 bezproblemowe. Og\u00f3lnie rzecz bior\u0105c, w sprawach takich jak d\u0142ugoterminowe niezawodne przechowywanie danych chcieliby\u015bmy korzysta\u0107 z jak najprostszych technicznych schemat\u00f3w. Dodanie nowej warstwy abstrakcji z systemu plik\u00f3w kontenera do systemu plik\u00f3w rodzica \u2014 samo w sobie stanowi ryzyko. Ale kiedy napotykamy trudno\u015bci w pracy systemu zapewniaj\u0105cego konteneryzacj\u0119 przy przesy\u0142aniu danych mi\u0119dzy tymi warstwami, to ju\u017c prawdziwe k\u0142opoty. Na obecnym etapie wi\u0119kszo\u015b\u0107 znanych problem\u00f3w zdaje si\u0119 by\u0107 rozwi\u0105zana. Ale sami rozumiecie, im bardziej skomplikowany mechanizm, tym \u0142atwiej si\u0119 \u0142amie.<\/p>\n

W \u015bwietle wszystkich tych \u00abprzygod\u00bb znacznie korzystniej i \u0142atwiej jest trzyma\u0107 baz\u0119 danych w jednym miejscu, a nawet je\u015bli potrzebujesz konteneryzacji aplikacji \u2014 niech dzia\u0142a sama dla siebie i przez bramk\u0119 rozdzielaj\u0105c\u0105 uzyskuje r\u00f3wnoczesne po\u0142\u0105czenie z baz\u0105 danych, kt\u00f3ra b\u0119dzie odczytywana i zapisywana tylko raz i w jednym miejscu. Takie podej\u015bcie minimalizuje ryzyko b\u0142\u0119d\u00f3w i desynchronizacji.<\/p>\n

Do czego zmierzamy? Do tego, \u017ce konteneryzacja baz danych ma sens tam, gdzie jest rzeczywista potrzeba. Nie mo\u017cna spakowa\u0107 bazy full-app i uruchamia\u0107 jej tak, jakby\u015b mia\u0142 dwa tuziny mikrous\u0142ug \u2014 to tak nie dzia\u0142a. I to trzeba jasno zrozumie\u0107.<\/p>\n

Zamiast wyj\u015bcia<\/h4>\n

\nJe\u015bli oczekujesz wyra\u017anej odpowiedzi na pytanie \u201ewirtualizowa\u0107 czy nie bazy danych\u201d, to zawiedziemy ci\u0119: nie b\u0119dzie jej tutaj. Poniewa\u017c przy tworzeniu jakiegokolwiek rozwi\u0105zania infrastrukturalnego nale\u017cy kierowa\u0107 si\u0119 nie mod\u0105 i post\u0119pem, ale przede wszystkim zdrowym rozs\u0105dkiem.<\/p>\n

S\u0105 projekty, w kt\u00f3re zasady i narz\u0119dzia zwi\u0105zane z Kubernetes idealnie pasuj\u0105, i w takich projektach zapada pok\u00f3j przynajmniej w obszarze backendu. A s\u0105 projekty, kt\u00f3re potrzebuj\u0105 nie konteneryzacji, a normalnej infrastruktury serwerowej, poniewa\u017c zasadniczo nie mog\u0105 si\u0119 przeskalowa\u0107 w model mikrous\u0142ugowy, bo si\u0119 nie sprawdz\u0105.
\n
\u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e \u043b\u044e\u0431\u043e\u043c\u0443 \u043f\u043e\u0432\u043e\u0434\u0443 \u0440\u0430\u0437\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u0443\u0441\u043b\u043e\u0432\u043d\u044b\u0445 \u043b\u0430\u0433\u0435\u0440\u044f: \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u0437\u0430\u00bb \u0438 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u043f\u0440\u043e\u0442\u0438\u0432\u00bb. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u0441\u043f\u043e\u0440\u043e\u0432 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u043c. \u041a\u0430\u043a\u0430\u044f \u041e\u0421 \u043b\u0443\u0447\u0448\u0435: Win \u0438\u043b\u0438 Linux? \u041d\u0430 \u0441\u043c\u0430\u0440\u0442\u0444\u043e\u043d\u0435 Android \u0438\u043b\u0438 iOS? \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u0432 \u043e\u0431\u043b\u0430\u043a\u0430\u0445 \u0438\u043b\u0438 \u0437\u0430\u043b\u0438\u0432\u0430\u0442\u044c \u043d\u0430 \u0445\u043e\u043b\u043e\u0434\u043d\u044b\u0435 RAID-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0438 \u043a\u043b\u0430\u0441\u0442\u044c \u0432\u0438\u043d\u0442\u044b \u0432 \u0441\u0435\u0439\u0444? \u0418\u043c\u0435\u044e\u0442 \u043b\u0438 PHP-\u0448\u043d\u0438\u043a\u0438 \u043f\u0440\u0430\u0432\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34596","post","type-post","status-publish","format-standard","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\udd47Czy bazy danych \u017cyj\u0105 w Kubernetes? | ProHoster","description":"Jako\u015b tak historycznie si\u0119 z\u0142o\u017cy\u0142o, \u017ce bran\u017ca IT.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\u0416\u0438\u0432\u0443\u0442 \u043b\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Kubernetes? | ProHoster","og:description":"\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34596","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 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-02-09 21:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}