As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Ative o Amazon EKS Auto Mode em todos os clusters EKS usando GitHub ações
Urbija Goswami e Anugrah Lakra, da Amazon Web Services
Resumo
Os clusters do Amazon Elastic Kubernetes Service (EKS) tradicionalmente exigem gerenciamento manual de recursos computacionais por meio de grupos de nós. Isso cria uma sobrecarga operacional para:
Decisões de planejamento e escalabilidade de capacidade
Provisionamento de nós e gerenciamento do ciclo de vida
Otimização de custos em diferentes tipos de carga de trabalho
Manutenção e atualizações da infraestrutura
O Amazon EKS Auto Mode automatiza o gerenciamento de recursos computacionais provisionando e escalando dinamicamente os nós com base nas demandas da carga de trabalho, eliminando a necessidade do gerenciamento manual de grupos de nós.
No entanto, muitas organizações lutam para habilitar e gerenciar consistentemente o Amazon EKS Auto Mode em seus clusters novos e existentes. Os desafios comuns incluem:
Processos complexos de migração de grupos de nós existentes
Risco de interrupção do serviço durante a transição
Necessidade de planejamento e teste cuidadosos de capacidade
Requisito de permissões e configurações específicas do Amazon IAM
Coordenação entre várias equipes e ambientes
Esse padrão implementa um fluxo de trabalho de GitHub ações
Depois de ativar o Modo Automático, o fluxo de trabalho drena e exclui grupos de nós antigos, atualiza as permissões da função do cluster e limpa os componentes de escalabilidade anteriores, como Karpenter e Cluster Autoscaler. O fluxo de trabalho pode ser integrado aos pipelines existentes de integração contínua e contínua delivery/deployment (CI/CD).
Pré-requisitos e limitações
Pré-requisitos
1. Obrigatório
Uma GitHub conta
e seu próprio GitHub repositório para executar o fluxo de trabalho Uma conta ativa da AWS
com permissões administrativas
2. Instalação de ferramentas locais
Terraform
versão 1.13.0 ou posterior GitHub CLI
(gh), configurada com as credenciais apropriadas kubectl e eksctl, configurados para gerenciamento de clusters
3. Requisitos do cluster EKS
Kubernetes versão 1.29 ou posterior
Configuração de acesso ao endpoint:
Ou está configurado para endpoints públicos e privados
Ou endpoint privado com NAT Gateway em sub-redes privadas
API EKS e acesso ao ConfigMapcluster ativados (necessários para permitir que o EKS gerencie dinamicamente os nós do Modo Automático e atualize o aws-auth ConfigMap para a autenticação adequada do cluster durante a migração)
4. Requisitos de configuração do IAM OIDC
A função e o provedor de identidade do IAM para GitHub isso incluem:
Política de confiança para GitHub OIDC
Permissões para:
Gerenciamento de clusters do EKS
Acesso ao bucket do S3
Gerenciamento de perfis do IAM
Gerenciamento de rede EC2
Consulte o código iam.tf
para uma configuração simples usando o Terraform. A função do IAM (GitHubActionsEKSRole) será criada quando o código do Terraform for aplicado.
Limitações
Só é compatível com clusters EKS com Kubernetes versão 1.29 e superior
Suporta apenas a versão 1.1.0 e superior do Karpenter
Region-specific implementação. Alguns serviços da AWS não estão disponíveis em todas as regiões da AWS. Para ver a disponibilidade da região, consulte os serviços da AWS por região
Requer acessibilidade do endpoint do cluster
Limitado a grupos de AWS-managed nós
Arquitetura
Pilha de tecnologias de destino
Arquitetura de destino

