A Landbay usa o GitOps com o Amazon Elastic Kubernetes Service

No cenário constante em evolução de empréstimos digitais, a Landbay, uma financiadora hipotecária premiada no mercado de compra e venda do Reino Unido, está revolucionando sua infraestrutura digital. Com a melhor corretagem da categoria respaldando suas operações de avaliação de risco, a plataforma da Landbay é baseada nos serviços da AWS e compreende aproximadamente 60 microsserviços, seguindo uma arquitetura de três camadas, combinando servidores Web, o Amazon Elastic Kubernetes Service (Amazon EKS) e uma camada de dados multicamadas. Ao combinar o poder dos serviços da Nuvem AWS com projetos de código aberto, a Landbay conseguiu aproveitar essa nova abordagem para criar a melhor arquitetura da categoria baseada no Amazon Elastic Kubernetes Service.

Vantagem do GitOps

À medida que as arquiteturas de microsserviços ganham destaque, o GitOps surgiu como um novo padrão para esse mecanismo de implantação. Dois produtos notáveis surgiram na Cloud Native Computing Foundation (CNCF): o Flux e o ArgoCD. A Landbay selecionou o Flux por sua integração nativa com o Kubernetes, expondo definições personalizadas de recursos (CRDs) para definir implantações, lançamentos de helm, Kustomizations e muito mais. Isso, por sua vez, capacitou os engenheiros de software no domínio do Kubernetes, entendendo melhor como o Flux se encaixa no ecossistema.

Visão geral da solução

Para fornecer uma compreensão abrangente da implementação do GitOps da Landbay, vamos analisar os principais componentes arquitetônicos e suas relações dentro do ecossistema da AWS:

• Amazon Elastic Container Registry (ECR): o Landbay utiliza o Amazon ECR para armazenar charts do Helm, bem como imagens do Docker.
• Controladores externos de DNS e do AWS Elastic Load Balancing: esses controladores são usados para configurar o Route53 e os balanceadores de carga, garantindo acesso externo às entradas do Kubernetes.
  
• Integração com o AWS Secrets Manager: por motivos de arquitetura e de segurança, a Landbay optou pela integração direta com o AWS Secrets Manager, em vez de usar ferramentas externas, como o controlador de segredos externos, que se alinha ao modelo de responsabilidade compartilhada da AWS e aprimora a postura geral de segurança da solução.
  
• Gerenciamento de configuração do Terraform: o Terraform pode ser usado para preencher lacunas ao fornecer um ConfigMap e os principais itens de configuração de sumarização (endpoints, CIDRs de sub-redes etc.). O Flux pode então usar o ConfigMap por meio de seu recurso de pós-compilação (veja a figura 2).
  

Ambiente Kubernetes e arquitetura de dados da Landbay

A Landbay é uma grande adepta do Terraform e toda a sua infraestrutura é codificada através da infraestrutura como código (IAC). Essa abordagem garante a sincronicidade entre os ambientes de teste e produção e garante que todas as mudanças na infraestrutura passem pelo processo padrão do ciclo de vida de desenvolvimento de softwares.

Para garantir um tempo de inatividade zero durante os upgrades do Amazon EKS, o Landbay emprega o uso de grupos de nós gerenciados pelo EKS com três grupos de nós gerenciados, cada um voltado para uma zona de disponibilidade específica. Essa configuração permite o uso de volumes persistentes, facilitados pelo driver CSI do Amazon Elastic Block Store (EBS). Além disso, a Landbay usa a funcionalidade topologySpreadConstraints (DoNotSchedule) para garantir que StatefulSets sejam disseminados pelas zonas de disponibilidade.

Para serviços essenciais, classes de prioridade personalizadas são usadas para eliminar implantações de menor prioridade.

Para reduzir os custos no ambiente de teste, a Landbay aproveita o poder das instâncias spot do Amazon EC2 por meio dos grupos de nós gerenciados do Terraform e do Amazon EKS.

