Criar um grupo de nós gerenciados - 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.

Criar um grupo de nós gerenciados

Este tópico descreve como iniciar grupos de nós gerenciados do Amazon EKS com nós registrados no cluster do Amazon EKS. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles.

Se for a primeira vez que você executa um grupo de nós gerenciados do Amazon EKS, recomendamos seguir um dos nossos guias Conceitos básicos do Amazon EKS. Os manuais fornecem demonstrações para criar um cluster do Amazon EKS com os nós.

Importante
Pré-requisitos

Você pode criar um grupo de nós gerenciados com o eksctl ou o AWS Management Console.

eksctl
Para criar um grupo de nós gerenciados com eksctl.

Este procedimento exige a versão eksctl 0.183.0 ou superior. Você pode verificar a versão com o seguinte comando:

eksctl version

Para obter instruções sobre como instalar ou atualizar o eksctl, consulte Instalação na documentação do 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. Crie o grupo de nós com ou sem o uso de um modelo de execução personalizado. A especificação manual de um modelo de lançamento permite uma maior personalização de um grupo de nós. Por exemplo, pode permitir a implantação de uma AMI personalizada ou fornecer argumentos para o script de boostrap.sh em uma AMI otimizada do Amazon EKS. Para obter uma lista completa de todas as opções e padrões disponíveis, insira o comando a seguir.

    eksctl create nodegroup --help

    No comando a seguir, substitua my-cluster pelo nome do cluster e substitua my-mng pelo nome do 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.

    Importante

    Se você não usar um modelo de execução personalizado ao criar um grupo de nós gerenciados, não use um superiormente para o grupo de nós. Se você não especificou um modelo de execução personalizado, o sistema gerará automaticamente um modelo de execução que não é recomendável alterar manualmente. Modificar manualmente esse modelo de execução gerado poderá causar erros automaticamente.

    Sem um modelo de inicialização

    O eksctl cria um modelo de inicialização padrão do Amazon EC2 na sua conta e implanta o grupo de nós usando um modelo de inicialização que ele criou baseado nas opções que você especifica. Antes de especificar um valor para --node-type, consulte Escolha de um tipo de instância do Amazon EC2.

    Substitua ami-family por uma palavra-chave permitida. Para obter mais informações, consulte Setting the node AMI Family (Configurar a família de AMIs de nós) na documentação do eksctl. 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.

    nota

    No Windows, esse comando não habilita o SSH. Em vez disso, ele associa seu par de chaves do Amazon EC2 à instância e permite que você faça RDP na instância.

    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 sobre o Linux, consulte Pares de chaves do Amazon EC2 e instâncias do Linux no Guia do usuário do Amazon EC2. Para obter mais informações sobre o Windows, consulte Pares de chaves do Amazon EC2 e instâncias do Windows no Guia do usuário do Amazon EC2.

    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.

    Se você quiser bloquear o acesso do Pod ao IMDS, adicione a opção --disable-pod-imds ao comando a seguir.

    eksctl create nodegroup \ --cluster my-cluster \ --region region-code \ --name my-mng \ --node-ami-family ami-family \ --node-type m5.large \ --nodes 3 \ --nodes-min 2 \ --nodes-max 4 \ --ssh-access \ --ssh-public-key my-key

    As instâncias podem atribuir um número significativamente maior de endereços IP aos Pods, atribuir endereços IP aos Pods de um bloco CIDR diferente do bloco CIDR da instância e ser implantadas em um cluster sem acesso à Internet. Para obter mais informações, consulte Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2, Rede personalizada para pods, e consulte Requisitos de clusters privados para obter opções adicionais a serem incluídas no comando anterior.

    Os grupos de nós gerenciados calculam e aplicam um único valor para o número máximo de Pods que podem ser executados em cada nó do grupo de nós, com base no tipo de instância. Se você criar um grupo de nós com diferentes tipos de instância, o menor valor calculado em todos os tipos de instância será aplicado como o número máximo de Pods que podem ser executados em cada tipo de instância no grupo de nós. Grupos de nós gerenciados calculam o valor usando o script referenciado em Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2.

    Com um modelo de inicialização

    O modelo de inicialização já deve existir e deve atender aos requisitos especificados em Conceitos básicos do modelo de execução.

    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.

    Se você quiser bloquear o acesso do Pod ao IMDS, especifique as configurações necessárias no modelo de execução.

    1. Copie o conteúdo a seguir para o seu dispositivo. Substitua o example values e, em seguida, execute o comando modificado para criar o arquivo eks-nodegroup.yaml. Várias configurações que você especifica ao implantar sem um modelo de execução são movidas para o modelo de execução. Se você não especificar a version, a versão padrão do modelo será usada.

      cat >eks-nodegroup.yaml <<EOF apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-mng launchTemplate: id: lt-id version: "1" EOF

      Para obter uma lista completa de configurações eksctl do arquivo de configurações, consulte Config file schema (Esquema do arquivo de configurações) na documentação do eksctl As instâncias podem, opcionalmente, atribuir um número significativamente maior de endereços IP aos Pods, atribuir endereços IP a Pods de um bloco CIDR diferente do bloco CIDR da instância, usar o runtime do containerd e ser implantadas em um cluster sem acesso externo à Internet. Para obter mais informações, consulte Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2, Rede personalizada para pods e Teste a migração do Docker para containerd e consulte Requisitos de clusters privados para obter opções adicionais a serem adicionadas ao arquivo de configurações.

      Se você não especificou um ID de AMI no modelo de lançamento, os grupos de nós gerenciados calculam e aplicam um único valor para o número máximo de Pods que podem ser executados em cada nó do grupo de nós, com base no tipo de instância. Se você criar um grupo de nós com diferentes tipos de instância, o menor valor calculado em todos os tipos de instância será aplicado como o número máximo de Pods que podem ser executados em cada tipo de instância no grupo de nós. Grupos de nós gerenciados calculam o valor usando o script referenciado em Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2.

      Se você especificou um ID de AMI no modelo de inicialização, especifique o número máximo de Pods que podem ser executados em cada nó do grupo de nós, se você estiver usando redes personalizadas ou se quiser aumentar o número de endereços IP atribuídos à instância. Para ter mais informações, consulte Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2.

    2. Implante o grupo de nós com o comando a seguir.

      eksctl create nodegroup --config-file eks-nodegroup.yaml
