O blog da AWS

O que há por trás do Amazon EKS Auto Mode

Este post do blog foi co-autorado por Alex Kestner, Sr Product Manager – EKS; Todd Neal, Sr. Software Engineer – EKS; Neelendra Bhandari, Sr Software Dev Manager – EKS; e Sai Vennam, Principal Specialist Solutions Architect. E traduzido por Rodrigo Prado – Sr. Solution Architect.

No re:Invent 2024, lançamos o Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode, uma nova funcionalidade que fornece um cluster Kubernetes em conformidade e pronto para produção, que está preparado para hospedar suas cargas de trabalho imediatamente. Neste post, mergulhamos no que isso significa para suas cargas de trabalho Kubernetes e olhamos por baixo dos panos dos clusters EKS Auto Mode.

Introdução ao EKS Auto Mode

O EKS Auto Mode é uma forma simplificada de executar aplicações no Kubernetes. Ele gerencia automaticamente a configuração, scaling e manutenção do control plane Kubernetes e worker nodes, para que você não precise se preocupar com a infraestrutura subjacente. Você foca em implementar suas aplicações, e o EKS Auto Mode cuida do resto, tornando-o ideal para usuários que querem usar Kubernetes sem gerenciar sua complexidade.

No re:Invent em 2017, lançamos o Amazon EKS, que simplificou a operação do Kubernetes para nossos usuários. No lançamento, o Amazon EKS forneceu um control plane Kubernetes gerenciado integrado com serviços existentes como AWS Identity and Access Management (IAM). Somos responsáveis pela saúde e patching desse control plane e nossos usuários atualmente executam dezenas de milhões de clusters EKS todo ano. No entanto, os usuários ainda eram responsáveis por operar seu data plane Kubernetes, os nodes Amazon Elastic Compute Cloud (Amazon EC2) nos quais as cargas de trabalho executavam. Introduzimos funcionalidades ao longo dos anos como Managed Node Groups e Karpenter, que reduziram o esforço de operar o data plane. Contudo, os usuários ainda eram responsáveis por escolher o S.O correto, escalar os nodes subjacentes e gerenciar add-ons e componentes centrais como o CNI e kube-proxy.

Figura 1: Modelo de Responsabilidade Compartilhada com Amazon EKS (sem Auto Mode)

O EKS Auto Mode é uma evolução sobre o modelo operacional que introduzimos em 2017, onde agora assumimos mais responsabilidade pela porção do data plane de um cluster Kubernetes e fornecemos capacidades gerenciadas de compute, networking e storage. O EKS Auto Mode permite que usuários criem um cluster e imediatamente comecem a implementar suas cargas de trabalho em um ambiente pronto para produção. Somos responsáveis pela configuração, patching e saúde das instâncias EC2, permitindo que usuários foquem apenas na configuração da VPC e cluster, e nos containers de aplicação que estão executando.

Figura 2: Modelo de Responsabilidade Compartilhada com EKS Auto Mode

O data plane no EKS Auto Mode

Há uma série de componentes críticos que compõem o data plane para clusters EKS Auto Mode:

  • EC2 Managed Instances são instâncias EC2 padrão onde o controle operacional foi delegado a um serviço AWS
  • Bottlerocket é um sistema operacional open source construído especificamente pela AWS para executar containers
  • Core capabilities e add-ons são incorporados aos nodes EKS Auto Mode, eliminando a necessidade dos usuários gerenciarem e manterem esses componentes
  • Worker nodes management (utilizando o Karpenter) lida com a saúde dos worker nodes automaticamente, com a capacidade de deletar e substituir nodes com os tipos de instância ideais para eficiência de custo

Instâncias EC2 gerenciadas

Em seu nível mais baixo, o EKS Auto Mode usa uma nova funcionalidade anunciada no re:Invent 2024:  Instâncias EC2 gerenciadas. São instâncias EC2 padrão, exceto que você delegou o controle operacional sobre a instância para um serviço AWS como o Amazon EKS. Essencialmente, você troca overhead operacional e algum controle para ganhar segurança aprimorada.

Por exemplo, você não mais desconecta manualmente um volume Amazon Elastic Block Store (Amazon EBS) de um node EKS Auto Mode, porque a capacidade de armazenamento gerenciado é responsável por anexar e desconectar volumes EBS necessários pelas cargas de trabalho. Similarmente, você não faz SSH diretamente nos nodes, mas sempre mantém a capacidade de interagir e fazer troubleshoot de instâncias através do serviço Amazon EKS.A limpeza de clusters EKS é mais direta, porque deletar o cluster EKS força a terminação das Instâncias EC2 gerenciadas associadas ao cluster.

