Kubernetes é uma excelente ferramenta para executar contêineres Docker em um ambiente de produção clusterizado. No entanto, existem tarefas que o Kubernetes não consegue resolver. Com implantações frequentes em um ambiente de produção, precisamos de um Blue/Green deployment totalmente automatizado para evitar interrupções nesse processo, que também requer o manuseio de solicitações HTTP externas e a execução de descargas SSL. Isso exige integração com um balanceador de carga, como o ha-proxy. Outra tarefa é o escalonamento semi-automático do próprio cluster Kubernetes ao operar em um ambiente de nuvem, como, por exemplo, a redução parcial do cluster durante a noite.
Embora o Kubernetes não possua essas funcionalidades 'prontas para uso', ele fornece uma API que pode ser utilizada para resolver essas tarefas. Ferramentas para implantação automática de Blue/Green e escalonamento do cluster Kubernetes foram desenvolvidas no âmbito do projeto Cloud RTI, que foi baseado em código aberto.
Neste artigo, uma transcrição de vídeo, é explicado como configurar o Kubernetes junto com outros componentes de código aberto para criar um ambiente pronto para produção, que lida com o código do commit git commit sem interrupções em produção.
Assim, após ter acesso aos seus aplicativos a partir do mundo externo, você pode começar a configurar a automação completa, ou seja, levá-la ao estágio em que pode executar um git commit e garantir que esse git commit finalize em produção. Naturalmente, ao realizar esses passos durante a implantação, não queremos enfrentar interrupções. Portanto, toda automação no Kubernetes começa com a API.
Kubernetes não é a ferramenta que pode ser utilizada de maneira produtiva 'pronta para uso'. Claro, você pode fazer isso, usar kubectl e assim por diante, mas ainda assim a API é o aspecto mais interessante e útil desta plataforma. Usando a API como um conjunto de funções, você pode acessar praticamente tudo o que deseja fazer no Kubernetes. O kubectl em si também utiliza a REST API.
Este é um REST, então você pode usar qualquer linguagem e ferramentas para trabalhar com esta API, mas bibliotecas personalizadas facilitarão muito sua vida. Minha equipe escreveu 2 dessas bibliotecas: uma para Java / OSGi e uma para Go. A segunda não é muito utilizada, mas, de qualquer forma, você tem essas ferramentas úteis à sua disposição. Elas constituem um projeto open-source parcialmente licenciado. Existem muitas dessas bibliotecas para várias linguagens, então você pode escolher as mais adequadas.
Assim, antes de começar a automatizar a implantação, é necessário garantir que esse processo não enfrentará períodos de inatividade. Por exemplo, nossa equipe realiza implantações em produção durante o meio do dia, quando as pessoas utilizam os aplicativos ao máximo, portanto, é muito importante evitar atrasos nesse processo. Para evitar períodos de inatividade, utilizamos 2 métodos: implantação blue/green ou atualização contínua. No último caso, se você tiver 5 réplicas do aplicativo em operação, elas são atualizadas sequencialmente, uma após a outra. Este método funciona muito bem, mas não é adequado se você tiver versões diferentes do aplicativo em execução simultaneamente durante o processo de implantação. Nesse caso, você pode atualizar a interface do usuário enquanto o backend ainda estiver rodando uma versão anterior, e a funcionalidade do aplicativo será interrompida. Portanto, do ponto de vista da programação, trabalhar nessas condições é bastante complicado.
Essa é uma das razões pelas quais preferimos usar a implantação blue/green para automatizar a implantação de nossos aplicativos. Com esse método, você deve garantir que em um determinado momento somente uma versão do aplicativo esteja ativa.
O mecanismo de implantação blue/green funciona da seguinte forma. Recebemos o tráfego para nossos aplicativos através do ha-proxy, que o direciona para as réplicas em execução da mesma versão do aplicativo.
Quando uma nova implantação ocorre, usamos o Deployer, que recebe os novos componentes e realiza o deploy da nova versão. O deploy da nova versão do aplicativo significa que um novo conjunto de réplicas é 'levantado', após o que essas réplicas da nova versão são iniciadas em um novo pod separado. No entanto, o ha-proxy não tem conhecimento delas e ainda não direciona nenhuma carga de trabalho para elas.
Portanto, é necessário primeiro realizar uma verificação de operação das novas versões por meio de health checking, para garantir que as réplicas estejam prontas para lidar com a carga.
Todos os componentes de implantação devem suportar alguma forma de health check. Isso pode ser apenas uma verificação simples de HTTP, onde você recebe um código de status 200, ou uma verificação mais profunda, na qual você verifica a conexão das réplicas com o banco de dados e outros serviços, a resiliência das conexões do ambiente dinâmico, se tudo está sendo iniciado e funcionando corretamente. Esse processo pode ser bastante complexo.
Depois que o sistema confirmar a operação de todas as réplicas atualizadas, o Deployer atualizará a configuração e transmitirá o confd correto, que reconfigurará o ha-proxy.
Somente depois disso o tráfego será direcionado para o pod com as réplicas da nova versão, enquanto o pod antigo desaparecerá.
Esse mecanismo não é uma característica do Kubernetes. O conceito de Blue/green deployment existe há bastante tempo e sempre utilizou um balanceador de carga. Primeiro, você direciona todo o tráfego para a versão antiga do aplicativo e, após a atualização, migra totalmente para a nova versão. Esse princípio é usado não apenas no Kubernetes.
Agora, vou apresentar a vocês um novo componente de implantação – o Deployer, que realiza verificações de operação, reconfigura o proxy e assim por diante. Este é um conceito que não diz respeito ao mundo externo e existe dentro do Kubernetes. Vou mostrar como criar seu próprio conceito de Deployer usando ferramentas open-source.
Então, a primeira coisa que o Deployer faz é criar um controlador de replicação RC usando a API do Kubernetes. Essa API cria pods e serviços para o próximo desdobramento, ou seja, cria um cluster totalmente novo para nossos aplicativos. Assim que o RC confirma que as réplicas foram iniciadas, ele realiza um teste de saúde (Health check). Para isso, o Deployer utiliza o comando GET /health. Este comando ativa os componentes de verificação correspondentes e verifica todos os elementos necessários para o funcionamento do cluster.
Depois que todos os pods reportam sua 'saúde', o Deployer cria um novo item de configuração – um armazenamento distribuído etcd, usado internamente pelo Kubernetes, incluindo para o armazenamento da configuração do balanceador de carga. Gravamos os dados no etcd, e uma pequena ferramenta chamada confd monitora o etcd para detectar novos dados.
Se detectar alguma alteração na configuração original, ele gera um novo arquivo de configurações e o envia para o ha-proxy. Nesse caso, o ha-proxy reinicia sem perder qualquer conexão e direciona a carga para os novos services que garantem o funcionamento da nova versão dos nossos aplicativos.
Como você pode ver, apesar da variedade de componentes, não há nada complicado aqui. Você só precisa prestar mais atenção à API e ao etcd. Quero falar sobre um deploier open-source que usamos – o Amdatu Kubernetes Deployer.
Esse é um instrumento para orquestração de desdobramentos do Kubernetes, com as seguintes funcionalidades:
- desdobramento Blue/Green;
- configuração de balanceador de carga externo;
- gerenciamento de descritores de desdobramento;
- gerenciamento do desdobramento real;
- verificação de saúde (Health checks) durante o desdobramento;
- injeção de variáveis de ambiente nos pods.
Este Deployer é construído sobre a API do Kubernetes e fornece uma API REST para gerenciar descritores e desdobramentos, além de uma API Websocket para logs em tempo real durante o processo de desdobramento.
Ele coloca os dados de configuração do balanceador de carga no etcd, portanto, você pode não usar o ha-proxy com suporte 'pronto para uso', mas facilmente utilizar seu próprio arquivo de configuração do balanceador. O Amdatu Deployer é escrito em Go, assim como o próprio Kubernetes, e licenciado sob a Apache.
Antes de utilizar esta versão do depurador, utilizei o seguinte descritor de implantação, no qual estão especificados os parâmetros que preciso.
Um dos parâmetros importantes deste código é a habilitação da flag "useHealthCheck". Precisamos especificar que, durante o processo de implantação, a verificação de saúde deve ser realizada. Este parâmetro pode ser desativado quando a implantação envolve contêineres de terceiros que não precisam ser verificados. Este descritor também especifica o número de réplicas e a URL do frontend que o ha-proxy necessita. No final, está a flag da especificação do pod "podspec", que se comunica com o Kubernetes para obter informações sobre a configuração de portas, imagens, etc. Este é um descritor simples no formato JSON.
Outra ferramenta que faz parte do projeto open-source Amdatu é o Deploymentctl. Ele possui uma interface de usuário (UI) para configurar a implantação, mantém um histórico das implantações e contém webhooks para chamadas de retorno de usuários e desenvolvedores externos. Você pode optar por não usar a UI, uma vez que o próprio Amdatu Deployer é uma REST API, mas essa interface pode facilitar muito a sua implantação sem o uso de qualquer API. O Deploymentctl é escrito em OSGi/Vertx utilizando Angular 2.
Agora vou demonstrar o que foi dito na tela, usando uma gravação pré-feita, para que você não precise esperar. Vamos implantar um aplicativo simples em Go. Não se preocupe se você nunca tiver trabalhado com Go antes, este é um aplicativo muito simples, então tudo deve ser claro para você.
Aqui estamos criando um servidor HTTP que responde apenas a /health, então este aplicativo apenas verifica a saúde e nada mais. Se a verificação for bem-sucedida, é acionada a estrutura JSON mostrada abaixo. Ela contém a versão do aplicativo que será implantada pelo depurador, a mensagem que você vê na parte superior do arquivo e um tipo de dado booleano - se o nosso aplicativo está funcionando ou não.
Quanto à última linha, eu fui um pouco astuto, pois coloquei um valor booleano fixo no início do arquivo, que me ajudará a implantar até mesmo um aplicativo "não saudável". Vamos tratar disso mais tarde.
Vamos começar. Primeiro, verificamos a existência de qualquer pod em execução com o comando ~ kubectl get pods e, na ausência de resposta da URL do frontend, confirmamos que nenhuma implantação está sendo realizada no momento.
Em seguida, na tela, você vê a interface Deploymentctl que mencionei, onde são definidos os parâmetros de implantação: namespace, nome do aplicativo, versão da implantação, número de réplicas, URL do frontend, nome do contêiner, imagem, limites de recursos, número da porta para verificação de saúde e assim por diante. Os limites de recursos são muito importantes, pois permitem utilizar a quantidade máxima possível de 'hardware'. Aqui também é possível visualizar o log da implantação, o Deployment log.
Se agora repetirmos o comando ~ kubectl get pods, veremos que o sistema 'congela' por 20 segundos, durante os quais ocorre a reconfiguração do ha-proxy. Após isso, o pod é iniciado e nossa réplica pode ser vista no log da implantação.
Eu cortei do vídeo a espera de 20 segundos, e agora você vê na tela que a primeira versão do aplicativo foi implantada. Tudo isso foi realizado apenas com a ajuda da interface gráfica.
Agora vamos tentar a segunda versão. Para isso, eu altero a mensagem do aplicativo de 'Hello, Kubernetes!' para 'Hello, Deployer!', o sistema cria esta imagem e a coloca no registro Docker, e então simplesmente clicamos novamente no botão 'Deploy' na janela do Deploymentctl. Isso automaticamente inicia o log de implantação da mesma forma que ocorreu na implantação da primeira versão do aplicativo.
O comando ~ kubectl get pods mostra que atualmente estão em execução 2 versões do aplicativo, no entanto, o frontend indica que ainda estamos usando a versão 1.
O balanceador de carga aguarda até que a verificação de saúde seja concluída, após o que redirecionará o tráfego para a nova versão. Depois de 20 segundos, mudamos para o curl e vemos que agora temos a 2ª versão do aplicativo implantada, enquanto a primeira foi removida.
Essa foi a implantação de um aplicativo 'saudável' — healthy. Vamos ver o que acontece se eu alterar o valor do parâmetro Healthy da nova versão do aplicativo de true para false, ou seja, se eu tentar implantar um aplicativo unhealthy que não passou na verificação de funcionalidade. Isso pode ocorrer se, durante a fase de desenvolvimento, ocorreram erros de configuração no aplicativo e ele foi enviado para produção dessa forma.
Como você pode ver, o deployment passa por todas as etapas mencionadas acima, e ~ kubectl get pods mostra que ambos os pods estão em execução. Porém, ao contrário do deployment anterior, o log mostra o estado de timeout. Ou seja, devido à falha na verificação de health check, a nova versão do aplicativo não pode ser implantada. Como resultado, você vê que o sistema voltou a utilizar a versão antiga do aplicativo, enquanto a nova versão foi simplesmente removida.
A boa notícia é que, mesmo que você tenha um grande número de solicitações simultâneas chegando ao aplicativo, os usuários nem perceberão a interrupção durante a execução do procedimento de deployment. Se você testar esse aplicativo com o framework Gatling, que lhe envia o maior número possível de solicitações, nenhuma dessas solicitações será descartada. Isso significa que nossos usuários nem notarão a atualização de versões em tempo real. Se a atualização falhar, a operação continuará na versão antiga; se for bem-sucedida, os usuários migrarão para a nova versão.
Há apenas uma coisa que pode levar a uma falha – se a verificação de health check passar com sucesso, mas o aplicativo falhar assim que receber a carga de trabalho, ou seja, o colapso ocorrerá apenas após a conclusão do deployment. Nesse caso, você terá que reverter manualmente para a versão antiga. Assim, discutimos como utilizar o Kubernetes com as ferramentas open-source criadas para ele. O procedimento de deployment será muito mais fácil se você integrar essas ferramentas aos pipelines de construção/deployment. Com isso, você pode usar tanto a interface do usuário quanto automatizar completamente esse processo, aplicando, por exemplo, commit to master.
Nosso servidor de build criará uma imagem Docker, enviando-a para o Docker Hub ou qualquer outro registro que você estiver utilizando. O Docker Hub suporta webhook, portanto, podemos iniciar um deployment remoto através do Deployer, conforme mostrado acima. Dessa forma, é possível automatizar completamente a implantação do aplicativo em um ambiente de produção potencial.
Vamos passar para o próximo tópico – a escalabilidade do cluster Kubernetes. Observe que o comando kubectl é o comando de escalabilidade. Com ele, é fácil aumentar o número de réplicas no nosso cluster existente. No entanto, na prática, normalmente queremos aumentar o número de nós, não de pods.
Nesse sentido, durante o horário comercial, pode ser necessário aumentar a capacidade, enquanto à noite, para reduzir os custos dos serviços da Amazon, será necessário diminuir o número de instâncias do aplicativo em execução. Isso não significa que será suficiente escalar apenas o número de pods, pois mesmo que um dos nós esteja ocioso, você ainda terá que pagar por ele à Amazon. Ou seja, além de escalar os pods, você precisará escalonar também o número de máquinas utilizadas.
Isso pode causar complicações, porque independentemente de estarmos usando a Amazon ou outro serviço de nuvem, o Kubernetes não tem conhecimento sobre o número de máquinas utilizadas. Falta uma ferramenta que permita escalar o sistema ao nível dos nós.
Portanto, teremos que cuidar tanto dos nós quanto dos pods. Podemos facilmente escalar o lançamento de novos nós usando a API da AWS e grupos de máquinas de escalonamento para configurar o número de nós de trabalho do Kubernetes. Também é possível usar cloud-init ou um script semelhante para registrar os nós no cluster Kubernetes.
Uma nova máquina é iniciada no grupo de Scaling, se registra como um nó, é registrada no registro mestre e começa a operar. Depois disso, é possível aumentar o número de réplicas para uso nos nós criados. Reduzir o tamanho requer mais esforço, pois é necessário garantir que essa ação não levará à destruição de aplicativos já em funcionamento após a desativação de máquinas "desnecessárias". Para evitar tal cenário, os nós devem ser colocados no status "unschedulable". Isso significa que o planejador padrão ignorará esses nós ao agendar pods do DaemonSet. O planejador não removerá nada desses servidores, mas também não iniciará novos contêineres lá. A próxima etapa é drenar o nó, ou seja, mover os pods ativos para outra máquina ou outros nós que tenham capacidade suficiente para isso. Depois de garantir que não há mais contêineres nesses nós, eles podem ser removidos do Kubernetes. Após isso, para o Kubernetes, eles simplesmente deixarão de existir. Em seguida, é necessário usar a API da AWS para desativar nós ou máquinas desnecessárias.
Você pode usar o Amdatu Scalerd — outra ferramenta open-source para escalonamento, semelhante à API da AWS. Ele fornece uma CLI para adicionar ou remover nós no cluster. Uma característica interessante é a possibilidade de configurar o planejador usando o seguinte arquivo json.
O código mostrado reduz pela metade a capacidade do cluster durante a noite. Nele, está configurado tanto o número de réplicas existentes quanto a capacidade desejada do cluster da Amazon. O uso deste planejador reduzirá automaticamente o número de nós durante a noite e aumentará pela manhã, permitindo economizar nos custos de uso de nós de um serviço em nuvem como a Amazon. Esta função não está embutida no Kubernetes, mas o uso do Scalerd permitirá escalonar esta plataforma como você desejar.
Quero chamar sua atenção para o fato de que muitas pessoas me dizem: "Tudo isso é bom, mas e quanto ao meu banco de dados, que geralmente permanece em um estado estático?" Como pode ser executado algo assim em um ambiente dinâmico como o Kubernetes? Na minha opinião, você não deve fazer isso, não deve tentar organizar o trabalho de um armazenamento de dados no Kubernetes. Tecnicamente é possível, e existem guias na internet sobre isso, mas isso complicará seriamente sua vida.
Sim, no Kubernetes existe o conceito de volumes persistentes, e você pode tentar executar armazenamentos de dados como Mongo ou MySQL, mas é uma tarefa bastante trabalhosa. Isso se deve ao fato de que os armazenamentos de dados não suportam completamente a interação com o ambiente dinâmico. A maioria dos bancos de dados requer configurações significativas, incluindo a configuração manual do cluster, não gosta de autoescalonamento e outras coisas do tipo.
Portanto, não complique sua vida tentando executar um armazenamento de dados no Kubernetes. Organize seu funcionamento da maneira tradicional usando serviços familiares e apenas permita que o Kubernetes os utilize.
Para concluir o tema, quero apresentar a vocês a plataforma Cloud RTI baseada em Kubernetes, na qual minha equipe está trabalhando. Ela fornece gerenciamento centralizado de logs, monitoramento de aplicativos e clusters e possui muitas outras funções úteis que serão valiosas para você. Utiliza diversas ferramentas open-source, como Grafana para exibição de monitoramento.
Foi feita uma pergunta sobre por que usar o balanceador de carga ha-proxy com Kubernetes. É uma boa pergunta, pois atualmente existem 2 níveis de balanceamento de carga. Os serviços Kubernetes ainda estão em endereços IP virtuais. Você não pode usá-los para as portas de máquinas host externas, porque se a Amazon sobrecarregar seu host em nuvem, o endereço mudará. É por isso que colocamos o ha-proxy na frente dos serviços — para criar uma estrutura mais estática para a interação contínua do tráfego com o Kubernetes.
Outra boa pergunta - como cuidar da mudança no esquema do banco de dados durante o blue/green deployment? O fato é que, independentemente do uso do Kubernetes, mudar o esquema do banco de dados é uma tarefa complexa. É necessário garantir a compatibilidade entre o esquema antigo e o novo, depois você poderá atualizar o banco de dados e, em seguida, atualizar as próprias aplicações. Você pode realizar a "substituição quente" (hot swapping) do banco de dados e, em seguida, atualizar as aplicações. Eu conheço pessoas que carregaram um cluster de banco de dados completamente novo com um novo esquema, essa é uma opção se você tiver um banco de dados sem esquema como o Mongo, mas de qualquer forma, não é uma tarefa simples. Se não houver mais perguntas, obrigado pela atenção!
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
