View a markdown version of this page

Cómo crear una clase de nodos para Amazon EKS - Amazon EKS
Consideraciones para cargas de trabajo con pocos pods o a gran escalaCómo crear una clase de nodosCreación de una entrada de acceso a una clase de nodosEspecificación de clase de nodosConsideracionesSubredes y grupos de seguridad independientes para podsModo de IP secundaria para podsDesactivación de la salida IPv4 desde pods IPv6 en clústeres IPv6.Configuración de la interfaz de red estáticaConfiguración de hugepages en los nodosConfigure los ajustes de kubelet en los nodosConfigure los sysctls del núcleo en los nodos

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Cómo crear una clase de nodos para Amazon EKS

Las clases de nodos de Amazon EKS son plantillas que ofrecen un control detallado de la configuración de los nodos administrados del modo automático de EKS. Una clase de nodos define los ajustes a nivel de infraestructura que se aplican a los grupos de nodos del clúster de EKS, incluida la configuración de la red, los ajustes de almacenamiento y el etiquetado de los recursos. En este tema se explica cómo crear y configurar una clase de nodos para cumplir con requisitos operativos específicos.

Si necesita personalizar la forma en que el modo automático de EKS aprovisiona y configura las instancias de EC2 más allá de los ajustes predeterminados, la creación de una clase de nodos permite controlar con precisión los parámetros críticos de la infraestructura. Por ejemplo, puede especificar la ubicación de la subred privada para mejorar la seguridad, configurar el almacenamiento efímero de las instancias para cargas de trabajo sensibles al rendimiento o aplicar un etiquetado personalizado para asignar los costos.

Consideraciones para cargas de trabajo con pocos pods o a gran escala

El modo automático de EKS usa la delegación de prefijos (prefijos /28) de forma predeterminada. Cada nodo reserva 16 direcciones IP para pods, lo que resulta eficiente para cargas de trabajo con muchos pods que usan todas esas direcciones. Para las cargas de trabajo con pocos pods (unos pocos pods por nodo, algo habitual en cargas de trabajo de ML o GPU, o en cargas de trabajo con un uso intensivo de antiafinidad) que usan más de unos cientos de nodos por zona de disponibilidad, el modo de IP secundaria ("32") es una configuración más optimizada. Asigna una IP por pod en lugar de reservar 16 por nodo, lo que amplía la capacidad disponible de las subredes de pods /20.

Para obtener más información, consulte Modo de IP secundaria para pods. Para mantener los pods en una subred separada de los nodos (independientemente del modo de asignación), consulte Subredes y grupos de seguridad independientes para pods.

Cómo crear una clase de nodos

Para crear una NodeClass, siga estos pasos:

  1. Cree un archivo YAML (por ejemplo, nodeclass.yaml) con la configuración de la clase de nodo

  2. Aplique la configuración al clúster mediante kubectl

  3. Haga referencia a la clase de nodos en la configuración del grupo de nodos. Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

Debe tener kubectl instalado y configurado. Para obtener más información, consulte Configuración para usar Amazon EKS.

Ejemplo de clase de nodos básica

A continuación, se muestra un ejemplo de clase de nodos:

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"

Esta NodeClass aumenta la cantidad de almacenamiento efímero en el nodo.

Aplique esta configuración mediante:

kubectl apply -f nodeclass.yaml

A continuación, haga referencia a la clase de nodos en la configuración del grupo de nodos. Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

Creación de una entrada de acceso a una clase de nodos

Si crea una clase de nodos personalizada, debe crear una entrada de acceso de EKS para permitir que los nodos se unan al clúster. EKS crea entradas de acceso automáticamente cuando se utilizan la clase de nodos y los grupos de nodos integrados.

Para obtener información sobre cómo funcionan las entradas de acceso, consulte Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS.

Al crear entradas de acceso para las clases de nodos del modo automático de EKS, debe utilizar el tipo de entrada de acceso EC2.

Creación de una entrada de acceso con la CLI

Para crear una entrada de acceso para los nodos de EC2 y asociar la política de nodos automáticos de EKS:

Actualice los siguientes comandos de la CLI con el nombre del clúster y el ARN del rol del nodo. El ARN del rol del nodo se especifica en la clase de nodo YAML.

# 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

Creación de una entrada de acceso con CloudFormation

Para crear una entrada de acceso para los nodos de EC2 y asociar la política de nodos automáticos de EKS:

Actualice el siguiente ejemplo de CloudFormation con el nombre de su clúster y el ARN del rol del nodo. El ARN del rol del nodo se especifica en la clase de nodo YAML.

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 obtener información sobre la implementación de pilas de CloudFormation, consulte Introducción a CloudFormation.

Especificación de clase de nodos

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

