Criar uma classe de nó para o Amazon EKS

As classes de nós do Amazon EKS são modelos que fornecem controle granular sobre a configuração dos nós gerenciados pelo Modo automático do EKS. Uma classe de nó define as configurações no nível de infraestrutura que se aplicam a grupos de nós no cluster de EKS, incluindo configuração de rede, configurações de armazenamento e marcação de recursos. Este tópico explica como criar e configurar uma classe de nó para atender aos requisitos operacionais específicos.

Quando você precisa personalizar como o Modo automático do EKS provisiona e configura instâncias do EC2 além das configurações padrão, a criação de uma classe de nó oferece controle preciso sobre os parâmetros críticos da infraestrutura. Por exemplo, você pode especificar o posicionamento em sub-rede privada para aumentar a segurança, configurar o armazenamento efêmero da instância para workloads sensíveis à performance ou aplicar marcações personalizadas para alocação de custos.

Considerações sobre workloads esparsas em pods ou de alta escala

O Modo automático do EKS usa delegação de prefixo (prefixos /28) por padrão. Cada nó reserva 16 IPs de pod, o que é eficiente para workloads densas que preenchem esses slots. Para workloads esparsas em pods (alguns pods por nó, comuns em workloads de ML ou GPU, ou workloads com alta antiafinidade) que visam mais do que algumas centenas de nós por zona de disponibilidade, o modo IP secundário ("32") é uma configuração mais otimizada. Ele aloca um IP por pod em vez de reservar 16 por nó, o que amplia a capacidade efetiva das sub-redes do pod /20.

Para obter mais informações, consulte Modo de IP secundário para pods. Para manter os pods em uma sub-rede separada dos nós (independente do modo de alocação), consulte Sub-redes e grupos de segurança separados para Pods.

Criar uma classe de nó

Para criar um NodeClass, siga estas etapas:

1. Criar um arquivo YAML (por exemplo, nodeclass.yaml) com sua configuração de classe de nó

2. Aplicar a configuração ao cluster usando o kubectl

3. Faça referência à classe de nó na configuração do grupo de nós. Para obter mais informações, consulte Criar um grupo de nós para o Modo Automático do EKS.

Você precisa ter o kubectl instalado e configurado. Para obter mais informações, consulte Configurar para usar o Amazon EKS.

Exemplo básico de classe de nó

Veja a seguir um exemplo de classe de nó:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

Essa NodeClass aumenta a quantidade de armazenamento efêmero no nó.

Aplique essa configuração usando:

kubectl apply -f nodeclass.yaml

Em seguida, faça referência à classe de nó na configuração do grupo de nós. Para obter mais informações, consulte Criar um grupo de nós para o Modo Automático do EKS.

Criar entrada de acesso de classe de nós

Se você criar uma classe de nós personalizada, precisará criar uma entrada de acesso do EKS para permitir que os nós se juntem ao cluster. O EKS cria automaticamente entradas de acesso quando você usa a classe de nós e os pools de nós integrados.

Para obter informações sobre como as entradas de acesso funcionam, consulte Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS.

Ao criar entradas de acesso para as classes de nós do Modo automático do EKS, você precisa usar o tipo de entrada de acesso do EC2.

Criar entrada de acesso com a CLI

Para criar uma entrada de acesso para os nós do EC2 e associar a política de nós automáticos do EKS:

Atualize os comandos da CLI a seguir com o nome do cluster e o ARN do perfil do nó. O ARN do perfil de nó é especificado no YAML da classe de nós.

# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

Criar entrada de acesso com o CloudFormation

Para criar uma entrada de acesso para os nós do EC2 e associar a política de nós automáticos do EKS:

Atualize o CloudFormation a seguir com o nome do cluster e o ARN do perfil do nó. O ARN do perfil de nó é especificado no YAML da classe de nós.

EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Para obter informações sobre a implantação de pilhas do CloudFormation, consulte Conceitos básicos do CloudFormation

Especificação das classes de nós

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws:kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

    # Optional: Static network interface configuration for EFA workloads
    networkInterfaces:
      # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface
      # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4Count: 10
    - deviceIndex: 1
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

Considerações

• Se você quiser verificar a quantidade de armazenamento local de uma instância, é possível descrever o nó para ver o recurso de armazenamento efêmero.

• Criptografia de volume: o EKS usa a chave do KMS personalizada configurada para criptografar o volume raiz somente leitura da instância e o volume de dados de leitura/gravação.

• Substituir o perfil do IAM do nó: caso altere o perfil do IAM do nó associado a um NodeClass, você precisará criar uma nova entrada de acesso. O EKS cria automaticamente uma entrada de acesso para o perfil do IAM do nó durante a criação do cluster. O perfil do IAM do nó requer a política de acesso AmazonEKSAutoNodePolicy do EKS. Para obter mais informações, consulte Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS.

