**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Criar nós autogerenciados do Microsoft Windows
Este tópico descreve como iniciar grupos do Auto Scaling de nós Windows que são registrados no seu 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](https://aws.amazon.com/ec2/pricing/).
É possível 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 obter mais informações, consulte [Implantar o Amazon EKS on-premises com o AWS Outposts](eks-outposts.md).
Habilite o suporte ao Windows para o cluster. Recomendamos revisar considerações importantes antes de iniciar um grupo de nós do Windows. Para obter mais informações, consulte [Habilitar o suporte ao Windows](windows-support.md#enable-windows-support).
É possível iniciar nós do autogerenciados do Windows com uma das seguintes opções:
+ [`eksctl`](#eksctl_create_windows_nodes)
+ [Console de gerenciamento da AWS](#console_create_windows_nodes)
## `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.215.0`. É possível 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](https://eksctl.io/installation) na documentação do `eksctl`.
**nota**
Este procedimento funciona apenas para clusters que foram criados com o `eksctl`.
1. (Opcional) Se a política do IAM gerenciada **AmazonEKS\$1CNI\$1Policy** (se você tiver um cluster do `IPv4`) ou a política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que você [mesmo criou](cni-iam-role.md#cni-iam-role-create-ipv6-policy) caso tenha um cluster do `IPv6`) estiver anexada ao [perfil IAM do nó do Amazon EKS](create-node-role.md), recomendamos atribuí-la a um perfil do IAM associado à conta de serviço do `aws-node` do Kubernetes. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
1. 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 ao qual adicionar um grupo de nós do Windows, recomendamos seguir [Conceitos básicos do Amazon EKS: `eksctl`](getting-started-eksctl.md). 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. É possível substituir *2019* por `2022` usar o Windows Server 2022 ou por `2025` usar o Windows Server 2025. 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](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e [Esquema de arquivo Config](https://eksctl.io/usage/schema/) 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 [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) 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"
```
1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Windows.
1. Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod 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 de instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
## Console de gerenciamento da AWS
**Pré-requisitos**
+ Um cluster existente do Amazon EKS e um grupo de nós do Linux. Se você não tiver esses recursos, recomendamos que os crie usando um de nossos guias em [Começar a usar o Amazon EKS](getting-started.md). Estes guias descrevem como criar um cluster do Amazon EKS com nós Linux.
+ Uma VPC e um grupo de segurança existentes que atendem aos requisitos de um cluster do Amazon EKS. Para obter mais informações, consulte [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md) e [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). Os guias em [Começar a usar o Amazon EKS](getting-started.md) criam uma VPC que atende aos requisitos. Como alternativa, você também pode seguir [Criar uma Amazon VPC para seu cluster do Amazon EKS](creating-a-vpc.md) para criar uma manualmente.
+ Um cluster existente do Amazon EKS que usa uma VPC e um grupo de segurança que atendam aos requisitos de um cluster do Amazon EKS. Para obter mais informações, consulte [Criar um cluster do Amazon EKS](create-cluster.md). Se você tiver sub-redes na região AWS em que AWS Outposts, AWS Wavelength ou AWS Local Zones estiverem ativados, essas sub-redes não deverão ter sido transmitidas quando você criou o cluster.
**Etapa 1: Inicie nós Windows autogerenciados usando o Console de gerenciamento da AWS **
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.
1. Abra o [console do AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Selecione **Criar pilha**.
1. Em **Specify template**, selecione **URL do modelo do Amazon S3**.
1. Copie a URL a seguir e cole-a no **URL do Amazon S3**.
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
```
1. Escolha **Next** (Avançar) duas vezes.
1. 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 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 que você usou na [Etapa 1: criar seu cluster do Amazon EKS](getting-started-console.md#eks-create-cluster). 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](creating-a-vpc.md). As etapas a seguir mostram um método de recuperar o grupo aplicável.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster.
1. Escolha a guia **Redes**.
1. 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 obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md).
**nota**
Os tipos de instâncias compatíveis com a versão mais recente do [plugin Amazon VPC CNI para o Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) estão listados em [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/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 obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).
+ **NodeImageIdSSMParam**: pré-preenchido com o parâmetro do Amazon EC2 Systems Manager do ID da principal AMI do Windows 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, será possível criar um no Console de gerenciamento da AWS. Para obter mais informações, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html), 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. É possível desabilitar IMDSv1. Para evitar que nós e pods futuros no grupo de nós usem o MDSv1, defina **DisableIMDSv1** como **true**. Para obter mais informações, consulte [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (Configurar o serviço de metadados de instância).
+ **VpcId**: selecione o ID para a [VPC](creating-a-vpc.md) 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](creating-a-vpc.md). Se os nós do Linux tiverem mais de um grupo de segurança anexado a eles, especifique todos eles. Isso serve, 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](creating-a-vpc.md), 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](creating-a-vpc.md) 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](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). 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](private-clusters.md).
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.
1. Confirme que a pilha pode criar recursos do IAM e escolha **Create stack** (Criar pilha).
1. Quando a criação da pilha for concluída, selecione-a no console e escolha **Outputs (Saídas)**.
1. Registre o valor de **NodeInstanceRole** para o grupo de nós criado. Você precisará dele ao configurar os nós de 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
```
1. 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
```
1. Adicione novas `mapRoles` entradas conforme necessário. Defina os valores `rolearn` para os valores **NodeInstanceRole** que você registrou no procedimento anterior.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows
[...]
```
1. Salve o arquivo e saia do seu editor de texto.
1. Se você recebeu um erro informando "`Error from server (NotFound): configmaps "aws-auth" not found`, aplique o estoque`ConfigMap`.
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
```
1. 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 os valores de exemplo e executando o seguinte comando:
```
sed -i.bak -e 's||my-node-linux-instance-role|' \
-e 's||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.
1. Aplique a configuração. Esse comando pode levar alguns minutos para ser concluído.
```
kubectl apply -f aws-auth-cm-windows.yaml
```
1. Observe o status de seus nós e aguarde até que eles atinjam o status `Ready`.
```
kubectl get nodes --watch
```
Insira `Ctrl`\$1`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`)](troubleshooting.md#unauthorized) no tópico de solução de problemas.
Se os nós não conseguirem se juntar ao cluster, consulte [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) no capítulo Solução de problemas.
**Etapa 3: Ações adicionais**
1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Windows.
1. (Opcional) Se a política do IAM gerenciada **AmazonEKS\$1CNI\$1Policy** (caso você tenha um cluster `IPv4`) ou *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que você [criou de forma independente](cni-iam-role.md#cni-iam-role-create-ipv6-policy), caso tenha um cluster `IPv6`) estiver anexada ao [perfil do IAM dos nós do Amazon EKS](create-node-role.md), recomendamos atribuí-la a um perfil do IAM que possa ser associado à conta de serviço do Kubernetes `aws-node`. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
1. Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod 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](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).