Lançar nós autogerenciados do Amazon Linux - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Lançar nós autogerenciados do Amazon Linux

Este tópico descreve como você pode iniciar grupos do Auto Scaling de nós do Linux que são registrados no cluster do Amazon EKS. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles. Além disso, é possível iniciar nós autogerenciados do Amazon Linux ao usar eksctl ou o AWS Management Console. Se você precisar iniciar nós no AWS Outposts, consulte Iniciar nós autogerenciados do Amazon Linux em um Outpost.

Pré-requisitos
eksctl
nota

No momento, a ferramenta eksctl não é compatível com o Amazon Linux 2023.

Pré-requisito

Versão 0.183.0 ou posterior da ferramenta da linha de comando do eksctl instalada no dispositivo ou no AWS CloudShell. Para instalar ou atualizar o eksctl, consulte Instalação na documentação do eksctl.

Para iniciar nós autogerenciados do Linux usando eksctl

  1. (Opcional) Se a política gerenciada do IAM, AmazonEKS_CNI_Policy, estiver anexada à Perfil do IAM em nós do Amazon EKS, recomendamos atribuí-la a um perfil do IAM que você associa à conta de serviço Kubernetes aws-node do Kubernetes. Para ter mais informações, consulte Configuração do Amazon VPC CNI plugin for Kubernetes a fim de usar perfis do IAM para contas de serviço (IRSA).

  2. O comando a seguir cria um grupo de nós em um cluster existente. Substitua al-nodes por um nome para o seu grupo de nós. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres. Substitua o my-cluster pelo nome do cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo dentro da Região da AWS e da Conta da AWS na qual você está criando o cluster. Substitua os valores de example value restantes pelos seus próprios valores. Os nós são criados com a mesma versão do Kubernetes que o ambiente de gerenciamento, por padrão.

    Antes de escolher um valor para --node-type, revise Escolha de um tipo de instância do Amazon EC2.

    Substituir my-key pelo nome do par de chaves do Amazon EC2 ou da chave pública. Essa chave é usada para SSH em seus nós depois que eles forem iniciados. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no AWS Management Console. Para obter mais informações, consulte Pares de chaves do Amazon EC2, no Guia do usuário do Amazon EC2.

    Crie seu grupo de nós com o comando a seguir.

    Importante

    Caso queria implantar um grupo de nós no AWS Outposts, no Wavelength ou nas sub-redes de zonas locais, há outras considerações:

    eksctl create nodegroup \
  --cluster my-cluster \
  --name al-nodes \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 4 \
  --ssh-access \
  --managed=false \
  --ssh-public-key my-key

    Para implantar um grupo de nós que:

    Para obter uma lista completa de todas as opções e padrões disponíveis, digite o comando a seguir.

    eksctl create nodegroup --help

    Se os nós não conseguirem se juntar ao cluster, consulte Worker nodes fail to join cluster (Falha nos nós ao ingressar no cluster) no manual de solução de problemas.

    Veja um exemplo de saída abaixo. Várias linhas são emitidas enquanto os nós são criados. Uma das últimas linha de saída é o exemplo de linha a seguir.

    [✔]  created 1 nodegroup(s) in cluster "my-cluster"

  3. (Opcional) Implante uma aplicação de amostra para testar o cluster e os nós do Linux.

  4. Convém bloquear o acesso para Pod ao IMDS se as condições a seguir forem verdadeiras:

    • Você planeja atribuir perfis do IAM a todas as contas de serviço do Kubernetes para que os Pods tenham apenas as permissões mínimas de que precisam.

    • Nenhum dos Pods do cluster requer acesso ao serviço de metadados de instâncias do Amazon EC2 (IMDS) por outros motivos, como recuperar a Região da AWS atual.

    Para obter mais informações, consulte Restringir o acesso ao perfil da instância atribuído ao nó de processamento.

