Olá a todos! Meu nome é Pavel Agaletsky. Trabalho como líder de equipe em uma equipe que desenvolve o sistema de entrega Lamoda. Em 2018, falei na conferência HighLoad++ e hoje gostaria de apresentar uma transcrição do meu relatório.

Meu tópico é dedicado à experiência de nossa empresa na implantação de sistemas e serviços em diferentes ambientes. Desde nossos tempos pré-históricos, quando implantamos todos os sistemas em servidores virtuais comuns, terminando com a transição gradual do Nomad para a implantação no Kubernetes. Vou lhe contar por que fizemos isso e quais problemas tivemos no processo.

Implantando aplicativos na VM

Comecemos pelo fato de que há 3 anos todos os sistemas e serviços da empresa foram implantados em servidores virtuais regulares. Tecnicamente, foi organizado de forma que todo o código dos nossos sistemas fosse armazenado e montado utilizando ferramentas de montagem automática, utilizando jenkins. Usando o Ansible, ele foi implementado do nosso sistema de controle de versão para servidores virtuais. Além disso, cada sistema que nossa empresa possuía foi implantado em pelo menos 2 servidores: um deles na cabeça e o segundo na cauda. Esses dois sistemas eram absolutamente idênticos entre si em todas as suas configurações, potência, configuração, etc. A única diferença entre eles era que head recebia tráfego de usuários, enquanto tail nunca recebia tráfego de usuários.

Por que isso foi feito?

Quando implantamos novas versões do nosso aplicativo, queríamos garantir uma implementação perfeita, ou seja, sem consequências perceptíveis para os usuários. Isso foi conseguido devido ao fato de que a próxima versão compilada usando Ansible foi lançada até o fim. Lá, as pessoas envolvidas na implantação puderam verificar e ter certeza de que estava tudo bem: todas as métricas, seções e aplicações estavam funcionando; os scripts necessários são lançados. Só depois de se convencerem de que estava tudo bem é que o trânsito foi alterado. Começou a ir para o servidor que anteriormente era tail. E aquele que antes era o chefe permaneceu sem tráfego de usuários, embora ainda tenha a versão anterior do nosso aplicativo.

Portanto, foi perfeito para os usuários. Porque a comutação é instantânea, pois é simplesmente a comutação do balanceador. Você pode facilmente reverter para a versão anterior simplesmente trocando o balanceador de volta. Também pudemos verificar se o aplicativo era capaz de entrar em produção antes mesmo de receber tráfego de usuários, o que foi bastante conveniente.

Que vantagens vimos em tudo isso?

1. Em primeiro lugar, basta simplesmente funciona. Todos entendem como funciona esse esquema de implantação, porque a maioria das pessoas já implantou em servidores virtuais regulares.
2. Isto é suficiente confiável, já que a tecnologia de implantação é simples, testada por milhares de empresas. Milhões de servidores são implantados dessa forma. É difícil quebrar alguma coisa.
3. E finalmente poderíamos conseguir implantações atômicas. Implantações que ocorrem simultaneamente para os usuários, sem um estágio perceptível de alternância entre a versão antiga e a nova.

Mas também vimos várias deficiências em tudo isto:

1. Além do ambiente de produção, do ambiente de desenvolvimento, existem outros ambientes. Por exemplo, controle de qualidade e pré-produção. Naquela época tínhamos muitos servidores e cerca de 60 serviços. Por esta razão foi necessário para cada serviço, mantenha a versão mais recente dele máquina virtual. Além disso, se quiser atualizar bibliotecas ou instalar novas dependências, você precisa fazer isso em todos os ambientes. Você também precisava sincronizar o horário em que implantaria a próxima nova versão do seu aplicativo com o horário em que o devops realizaria as configurações de ambiente necessárias. Neste caso, é fácil entrar numa situação em que o nosso ambiente será um pouco diferente em todos os ambientes ao mesmo tempo. Por exemplo, num ambiente de QA haverá algumas versões de bibliotecas, e num ambiente de produção haverá diferentes, o que levará a problemas.
2. Dificuldade em atualizar dependências sua aplicação. Não depende de você, mas da outra equipe. Ou seja, da equipe devops que mantém os servidores. Você deve dar a eles uma tarefa apropriada e uma descrição do que deseja fazer.
3. Naquela época, também queríamos dividir os grandes monólitos que tínhamos em pequenos serviços separados, pois entendíamos que haveria cada vez mais deles. Naquela época já tínhamos mais de 100. Para cada novo serviço era necessário criar uma nova máquina virtual separada, que também precisava ser mantida e implantada. Além disso, você não precisa de um carro, mas de pelo menos dois. Somado a tudo isso está o ambiente de controle de qualidade. Isso causa problemas e torna mais difícil construir e executar novos sistemas. processo complexo, caro e demorado.

