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 WindowsHostProcess
Podna 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
ekube-proxy
são redirecionados para o log de eventos doEKS
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çoIPv4
por causa de regraskube-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
-
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
pelo nome do cluster.eksClusterRole
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 a Função do IAM do cluster do Amazon EKS. Substitua o
pelo nome do cluster.eksClusterRole
aws iam attach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Crie um arquivo denominado
com o seguinte conteúdo:vpc-resource-controller-configmap.yaml
apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
-
Aplicar o
ConfigMap
ao seu cluster.kubectl apply -f
vpc-resource-controller-configmap.yaml
-
Verifique se seu
ConfigMap
doaws-auth
contém um mapeamento para o perfil de instância do nó Windows para incluir o grupo de permissões do RBACeks: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 seuConfigMap
ou criá-lo para incluir o grupo necessário. Para obter mais informações sobre oConfigMap
doaws-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.