{"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\/pt\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Os bancos de dados vivem no Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Os
\n
\nHistoricamente, a ind\u00fastria de TI se divide em dois campos, aqueles que est\u00e3o \"a favor\" e aqueles que est\u00e3o \"contra\". E o tema das discuss\u00f5es pode ser absolutamente arbitr\u00e1rio. Qual sistema operacional \u00e9 melhor: Windows ou Linux? Usar Android ou iOS no smartphone? Armazenar tudo na nuvem ou utilizar datacenters RAID frios e guardar os discos em um cofre? Os programadores PHP t\u00eam o direito de se chamar de programadores? Esses debates, \u00e0s vezes, t\u00eam um car\u00e1ter exclusivamente existencial e n\u00e3o t\u00eam base al\u00e9m do interesse esportivo.<\/p>\n

Assim, com o surgimento dos containers e de todo esse universo que adoramos com Docker e o Kubernetes, come\u00e7aram as discuss\u00f5es \"a favor\" e \"contra\" o uso de novas possibilidades em diversas \u00e1reas do backend. (Adiantamos que, embora na maioria das vezes o Kubernetes seja citado como orquestrador, a escolha deste instrumento em particular n\u00e3o \u00e9 fundamental. Voc\u00ea pode substitu\u00ed-lo por qualquer outro que achar mais conveniente e familiar.)<\/p>\n

E, \u00e0 primeira vista, poderia parecer uma simples discuss\u00e3o entre dois lados da mesma moeda. Assim como a eterna rivalidade entre Windows e Linux, na qual pessoas razo\u00e1veis existem em algum lugar no meio. Por\u00e9m, no caso da containeriza\u00e7\u00e3o, as coisas n\u00e3o s\u00e3o t\u00e3o simples. Geralmente, nesses debates n\u00e3o h\u00e1 um lado certo, mas no caso de \"usar\" ou \"n\u00e3o usar\" containers para armazenar bancos de dados, tudo se inverte. Porque, em certo sentido, tanto os defensores quanto os opositores desse abordagem est\u00e3o corretos.
\n<\/a><\/noindex><\/p>\n

Lado Luminoso<\/h4>\n

\nPodemos resumir a argumenta\u00e7\u00e3o do Lado Luminoso em uma frase: \u201cEi, 2019 est\u00e1 a\u00ed!\u201d Soa como populismo, sem d\u00favida, mas se olharmos a situa\u00e7\u00e3o em detalhe, h\u00e1 seus benef\u00edcios. Vamos analisar esses pontos agora.<\/p>\n

Suponhamos que voc\u00ea tenha um grande projeto web. Ele pode ter sido inicialmente constru\u00eddo com base em uma abordagem de microsservi\u00e7os, ou pode ter chegado a essa arquitetura de forma evolutiva \u2014 isso, na verdade, n\u00e3o \u00e9 muito importante. Voc\u00ea dividiu nosso projeto em microsservi\u00e7os separados, configurou a orquestra\u00e7\u00e3o, o balanceamento de carga e a escalabilidade. E agora, com a consci\u00eancia tranquila, voc\u00ea est\u00e1 tomando um mojito na rede enquanto desfruta dos efeitos dos hacks, em vez de precisar reiniciar servidores que ca\u00edram. Mas em todas as a\u00e7\u00f5es, \u00e9 preciso ter consist\u00eancia. Muito frequentemente, apenas o pr\u00f3prio aplicativo \u2014 o c\u00f3digo \u2014 \u00e9 conteinerizado. E o que mais temos al\u00e9m do c\u00f3digo?<\/p>\n

Correto, os dados. O cora\u00e7\u00e3o de qualquer projeto s\u00e3o seus dados: isso pode ser desde um banco de dados t\u00edpico \u2014 MySQL, PostgreSQL, MongoDB \u2014 at\u00e9 fontes de armazenamento utilizadas para busca (ElasticSearch), ou armazenamento key-value para cache \u2014 por exemplo, Redis, etc. Neste momento, n\u00e3o vamos falar sobre as implementa\u00e7\u00f5es problem\u00e1ticas de backend, onde o banco de dados cai devido a consultas mal escritas, mas sim sobre como garantir a resili\u00eancia desse banco de dados sob a carga do cliente. Afinal, quando conteinerizamos nosso aplicativo e permitimos que ele escale livremente para lidar com qualquer quantidade de solicita\u00e7\u00f5es recebidas, isso necessariamente aumenta tamb\u00e9m a carga sobre o banco de dados.<\/p>\n

Na verdade, o canal de acesso ao banco de dados e o servidor em que ele est\u00e1 rodando se tornam o gargalo em nosso maravilhoso backend containerizado. O principal motivo da virtualiza\u00e7\u00e3o por cont\u00eainer \u00e9 a mobilidade e flexibilidade da estrutura, permitindo organizar a distribui\u00e7\u00e3o da carga m\u00e1xima em toda a infraestrutura dispon\u00edvel da forma mais eficiente poss\u00edvel. Ou seja, se n\u00e3o containerizarmos e n\u00e3o distribuirmos todos os elementos do sistema pelo cluster \u2014 estamos cometendo um erro muito s\u00e9rio.<\/p>\n

\u00c9 muito mais l\u00f3gico agrupar n\u00e3o apenas o pr\u00f3prio aplicativo, mas tamb\u00e9m os servi\u00e7os respons\u00e1veis pelo armazenamento de dados. Ao implementar e implantar servidores web independentes que distribuam a carga entre si no k8s, j\u00e1 resolvemos o problema de sincroniza\u00e7\u00e3o de dados \u2014 como os coment\u00e1rios em postagens, se pegarmos como exemplo algum meio de comunica\u00e7\u00e3o ou plataforma de blogs. De qualquer forma, criamos uma representa\u00e7\u00e3o interna da base de dados, mesmo que virtual, como ExternalService. A quest\u00e3o \u00e9 que a pr\u00f3pria base de dados ainda n\u00e3o est\u00e1 agrupada \u2014 os servidores web implantados no cluster obt\u00eam informa\u00e7\u00f5es sobre as mudan\u00e7as da nossa base de dados est\u00e1tica que funciona separadamente.<\/p>\n

Sente uma pegadinha? Usamos k8s ou Swarm para distribuir a carga e evitar a queda do principal servidor web<\/a>, mas n\u00e3o fazemos isso para a base de dados. Contudo, se a base de dados cair, toda a nossa infraestrutura agrupada perde o sentido \u2014 de que adianta p\u00e1ginas web vazias que retornam um erro de acesso \u00e0 base de dados?<\/p>\n

\u00c9 precisamente por isso que a agrupa\u00e7\u00e3o deve envolver n\u00e3o apenas os servidores web, como \u00e9 normalmente feito, mas tamb\u00e9m a infraestrutura da base de dados. Apenas assim podemos garantir uma estrutura que funciona plenamente em uma \u00fanica unidade, mas ainda assim independente umas das outras. Mesmo que metade do nosso backend \u201cdesmorone\u201d sob carga \u2014 o restante sobreviver\u00e1, e o sistema de sincroniza\u00e7\u00e3o da base de dados entre si dentro do cluster, junto com a possibilidade de escalonamento infinito e implanta\u00e7\u00e3o de novos clusters, ajudar\u00e1 a alcan\u00e7ar rapidamente as capacidades necess\u00e1rias \u2014 se houver racks no datacenter.<\/p>\n

Al\u00e9m disso, o modelo de base de dados distribu\u00edda em clusters permite levar essa mesma base de dados para onde ela \u00e9 necess\u00e1ria; se estamos falando de um servi\u00e7o global, \u00e9 bastante il\u00f3gico operar um cluster web em algum lugar na \u00e1rea de S\u00e3o Francisco e ao mesmo tempo trafegar pacotes ao acessar a base de dados na regi\u00e3o de Moscou e voltar.<\/p>\n

Al\u00e9m disso, a containeriza\u00e7\u00e3o da base de dados permite construir todos os elementos do sistema em um mesmo n\u00edvel de abstra\u00e7\u00e3o. Isso, por sua vez, possibilita gerenciar esse sistema diretamente do c\u00f3digo, pelos desenvolvedores, sem a necessidade de envolver ativamente os administradores. Os desenvolvedores perceberam que precisavam de um SGBD separado para um novo subprojeto \u2014 f\u00e1cil! Criaram um arquivo yaml, carregaram no cluster, e tudo pronto.<\/p>\n

E, claro, a opera\u00e7\u00e3o interna torna-se muito mais f\u00e1cil. Diga-me, quantas vezes voc\u00ea fechou os olhos quando um novo membro da equipe tentou acessar o banco de dados de produ\u00e7\u00e3o? Que, na verdade, \u00e9 o \u00fanico que voc\u00ea tem e que est\u00e1 rodando agora mesmo? Claro, todos n\u00f3s somos adultos aqui, e temos um backup recente em algum lugar, e ainda mais atr\u00e1s \u2014 atr\u00e1s da prateleira com os pepinos da av\u00f3 e os esquis antigos \u2014 um outro backup, possivelmente at\u00e9 em armazenamento frio, porque uma vez seu escrit\u00f3rio pegou fogo. Mas, mesmo assim, cada entrada de um novo membro da equipe que tem acesso \u00e0 infraestrutura de produ\u00e7\u00e3o e, claro, ao banco de dados de produ\u00e7\u00e3o \u00e9 um balde de Valium para todos ao redor. Quem conhece esse novato? E se ele for desastrado? \u00c9 assustador, concorda?<\/p>\n

A conteineriza\u00e7\u00e3o e, na verdade, a topologia f\u00edsica distribu\u00edda do seu banco de dados ajudam a evitar esses momentos de estresse. Voc\u00ea n\u00e3o confia no novato? Ok! Vamos criar um cluster pr\u00f3prio para ele trabalhar e desconect\u00e1-lo dos outros clusters de banco de dados \u2014 a sincroniza\u00e7\u00e3o ser\u00e1 apenas por push manual e a ativa\u00e7\u00e3o simult\u00e2nea de duas chaves (uma para o l\u00edder da equipe e a outra para o admin). E todos ficam felizes.<\/p>\n

Agora \u00e9 hora de mudar de ideia em rela\u00e7\u00e3o \u00e0 clusteriza\u00e7\u00e3o do banco de dados.<\/p>\n

Lado Sombrio<\/h4>\n

\nRefletindo sobre por que n\u00e3o se deve conteinerizar o banco de dados e continuar a oper\u00e1-lo em um \u00fanico central servidor<\/a>, n\u00e3o vamos nos rebaixar a ret\u00f3ricas de ortodoxos e afirma\u00e7\u00f5es do tipo \"nossos antecessores operavam bancos de dados em hardware, e n\u00f3s iremos fazer o mesmo!\" Em vez disso, vamos tentar imaginar uma situa\u00e7\u00e3o em que a conteineriza\u00e7\u00e3o realmente traria dividendos significativos.<\/p>\n

Concorde que os projetos que realmente precisam de um banco de dados em cont\u00eainer podem ser contados com os dedos de uma m\u00e3o, mesmo que n\u00e3o muito habilidosa. Na maioria dos casos, at\u00e9 mesmo o uso de k8s ou Docker Swarm se mostra excessivo \u2014 muitas vezes, essas ferramentas s\u00e3o usadas pela popularidade geral das tecnologias e pela press\u00e3o de diretores para jogar tudo nas nuvens e em cont\u00eaineres. Porque agora isso est\u00e1 na moda e todo mundo est\u00e1 fazendo isso.<\/p>\n

Em pelo menos metade dos casos, o uso do Kubernetes ou simplesmente do Docker em um projeto \u00e9 desnecess\u00e1rio. A quest\u00e3o \u00e9 que nem todas as equipes ou empresas de outsourcing contratadas para gerenciar a infraestrutura do cliente t\u00eam plena consci\u00eancia disso. Pior ainda, quando os cont\u00eaineres s\u00e3o impostos, pois isso se torna um custo consider\u00e1vel para o cliente.<\/p>\n

De modo geral, existe a opini\u00e3o de que a mafia do Docker\/Kubernetes simplesmente subjuga os clientes que delegam essas quest\u00f5es de infraestrutura para o outsourcing. Afinal, para trabalhar com clusters, s\u00e3o necess\u00e1rios engenheiros que compreendam isso e a arquitetura da solu\u00e7\u00e3o implementada. N\u00f3s j\u00e1 comentamos sobre nosso caso com a publica\u00e7\u00e3o Republic \u2014 l\u00e1, treinamos a equipe do cliente a trabalhar nas realidades do Kubernetes, e todos ficaram satisfeitos. E foi um trabalho honesto. Muitas vezes, os 'implementadores' do Kubernetes sequestram a infraestrutura do cliente \u2014 agora, apenas eles entendem como tudo funciona, enquanto do lado do cliente n\u00e3o h\u00e1 especialistas.<\/p>\n

Agora imagine que estamos entregando n\u00e3o apenas a parte do servidor web, mas tamb\u00e9m a manuten\u00e7\u00e3o do banco de dados ao outsourcing. J\u00e1 dissemos que o banco de dados \u00e9 o cora\u00e7\u00e3o, e a perda do cora\u00e7\u00e3o \u00e9 fatal para qualquer organismo vivo. Resumindo, as perspectivas n\u00e3o s\u00e3o as melhores. Portanto, em vez do hype em torno do Kubernetes, muitos projetos deveriam simplesmente investir em um plano adequado na AWS, que resolveria todos os problemas de carga em seus sites\/projetos. Mas a AWS j\u00e1 n\u00e3o \u00e9 mais tend\u00eancia, e a apar\u00eancia custa mais do que o dinheiro \u2014 infelizmente, isso tamb\u00e9m se aplica ao setor de TI.<\/p>\n

Ok. Talvez a clusteriza\u00e7\u00e3o realmente seja necess\u00e1ria para o projeto, mas se a quest\u00e3o das aplica\u00e7\u00f5es stateless est\u00e1 clara, como ent\u00e3o organizar uma conex\u00e3o de rede adequada para um banco de dados clusterizado?<\/p>\n

Quando falamos sobre a solu\u00e7\u00e3o de engenharia sem costura que representa a transi\u00e7\u00e3o para o k8s, a nossa maior preocupa\u00e7\u00e3o \u00e9 a replica\u00e7\u00e3o de dados em um banco de dados clusterizado. Alguns SGBDs t\u00eam uma abordagem bastante flex\u00edvel em rela\u00e7\u00e3o \u00e0 distribui\u00e7\u00e3o de dados entre suas inst\u00e2ncias. No entanto, muitos outros n\u00e3o s\u00e3o t\u00e3o receptivos. E, frequentemente, o principal argumento na escolha do SGBD para nosso projeto n\u00e3o \u00e9 a capacidade de replica\u00e7\u00e3o com o m\u00ednimo de recursos e custos de engenharia. Especialmente se o projeto n\u00e3o foi inicialmente planejado como microservi\u00e7o e simplesmente evoluiu nessa dire\u00e7\u00e3o. <\/p>\n

Acreditamos que n\u00e3o \u00e9 necess\u00e1rio falar sobre a velocidade dos discos de rede \u2014 eles s\u00e3o lentos. Ou seja, n\u00e3o temos a real possibilidade de, caso necess\u00e1rio, reiniciar a inst\u00e2ncia do SGBD em algum lugar onde haja mais, por exemplo, poder de processamento ou mem\u00f3ria RAM livre. Rapidamente esbarramos na performance do subsistema de disco virtualizado. Portanto, o SGBD deve estar vinculado ao seu pr\u00f3prio conjunto pessoal de m\u00e1quinas, localizadas nas proximidades. Ou ent\u00e3o precisamos encontrar uma maneira de garantir uma sincroniza\u00e7\u00e3o de dados suficientemente r\u00e1pida com as reservas planejadas. <\/p>\n

Continuando o assunto dos sistemas de arquivos virtuais: os Docker Volumes, infelizmente, n\u00e3o s\u00e3o isentos de problemas. De modo geral, em quest\u00f5es de armazenamento de dados confi\u00e1vel e de longo prazo, gostar\u00edamos de utilizar esquemas tecnicamente simples. E a adi\u00e7\u00e3o de uma nova camada de abstra\u00e7\u00e3o do sistema de arquivos do cont\u00eainer para o sistema de arquivos do host pai \u2014 isso por si s\u00f3 j\u00e1 \u00e9 um risco. Mas quando ainda surgem dificuldades na opera\u00e7\u00e3o do sistema de cont\u00eaineriza\u00e7\u00e3o em transmitir dados entre essas camadas, a situa\u00e7\u00e3o se complica ainda mais. No momento, a maioria dos problemas conhecidos pela humanidade parece ter sido resolvida. Mas voc\u00eas entendem, quanto mais complexo o mecanismo, mais simples ele se quebra.<\/p>\n

\u00c0 luz de todas essas \"aventuras\", \u00e9 muito mais vantajoso e simples manter o banco de dados em um \u00fanico lugar, e mesmo que voc\u00ea precise da containeriza\u00e7\u00e3o da aplica\u00e7\u00e3o \u2014 deixe-a rodar sozinha e, atrav\u00e9s de um gateway de distribui\u00e7\u00e3o, receba a conex\u00e3o simult\u00e2nea com o banco de dados, que ser\u00e1 lido e escrito apenas uma vez e em um s\u00f3 lugar. Essa abordagem reduz a probabilidade de erros e desincroniza\u00e7\u00f5es a n\u00edveis m\u00ednimos.<\/p>\n

A que estamos nos referindo? Ao fato de que a containeriza\u00e7\u00e3o de bancos de dados \u00e9 apropriada quando existe uma necessidade real. N\u00e3o se pode simplesmente empacotar um banco de dados de um aplicativo completo e faz\u00ea-lo rodar como se voc\u00ea tivesse uma d\u00fazia de microsservi\u00e7os \u2014 isso n\u00e3o funciona assim. E \u00e9 preciso entender isso claramente.<\/p>\n

Em vez de uma conclus\u00e3o<\/h4>\n

\nSe voc\u00ea espera uma conclus\u00e3o clara sobre \"virtualizar ou n\u00e3o o banco de dados\", lamentamos: n\u00e3o a ter\u00e1 aqui. Porque ao criar qualquer solu\u00e7\u00e3o de infraestrutura, deve-se seguir n\u00e3o as modas e o progresso, mas, primeiramente, o bom senso.<\/p>\n

Existem projetos para os quais os princ\u00edpios e ferramentas que v\u00eam com o Kubernetes se encaixam perfeitamente, e nesses projetos a paz se estabelece pelo menos na \u00e1rea de backend. E h\u00e1 projetos que precisam n\u00e3o de containeriza\u00e7\u00e3o, mas de uma infraestrutura de servidor adequada, porque eles n\u00e3o conseguem fundamentalmente se reescalar para um modelo de cluster de microsservi\u00e7os, pois isso causaria falhas.
\n
Fonte: 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\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\udd47Os bancos de dados vivem no Kubernetes? | ProHoster","description":"Historicamente, a ind\u00fastria de TI se desenvolveu assim.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}