Criar nós Microsoft Windows autogerenciados

Para 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.191.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.

1. (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 Configurar o plug-in CNI da Amazon VPC para usar IRSA.

2. Esse procedimento pressupõe que você tem um cluster existente. Caso ainda não tenha um cluster do Amazon EKS e um grupo de nós do Amazon Linux ao qual adicionar um grupo de nós do Windows, recomendamos que você siga o guia Conceitos básicos do Amazon EKS: eksctl. O guia fornece uma demonstração completa para 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 está o cluster. 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 dentro da Região da AWS e da Conta da AWS na qual você está criando o cluster. Substitua ng-windows 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. Para obter o Kubernetes versão 1.24 ou posterior, você pode substituir 2019 por 2022 para usar o Windows Server 2022. Substitua o resto dos example values pelos seus próprios valores.

   Importante

   Para implantar um grupo de nós em sub-redes do AWS Outposts, do AWS Wavelength ou de zonas locais da AWS, não passe as sub-redes do AWS Outposts, do Wavelength o de zonais locais ao criar o cluster. Crie o grupo de nós com um arquivo de configuração, especificando o AWS Outposts, o Wavelength ou sub-redes de Zonas locais. 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

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

   • Para ver as opções disponíveis para os comandos eksctl, insira o comando a seguir.

     eksctl command -help
     

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

Etapa 1: Para iniciar nós autogerenciados do Windows 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 em https://console.aws.amazon.com/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:

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

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

     Importante

     Esse nome deve corresponder exatamente ao nome usado em Etapa 1: Criar o 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 no resultado do AWS CloudFormation que você gerou na criação da VPC.

     As etapas a seguir mostram um método de 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 Escolher um tipo de instância de nó do Amazon EC2 ideal.

     nota

     Os tipos de instâncias compatíveis com a versão mais recente do Amazon VPC CNI plugin for Kubernetesestão listados em vpc_ip_resource_limit.go no 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 para o Amazon EKS), insira um ID de AMI do nó para a sua 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, 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 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 a VPC usando as etapas em Criar uma Amazon VPC para o cluster do Amazon EKS, especifique apenas as sub-redes privadas na VPC para que os nós sejam executados.

     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, esteja ciente das considerações e das etapas adicionais em Implementar clusters privados com acesso limitado à internet.

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

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: Habilitar os nós a ingressar no 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. É possível fazer isso com um editor de texto ou substituindo o example values 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 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 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 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.