• Densidade máxima dos pods: o EKS limita o número máximo de pods em um nó a 110. Esse limite é aplicado após o cálculo do máximo de pods existentes. Para obter mais informações, consulte Escolher um tipo de instância de nó do Amazon EC2 ideal.

• Tags: caso queira propagar tags do Kubernetes para o EC2, você precisará configurar permissões adicionais do IAM. Para obter mais informações, consulte Saber mais sobre identidade e acesso no Modo Automático do EKS.

• Classe de nó padrão: não nomeie sua classe de nó personalizada default. Isso ocorre porque o Modo automático do EKS inclui um NodeClass denominado default que é provisionado automaticamente quando você habilita pelo menos um NodePool integrado. Para obter informações sobre como habilitar NodePools integrados, consulte Habilitar ou desabilitar NodePools integrados.

• Comportamento dos subnetSelectorTerms com várias sub-redes: se houver várias sub-redes que correspondam às condições dos subnetSelectorTerms ou que você forneça por ID, o Modo automático do EKS criará nós distribuídos pelas sub-redes.

  • Se as sub-redes estiverem em zonas de disponibilidade (AZ) diferentes, será possível usar recursos do Kubernetes, como Restrições de distribuição da topologia de pods e Roteamento com reconhecimento de topologia, para distribuir os pods e o tráfego pelas zonas, respectivamente.

  • Se houver várias sub-redes na mesma AZ que correspondam aos subnetSelectorTerms, o Modo automático do EKS criará pods em cada nó distribuídos pelas sub-redes nessa AZ. O Modo automático do EKS cria interfaces de rede secundárias em cada nó nas outras sub-redes na mesma AZ. Ele escolhe com base no número de endereços IP disponíveis em cada sub-rede para usar as sub-redes com mais eficiência. No entanto, você não pode especificar qual sub-rede o Modo automático do EKS usará para cada pod; se você precisar que os pods sejam executados em sub-redes específicas, então use o Sub-redes e grupos de segurança separados para Pods.

• Restrições relacionadas à estratégia de grupos de posicionamento: cada estratégia de grupo de posicionamento (por exemplo, cluster, partição e distribuição) conta com limitações específicas quanto aos tipos de instância, às zonas de disponibilidade (AZs, na sigla em inglês) e à capacidade. Para obter mais detalhes, consulte Estratégias de grupos de posicionamento no Guia do usuário do Amazon EC2.

• Grupo com posicionamento distribuído (limite de sete instâncias): um grupo com posicionamento distribuído em nível de rack permite, no máximo, sete instâncias ativas por zona de disponibilidade em cada grupo. Isso cria os seguintes cenários de exceção:

  • Substituição por desvio bloqueada por capacidade máxima: o Modo Automático do EKS inicia um nó de substituição antes de encerrar o nó antigo. Quando um grupo com posicionamento distribuído atinge sete instâncias em uma zona de disponibilidade, a tentativa de iniciar a instância de substituição falha, e o nó com desvio permanece em execução até que um espaço seja liberado.

  • Todas as AZs estão com capacidade máxima: se cada zona de disponibilidade no grupo com posicionamento distribuído atingir o limite de sete instâncias, não será possível agendar substituições. Nós com desvio ou candidatos à consolidação continuam em execução por tempo indeterminado.

  • Sem alternativas externas ao grupo de posicionamento: o Modo Automático do EKS não tenta iniciar instâncias de substituição fora do grupo de posicionamento.

  • Solução alternativa: use a política de consolidação WhenEmpty (consolidationPolicy: WhenEmpty). A exclusão dos nós ocorre apenas após a drenagem de todos os pods, exceto os do DaemonSet. Isso libera uma vaga no grupo de posicionamento imediatamente, eliminando a necessidade de iniciar uma substituição prévia. Observe que o desvio sempre usa a substituição seguida de exclusão, independentemente da política de consolidação, de modo que o desvio permanece bloqueado na capacidade máxima.

• Vinculação da zona de disponibilidade de um grupo de posicionamento de cluster: assim que a primeira instância é iniciada em um grupo de posicionamento de cluster, o grupo de posicionamento fica vinculado a essa zona de disponibilidade. Se o NodePool permitir várias zonas de disponibilidade, as inicializações paralelas durante o aumento vertical da escala inicial podem entrar em conflito: um deles tem sucesso e vincula a zona de disponibilidade, enquanto os outros falham com erros de capacidade. Vincule a zona de disponibilidade nos requisitos do NodePool para evitar falhas temporárias.

• Grupo com posicionamento em partições: os grupos com posicionamento em partições são compatíveis sem restrições adicionais além dos limites padrão do EC2.