Consideraciones

  • Si desea verificar cuánto almacenamiento local tiene una instancia, puede describir el nodo para ver el recurso de almacenamiento efímero.

  • Cifrado de volumen: EKS utiliza la clave de KMS personalizada configurada para cifrar el volumen raíz de solo lectura de la instancia y el volumen de datos de lectura/escritura.

  • Sustitución del rol de IAM del nodo: si cambia el rol de IAM del nodo asociado a una NodeClass, tendrá que crear una nueva entrada de acceso. EKS crea automáticamente una entrada de acceso para el rol de IAM del nodo durante la creación del clúster. El rol de IAM del nodo requiere la política de acceso de EKS AmazonEKSAutoNodePolicy. Para obtener más información, consulte Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS.

  • Densidad máxima de pods: EKS limita la cantidad máxima de pods en un nodo a 110. Este límite se aplica después del cálculo de la cantidad máxima de pods existente. Para obtener más información, consulte Elección de un tipo de instancia de nodo de Amazon EC2 óptimo.

  • Etiquetas: si desea propagar etiquetas de Kubernetes a EC2, debe configurar permisos de IAM adicionales. Para obtener más información, consulte Más información sobre las identidades y el acceso en el modo automático de EKS.

  • Clase de nodo predeterminada: no asigne el nombre default a su clase de nodo personalizada. Esto se debe a que el modo automático de EKS incluye una NodeClass llamada default que se aprovisiona automáticamente cuando se habilita al menos una NodePool integrada. Para obtener más información sobre la activación de NodePools integrados, consulte Cómo habilitar o desactivar los NodePools integrados.

  • Comportamiento de subnetSelectorTerms con varias subredes: si hay varias subredes que coinciden con las condiciones de subnetSelectorTerms o que proporciona por ID, el modo automático de EKS crea nodos distribuidos entre las subredes.

    • Si las subredes se encuentran en diferentes zonas de disponibilidad (AZ), puede usar las características de Kubernetes, como las restricciones de propagación de topología de pods y el enrutamiento consciente de la topología, para distribuir los pods y el tráfico entre las zonas, respectivamente.

    • Si hay varias subredes en la misma AZ que coincidan con subnetSelectorTerms, el modo automático de EKS crea pods en cada nodo distribuidos en las subredes de esa AZ. El modo automático de EKS crea interfaces de red secundarias en cada nodo de las demás subredes de la misma AZ. Elige en función del número de direcciones IP disponibles en cada subred, para utilizar las subredes de manera más eficiente. Sin embargo, no puede especificar qué subred usa el modo automático de EKS para cada pod; si necesita que los pods se ejecuten en subredes específicas, utilice Subredes y grupos de seguridad independientes para pods en su lugar.

  • Restricciones de la estrategia de grupo de ubicación: cada estrategia de grupo de ubicación (clúster, partición, distribución) tiene limitaciones específicas en cuanto a los tipos de instancias, las AZ y la capacidad. Para obtener más información, consulte Estrategias de grupos de ubicación en la Guía del usuario de Amazon EC2.

  • Grupo con ubicación distribuida: límite de 7 instancias: un grupo con ubicación distribuida de bastidor permite hasta 7 instancias en ejecución por zona de disponibilidad por grupo. Esto crea los siguientes casos extremos:

    • El reemplazo de desviaciones está bloqueado al máximo de su capacidad: el modo automático de EKS lanza un nodo de reemplazo antes de terminar el anterior. Cuando un PG disperso tiene 7 instancias en una zona de disponibilidad, se produce un error en el lanzamiento de reemplazo y el nodo desviado sigue funcionando hasta que se libere una ranura.

    • Todas las zonas de disponibilidad (AZ) al máximo de su capacidad: si todas las AZ de la PG distribuida están al límite de 7 instancias, no se podrá programar ningún reemplazo. Los nodos desviados o candidatos a la consolidación permanecen en ejecución indefinidamente.

    • No hay opciones alternativas fuera del grupo de ubicación: el modo automático de EKS no intenta lanzar instancias de reemplazo fuera del grupo de ubicación.

    • Solución alternativa: utilice la política de consolidación WhenEmpty (consolidationPolicy: WhenEmpty). Los nodos se eliminan solo después de que se agoten todos los pods que no son de Daemonset, lo que libera una ranura PG sin necesidad de un lanzamiento de reemplazo primero. Tenga en cuenta que la desviación siempre utiliza el reemplazo y luego la eliminación, independientemente de la política de consolidación, por lo que la desviación permanece bloqueada durante su capacidad máxima.

  • Fijación de zonas de disponibilidad del grupo con ubicación en clúster: una vez que la primera instancia se lanza a un grupo con ubicación en clúster, el PG se fija en esa zona de disponibilidad. Si su NodePool permite múltiples AZ, los lanzamientos paralelos durante el escalamiento vertical inicial pueden competir: uno tiene éxito y fija la AZ, el resto falla con errores de capacidad. Fije la zona de disponibilidad en sus requisitos de NodePool para evitar fallos transitorios.

  • Grupo con ubicación en particiones: se admiten grupos con ubicación en particiones sin restricciones adicionales que superen los límites estándar de EC2.

  • La consolidación puede sacar los pods de un grupo de ubicación: si un pod no tiene restricciones de programación para un grupo de ubicación (como un nodeSelector en eks.amazonaws.com/placement-group-id), la consolidación puede moverlo a un nodo fuera del PG. Las aplicaciones que requieran pertenecer a un grupo de ubicación deben expresarlo mediante restricciones a nivel de pod.

  • Grupo de ubicación inexistente o eliminado: si un NodeClass hace referencia a grupo de ubicación que no existe o que se ha eliminado, no se lanza ninguna instancia. El formato de ID del grupo de ubicación se valida en el momento de la admisión, pero su existencia solo se comprueba en el momento del lanzamiento. Si se elimina un grupo de ubicación mientras los nodos están en ejecución, los nodos existentes se marcan como desviados y permanecen en ejecución indefinidamente, ya que los lanzamientos de reemplazo de desviaciones también quedan bloqueados.

  • Hugepages: para obtener información sobre la configuración de hugepages en los nodos, consulte Configuración de hugepages en los nodos.

  • Configuración de kubelet: para obtener información sobre cómo anular la configuración de kubelet, como la densidad de los pods, los umbrales de expulsión y la rotación de registros, consulte Configure los ajustes de kubelet en los nodos.

  • Sysctls del kernel: para obtener información sobre la configuración de los sysctls del kernel en los nodos, consulte Configure los sysctls del núcleo en los nodos.