Portanto, decidimos que seria mais conveniente passar da implantação de máquinas virtuais regulares para a implantação de nossos aplicativos em um contêiner docker. Se você possui o docker, precisa de um sistema que possa executar o aplicativo em um cluster, já que não é possível simplesmente criar um contêiner. Normalmente você deseja acompanhar quantos contêineres são levantados para que sejam levantados automaticamente. Por esta razão, precisávamos selecionar um sistema de controle.

Pensamos muito sobre qual poderíamos escolher. O fato é que naquela época essa pilha de implantação em servidores virtuais comuns estava um tanto desatualizada, pois não possuíam as versões mais recentes dos sistemas operacionais. Em algum momento, existia até o FreeBSD, que não era muito conveniente de suportar. Entendemos que precisávamos migrar para o docker o mais rápido possível. Nossos devops analisaram sua experiência existente com diferentes soluções e escolheram um sistema como o Nomad.

Mudar para Nômade

Nomad é um produto da HashiCorp. Eles também são conhecidos por suas outras soluções:

"Cônsul" é uma ferramenta para descoberta de serviços.

"Terraforma" - um sistema de gerenciamento de servidores que permite configurá-los por meio de configuração, a chamada infraestrutura como código.

"Vagabundo" permite implantar máquinas virtuais localmente ou na nuvem por meio de arquivos de configuração específicos.

Naquela época, o Nomad parecia uma solução bastante simples, que poderia ser rapidamente alterada sem alterar toda a infraestrutura. Além disso, é bastante fácil de aprender. É por isso que o escolhemos como sistema de filtragem para nosso contêiner.

O que você precisa para implantar seu sistema no Nomad?

1. Primeiro de tudo você precisa imagem docker sua aplicação. Você precisa construí-lo e colocá-lo no repositório de imagens do Docker. No nosso caso, este é um artefato - um sistema que permite inserir nele vários artefatos de diferentes tipos. Ele pode armazenar arquivos, imagens docker, pacotes PHP do compositor, pacotes NPM e assim por diante.
2. Também necessário arquivo de configuração, que dirá ao Nomad o que, onde e em que quantidade você deseja implantar.

Quando falamos em Nomad, ele utiliza a linguagem HCL como formato de arquivo de informações, que significa Linguagem de configuração HashiCorp. Este é um superconjunto do Yaml que permite descrever seu serviço em termos Nomad.

Ele permite que você diga quantos contêineres deseja implantar, de quais imagens passar vários parâmetros para eles durante a implantação. Assim, você alimenta esse arquivo no Nomad e ele lança contêineres em produção de acordo com ele.

No nosso caso, percebemos que simplesmente escrever arquivos HCL absolutamente idênticos para cada serviço não seria muito conveniente, porque existem muitos serviços e às vezes você deseja atualizá-los. Acontece que um serviço é implantado não em uma instância, mas em várias instâncias diferentes. Por exemplo, um dos sistemas que temos em produção possui mais de 100 instâncias em produção. Eles são executados a partir das mesmas imagens, mas diferem nas definições e nos arquivos de configuração.

Portanto, decidimos que seria conveniente armazenar todos os nossos arquivos de configuração para implantação em um repositório comum. Desta forma eles eram visíveis: eram fáceis de manter e podíamos ver quais sistemas tínhamos. Se necessário, também é fácil atualizar ou alterar alguma coisa. Adicionar um novo sistema também não é difícil - você só precisa criar um arquivo de configuração dentro do novo diretório. Dentro dele estão os seguintes arquivos: service.hcl, que contém uma descrição do nosso serviço, e alguns arquivos env que permitem que este mesmo serviço, sendo implantado em produção, seja configurado.

No entanto, alguns de nossos sistemas são implantados em produção não em uma cópia, mas em várias ao mesmo tempo. Portanto, decidimos que seria conveniente armazenarmos não as configurações em sua forma pura, mas em sua forma padronizada. E nós escolhemos Jinja 2. Neste formato, armazenamos as configurações do próprio serviço e os arquivos env necessários para ele.