• Processo de consolidação com possibilidade de mover pods para fora de um grupo de posicionamento: isso ocorre quando o pod não possui restrições específicas de agendamento relacionadas ao grupo de posicionamento, como o nodeSelector para eks.amazonaws.com/placement-group-id, permitindo que ele seja migrado para um nó externo ao grupo. As aplicações que requerem associação a um grupo de posicionamento devem expressar isso por meio de restrições no nível do pod.

• Grupo de posicionamento inexistente ou excluído: se um NodeClass referenciar um grupo de posicionamento que não existe ou foi excluído, nenhuma instância será iniciada. O formato do ID do grupo de posicionamento é validado no momento da admissão, mas sua existência real só é verificada no momento da inicialização. Se um grupo de posicionamento for excluído enquanto os nós estiverem ativos, os nós existentes serão marcados como com desvios e continuarão em execução por tempo indeterminado, já que as inicializações para substituição por desvio também são bloqueadas.

• Hugepages: para obter informações sobre como configurar hugepages em nós, consulte Configurar hugepages em nós.

• Configurações do Kubelet: para obter informações sobre como substituir as configurações do Kubelet, como densidade de pods, limites de despejo e rotação de logs, consulte Defina as configurações do kubelet nos nós.

• sysctls do Kernel: para obter informações sobre como configurar sysctls do kernel em nós, consulte Configurar sysctls do kernel nos nós.

Sub-redes e grupos de segurança separados para Pods

Os campos podSubnetSelectorTerms e podSecurityGroupSelectorTerms permitem configurações avançadas de rede, possibilitando que os pods sejam executados em sub-redes e grupos de segurança diferentes de seus nós. Os dois campos devem ser especificados juntos. Essa separação fornece controle aprimorado do roteamento do tráfego de rede e das políticas de segurança.

nota

Esse atributo difere do atributo Grupos de segurança para pods (SGPP) usado com a CNI da VPC para computação não no Modo Automático do EKS. O SGPP não é compatível com o Modo automático do EKS. Em vez disso, use podSecurityGroupSelectorTerms no NodeClass para aplicar grupos de segurança distintos ao tráfego do Pod. Os grupos de segurança se aplicam no nível NodeClass, ou seja, todos os pods nos nós que os usam NodeClass compartilham os mesmos grupos de segurança do pod.

Como funciona

Quando você configura podSubnetSelectorTerms e podSecurityGroupSelectorTerms:

1. A ENI primária do nó usa as sub-redes e os grupos de segurança de subnetSelectorTerms e securityGroupSelectorTerms. Apenas o endereço IP do próprio nó é atribuído a esta interface.

2. O Modo Automático do EKS cria ENIs secundárias nas sub-redes correspondentes a podSubnetSelectorTerms, com os grupos de segurança de podSecurityGroupSelectorTerms associados. Os endereços IP dos pods são atribuídos a partir dessas ENIs secundárias usando prefixos /28 por padrão, com recurso automático para IPs secundárias (/32) quando não há um bloco de prefixos contíguo disponível. Se ipv4PrefixSize estiver definido como "32" em advancedNetworking, somente IPs secundários serão usados.

3. Os grupos de segurança especificados em podSecurityGroupSelectorTerms aplicam-se ao tráfego de pod na VPC. Para o tráfego destinado a destinos fora da VPC, os Pods utilizam a ENI primária do nó (e seus grupos de segurança), pois a tradução de endereços de rede de origem (SNAT) converte o IP do Pod para o IP do nó. Você pode modificar esse comportamento com o campo snatPolicy no NodeClass.

Casos de uso

Use podSubnetSelectorTerms e podSecurityGroupSelectorTerms quando você precisar:

• Aplicar diferentes grupos de segurança para controlar o tráfego de nós e pods separadamente.

• Separar o tráfego de infraestrutura (comunicação de nó a nó) do tráfego de aplicações (comunicação de pod a pod).

• Aplicar configurações de rede diferentes às sub-redes de nós e às sub-redes de pods.

• Configurar proxies reversos ou filtragem de rede especificamente para o tráfego de nós sem afetar o tráfego de pods. Use advancedNetworking e certificateBundles para definir seu proxy reverso e quaisquer certificados autoassinados ou privados para o proxy.

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

Considerações sobre sub-redes e grupos de segurança separados para Pods

• Escopo do grupo de segurança: os grupos de segurança de podSecurityGroupSelectorTerms são anexados às ENIs secundárias e se aplicam ao tráfego de pod dentro da VPC. Quando o SNAT está habilitado (o padrão snatPolicy: Random), o tráfego que sai da VPC é redirecionado para o endereço IP da ENI primária do nó; assim, os grupos de segurança do nó de securityGroupSelectorTerms passam a ser aplicados a esse tráfego. Se você definir snatPolicy: Disabled, os Pods usarão seus próprios endereços IP para todo o tráfego, e você deverá garantir que o roteamento e os grupos de segurança estejam configurados adequadamente.

