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 do 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:

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:
  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: MyNodeRole  # IAM role 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"

  # 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

  # Optional: Forward proxy, commonly requires certificateBundles as well
  #for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
  advancedNetworking:
    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

  # 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

Seleção de sub-rede para pods

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

Casos de uso

Use os podSubnetSelectorTerms quando precisar:

Exemplo de configuração

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

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

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

  # Separate subnets for pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

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

Considerações sobre seletores de sub-rede para pods