Instâncias EC2 gerenciadas permitem que o EKS Auto Mode gerencie perfeitamente a capacidade de compute para cargas de trabalho Kubernetes. Portanto, você pode focar em implementar e executar aplicações ao invés de gerenciar nodes. Suas cargas de trabalho são mantidas no mesmo padrão como se a AWS estivesse executando cargas de trabalho em seu nome (por exemplo, AWS Lambda ou AWS Fargate). Quando as cargas de trabalho excedem a capacidade de nodes existentes, o EKS Auto Mode usa Karpenter (coberto em detalhes na seção Worker nodes management abaixo) para provisionar dinamicamente mais Instâncias EC2 gerenciadas para garantir alta disponibilidade e performance, eliminando assim a necessidade de ajustes manuais de scaling.

Além de simplificar o gerenciamento de infraestrutura, Instâncias EC2 gerenciadas também ajudam a otimizar custos. Elas podem usar mecanismos existentes de economia de custo da AWS, como Instâncias Reservadas e Savings Plans, fornecendo assim flexibilidade enquanto mantém despesas previsíveis.

Usar Instâncias EC2 gerenciadas através do EKS Auto Mode permite que os usuários desfrutem de uma experiência Kubernetes totalmente gerenciada onde a AWS cuida da infraestrutura, liberando usuários para se concentrarem no desenvolvimento e scaling de aplicações.

Bottlerocket como a escolha de sistema operacional

Instâncias EC2 gerenciadas, como todas as outras Instâncias EC2, precisam de um sistema operacional. O EKS Auto Mode usa Bottlerocket: um sistema operacional open source construído especificamente pela AWS para executar containers. Bottlerocket é um sistema operacional base ideal para EKS Auto Mode, pois é projetado para executar cargas de trabalho Kubernetes de forma eficiente e segura. Bottlerocket inclui apenas o software essencial necessário para executar containers. O projeto open source mantém cerca de 100 definições de package, comparado a 50.000 em um sistema operacional de propósito geral grande. Isso garante que funcionalidades e dependências desnecessárias sejam desabilitadas em tempo de build.

Além disso, isso reduz a área de superfície de ataque para potenciais CVEs, ao mesmo tempo que fornece mais recursos para cargas de trabalho, eliminando serviços que não são necessários para os casos de uso de containers. Bottlerocket impõe verificações de integridade criptográfica para o root filesystem e controles de acesso obrigatórios, como SELinux, para reduzir a superfície de ataque no evento de escape de container.

As Amazon Machine Images (AMIs) do EKS Auto Mode são variantes customizadas do Bottlerocket que usam o novo sistema Out of Tree Build (OOTB) do Bottlerocket, que é um mecanismo simplificado para criar variantes customizadas do Bottlerocket. Essas variantes definem uma dependência no core do Bottlerocket de uma forma que permite que a variante customizada evolua independentemente e consuma atualizações do Bottlerocket core com segurança.

O kernel kit e core kit formam o núcleo do Bottlerocket, e as AMIs do EKS Auto Mode consomem ambos esses kits do projeto Bottlerocket para se beneficiar de seu foco em segurança e dependências cuidadosamente selecionadas.

Além de fornecer novas capacidades de node específicas do EKS Auto Mode, a Auto Mode AMI também faz algumas mudanças na configuração base do Bottlerocket. Por exemplo, o Bottlerocket padrão não suporta login interativo através de SSH ou Console. Em vez disso, permite que usuários tragam um tipo especial de container chamado host container para fornecer acesso.

O EKS Auto Mode desabilita completamente os host containers do Bottlerocket e em vez disso fornece mecanismos nativos do Kubernetes para recuperar logs de node e interagir diretamente com o node, como recuperar informações de troubleshooting do node quando o mesmo não tem conectividade de rede. O EKS Auto Mode também usa novas funcionalidades do Bottlerocket como bootstrap commands para configurar armazenamento de instância local no node para os tipos de instância que o suportam. Isso garante que o armazenamento local efêmero de alta velocidade incluído com esses tipos de instâncias seja automaticamente usado para imagens de container, dados efêmero de pod e logs.

Core node capabilities