AWS Management Console
Para criar um grupo de nós gerenciados usando o AWS Management Console
  1. Aguarde até que o status do cluster seja exibido como ACTIVE. Não é possível criar um grupo de nós gerenciados para um cluster que ainda não esteja ACTIVE.

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

  3. Escolha o nome do cluster em que você deseja criar um grupo de nós gerenciados.

  4. Selecione a guia Compute (Computação).

  5. Escolha Add Node Group (Adicionar grupo de nós).

  6. Na página Configure node group (Configurar o grupo de nós) preencha os parâmetros adequadamente e escolha Next (Próximo).

    • Name (Nome) – Insira um nome exclusivo para o grupo de nós gerenciados. 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.

    • Node IAM role (Perfil do IAM do nó): escolha a função da instância do nó a ser usada com o grupo de nós. Para ter mais informações, consulte Perfil do IAM em nós do Amazon EKS.

      Importante
      • Não é possível usar o mesmo perfil usado para criar clusters.

      • Recomendamos usar uma função que não esteja em uso atualmente por um grupo de nós autogerenciados. Caso contrário, planeje usar com um novo grupo de nós autogerenciados. Para ter mais informações, consulte Excluir um grupo de nós gerenciados.

    • Usar: (opcional) escolha se deseja usar um modelo de execução existente. Selecione um Nome de modelo de inicialização. Depois, selecione Launch template version (Versão do modelo de inicialização). Se você não selecionar uma versão, o Amazon EKS usará a versão padrão do modelo. Os modelos de inicialização permitem uma maior personalização do grupo de nós, por exemplo, permitem que você implante uma AMI personalizada, atribua um número significativamente maior de endereços IP aos Pods, atribua endereços IP a Pods de um bloco CIDR diferente do bloco da instância, habilite o runtime do containerd para as instâncias, e também que implante nós em um cluster sem acesso de saída à Internet. Para obter mais informações, consulte Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2, Rede personalizada para pods, Teste a migração do Docker para containerd e Requisitos de clusters privados.

      O modelo de execução deve cumprir os requisitos do Como personalizar nós gerenciados com modelos de execução. Se você não usar seu próprio modelo de execução, a API do Amazon EKS criará um modelo de execução padrão do Amazon EC2 em sua conta e implantará o grupo de nós usando o modelo de execução padrão.

      Se você implementar Perfis do IAM para contas de serviço, atribua as permissões necessárias diretamente a todos os Pod que precisem ter acesso aos serviços da AWS, e nenhum Pods no cluster exigirá acesso ao IMDS por outros motivos, como recuperar a Região da AWS atual, depois, você também poderá desabilitar o acesso ao IMDS para Pods que não usam redes de host em um modelo de inicialização. Para obter mais informações, consulte Restringir o acesso ao perfil da instância atribuído ao nó de processamento.

    • Rótulos do Kubernetes: (Opcional) Você pode optar por aplicar rótulos do Kubernetes aos nós no grupo de nós gerenciados.

    • Kubernetes taints: (Opcional) É possível aplicar Kubernetes taints aos nós do seu grupo de nós gerenciados. As opções disponíveis naAs opções disponíveis no menu Effect (Efeito) são NoSchedule, NoExecute e PreferNoSchedule. Para ter mais informações, consulte Taints de nós em grupos de nós gerenciados.

    • Etiquetas – (Opcional) você pode optar por aplicar etiquetas ao grupo de nós gerenciados pelo Amazon EKS. Essas etiquetas não se propagam para outros recursos no grupo de nós, como instâncias ou grupos do Auto Scaling. Para ter mais informações, consulte Marcar os recursos do Amazon EKS.

  7. Na página Set compute and scaling configuration (Definir configuração de escalabilidade e computação), preencha os parâmetros adequadamente e escolha Next (Próximo).

    • AMI type (Tipo de AMI): selecione um tipo de AMI. Se estiver implantando instâncias Arm, não deixe de revisar as considerações em AMIs Amazon Linux Arm otimizadas para Amazon EKS antes de implantar..

      Se você especificou um modelo de inicialização na página anterior e especificou nele uma AMI, não poderá selecionar um valor. O valor do modelo é exibido. A AMI especificada no modelo deve atender aos requisitos em Especificar uma AMI.

    • Tipo de capacidade – Selecione um tipo de capacidade. Para obter mais informações sobre a escolha de um tipo de capacidade, consulte Tipos de capacidade do grupo de nós gerenciados. Não é possível misturar diferentes tipos de capacidade dentro do mesmo grupo de nós. Se você quiser usar os dois tipos de capacidade, crie grupos de nós separados, cada um com seus próprios tipos de capacidade e instância.

    • Tipos de instância: por padrão, um ou mais tipos de instância são especificados. Para remover um tipo de instância padrão, selecione a caixa de seleção X no lado direito do tipo de instância. Escolha o tipo de instância a ser usado no grupo de nós gerenciados. Para ter mais informações, consulte Escolha de um tipo de instância do Amazon EC2.

      O console exibe um conjunto de tipos de instância comumente usados. Se você precisar criar um grupo de nós gerenciados com um tipo de instância que não é exibido, use eksctl, a AWS CLI, o AWS CloudFormation ou um SDK para criar o grupo de nós. Se você especificou um modelo de execução na página anterior, não será possível selecionar um valor, porque o tipo de instância deve ser especificado no modelo de execução. O valor do modelo de execução é exibido. Se você selecionou Spot para o Tipo de capacidade, recomendamos especificar vários tipos de instância para melhorar a disponibilidade.

    • Tamanho do disco – Insira o tamanho do disco (em GiB) a ser usado para o volume raiz do nó.

      Se você especificou um modelo de execução na página anterior, não será possível selecionar um valor, porque ele deverá ser especificado no modelo de execução.

    • Tamanho desejado – Especifique o número atual de nós que o grupo de nós gerenciados deverá manter na inicialização.

      nota

      O Amazon EKS não reduz nem aumenta automaticamente a escala na horizontal do grupo de nós. No entanto, você pode configurar o Kubernetes Cluster Autoscaler para fazer isso por você.

    • Tamanho mínimo – Especifique o número mínimo de nós para o qual o grupo de nós gerenciados pode ser reduzido.

    • Tamanho máximo – Especifique o número máximo de nós para o qual o grupo de nós gerenciados pode ser expandido.

    • Configuração da atualização de grupo de nós – (Opcional) Você pode selecionar o número ou porcentagem de nós a serem atualizados em paralelo. Esses nós estarão indisponíveis durante a atualização. Para o Máximo disponível, selecione uma das seguintes opções e especifique um Valor:

      • Number (Número): selecione e especifique o número de nós em seu grupo de nós que podem ser atualizados em paralelo.

      • Percentage (Porcentagem): selecione e especifique a porcentagem de nós em seu grupo de nós que podem ser atualizados em paralelo. Isso será útil se você tiver um grande número de nós em seu grupo de nós.

  8. Na página Specify networking (Especificar a rede), preencha os parâmetros conforme necessário e, em seguida, escolha Next (Próximo).

    • Sub-redes – Escolha as sub-redes nas quais iniciar os nós gerenciados.

      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 Autoescalabilidade, 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.

      Importante
      • Se você escolher uma sub-rede pública e o cluster tiver somente o endpoint do servidor de API público habilitado, a sub-rede deverá ter o MapPublicIPOnLaunch definido como true para que as instâncias ingressem com êxito em um cluster. Se a sub-rede 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 foram criadas com modelos do eksctl ou AWS CloudFormation 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.

      • Se você usar um modelo de execução e especificar várias interfaces de rede, o Amazon EC2 não atribuirá automaticamente um endereço IPv4 público, mesmo que o MapPublicIpOnLaunch seja definido como true. Para que os nós ingressem no cluster nesse cenário, você deve habilitar o endpoint do servidor de API privado do cluster ou iniciar nós em uma sub-rede privada com acesso de saída à Internet fornecido por meio de um método alternativo, como um Gateway NAT. Para obter mais informações, consulte Endereçamento de IP de instâncias do Amazon EC2, no Guia do Usuário do Amazon EC2.

    • Configurar o acesso SSH aos nós (opcional). Habilitar o SSH permite que você se conecte às suas instâncias e reúna informações de diagnóstico quando houver problemas. É altamente recomendado habilitar o acesso remoto ao criar o grupo de nós. Não será possível habilitar o acesso remoto depois que o grupo estiver criado.

      Se você optou por usar um modelo de execução, essa opção não será exibida. Para habilitar o acesso remoto aos nós, especifique um par de chaves no modelo de execução e verifique se a porta adequada está aberta aos nós nos grupos de segurança especificados no modelo de execução. Para ter mais informações, consulte Usar grupos de segurança personalizados.

      nota

      No Windows, esse comando não habilita o SSH. Em vez disso, ele associa seu par de chaves do Amazon EC2 à instância e permite que você faça RDP na instância.

    • Para o par de chaves SSH (Opcional), escolha uma chave SSH do Amazon EC2 para usar. Para obter mais informações sobre o Linux, consulte Pares de chaves do Amazon EC2 e instâncias do Linux no Guia do usuário do Amazon EC2. Para obter mais informações sobre o Windows, consulte Pares de chaves do Amazon EC2 e instâncias do Windows no Guia do usuário do Amazon EC2. Se você optar por usar um modelo de execução, não será possível selecionar um. Quando uma chave SSH do Amazon EC2 é fornecida para grupos de nós que usam AMIs Bottlerocket, o contêiner administrativo também é habilitado. Para obter mais informações, consulte Admin container(Contêiner administrador) no GitHub.

    • Para Allow SSH remote access from (Permitir o acesso remoto de SSH) se você quiser limitar o acesso a instâncias específicas, selecione os grupos de segurança associados a essas instâncias. Se você não selecionar grupos de segurança específicos, o acesso SSH será permitido de qualquer lugar na Internet (0.0.0.0/0).

  9. Na página Review and create (Revisar e criar), reveja a configuração do grupo de nós gerenciados e escolha Create (Criar).

    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.

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

    kubectl get nodes --watch
  11. (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

Agora que você tem um cluster do Amazon EKS com nós, já poderá iniciar a instalação dos complementos do Kubernetes e implantar as aplicações no cluster. Os seguintes tópicos de documentação ajudam a estender a funcionalidade do seu cluster:

  • A entidade principal do IAM que criou o cluster é a única entidade que pode fazer chamadas ao servidor da API do Kubernetes usando kubectl ou o AWS Management Console. Se quiser que outras entidades principais do IAM tenham acesso ao cluster, será necessário adicioná-los. Para obter mais informações, consulte Conceder acesso a APIs do Kubernetes e Permissões obrigatórias.

  • 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.

  • Autoescalabilidade: configure o Kubernetes Cluster Autoscaler para ajustar automaticamente o número de nós nos grupos de nós.

  • Implante uma aplicação de exemplo no cluster.

  • Gerenciamento de clusters – Saiba como usar ferramentas importantes para gerenciar o cluster.