Simplificar o ciclo de vida dos nós com grupos de nós gerenciados

• Os grupos de nós gerenciados do Amazon EKS criam e gerenciam instâncias do Amazon EC2 para você.

• Todos os nós gerenciados são provisionados como parte de um grupo do Amazon EC2 Auto Scaling gerenciado pelo Amazon EKS para você. Além disso, todos os recursos, inclusive as instâncias do Amazon EC2 e os grupos do Auto Scaling, são executados em sua conta da AWS.

• O grupo do Auto Scaling de um grupo de nós gerenciados abrange todas as sub-redes que você especificar ao criar o grupo.

• O Amazon EKS adiciona etiquetas aos recursos do grupo de nós gerenciados para que eles sejam configurados para usar o Kubernetes Cluster Autoscaler.

  Importante

  Se você está executando uma aplicação com estado em várias zonas de disponibilidade baseadas em volumes do Amazon EBS e usando o Kubernetes Escalar a computação em cluster com o Karpenter e o Cluster Autoscaler, deverá configurar vários grupos de nós, cada um delimitado a uma única zona de disponibilidade. Além disso, você deverá ativar o recurso --balance-similar-node-groups.

• Você pode usar um modelo de execução personalizado para obter um nível maior de flexibilidade e personalização ao implantar nós gerenciados. Por exemplo, é possível especificar argumentos kubelet extras e usar uma AMI personalizada. Para obter mais informações, consulte Personalizar nós gerenciados com modelos de execução. Se você não usar um modelo de execução personalizado ao criar primeiro um grupo de nós gerenciados, um modelo de execução será gerado automaticamente. Não modifique manualmente esse modelo gerado automaticamente, ou ocorrerão erros.

• O Amazon EKS segue o modelo de responsabilidade compartilhada para CVEs e patches de segurança nos grupos de nós gerenciados. Quando os nós gerenciados executam uma AMI otimizada para o Amazon EKS, o Amazon EKS é responsável por criar versões da AMI com patches quando erros ou problemas forem relatados. Podemos publicar uma correção. No entanto, você é responsável por implantar essas versões de AMI com patches nos grupos de nós gerenciados. Quando os nós gerenciados executam uma AMI personalizada, você é responsável por criar versões da AMI com patches quando erros ou problemas forem relatados e, em seguida, implantar a AMI. Para obter mais informações, consulte Atualizar um grupo de nós gerenciados para seu cluster.

• Os grupos de nós gerenciados do Amazon EKS podem ser executados em sub-redes públicas e privadas. Se você executar um grupo de nós gerenciados em uma sub-rede pública depois de 22 de abril de 2020, a sub-rede deverá ter o MapPublicIpOnLaunch definida como true para que as instâncias possam ingressar com êxito em um cluster. Se a sub-rede pública foi criada usando eksctl ou os modelos do Amazon EKS fornecidos pelo AWS CloudFormation depois de 26 de março de 2020, essa configuração já estará definida como true. Se as sub-redes públicas foram criadas antes de 26 de março de 2020, será necessário alterar a configuração manualmente. Para obter mais informações, consulte Modificar o atributo de endereçamento IPv4 público para a sua sub-rede.

• Ao implantar um grupo de nós gerenciados em sub-redes privadas, certifique-se de que ele possa acessar o Amazon ECR para extrair imagens de contêiner. Você pode fazer isso conectando um gateway NAT à tabela de rotas da sub-rede ou adicionando os seguintes endpoints de VPC do AWS PrivateLink:

  • Interface do endpoint de API do Amazon ECR - com.amazonaws.region-code.ecr.api

  • Interface do endpoint de API do registro Docker do Amazon ECR - com.amazonaws.region-code.ecr.dkr

  • Endpoint de gateway do Amazon S3 - com.amazonaws.region-code.s3

  Para conhecer alguns serviços e endpoints frequentemente, consulte Implementar clusters privados com acesso limitado à internet.

• Os grupos de nós gerenciados não podem ser implantados no AWS Outposts, no AWS Wavelength ou no AWS Local Zones.

• Você pode criar vários grupos de nós gerenciados em um único cluster. Por exemplo, é possível criar um grupo de nós com a AMI padrão do Amazon Linux otimizada para o Amazon EKS para algumas workloads e outro grupo com a variante de GPU para workloads que requerem suporte para GPU.