Finalmente, a Landbay adotou o sistema Bottlerocket ao apresentar uma superfície de ataque muito reduzida. Seu operador Kubernetes é usado para atualizar gradualmente os nós em um cluster usando o conceito de ondas. Embora o acesso ao sistema de arquivos raiz esteja bloqueado, a integração com o IAM e o Systems Manager (SSM) satisfaz os requisitos fundamentais da Landbay.

Complementos do Amazon EKS

Além do plugin CNI do Amazon Virtual Private Cloud (Amazon VPC), a Landbay executa os seguintes complementos:

1. CoreDNS: garante a resolução do serviço DNS dentro do cluster
2. KubeProxy: sustenta a descoberta de serviços e a criação de redes no Kubernetes.
   
3. CNI do Amazon VPC com enableNetworkPolicy: permite a aplicação de políticas de rede que ajudam a Landbay a proteger vários acessos a namespaces e pods.
   
4. Driver CSI do Amazon EBS: permite o uso de volumes persistentes.
   

Configuração de gerenciamento de acessos

A Landbay usa o Centro de Identidade do AWS IAM para controlar todo o acesso às APIs da AWS. O Amazon EKS permite o mapeamento de funções de SSO em grupos do Kubernetes, possibilitando o mapeamento indireto para grupos do Azure Entra ID por meio da equipe de administração de TI. Essa abordagem garante uma separação de ocorrências entre a equipe de administração de TI e o resto da organização.

O fragmento acima pode então ser usado para definir um recurso kubernetes_config_map_v1-data aws_auth:

Para evitar a proliferação de funções, o Kubernetes fornece um mecanismo para reunir permissões de outras versões do Helm em grupos existentes usando a opção “aggregate-to-admin”:

AWS Load Balancer Controller

Para aprimorar a integração entre os serviços, a Landbay utilizou o AWS Load Balancer Controller (LBC) e o controlador de DNS externo.

O AWS Load Balancer Controller possibilita o provisionamento de balanceadores de carga diretamente das entradas, e tem a capacidade de reutilizar balanceadores de carga gerenciados externamente e atribuir pods de destino. Ao separar o provisionamento de balanceadores de carga em um projeto separado, as equipes de DevOps podem ter mais privilégios em um repositório de código-fonte e, ao mesmo tempo, fornecer ferramentas de trabalho aos engenheiros que gerenciam os alvos.

O controlador também gerencia grupos de segurança conforme necessário no backend entre o balanceador de carga e seus alvos. Além disso, usando a anotação group.name, o mesmo balanceador de carga pode ser compartilhado com vários grupos-alvo nos bastidores

A Landbay também usa o AWS Load Balancer Controller para provisionar balanceadores de carga de rede e permitir a entrada de funções do AWS Lambda executadas dentro da VPC na infraestrutura EKS.

Complementando isso, o controlador de DNS externo permite que os pods do Kubernetes tenham acesso limitado de gravação no Route53. Esse recurso facilita a exposição automática de serviços externos com nomes de DNS práticos, aprimorando a experiência geral do usuário.

Do ponto de vista da segurança, o controlador do Application Load Balancer (ALB) e o controlador de DNS externo necessitam de um conjunto limitado de permissões do IAM, que podem ser bloqueadas rigorosamente. Por exemplo, o controlador de DNS simplesmente requer acesso de gravação em zonas específicas do Route 53 (route53:ChangeResourceRecordSets), bem como algumas permissões de lista.

Gerenciamento de segredos no Kubernetes

Embora a maioria das soluções resolva problemas relacionados ao gerenciamento de segredos, como rotação de segredos e integração, usar o armazenamento de segredos do Kubernetes ou a sincronização de segredos externos com o Kubernetes resultará no armazenamento de segredos em texto não criptografado no etcd subjacente do Kubernetes. Embora o uso de “segredos criptografados no EKS” ajude a mitigar vetores de ataque físico, o acesso por meio da API do Kubernetes expõe os valores brutos do segredo, de acordo com o modelo de responsabilidade compartilhada da AWS.