Além disso, colocamos no repositório um script de implantação comum a todos os projetos, que permite lançar e implantar seu serviço em produção, no ambiente desejado, no destino desejado. No caso em que transformamos nossa configuração HCL em um modelo, o arquivo HCL, que antes era uma configuração normal do Nomad, neste caso começou a parecer um pouco diferente.

Ou seja, substituímos algumas variáveis ​​de localização de configuração por inserções de variáveis ​​obtidas de arquivos env ou outras fontes. Além disso, tivemos a oportunidade de coletar arquivos HCL de forma dinâmica, ou seja, podemos usar não apenas inserções comuns de variáveis. Como o jinja suporta loops e condições, você também pode criar arquivos de configuração lá, que mudam dependendo de onde exatamente você implanta seus aplicativos.

Por exemplo, você deseja implantar seu serviço em pré-produção e produção. Digamos que na pré-produção você não queira executar scripts cron, mas apenas ver o serviço em um domínio separado para ter certeza de que está funcionando. Para quem implanta o serviço, o processo parece muito simples e transparente. Tudo o que você precisa fazer é executar o arquivo deploy.sh, especificar qual serviço deseja implantar e para qual destino. Por exemplo, você deseja implantar um determinado sistema na Rússia, Bielorrússia ou Cazaquistão. Para fazer isso, basta alterar um dos parâmetros e você terá o arquivo de configuração correto.

Quando o serviço Nomad já está implantado em seu cluster, ele fica assim.

Primeiro, você precisa de algum tipo de balanceador externo, que receberá todo o tráfego do usuário. Ele trabalhará em conjunto com o Consul e descobrirá onde, em qual nó, em qual endereço IP está localizado um serviço específico que corresponde a um determinado nome de domínio. Os serviços no Consul vêm do próprio Nomad. Por se tratarem de produtos da mesma empresa, eles estão bastante relacionados entre si. Podemos dizer que o Nomad pronto para uso pode cadastrar todos os serviços nele lançados dentro do Consul.

Depois que seu balanceador de carga front-end souber para qual serviço enviar o tráfego, ele o encaminhará para o contêiner apropriado ou para vários contêineres que correspondam ao seu aplicativo. Naturalmente, também é preciso pensar na segurança. Embora todos os serviços sejam executados nas mesmas máquinas virtuais em contêineres, isso geralmente exige a prevenção do acesso gratuito de qualquer serviço a qualquer outro. Conseguimos isso por meio da segmentação. Cada serviço foi lançado em uma rede virtual própria, na qual foram prescritas regras de roteamento e regras para permitir/negar acesso a outros sistemas e serviços. Eles poderiam estar localizados dentro e fora deste cluster. Por exemplo, se você quiser evitar que um serviço se conecte a um banco de dados específico, isso pode ser feito por meio da segmentação no nível da rede. Ou seja, mesmo por engano, você não pode se conectar acidentalmente do ambiente de teste ao seu banco de dados de produção.

Quanto nos custou a transição em termos de recursos humanos?

A transição de toda a empresa para o Nomad levou aproximadamente 5 a 6 meses. Mudamos serviço por serviço, mas em um ritmo bastante rápido. Cada equipe teve que criar seus próprios contêineres para os serviços.

Adotamos uma abordagem tal que cada equipe é responsável pelas imagens docker de seus sistemas de forma independente. Devops fornece a infraestrutura geral necessária para implantação, ou seja, suporte para o próprio cluster, suporte para o sistema de CI e assim por diante. E naquela época tínhamos mais de 60 sistemas transferidos para o Nomad, o que somava cerca de 2 mil contêineres.

Devops é responsável pela infraestrutura geral de tudo relacionado à implantação e servidores. E cada equipe de desenvolvimento, por sua vez, é responsável por implementar containers para seu sistema específico, pois é a equipe que sabe o que geralmente precisa em determinado container.

Razões para abandonar o Nomad

Que vantagens obtivemos ao mudar para a implantação usando Nomad e docker, entre outros?