• Se o grupo de nós gerenciados encontrar uma falha nas verificações de status para as instâncias do Amazon EC2, o Amazon EKS retornará um código de erro para ajudar você a diagnosticar o problema. Para obter mais informações, consulte Códigos de erro para o grupo de nós gerenciados.

• O Amazon EKS adiciona rótulos do Kubernetes a instâncias de grupo de nós gerenciados. Esses rótulos fornecidos pelo Amazon EKS são prefixados com eks.amazonaws.com.

• O Amazon EKS drena automaticamente os nós usando a API do Kubernetes durante os encerramentos ou atualizações.

• Os orçamentos de interrupção do pod não são respeitados ao encerrar um nó com AZRebalance ou reduzir a contagem de nós desejada. Essas ações tentam remover o Pods do nó. Mas se demorar mais de 15 minutos, o nó será encerrado, independentemente de todos os Pods no nó serem encerrados. Para estender o período até que o nó seja encerrado, adicione um hook do ciclo de vida ao grupo do Auto Scaling. Para obter mais informações, consulte Adicionar ganchos de ciclo de vida, no Guia do usuário do Amazon EC2 Auto Scaling.

• Para executar o processo de drenagem corretamente após receber uma notificação de interrupção pontual ou uma notificação de rebalanceamento de capacidade, CapacityRebalance deve ser definido como true.

• A atualização de grupos de nós gerenciados respeita os orçamentos para interrupção do Pod definidos para os Pods. Para obter mais informações, consulte Entenda cada fase das atualizações de nós.

• Não há custos adicionais para o uso dos grupos de nós gerenciados do Amazon EKS. Você paga apenas pelo recursos da AWS que provisionar.

• Se quiser criptografar volumes do Amazon EBS para os nós, você pode implantar os nós usando um modelo de execução. Para implantar nós gerenciados com volumes criptografados do Amazon EBS sem usar um modelo de execução, criptografe todos os novos volumes do Amazon EBS criados em sua conta. Para obter mais informações, consulte Criptografia por padrão no Guia do usuário do Amazon EC2.

Como funciona

Por padrão, se você não especificar um tipo de capacidade, o grupo de nós gerenciados será provisionado com instâncias sob demanda. Um grupo de nós gerenciados configura um grupo do Amazon EC2 Auto Scaling em seu nome com as seguintes configurações aplicadas:

• A estratégia de alocação para provisionar capacidade sob demanda é definida como prioritized. O grupo de nós gerenciados usa a ordem dos tipos de instâncias transferidas na API para determinar qual tipo de instância usar primeiro para atender à capacidade sob demanda. Por exemplo, você pode especificar três tipos de instância na seguinte ordem: c5.large, c4.large e c3.large. Quando as instâncias sob demanda são iniciadas, o grupo de nós gerenciados atende à capacidade sob demanda, começando com o c5.large, depois o c4.large e, em seguida, o c3.large. Para obter mais informações, consulte Grupo do Amazon EC2 Auto Scaling) no Guia do usuário do Amazon EC2 Auto Scaling.

• O Amazon EKS adiciona o seguinte rótulo do Kubernetes a todos os nós do grupo de nós gerenciados que especifica o tipo de capacidade: eks.amazonaws.com/capacityType: ON_DEMAND. Você pode usar esse rótulo para agendar aplicações com estado ou intolerantes a falhas em nós sob demanda.

Como funciona

Para usar instâncias spot dentro de um grupo de nós gerenciados, crie o grupo definindo o tipo de capacidade como spot. Um grupo de nós gerenciados configura um grupo do Amazon EC2 Auto Scaling em seu nome com as seguintes práticas recomendadas Spot aplicadas:

• Para garantir que os nós spot sejam provisionados nos pools de capacidade spot ideais, a estratégia de alocação é definida como uma das seguintes opções:

  • price-capacity-optimized (PCO): ao criar novos grupos de nós em um cluster com o Kubernetes versão 1.28 ou superior, a estratégia de alocação é definida como price-capacity-optimized. No entanto, a estratégia de alocação não será alterada para grupos de nós já criados com capacity-optimized antes de os grupos de nós gerenciados pelo Amazon EKS começarem a oferecer suporte ao PCO.

  • capacity-optimized (CO): ao criar novos grupos de nós em um cluster com o Kubernetes versão 1.27 ou inferior, a estratégia de alocação é definida como capacity-optimized.

  Para aumentar o número de grupos de capacidade spot disponíveis para alocação de capacidade, configure um grupo de nós gerenciados para usar vários tipos de instância.

