Criar nós Microsoft Windows autogerenciados - Amazon EKS
eksctlAWS Management Console

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Escolha o link Editar esta página no GitHub, disponível no painel direito de cada página. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Criar nós Microsoft Windows autogerenciados

Este tópico descreve como iniciar grupos do Auto Scaling de nós do Windows 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.

Importante

  • Os nós do Amazon EKS são instâncias padrão do Amazon EC2, e você é cobrado por eles com base nos preços normais das instâncias do Amazon EC2. Para obter mais informações, consulte Definição de preço do Amazon EC2.

  • Você pode iniciar nós do Windows em clusters estendidos do Amazon EKS no AWS Outposts, mas não pode iniciá-los em clusters locais no AWS Outposts. Para ter mais informações, consulte Implantar o Amazon EKS on-premises com o AWS Outposts.

Habilite o suporte ao Windows no cluster. Recomendamos revisar considerações importantes antes de iniciar um grupo de nós do Windows. Para ter mais informações, consulte Habilitar o suporte do Windows.

Você pode iniciar nós do Windows autogerenciados com uma das seguintes opções:

eksctl

Iniciar nós autogerenciados do Windows usando eksctl

Este procedimento exige que você instale o eksctl e que a versão do eksctl seja pelo menos a 0.199.0. Você pode verificar a versão com o comando a seguir.

eksctl version

Para obter instruções sobre como instalar ou atualizar o eksctl, consulte Instalação na documentação do eksctl.

nota

Este procedimento funciona apenas para clusters que foram criados com o eksctl.

  1. (Opcional) Se a política IAM gerenciada AmazonEKS_CNI_Policy (se você tiver um cluster do IPv4) ou a política AmazonEKS_CNI_IPv6_Policy (que você mesmo criou se tiver um cluster do IPv6) estiver anexada ao perfil IAM do nó do Amazon EKS, recomendamos atribuí-la a um perfil do IAM associado à conta de serviço Kubernetes aws-node. Para ter mais informações, consulte Configurar o plug-in CNI da Amazon VPC para usar IRSA.

  2. Esse procedimento pressupõe que você tem um cluster existente. Se você ainda não tiver um cluster do Amazon EKS e um grupo de nós do Amazon Linux para adicionar um grupo de nós do Windows, recomendamos que você siga Conceitos básicos do Amazon EKS: eksctl. Este guia fornece um passo a passo completo sobre como criar um cluster do Amazon EKS com nós do Amazon Linux.

    Crie seu grupo de nós com o comando a seguir. Substitua region-code pela região da AWS em que seu cluster se encontra. Substitua 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 na região da AWS e na conta da AWS em que você está criando o cluster. Substitua ng-windows por um nome para 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. Para a versão Kubernetes 1.24 ou posterior, você pode substituir 2019 por 2022 para usar o Windows Server 2022. Substitua o restante dos valores de exemplo por seus próprios valores.

    Importante

    Para implantar um grupo de nós nas sub-redes AWS Outposts, AWS Wavelength ou AWS Local Zone, não passe as sub-redes AWS Outposts, Wavelength ou Local Zone ao criar o cluster. Crie o grupo de nós com um arquivo de configuração, especificando as sub-redes AWS Outposts, Wavelength ou Local Zone. Para obter mais informações, consulte Criar um grupo de nós em um arquivo de configuração e Esquema de arquivo Config na documentação do eksctl.

    eksctl create nodegroup \
    --region region-code \
    --cluster my-cluster \
    --name ng-windows \
    --node-type t2.large \
    --nodes 3 \
    --nodes-min 1 \
    --nodes-max 4 \
    --managed=false \
    --node-ami-family WindowsServer2019FullContainer
    nota

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

  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 Pods no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.

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

AWS Management Console

Pré-requisitos