Subredes y grupos de seguridad independientes para pods

Los campos podSubnetSelectorTerms y podSecurityGroupSelectorTerms permiten efectuar configuraciones de red avanzadas, ya que permiten que los pods se ejecuten en subredes y grupos de seguridad diferentes a los de sus nodos. Ambos campos deben especificarse juntos. Esta separación proporciona un mayor control sobre el enrutamiento del tráfico de la red y las políticas de seguridad.

nota

Esta característica es diferente de la característica Grupos de seguridad para pods (SGPP) que se utiliza con el CNI de VPC para la computación que no es en el modo automático de EKS. El modo automático de EKS no admite SGPP. En su lugar, use podSecurityGroupSelectorTerms en NodeClass para aplicar grupos de seguridad independientes al tráfico del pod. Los grupos de seguridad se aplican a nivel NodeClass, es decir, todos los pods de los nodos que utilizan ese NodeClass comparten los mismos grupos de seguridad de pods.

Funcionamiento

Cuando configura podSubnetSelectorTerms y podSecurityGroupSelectorTerms:

  1. El ENI principal del nodo utiliza las subredes y los grupos de seguridad de subnetSelectorTerms y securityGroupSelectorTerms. Solo la dirección IP del nodo está asignada a esta interfaz.

  2. El modo automático de EKS crea ENI secundarios en las subredes coincidentes con podSubnetSelectorTerms, con los grupos de seguridad de podSecurityGroupSelectorTerms asociados. Las direcciones IP de los pods se asignan desde estos ENI secundarios mediante prefijos /28 de forma predeterminada, y se recurre automáticamente a las IP secundarias (/32) cuando no hay un bloque de prefijos contiguo disponible. Si ipv4PrefixSize se establece en "32" en advancedNetworking, solo se utilizan las IP secundarias.

  3. Los grupos de seguridad especificados en podSecurityGroupSelectorTerms se aplican al tráfico de pods dentro de la VPC. Para el tráfico destinado fuera de la VPC, los pods utilizan el ENI principal del nodo (y sus grupos de seguridad) porque la traducción de direcciones de red de origen (SNAT) traduce la IP del pod a la IP del nodo. Puede modificar este comportamiento con el campo snatPolicy de NodeClass.

Casos de uso

Use podSubnetSelectorTerms y podSecurityGroupSelectorTerms cuando necesite:

  • Aplicar diferentes grupos de seguridad para controlar el tráfico de los nodos y los pods por separado.

  • Separar el tráfico de infraestructura (comunicación de nodo a nodo) del tráfico de aplicaciones (comunicación de pod a pod).

  • Aplicar configuraciones de red diferentes a las subredes de nodos que a las subredes de pods.

  • Configurar proxies inversos o filtrado de red específicamente para el tráfico de nodos sin afectar al tráfico de los pods. Utilizar advancedNetworking y certificateBundles para definir su proxy inverso y cualquier certificado autofirmado o privado para el proxy.

