Implantar nós do Windows em clusters do EKS - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Implantar nós do Windows em clusters do EKS

Antes de implantar nós do Windows, esteja ciente das considerações a seguir.

Considerações
  • É possível usar rede de hosts nos nós do Windows usando HostProcess Pods. Para obter mais informações, consulte Criar um 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 core 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.

  • Não é possível usar Atribuir grupos de segurança a pods individuais com Pods executados em nós do Windows.

  • Não é possível usar redes personalizadas com nós do Windows.

  • Não é possível usar IPv6 com nós do Windows.

  • Os nós do Windows são compatíveis com 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 é compatível com até 1024 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 Pods do Amazon EKS no Fargate.

  • 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 postar sua contribuição ou arquivar problemas sobre o controlador, acesse o projeto no GitHub.

  • Ao especificar uma ID de AMI personalizada para grupos de nós gerenciados do Windows, adicione eks:kube-proxy-windows ao mapa de configuração do AWS IAM Authenticator. Para ter 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.

Pré-requisitos
  • Um cluster existente. O cluster deve estar executando uma das versões do Kubernetes e versões da plataforma listadas na tabela a seguir. É compatível também com todas as versões do Kubernetes e da plataforma posteriores às versões listadas.

    Versão do Kubernetes Versão da plataforma
    1.31 eks.1
    1.30 eks.2
    1.29 eks.1
    1.28 eks.1
    1.27 eks.1
    1.26 eks.1
    1.25 eks.1
    1.24 eks.2
  • O 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 ao Windows legado, deverá usar um nó do Linux (não é possível usar um Pod do Fargate) para executar o CoreDNS.

  • Um Função do IAM do cluster do Amazon EKS existente.

Habilitar o suporte do Windows

Para habilitar o suporte ao Windows no cluster
  1. Se não houver nós do Amazon Linux no cluster e você usar grupos de segurança para Pods, pule para a próxima etapa. Caso contrário, confirme se a política gerenciada AmazonEKSVPCResourceController está anexada à função do cluster. Substitua o eksClusterRole pelo nome 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.

  2. Anexe a política gerenciada AmazonEKSVPCResourceController a Função do IAM do cluster do Amazon EKS. Substitua o eksClusterRole pelo nome do cluster.

    aws iam attach-role-policy \ --role-name eksClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
  3. Crie um arquivo denominado vpc-resource-controller-configmap.yaml com o seguinte conteúdo:

    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
  4. Aplicar o ConfigMap ao seu cluster.

    kubectl apply -f vpc-resource-controller-configmap.yaml
  5. Verifique se seu ConfigMap do aws-auth contém um mapeamento para o perfil de instância do nó Windows para incluir o grupo de permissões do RBAC eks:kube-proxy-windows. 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.

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

nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: amd64

Para Pods do Windows, use o texto do seletor de nó a seguir nos 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.

Oferecer suporte a uma maior densidade de Pod em nós do Windows

No Amazon EKS, cada Pod recebe um endereço IPv4 da sua 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 Pod em nós do Windows com a habilitação da delegação de prefixo 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, os endereços IP disponíveis não devem limitar sua capacidade de escalar o número de Pods em seus nós. Para ter mais informações, consulte Atribuir mais endereços IP aos nós do Amazon EKS com prefixos.