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

Meu nome \u00e9 Sergey, sou da empresa ITSumma, e quero contar como abordamos o backup no Kubernetes. Ultimamente, tenho trabalhado bastante em consultoria para a implementa\u00e7\u00e3o de diversas solu\u00e7\u00f5es DevOps para diferentes equipes, e, em particular, estou envolvido em projetos que utilizam K8s. Na confer\u00eancia Uptime Day 4, que foi dedicada ao backup em arquiteturas complexas, eu apresentei uma palestra sobre o backup do 'cubo', e aqui est\u00e1 uma recapitula\u00e7\u00e3o livre dela. Apenas aviso antecipadamente que n\u00e3o se trata de um guia direto, mas sim de uma s\u00edntese de reflex\u00f5es sobre o assunto.<\/p>\n

\"Backup
\n
\nEm ess\u00eancia, monitoramento e backup s\u00e3o as duas ferramentas principais para aumentar a resili\u00eancia de qualquer projeto. Mas voc\u00ea dir\u00e1, no Kubernetes tudo se equilibra automaticamente, tudo se escala por si s\u00f3, e se algo acontecer, tudo se recupera por si mesmo... Ou seja, em uma primeira pesquisa superficial sobre o tema, ao perguntar como as pessoas abordam o backup no K8s, a internet me respondeu 'por qu\u00ea?'. Muitos pensam que o Kubernetes \u00e9 uma coisa m\u00e1gica que elimina todos os problemas de infraestrutura e garante que o projeto nunca falhe. Mas... o mundo n\u00e3o \u00e9 o que parece.
\n<\/a><\/noindex>
\nComo abordamos o processo de backup no passado? T\u00ednhamos ambientes id\u00eanticos para hospedagem \u2014 ou eram m\u00e1quinas virtuais ou servidores f\u00edsicos servidores<\/a>, aos quais aplic\u00e1vamos tr\u00eas pr\u00e1ticas b\u00e1sicas: <\/p>\n

    \n
  1. sincroniza\u00e7\u00e3o de c\u00f3digo e est\u00e1tica<\/li>\n
  2. sincroniza\u00e7\u00e3o de configura\u00e7\u00f5es<\/li>\n
  3. replica\u00e7\u00e3o de banco de dados<\/li>\n<\/ol>\n

    \nE voil\u00e0: a qualquer momento, podemos alternar para o ambiente de backup, todos ficam felizes, nos levantamos e dispersamos. <\/p>\n

    \"Backup
    \n
    \nE o que nos \u00e9 oferecido para aumentar a disponibilidade cont\u00ednua da nossa aplica\u00e7\u00e3o kubernetes? A primeira coisa mencionada na documenta\u00e7\u00e3o n\u00e3o oficial \u00e9 que devemos implementar v\u00e1rias m\u00e1quinas, criar muitos mestres \u2014 sua quantidade deve atender aos requisitos de qu\u00f3rum dentro do cluster, e que em cada um dos mestres esteja ativo o etcd, api, MC, scheduler... E parece tudo maravilhoso: quando v\u00e1rias n\u00f3s de trabalho ou mestres falham, nosso cluster se reequilibra e a aplica\u00e7\u00e3o continua a funcionar. Novamente soa como m\u00e1gica! Mas muitas vezes nosso cluster est\u00e1 dentro de um \u00fanico centro de dados, o que pode levantar algumas quest\u00f5es. O que acontece se um escavador aparecer e cortar o cabo, se um raio atingir, ou se houver uma inunda\u00e7\u00e3o devastadora? Tudo se perder\u00e1, nosso cluster n\u00e3o existe mais. Como abordar a redund\u00e2ncia considerando esse aspecto do problema? <\/p>\n

    Antes de mais nada, voc\u00ea deve ter outro cluster em reserva quente, ou seja, um cluster para o qual voc\u00ea pode alternar a qualquer momento. Nesse caso, do ponto de vista do Kubernetes, as infraestruturas devem ser totalmente id\u00eanticas. Portanto, se houver plugins n\u00e3o padr\u00e3o para trabalhar com o sistema de arquivos, solu\u00e7\u00f5es personalizadas para ingress, elas devem ser completamente id\u00eanticas em seus dois (ou tr\u00eas, ou dez, dependendo de quanto voc\u00ea pode gastar e da for\u00e7a dos administradores) clusters. \u00c9 necess\u00e1rio definir claramente dois conjuntos de aplicativos (deployments, statefulsets, daemonsets, cronjobs, etc.): quais deles podem operar continuamente na reserva e quais \u00e9 melhor n\u00e3o ativar at\u00e9 a mudan\u00e7a imediata. <\/p>\n

    Ent\u00e3o, nosso cluster de reserva deve ser completamente id\u00eantico ao nosso cluster de produ\u00e7\u00e3o? N\u00e3o. Se antes, ao trabalhar com projetos monol\u00edticos e infraestrutura f\u00edsica, mant\u00ednhamos um ambiente praticamente id\u00eantico, no contexto do Kubernetes, eu acredito que isso n\u00e3o deve ser o caso. Vamos analisar o porqu\u00ea.<\/p>\n

    Por exemplo, come\u00e7aremos com as entidades b\u00e1sicas do Kubernetes \u2014 os deployments \u2014 que devem ser id\u00eanticos. Aplicativos devem ser iniciados que, a qualquer momento, podem assumir o processamento do tr\u00e1fego e permitir que nosso projeto continue vivo. Quando falamos sobre arquivos de configura\u00e7\u00e3o, \u00e9 necess\u00e1rio avaliar se devem ser iguais ou n\u00e3o. Ou seja, se somos pessoas respons\u00e1veis e n\u00e3o usamos subst\u00e2ncias proibidas, e n\u00e3o mantemos a base de dados no K8s, as nossas configmaps devem conter as configura\u00e7\u00f5es de acesso ao banco de dados de produ\u00e7\u00e3o (o processo de backup \u00e9 constru\u00eddo separadamente). Portanto, para garantir o acesso \u00e0 inst\u00e2ncia de backup do banco de dados, devemos ter um arquivo de configura\u00e7\u00e3o (configmap) separado. Da mesma forma, trabalhamos com secrets: senhas de acesso ao banco, chaves de API; a qualquer momento, pode estar ativo ou o secret de produ\u00e7\u00e3o ou o de backup. Assim, j\u00e1 temos duas entidades Kubernetes, cujas vers\u00f5es de backup n\u00e3o devem ser id\u00eanticas \u00e0s de produ\u00e7\u00e3o. A pr\u00f3xima entidade a ser considerada \u00e9 o cronjob. Os cronjobs no backup de maneira alguma devem ser id\u00eanticos ao conjunto de cronjobs do cluster de produ\u00e7\u00e3o! Se levantarmos um cluster de backup e o ativarmos completamente com todos os cronjobs habilitados \u2014 por exemplo, as pessoas poder\u00e3o receber duas mensagens ao inv\u00e9s de uma. Ou alguma sincroniza\u00e7\u00e3o de dados com fontes externas ocorrer\u00e1 duas vezes, e, consequentemente, come\u00e7aremos a nos preocupar, chorar, gritar e nos irritar. <\/p>\n

    \"Backup
    \n
    \nE como nos sugerem organizar o cluster de reserva as pessoas da internet? A segunda resposta mais popular depois de \"qual o sentido?\" \u00e9 o uso da Kubernetes Federation. <\/p>\n

    O que \u00e9 isso? \u00c9, digamos, um grande meta-cluster. Se imaginarmos a arquitetura do Kubernetes \u2014 onde temos um master e v\u00e1rios n\u00f3s \u2014 do ponto de vista da federa\u00e7\u00e3o, tamb\u00e9m temos um master e v\u00e1rios n\u00f3s, mas cada n\u00f3 \u00e9 um cluster separado. Ou seja, estamos lidando com as mesmas entidades e primitivos que em um \u00fanico Kubernetes, apenas manipulando n\u00e3o nossas m\u00e1quinas f\u00edsicas, mas clusters inteiros. Dentro da federa\u00e7\u00e3o, temos uma sincroniza\u00e7\u00e3o completa dos recursos federativos dos pais para os filhos. Por exemplo, se fizermos um deployment atrav\u00e9s da federa\u00e7\u00e3o \u2014 ele ser\u00e1 implantado em cada um de nossos clusters filhotes. Se pegarmos algum configmap, segredo e o distribuirmos pela federa\u00e7\u00e3o \u2014 ele se espalhar\u00e1 por todos os nossos clusters filhotes; ao mesmo tempo, a federa\u00e7\u00e3o permite personalizar nossos recursos nos filhos. Ou seja, pegamos um configmap, implantamos atrav\u00e9s da federa\u00e7\u00e3o e, se precisarmos fazer alguma altera\u00e7\u00e3o nos clusters espec\u00edficos, iremos ajustar em um cluster separado, e essa mudan\u00e7a n\u00e3o ser\u00e1 sincronizada em outros lugares. <\/p>\n

    Kubernetes Federation \u00e9 uma ferramenta relativamente nova e n\u00e3o suporta todo o conjunto de recursos que o pr\u00f3prio K8s oferece: na publica\u00e7\u00e3o de uma das primeiras vers\u00f5es da documenta\u00e7\u00e3o, mencionava-se suporte apenas para config maps, deployment sob replica set e ingress. Segredos n\u00e3o eram suportados, trabalho com volumes tamb\u00e9m n\u00e3o. Um conjunto de recursos bastante limitado. Especialmente se gostamos de brincar, por exemplo, passando nossos pr\u00f3prios recursos para o Kubernetes atrav\u00e9s de custom resource definitions, mas na federa\u00e7\u00e3o n\u00e3o conseguimos fazer isso. Ou seja, parece uma solu\u00e7\u00e3o vi\u00e1vel, mas nos faz atirar no pr\u00f3prio p\u00e9 de vez em quando. Por outro lado, a federa\u00e7\u00e3o permite gerenciar de forma flex\u00edvel o nosso replicaset. Por exemplo, queremos que 10 r\u00e9plicas da nossa aplica\u00e7\u00e3o sejam executadas; por padr\u00e3o, a federa\u00e7\u00e3o divide esse n\u00famero proporcionalmente entre o n\u00famero de clusters. E tudo isso ainda pode ser configurado! Podemos especificar que no cluster de produ\u00e7\u00e3o precisamos manter 6 r\u00e9plicas da nossa aplica\u00e7\u00e3o e, no cluster de reserva, para economizar recursos ou por alguma divers\u00e3o, apenas 4 r\u00e9plicas da nossa aplica\u00e7\u00e3o. Isso tamb\u00e9m \u00e9 bastante conveniente. Mas com a federa\u00e7\u00e3o, precisamos usar algumas novas solu\u00e7\u00f5es, fazer alguns deployments de forma din\u00e2mica, nos for\u00e7ar a pensar um pouco mais... <\/p>\n

    \u00c9 poss\u00edvel abordar o processo de reserva do Kubernetes de uma forma mais simples? Quais ferramentas temos \u00e0 nossa disposi\u00e7\u00e3o?<\/p>\n

    Em primeiro lugar, sempre temos algum sistema ci\/cd, ou seja, n\u00e3o precisamos ir manualmente e escrever nos servidores create\/apply. O sistema gera arquivos yaml para nossos cont\u00eaineres. <\/p>\n

    Em segundo lugar, temos v\u00e1rios clusters, e temos um ou v\u00e1rios (se formos inteligentes) registries, que tamb\u00e9m reservamos. E h\u00e1 uma \u00f3tima ferramenta chamada kubectl, que pode trabalhar com v\u00e1rios clusters ao mesmo tempo. <\/p>\n

    \"Backup
    \n
    \nEnt\u00e3o, na minha opini\u00e3o, a solu\u00e7\u00e3o mais simples e correta para construir um cluster de backup \u00e9 implementar um deploy paralelo primitivo. Existe um pipeline no sistema CI\/CD; primeiro constru\u00edmos nossos cont\u00eaineres, testamos e implantamos os aplicativos atrav\u00e9s do kubectl em v\u00e1rios clusters independentes. Podemos fazer despliegues simult\u00e2neos em v\u00e1rios clusters. Assim, tamb\u00e9m resolvemos a entrega das configura\u00e7\u00f5es nessa etapa. \u00c9 poss\u00edvel definir previamente um conjunto de configura\u00e7\u00f5es para o nosso cluster de produ\u00e7\u00e3o e um conjunto de configura\u00e7\u00f5es para o cluster de backup e, no n\u00edvel do sistema CI\/CD, implantar o ambiente de produ\u00e7\u00e3o no cluster de produ\u00e7\u00e3o e o ambiente de backup no cluster de backup. Comparado \u00e0 federa\u00e7\u00e3o, n\u00e3o precisamos ir a cada cluster filho depois de definir o recurso federativo e reconfigurar algo. Fizemos isso com anteced\u00eancia. Que maravilha somos.<\/p>\n

    Mas... h\u00e1... eu havia escrito, existe a \"raiz de todos os males\", mas, na verdade, s\u00e3o duas. Primeiro, o sistema de arquivos. Existe algum PV, ou usamos armazenamento externo. Se armazenamos arquivos dentro do cluster, devemos agir segundo as pr\u00e1ticas antigas, herdadas dos tempos de infraestrutura f\u00edsica: por exemplo, sincronizar com lsync. Ou com qualquer outro recurso que voc\u00ea prefira. Vamos implantar tudo em outras m\u00e1quinas e seguimos.<\/p>\n

    Em segundo lugar, e, na verdade, um ponto de confronto at\u00e9 mais importante \u2014 o banco de dados. Se somos pessoas inteligentes e n\u00e3o mantemos o banco no Kubernetes, ent\u00e3o o processo de backup de dados segue o mesmo modelo antigo \u2014 replica\u00e7\u00e3o master-slave, depois a mudan\u00e7a, alcan\u00e7amos a r\u00e9plica e viveremos bem. Mas se mantivermos nosso banco de dados dentro do cluster, existem muitas solu\u00e7\u00f5es prontas para organizar a mesma replica\u00e7\u00e3o master-slave, muitas solu\u00e7\u00f5es para levantar um banco de dados dentro do Kubernetes.
    \n J\u00e1 li bilh\u00f5es de relat\u00f3rios sobre backup de bancos de dados, escritos bilh\u00f5es de artigos, n\u00e3o h\u00e1 nada de novo aqui, na verdade. Em geral, siga seu sonho, viva como quiser, invente tamb\u00e9m algumas gambiarras complexas, mas sempre pense em como voc\u00ea ir\u00e1 fazer o backup de tudo isso.<\/p>\n

    Agora vamos falar sobre como, em geral, o processo de mudan\u00e7a para um site de backup ocorrer\u00e1 em caso de inc\u00eandio. Em primeiro lugar, fazemos o deploy paralelo de aplicativos sem estado. Eles n\u00e3o afetam a l\u00f3gica de neg\u00f3cios de nossas aplica\u00e7\u00f5es, do nosso projeto, podemos ter constantemente dois conjuntos de aplicativos em execu\u00e7\u00e3o, e eles podem come\u00e7ar a receber tr\u00e1fego. \u00c9 muito importante, no processo de mudan\u00e7a para o site de backup, verificar se precisamos reconfigurar as configura\u00e7\u00f5es. Por exemplo, temos um cluster Kubernetes de produ\u00e7\u00e3o, um cluster Kubernetes de backup, um banco de dados externo mestre, e um banco de dados externo mestre de backup. Temos quatro op\u00e7\u00f5es de como esses aplicativos em produ\u00e7\u00e3o podem come\u00e7ar a interagir entre si. Podemos ter a mudan\u00e7a do banco de dados e, nesse caso, ser\u00e1 necess\u00e1rio redirecionar o tr\u00e1fego no cluster de produ\u00e7\u00e3o para o novo banco, ou o cluster pode falhar \u2014 e n\u00f3s mudamos para o backup, mas continuamos trabalhando com o banco de dados de produ\u00e7\u00e3o. Al\u00e9m disso, h\u00e1 a terceira op\u00e7\u00e3o, onde ambos falham, e n\u00f3s mudamos ambos os aplicativos, redefinimos nossa configura\u00e7\u00e3o, para que os novos aplicativos funcionem com o novo banco de dados. <\/p>\n

    Ent\u00e3o, quais conclus\u00f5es podemos tirar disso tudo? <\/p>\n

    \"Backup
    \n
    \nPrimeira conclus\u00e3o: viver com backup \u00e9 bom. Mas caro. Idealmente, n\u00e3o devemos depender de um \u00fanico backup. O ideal \u00e9 viver com m\u00faltiplos backups. Em primeiro lugar, o backup deve estar, no m\u00ednimo, em mais de um centro de dados, e, em segundo lugar, de prefer\u00eancia, com outro provedor de hospedagem. J\u00e1 aconteceu muitas vezes \u2014 e na minha experi\u00eancia isso foi o que aconteceu. Infelizmente, n\u00e3o posso nomear os projetos, mas quando ocorreu o inc\u00eandio no centro de dados... Eu disse: vamos mudar para o backup! E os servidores de backup estavam na mesma prateleira...<\/p>\n

    Ou imagine que a Amazon foi banida na R\u00fassia (isso j\u00e1 aconteceu). E pronto: n\u00e3o adianta que nosso backup esteja em outra Amazon? Ele tamb\u00e9m est\u00e1 indispon\u00edvel. Portanto, eu repito: mantenha o backup, no m\u00ednimo, em outro centro de dados, e preferencialmente \u2014 com outro provedor de hospedagem. <\/p>\n

    A segunda conclus\u00e3o \u00e9: se voc\u00ea tem um aplicativo no Kubernetes que se comunica com fontes externas (pode ser um banco de dados ou algum API externo), certifique-se de defini-lo como um servi\u00e7o com Endpoint externo, para que, no momento da troca, voc\u00ea n\u00e3o precise redeployar 15 de seus aplicativos que acessam o mesmo banco. Defina o banco como um servi\u00e7o separado, acesse-o como se estivesse dentro do cluster: se o banco falhar, voc\u00ea pode trocar o IP em um \u00fanico lugar e continuar a viver feliz. <\/p>\n

    E por \u00faltimo: eu amo o \"cubinho\", assim como as experi\u00eancias com ele. Tamb\u00e9m gosto de compartilhar os resultados dessas experi\u00eancias e, de modo geral, minha experi\u00eancia pessoal. Por isso, gravei uma s\u00e9rie de webinars sobre K8s, venha para nosso canal no youtube<\/a><\/noindex> para mais detalhes.
    \n
    Fonte:     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\udd47A reserva no Kubernetes: ela existe | ProHoster","description":"Meu nome \u00e9 Sergey, sou da empresa ITSumma e quero te contar como abordamos a reserva no Kubernetes.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","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\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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/33773","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=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}