A jornada de Kubernetes
Diretor de Operações de Software e Segurança
TrustlyA , Inc. (anteriormente conhecida como PayWithMybank) trabalhou com toda a sua operação em nuvem para executar mais de 20 microsserviços desde 2015, que são responsáveis por conectar seus usuários com mais de 1.000 bancos globalmente. Embora o Trustly tivesse uma infraestrutura madura e estável, a jornada começou em 2018 para modernizar a arquitetura do aplicativo para usar contêineres no Kubernetes.
Visão geral
O ambiente da Trusty é executado inteiramente na Amazon Web Services (AWS). Durante anos, teve principalmente orquestração de nuvem usando CloudFormation e Packer. Utilizámos três camadas de CloudFormation: uma para a rede, uma para o proxy inverso (Nginx) e uma para a aplicação. Cerca de duas implementações por dia foram feitas diretamente pelo CloudFormation. Este modelo de implementação contínua serviu-nos muito bem. Vamos chamar esse antigo ambiente de classic-infra.
Em 2018, a equipa DevSecOps do Trustly começou a estudar o Kubernetes (K8s) e transferiu o tráfego de produção para o novo ambiente em maio de 2021. Quando começámos a estudar a Kubernetes, tornou-se claro que esta não satisfazia todas as capacidades da nossa interface clássica. Como resultado, pesquisámos as ferramentas essenciais para o nosso processo dentro do cluster.
Mas primeiro, vamos falar sobre o Elastic Kubernetes Service (EKS)...
EKS: Como estávamos na AWS, fazia sentido usar o EKS para executar nosso ambiente no K8s. O EKS é um serviço da AWS que fornece segurança e disponibilidade para o plano de controle do Kubernetes. Quando começámos em 2018, a versão do EKS era 1.11, o que criou muitos problemas e exigiu processos manuais para integrar o nosso VPC com a ferramenta EKSCTL. Por exemplo, podia-se provisionar o cluster K8s, mas havia demasiados passos manuais para fazer tudo funcionar. Quando lançámos o cluster K8s em produção em 2021, já estávamos na versão 1.20 do EKS, que fornecia muito mais capacidades de automatização no EKSCTL.
Ferramentas
OpenSearch: Com o Kubernetes, é necessário recolher e centralizar os registos de alguma forma. Por esse motivo, precisávamos de uma ferramenta para gerenciar logs de aplicativos no Kubernetes. Um dos motivos pelos quais o projeto levou três anos para ser concluído foi o tempo necessário para aprender e implantar um cluster do ElasticSearch usando o OpenDistroElasticSearch (no início). Recentemente, actualizámos para o OpenSearch, que é uma ferramenta robusta com todas as funcionalidades necessárias para uma gestão fiável dos registos e que pode ser integrada no Filebeat e no Logstash.
Spinnaker: Na jornada para implantar o Kubernetes, notamos limitações nos requisitos de implantação. Para as resolver, adoptámos a ferramenta Spinnaker, desenvolvida e mantida pela Netflix. O Spinnaker permitiu-nos criar um pipeline complexo e a possibilidade de ter uma implementação azul/verde no nosso cluster.
Terraform: Quando começámos a nossa viagem, todo o nosso ambiente estava no CloudFormation. Não tínhamos experiência com o Terraform. Para os novos ambientes Kubernetes, toda a configuração da conta AWS foi criada pelo Terraform. O Terraform é responsável por criar o VPC, os grupos de segurança, as sub-redes, as tabelas de rota, o gateway nat e os recursos necessários para executar o cluster do K8s.
Eksctl: Esta é uma excelente ferramenta para instalação e configuração de um cluster EKS. Ela consegue facilitar vários passos na instalação de um novo cluster EKS.
Com todas estas ferramentas, foi possível manter a mesma visibilidade que tínhamos no classic-infra dentro do cluster EKS, obtendo os benefícios do Kubernetes nesta nova arquitetura.
A vez
Para estarmos preparados para o dinamismo e o ritmo acelerado do desenvolvimento do Kubernetes, concebemos - tanto no VPC como nos componentes associados ao cluster - a capacidade de executar a nossa aplicação simultaneamente em dois clusters (encaminhando o tráfego entre eles através do ROUTE53). Esta estratégia ajudou-nos a passar do classic-infra para o Kubernetes, dividindo o tráfego em pequenas percentagens até atingir 100% de tráfego no K8s.
Aumentámos cuidadosamente o tráfego ao longo das semanas (começando com 1% do tráfego, passando depois para 5% do tráfego). Após muitos ajustes e melhorias, acabámos por converter 100% do tráfego para Kubernetes. Nesse ponto, estávamos confortáveis com o ambiente e pudemos observar sua estabilidade nos dias seguintes.
A receita para o sucesso da nossa estratégia foi manter o log do cluster separado do cluster K8s. Com isso, ambos os ambientes poderiam enviar logs para o OpenSearch e, através de tags, poderíamos identificar o cluster em cada linha de log, facilitando o troubleshooting.
Conclusão
O Kubernetes é uma ferramenta poderosa, mas requer um esforço extra para instalar, configurar e manter, e requer outros componentes para criar um cluster K8s que esteja pronto para produção.
Este primeiro artigo é uma visão geral da arquitetura do Kubernetes em Trustly. Se você quiser ver mais detalhes sobre escalonamento automático, estratégia de verificação de integridade de pods e práticas recomendadas de Java usando contêineres, siga este blog para obter conteúdo futuro.
Denner Padilha
Chefe de Operações de Nuvem e Segurança, Trustly América
Denner é Chefe de Operações de Nuvem e Segurança em Trustly. No início de 2018, Denner ingressou no Trustly como Gerente de Operações de TI, onde foi responsável por toda a infraestrutura de nuvem e operações de TI para as Américas do Norte.
Denner tem vasta experiência em desempenho de aplicativos, bem como em auditoria de segurança ISO27001, PCI e SSAE18 SOC Tipo 2. Anteriormente, trabalhou como professor no Brasil, ensinando disciplinas de TI para estudantes de graduação e MBA.