AWS Management Console
Etapa 1: Para iniciar nós autogerenciados do Linux usando o AWS Management Console

  1. Faça download da versão mais recente do modelo AWS CloudFormation.

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml

  2. Aguarde até que o status do cluster seja exibido como ACTIVE. Se você executar os nós antes que o cluster esteja ativo, o registro dos nós no cluster falhará, e você terá de executá-los novamente.

  3. Abra o console do AWS CloudFormation em https://console.aws.amazon.com/cloudformation.

  4. Selecione Create stack (Criar pilha) e With new resources (standard) (Com novos recursos, padrão).

  5. Para Specify template (Especificar modelo), selecione Upload a template file (Fazer upload de um arquivo de modelo) e depois Choose file (Escolher arquivo).

  6. Selecione o arquivo amazon-eks-nodegroup.yaml que você baixou.

  7. Escolha Próximo.

  8. Na página Specify stack details (Especificar detalhes da pilha), insira os parâmetros de acordo e escolha Next (Próximo):

    • Stack name (Nome da pilha): escolha um nome de pilha para a pilha do AWS CloudFormation. Por exemplo, você pode chamar de my-cluster-nodes. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo dentro da Região da AWS e da Conta da AWS na qual você está criando o cluster.

    • ClusterName: insira o nome que você usou ao criar o cluster do Amazon EKS. Esse nome deve ser igual ao nome do cluster, ou seus nós não poderão ingressar no cluster.

    • ClusterControlPlaneSecurityGroup: escolha o valor de SecurityGroups no resultado do AWS CloudFormation que você gerou na criação da VPC.

      As etapas a seguir mostram uma operação para recuperar o grupo aplicável.

      1. Abra o console do Amazon EKS em https://console.aws.amazon.com/eks/home#/clusters.

      2. Escolha o nome do cluster.

      3. Escolha a guia Redes.

      4. Use o valor de Additional security group (Grupos de segurança adicionais) como referência ao selecionar na lista suspensa ClusterControlPlaneSecurityGroup.

    • NodeGroupName: insira um nome para o grupo de nós. Esse nome poderá ser usado superiormente para identificar o grupo de nós do Auto Scaling que for criado para os nós. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres.

    • NodeAutoScalingGroupMinSize: digite o número mínimo de nós para o qual o grupo Auto Scaling de nós pode ser escalado.

    • NodeAutoScalingGroupDesiredCapacity: insira o número desejado de nós para o qual dimensionar quando a pilha for criada.

    • NodeAutoScalingGroupMaxSize: digite o número máximo de nós para o qual o grupo Auto Scaling de nós pode ser escalado.

    • NodeInstanceType: escolha um tipo de instância para os nós. Para ter mais informações, consulte Escolha de um tipo de instância do Amazon EC2.

    • NodeImageIdSSMParam: pré-preenchido com o parâmetro do Amazon EC2 Systems Manager de uma AMI recente otimizada para Amazon EKS, para uma versão do Kubernetes variável. Para usar uma versão secundária diferente do Kubernetes compatível com o Amazon EKS, substitua 1.XX por uma versão diferente compatível. Recomendamos especificar a mesma versão do Kubernetes que seu cluster.

      Você também pode substituir amazon-linux-2 por um tipo de AMI diferente. Para ter mais informações, consulte IDs da AMI da AMI do Amazon Linux otimizada para Amazon EKS.

      nota

      A AMI do nó do Amazon EKS é baseada no Amazon Linux. Você pode monitorar eventos de segurança ou privacidade para o Amazon Linux 2 no Centro de segurança do Amazon Linux ou fazendo a assinatura do feed RSS associado. Os eventos de segurança e privacidade incluem uma visão geral do problema, quais pacotes são afetadas e como atualizar suas instâncias para corrigir o problema.

    • NodeImageId: (opcional) se estiver usando sua própria AMI personalizada (em vez da AMI otimizada para o Amazon EKS), insira um ID de AMI do nó para a sua Região da AWS. Se você especificar um valor aqui, ele substituirá todos os valores no campo NodeImageIdSSMParam.

    • NodeVolumeSize: especifique um tamanho de volume raiz para os nós, em GiB.

    • NodeVolumeType: especifique um tipo de volume raiz para os nós.

    • KeyName: insira o nome de um par de chaves SSH do Amazon EC2; que você pode usar para conectar-se usando SSH em seus nós, depois de iniciados. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no AWS Management Console. Para obter mais informações, consulte Pares de chaves do Amazon EC2, no Guia do usuário do Amazon EC2.

      nota

      Se você não fornecer um par de chaves aqui, ocorrerá uma falha ao criar a pilha do AWS CloudFormation.

    • BootstrapArguments: especifique argumentos opcionais para passar para o script de bootstrap do nó, como argumentos kubelet adicionais. Para obter mais informações, consulte as bootstrap script usage information (informações sobre o uso do script de boostrap) no GitHub.

      Para implantar um grupo de nós que:

    • DisableIMDSv1: por padrão, cada nó oferece suporte ao serviço de metadados de instância versão 1 (IMDSv1) e IMDSv2. Você pode desabilitar IMDSv1. Para evitar que futuros nós e Pods no grupo de nós usem MDSv1, defina DisableIMDSv1 como true. Para obter mais informações, consulte Configuring the instance metadata service (Configurar o serviço de metadados de instância). Para obter mais informações sobre como restringir o acesso a ele em seus nós, consulte Restringir o acesso ao perfil da instância atribuído ao nó de processamento.

    • VpcId: insira o ID da VPC que você criou.

    • Sub-redes: escolha as sub-redes criadas para a sua VPC. Se você criou a VPC usando as etapas descritas em Criar uma VPC para o cluster do Amazon EKS, especifique apenas as sub-redes privadas na VPC para que os nós sejam executados. É possível ver quais sub-redes são privadas abrindo cada link de sub-rede na guia Networking (Redes) do cluster.

      Importante

      • Se alguma das sub-redes for pública, ela deverá ter a atribuição automática de atribuição de endereço IP público habilitada. Se a configuração não estiver habilitada para a sub-rede pública, os nós implantados nessa sub-rede pública não receberão um endereço IP público e não poderão se comunicar com o cluster nem com outros produtos da AWS. Se a sub-rede tiver sido implantada antes de 26 de março de 2020 usando qualquer um dos modelos doAWS CloudFormation VPC para o Amazon EKS, ou usando o eksctl, a atribuição automática de endereço IP público será desabilitada para sub-redes públicas. Para obter informações sobre como habilitar a atribuição de endereço IP público para uma sub-rede, consulte Modificar o atributo de endereçamento IPv4 público para a sub-rede. Se o nó for implantado em uma sub-rede privada, ele poderá se comunicar com o cluster e com outros produtos da AWS por um gateway NAT.

      • Se as sub-redes não tiverem acesso à Internet, certifique-se de que você esteja ciente das considerações e das etapas adicionais em Requisitos de clusters privados.

      • Se você selecionou sub-redes do AWS Outposts, do Wavelength de Zonas locais, essas sub-redes não devem ter sido passadas quando você criou o cluster.

  9. Selecione as opções desejadas na página Configure stack options (Configurar opções de pilha) e depois escolha Next (Próximo).

  10. Marque a caixa de seleção à esquerda de I acknowledge that AWS CloudFormation might create IAM resources. (Reconheço que o pode criar recursos do IAM) e escolha Create stack (Criar pilha).

  11. Quando a criação da pilha for concluída, selecione-a no console e escolha Outputs (Saídas).

  12. Registre o valor de NodeInstanceRole para o grupo de nós criado. Você precisará dele ao configurar os nós do Amazon EKS.

