**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.
## 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
1. Aplique la configuración al clúster mediante `kubectl`
1. 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](create-node-pool.md).
Debe tener `kubectl` instalado y configurado. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
### 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](create-node-pool.md).
## 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](access-entries.md).
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 \
--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
```
### 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:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Para obtener información sobre la implementación de pilas de CloudFormation, consulte [Introducción a CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html).
## 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
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
```
## 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](access-entries.md).
+ **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](choosing-instance-type.md).
+ **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](auto-learn-iam.md).
+ **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](set-builtin-node-pools.md).
+ **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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) y el [enrutamiento consciente de la topología](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), 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](#pod-subnet-selector) en su lugar.
## 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](security-groups-for-pods.md) (SGPP) que se utiliza con el CNI de VPC de AWS para la computación en modo automático que no es 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.
1. 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.
1. 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.