• Granularidade no nível da NodeClass: Os grupos de segurança de Pods se aplicam a todos os Pods agendados nos nós usando o NodeClass. Para aplicar diferentes grupos de segurança a diferentes workloads, crie recursos NodeClass e NodePool separados e utilize taints, tolerações ou seletores de nó para agendar as workloads nos nós apropriados.

• Densidade reduzida de pods: é possível executar menos Pods em cada nó, pois a interface de rede principal do nó é reservada para o endereço IP do próprio nó e não pode ser usada para Pods.

• Limitações do seletor de sub-rede: as configurações padrão de subnetSelectorTerms e securityGroupSelectorTerms não se aplicam à seleção de sub-rede ou grupo de segurança de pods.

• Planejamento de rede: garanta um espaço de endereços IP adequado nas sub-redes de nós e de pods para ser compatível com os seus requisitos de workload.

• Configuração de roteamento: verifique se a tabela de rotas e a lista de controle de acesso (ACL) de rede das sub-redes de pods estão configuradas corretamente para comunicação entre as sub-redes de nós e de pods.

• Zonas de disponibilidade: verifique se você criou sub-redes de pod em várias AZs. Se você estiver usando uma sub-rede específica de pod, ela deve estar na mesma AZ que a sub-rede do nó.

Modo de IP secundário para pods

O campo ipv4PrefixSize permite configurações avançadas de rede, permitindo somente a alocação de endereços IP secundários aos nós. Esse atributo não aloca prefixos (/28) aos nós e mantém somente um IP secundário como MinimalIPTarget.

advancedNetworking.ipv4PrefixSize aceita dois valores: Auto (padrão; delegação de prefixo; maior velocidade de criação de pods; reserva um mínimo de 16 IPs por nó) e "32" (modo IP secundário; 1 IP por pod; adição de chamadas AssignPrivateIpAddresses por pod; pods por nó limitados pelo limite de IP ENI do tipo de instância).

No modo Auto, o Modo automático do EKS aloca um prefixo /28 (16 IPs) para cada nó antecipadamente e adiciona outro /28 quando a demanda do pod excede a capacidade do bloco atual, portanto, 16 é um mínimo por nó em vez de um limite.

Use os números a seguir para planejar; os clusters reais variam. Quando a sub-rede do pod fica fragmentada e nenhuma /28 contígua está livre, o modo Auto retorna para a alocação por IP nesse nó. As contagens de IPs por nó ficam então abaixo do padrão de 16 por prefixo mostrado abaixo.

Exemplo A: 1 pod no nó

• Modo IP secundário: 1 IP de pod + 1 IP de nó = 2 IPs em uso.

• Modo de prefixo: 1 IP de nó + 16 IPs do primeiro prefixo /28 (dos quais 1 é usado pelo pod, 15 são mantidos para futuros pods) = 17 IPs alocados, 2 em uso.

Exemplo B: 18 pods no nó

• Modo IP secundário: 18 IPs de pod + 1 IP de nó = 19 IPs em uso.

• Modo de prefixo: 1 IP de nó + 2 × /28 prefixos (32 IPs no total, o primeiro /28 cheio em 16 pods, o segundo /28 contém os pods 17-18 com 14 retidos para futuros pods) = 33 IPs alocados, 19 em uso.

Para alternar para o modo IP secundário (1 IP por pod, sem reserva de prefixo) para uma workload esparsa de pods, crie um NodeClass personalizado com advancedNetworking.ipv4PrefixSize: "32" e aponte um NodePool personalizado para ele. Os pools de nós integrados general-purpose e system usam o NodeClass default provisionado automaticamente; a substituição de ipv4PrefixSize requer um NodeClass personalizado emparelhado com um NodePool personalizado.

Casos de uso

• Melhor utilização do endereço IP da sub-rede

• Sem fragmentação de prefixo

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

Considerações sobre o modo de IP secundário

• Velocidade reduzida de criação de pods: como apenas um IP secundário é aquecido, o serviço IPAM precisa de mais tempo para provisionar IPs na criação de mais pods.

Desabilite a saída de IPv4 dos pods IPv6 em clusters de IPv6.

O campo enableV4Egress é true por padrão. Para clusters IPv6 em modo automático, é possível desativar esse recurso para que o modo automático não crie uma interface IPv4 apenas de saída para pods IPv6. Isso é importante porque a interface de saída IPv4 não está sujeita à aplicação da política de rede. As políticas de rede são aplicadas apenas na interface principal do Pod (eth0).