Um node Kubernetes tipicamente precisa de uma série de DaemonSets que criam um pod por node para fornecer funcionalidade essencial a nível de node. Nossos usuários frequentemente expressaram que gerenciar, fazer patching e garantir compatibilidade entre esses componentes era desafiador e demorado. Como parte do EKS Auto Mode, eliminamos esse trabalho pesado e indiferenciado para os componentes mais comumente utilizados.

Começamos identificando quais core node capabilities eram usadas na vasta maioria dos Clusters EKS, e então trabalhamos para construir essas capacidades diretamente nos nodes EKS Auto Mode:

  • Networking: Configuração de networking local do node, DNS e enforcement de política de rede
  • Storage: Configuração a nível de sistema operacional de Volumes Persistentes suportados por Amazon EBS e armazenamento de instância local  para dados efêmeros
  • Identity: Fornece identidades IAM para pods configurados
  • Specialized hardware support
    • AWS Neuron: Drivers e device plugin para tornar aceleradores Inferentia e Trainium disponíveis para pods
    • NVIDIA: Drivers e device plugin para tornar GPUs NVIDIA disponíveis para pods
    • Elastic Fabric Adapter (EFA): Drivers e device plugin para tornar dispositivos EFA disponíveis para pods
  • Health: Monitoramento de integridade de nodes, habilitando relatórios e reparo automático de determinados modos de falha

Portanto, com um cluster EKS Auto Mode, você pode criar um pod com a rede configurada corretamente, incluindo a aplicação de Políticas de Rede, que usa Pod Identity para fazer requisições para serviços AWS, e tem um Volume Persistente suportado por Amazon EBS onde armazena dados. Se seu Node Pool suporta tipos de instância acelerados, então esse mesmo pod também pode usar aceleradores Neuron ou GPUs NVIDIA solicitando o recurso através das solicitações de recursos do pod.

Para reduzir ainda mais a sobrecarga nos usuários, o monitoramento de integridade built-in verifica periodicamente um conjunto de problemas e modos de falha que identificamos ao longo do tempo operando Amazon EKS, e reporta esses através de eventos e condições Kubernetes. Para casos de erro como um kubelet não responsivo ou esgotamento de todos os process IDs, o EKS Auto Mode pode reparar automaticamente o node substituindo-o para minimizar interrupções das aplicações

Worker nodes management

A capacidade de computação do EKS Auto Mode, utilizando o Karpenter, combina instâncias EC2 gerenciadas e as AMIs baseadas em Bottlerocket do EKS Auto Mode para criar nodes do EKS Auto Mode. Ele automaticamente inicia e encerra esses nodes conforme necessário para fornecer a capacidade de compute necessária para executar suas cargas de trabalho. Esses nodes são continuamente otimizados para eficiência de custo baseado em seus Node Pools configurados e os requisitos de carga de trabalho dentro do seu cluster.

O processo começa identificando os tipos de instância com melhor custo-benefício que atendem aos requisitos do seu workload (como CPU, memória ou necessidades de hardware especializado) e suas restrições de agendamento do Kubernetes. Você pode precisamente controlar a seleção de tipo de instância através de requisitos de workload ou Node Pool, ou manter flexibilidade permitindo uma gama mais ampla de tipos de instância, potencialmente reduzindo custos. Quando instâncias adequadas são identificadas, o EKS Auto Mode provisiona as instâncias EC2 gerenciadas necessárias usando AMIs Auto Mode compatíveis para esses tipos específicos de instância.

Ao longo do tempo, os requisitos de cargas de trabalho podem mudar conforme fazem scale up ou down para atender à demanda, ou quando cargas de trabalho são adicionadas ou removidas do cluster. O EKS Auto Mode avalia continuamente todo o seu cluster como parte de seu processo de consolidação para determinar se pode executar as cargas de trabalho maximizando o custo-benefício. Em alto nível, usa dois métodos para alcançar isso:

  • Node deletion: Um node é elegível para deleção quando todos os seus pods podem executar na capacidade disponível de outros nodes no cluster
  • Node replacement: Um node pode ser substituído quando todos os seus pods podem ser redistribuídos através tanto da capacidade disponível de nodes existentes quanto de um único node substituto de menor custo

Essa integração perfeita de provisionamento rápido de nodes e otimização contínua de custos permite que você foque nas cargas de trabalho do seu cluster enquanto o EKS Auto Mode cuida das tarefas de gerenciamento de nodes

Lifecycle e manutenção

