Habilitar o suporte ao Windows para o cluster do Amazon EKS - Amazon EKS
Habilitar o suporte ao WindowsRemover suporte ao Windows herdadoDesabilitar o suporte ao WindowsImplantar podsHabilitar o suporte ao Windows herdadoSuporte a uma maior densidade de Pod em nós do Windows

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.

Habilitar o suporte ao Windows para o cluster do Amazon 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 Grupos de segurança do Pods 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.

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. Se a versão do cluster ou da plataforma for anterior a uma das versões a seguir, será necessário habilitar o suporte ao Windows herdado no plano de dados do cluster. Depois que o cluster estiver em uma das versões a seguir do Kubernetes e da plataforma, ou versões posteriores, será possível remover o suporte ao Windowsherdado e habilitar o suporte ao Windows no ambiente de gerenciamento.

    Versão do Kubernetes Versão da plataforma
    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 ao Windows

Se o cluster não estiver em uma das versões do Kubernetes e da plataforma listadas em Pré-requisitos, ou versões posteriores, será necessário habilitar o suporte ao Windows herdado. Para ter mais informações, consulte Habilitar o suporte ao Windows herdado.

Se você nunca habilitou o suporte ao Windows no cluster, vá para a próxima etapa.

Se você habilitou o suporte ao Windows em um cluster de uma versão anterior à versão do Kubernetes ou da plataforma listada em Prerequisites (Pré-requisitos), primeiro será necessário remover vpc-resource-controller e vpc-admission-webhook do plano de dados. Eles estão defasados e não são mais necessários.

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.

Remover o suporte ao Windows herdado do plano de dados

Se você habilitou o suporte ao Windows em um cluster de uma versão anterior à versão do Kubernetes ou da plataforma listada em Prerequisites (Pré-requisitos), primeiro será necessário remover vpc-resource-controller e vpc-admission-webhook do plano de dados. Eles estão defasados e não são mais necessários, pois a funcionalidade que forneciam agora está habilitada no ambiente de gerenciamento.

  1. Desinstale vpc-resource-controller usando o comando a seguir. Use esse comando independentemente da ferramenta com a qual tenha sido instalado originalmente. Substitua region-code (somente a instância desse texto depois de /manifests/) pela Região da AWS na qual está o cluster.

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. Desinstale o vpc-admission-webhook usando as instruções para a ferramenta com a qual você instalou.

    eksctl

    Execute os seguintes comandos.

    kubectl delete deployment -n kube-system vpc-admission-webhook
kubectl delete service -n kube-system vpc-admission-webhook
kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io vpc-admission-webhook-cfg
    kubectl on macOS or Windows

    Execute o seguinte comando . Substitua region-code (somente a instância desse texto depois de /manifests/) pela Região da AWS na qual está o cluster.

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml

  3. Habilite o suporte ao Windows para o cluster no ambiente de gerenciamento.

Desabilitar o suporte ao Windows

Para desabilitar o suporte ao Windows no cluster

  1. Se o cluster contiver nós do Amazon Linux e você usar grupos de segurança para Pods com eles, pule esta etapa.

    Remova a política do IAM AmazonVPCResourceController gerenciada da função do cluster. Substitua eksClusterRole pelo nome da função do cluster e 111122223333 pelo ID da conta.

    aws iam detach-role-policy \
    --role-name eksClusterRole \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

  2. Desabilitar Windows IPAM no ConfigMap do amazon-vpc-cni.

    kubectl patch configmap/amazon-vpc-cni \
                    -n kube-system \
                    --type merge \
                    -p '{"data":{"enable-windows-ipam":"false"}}'

Implantar pods

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.

Habilitar o suporte ao Windows herdado

Se o cluster estiver em uma das versões do Kubernetes e da plataforma listadas em Prerequisites (Pré-requisitos), ou em versões posteriores, recomendamos habilitar o suporte ao Windows no ambiente de gerenciamento. Para ter mais informações, consulte Habilitar o suporte ao Windows.

As etapas a seguir ajudam a habilitar o suporte ao Windows herdado para o plano de dados do cluster do Amazon EKS, caso a versão do cluster ou da plataforma seja anterior às versões listadas em Prerequisites (Pré-requisitos). Depois que as versões do cluster e da plataforma forem uma das versões listadas em Prerequisites (Pré-requisitos), ou versões posteriores, recomendamos remover o suporte ao Windows herdado e habilitá-lo para o ambiente de gerenciamento.