Casos de uso

Use os enableV4Egress quando precisar:

• Use o cluster IPv6: o tráfego de saída IPv4 é permitido por padrão.

• Usar política de rede: atualmente, a Política de Rede do EKS não oferece suporte ao dual-stack. A desativação de enableV4Egress pode impedir que o tráfego do pod saia inesperadamente pelo IPv4.

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

Considerações para desabilitar o EnableV4egress

• Política de rede no cluster IPv6: clusters IPv6 permitem tráfego de IPv4 por padrão. A configuração enableV4Egress: false bloqueia o tráfego de saída IPv4, fornecendo segurança aprimorada, especialmente quando usada com políticas de rede.

Configuração da interface de rede estática

O campo networkInterfaces em advancedNetworking permite que você defina estaticamente as interfaces de rede conectadas às instâncias na inicialização. Isso é usado principalmente para configurar dispositivos do Elastic Fabric Adapter (EFA) para comunicação entre nós de alto desempenho em workloads de treinamento e inferência distribuídas. Esse recurso pode ser combinado com grupos de nós de capacidade estática para manter os nós pré-aquecidos e prontos para EFA. Para obter mais informações sobre o gerenciamento de dispositivos do EFA no EKS, consulte Gerenciar dispositivos EFA no Amazon EKS. Para conferir a configuração recomendada do EFA para tipos de instâncias específicas, consulte Maximizar a largura de banda da rede em tipos de instâncias habilitadas para EFA no Guia do usuário do Amazon EC2.

Como funciona

Cada entrada em networkInterfaces define uma interface de rede que é anexada à instância durante a inicialização. Cada entrada especifica um networkCardIndex (a placa de rede, em que 0 é a primária), um deviceIndex (a posição do dispositivo nessa placa) e um interfaceType (interface para tráfego padrão baseado em IP ou efa-only para interfaces do EFA dedicadas ao tráfego RDMA sem endereços IP). A ENI primária (networkCardIndex: 0, deviceIndex: 0) deve usar interfaceType: interface para ser compatível com a comunicação de nós baseada em IP. As interfaces efa-only são compatíveis somente com capacidades de dispositivos do EFA para RDMA e não podem ser configuradas com endereços IP.

Você pode atribuir capacidade IP às interfaces na placa de rede primária (networkCardIndex: 0) usando secondaryIPv4Count (cada unidade fornece um endereço IP) ou secondaryIPv4PrefixCount (cada unidade fornece um prefixo /28 com 16 endereços IP). Somente um deles pode ser usado por interface, e eles são somente compatíveis com networkCardIndex: 0. Eles não podem ser usados em interfaces efa-only.

Importante

Quando networkInterfaces está configurado, o Modo Automático do EKS não anexa IPs, prefixos ou ENIs adicionais após a inicialização da instância. Somente as interfaces e os endereços IP configurados na inicialização ficam disponíveis para os pods. Você deve planejar a densidade do pod com base no número de IPs configurados.

Considerações

O IPv6 não é compatível com interfaces de rede definidas estaticamente. associatePublicIPAddress não é compatível quando mais de uma interface de rede é definida, portanto, os nós que usam várias interfaces não podem ter IPs públicos (seja em clusters somente públicos, seja em clusters mistos públicos/privados).

Ao usar podSubnetSelectorTerms e podSecurityGroupSelectorTerms com interfaces de rede estáticas, configure a ENI primária com 0 IP secundário. A ENI primária usa os grupos de segurança e a sub-rede do nó, enquanto o tráfego de pods usa a configuração da sub-rede de pods nas ENIs secundárias.

Exemplo: interfaces somente EFA para treinamento em GPU

O exemplo a seguir mostra um NodeClass configurado com interfaces somente EFA para uma instância de GPU usada em treinamento distribuído. A interface primária tem um prefixo /28 (16 IPs de pod), e quatro interfaces adicionais somente EFA fornecem conectividade RDMA. Essa configuração pode ser combinada com um grupo de nós de capacidade estática para manter os nós pré-aquecidos e prontos para EFA.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-training
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - deviceIndex: 1
      interfaceType: efa-only
      networkCardIndex: 0
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 2
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 3

Configurar hugepages em nós

Com o campo advancedCompute.hugepages, você pode configurar hugepages em nós no NodeClass. O Hugepages melhora o desempenho do acesso à memória para workloads sensíveis à latência, como computação de alta performance (HPC), bancos de dados e aplicações que fazem uso intensivo da rede. É possível usar duas configurações independentes de hugepages separadamente ou em conjunto:

