Para o serviço de backup Clumio Protect, utilizamos o Amazon Elastic Kubernetes Service (EKS) para gerenciar nossos clusters do Kubernetes. A principal vantagem de usar um Kubernetes gerenciado é a integração estreita com outros serviços do seu provedor de nuvem. Especificamente, quando você cria um novo serviço do Kubernetes, um controlador de serviço — fornecido pela AWS e instalado no cluster — cria uma nova instância do Elastic Load Balancer (ELB) e a configura para encaminhar o tráfego para o serviço. Ao mesmo tempo, esse controlador gerencia todo o ciclo de vida do balanceador de carga correspondente: ele fornece uma configuração correta para suas verificações de integridade e mantém o grupo de destinos do balanceador de carga atualizado quando você adiciona ou remove nós do cluster. Por fim, ele exclui o balanceador de carga quando você exclui seu serviço do Kubernetes do cluster.
Embora seja muito prático utilizar os serviços do Kubernetes com o suporte dos balanceadores de carga da AWS, há várias questões que devemos levar em consideração.
A arquitetura nativa da nuvem da Clumio
Nossa arquitetura é baseada em microsserviços, e cada um de nossos clusters do Kubernetes conta com várias dezenas desses serviços. O número de serviços é especialmente notável em nossos clusters de desenvolvimento, onde hospedamos o maior número possível de ambientes de desenvolvimento isolados em um único cluster. Em alguns clusters de desenvolvimento, temos mais de 300 serviços, e esse número continua aumentando. Nem é preciso dizer que cada balanceador de carga da AWS tem um custo, e não seria razoável termos mais de 300 balanceadores de carga da AWS apenas para um único cluster de desenvolvimento. Outra questão é o limite de balanceadores de carga que cada cluster EKS pode suportar. Esse limite está relacionado ao número máximo de regras no Grupo de Segurança do EC2. Especificamente, nosso cluster EKS médio não poderia ter mais do que 60 balanceadores de carga clássicos. Para resolver essa questão, decidimos usar o Kubernetes Ingress para a maioria dos nossos serviços. O mecanismo do Ingress nos permite compartilhar um único ELB entre vários serviços em um cluster EKS, o que reduz o uso de recursos e os custos.
Por que adicionar o Kubernetes Ingress
A criação de um novo balanceador de carga da AWS geralmente leva algum tempo. Esse atraso é aceitável para a maioria das operações; no entanto, para certas alterações — como, por exemplo, a implantação simultânea de vários microsserviços —, queríamos minimizar o tempo necessário para que eles ficassem no estado de Readiness. Para atender a esse caso de uso, a adição de um novo Ingress do Kubernetes proporciona uma operação instantânea. Dependendo da implementação específica, um controlador de Ingress precisa recarregar a nova configuração, de forma semelhante aos controladores de Ingress do Nginx, ou aplicar a nova configuração em tempo de execução, de forma semelhante aos controladores de Ingress baseados no Envoy.
Ao trabalhar com serviços, espera-se que cada um deles tenha um nome DNS, possivelmente externo. Com a abordagem de um ELB por serviço, não é possível criar um nome DNS até que o ELB seja criado. Com um único ELB pré-alocado para o controlador de Ingress, é possível atribuir antecipadamente quantos aliases DNS forem necessários a esse ELB, de modo que todos os nossos serviços fiquem disponíveis assim que criarmos definições de Ingress para eles.
Alguns de nossos serviços expõem uma API REST, mas a grande maioria deles possui endpoints gRPC. Precisávamos de um controlador Ingress que suportasse tanto HTTPS quanto gRPC ao mesmo tempo, e queríamos que o TLS fosse encerrado no próprio controlador Ingress. Este último não era um requisito estrito, e consideramos usar sidecars do Istio para encerrar o TLS diretamente em um pod de microsserviço. No entanto, decidimos usar o controlador Ingress para encerrar o TLS porque é mais simples de gerenciar e, em geral, exige menos sobrecarga para o cluster. Outro requisito que tínhamos era poder implantar várias instâncias do controlador Ingress no mesmo cluster. Uma definição específica do Ingress pode ter uma anotação kubernetes.io/ingress.class para especificar qual controlador de Ingress deve ser utilizado.
Testamos vários controladores Ingress e descobrimos que foi surpreendentemente difícil encontrar aquele que atendesse a todos os requisitos. Alguns controladores não funcionavam corretamente com o gRPC, outros não ofereciam suporte a múltiplas instâncias de controlador nos mesmos clusters. Por fim, descobrimos que o controlador Ingress do NGINX funciona para nós. Tivemos que fazer apenas um pequeno ajuste na configuração para aumentar o tamanho do buffer do gRPC e, assim, fazer com que funcionasse com nossa pilha de gRPC.
Aprimoramos constantemente nossos serviços de infraestrutura para dimensionar nossa infraestrutura e otimizar os custos de manutenção. Inicialmente, utilizávamos um balanceador de carga dedicado por serviço, mas logo atingimos o limite de balanceadores de carga por cluster. Nesse momento, atualizamos nossa infraestrutura para utilizar controladores Ingress hospedados para a conectividade externa de nossos serviços e reduzimos significativamente o número de balanceadores de carga clássicos da AWS necessários para o produto. Usar o AWS Application Load Balancer (ALB) não era uma opção naquele momento, pois o ALB não oferecia suporte a gRPC. No final de 2020, a AWS anunciou que havia adicionado suporte para HTTP/2 de ponta a ponta e gRPC ao Application Load Balancer. Agora podemos usar o controlador AWS Load Balancer, anteriormente conhecido como “AWS ALB Ingress Controller”, que foi doado ao Grupo de Interesse Especial do Kubernetes da AWS (SIG-AWS) para permitir que a AWS e outros colaboradores do SIG-AWS mantenham oficialmente o projeto. Estamos ansiosos para utilizar esse controlador Ingress em nossa infraestrutura. Outro foco de nosso interesse é a Kubernetes Gateway API, uma nova API do Kubernetes que está em fase de desenvolvimento pelo Grupo de Interesse Especial em Rede (SIG-Network). Em comparação com a API Ingress, a API Gateway expõe uma API mais geral para proxy, que pode ser usada para mais protocolos além do HTTP, e modela mais componentes de infraestrutura para oferecer melhores opções de implantação e gerenciamento aos operadores de cluster. Estamos ansiosos para experimentar futuros controladores do Kubernetes que implementem a API Gateway.
Redução do uso de recursos e dos custos
O mecanismo Ingress do Kubernetes nos ajuda a reduzir a utilização de recursos e os custos. Não estamos mais limitados pelas restrições do EC2 e do EKS no que diz respeito ao número de serviços implantados em um único cluster gerenciado do Kubernetes. Alguns dos controladores Ingress de código aberto funcionam com serviços gRPC de forma nativa, mas exigem uma verificação adicional para confirmar se são adequados a um caso de uso específico. A comunidade do Kubernetes fornece e aprimora constantemente as APIs do Kubernetes, como a API do Ingress ou a API do Gateway, enquanto fornecedores comerciais e de código aberto oferecem diversas implementações dessas APIs. Isso permite escolher a implementação certa para um caso de uso específico e substituir implementações sem grandes alterações no nível da aplicação.