Configuración de ejemplo

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"

Consideraciones para subredes y grupos de seguridad de pods independientes

  • Ámbito del grupo de seguridad: los grupos de seguridad de podSecurityGroupSelectorTerms están asociados a los ENI secundarios y se aplican al tráfico del pod dentro de la VPC. Cuando SNAT está habilitado (el valor predeterminado snatPolicy: Random), el tráfico que sale de la VPC se traduce a la dirección IP ENI principal del nodo, por lo que los grupos de seguridad securityGroupSelectorTerms del nodo se aplican a ese tráfico en su lugar. Si configura snatPolicy: Disabled, los pods utilizan sus propias direcciones IP para todo el tráfico y debe asegurarse de que los grupos de enrutamiento y seguridad estén configurados en consecuencia.

  • Granularidad a nivel de NodeClass: los grupos de seguridad de los pods se aplican a todos los pods programados en los nodos que utilizan NodeClass. Para aplicar diferentes grupos de seguridad a diferentes cargas de trabajo, cree recursos de NodeClass y NodePool independientes y utilice restricciones, tolerancias o selectores de nodos para programar las cargas de trabajo en los nodos correspondientes.

  • Densidad de pods reducida: se pueden ejecutar menos pods en cada nodo, ya que la interfaz de red principal del nodo está reservada para la IP del nodo y no se puede usar para los pods.

  • Limitaciones del selector de subredes: las configuraciones subnetSelectorTerms y securityGroupSelectorTerms estándar no se aplican a la selección de grupos de seguridad y subredes de los pods.

  • Planificación de la red: garantice un espacio de direcciones IP adecuado en las subredes de nodos y pods para satisfacer sus requisitos de carga de trabajo.

  • Configuración de enrutamiento: verifique que la tabla de enrutamiento y la lista de control de acceso (ACL) de red de las subredes de pods estén configuradas correctamente para la comunicación entre las subredes de nodos y pods.

  • Zonas de disponibilidad: verifique que haya creado subredes de pods en varias AZ. Si está utilizando una subred de pod específica, debe estar en la misma AZ que la subred del nodo.

Modo de IP secundaria para pods

Los campos ipv4PrefixSize permiten configuraciones de red avanzadas al asignar únicamente direcciones IP secundarias a los nodos. Esta característica no asigna prefijos (/28) a los nodos y mantiene solo una IP secundaria como MinimalIPTarget.

advancedNetworking.ipv4PrefixSize acepta dos valores: Auto (predeterminado; delegación de prefijos; mayor velocidad de creación de pods; reserva un mínimo de 16 direcciones IP por nodo) y "32" (modo de IP secundaria; 1 dirección IP por pod; agrega llamadas AssignPrivateIpAddresses por cada pod; la cantidad de pods por nodo está limitada por el límite de direcciones IP de las ENI del tipo de instancia).

En el modo Auto, EKS Auto Mode asigna un prefijo /28 (16 IP) a cada nodo por adelantado y añade otro /28 cuando la demanda de pods supera la capacidad del bloque actual, por lo que 16 es un mínimo por nodo en lugar de un límite.

Use los siguientes números para planificar; los clústeres reales pueden variar. Cuando la subred del pod se fragmenta, y no queda libre ninguna /28 contigua, el modo Auto recurre a la asignación por IP en ese nodo. Por lo tanto, los recuentos de IP por nodo se sitúan por debajo del patrón de 16 por prefijo que se muestra a continuación.

Ejemplo A: 1 pod en el nodo

  • Modo IP secundario: 1 IP de pod + 1 IP de nodo = 2 IP en uso.

  • Modo de prefijo: 1 IP de nodo + 16 IP del primer prefijo /28 (de las cuales 1 se usa para el pod y 15 se mantienen para los pods futuros) = 17 IP asignadas y 2 en uso.

Ejemplo B: 18 pods en el nodo

  • Modo IP secundario: 18 IP de pod + 1 IP de nodo = 19 IP en uso.

  • Modo de prefijo: 1 dirección IP del nodo + 2 prefijos /28 (32 direcciones IP en total; el primer prefijo /28 está completo con 16 pods y el segundo prefijo /28 contiene los pods 17 y 18, con 14 direcciones IP reservadas para futuros pods) = 33 direcciones IP asignadas, 19 en uso.

Para cambiar al modo de IP secundaria (1 IP por pod, sin reserva de prefijo) para una carga de trabajo con pocos pods, cree una NodeClass personalizada con advancedNetworking.ipv4PrefixSize: "32" y configure un NodePool personalizado para que lo utilice. Los NodePools integrados general-purpose y system usan el NodeClass default, que se aprovisiona automáticamente. Para anular ipv4PrefixSize, se requiere un NodeClass personalizado junto con un NodePool personalizado.

