Cómo crear una clase de nodos Creación de una entrada de acceso a una clase de nodos Especificación de clase de nodos Consideraciones Subredes y grupos de seguridad independientes para pods Modo de IP secundaria para pods Desactivación de la salida IPv4 desde pods IPv6 en clústeres IPv6.Configuración de la interfaz de red estática

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.

Cómo crear una clase de nodos

Para crear una NodeClass, siga estos pasos:

Cree un archivo YAML (por ejemplo, nodeclass.yaml) con la configuración de la clase de nodo
Aplique la configuración al clúster mediante kubectl
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.

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:

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.
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.
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: compruebe 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.

Casos de uso

Use ipv4PrefixSize cuando necesite:

Utilización reducida de IP: solo se precalentará una dirección IP en cada nodo.
Menor tasa de renovación de pods: la velocidad de creación de pods no es una preocupación principal.
Sin fragmentación de prefijos: la fragmentación causada por prefijos representa una preocupación importante o un impedimento para utilizar el modo automático.

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

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Configuración

Creación de un grupo de nodos