Antes do EKS Auto Mode, usuários eram responsáveis por validar a compatibilidade de componentes a nível de node com seu control plane do cluster EKS, implementar esses componentes e garantir que permanecessem com patches e atualizados. Funcionalidades como Cluster Insights reduziram parte dessa carga mostrando incompatibilidades, mas o deployment e patching permaneciam uma responsabilidade do usuário.

O EKS Auto Mode permite que a AWS assuma essa responsabilidade, garantindo que uma AMI testada e atualizada, que inclui todas as capacidades essenciais de node, seja continuamente disponibilizada para todos os nodes do EKS Auto Mode. Nosso processo de build e release da AMI do Auto Mode é conduzido por um pipeline de implantação contínua que é responsável por:

  • Verificação de CVEs
  • Construção de AMI
  • Validação de AMI
    • Testes de conformidade do Kubernetes
    • Testes funcionais de componentes (por exemplo, validar que pods podem obter credenciais IAM através do EKS Pod Identity)
    • Testes de segurança
  • Implantação de AMI

O pipeline adere às nossas melhores práticas para Implantações contínuas seguras. O processo começa implantando a AMI recém-testada em um pequeno subconjunto de clusters EKS Auto Mode em uma única região, com um período de estabilização para detectar problemas potenciais. Conforme a confiança na estabilidade da AMI aumenta, ela é gradualmente distribuída para mais clusters em ondas maiores e através de mais Regiões AWS, enquanto reduz o tempo de estabilização entre implantações.

O EKS Auto Mode permite que usuários controlem e acionem todas as atualizações do control plane. Para atualizações do data plane, usuários podem usar Pod Disruption Budgets e Node Disruption Budgets para gerenciar o processo de atualização. Essas ferramentas oferecem controle granular tanto a nível de pod quanto de node:

  • Pod Disruption Budgets definem o número máximo de interrupções permitidas para cargas de trabalho específicas durante atualizações.
  • Node Disruption Budgets permitem que usuários especifiquem janelas de manutenção e controlem o número de nodes que podem ser atualizados simultaneamente.

Quando a AWS lança novas AMIs do EKS Auto Mode com patches de segurança, o EKS Auto Mode pode automaticamente atualizar os nodes respeitando as restrições de agendamento do Kubernetes e os orçamentos de interrupção configurados. A documentação de melhores práticas do Amazon EKS fornece orientação detalhada sobre como implementar esses controles efetivamente, incluindo recomendações específicas para manter a confiabilidade da aplicação durante atualizações.

Conclusão

O Amazon EKS Auto Mode representa uma evolução significativa em como os usuários podem executar Kubernetes na AWS. Combinando instâncias gerenciadas do Amazon EC2 para gerenciamento seguro de computação, Bottlerocket para um sistema operacional otimizado para containers, e capacidades de nodes integradas para funcionalidade essencial, permite que o EKS Auto Mode habilite usuários a mudarem seu foco do gerenciamento de infraestrutura para o desenvolvimento de aplicações. Em vez de gastar tempo configurando componentes de node, gerenciando patches de segurança e mantendo ferramentas operacionais, equipes podem se concentrar em implementar e escalar aplicações que importam para seus negócios.

Pronto para começar com EKS Auto Mode? Você pode implantar um novo cluster EKS Auto Mode ou habilitar o EKS Auto Mode em um cluster existente usando eksctl, a AWS CLI, o Console de Gerenciamento AWS, as APIs do EKS ou suas ferramentas de infraestrutura como código preferidas. Experimente nosso workshop prático que guia você pela implantação de cargas de trabalho e exploração das capacidades do Auto Mode. Você pode executar isso na sua própria conta da AWS ou se registrar para um evento hosted pela AWS.

Este conteúdo foi traduzido da postagem original do blog, que pode ser encontrada aqui.

Biografia do tradutor 

Rodrigo Prado é arquiteto de soluções sênior na AWS com mais de 20 anos de experiência em TI. Ele trabalha apoiando empresas de software na sua jornada de modernização e disponibilização de suas soluções no AWS Marketplace.

https://www.linkedin.com/in/rmprado/

Biografia do Revisor

Bruno Lopes é Sr. Specialist Solutions Architect na AWS LATAM, com mais de 17 anos de experiência em TI. Especialista em Containers e Kubernetes na AWS, ele atua com clientes em toda a América Latina, acelerando a modernização de aplicações e a adoção de ambientes híbridos. Ao longo da carreira, também atuou como Consultor, Technical Trainer e Evangelista, ajudando equipes a superarem desafios técnicos com soluções inovadoras e práticas.

https://www.linkedin.com/in/blopesinfo/