O uso do driver Container Storage Interface (CSI) fornecido pela AWS oferece benefícios, mas também afasta a arquitetura de gerenciamento nativo do Kubernetes. Considerando que tanto o driver CSI quanto uma solução de provedor externo exigem integração direta com o provedor externo de segredos, a Landbay decidiu integrar seus microsserviços diretamente ao AWS Secret Manager.

A opção de integração direta evita a introdução de mais complexidade no ambiente, o que, de outra forma, poderia levar a mais custos de manutenção e suporte. Também evita a presença de segredos de texto não criptografado em volumes de contêineres, aumentando ainda mais a segurança.

Fluxo de provisionamento no ambiente da AWS

O Flux, que é a solução de GitOps escolhida pela Landbay, fornece um provedor Terraform para inicializar clusters EKS. Em intervalos regulares configuráveis, o Flux garante que todos os manifestos do Kubernetes definidos no repositório Git se reconciliem com os recursos existentes implantados no Kubernetes, revertendo qualquer desvio detectado. Depois que o Flux é inicializado, ele pode realizar sua primeira reconciliação, instalando serviços configurados, pods, conjuntos com estado e muito mais no cluster Kubernetes, conforme mostrado na figura abaixo.

O Flux pode utilizar o AWS Elastic Container Registry (ECR) como um repositório Helm, pois o ECR oferece suporte de alta qualidade para artefatos OCI. Isso permite que o Flux atue como o elo entre o ECR e o EKS, usando Kustomizations para aplicar configurações específicas do ambiente.

Uma vantagem importante dessa abordagem é a separação lógica entre a parte de integração contínua (CI) do pipeline de implantação (compilação, teste e pacotes) e a parte de implantação contínua (CD) (entrega no ambiente). Do ponto de vista da segurança, o Flux extrai as alterações, permitindo que as permissões de acesso sejam bloqueadas significativamente para implantações diárias. Para evitar atrasos na implantação, a única permissão necessária está relacionada a uma ferramenta de construção para “notificar” o Flux sobre uma reconciliação antecipada, o que pode ser feito por meio de um kubeconfig bloqueado, com um usuário restrito.

Como resultado, implantar, reverter ou promover um novo microsserviço se torna tão simples quanto atualizar um fragmento de versionamento semântico (semver) em um arquivo YAML ou reverter um commit. Ao observar uma alteração no Git, o Flux aciona uma reconciliação com o Kubernetes e atualiza o serviço correspondente apropriadamente.

Estrutura do repositório do Flux e componentes compartilhados

O Flux fornece uma documentação abrangente sobre estruturas de repositório recomendadas. A abordagem da Landbay é relativamente simples e segue essas melhores práticas.

As configurações de cluster são definidas em suas próprias pastas dedicadas, cada uma referenciando componentes compartilhados. Dentro dessas pastas de cluster, o uso extensivo de Kustomizations garante o isolamento entre os clusters. Isso permite configurações específicas do ambiente, como versionamento e memória.

A estrutura ilustrada acima estabelece um equilíbrio entre compartilhar código e reter a natureza declarativa e explícita do paradigma GitOps, permitindo que um engenheiro leia um repositório Git e verifique quais componentes, versões ou pacotes foram instalados no cluster.

Ao separar os componentes, a Landbay pode agilizar o processo de criação de novos clusters. A partir disso, a configuração do cluster se torna uma questão de escolher “peças de LEGO” e montá-las com alguma configuração específica do ambiente.

Além disso, embora alguns clusters operem na nuvem e exijam componentes extras, outros clusters podem ser direcionados a engenheiros de DevOps que trabalham localmente. Essa abordagem de desenvolvimento local fornece um ciclo de feedback mais rápido e não inclui componentes diretamente relacionados aos serviços da AWS.

Desenvolvimento local como ponto de partida

A abordagem de desenvolvimento local também é o ponto de partida para implantações rápidas de ambientes de desenvolvimento efêmeros baseados em nuvem. Ao usar namespaces do Kubernetes e remover dependências dos serviços gerenciados pela AWS, a Landbay pode usar o Flux para inicializar rapidamente novos ambientes independentes.