• Hugepages estáticas: use o campo pages para pré-alocar um número fixo de hugepages de 2Mi ou 1Gi em cada nó, ou uma combinação dos dois tamanhos. As hugepages estáticas são um recurso de nó programável. Para consumi-las, configure seus Pods para solicitar explicitamente recursos de hugepages, como hugepages-2Mi ou hugepages-1Gi. Para obter mais informações, consulte Manage Huge Pages na documentação do Kubernetes.

• Transparent Hugepages (THP): use o campo transparent para configurar a política THP do kernel. O THP é uma política de todo o kernel, em vez de um recurso alocável. Isso não afeta a programação ou a capacidade do nó, e os pods não o solicitam. Para obter mais informações, consulte Suporte a Transparent Hugepage na documentação do kernel Linux.

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: hugepages-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    hugepages:
      # Static hugepage reservations: up to one entry for each size
      pages:
        - size: "2Mi"
          count: 512
        - size: "1Gi"
          count: 2
      # Transparent hugepages (THP) kernel policy
      transparent:
        enabled: always  # or madvise, never
        defrag: defer    # or always, defer+madvise, madvise, never

Configurações de Transparent Hugepage

Ambas as configurações transparent são opcionais. Se você omitir uma configuração, o nó usará a padrão do kernel (madvise).

• enabled : use enabled para controlar a política de alocação de THP. Defina isso como always para aplicar o THP em todo o sistema. Defina-o como madvise para aplicar o THP somente às regiões de memória que optam por madvise(MADV_HUGEPAGE). Defina-o como never para desativar o THP.

• defrag : use defrag para controlar a agressividade com que o kernel compacta a memória para satisfazer uma alocação de THP. Os valores válidos são always, defer, defer+madvise, madvise e never.

Para desativar o THP, como para workloads de banco de dados que recomendam desativá-lo, defina enabled: never. Quando enabled estiver never, deixe defrag sem definir ou defina como never; a validação do NodeClass rejeita qualquer outra combinação.

Considerações sobre hugepages

Considere o seguinte ao configurar hugepages em um NodeClass:

• Tamanhos estáticos de páginas enormes: use o campo pages para especificar até uma entrada para cada tamanho de hugepage (2Mi e 1Gi). Você pode reservar os dois tamanhos nos mesmos nós.

• Reserva de memória: as hugepages estáticas são contabilizadas na memória total da instância. O Amazon EKS marca os tipos de instância como incompatíveis com o NodeClass quando a reserva combinada de hugepages em todos os tamanhos de página excede 80% da memória total.

• Exclusão mútua de EFA: o Elastic Fabric Adapter (EFA) e hugepages estáticas não podem coexistir no mesmo NodeClass. Se você definir interfaceType: efa-only junto com pages, a validação do NodeClass falhará. O Amazon EKS não provisiona Pods que solicitam vpc.amazonaws.com/efa de um NodeClass com hugepages estáticas. Use um NodeClass separado para workloads do EFA. Páginas enormes transparentes não entram em conflito com o EFA; você pode configurar transparent em um NodeClass que usa interfaces EFA.

Defina as configurações do kubelet nos nós

Use o campo advancedCompute.kubelet para substituir as configurações de kubelet nos nós do NodeClass. Com essas substituições, você pode ajustar a densidade do pod, o despejo por pressão de recursos, a rotação do log do contêiner e o comportamento de falta de memória (OOM). O Amazon EKS aplica as configurações padrão do kubelet aos nós do Modo automático, portanto, configure esse campo somente quando suas workloads exigirem um comportamento diferente. Para obter mais informações sobre as configurações subjacentes, consulte Configuração do Kubelet na documentação do Kubernetes.

As seguintes configurações de kubelet estão disponíveis:

• maxPods: o número máximo de pods que podem ser executados em um nó.

• podPidsLimit: o número máximo de IDs de processo (PIDs) por pod.

• idsPerPod: o número de UIDs e GIDs que o kubelet aloca para o namespace de usuário de cada pod.

• singleProcessOOMKill: se o kubelet OOM elimina processos em um contêiner individualmente em vez de em grupo.

• eviction: limites de despejo rígidos e flexíveis para sinais de pressão de recursos.

• logging: tamanho da rotação do log do contêiner e contagem de arquivos.