Etapa 2: Habilitar os nós a ingressar no cluster
nota

Se você iniciou os nós dentro de uma VPC privada sem acesso de saída à Internet, certifique-se de habilitá-los para ingressar no cluster pela VPC.

  1. Verifique se você já tem um aws-auth ConfigMap.

    kubectl describe configmap -n kube-system aws-auth

  2. Se você receber um aws-auth ConfigMap, atualize-o conforme necessário.

    1. Abra o ConfigMap para edição.

      kubectl edit -n kube-system configmap/aws-auth

    2. Adicione uma nova mapRoles entrada conforme necessário. Defina o valor rolearn para o valor NodeInstanceRole que você registrou no procedimento anterior.

      [...]
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
[...]

    3. Salve o arquivo e saia do seu editor de texto.

  3. Se você recebeu um erro informando "Error from server (NotFound): configmaps "aws-auth" not found, aplique o estoqueConfigMap.

    1. Faça download do mapa de configuração.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml

    2. No arquivo aws-auth-cm.yaml, configure o valor rolearn para o valor NodeInstanceRole que você registrou no procedimento anterior. É possível fazer isso com um editor de texto ou substituindo my-node-instance-role e executando o seguinte comando:

      sed -i.bak -e 's|<ARN of instance role (not instance profile)>|my-node-instance-role|' aws-auth-cm.yaml

    3. Aplique a configuração. Esse comando pode demorar alguns minutos para ser concluído.

      kubectl apply -f aws-auth-cm.yaml

  4. Observe o status de seus nós e aguarde até que eles atinjam o status Ready.

    kubectl get nodes --watch

    Insira Ctrl+C para retornar a um prompt de shell.

    nota

    Se você receber qualquer erro de autorização ou de tipo de recurso, consulte Acesso negado ou não autorizado (kubectl) no tópico de solução de problemas.

    Se os nós não conseguirem se juntar ao cluster, consulte Worker nodes fail to join cluster (Falha nos nós ao ingressar no cluster) no manual de solução de problemas.

  5. (Somente nós de GPU) Se tiver escolhido um tipo de instância de GPU e a AMI acelerada otimizada para o Amazon EKS, você deverá aplicar o Plug-in de dispositivo NVIDIA para Kubernetes como um DaemonSet no cluster. Substitua vX.X.X pela versão desejada de NVIDIA/k8s-device-plugin antes de executar o comando a seguir.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml
Etapa 3: Ações adicionais

  1. (Opcional) Implante uma aplicação de amostra para testar o cluster e os nós do Linux.

  2. (Opcional) Se a política do IAM gerenciada AmazonEKS_CNI_Policy (se você tiver um cluster IPv4) ou a AmazonEKS_CNI_IPv6_Policy (que você mesmo criou caso tenha um cluster IPv6) estiver anexada à Perfil do IAM em nós do Amazon EKS, é recomendável atribuí-la a um perfil do IAM que você associará à conta de serviço aws-node do Kubernetes. Para ter mais informações, consulte Configuração do Amazon VPC CNI plugin for Kubernetes a fim de usar perfis do IAM para contas de serviço (IRSA).

  3. Convém bloquear o acesso para Pod ao IMDS se as condições a seguir forem verdadeiras:

    • Você planeja atribuir perfis do IAM a todas as contas de serviço do Kubernetes para que os Pods tenham apenas as permissões mínimas de que precisam.

    • Nenhum dos Pods do cluster requer acesso ao serviço de metadados de instâncias do Amazon EC2 (IMDS) por outros motivos, como recuperar a Região da AWS atual.

    Para obter mais informações, consulte Restringir o acesso ao perfil da instância atribuído ao nó de processamento.