Nesse caso, o ambiente de desenvolvimento da Landbay pode substituir o Amazon Relational Database Service (RDS) por um contêiner simples do MariaDB ou o Amazon OpenSearch Service pelo contêiner OpenSearch equivalente. Embora essa abordagem mantenha os ambientes de desenvolvimento arquitetonicamente “em sintonia” (por exemplo, namespace semelhante, descoberta de serviços, rede etc.), a desvantagem é a flexibilização da resiliência operacional, o que pode ser aceitável para alguns ambientes de desenvolvimento.

Integração do EKS, de GitOps e de serviços da AWS

Na Landbay, a infraestrutura da AWS é gerenciada inteiramente pelo Terraform. Dessa forma, é imprescindível preencher a lacuna entre os elementos provisionados pelo Terraform (RDS, OpenSearch etc.) e outros pods em execução no cluster. A forma nativa de acessar a configuração no Kubernetes em microsserviços é por meio do ConfigMaps.

O diagrama a seguir mostra a inter-relação entre nossos projetos do Terraform e do Flux.

O primeiro projeto do Terraform é responsável por configurar todas as redes básicas, balanceadores de carga voltados para a Internet e serviços gerenciados pela AWS. O segundo projeto estabelece o cluster EKS, inicializa o Flux no cluster, protege o cluster EKS, configura qualquer perfil do IAM e gerencia questões de baixo nível, como grupos de nós gerenciados executando o Bottlerocket. Esse projeto cria um ambiente ConfigMap que consulta todas as variáveis ambientais na AWS e as injeta no Kubernetes.

O projeto final é um projeto dedicado do Flux. Isso define a configuração do cluster para o ambiente, vincula um conjunto de componentes compartilhados e, em seguida, versões do Helm de kustomizes e manifestos do Kubernetes se adequam ao ambiente relevante. O ambiente ConfigMap pode então ser usado como parte das kustomizations no repositório do Flux. O Flux também oferece um recurso de substituição de variáveis pós-compilação, permitindo o uso de substituições de variáveis com um rico conjunto de funções de substituição da string bash bem definidas.

Por exemplo, em um chart do Helm, os valores podem usar a substituição de variáveis pós-compilação. Como pode ser visto na ilustração abaixo, essa abordagem aprimora o repositório de GitOps para que os componentes compartilhados possam se tornar independentes do ambiente.

Conclusão

A decisão da Landbay de adotar o GitOps por meio do Flux, totalmente integrado ao Amazon EKS e ao ecossistema mais amplo da AWS, provou ser um divisor de águas. Ao adotar essa abordagem de ponta, a Landbay abriu portas para uma infinidade de benefícios que simplificaram suas operações e elevaram sua postura de segurança. Talvez uma das vantagens mais significativas tenha sido a obtenção de eficiências de engenharia em todos os setores. Desde implantações mais rápidas e tempos de espera reduzidos até o aproveitamento contínuo de soluções de terceiros, a integração de GitOps com o EKS e os serviços da AWS revolucionou os processos de desenvolvimento da Landbay.

Além disso, o cenário de segurança da Landbay foi fortalecido, tornando-se mais robusto e favorecendo economicamente a sua manutenção. Ao aproveitar o Bottlerocket, segregar tarefas por meio de permissões SCM/Git e permitir atualizações fáceis por meio do Helm, a Landbay solidificou seu compromisso com a segurança e otimizou os custos operacionais.

O impacto mais profundo dessa jornada transformadora está na maior visibilidade e transparência do estado e das mudanças de workloads do EKS. Com o GitOps, a configuração é declarada usando YAML e todas as modificações são armazenadas como confirmações do Git. Essa mudança de paradigma gerou vantagens significativas para as equipes de suporte, de risco, de conformidade e de auditoria da Landbay, capacitando-as com uma visão e controle sem precedentes sobre seus sistemas de missão crítica.

Caso sinta que a sua startup está preparada para essa transformação assim como a Landbay, participe do AWS Activate para ter acesso a modelos implantáveis, créditos da AWS e oportunidades de aprendizado.