• allowedUnsafeSysctls: uma lista de sysctls inseguros, ou padrões com namespace que terminam em *, que os pods programados no nó têm permissão para definir.

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: kubelet-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kubelet:
      # Range: 1-110
      maxPods: 60
      # -1 disables the limit, or specify 100 or greater
      podPidsLimit: 4096
      # Multiple of 65536, range: 65536-4294967295. Requires
      # advancedCompute.kernel.sysctl.user.max_user_namespaces > 0.
      idsPerPod: 65536
      singleProcessOOMKill: false
      eviction:
        # Valid signals: memory.available, nodefs.available, nodefs.inodesFree,
        # imagefs.available, imagefs.inodesFree, pid.available
        hard:
          memory.available: "100Mi"
          nodefs.available: "10%"
        soft:
          memory.available: "500Mi"
          nodefs.available: "15%"
        # Required when soft thresholds are set
        softGracePeriod:
          memory.available: "1m30s"
          nodefs.available: "2m"
        # 0 uses each Pod's terminationGracePeriodSeconds
        maxPodGracePeriod: 60
      logging:
        containerLogMaxSize: "10Mi"
        # Minimum: 2
        containerLogMaxFiles: 5
      # Up to 64 entries. Allowed patterns: kernel.shm*, kernel.msg*,
      # kernel.sem, fs.mqueue.*, net.*
      allowedUnsafeSysctls:
        - "net.core.somaxconn"
        - "kernel.shm*"

Considerações sobre configurações do Kubelet

Considere o seguinte ao definir as configurações de kubelet em um NodeClass:

• Substituição do nó: alterar as configurações do kubelet em um NodeClass existente marca os nós que o usam como desviados. O Amazon EKS substitui esses nós por novos nós que usam a configuração atualizada. O Amazon EKS não aplica as configurações do kubelet aos nós em execução no local.

• Fixação de maxPods: o valor definido é um limite superior, não uma garantia. Em tempo de execução, o Amazon EKS aplica o menor dos três valores. Esses são seu valor maxPods, os endereços IP disponíveis para o tipo de instância e o limite do Modo automático de 110 pods por nó. Para obter mais informações, consulte Escolher um tipo de instância de nó do Amazon EC2 ideal.

• Valores de podPidsLimit: especifique -1 para desativar o limite ou um valor igual a 100 ou superior. A validação de NodeClass rejeita valores entre 0 e 99.

• Requisitos de idsPerPod: O valor deve ser um múltiplo de 65536 entre 65536 e 4294967295. A configuração idsPerPod requer que advancedCompute.kernel.sysctl.user.max_user_namespaces seja definido como um valor positivo na mesma NodeClass; a admissão NodeClass rejeita as configurações que definem idsPerPod sem também definir user.max_user_namespaces como um valor maior que 0. Para obter mais informações sobre o user.max_user_namespaces, consulte Sysctls compatíveis.

• Limites de despejo suave: um limite suave deve ser menos agressivo do que o limite rígido para o mesmo sinal, o que significa que ele é acionado mais cedo. Ao definir limites flexíveis, você também deve configurar softGracePeriod para cada sinal. Um limite flexível e um limite rígido podem usar unidades diferentes, como uma porcentagem e uma quantidade absoluta. Nesse caso, o Amazon EKS resolve os dois valores para cada tipo de instância. Em seguida, o Amazon EKS marca os tipos de instância que violam a comparação como incompatíveis com o NodeClass.

• Requisito de versão de singleProcessOOMKill: essa configuração requer a versão 1.32 ou posterior do Kubernetes. Nas versões anteriores, o Amazon EKS emite um evento de aviso no NodeClass e a configuração não tem efeito.

• Restrições de allowedUnsafeSysctls: você pode especificar até 64 entradas, e cada entrada deve corresponder a um dos padrões permitidos: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue. ou net.. Permitir um sysctl inseguro no nó permite que apenas os pods o solicitem. Cada pod ainda deve listar o sysctl em seu securityContext.sysctls. Para obter mais informações, consulte Usar o sysctls em um cluster Kubernetes na documentação do Kubernetes.

Configurar sysctls do kernel nos nós

Use o campo advancedCompute.kernel.sysctl para definir sysctls do kernel Linux em nós no NodeClass. Os sysctls ajustam o comportamento do kernel de tempo de execução para workloads que precisam de limites de rede mais altos, políticas de gerenciamento de memória diferentes ou configurações de TCP específicas. Os nomes das propriedades no campo sysctl correspondem exatamente ao nome sysctl do kernel subjacente (por exemplo, vm.swappiness e net.core.somaxconn). O Amazon EKS aplica valores sysctl na inicialização do nó. Se você alterar um sysctl em um NodeClass existente, o Amazon EKS começará a substituir os nós para que os novos valores entrem em vigor.

Exemplo de configuração

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: tuned-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kernel:
      sysctl:
        vm.swappiness: 30
        net.core.somaxconn: 4096
        net.ipv4.tcp_congestion_control: "cubic"
        vm.dirty_background_ratio: 10
        vm.dirty_ratio: 20

Sysctls compatíveis

O Amazon EKS é compatível somente com os sysctls na tabela a seguir. Cada sysctl numérico impõe o mínimo e o máximo mostrados, e a admissão do NodeClass rejeita valores fora desse intervalo. Os sysctls de string aceitam somente os valores listados.

