O Blue Matador migrou a infraestrutura do Kubernetes de um cluster gerenciado pelo kops executando em instâncias AWS EC2 para o serviço EKS gerenciado do Kubernetes da AWS depois de fazer uma comparação de outros recursos. Foi escolhido a EKS por ter o melhor modelo de segurança, um plano de controle gerenciado e um menor custo para esse caso de uso em específico. Enquanto o kops foi o vencedor na criação de um novo cluster Kubernetes, o EKS teve uma pontuação mais alta em gerenciamento e segurança de cluster. O InfoQ procurou Keilan Jackson, engenheiro de software da Blue Matador, para descobrir mais sobre a experiência.
O modelo de responsabilidade compartilhada da EKS e o plano de controle gerenciado foram os principais motivos da migração. Antes da EKS, o time do Blue Matador executava os próprios nós principais do Kubernetes em instâncias AWS de 3 c4.large. Atualizações do Kubernetes, para ambos os recursos, correções de bugs e de segurança, eram de responsabilidade da equipe. A AWS ainda oferecia uma camada de segurança, pois a infraestrutura estava sendo executada em um ambiente da AWS, mas o time do Blue Matador precisava gerenciar os próprios problemas de segurança específicos do Kubernetes. "Os clusters do Kubernetes criados com o kops são configurados por padrão de forma muito parecida com o EKS", comentou Jackson, em termos de recursos como rede privada, volumes de arquivos criptografados e controles de grupo de segurança. Configurar um novo cluster usando o EKS precisou de algum trabalho preparatório, mas o EKS facilitou o gerenciamento do cluster depois que a configuração inicial foi feita.
O Blue Matador usa principalmente o HashiCorp Terraform para gerenciar os recursos na AWS. Além disso, possui implementações para muitos tipos de recursos em provedores cloud, mas o uso no mundo real revela certos desafios. Jackson falou sobre alguns dos desafios específicos do EKS que enfrentaram no projeto de migração:
Tentamos alavancar o máximo possível o módulo EKS construído pela comunidade. Os principais problemas que tivemos foram usar versões desatualizadas do provedor da AWS e do Terraform e, em seguida, conectar os recursos gerenciados deste módulo aos nossos recursos gerenciados externamente como nosso ALB principal, as instâncias do RDS e assim por diante. Recomendo externalizar algumas variáveis terraform do módulo usado para configurar o EKS para referenciá-las nos outros módulos:
output "worker_role_arn" { value = "${module.eks_cluster.worker_iam_role_arn}" }
Embora o Terraform possa criar e gerenciar bem os clusters EKS, este último depende dos recursos periféricos que precisam ser interligados. Jackson comenta mais sobre o assunto:
O KS precisa de muitos recursos além do próprio cluster EKS para ser executado. Precisamos configurar nós de trabalho, grupos de segurança, rede VPC e ter um plano para fazer atualizações quando novas versões do Kubernetes forem suportadas pelo EKS. Definitivamente, use o módulo de comunidade se possível, pois isso ajuda a conectar muitos desses recursos essenciais de maneira correta, mas lembre-se de verificar novamente as configurações de acordo com as necessidades de segurança. Por exemplo, é necessário que certifiquemos que os grupos de segurança estejam abertos apenas para os itens que precisam deles, que os nós de trabalho não recebam endereços de IP públicos e que estejamos usando uma AMI criptografada para o dispositivo raiz.
Referindo-se à escala clusters, Jackson diz que "o tamanho total do cluster não chegou a um ponto em que tiveram que usar mais de três masters do cluster de kops, mas era importante que pudessem escalar de maneira rápida e fácil os nós e atualizar para versões mais recentes do Kubernetes à medida que forem lançadas. "
O gerenciamento de ofertas do Kubernetes geralmente são integradas às soluções de monitoramento da plataforma. Jackson explica como monitoram o cluster:
Primeiramente confiamos em nosso próprio produto, o Blue Matador, para nos alertar sobre os clusters Kubernetes. O sistema encontra problemas como deployments que não estão íntegros, eventos de nó críticos, pods que podem ficar sem memória e isso nos ajuda a manter o controle sobre a utilização do cluster. Também usamos o Datadog, mas apenas para representar graficamente algumas métricas personalizadas. Estamos de olho no CloudWatch Container Insights para o Amazon EKS, mas o CloudWatch em geral não é dinâmico o suficiente para o Kubernetes, portanto, não confiamos nele para alertas de produção.
A migração também reduziu os custos de infraestrutura e monitoramento do time.