BT

Início Notícias Migrando de Kubernetes autogerenciados para o AWS EKS usando o Terraform no Blue Matador

Migrando de Kubernetes autogerenciados para o AWS EKS usando o Terraform no Blue Matador

Favoritos

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.