Sysctl	Descrição	Valores permitidos
fs.aio-max-nr	O número máximo de solicitações de E/S assíncronas.	65536–4194304
fs.inotify.max_user_instances	O número máximo de instâncias do inotify por ID de usuário real.	8192–1048576
fs.inotify.max_user_watches	O número máximo de observadores do inotify por ID de usuário real.	8192–1048576
fs.nr_open	O número máximo de identificadores de arquivo que um processo pode alocar.	1048576–2147483584
kernel.perf_event_paranoid	Controla o acesso sem privilégios aos sistemas de eventos de performance.	-1–2
net.core.netdev_max_backlog	O número máximo de pacotes enfileirados no lado INPUT por CPU.	1000–3240000
net.core.rmem_max	O tamanho máximo do buffer do soquete de recebimento, em bytes.	212992–134217728
net.core.somaxconn	O valor máximo para o argumento backlog na syscall de recepção.	4096–3240000
net.core.wmem_max	O tamanho máximo do buffer do soquete de envio, em bytes.	212992–134217728
net.ipv4.neigh.default.gc_thresh1	Entradas mínimas de cache ARP antes que a coleta de resíduos possa ser executada.	0–262144
net.ipv4.neigh.default.gc_thresh2	Número máximo flexível de entradas de cache ARP.	512–524288
net.ipv4.neigh.default.gc_thresh3	Número máximo inflexível de entradas de cache ARP.	1024–1048576
net.ipv4.tcp_congestion_control	O algoritmo de controle de congestionamento TCP para novas conexões.	cubic, reno
net.ipv4.tcp_fin_timeout	O período em segundos durante o qual uma conexão órfã permanece no estado FIN_WAIT_2 antes de ser cancelada na extremidade local.	5–120
net.ipv4.tcp_keepalive_time	A frequência em segundos em que o TCP envia mensagens de keepalive quando o keepalive está ativado.	30–432000
net.ipv4.tcp_max_syn_backlog	O número máximo de solicitações SYN pendentes que são permitidas. Solicitações além desse valor são descartadas pelo kernel.	128–3240000
net.ipv4.tcp_tw_reuse	Habilite a reutilização de soquetes TIME-WAIT para novas conexões quando estiver seguro do ponto de vista do protocolo. 0 desativa, 1 ativa globalmente, 2 ativa somente para loopback.	0–2
user.max_user_namespaces	O número máximo de namespaces de usuário que podem ser criados por um usuário. Um valor de 0 desativa os namespaces do usuário.	0–2147483647
vm.dirty_background_ratio	Porcentagem da memória disponível na qual os threads flusher do kernel começam a gravar páginas sujas de volta no disco.	1–20
vm.dirty_expire_centisecs	Centésimos de segundo antes que uma página suja se torne elegível para writeback.	0–6000
vm.dirty_ratio	Porcentagem da memória disponível na qual os programas de gravação são forçados a bloquear as gravações.	5–40
vm.dirty_writeback_centisecs	Centésimos de segundo entre as invocações do thread flusher.	0–1000
vm.max_map_count	O número máximo de áreas de mapa de memória que um único processo pode ter.	65530–2147483647
vm.swappiness	Custo relativo de E/S da troca versus paginação do sistema de arquivos.	0–200
vm.watermark_scale_factor	Taxa de marca-d'água de recuperação de memória em frações de 10.000.	10–3000

Considerações sobre sysctls

Considere o seguinte ao configurar sysctls de kernel em um NodeClass:

• Sysctls compatíveis: somente os sysctls listados em Sysctls compatíveis são compatíveis. Cada campo impõe um mínimo e um máximo documentados, e a admissão do NodeClass rejeita valores fora desse intervalo.

• Aplicado na inicialização: os sysctls são gravados no [settings.kernel.sysctl] do Bottlerocket na inicialização do nó. As alterações em tempo de execução em spec.advancedCompute.kernel.sysctl marcam os nós existentes como desviados; os novos valores entram em vigor somente nos nós de substituição.

• vm.dirty_background_ratio e vm.dirty_ratio: esses dois campos devem ser definidos ou omitidos juntos, e vm.dirty_background_ratio deve ser estritamente menor que vm.dirty_ratio. A admissão do NodeClass rejeita configurações que violam qualquer uma das regras.

• net.ipv4.neigh.default.gc_thresh1, gc_thresh2 e gc_thresh3 : os três limites do cache ARP devem ser todos definidos juntos ou todos omitidos, e seus valores devem satisfazer gc_thresh1 < gc_thresh2 < gc_thresh3. A admissão do NodeClass rejeita configurações que violam qualquer uma das regras.

• net.ipv4.tcp_congestion_control : somente cubic e reno são aceitos.