Etapa 1: Inicie nós Windows autogerenciados usando o AWS Management Console

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

  2. Abra o console do AWS CloudFormation.

  3. Selecione Criar pilha.

  4. Em Specify template, selecione Amazon S3 template URL (URL do modelo do Amazon S3).

  5. Copie a URL a seguir e cole-a no Amazon S3 URL (URL do Amazon S3).

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml

  6. Escolha Next (Avançar) duas vezes.

  7. Na página Quick create stack (Criar pilha rapidamente), insira os parâmetros a seguir de forma adequada:

    • Nome da pilha: escolha um nome para a pilha do AWS CloudFormation. Por exemplo, você pode chamá-lo de my-cluster-nodes````.

    • ClusterName: insira o nome que você usou ao criar o cluster do Amazon EKS.

      Importante

      Esse nome deve corresponder exatamente ao nome que você usou na Etapa 1: criar seu cluster do Amazon EKS. Caso contrário, seus nós não poderão ser incorporados ao cluster.

    • ClusterControlPlaneSecurityGroup: Escolha o grupo de segurança na saída do AWS CloudFormation que você gerou ao criar sua VPC. As etapas a seguir mostram um método de recuperar o grupo aplicável.

      1. Abra o console do Amazon EKS.

      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 Escolher um tipo de instância de nó do Amazon EC2 ideal.

      nota

      Os tipos de instância compatíveis com a versão mais recente do plug-in Amazon VPC CNI para Kubernetes estão listados em vpc_ip_resource_limit.go em GitHub. Talvez seja necessário atualizar a versão da CNI para usar os tipos de instâncias compatíveis mais recentes. Para ter mais informações, consulte Atribuir IPs a Pods com a CNI da Amazon VPC.

    • NodeImageIdSSMParam: preenchido com o parâmetro do Amazon EC2 Systems Manager do ID da AMI do Windows Core otimizada para Amazon EKS recomendada atualmente. Para usar a versão completa do Windows, substitua Core por Full.

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

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

    • 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, a pilha do AWS CloudFormation não será criada.

    • BootstrapArguments: especifique argumentos opcionais para passar para o script de bootstrap do nó, como argumentos kubelet adicionais usando -KubeletExtraArgs.

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

    • VpcId: selecione o ID para a VPC que você criou em .

    • NodeSecurityGroups: selecione o grupo de segurança que foi criado para o grupo de nós do Linux quando você criou a VPC. Se os nós do Linux tiverem mais de um grupo de segurança anexado a eles, especifique todos eles. Isso é importante, por exemplo, quando o grupo de nós do Linux foi criado com eksctl.

    • Subnets (Sub-redes): escolha as sub-redes que você criou. Se você criou sua VPC usando as etapas em Criar uma Amazon VPC para seu cluster do Amazon EKS, especifique apenas as sub-redes privadas dentro da VPC para que seus nós sejam iniciados.

      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 um dos modelos de VPC do Amazon EKS AWS CloudFormation ou usando eksctl, a atribuição automática de endereço IP público estará desativada 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ê está ciente das considerações e etapas adicionais em Implantar clusters privados com acesso limitado à Internet.

      • Se você selecionar as sub-redes AWS Outposts, Wavelength ou Local Zone, as sub-redes não deverão ter sido passadas quando você criou o cluster.

  8. Confirme que a pilha pode criar recursos do IAM e escolha Create stack (Criar pilha).

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

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

Etapa 2: habilite os nós para participar do cluster

  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 novas mapRoles entradas conforme necessário. Defina os valores rolearn para os valores NodeInstanceRole que você registrou no procedimento anterior.

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

    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-windows.yaml

    2. No arquivo aws-auth-cm-windows.yaml, configure os valores rolearn para os valores NodeInstanceRole aplicáveis que você registrou nos procedimentos anteriores. Você pode fazer isso com um editor de texto ou substituindo os valores de exemplo e executando o seguinte comando:

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

      • Não modifique outras linhas do arquivo.

      • Não use o mesmo perfil do IAM para nós do Windows e Linux.

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

      kubectl apply -f aws-auth-cm-windows.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 capítulo Solução de problemas.

Etapa 3: Ações adicionais

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

  2. (Opcional) Se a política IAM gerenciada AmazonEKS_CNI_Policy (se você tiver um cluster do IPv4) ou a política AmazonEKS_CNI_IPv6_Policy (que você mesmo criou se tiver um cluster do IPv6) estiver anexada ao perfil IAM do nó do Amazon EKS, recomendamos atribuí-la a um perfil do IAM associado à conta de serviço Kubernetes aws-node. Para ter mais informações, consulte Configurar o plug-in CNI da Amazon VPC para usar 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 Pods no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.

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