O blog da AWS
16 Benefícios do Amazon EKS para se considerar quando escolher sua opção de deploy
Por Gabriel Bella Martini, Education Solutions Architect, AWS Brazil Public Sector
Lucas Duarte, Sr. Container Specialist SA, AWS LATAM
O Amazon Elastic Kubernetes Service (Amazon EKS) é um serviço Kubernetes totalmente gerenciado. O Amazon EKS executa o Control Plane do Kubernetes em várias zonas de disponibilidade da AWS, detecta automaticamente e substitui nós do Control Plane que apresentam problemas de integridade e oferece atualizações e aplicação de patches sob demanda. O EKS oferece disponibilidade de 99,95% no SLA. Ao mesmo tempo, o console EKS fornece capacidade de observabilidade dos clusters do Kubernetes para que possa identificar e resolver problemas com mais rapidez.
Neste blogpost falaremos sobre benefícios em utilizar o Amazon EKS, por se tratar de uma versão gerenciada do Kubernetes existem diversas funcionalidades que são abstraidas para o cliente facilitando assim a operação do seu cluster, trazendo os pontos importantes de forma simples e direta para te ajudar a definir como você irá realizar o deploy de seu ambiente Kubernetes.
Provisionamento e Configuração
Control Plane Gerenciado
O Control Plane do Kubernetes possui os componentes essenciais para o funcionamento do cluster, sendo responsáveis por detectar eventos e executar ações no cluster. Requisitos como trabalhar com alta disponibilidade e escalabilidade de cada um dos seus componentes é necessário para o funcionamento do Kubernetes. O EKS gerencia automaticamente a disponibilidade entre zonas de disponibilidade e escalabilidade dos componentes Kubernetes API e camada de persistência etcd para cada cluster.
Node Groups Gerenciados
Provisionar, registrar, atualizar e gerenciar os próprios nós (instâncias Amazon EC2) pode ser uma tarefa difícil. O EKS possibilita a utilização de nós gerenciados, utilizando a integração de forma transparente com o Amazon EC2 Auto Scaling e a possibilidade de utilização de instâncias spot, Arm e instâncias de inferência de forma simplificada, pode-se criar, registrar automaticamente ao cluster autoscaler, atualizar automaticamente ou encerrar nós para seu cluster com uma única operação. É importante considerar a questão de responsabildiade compartilhada, sendo ainda assim necessário verificar e utilizar as últimas versões de imagens oficiais AWS para o EKS ou instalar os patches de segurança caso esteja utilizando uma imagem customizada.
Fargate
O AWS Fargate é um serviço para execução de containers serverless. O Fargate elimina a necessidade de escolher instâncias, atualizar e gerenciar máquinas virtuais e ajustar a escala da capacidade do cluster, focando somente na execução do container. O EKS permite utilizar nós do tipo Fargate utilizando controllers criados pela própria AWS e instalados no control plane gerenciado do EKS, possuindo uma integração transparente com os componentes do Kubernetes. Verifique através deste link as considerações para saber se este modelo de execução é o melhor para o seu tipo de workload.
Console & eksctl
A AWS disponibiliza duas maneiras nativas para o gerenciamento e provisionamento do cluster EKS. Através da console AWS é possível administrar, visualizar e efetuar troubleshoot em um lugar centralizado. Também é possível utilizar o eksctl, uma ferramenta de linha de comando open-source para simplificar as operações de seu cluster, incluindo o gerenciamento de nós , provisionamento da infraestrutura e add-ons.
Add-ons Gerenciados
O Amazon EKS permite instalar, gerenciar e atualizar add-ons em seu cluster diretamente via console, cli ou API. Todos os add-ons disponibilizados via EKS API são validados pela AWS e é possível adicionar em momento de provisionamento do cluster ou posteriormente. Um exemplo de add-on é o VPC CNI, no qual abordaremos mais a frente. Para verificar os add-ons disponíveis até o momento siga as instruções neste link.
Atualização
Controle de Versão do Control Plane
O Amazon EKS trás uma maneira preescritiva de realizar o update do Control Plane, o processo de atualização consiste em o Amazon EKS iniciar novos nodes do API Server com a versão atualizada do Kubernetes para substituir os nós existentes, por se tratar de um serviço gerenciado, o Amazon EKS executa verificações de integridade nesses novos nodes para validar o seu funcionamento. É importante salientar que a versão dos Node Groups deve ser a mesma que a versão do Control Plane no momento de realizar o update da versão, mais informações sobre o update preescritivo podem ser encontradas neste link.
Atualização dos Node Groups Gerenciados
Conforme informado nos paragrafos anteriores, a utilização do Managed Node Groups é uma maneira de automatizar o provisionamento e gerenciamento do ciclo de vida dos Nodes. Quando utilizado o Amazon EKS automaticamente faz o update dos seus Nodes para você, incrementando o tamanho máximo e o tamanho desejado do Auto Scaling Group em até duas vezes o número de Zona de disponibilidades, isso garante que pelo menos uma nova instância com a nova versão seja iniciada em todas as AZs que seu Austo Scaling Group está implantado, se você estiver utilizando uma AMI otimizada do Amazon EKS, ele automaticamente aplica os últimos patches de segurança e de sistema operacional, o update pode ser realizado via eksctl ou também via AWS Console, informações de como realizar o update de um Managed Node Group podem ser encontradas nesse link.
Atualização dos Node Groups Autogeridos
Já o Self-managed Node Groups o processo de atualização é um pouco mais complexo, uma vez que os passos que são executados pelo Amazon EKS de forma automatizada precisam ser feitos pelo administrador do cluster de forma “manual”, existem basicamente duas maneiras de realizar o update de versão de um Self-managed node group, são elas:
Segurança
OpenID
OpenID Connect é um protocolo de autenticação baseado no OAuth 2.0. Ele adiciona uma camada em cima do OAuth 2.0 que adiciona a identificação de quem está logado, no Amazon EKS você pode utilizar um OIDC identity provider público como por exemplo a Amazon ou o seu próprio Identity Provider.
IAM Roles para Service Accounts
Quando o Amazon EKS foi lançado não existia uma maneira nativa de associar roles a objetos do Kubernetes como, por exemplo, um Deployment. Para endereçar esse requisito a comunidade veio com algumas soluções Open-Source, como por exemplo kube2iam, kiam entre outros. Agora você pode associar uma role do IAM com uma Service Account do Kubernetes, essa Service Account então prove permissões a nível da AWS para os containers em qualquer pod que utilize essa Service Account. As roles do IAM para Service Account oferecem os seguintes benefícios:
- Menor Privilégio – Utilizando IAM Roles para Service Accounts, você não precisa mais prover permissões extendidas para a role do Node que os pods estão rodando.
- Isolamento de Credenciais – Um container só pode recuperar credenciais para a role do IAM que esteja associado com a sua Service Account.
- Auditoria – O registro em log de acessos e eventos está disponível no AWS CloudTrail.
Auditoria
O Amazon EKS é integrado ao AWS CloudTrail, um serviço que fornece um registro de ações realizadas por um usuário, uma função ou um serviço da AWS no Amazon EKS. O CloudTrail captura todas as chamadas de API do serviço Amazon EKS como eventos, incluindo as chamadas do console do Amazon EKS e desde as chamadas de código até as operações de API do Amazon EKS. Também é possível enviar logs do control plane para o Amazon CloudWatch Logs, alguns tipos de logs que podem ser habilitados são API Server, Controller Manager e Scheduler.
Security Group para Pods
A utilização de Security Groups para pods só é possível por conta do Amazon VPC CNI, abordaremos o funcionamento e os beneficios do Amazon VPC CNI nos próximos tópicos. Security groups para pods integra os security groups do Amazon EC2 com os pods do Kubernetes, você pode utilizar security groups do Amazon EC2 para definir regras que permitem tráfego de rede de entrada e saída para e a partir de pods que você implanta em nodes em execução em muitos tipos de instâncias Amazon EC2.
Envelope Encryption com KMS
O Amazon EKS permite implementar envelope encryption de secrets do Kubernetes usando chaves do AWS KMS para clusters EKS existentes. A envelope encryption adiciona uma camada de criptografia gerenciada pelo cliente para secrets de apps ou dados do usuário armazenados em um cluster Kubernetes, saiba como implementar envelope encryption utilizando eksctl neste link.
Redes
API Server Público e Privado
O API Server é um dos componentes do Control Plane responsável pela comunicação do cluster. Através da exposição de uma API HTTP é permitido consultar e manipular o estado dos objetos no Kubernetes. Por padrão o EKS cria um API Server público com integração ao AWS IAM e RBAC nativo do Kubernetes. Para restringir o acesso somente via Amazon VPC o cluster permite habilitar o acesso privado. Essa mudança pode ser feita em um cluster existente ou pode ser definida em um novo cluster. Se necessário, também é possível manter os dois tipos de comunição, público e privado.
VPC CNI
Pensando na interface de rede do Kubernetes, a AWS suporta de forma nativa o plugin Open-source VPC CNI que possibilita os pods terem o mesmo endereço IP dentro da sua rede VPC além da possibilidade de utilizar de forma transparante a segurança e os recursos de rede que a AWS disponibiliza, como por exemplo, security groups e regras de roteamento. Caso você queira utilizar outro plugin CNI também é possível, sendo recomendado ter a experiência de gerenciar uma rede Kubernetes com esse plugin e/ou suporte comercial do plugin escolhido, alguns exemplos são o Calico e o Weave Net.
Nuvem Híbrida
O Amazon EKS Anywhere permite criar e operacionalizar clusters EKS em seu próprio datacenter e com as mesmas ferramentas que o EKS na AWS. A distribuição utilizada pelo Amazon EKS é a EKS Distro que está disponível de forma Open-source no GitHub.
Conclusão
Durante o Blogpost foram abordados alguns pontos e benefícios em utilizar o Amazon EKS, por se tratar de um serviço gerenciado pela AWS existem várias features built-in que facilitam a operação do cluster Kubernetes, dessa forma diminuindo o overhead operacional do administrador do cluster. No momento da escolha de onde realizará o deploy do seu cluster é importante considerar além da precificação, todos os benefícios atrelados em utilizar um serviço gerenciado.
Sobre os autores
Gabriel Bella Martini é um Arquiteto de Soluções na AWS com foco em clientes de Educação. Tem experiência em diferentes projetos relacionados a Inteligência Artificial e tem grande interesse na área de computação gráfica.
Lucas Duarte é um Arquiteto Especialista em Containers na AWS com focos em clientes LATAM. Entusiasta de automação, Cloud, e cultura DevOps. Com experiência prévia em projetos focados nesse segmento em empresas como IFood, Guiabolso e Mandic. Tem trabalhado em diferentes projetos relacionados principalmente a orquestração de containers e microsserviços.