Considerações Pré-requisitos Habilitar o suporte ao Windows Implantar pods do Windows Compatibilidade com uma maior densidade de pods em nós do Windows

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 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 com pods em execução nos nós do Windows.
Você não pode usar redes personalizadas 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 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 a partir da compilação do sistema operacional 17763.2746.
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 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.
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 para obter orientação.
Considerações sobre as entradas de acesso do EKS
- Se você usar outro perfil de nó do IAM para instâncias do Windows, o EKS criará automaticamente a entrada de acesso do Windows necessária.
- 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.
  
  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/<role-name> --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.

Habilitar o suporte ao Windows

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. Substitua eksClusterRole com o nome da função do cluster.


aws iam list-attached-role-policies --role-name eksClusterRole

Veja um exemplo de saída abaixo.


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

Anexe a política gerenciada AmazonEKSVPCResourceController ao seu perfil do IAM de cluster do Amazon EKS. 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
```
Atualize o ConfigMap da CNI da VPC para habilitar o IPAM do Windows:
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"
```
2. Aplicar o ConfigMap ao seu cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
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 um exemplo de saída abaixo.
```
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 ConfigMapaws-auth ao seu cluster.
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 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.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Configurar o acesso ao endpoint

Desativar o suporte ao Windows