**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. # Implantar nós Windows em clusters EKS Saiba como habilitar e gerenciar o suporte do Windows para o cluster do Amazon EKS para executar contêineres do Windows junto com contêineres do Linux. ## Considerações Antes de implantar nós do Windows, esteja ciente das seguintes considerações: + O Modo Automático do EKS não é compatível com nós do Windows + É possível usar rede de hosts nos nós do Windows usando `HostProcess` Pods. Para obter mais informações, consulte [Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) na documentação do Kubernetes. + Os clusters do Amazon EKS devem conter um ou mais nós do Linux ou do Fargate para executar pods do sistema de núcleo que só são executados no Linux, como o CoreDNS. + Os logs de eventos do `kubelet` e `kube-proxy` são redirecionados para o log de eventos do `EKS Windows` e são definidos com um limite de 200 MB. + Você não pode usar [Atribuir grupos de segurança a pods individuais](security-groups-for-pods.md) com pods em execução nos nós do Windows. + Você não pode usar [redes personalizadas](cni-custom-network.md) com nós do Windows. + Você não pode usar `IPv6` com nós do Windows. + Os nós o Windows oferecem suporte para uma interface de rede elástica por nó. Por padrão, o número de pods que podem ser executados por nó do Windows é igual ao número de endereços IP disponíveis por interface de rede elástica para o tipo de instância do nó, menos um. Para obter mais informações, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*. + Em um cluster do Amazon EKS, um único serviço com um balanceador de carga pode ser compatível com até 1.024 pods de backend. Cada pod tem seu próprio endereço IP exclusivo. O limite anterior de 64 pods não é mais o caso, depois de uma [atualização do Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) a partir da [compilação do sistema operacional 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4). + Contêineres do Windows não são compatíveis com os pods do Amazon EKS no Fargate. + Você não pode usar os Amazon EKS Hybrid Nodes com o Windows como sistema operacional para o host. + Não é possível recuperar logs do pod `vpc-resource-controller`. Antes, era possível implantar o controlador no plano de dados. + Há um período de resfriamento antes de um endereço `IPv4` ser atribuído a um novo pod. Isso evita que o tráfego flua para um pod antigo com o mesmo endereço `IPv4` por causa de regras `kube-proxy` obsoletas. + A fonte do controlador é gerenciada no GitHub. Para contribuir ou arquivar problemas sobre o controlador, acesse o [projeto](https://github.com/aws/amazon-vpc-resource-controller-k8s) no GitHub. + Ao especificar um ID de AMI personalizado para grupos de nós gerenciados do Windows, adicione `eks:kube-proxy-windows` ao mapa de configuração do AWS IAM Authenticator. Para obter mais informações, consulte [Limites e condições ao especificar uma ID de AMI](launch-templates.md#mng-ami-id-conditions). + Se preservar os endereços IPv4 disponíveis for crucial para sua sub-rede, consulte [IP Address Management em Windows Networking no Guia de práticas recomendadas do EKS](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) para obter orientação. + Considerações sobre as entradas de acesso do EKS + As entradas de acesso para uso com os nós do Windows precisam do tipo `EC2_WINDOWS`. Para obter mais informações, consulte [Criar entradas de acesso](creating-access-entries.md). Para criar uma entrada de acesso para um nó do Windows: ``` aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows ``` ## Pré-requisitos + Um cluster existente. + Seu cluster deve ter pelo menos um (recomendamos pelo menos dois) nó do Linux ou pod do Fargate para executar o CoreDNS. Se você habilitar o suporte legado do Windows, deverá usar um nó do Linux (não é possível usar um pod do Fargate) para executar o CoreDNS. + [Perfil do IAM existente do cluster do Amazon EKS](cluster-iam-role.md). ## Habilitar o suporte ao Windows 1. Se não houver nós do Amazon Linux no cluster e você usar grupos de segurança para pods, vá para a próxima etapa. Caso contrário, confirme se a política gerenciada `AmazonEKSVPCResourceController` está anexada à [função do cluster](cluster-iam-role.md). Substitua *eksClusterRole* com o nome da função do cluster. ``` aws iam list-attached-role-policies --role-name eksClusterRole ``` Veja abaixo um exemplo de saída. ``` { "AttachedPolicies": [ { "PolicyName": "AmazonEKSClusterPolicy", "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy" }, { "PolicyName": "AmazonEKSVPCResourceController", "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController" } ] } ``` Se a política estiver anexada, como está na saída anterior, pule a próxima etapa. 1. Anexe a política gerenciada ** [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html) ** ao seu [perfil do IAM de cluster do Amazon EKS.](cluster-iam-role.md) Substitua *eksClusterRole* com o nome da função do cluster. ``` aws iam attach-role-policy \ --role-name eksClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController ``` 1. Atualize o ConfigMap da CNI da VPC para habilitar o IPAM do Windows. Observe que, se a CNI da VPC estiver instalada no seu cluster usando um chart do Helm ou como um complemento do Amazon EKS, você talvez não consiga modificar diretamente o ConfigMap. Para obter informações sobre como configurar os complementos do Amazon EKS, consulte [Determinar os campos que podem ser personalizados para os complementos do Amazon EKS](kubernetes-field-management.md). 1. Crie um arquivo chamado *vpc-resource-controller-configmap.yaml* com o conteúdo a seguir. ``` apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true" ``` 1. Aplicar o `ConfigMap` ao seu cluster. ``` kubectl apply -f vpc-resource-controller-configmap.yaml ``` 1. Se o cluster tiver o modo de autenticação definido para habilitar o configmap `aws-auth`: + Verifique se seu `ConfigMap` do `aws-auth` contém um mapeamento para o perfil de instância do nó do Windows para incluir o grupo de permissões `eks:kube-proxy-windows` do RBAC. O comando a seguir pode ser executado para verificar. ``` kubectl get configmap aws-auth -n kube-system -o yaml ``` Veja abaixo um exemplo de saída. ``` apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows # This group is required for Windows DNS resolution to work rolearn: arn:aws:iam::111122223333:role/eksNodeRole username: system:node:{{EC2PrivateDNSName}} [...] ``` Você deverá ver `eks:kube-proxy-windows` listado em grupos. Se o grupo não for especificado, será necessário atualizar seu `ConfigMap` ou criá-lo para incluir o grupo necessário. Para obter mais informações sobre o `ConfigMap` do `aws-auth`, consulte [Como aplicar o `ConfigMap` `aws-auth` ao seu cluster](auth-configmap.md#aws-auth-configmap). 1. Se o cluster tiver o modo de autenticação definido para desabilitar o configmap `aws-auth`, você poderá usar as entradas de acesso do EKS. Crie um perfil de nó para uso com instâncias do Windows, e o EKS criará automaticamente uma entrada de acesso do tipo `EC2_WINDOWS`. ## Implantar pods do Windows Para implantar pods no cluster, será necessário especificar o sistema operacional que eles usam, se você estiver executando uma mistura de tipos de nós. Para pods do Linux, use o texto do seletor de nó a seguir em seus manifestos. ``` nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: amd64 ``` Para pods do Windows, use o texto do seletor de nó a seguir em seus manifestos. ``` nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64 ``` Você pode implantar uma [aplicação de exemplo](sample-deployment.md) para ver os seletores de nós em uso. ## Compatibilidade com uma maior densidade de pods em nós do Windows No Amazon EKS, cada pod recebe um endereço `IPv4` da VPC. Como resultado, o número de pods que podem ser implantados em um nó é limitado pelos endereços IP disponíveis, mesmo que haja recursos suficientes para executar mais pods no nó. Como somente uma interface de rede elástica é aceita por cada nó do Windows, por padrão, o número máximo de endereços IP disponíveis em um nó do Windows é igual a: ``` Number of private IPv4 addresses for each interface on the node - 1 ``` Um endereço IP é usado como endereço IP principal da interface de rede, e portanto, não pode ser alocado a pods. É possível permitir uma maior densidade de pods em nós do Windows ao habilitar a delegação de prefixo de IP. Esse recurso permite atribuir um prefixo `IPv4` `/28` à interface de rede primária, em vez de atribuir endereços `IPv4` secundários. A atribuição de um prefixo IP aumenta o número máximo de endereços `IPv4` disponíveis no nó para: ``` (Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16 ``` Com esse número significativamente maior de endereços IP disponíveis, eles não limitarão sua capacidade de escalar o número de pods em seus nós. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md).