Casos de uso

  • Mejor utilización de las direcciones IP de subred

  • Sin fragmentación de prefijos

Configuración de ejemplo

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

  advancedNetworking:
    ipv4PrefixSize: "32"

Consideraciones para el modo de IP secundaria

  • Velocidad reducida de creación de pods: dado que solo se precalienta una IP secundaria, el servicio IPAM requiere más tiempo para aprovisionar direcciones IP cuando se crean pods adicionales.

Desactivación de la salida IPv4 desde pods IPv6 en clústeres IPv6.

Los campos enableV4Egress es true de forma predeterminada. En clústeres IPv6 en modo automático, la característica se puede desactivar para que el modo automático no cree una interfaz IPv4 solo de salida para pods IPv6. Esto es importante porque la interfaz de salida IPv4 no está sujeta a la aplicación de la política de red. Las políticas de red solo se aplican en la interfaz principal del pod (eth0).

Casos de uso

Use enableV4Egress cuando necesite:

  • Uso de clúster IPv6: el tráfico de salida IPv4 está permitido de forma predeterminada.

  • Uso de políticas de red: actualmente, la política de red de EKS no admite configuración de doble pila. La desactivación de enableV4Egress puede impedir que el tráfico del pod salga por IPv4 de forma inesperada.

Configuración de ejemplo

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

  advancedNetworking:
    enableV4Egress: false

Consideraciones para desactivar enableV4Egress

  • Políticas de red en clústeres IPv6: los clústeres IPv6 permiten tráfico IPv4 de forma predeterminada. Establecer enableV4Egress: false bloquea el tráfico de salida IPv4 y proporciona mayor seguridad, especialmente cuando se utiliza junto con políticas de red.

Configuración de la interfaz de red estática

El campo networkInterfaces de advancedNetworking le permite definir de forma estática las interfaces de red conectadas a las instancias en el momento del lanzamiento. Se usa principalmente para configurar los dispositivos de Elastic Fabric Adapter (EFA) para una comunicación entre nodos de alto rendimiento en cargas de trabajo de entrenamiento e inferencia distribuidas. Esta característica se puede combinar con grupos de nodos de capacidad estática para mantener los nodos precalentados y preparados para EFA. Para obtener más información sobre la administración de dispositivos de EFA en EKS, consulte Administración de los dispositivos EFA en Amazon EKS. Para obtener la configuración de EFA recomendada para los tipos de instancia, consulte Maximizar el ancho de banda de la red para los tipos de instancias habilitadas para EFA en la Guía del usuario de Amazon EC2.

Funcionamiento

Cada entrada de networkInterfaces define una interfaz de red que se adjunta a la instancia durante el lanzamiento. Cada entrada especifica un networkCardIndex (la tarjeta de red, donde 0 es la principal), un deviceIndex (la posición del dispositivo en esa tarjeta) y un interfaceType (interface para el tráfico basado en IP estándar o efa-only para las interfaces de EFA dedicadas al tráfico RDMA sin direcciones IP). La ENI principal (networkCardIndex: 0, deviceIndex: 0) debe usar interfaceType: interface para admitir la comunicación de nodos basada en IP. Las interfaces efa-only solo admiten las capacidades de los dispositivos de EFA para RDMA y no se pueden configurar con direcciones IP.

Puede asignar la capacidad IP a las interfaces de la tarjeta de red principal (networkCardIndex: 0) con secondaryIPv4Count (cada unidad proporciona 1 dirección IP) o secondaryIPv4PrefixCount (cada unidad proporciona un prefijo /28 con 16 direcciones IP). Solo se puede usar una de estas opciones por interfaz y solo se admiten en networkCardIndex: 0. No se pueden usar en las interfaces efa-only.

importante

Cuando networkInterfaces está configurado, el modo automático de EKS no adjunta direcciones IP, prefijos ni ENI adicionales tras el lanzamiento de la instancia. Solo las interfaces y las direcciones IP configuradas en el momento del lanzamiento están disponibles para los pods. Debe planificar la densidad de los pods en función del número de IP configuradas.

Consideraciones

Las interfaces de red definidas estáticamente no admiten IPv6. associatePublicIPAddress no es compatible cuando hay más de una interfaz de red definida, por lo que los nodos que utilizan varias interfaces no pueden tener direcciones IP públicas (ya sea en clústeres exclusivamente públicos o en clústeres mixtos públicos y privados).

Cuando utilice podSubnetSelectorTerms y podSecurityGroupSelectorTerms con interfaces de red estáticas, configure la ENI principal con 0 IP secundarias. La ENI principal usa la subred del nodo y los grupos de seguridad, mientras que el tráfico del pod usa la configuración de subred del pod en las ENI secundarias.