Você pode usar eksctl, um cliente do Windows ou um cliente do macOS ou Linux para habilitar o suporte ao Windows herdado para o cluster.

eksctl
Para habilitar o suporte ao Windows herdado para o cluster com eksctl
Pré-requisito

Este procedimento exige a versão eksctl 0.183.0 ou superior. Você pode verificar a versão com o comando a seguir.

eksctl version

Para obter mais informações sobre a instalação ou atualização do eksctl consulte Instalação na documentação do eksctl.

  1. Habilite o suporte ao Windows para o cluster do Amazon EKS com o comando do eksctl a seguir. Substitua o my-cluster pelo nome do cluster. Esse comando implanta o controlador de recursos da VPC e o webhook do controlador de admissão da VPC que são necessários nos clusters do Amazon EKS para executar as workloads do Windows.

    eksctl utils install-vpc-controllers --cluster my-cluster --approve
    Importante

    O webhook do controlador de admissão da VPC é assinado com um certificado que expira um ano após a data de emissão. Para evitar tempo de inatividade, certifique-se de renovar o certificado antes que ele expire. Para ter mais informações, consulte Renovar o certificado webhook de admissão da VPC.

  2. Depois de habilitar o suporte ao Windows, você pode iniciar um grupo de nós do Windows no cluster. Para ter mais informações, consulte Iniciar nós do Windows autogerenciados.

Windows
Para habilitar o suporte ao Windows herdado para o cluster com um cliente do Windows

Nas etapas a seguir, substitua region-code pela Região da AWS na qual o cluster reside.

  1. Implante o controlador de recursos da VPC em seu cluster.

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. Implante o webhook do controlador de admissão da VPC em seu cluster.

    1. Faça download dos scripts e dos arquivos de implantação necessários.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/Setup-VPCAdmissionWebhook.ps1;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.ps1;

    2. Instale o OpenSSL e o jq.

    3. Configure e implante o webhook de admissão da VPC.

      ./Setup-VPCAdmissionWebhook.ps1 -DeploymentTemplate ".\vpc-admission-webhook-deployment.yaml"
      Importante

      O webhook do controlador de admissão da VPC é assinado com um certificado que expira um ano após a data de emissão. Para evitar tempo de inatividade, certifique-se de renovar o certificado antes que ele expire. Para ter mais informações, consulte Renovar o certificado webhook de admissão da VPC.

  3. Determine se o cluster tem a vinculação de função de cluster necessária.

    kubectl get clusterrolebinding eks:kube-proxy-windows

    Se uma saída semelhante ao resultado de exemplo a seguir for retornada, o cluster terá a vinculação de função necessária.

    NAME                      AGE
eks:kube-proxy-windows    10d

    Se a saída incluir Error from server (NotFound), o cluster não tem a associação de função de cluster necessária. Adicione a vinculação criando um arquivo chamado eks-kube-proxy-windows-crb.yaml com o conteúdo a seguir.

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: eks:kube-proxy-windows
  labels:
    k8s-app: kube-proxy
    eks.amazonaws.com/component: kube-proxy
subjects:
  - kind: Group
    name: "eks:kube-proxy-windows"
roleRef:
  kind: ClusterRole
  name: system:node-proxier
  apiGroup: rbac.authorization.k8s.io

    Aplique a configuração ao cluster.

    kubectl apply -f eks-kube-proxy-windows-crb.yaml

  4. Depois de habilitar o suporte ao Windows, você pode iniciar um grupo de nós do Windows no cluster. Para ter mais informações, consulte Iniciar nós do Windows autogerenciados.

macOS and Linux
Para habilitar o suporte ao Windows herdado para seu cluster com um cliente do macOS ou Linux

Este procedimento requer que a biblioteca openssl e o processador jq JSON estejam instalados em seu sistema cliente.