O fluxo de trabalho de GitHub ações é acionado do GitHub repositório pelo usuário.
O GitHub Actions Workflow assume uma função do IAM usando o OIDC para fazer as alterações necessárias na conta da AWS. Ele também verifica a presença da função EKS Auto Node na conta e, se não estiver presente, a função é criada e as políticas necessárias são anexadas.
Um backup do estado atual do cluster EKS que precisa do Modo Automático ativado é carregado em um bucket do S3.
A função de cluster do cluster que precisa do Modo Automático ativado é recuperada e permissões adicionais (AmazonEKSComputePolicy,,, AmazonEKSBlockStoragePolicy AmazonEKSLoadBalancingPolicy AmazonEKSNetworkingPolicy, AmazonEKSClusterPolicy) são adicionadas a ela se não estiverem presentes no Modo Automático EKS. Além disso, como uma etapa de pré-migração, as sub-redes dos clusters são atualizadas com tags para habilitação do EKS Auto Mode.
O fluxo de trabalho ativa o EKS Auto Mode no cluster EKS.
Grupos de nós antigos são identificados e excluídos. Isso é ignorado se o usuário não tiver concedido as permissões para a função do IAM descritas nas etapas opcionais de configuração abaixo.
Os componentes de escalabilidade (Karpenter e Cluster Autoscaler) também são removidos se estiverem presentes anteriormente.
O fluxo de trabalho de GitHub ações consiste em três trabalhos principais:
check-clusters: identifica clusters sem o modo automático ativado e atualiza as políticas do IAM e as tags de sub-rede.backup-and-check: faz backup do estado do cluster antes da migração.gradual-migration: ativa o modo automático enquanto drena gradualmente os grupos de nós existentes e limpa os componentes de escalabilidade antigos. Ele também faz uma verificação final dos estados dos clusters após a migração.
nota
Se você precisar de backups de configuração de nós ou planeja excluir nodes/node grupos durante a migração para o Modo Automático do EKS, adicione a função do IAM criada usando o código terraform ao ConfigMap aws-auth. Sem isso, você ainda pode visualizar as configurações do grupo de nós.
Ferramentas
CLI DA AWS:
A AWS Command Line Interface (AWS CLI) é uma ferramenta de código aberto que ajuda na interação com os serviços da AWS por meio de comandos no seu shell de linha de comandos. Em nossa solução, usamos a interface de linha de comando dos serviços da AWS para executar atualizações de configuração de cluster EKS, atualizações de funções do IAM e consultar o status do cluster em todo o processo de automação.
Amazon EKS:
O Amazon Elastic Kubernetes Service (Amazon EKS) ajuda você a executar o Kubernetes na AWS sem precisar instalar e manter seus próprios nós ou ambiente de gerenciamento do Kubernetes. Nesse padrão, o Amazon EKS é o serviço de destino em que o Modo Automático está habilitado para automatizar o provisionamento computacional e a escalabilidade de nós entre clusters em uma região específica.
IAM:
O AWS Identity and Access Management (IAM) ajuda você a gerenciar com segurança o acesso aos seus recursos da AWS, controlando quem está autenticado e autorizado a usá-los. Em nossa solução, nós o usamos para gerenciar permissões para GitHub ações para modificar as configurações do cluster EKS por meio da federação OIDC. A solução também modifica as permissões da função de cluster e adiciona um trabalho para criar a função de nó EKS para que o EKS Auto Mode possa programar os pods pendentes em novos nós que ele cria como parte dos pools de nós.
Amazon S3:
O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de objetos baseado na nuvem que ajuda você a armazenar, proteger e recuperar qualquer quantidade de dados. Em nossa solução, usamos um bucket S3 para armazenar os backups com data e hora dos clusters antes que o EKS Auto Mode seja ativado neles, o que ajudaria na recuperação de desastres.
Outras ferramentas:
GitHub Ações:
GitHub Actions
HashiCorp Terraforma:
O Terraform
Repositório de código
O código desse padrão está disponível no GitHub EKS Auto Mode Enablement por meio do repositório GitHub Actions
Práticas recomendadas
Segurança:
Respeite o princípio de privilégio mínimo, garantindo somente as permissões estritamente necessárias para a execução de uma tarefa. Para obter mais informações, consulte Conceder privilégios mínimos e melhores práticas de segurança na documentação do IAM. Consulte o arquivo iam.tf
no repositório para obter a configuração mínima necessária. Defina o escopo da política de confiança da função do IAM para seu GitHub repositório e ramificação específicos para evitar que execuções de fluxo de trabalho não autorizadas assumam a função.
Ative o registro do plano de controle do EKS (servidor de API, auditoria, autenticador) antes de iniciar a migração para que você possa diagnosticar problemas de agendamento ou autenticação após a ativação do Modo Automático.
Adicione --sse AES256 a todos os comandos aws s3 cp no script de backup
para aplicar a criptografia do lado do servidor em backups do estado do cluster.
Confiabilidade:
Teste primeiro o fluxo de trabalho em um cluster que não seja de produção. Verifique se as cargas de trabalho são reprogramadas corretamente nos nós do Modo Automático antes de migrar os clusters de produção.
Verifique se os backups do S3 foram concluídos com êxito e contêm dados válidos de configuração de cluster, grupo de nós, versão do Helm e recursos personalizados antes de continuar com a ativação do Modo Automático.
Depois de ativar o Modo Automático, monitore os eventos de agendamento de pods e a latência de provisionamento de nós usando o CloudWatch Amazon Container Insights para detectar problemas com antecedência.
Desempenho:
Revise periodicamente os padrões de escalabilidade do pool de nós do Modo Automático e ajuste as solicitações e os limites de recursos da carga de trabalho para evitar excesso de provisionamento ou atrasos no agendamento.
Custos:
Marque clusters EKS e recursos associados (funções do IAM, buckets de backup do S3, sub-redes) com metadados de ambiente e propriedade para apoiar o controle de custos e a visibilidade operacional. Para obter mais informações, consulte a documentação sobre marcação de recursos da AWS. Você pode editar o arquivo do fluxo de trabalho para adicionar tags personalizadas durante o processo de migração.
Configure alertas do AWS Cost Explorer para monitorar mudanças nos custos computacionais após ativar o Modo Automático, pois o Modo Automático pode alterar os tipos de instância e o comportamento de escalabilidade. Para obter mais informações, consulte a documentação Analisando seus custos com o AWS Cost Explorer.
Operações:
Mantenha o arquivo do fluxo de trabalho e as configurações do Terraform no controle de versão e documente todas as substituições específicas do ambiente, como região, ARN da função ou nome do bucket do S3.
Épicos
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Configure o GitHub repositório. |
| AWS DevOps, arquiteto de nuvem |
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Configurar o IAM para backup e exclusão de grupos de nós |
Substitua $CLUSTER_NAME e $ACCOUNT_ID pelos valores apropriados.
Substitua $AWS_REGION e $ROLE_ARN pela região específica e pelo arn da função IAM criada acima, respectivamente. | AWS DevOps, arquiteto de nuvem |
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Acione o fluxo de trabalho de GitHub ações. | O fluxo de trabalho é acionado automaticamente quando qualquer alteração é enviada para as ramificações de recursos, principal ou de desenvolvimento. Para acionar manualmente via GitHub UI: 1. Vá para o repositório em GitHub 2. Clique na guia “Ações” 3. Selecione o fluxo de trabalho (pipeline de modo automático) 4. Clique no botão “Executar fluxo de trabalho” 5. Escolha a ramificação e clique em “Executar fluxo de trabalho” O fluxo de trabalho gerencia a verificação | AWS DevOps, arquiteto de nuvem |
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Implementação da implantação em vários ambientes. |
|
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Limpar os recursos |
| AWS geral, arquiteto de nuvem |
Solução de problemas
| Problema | Solução |
|---|---|
Problemas de autenticação | • Verifique se o provedor GitHub OIDC está configurado corretamente no AWS IAM • Verifique se o ARN da função do IAM em git secrets corresponde à função real criada com terraform () GitHubActionsEKSRole • Certifique-se de que o GitHub repositório tenha os segredos necessários configurados - AWS_REGION e. AWS_ROLE_ARN • Validar as configurações da região da AWS que correspondam às localizações do seu cluster |
Problemas de permissão | <role-arn>• Teste as permissões de funções do IAM localmente: bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters • Certifique-se de que a função tenha DescribeCluster permissões eks: UpdateClusterConfig e eks: |
Compatibilidade de clusters | <cluster-name>• Confirme se os clusters EKS estão executando o Kubernetes 1.29 ou superior: bash aws eks describe-cluster --name --query 'cluster.version' • Verifique se os clusters estão no estado ATIVO antes de ativar o Modo Automático |
falhas no fluxo de trabalho | • Verifique os registros de GitHub ações para ver mensagens de erro específicas • Verifique a sintaxe do arquivo do fluxo de trabalho em. github/workflows/auto-mode-pipeline.yml • Garantir que as variáveis de ambiente estejam definidas corretamente no fluxo de trabalho |