Ejemplo: interfaces solo de EFA para el entrenamiento de GPU

En el siguiente ejemplo, se muestra una NodeClass configurada con interfaces solo de EFA para una instancia de GPU utilizada en el entrenamiento distribuido. La interfaz principal tiene un prefijo /28 (16 IP de pod) y 4 interfaces adicionales solo de EFA proporcionan conectividad de RDMA. Esta configuración se puede combinar con un grupo de nodos de capacidad estática para mantener los nodos precalentados y preparados 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

Configuración de hugepages en los nodos

Con el campo advancedCompute.hugepages, puede configurar hugepages en los nodos de NodeClass. Las hugepages mejoran el rendimiento del acceso a la memoria para cargas de trabajo sensibles a la latencia, como la computación de alto rendimiento (HPC), las bases de datos y las aplicaciones con uso intensivo de red. Puede usar dos configuraciones de hugepages por separado o juntas:

  • Hugepages estáticas: use el campo pages para asignar previamente un número fijo de hugepages de 2Mi o 1Gi en cada nodo, o una combinación de ambos tamaños. Las hugepages estáticas son un recurso de nodo programable. Para usarlos, configure los pods para que soliciten recursos de hugepages de forma explícita, como hugepages-2Mi o hugepages-1Gi. Para obtener más información, consulte Manage HugePages en la documentación de Kubernetes.

  • Hugepages transparentes (THP): use el campo transparent para configurar la política de THP del kernel. THP es una política que abarca todo el kernel y no un recurso asignable. No afecta la programación ni a la capacidad de los nodos, y los pods no la solicitan. Para obtener más información, consulte Transparent Hugepage Support en la documentación del kernel de Linux.

Configuración de ejemplo

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

Configuración de hugepages

Ambos ajustes transparent son opcionales. Si omite un ajuste, el nodo usa el valor predeterminado del kernel (madvise).

  • enabled – Use enabled para controlar la política de asignación de THP. Establezca este valor en always para aplicar THP en todo el sistema. Establezca el valor en madvise para que aplique THP solo a las regiones de memoria que estén habilitadas con madvise(MADV_HUGEPAGE). Establezca el valor en never para deshabilitar THP.

  • defrag – Use defrag para controlar la agresividad con la que el kernel compacta la memoria para satisfacer una asignación de THP. Los valores válidos son always, defer, defer+madvise, madvise y never.

Para deshabilitar THP, por ejemplo, para las cargas de trabajo de bases de datos que recomiendan desactivarla, configure enabled: never. Cuando enabled sea never, deje defrag sin establecer o establézcalo ennever; la validación de NodeClass rechaza cualquier otra combinación.

Consideraciones sobre las hugepages

A la hora de configurar hugepages en una NodeClass, tenga en cuenta lo siguiente:

  • Tamaños de hugepage estáticos: use el campo pages para especificar hasta una entrada para cada tamaño de hugepage (2Mi y 1Gi). Puede reservar ambos tamaños en los mismos nodos.

  • Reserva de memoria: las hugepages estáticas se tienen en cuenta en la memoria total de la instancia. Amazon EKS marca los tipos de instancia como incompatibles con la NodeClass cuando la reserva de hugepages combinada en todos los tamaños de página supera el 80 % de la memoria total.

  • Exclusión mutua de EFA: Elastic Fabric Adapter (EFA) y las hugepages estáticas no pueden coexistir en la misma NodeClass. Si configura interfaceType: efa-only junto con pages, se producirá un error en la validación de la NodeClass. Amazon EKS no aprovisiona pods que soliciten vpc.amazonaws.com/efa desde una NodeClass con hugepages estáticas. Utilice una NodeClass independiente para las cargas de trabajo de EFA. Las hugepages transparentes no entran en conflicto con EFA; puede configurar transparent en una NodeClass que use interfaces EFA.

Configure los ajustes de kubelet en los nodos

Use el campo advancedCompute.kubelet para anular la configuración de kubelet en los nodos del NodeClass. Con estas anulaciones, puede ajustar la densidad del pod, la expulsión por presión de recursos, la rotación del registro del contenedor y el comportamiento de falta de memoria (OOM). Amazon EKS aplica la configuración de kubelet predeterminada a los nodos de modo automático, por lo que debe configurar este campo solo cuando las cargas de trabajo requieran un comportamiento diferente. Para obtener más información sobre la configuración subyacente, consulte Configuración de Kubelet en la documentación de Kubernetes.