• O Rebalanceamento de capacidade spot do Amazon EC2 está habilitado para que o Amazon EKS possa drenar e reequilibrar os nós spot para minimizar a interrupção da aplicação quando um nó spot correr um risco alto de interrupção. Para obter mais informações, consulte Rebalancear a capacidade do Amazon EC2 Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling.

  • Quando um nó spot recebe uma recomendação de rebalanceamento, o Amazon EKS tenta iniciar automaticamente um novo nó spot de substituição.

  • Se um aviso de interrupção do spot de dois minutos chegar antes que o nó spot de substituição esteja em um estado Ready, o Amazon EKS começa a drenar o nó spot que recebeu a recomendação de rebalanceamento. O Amazon EKS drena o nó da melhor forma possível. Como resultado, não há garantia de que o Amazon EKS aguardará que o nó de substituição se junte ao cluster antes de drenar o nó existente.

  • Quando um nó spot de substituição inclui o bootstrap no estado Ready no Kubernetes, o Amazon EKS isola e drena o nó Spot que recebeu a recomendação de rebalanceamento. Isolar o nó spot garante que o controlador de serviço não envie novas solicitações para esse nó spot. Ele também o remove da lista de nós spot íntegros e ativos. Drenar o nó Spot garante que os Pods em execução sejam removidos normalmente.

• O Amazon EKS adiciona o seguinte rótulo do Kubernetes a todos os nós do grupo de nós gerenciados que especifica o tipo de capacidade: eks.amazonaws.com/capacityType: SPOT. Você pode usar esse rótulo para agendar aplicações com estado ou intolerantes a falhas em nós spot.

Considerações para selecionar um tipo de capacidade

Ao decidir se deseja implantar um grupo de nós com capacidade sob demanda ou spot, você deve considerar as seguintes condições:

• Convém usar instâncias spot para aplicações sem estado, com tolerância a falhas e flexíveis. Isso inclui workloads de treinamento em lote e de machine learning, ETLs de big data, como Apache Spark, aplicações de processamento de fila e endpoints de API sem estado. Como o spot é a capacidade sobressalente do Amazon EC2, que pode ser alterada ao longo do tempo, recomendamos usar a capacidade spot para workloads tolerantes a interrupções. Mais especificamente, a capacidade spot é adequada para workloads que podem tolerar períodos em que a capacidade necessária não está disponível.

• Recomendamos usar On-Demand para aplicações que sejam intolerantes a falhas. Isso inclui ferramentas de gerenciamento de clusters, como ferramentas operacionais e de monitoramento, implantações que exigem StatefulSets e aplicações com estado, como bancos de dados.

• Para maximizar a disponibilidade de suas aplicações ao usar instâncias spot, recomendamos que você configure um grupo de nós gerenciados spot para usar vários tipos de instância. Recomendamos aplicar as seguintes regras ao usar vários tipos de instância:

  • Dentro de um grupo de nós gerenciados, se você estiver usando o Cluster Autoscaler, recomendamos o uso de um conjunto flexível de tipos de instância com a mesma quantidade de vCPU e recursos de memória. Isso serve para garantir que os nós de seu cluster escalem conforme o esperado. Por exemplo, se você precisar de quatro vCPUs e oito GiB de memória, use c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge ou outros tipos de instância semelhantes.

  • Para melhorar a disponibilidade das aplicações, recomendamos implantar vários grupos de nós gerenciados pelo spot. Para isso, cada grupo deverá usar um conjunto flexível de tipos de instância que tenham os mesmos recursos de vCPU e memória. Por exemplo, se você precisar de 4 vCPUs e 8 GiB de memória, recomendamos que você crie um grupo de nós gerenciados com c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge ou outros tipos de instância semelhantes, e um segundo grupo de nós gerenciados com m3.xlarge, m4.xlarge, m5.xlarge, m5d.xlarge, m5a.xlarge, m5n.xlarge ou outros tipos de instância semelhantes.

  • Ao implantar o grupo de nós com o tipo de capacidade spot que estiver usando um modelo de execução personalizado, use a API para passar vários tipos de instância. Não passe um único tipo de instância pelo modelo de execução. Para obter mais informações sobre como implantar um grupo de nós usando um modelo de execução, consulte Personalizar nós gerenciados com modelos de execução.