1. Nós forneceu condições iguais para todos os ambientes. No desenvolvimento, ambiente de QA, pré-produção, produção, são utilizadas as mesmas imagens de contêiner, com as mesmas dependências. Conseqüentemente, você praticamente não tem chance de que o que acabará na produção não seja o que você testou anteriormente localmente ou em seu ambiente de teste.
2. Também descobrimos que é suficiente fácil adicionar um novo serviço. Do ponto de vista da implantação, qualquer novo sistema é lançado de forma muito simples. Basta ir ao repositório que armazena as configurações, adicionar outra configuração para o seu sistema e está tudo pronto. Você pode implantar seu sistema em produção sem nenhum esforço adicional de devops.
3. Todos arquivos de configuração em um repositório comum acabou por estar sob revisão. No momento em que implantamos nossos sistemas utilizando servidores virtuais, utilizamos Ansible, em que as configurações estavam no mesmo repositório. No entanto, para a maioria dos desenvolvedores, isso foi um pouco mais difícil de trabalhar. Aqui o volume de configurações e códigos que você precisa adicionar para implantar o serviço tornou-se muito menor. Além disso, é muito fácil para os devops consertarem ou alterarem isso. No caso de transições, por exemplo, para uma nova versão do Nomad, eles podem pegar e atualizar em massa todos os arquivos operacionais localizados no mesmo local.

Mas também encontramos várias desvantagens:

Acontece que nós não foi possível obter implantações perfeitas no caso de Nômade. Ao implantar contêineres sob diferentes condições, ele poderia estar em execução, e o Nomad o percebeu como um contêiner pronto para receber tráfego. Isso aconteceu antes mesmo que o aplicativo dentro dele tivesse a chance de ser iniciado. Por isso, o sistema passou a produzir 500 erros em um curto período de tempo, pois o tráfego começou a ir para um contêiner que ainda não estava pronto para aceitá-lo.

Encontramos alguns pelos pântanos. O bug mais significativo é que o Nomad não lida muito bem com um cluster grande se você tiver muitos sistemas e contêineres. Quando você deseja retirar um dos servidores incluídos no cluster Nomad para manutenção, há uma probabilidade bastante alta de que o cluster não se sinta muito bem e desmorone. Alguns contêineres podem, por exemplo, cair e não subir - isso custará muito mais tarde se todos os seus sistemas de produção estiverem localizados em um cluster gerenciado pelo Nomad.

Então decidimos pensar sobre onde deveríamos ir a seguir. Nesse ponto, ficamos muito mais conscientes do que queríamos alcançar. Ou seja: queremos confiabilidade, um pouco mais de funções do que o Nomad oferece e um sistema mais maduro e estável.

Nesse sentido, nossa escolha recaiu sobre o Kubernetes como a plataforma mais popular para o lançamento de clusters. Especialmente tendo em conta que o tamanho e o número dos nossos contentores eram suficientemente grandes. Para tais fins, o Kubernetes parecia ser o sistema mais adequado que poderíamos considerar.

Transição para Kubernetes

Vou contar um pouco sobre os conceitos básicos do Kubernetes e como eles diferem do Nomad.

Em primeiro lugar, o conceito mais básico do Kubernetes é o conceito de pod. Vagem é um grupo de um ou mais contêineres que sempre funcionam juntos. E eles sempre funcionam como se estivessem estritamente em uma máquina virtual. Eles são acessíveis entre si via IP 127.0.0.1 em portas diferentes.

Vamos supor que você tenha um aplicativo PHP que consiste em nginx e php-fpm - o esquema clássico. Provavelmente, você desejará manter os contêineres nginx e php-fpm juntos o tempo todo. O Kubernetes permite que você consiga isso descrevendo-os como um pod comum. Isso é exatamente o que não conseguimos com o Nomad.

O segundo conceito é desenvolvimento. O fato é que o casulo em si é algo efêmero; ele começa e desaparece. Você deseja eliminar todos os seus contêineres anteriores primeiro e depois lançar novas versões de uma vez ou deseja lançá-los gradualmente? Este é o processo pelo qual o conceito de implantação é responsável. Descreve como você implanta seus pods, em que quantidade e como atualizá-los.

O terceiro conceito é serviço. Seu serviço é na verdade seu sistema, que recebe algum tráfego e o encaminha para um ou mais pods correspondentes ao seu serviço. Ou seja, permite dizer que todo o tráfego de entrada para tal e tal serviço com tal e tal nome deve ser enviado para esses pods específicos. E, ao mesmo tempo, fornece equilíbrio de tráfego. Ou seja, você pode iniciar dois pods do seu aplicativo e todo o tráfego de entrada será balanceado uniformemente entre os pods relacionados a este serviço.

E o quarto conceito básico é Ingresso. Este é um serviço executado em um cluster Kubernetes. Ele atua como um balanceador de carga externo que assume todas as solicitações. Usando a API Kubernetes, o Ingress pode determinar para onde essas solicitações devem ser enviadas. Além disso, ele faz isso com muita flexibilidade. Você pode dizer que todas as solicitações para este host e tal URL são enviadas para este serviço. E essas solicitações que chegam a esse host e a outra URL são enviadas para outro serviço.

