Olá pessoal!
Neste artigo, decidimos especular um pouco sobre quando e por que as empresas precisam do Kubernetes. Quão difícil é a tecnologia de entrada, quão rápido e como ela será recompensada. Vale a pena e o que tudo isso ameaça. Não nos propusemos a escrever uma revisão técnica aprofundada, das quais existem muitas, mas nos materiais a seguir compartilharemos definitivamente nossas melhores práticas em termos de arquitetura e estabilidade de aplicativos no Kubernetes. Agora, nos concentramos em saber se o jogo vale a pena e o que ganhamos na saída.
O tempo de lançamento no mercado - a velocidade de atualização das atualizações do mercado - hoje está se tornando um fator essencial na eficácia das soluções de TI. O produto precisa ser aprimorado todos os dias: adicione novas funções e módulos, mantenha a documentação e os scripts em perfeitas condições. Ao mesmo tempo, os sistemas online devem funcionar sem problemas e ser atualizados sem afetar os usuários.
Os guardas da atualização contínua discreta são microsserviços, contêineres e a infraestrutura para sua orquestração - Kubernetes (ou K8S, é chamado em círculos técnicos).
Como o Kubernetes fornece atualizações contínuas do sistema
A principal tarefa ao atualizar uma solução de TI é garantir a operação correta após a transferência do ambiente de desenvolvimento para a plataforma do produto. E também no bom funcionamento do sistema no momento da atualização do produto.
O problema está no fato de que as configurações do ambiente de desenvolvimento e dos servidores industriais geralmente não coincidem. Os contêineres corrigem esse problema combinando todos os componentes de software em um pacote isolado do ambiente externo. Isso permite implantar aplicativos de maneira rápida e confiável em qualquer infraestrutura e facilita a atualização da base de código do sistema.
Sem ser notado pelos usuários, as atualizações ocorrem através da duplicação de contêineres e do redirecionamento seqüencial de usuários de um para outro. Para gerenciamento de contêineres (orquestração), usamos o Kuberenetes. Por fim, facilita o gerenciamento, a implantação e a atualização da solução, o monitoramento de desempenho e a depuração em caso de falha.
Quando uma empresa precisa do Kubernetes
Chegou a hora das empresas pensarem em mudar para a plataforma Kubernetes quando:
- Um projeto ou sistema é uma ferramenta significativa para os negócios e, portanto, deve ser tolerante a falhas e continuar a funcionar, mesmo que alguma peça esteja com defeito.
- O sistema está muito carregado, mantendo atualizações ou aprimoramentos rápidos.
- O sistema precisa periodicamente de capacidade adicional. E precisa deles prontamente.
- E com tudo isso, a velocidade de entrega de atualizações para o ambiente industrial é medida em semanas, meses, anos, mas nunca - horas ou dias.
Você também precisa do Kubernetes como uma ferramenta para automação e padronização do trabalho com a solução, se além dos itens acima:
- Não há isolamento entre os sistemas de TI da empresa e cada um pode influenciar o outro.
- Se você precisar escrever um script separado a cada vez para se comunicar com os parâmetros do servidor no qual o sistema está implantado, ou seja, poderá dimensionar esse processo apenas manualmente.
- Existem pessoas-chave na equipe de desenvolvimento - portadoras de “conhecimento secreto” sobre o projeto ou sistema, e elas parecem únicas e insubstituíveis.
Essencialmente, a mudança para o Kubernetes é uma obrigação para as empresas que precisam oferecer suporte a sistemas de informações on-line 24 horas por dia, 7 dias por semana.
Por que Kubernetes?
O Kubernetes não é a única alternativa para integração e implantação contínua (CI / CD). Mas foi o Kubernetes que se tornou o padrão do setor para gerenciar sistemas que exigem alta disponibilidade.
Para nós, como desenvolvedor, os argumentos decisivos a favor do Kubernetes são os seguintes:
- A plataforma está focada em aplicativos, não em infraestrutura.
- O Kubernetes é conveniente para trabalhar com um datacenter, assim como com vários, distribuídos em diferentes cidades.
- Suporte fácil à solução através de documentação clara e uma comunidade ativa.
- Configuração flexível de diferentes aplicações, distribuição segura de tráfego.
- Suporte de contêiner do Docker.
Quais são os benefícios dos negócios da Kubernetes?
- Configuração flexível e processo de atualização automatizada
Você mesmo determina qual parte do sistema deve ser colocada em operação comercial. O Kubernetes permite fazer um curto ciclo de liberação. Todas as operações - desde o código fonte do sistema até a liberação no ambiente do produto - ocorrem automaticamente. Você não precisa de uma equipe de engenheiros para fazer o sistema funcionar. As atualizações atuais não afetam o desempenho do sistema e podem ser realizadas a qualquer momento, conveniente para os desenvolvedores. - Colocação e dimensionamento do sistema
O sistema pode ser colocado na capacidade de computação do cliente (ou no datacenter) e em qualquer provedor de nuvem, por exemplo, Amazon ou Azure. Qualquer nível de desempenho e tolerância a falhas pode ser facilmente alcançado escalando o cluster. - Padronização e auto-documentação
A solução não requer instruções. É auto-documentado e imediatamente empacotado automaticamente em uma unidade de uso - um contêiner. Descrevemos a configuração no Kubernetes como um plano / diagrama. Nós não escrevemos scripts que preparam o ambiente, como era antes do Kubernetes. Em vez disso, passamos às informações do Kubernetes (um diagrama) sobre como a solução deve funcionar. E ele mesmo implementa esse esquema.
Os desenvolvedores agora estão escrevendo um aplicativo para trabalhar em um contêiner. Os engenheiros do DevOps escrevem um diagrama de como um aplicativo deve funcionar em um contêiner, e o próprio Kubernetes executa as tarefas de criação de uma solução.
A tecnologia Kubernetes é padronizada. Será fácil para você treinar um novo funcionário em seu sistema de liberação ou transferir o sistema para um novo contratado.
A descrição final da configuração criada pelo Kubernetes também é a documentação para o sistema. Dos nomes, fica claro imediatamente quais parâmetros estão configurados e para que servem.
Por esse motivo, a plataforma Kubernetes como um todo universaliza lançamentos, atualizações e lançamentos do aplicativo.
- Teste ao vivo indolor
O processo de teste da solução mudou. Os desenvolvedores podem, sob demanda, criar ambientes idênticos aos do produto para testes automatizados. E os logs gerais de como o aplicativo funciona e como o Kubernetes funciona com o aplicativo ajudam a investigar problemas e a encontrar erros ainda mais rapidamente.
Que transição comercial para o Kubernetes exigirá
O próprio Kubernetes será apenas uma pequena parte do seu novo sistema. Você precisa estar preparado para que o Kubernetes, como uma ferramenta para padronizar todo o ciclo de desenvolvimento, a atualização e a publicação de aplicativos acarreta uma mudança em tudo no momento da transição: arquitetura de software, processo de desenvolvimento e manutenção da infraestrutura.
- Arquitetura da solução
Do ponto de vista do produto, a transição é possível apenas se o sistema for implementado ou atualizado para uma arquitetura de microsserviço com base em serviços que podem ser empacotados em contêineres (serviços sem estado). - Processo de desenvolvimento
Do ponto de vista do processo de desenvolvimento, a transição envolve principalmente uma mudança de pensamento. Quaisquer melhorias situacionais e "muletas" adicionadas no último momento são completamente excluídas. Um desenvolvedor de soluções de TI pode trabalhar apenas como uma equipe, que inicialmente produz um produto decomposto, inicialmente testado, suportado, empacotado e decomposto. Tudo deve ser construído logicamente desde a primeira linha de código até a operação. - Processo de atualização
Mesmo no estágio de desenvolvimento da arquitetura do aplicativo, você precisa pensar em como atualizar a solução sem parar. E entenda imediatamente como você atualizará o banco de dados, API, como é lógico oferecer suporte a várias versões do aplicativo, levando em consideração o fato de que as pessoas trabalham com o sistema durante a atualização e podem cair em versões diferentes.
E mais uma mudança de pensamento está relacionada ao fato de que, ao mudar para o Kubernetes, a infraestrutura começa a funcionar no modo somente leitura e para atualizar o sistema, você precisa criar novas versões das imagens do aplicativo e pedir ao Kubernetes para usar a nova versão, e depois desativará a versão antiga e irá se excluir.
Portanto, melhorias no sistema e mudanças na tecnologia do trabalho não podem ser evitadas. A mudança não será rápida. Mas você precisará alterar o paradigma apenas uma vez.
Case. Como transferimos o sistema de microsserviço para o Kubernetes
Operamos em um ambiente de produto uma solução altamente carregada baseada na arquitetura de microsserviços, que transmite mais de 300 mil transações por dia e nos horários de pico - 60 a 80 mil por hora. Atualizamos regularmente o produto, também há versões mais urgentes que anteriormente eram necessárias para suspender o sistema ou parte de sua funcionalidade por um tempo.
Entramos no mercado sem K8S, mas desenvolvemos o sistema inicialmente com um olho. Foram necessárias 6 semanas para traduzir a solução para o Kubernetes. Mudamos nas seguintes direções:
1) Configurando o pipeline de implantação
a. Configurando o pipeline para montagem, teste e atualização de aplicativos contínuos (CI / CD) em ambientes de teste.
b. Configure atualizações contínuas em um ambiente industrial.
c. Preparação e configuração do ambiente o mais próximo possível do ambiente industrial (pré-produção). Implantamos e testamos o cluster próximo às máquinas virtuais atuais.
d. Desenvolvimento de um plano de migração para um ambiente industrial.
Então, tudo parece simples, temos um pipeline de CI / CD para todos os ambientes e você pode mudar, mas é muito cedo!
2) Seleção de configuração de cluster
Passamos algumas semanas selecionando a configuração mais estável dos componentes e versões do cluster Kubernetes: sistema operacional + Docker + Kubernetes.
Testamos três configurações diferentes de sistemas operacionais (Ubuntu, CentOS, Oracle Linux, versões mais recentes). Em cada sistema operacional, verificamos duas versões diferentes do Docker e do Kubernetes - a que foi entregue nas versões mais recentes dos pacotes padrão do sistema operacional e a versão mais recente do fabricante. Como resultado, as configurações da distribuição padrão do Oracle Linux mostraram a maior estabilidade e nós as estabelecemos.
3) Definindo configurações de contêiner
Passamos mais tempo ajustando os parâmetros do contêiner - configuramos os requisitos de memória, disco e processos.
E somente depois que fizemos tudo isso e testamos vários parâmetros de funcionamento do sistema (estabilidade, tolerância a falhas e outros) na pré-codificação sob cargas próximas às de combate e o sistema funcionou de maneira estável, passamos para a etapa final - a migração.
Então tudo foi simples.
Dia C. Migração
Para a migração de combate, escolhemos o tempo com a carga mínima do sistema: o número mínimo de usuários e a ausência de uma carga aumentada de acordo com o cronograma de trabalho interno dos algoritmos do sistema.
O tempo de inatividade do sistema foi de cerca de uma hora e praticamente não afetou os usuários. A migração em si consistiu em trocar os usuários de um sistema para outro e observar que tudo corria bem.
Vida com Kubernetes
Agora, o processo de atualização não afeta o desempenho do sistema, pode ser realizado a qualquer momento, conveniente para os desenvolvedores e tem a seguinte aparência:
- Os desenvolvedores fizeram uma revisão, testaram e enviaram o código para a publicação.
- O código foi montado automaticamente, empacotado em imagens do docker e publicado em um repositório do docker privado.
- O Kubernetes gera automaticamente novas versões de serviços, verifica se os serviços estão funcionando corretamente, alterna os usuários para usar novas versões de serviços, interrompe o trabalho de versões antigas e as remove do cluster. A atualização ocorreu.
Resumindo nossa experiência
Você precisa do Kubernetes se:
- É necessária alta disponibilidade do sistema.
- O sistema está se desenvolvendo dinamicamente e você precisa fornecer alterações no ambiente do produto com os olhos fechados.
- Você deseja trabalhar como uma única equipe, do código ao ambiente do produto.
- Você está criando um sistema dinâmico e em evolução que irá operar por anos.
O Kubernetes é "caro", pois a entrada na tecnologia exigirá:
- Estudo por desenvolvedores de tecnologias relacionadas.
- Revisão dos processos de design, desenvolvimento, implantação, teste e gerenciamento ambiental.
- Experiência na operação do próprio Kubernetes: agora você precisa monitorar não apenas o seu sistema, mas também os serviços de aplicativos do Kubernetes.
Pague o Kubernetes muito rapidamente:
- O procedimento de atualização do sistema é muito mais simples e rápido. Os desenvolvedores são liberados de todo um bloco de trabalho.
- Cada novo especialista já entrará no projeto nos trilhos.
- O transportador será transparente e automatizado.
- A experiência será repetida por sua equipe para outros sistemas.
- Você atualizará o sistema sem colocá-lo fora de operação, o que significa que não interromperá os negócios.
PS Conselhos práticos: divida a entrada da tecnologia em dois estágios: desenvolvendo um sistema com a arquitetura correta de microsserviço e movendo-o sob o controle do K8S. Assim, a transição sob o Kubernetes não se transformará em uma refatoração global.