La siguiente configuración de kubelet está disponible:

  • maxPods: el número máximo de pods que pueden ejecutarse en un nodo.

  • podPidsLimit: el número máximo de ID de proceso (PID) por pod.

  • idsPerPod: la cantidad de UID y GID que el kubelet asigna al espacio de nombres de usuario de cada pod.

  • singleProcessOOMKill: si el kubelet OOM elimina los procesos de un contenedor de forma individual en lugar de como grupo.

  • eviction: umbrales de expulsión estrictos y flexibles para señales de presión de recursos.

  • logging: tamaño de rotación del registro del contenedor y número de archivos.

  • allowedUnsafeSysctls: una lista de sysctls no seguros, o patrones de espacios de nombres que terminan en *, que los pods programados en el nodo pueden configurar.

Configuración de ejemplo

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*"

Consideraciones sobre la configuración de Kubelet

A la hora de configurar los ajustes de kubelet en una NodeClass, tenga en cuenta lo siguiente:

  • Sustitución de nodos: al cambiar la configuración del kubelet en un NodeClass existente, los nodos que lo usan se marcan como desviados. Amazon EKS reemplaza esos nodos por nodos nuevos que usan la configuración actualizada. Amazon EKS no aplica la configuración de kubelet a los nodos que están en ejecución en su lugar.

  • maxPods acotación: el valor que establezca es un límite superior, no una garantía. En tiempo de ejecución, Amazon EKS aplica el menor de los tres valores. Este es su valor maxPods, las direcciones IP disponibles para el tipo de instancia y el límite del modo automático de 110 pods por nodo. Para obtener más información, consulte Elección de un tipo de instancia de nodo de Amazon EC2 óptimo.

  • valores de podPidsLimit: especifique -1 si desea deshabilitar el límite o un valor igual a 100 o superior. NodeClassLa validación rechaza los valores comprendidos entre 0 y 99.

  • requisitos de idsPerPod: el valor debe ser un múltiplo de 65536 entre 65536 y 4294967295. Para configurar idsPerPod, es necesario que advancedCompute.kernel.sysctl.user.max_user_namespaces se establezca en un valor positivo en el mismo NodeClass; la admisión de NodeClass rechaza las configuraciones que establecen idsPerPod sin establecer también user.max_user_namespaces en un valor superior a 0. Para obtener más información acerca de user.max_user_namespaces, consulte Sysctls compatibles.

  • Umbrales de expulsión flexible: un umbral flexible debe ser menos agresivo que el umbral estricto para la misma señal, lo que significa que se activa antes. Si establece umbrales flexibles, también debe establecer softGracePeriod para cada señal. Un umbral flexible y un umbral estricto pueden usar diferentes unidades, como un porcentaje y una cantidad absoluta. En ese caso, Amazon EKS resuelve ambos valores para cada tipo de instancia. A continuación, Amazon EKS marca los tipos de instancias que infringen la comparación como incompatibles con NodeClass.

  • requisito de versión singleProcessOOMKill: esta configuración requiere la versión 1.32 o posterior de Kubernetes. En las versiones anteriores, Amazon EKS emite un evento de advertencia en NodeClass, y la configuración no tiene ningún efecto.

  • restricciones allowedUnsafeSysctls: puede especificar hasta 64 entradas, y cada entrada debe coincidir con uno de los patrones permitidos: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue. o net.. Permitir un sysctl no seguro en el nodo solo permite que los pods lo soliciten. Cada pod debe seguir incluyendo el sysctl en su securityContext.sysctls. Para obtener más información, consulte Using sysctls in a Kubernetes Cluster en la documentación de Kubernetes.

Configure los sysctls del núcleo en los nodos

Use el campo advancedCompute.kernel.sysctl para configurar los sysctls del núcleo de Linux en los nodos del NodeClass. Los sysctls ajustan el comportamiento del núcleo en tiempo de ejecución para las cargas de trabajo que necesitan límites de red más altos, diferentes políticas de administración de memoria o configuraciones de TCP específicas. Los nombres de las propiedades del campo sysctl coinciden exactamente con el nombre sysctl del núcleo subyacente (por ejemplo, vm.swappiness y net.core.somaxconn). Amazon EKS aplica valores sysctl en el arranque del nodo. Si cambia un sysctl en una NodeClass existente, Amazon EKS comienza a sustituir los nodos para aplicar los nuevos valores.

Configuración de ejemplo

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 compatibles

Amazon EKS es compatible únicamente con los sysctls de la siguiente tabla. Cada sysctl numérico aplica el mínimo y el máximo que se muestran, y la admisión de NodeClass rechaza los valores fuera de ese rango. Los sysctls de tipo cadena solo aceptan los valores de la lista.

Sysctl Descripción Valores permitidos

fs.aio-max-nr

El número máximo de solicitudes de E/S asíncronas.

65536–4194304

fs.inotify.max_user_instances

El número máximo de instancias de inotify por ID de usuario real.

8192–1048576