O mais legal do ponto de vista de quem desenvolve uma aplicação é que você mesmo consegue gerenciar tudo. Ao definir a configuração do Ingress, você pode enviar todo o tráfego proveniente de tal e tal API para contêineres separados escritos, por exemplo, em Go. Mas esse tráfego, vindo para o mesmo domínio, mas para uma URL diferente, deveria ser enviado para containers escritos em PHP, onde há muita lógica, mas não são muito rápidos.

Se compararmos todos esses conceitos com o Nomad, podemos dizer que os três primeiros conceitos são todos juntos Serviço. E o último conceito está ausente no próprio Nomad. Usamos um balanceador externo: pode ser haproxy, nginx, nginx+ e assim por diante. No caso de um cubo, não é necessário introduzir este conceito adicional separadamente. No entanto, se você olhar para o Ingress internamente, ele é nginx, haproxy ou traefik, mas meio que integrado ao Kubernetes.

Todos os conceitos que descrevi são, na verdade, recursos que existem dentro de um cluster Kubernetes. Para descrevê-los no cubo, é usado um formato yaml, que é mais legível e familiar do que os arquivos HCL no caso do Nomad. Mas estruturalmente eles descrevem a mesma coisa no caso, por exemplo, de pod. Eles dizem - eu quero implantar tais e tais pods lá, com tais e tais imagens, em tais e tais quantidades.

Além disso, percebemos que não queríamos criar cada recurso individual manualmente: implantação, serviços, Ingress, etc. Em vez disso, queríamos descrever cada um dos nossos sistemas em termos de Kubernetes durante a implantação, para que não tivéssemos que recriar manualmente todas as dependências de recursos necessárias na ordem correta. Helm foi escolhido como o sistema que nos permitiu fazer isso.

Conceitos básicos no Helm

Elmo é gerenciador de pacotes para Kubernetes. É muito semelhante ao funcionamento dos gerenciadores de pacotes em linguagens de programação. Eles permitem que você armazene um serviço que consiste em, por exemplo, implantação nginx, implantação php-fpm, configuração para Ingress, configmaps (esta é uma entidade que permite definir env e outros parâmetros para o seu sistema) na forma de assim- chamados gráficos. Ao mesmo tempo, Helm roda em cima do Kubernetes. Ou seja, não se trata de algum tipo de sistema à parte, mas apenas de mais um serviço lançado dentro do cubo. Você interage com ele por meio de sua API por meio de um comando de console. Sua comodidade e beleza é que mesmo que o leme quebre ou você o retire do cluster, seus serviços não irão desaparecer, já que o leme serve essencialmente apenas para iniciar o sistema. O próprio Kubernetes é então responsável pelo desempenho e pelo estado dos serviços.

Também percebemos que templateização, que anteriormente fomos forçados a fazer introduzindo o jinja em nossas configurações, é uma das principais características do helm. Todas as configurações que você cria para seus sistemas são armazenadas no helm na forma de templates, um pouco parecidos com o jinja, mas, na verdade, usando os templates da linguagem Go, na qual o helm é escrito, como o Kubernetes.

Helm adiciona mais alguns conceitos para nós.

de cores - esta é uma descrição do seu serviço. Em outros gerenciadores de pacotes, seria chamado de pacote, pacote ou algo semelhante. Aqui é chamado de gráfico.

Valores são as variáveis ​​que você deseja usar para criar suas configurações a partir de modelos.

Solte. Cada vez que um serviço implementado usando o helm recebe uma versão incremental da versão. Helm lembra qual era a configuração do serviço na versão anterior, na versão anterior e assim por diante. Portanto, se você precisar reverter, basta executar o comando helm callback, apontando-o para a versão anterior. Mesmo que a configuração correspondente em seu repositório não esteja disponível no momento da reversão, o helm ainda se lembrará do que era e reverterá seu sistema para o estado em que estava na versão anterior.

No caso de usarmos helm, as configurações regulares do Kubernetes também se transformam em templates nos quais é possível usar variáveis, funções e aplicar instruções condicionais. Dessa forma, você pode coletar a configuração do seu serviço dependendo do ambiente.