Nas etapas a seguir, substitua region-code pela Região da AWS na qual o cluster reside.

  1. Implante o controlador de recursos da VPC em seu cluster.

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. Crie o manifesto webhook do controlador de admissão da VPC para seu cluster.

    1. Faça download dos scripts e dos arquivos de implantação necessários.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.sh
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml

    2. Adicione permissões aos scripts de shell para que eles possam ser executados.

      chmod +x webhook-create-signed-cert.sh webhook-patch-ca-bundle.sh

    3. Crie um segredo para comunicação segura.

      ./webhook-create-signed-cert.sh

    4. Verifique o segredo.

      kubectl get secret -n kube-system vpc-admission-webhook-certs

    5. Configure o webhook e crie um arquivo de implantação.

      cat ./vpc-admission-webhook-deployment.yaml | ./webhook-patch-ca-bundle.sh > vpc-admission-webhook.yaml

  3. Implante o webhook de admissão da VPC.

    kubectl apply -f vpc-admission-webhook.yaml
    Importante

    O webhook do controlador de admissão da VPC é assinado com um certificado que expira um ano após a data de emissão. Para evitar tempo de inatividade, certifique-se de renovar o certificado antes que ele expire. Para ter mais informações, consulte Renovar o certificado webhook de admissão da VPC.

  4. Determine se o cluster tem a vinculação de função de cluster necessária.

    kubectl get clusterrolebinding eks:kube-proxy-windows

    Se uma saída semelhante ao resultado de exemplo a seguir for retornada, o cluster terá a vinculação de função necessária.

    NAME                     ROLE                              AGE
eks:kube-proxy-windows   ClusterRole/system:node-proxier   19h

    Se a saída incluir Error from server (NotFound), o cluster não tem a associação de função de cluster necessária. Adicione a vinculação criando um arquivo chamado eks-kube-proxy-windows-crb.yaml com o conteúdo a seguir.

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: eks:kube-proxy-windows
  labels:
    k8s-app: kube-proxy
    eks.amazonaws.com/component: kube-proxy
subjects:
  - kind: Group
    name: "eks:kube-proxy-windows"
roleRef:
  kind: ClusterRole
  name: system:node-proxier
  apiGroup: rbac.authorization.k8s.io

    Aplique a configuração ao cluster.

    kubectl apply -f eks-kube-proxy-windows-crb.yaml

  5. Depois de habilitar o suporte ao Windows, você pode iniciar um grupo de nós do Windows no cluster. Para ter mais informações, consulte Iniciar nós do Windows autogerenciados.

Renovar o certificado webhook de admissão da VPC

O certificado usado pelo webhook de admissão da VPC expira um ano após a emissão. Para evitar o tempo de inatividade, é importante renovar o certificado antes que ele expire. Você pode verificar a data de validade do certificado atual com o comando a seguir.

kubectl get secret \
    -n kube-system \
    vpc-admission-webhook-certs -o json | \
    jq -r '.data."cert.pem"' | \
    base64 -decode | \
    openssl x509 \
    -noout \
    -enddate | \
    cut -d= -f2

Veja um exemplo de saída abaixo.

May 28 14:23:00 2022 GMT

Você pode renovar o certificado usando eksctl ou um computador com Windows ou Linux/macOS. Siga as instruções para a ferramenta que você usou originalmente para instalar o webhook de admissão da VPC. Por exemplo, se você instalou originalmente o webhook de admissão da VPC usando eksctl, você deverá renovar o certificado usando as instruções na guia eksctl.

eksctl

  1. Instale o certificado Substitua o my-cluster pelo nome do cluster.

    eksctl utils install-vpc-controllers -cluster my-cluster -approve

  2. Verifique se você recebe o seguinte resultado:

    2021/05/28 05:24:59 [INFO] generate received request
2021/05/28 05:24:59 [INFO] received CSR
2021/05/28 05:24:59 [INFO] generating key: rsa-2048
2021/05/28 05:24:59 [INFO] encoded CSR

  3. Reinicie a implantação do webhook.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook

  4. Se o certificado que você renovou tiver expirado e houver Pods do Windows presos no estado Container creating, será necessário excluir e reimplantar esses Pods.

Windows

  1. Obtenha o script para gerar novo certificado.

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;

  2. Prepare o parâmetro para o script.

    ./webhook-create-signed-cert.ps1 -ServiceName vpc-admission-webhook-svc -SecretName vpc-admission-webhook-certs -Namespace kube-system

  3. Reinicie a implantação do webhook.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment

  4. Se o certificado que você renovou tiver expirado e houver Pods do Windows presos no estado Container creating, será necessário excluir e reimplantar esses Pods.

Linux and macOS
Pré-requisito

Você deve ter o OpenSSL e o jq instalados em seu computador.

  1. Obtenha o script para gerar novo certificado.

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh

  2. Altere as permissões.

    chmod +x webhook-create-signed-cert.sh

  3. Executar o script.

    ./webhook-create-signed-cert.sh

  4. Reinicie o webhook.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment

  5. Se o certificado que você renovou tiver expirado e houver Pods do Windows presos no estado Container creating, será necessário excluir e reimplantar esses Pods.

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 Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2.