fs.inotify.max_user_watches

El número máximo de supervisiones de inotify por ID de usuario real.

8192–1048576

fs.nr_open

El número máximo de identificadores de archivos que un proceso puede asignar.

1048576–2147483584

kernel.perf_event_paranoid

Controla el acceso sin privilegios a los sistemas de eventos de rendimiento.

-1–2

net.core.netdev_max_backlog

El número máximo de paquetes en cola en el lado INPUT por CPU.

1000–3240000

net.core.rmem_max

El tamaño máximo del búfer del socket de recepción, en bytes.

212992–134217728

net.core.somaxconn

El valor máximo del argumento backlog en la llamada al sistema listen.

4096–3240000

net.core.wmem_max

El tamaño máximo del búfer del socket de recepción, en bytes.

212992–134217728

net.ipv4.neigh.default.gc_thresh1

Número mínimo de entradas en la caché ARP antes de que se pueda ejecutar la recopilación de elementos no utilizados.

0–262144

net.ipv4.neigh.default.gc_thresh2

El número máximo flexible de entradas de caché ARP.

512–524288

net.ipv4.neigh.default.gc_thresh3

El número máximo estricto de entradas de caché ARP.

1024–1048576

net.ipv4.tcp_congestion_control

El algoritmo de control de congestión de TCP para nuevas conexiones.

cubic, reno

net.ipv4.tcp_fin_timeout

El tiempo, en segundos, que una conexión huérfana permanece en el estado FIN_WAIT_2 antes de ser anulada en el extremo local.

5–120

net.ipv4.tcp_keepalive_time

Con qué frecuencia, en segundos, TCP envía mensajes keepalive cuando esta función está activada.

30–432000

net.ipv4.tcp_max_syn_backlog

Número máximo de solicitudes SYN pendientes que se permiten. El kernel descarta las solicitudes que superen este valor.

128–3240000

net.ipv4.tcp_tw_reuse

Habilite la reutilización de los sockets TIME-WAIT para nuevas conexiones cuando sea seguro desde el punto de vista del protocolo. 0 deshabilita, 1 habilita globalmente y 2 habilita solo para el bucle invertido.

0–2

user.max_user_namespaces

El número máximo de espacios de nombres de usuario que un usuario puede crear. El valor de 0 deshabilita los espacios de nombres de usuario.

0–2147483647

vm.dirty_background_ratio

Porcentaje de memoria disponible a partir del cual los subprocesos de vaciado del kernel comienzan a escribir las páginas sucias en el disco.

1–20

vm.dirty_expire_centisecs

Centésimas de segundo antes de que una página sucia sea apta para la reescritura.

0–6000

vm.dirty_ratio

Porcentaje de memoria disponible en el que los programas de escritura se ven obligados a bloquearse al escribir.

5–40

vm.dirty_writeback_centisecs

Centésimas de segundo entre las invocaciones del subproceso de limpieza.

0–1000

vm.max_map_count

El número máximo de áreas del mapa de memoria que puede tener un solo proceso.

65530–2147483647

vm.swappiness

Costo relativo de E/S del intercambio en comparación con la paginación del sistema de archivos.

0–200

vm.watermark_scale_factor

Proporción del umbral de recuperación de memoria expresada en fracciones de 10 000.

10–3000

Consideraciones sobre sysctls

A la hora de configurar kernel sysctls en una NodeClass, tenga en cuenta lo siguiente:

  • Sysctls compatibles: solo se admiten los sysctls enumerados en Sysctls compatibles. Cada sysctl numérico aplica el mínimo y el máximo que se muestran, y la admisión de NodeClass rechaza los valores fuera de ese rango.

  • Aplicado al arrancar: los sysctls se escriben en los de Bottlerocket [settings.kernel.sysctl] al arrancar el nodo. Los cambios en tiempo de ejecución en spec.advancedCompute.kernel.sysctl marcan los nodos existentes como desviados; los nuevos valores solo se aplican a los nodos de reemplazo.

  • vm.dirty_background_ratio y vm.dirty_ratio: estos dos campos deben estar configurados o bien omitidos ambos, y vm.dirty_background_ratio debe ser estrictamente inferior a vm.dirty_ratio. La admisión de NodeClass rechaza las configuraciones que infringen cualquiera de las dos reglas.

  • net.ipv4.neigh.default.gc_thresh1, gc_thresh2 y gc_thresh3: los tres umbrales de caché de ARP deben configurarse todos juntos o bien omitirse todos, y sus valores deben satisfacer gc_thresh1 < gc_thresh2 < gc_thresh3. La admisión de NodeClass rechaza las configuraciones que infringen cualquiera de las dos reglas.

  • net.ipv4.tcp_congestion_control — Solo se aceptan cubic y reno.