Na prática, decidimos fazer as coisas de forma um pouco diferente do que fizemos com o Nomad. Se no Nomad tanto as configurações de implantação quanto as n variáveis ​​necessárias para implantar nosso serviço foram armazenadas em um repositório, aqui decidimos dividi-las em dois repositórios separados. O repositório “deploy” armazena apenas n variáveis ​​necessárias para implantação, e o repositório “helm” armazena configurações ou gráficos.

O que isso nos deu?

Apesar de não armazenarmos nenhum dado realmente sensível nos próprios arquivos de configuração. Por exemplo, senhas para bancos de dados. Eles são armazenados como segredos no Kubernetes, mas, mesmo assim, ainda existem certas coisas às quais não queremos dar acesso a todos. Portanto, o acesso ao repositório “deploy” é mais limitado, e o repositório “helm” contém simplesmente uma descrição do serviço. Por esse motivo, pode ser acessado com segurança por um maior número de pessoas.

Como não temos apenas produção, mas também outros ambientes, graças a esta separação podemos reutilizar nossos helm charts para implantar serviços não apenas na produção, mas também, por exemplo, em um ambiente de QA. Até mesmo para implantá-los localmente usando Minikubo - isso é algo para executar o Kubernetes localmente.

Dentro de cada repositório deixamos uma divisão em diretórios separados para cada serviço. Ou seja, dentro de cada diretório existem templates relacionados ao gráfico correspondente e que descrevem os recursos que precisam ser implantados para rodar nosso sistema. Deixamos apenas ambientes no repositório “deploy”. Nesse caso, não usamos templates usando jinja, porque o próprio helm fornece templates prontos para uso - esta é uma de suas principais funções.

Deixamos um script de implantação - deploy.sh, que simplifica e padroniza o lançamento para implantação usando o helm. Portanto, para quem deseja implantar, a interface de implantação é exatamente a mesma da implantação por meio do Nomad. O mesmo deploy.sh, o nome do seu serviço e onde você deseja implantá-lo. Isso faz com que o leme seja inicializado internamente. Ele, por sua vez, coleta configurações de modelos, insere neles os arquivos de valores necessários e, em seguida, implanta-os, lançando-os no Kubernetes.

Descobertas

O serviço Kubernetes parece ser mais complexo que o Nomad.

Aqui o tráfego de saída chega ao Ingress. Este é apenas o front controller, que assume todas as solicitações e posteriormente as envia aos serviços correspondentes aos dados da solicitação. Ele os determina com base nas configurações que fazem parte da descrição do seu aplicativo no helm e que os desenvolvedores definem por conta própria. O serviço envia solicitações para seus pods, ou seja, containers específicos, balanceando o tráfego de entrada entre todos os containers que pertencem a este serviço. E, claro, não devemos esquecer que não devemos fugir da segurança no nível da rede. Portanto, a segmentação funciona em um cluster Kubernetes, que é baseado em marcação. Todos os serviços possuem determinadas tags às quais estão associados os direitos de acesso dos serviços a determinados recursos externos/internos dentro ou fora do cluster.

Ao fazermos a transição, vimos que o Kubernetes tinha todos os recursos do Nomad, que havíamos usado anteriormente, e também adicionou muitas coisas novas. Ele pode ser expandido por meio de plug-ins e, na verdade, por meio de tipos de recursos personalizados. Ou seja, você tem a oportunidade não apenas de usar algo que vem com o Kubernetes pronto para uso, mas de criar seu próprio recurso e serviço que irá ler seu recurso. Isso oferece opções adicionais para expandir seu sistema sem precisar reinstalar o Kubernetes e sem exigir modificações.

Um exemplo desse uso é o Prometheus, que roda dentro de nosso cluster Kubernetes. Para que ele comece a coletar métricas de um determinado serviço, precisamos adicionar um tipo adicional de recurso, o chamado monitor de serviço, à descrição do serviço. O Prometheus, por poder ler um tipo de recurso customizado quando iniciado no Kubernetes, começa automaticamente a coletar métricas do novo sistema. É bastante conveniente.

A primeira implantação que fizemos no Kubernetes foi em março de 2018. E durante esse tempo nunca tivemos problemas com isso. Funciona de forma bastante estável, sem bugs significativos. Além disso, podemos expandi-lo ainda mais. Hoje temos recursos suficientes e gostamos muito do ritmo de desenvolvimento do Kubernetes. Atualmente, mais de 3000 contêineres estão no Kubernetes. O cluster ocupa vários nós. Ao mesmo tempo, é útil, estável e muito controlável.

Fonte: habr.com