Kubernetes é uma ótima ferramenta para executar contêineres Docker em um ambiente de produção em cluster. No entanto, existem problemas que o Kubernetes não consegue resolver. Para implantações de produção frequentes, precisamos de uma implantação Azul/Verde totalmente automatizada para evitar tempo de inatividade no processo, que também precisa lidar com solicitações HTTP externas e realizar descarregamentos de SSL. Isso requer integração com um balanceador de carga como o ha-proxy. Outro desafio é o dimensionamento semiautomático do próprio cluster Kubernetes quando executado em um ambiente de nuvem, por exemplo, reduzindo parcialmente o cluster à noite.
Embora o Kubernetes não tenha esses recursos prontos para uso, ele fornece uma API que você pode usar para resolver problemas semelhantes. Ferramentas para implantação automatizada Blue/Green e escalonamento de um cluster Kubernetes foram desenvolvidas como parte do projeto Cloud RTI, que foi criado com base em código aberto.
Este artigo, uma transcrição de vídeo, mostra como configurar o Kubernetes junto com outros componentes de código aberto para criar um ambiente pronto para produção que aceita código de um commit git sem tempo de inatividade na produção.
Assim, uma vez que você tenha acesso às suas aplicações do mundo externo, você pode começar a configurar totalmente a automação, ou seja, trazê-la para o estágio onde você pode realizar um git commit e garantir que esse git commit acabe em produção. Naturalmente, ao implementar essas etapas, ao implementar a implantação, não queremos enfrentar tempo de inatividade. Portanto, qualquer automação no Kubernetes começa com a API.
Kubernetes não é uma ferramenta que possa ser usada de forma produtiva imediatamente. Claro, você pode fazer isso, usar kubectl e assim por diante, mas ainda assim a API é a coisa mais interessante e útil nesta plataforma. Ao usar a API como um conjunto de funções, você pode acessar quase tudo que deseja fazer no Kubernetes. O próprio kubectl também usa a API REST.
Isso é REST, então você pode usar qualquer linguagem ou ferramenta para trabalhar com esta API, mas sua vida será muito mais fácil com bibliotecas customizadas. Minha equipe escreveu duas dessas bibliotecas: uma para Java/OSGi e outra para Go. O segundo não é usado com frequência, mas de qualquer forma você tem essas coisas úteis à sua disposição. Eles são um projeto de código aberto parcialmente licenciado. Existem muitas dessas bibliotecas para diferentes idiomas, então você pode escolher aquela que melhor se adapta a você.
Portanto, antes de começar a automatizar sua implantação, você precisa ter certeza de que o processo não estará sujeito a nenhum tempo de inatividade. Por exemplo, nossa equipe realiza implantações de produção durante o meio do dia, quando as pessoas estão utilizando mais os aplicativos, por isso é importante evitar atrasos nesse processo. Para evitar tempo de inatividade, dois métodos são usados: implantação azul/verde ou atualização contínua. Neste último caso, se você tiver 2 réplicas da aplicação em execução, elas serão atualizadas sequencialmente, uma após a outra. Este método funciona muito bem, mas não é adequado se você tiver diferentes versões 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 está executando a versão antiga e o aplicativo irá parar de funcionar. Portanto, do ponto de vista da programação, trabalhar nessas condições é bastante difícil.
Esta é uma das razões pelas quais preferimos usar a implantação azul/verde para automatizar a implantação de nossos aplicativos. Com este método, você deve garantir que apenas uma versão do aplicativo esteja ativa por vez.
O mecanismo de implantação azul/verde é semelhante a este. Recebemos tráfego para nossos aplicativos através do ha-proxy, que o encaminha para réplicas em execução do aplicativo da mesma versão.
Quando uma nova implantação é feita, utilizamos o Deployer, que recebe os novos componentes e implanta a nova versão. A implantação de uma nova versão de um aplicativo significa que um novo conjunto de réplicas é “criado”, após o qual essas réplicas da nova versão são lançadas em um novo pod separado. No entanto, o ha-proxy não sabe nada sobre eles e ainda não encaminha nenhuma carga de trabalho para eles.
Portanto, antes de mais nada, é necessário realizar uma verificação de desempenho das novas versões do healthcheck para garantir que as réplicas estejam prontas para atender a carga.
Todos os componentes de implantação devem oferecer suporte a alguma forma de verificação de integridade. Esta pode ser uma verificação de chamada HTTP muito simples, quando você recebe um código com status 200, ou uma verificação mais aprofundada, na qual você verifica a conexão das réplicas com o banco de dados e outros serviços, a estabilidade das conexões do ambiente dinâmico e se tudo inicia e funciona corretamente. Este processo pode ser bastante complexo.
Depois que o sistema verificar se todas as réplicas atualizadas estão funcionando, o Deployer atualizará a configuração e passará o confd correto, que reconfigurará o ha-proxy.
Somente depois disso o tráfego será direcionado para o pod com réplicas da nova versão, e o pod antigo desaparecerá.
Este mecanismo não é um recurso do Kubernetes. O conceito de implantação Azul/verde já 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, transfere-o completamente para a nova versão. Este princípio não é usado apenas no Kubernetes.
Agora apresentarei um novo componente de implantação - Deployer, que executa verificações de integridade, reconfigura proxies e assim por diante. Este é um conceito que não se aplica ao mundo exterior e existe dentro do Kubernetes. Mostrarei como você pode criar seu próprio conceito de Deployer usando ferramentas de código aberto.
Portanto, a primeira coisa que o Deployer faz é criar um controlador de replicação RC usando a API Kubernetes. Essa API cria pods e serviços para posterior implantação, ou seja, cria um cluster completamente novo para nossas aplicações. Assim que o RC estiver convencido de que as réplicas foram iniciadas, ele realizará uma verificação de integridade de sua funcionalidade. Para fazer isso, o Deployer usa o comando GET /health. Ele executa os componentes de verificação apropriados e verifica todos os elementos que suportam a operação do cluster.
Depois que todos os pods relatarem sua integridade, o Deployer cria um novo elemento de configuração - armazenamento distribuído etcd, que é usado internamente pelo Kubernetes, incluindo o armazenamento da configuração do balanceador de carga. Gravamos dados no etcd, e uma pequena ferramenta chamada confd monitora o etcd em busca de novos dados.
Se detectar alguma alteração na configuração inicial, ele gera um novo arquivo de configurações e o transfere para o ha-proxy. Nesse caso, o ha-proxy reinicia sem perder nenhuma conexão e direciona a carga para novos serviços que permitem o funcionamento da nova versão de nossos aplicativos.
Como você pode ver, apesar da abundância de componentes, não há nada complicado aqui. Você só precisa prestar mais atenção à API e ao etcd. Quero falar sobre o implantador de código aberto que usamos - Amdatu Kubernetes Deployer.
É uma ferramenta para orquestrar implantações do Kubernetes e possui os seguintes recursos:
- Implantação Azul/Verde;
- configurar um balanceador de carga externo;
- gerenciamento de descritores de implantação;
- gerenciar a implantação real;
- verificar a funcionalidade das verificações de integridade durante a implantação;
- implementação de variáveis de ambiente em pods.
Este Deployer é construído sobre a API Kubernetes e fornece uma API REST para gerenciar identificadores e implantações, bem como uma API Websocket para streaming de logs durante o processo de implantação.
Ele coloca os dados de configuração do balanceador de carga no etcd, para que você não precise usar o ha-proxy com suporte pronto para uso, mas use facilmente seu próprio arquivo de configuração do balanceador de carga. Amdatu Deployer é escrito em Go, como o próprio Kubernetes, e é licenciado pela Apache.
Antes de começar a usar esta versão do implantador, usei o seguinte descritor de implantação, que especifica os parâmetros necessários.
Um dos parâmetros importantes deste código é habilitar o sinalizador “useHealthCheck”. Precisamos especificar que uma verificação de integridade deve ser realizada durante o processo de implantação. Essa configuração pode ser desabilitada quando a implantação usa contêineres de terceiros que não precisam ser verificados. Este descritor também indica o número de réplicas e a URL de frontend que o ha-proxy precisa. No final está o sinalizador de especificação do pod "podspec", que chama o Kubernetes para obter informações sobre configuração da porta, imagem, etc. Este é um descritor JSON bastante simples.
Outra ferramenta que faz parte do projeto Amdatu de código aberto é o Deploymentctl. Ele possui uma interface de usuário para configurar implantações, armazena o histórico de implantações e contém webhooks para retornos de chamada de usuários e desenvolvedores terceirizados. Você não pode usar a IU, pois o próprio Amdatu Deployer é uma API REST, mas essa interface pode tornar a implantação muito mais fácil para você sem envolver nenhuma API. Deploymentctl é escrito em OSGi/Vertx usando Angular 2.
Agora demonstrarei o que foi dito acima na tela usando uma gravação pré-gravada para que você não precise esperar. Estaremos implantando um aplicativo Go simples. Não se preocupe se você nunca experimentou o Go antes, é um aplicativo muito simples, então você deve ser capaz de descobri-lo.
Aqui estamos criando um servidor HTTP que responde apenas a /health, portanto esta aplicação testa apenas a verificação de saúde e nada mais. Se a verificação for aprovada, a estrutura JSON mostrada abaixo será usada. Ele contém a versão do aplicativo que será implantado pelo implementador, a mensagem que você vê no topo do arquivo e o tipo de dados booleano - se nosso aplicativo está funcionando ou não.
Enganei um pouco na última linha, pois coloquei um valor booleano fixo no topo do arquivo, o que no futuro me ajudará a implantar até mesmo um aplicativo “não íntegro”. Trataremos disso mais tarde.
Então vamos começar. Primeiro, verificamos a presença de pods em execução usando o comando ~ kubectl get pods e, com base na ausência de resposta da URL do frontend, garantimos que nenhuma implantação esteja sendo feita no momento.
Em seguida, na tela, você vê a interface Deploymentctl que mencionei, na qual os parâmetros de implantação são definidos: namespace, nome do aplicativo, versão de implantação, número de réplicas, URL de front-end, nome do contêiner, imagem, limites de recursos, número da porta para verificação de integridade, etc. Os limites de recursos são muito importantes, pois permitem usar a quantidade máxima possível de hardware. Aqui você também pode visualizar o log de implantação.
Se você repetir agora o comando ~ kubectl get pods, poderá ver que o sistema “congela” por 20 segundos, durante os quais o ha-proxy é reconfigurado. Depois disso, o pod é iniciado e nossa réplica pode ser vista no log de implantação.
Cortei a espera de 20 segundos do vídeo e agora você pode ver na tela que a primeira versão do aplicativo foi implantada. Tudo isso foi feito usando apenas a UI.
Agora vamos tentar a segunda versão. Para fazer isso, mudo a mensagem do aplicativo de “Hello, Kubernetes!” em “Hello, Deployer!”, o sistema cria esta imagem e a coloca no registro do Docker, após o que simplesmente clicamos novamente no botão “Deploy” na janela Deploymentctl. Nesse caso, o log de implantação é iniciado automaticamente da mesma forma que aconteceu na implantação da primeira versão da aplicação.
O comando ~ kubectl get pods mostra que existem atualmente 2 versões do aplicativo em execução, mas o frontend mostra que ainda estamos executando a versão 1.
O balanceador de carga aguarda a conclusão da verificação de integridade antes de redirecionar o tráfego para a nova versão. Após 20 segundos, mudamos para curl e vemos que agora temos a versão 2 do aplicativo implantada e a primeira foi excluída.
Esta foi a implantação de um aplicativo “saudável”. Vamos ver o que acontece se para uma nova versão do aplicativo eu alterar o parâmetro Healthy de true para false, ou seja, tento implantar um aplicativo não íntegro que falhou na verificação de integridade. Isso pode acontecer se alguns erros de configuração foram cometidos na aplicação na fase de desenvolvimento e ela foi enviada para produção neste formato.
Como você pode ver, a implantação passa por todas as etapas acima e ~kubectl get pods mostra que ambos os pods estão em execução. Mas, diferentemente da implantação anterior, o log mostra o status do tempo limite. Ou seja, devido à falha na verificação de integridade, a nova versão do aplicativo não pode ser implantada. Como resultado, você verá que o sistema voltou a usar a versão antiga do aplicativo e a nova versão foi simplesmente desinstalada.
O bom disso é que mesmo que você tenha um grande número de solicitações simultâneas chegando ao aplicativo, eles nem perceberão o tempo de inatividade durante a implementação do procedimento de implantação. Se você testar este aplicativo usando a estrutura Gatling, que envia tantas solicitações quanto possível, nenhuma dessas solicitações será descartada. Isso significa que nossos usuários nem perceberão as atualizações de versão em tempo real. Se falhar, o trabalho continuará na versão antiga; se for bem-sucedido, os usuários mudarão para a nova versão.
Só há uma coisa que pode falhar - se a verificação de integridade for bem-sucedida, mas o aplicativo falhar assim que a carga de trabalho for aplicada a ele, ou seja, o colapso ocorrerá somente após a conclusão da implantação. Nesse caso, você terá que reverter manualmente para a versão antiga. Então, vimos como usar o Kubernetes com as ferramentas de código aberto projetadas para ele. O processo de implantação será muito mais fácil se você incorporar essas ferramentas em seus pipelines de Build/Deploy. Ao mesmo tempo, para iniciar a implantação, você pode usar a interface do usuário ou automatizar totalmente esse processo usando, por exemplo, commit to master.
Nosso Build Server criará uma imagem Docker e a enviará para o Docker Hub ou qualquer registro que você usar. Docker Hub oferece suporte a webhook, para que possamos acionar a implantação remota via Deployer da maneira mostrada acima. Dessa forma, você pode automatizar totalmente a implantação do seu aplicativo para produção potencial.
Vamos para o próximo tópico: dimensionamento do cluster Kubernetes. Observe que o comando kubectl é um comando de escalonamento. Com mais ajuda, podemos aumentar facilmente o número de réplicas em nosso cluster existente. No entanto, na prática, geralmente queremos aumentar o número de nós em vez de pods.
Ao mesmo tempo, durante o horário de trabalho pode ser necessário aumentar e, à noite, para reduzir o custo dos serviços da Amazon, pode ser necessário reduzir o número de instâncias de aplicativos em execução. Isso não significa que dimensionar apenas o número de pods será suficiente, porque mesmo que um dos nós esteja ocioso, você ainda terá que pagar à Amazon por isso. Ou seja, junto com o dimensionamento dos pods, você precisará dimensionar o número de máquinas utilizadas.
Isso pode ser desafiador porque, quer usemos a Amazon ou outro serviço de nuvem, o Kubernetes não sabe nada sobre o número de máquinas em uso. Falta uma ferramenta que permita dimensionar o sistema no nível do nó.
Portanto, teremos que cuidar tanto dos nós quanto dos pods. Podemos escalar facilmente o lançamento de novos nós usando a API da AWS e máquinas de grupo de escalonamento para configurar o número de nós de trabalho do Kubernetes. Você também pode usar cloud-init ou um script semelhante para registrar nós no cluster Kubernetes.
A nova máquina inicia no grupo Scaling, inicia-se como um nó, registra-se no registro do mestre e começa a funcionar. Depois disso, você poderá aumentar o número de réplicas para uso nos nós resultantes. A redução exige mais esforço, pois é preciso ter certeza de que tal etapa não leva à destruição de aplicativos já em execução após desligar máquinas “desnecessárias”. Para evitar tal cenário, você precisa definir os nós para o status “não programável”. Isso significa que o agendador padrão irá ignorar esses nós ao agendar pods DaemonSet. O agendador não excluirá nada desses servidores, mas também não lançará novos contêineres neles. O próximo passo é expulsar o nó de drenagem, ou seja, transferir os pods em execução dele 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, você poderá removê-los do Kubernetes. Depois disso, eles simplesmente deixarão de existir para o Kubernetes. Em seguida, você precisa usar a API da AWS para desabilitar nós ou máquinas desnecessárias.
Você pode usar Amdatu Scalerd, outra ferramenta de escalonamento de código aberto semelhante à API AWS. Ele fornece uma CLI para adicionar ou remover nós em um cluster. Seu recurso interessante é a capacidade de configurar o agendador usando o seguinte arquivo json.
O código mostrado reduz a capacidade do cluster pela metade durante o período noturno. Ele configura o número de réplicas disponíveis e a capacidade desejada do cluster Amazon. O uso deste agendador reduzirá automaticamente o número de nós à noite e os aumentará pela manhã, economizando o custo de uso de nós de um serviço de nuvem como o Amazon. Este recurso não está integrado ao Kubernetes, mas o uso do Scalerd permitirá que você dimensione esta plataforma da maneira que desejar.
Gostaria de salientar que muitas pessoas me dizem: “Está tudo muito bem, mas e o meu banco de dados, que geralmente é estático?” Como você pode executar algo assim em um ambiente dinâmico como o Kubernetes? Na minha opinião, você não deveria fazer isso, não deveria tentar executar um data warehouse no Kubernetes. Isso é tecnicamente possível e existem tutoriais na Internet sobre esse assunto, mas complicará seriamente a sua vida.
Sim, existe um conceito de armazenamento persistente no Kubernetes, e você pode tentar executar armazenamentos de dados como Mongo ou MySQL, mas esta é uma tarefa bastante trabalhosa. Isto se deve ao fato de que os data warehouses não suportam totalmente a interação com um ambiente dinâmico. A maioria dos bancos de dados requer configuração significativa, incluindo configuração manual do cluster, não gosta de escalonamento automático e outras coisas semelhantes.
Portanto, você não deve complicar sua vida tentando executar um data warehouse no Kubernetes. Organize seu trabalho da maneira tradicional usando serviços familiares e simplesmente forneça ao Kubernetes a capacidade de usá-los.
Para finalizar o tópico, gostaria de apresentar a plataforma Cloud RTI baseada em Kubernetes, na qual minha equipe está trabalhando. Ele fornece registro centralizado, monitoramento de aplicativos e clusters e muitos outros recursos úteis que serão úteis. Ele usa várias ferramentas de código aberto, como o Grafana, para exibir o monitoramento.
Houve uma dúvida sobre por que usar o balanceador de carga ha-proxy com Kubernetes. Boa pergunta porque atualmente existem 2 níveis de balanceamento de carga. Os serviços Kubernetes ainda residem em endereços IP virtuais. Você não pode usá-los para portas em máquinas host externas porque se a Amazon sobrecarregar seu host na 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 o tráfego se comunicar perfeitamente com o Kubernetes.
Outra boa pergunta é como você pode cuidar das alterações no esquema do banco de dados ao fazer a implantação azul/verde? O fato é que independente do uso do Kubernetes, alterar o esquema do banco de dados é uma tarefa difícil. Você precisa garantir que o esquema antigo e o novo sejam compatíveis, após o que você pode atualizar o banco de dados e, em seguida, atualizar os próprios aplicativos. Você pode trocar o banco de dados a quente e depois atualizar os aplicativos. Conheço pessoas que inicializaram um cluster de banco de dados completamente novo com um novo esquema. Esta é uma opção se você tiver um banco de dados sem esquema como o Mongo, mas de qualquer maneira não é uma tarefa fácil. Caso não tenha mais dúvidas, obrigado pela atenção!
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com