**Ajudar a melhorar esta página** Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página. # 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. ## 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ó 1. Aplicar a configuração ao cluster usando o `kubectl` 1. 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](create-node-pool.md). Você precisa ter o `kubectl` instalado e configurado. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md). ### 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](create-node-pool.md). ## 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](access-entries.md). 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 \ --principal-arn \ --type EC2 # Associate the auto node policy aws eks associate-access-policy \ --cluster-name \ --principal-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: PrincipalArn: Type: "EC2" AccessPolicies: - AccessScope: Type: cluster PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy DependsOn: [ ] # previously defined in CloudFormation ``` Para obter informações sobre a implantação de pilhas do CloudFormation, consulte [Conceitos básicos do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html) ## 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 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: 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](access-entries.md). + **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](choosing-instance-type.md). + **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](auto-learn-iam.md). + **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](set-builtin-node-pools.md). + **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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) e [Roteamento com reconhecimento de topologia](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), 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](#pod-subnet-selector). ## 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 recurso difere do recurso [Grupos de Segurança para Pods](security-groups-for-pods.md) (SGPP) utilizado com o AWS VPC CNI para instâncias de computação que não estã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. 1. 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. 1. 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. ### Casos de uso Use os `ipv4PrefixSize` quando precisar: + **Utilização reduzida de IP**: somente um endereço IP será aquecido em cada nó. + **Menor taxa de agitação de pods**: a velocidade de criação de pods não é uma grande preocupação. + **Sem fragmentação de prefixo**: a fragmentação causada pelo prefixo é uma grande preocupação ou impedimento para usar o modo automático. ### 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.