**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.
# Configuración de los ajustes del modo automático de EKS
En este capítulo se describe cómo configurar aspectos específicos de los clústeres del modo automático de Amazon Elastic Kubernetes Service (EKS). Aunque el modo automático de EKS administra la mayoría de los componentes de la infraestructura de forma automática, puede personalizar ciertas características para satisfacer los requisitos de la carga de trabajo.
Con las opciones de configuración que se describen en este tema, se pueden modificar los ajustes de red, los recursos de computación y los comportamientos de equilibrio de carga, a la vez que se aprovechan las ventajas que ofrece la administración automatizada de la infraestructura. Antes de realizar cualquier cambio en la configuración, revise las opciones disponibles en las siguientes secciones para determinar qué enfoque se adapta mejor a sus necesidades.
| ¿Qué características desea configurar? | Opción de configuración |
| --- | --- |
| **Redes y almacenamiento de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md) |
| **Recursos de computación de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md) |
| **Grupos de nodos con capacidad estática** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Grupos de nodos con capacidad estática en el modo automático de EKS](auto-static-capacity.md) |
| **Configuración del equilibrador de carga de aplicación** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de una IngressClass para configurar el equilibrador de carga de aplicación](auto-configure-alb.md) |
| **Configuración del equilibrador de carga de red** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red](auto-configure-nlb.md) |
| **Configuración de la clase de almacenamiento** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de una clase de almacenamiento](create-storage-class.md) |
| **Control del uso de ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md) |
| **Seguridad avanzada de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Configuración de ajustes avanzados de seguridad para los nodos](auto-advanced-security.md) |
# 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.
# Creación de un grupo de nodos para el modo automático de EKS
Los grupos de nodos de Amazon EKS ofrecen una forma flexible de administrar los recursos de computación del clúster de Kubernetes. En este tema se muestra cómo crear y configurar grupos de nodos mediante Karpenter, una herramienta de aprovisionamiento de nodos que ayuda a optimizar el escalado del clúster y el uso de los recursos. Con el recurso NodePool de Karpenter, puede definir requisitos específicos para los recursos de computación, como los tipos de instancias, las zonas de disponibilidad, las arquitecturas y los tipos de capacidad.
No puede modificar los grupos de nodos `system` y `general-purpose` integrados. No puede habilitarlos ni deshabilitarlos. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
La especificación NodePool permite un control detallado de los recursos de computación del clúster de EKS mediante diversas etiquetas y requisitos compatibles. Estas incluyen opciones para especificar las categorías de instancias de EC2, los ajustes de la CPU, las zonas de disponibilidad, las arquitecturas (ARM64 o AMD64) y los tipos de capacidad (spot o bajo demanda). También puede establecer límites de recursos para el uso de la CPU y la memoria, lo que garantiza que el clúster se mantenga dentro de los límites operativos necesarios.
El modo automático de EKS utiliza las conocidas etiquetas de Kubernetes para ofrecer formas uniformes y estandarizadas de identificar las características de los nodos. Estas etiquetas, como `topology.kubernetes.io/zone` de las zonas de disponibilidad y `kubernetes.io/arch` de la arquitectura de la CPU, siguen las convenciones establecidas de Kubernetes. Además, las etiquetas específicas de EKS (con el prefijo `eks.amazonaws.com/`) amplían esta funcionalidad con atributos específicos de AWS, como los tipos de instancias, los fabricantes de CPU, las capacidades de la GPU y las especificaciones de red. Este sistema de etiquetado estandarizado permite una integración perfecta con herramientas de Kubernetes existentes y, al mismo tiempo, proporciona una profunda integración de la infraestructura de AWS.
## Cómo crear un NodePool
Siga estos pasos para crear un NodePool para el clúster de Amazon EKS:
1. Cree un archivo YAML llamado `nodepool.yaml` con la configuración de NodePool necesaria. Puede usar la siguiente configuración de muestra.
1. Aplique el NodePool al clúster:
```
kubectl apply -f nodepool.yaml
```
1. Compruebe que el NodePool se haya creado correctamente:
```
kubectl get nodepools
```
1. (Opcional) Supervise el estado del NodePool:
```
kubectl describe nodepool default
```
Asegúrese de que el NodePool haga referencia a una NodeClass válida que exista en el clúster. La NodeClass define configuraciones específicas de AWS para los recursos de computación. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## NodePool de muestra
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Etiquetas compatibles con el modo automático de EKS
El modo automático de EKS es compatible con las siguientes etiquetas conocidas.
**nota**
El modo automático de EKS utiliza etiquetas diferentes a las de Karpenter. Las etiquetas relacionadas con las instancias administradas por EC2 comienzan con `eks.amazonaws.com`.
| Etiqueta | Ejemplo | Descripción |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Región AWS |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Tipo de instancia AWS |
| kubernetes.io/arch | amd64 | Las arquitecturas se definen mediante [valores GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) de la instancia |
| karpenter.sh/capacity-type | spot | Los tipos de capacidad incluyen `spot` y `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Tipos de instancias que usan un hipervisor específico |
| eks.amazonaws.com/compute-type | auto | Identifica los nodos administrados del modo automático de EKS |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Tipos de instancias que admiten (o no) el cifrado en tránsito |
| eks.amazonaws.com/instance-category | g | Tipos de instancias de la misma categoría, generalmente la cadena antes del número de generación. |
| eks.amazonaws.com/instance-generation | 4 | Número de generación del tipo de instancia dentro de una categoría de instancias |
| eks.amazonaws.com/instance-family | g4dn | Tipos de instancias de propiedades similares, pero con diferentes cantidades de recursos |
| eks.amazonaws.com/instance-size | 8xlarge | Tipos de instancias con cantidades de recursos similares, pero con propiedades diferentes |
| eks.amazonaws.com/instance-cpu | 32 | Cantidad de CPU en la instancia |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nombre del fabricante de la CPU |
| eks.amazonaws.com/instance-memory | 131072 | Cantidad de mebibytes de memoria de la instancia |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Cantidad [máxima de megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) de EBS disponibles en la instancia |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Cantidad de [megabits de referencia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibles en la instancia |
| eks.amazonaws.com/instance-gpu-name | t4 | Nombre de la GPU de la instancia, si está disponible |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nombre del fabricante de la GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Cantidad de GPU en la instancia |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Cantidad de mebibytes de memoria de la GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Cantidad de gibibytes de almacenamiento nvme local en la instancia |
**nota**
El modo automático de EKS solo es compatible con determinadas instancias y tiene requisitos de tamaño mínimo. Para obtener más información, consulte [Referencia de instancias compatibles con el modo automático de EKS](automode-learn-instances.md#auto-supported-instances).
## Etiquetas no compatibles con el modo automático de EKS
El modo automático de EKS no es compatible con las siguientes marcas.
+ El modo automático de EKS solo es compatible con Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Desactivación de los grupos de nodos integrados
Si crea grupos de nodos personalizados, puede deshabilitar los grupos de nodos integrados. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
## Clúster sin grupos de nodos integrados
Puede crear un clúster sin los grupos de nodos integrados. Esta opción resulta útil cuando la organización ha creado grupos de nodos personalizados.
**nota**
Al crear un clúster sin grupos de nodos integrados, la NodeClass `default` no se aprovisiona automáticamente. Deberá crear una NodeClass personalizada. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
**Información general:**
1. Cree un clúster de EKS con los valores `nodePools` y `nodeRoleArn` vacíos.
+ Ejemplo de `autoModeConfig` de eksctl:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Para obtener más información, consulte [Creación de un clúster de modo automático de EKS con la CLI de eksctl](automode-get-started-eksctl.md)
1. Creación de una clase de nodos personalizada con un ARN de rol del nodo
+ Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md)
1. Creación de una entrada de acceso para la clase de nodos personalizada
+ Para obtener más información, consulte [Creación de una entrada de acceso a una clase de nodos](create-node-class.md#auto-node-access-entry)
1. Creación de un grupo de nodos personalizado, como se ha descrito anteriormente.
## Interrupción
Puede configurar el modo automático de EKS para interrumpir los nodos que atraviesan su NodePool de varias formas. Puede utilizar `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` o `spec.template.spec.expireAfter`. También puede limitar la frecuencia de las interrupciones del modo automático de EKS a través de `spec.disruption.budgets` del NodePool. También puede controlar los intervalos de tiempo y el número de nodos simultáneos interrumpidos. Para obtener instrucciones sobre cómo configurar este comportamiento, consulte [Disruption](https://karpenter.sh/docs/concepts/disruption/) en la documentación de Karpenter.
Puede configurar la interrupción de los grupos de nodos para:
+ Identificar cuándo están infrautilizadas las instancias y consolidar las cargas de trabajo.
+ Crear un presupuesto de interrupciones del grupo de nodos para limitar las terminaciones de nodos a causa de desviaciones, vacíos y consolidaciones.
De forma predeterminada, el modo automático de EKS:
+ Consolida las instancias infrautilizadas.
+ Termina las instancias después de 336 horas.
+ Establece un presupuesto único de interrupciones del 10 % de los nodos.
+ Permite reemplazar los nodos debido a la desviación cuando se lanza una nueva AMI en modo automático, lo que ocurre aproximadamente una vez por semana.
## Periodo de gracia por terminación
Cuando no se define explícitamente un `terminationGracePeriod` en el NodePool del modo automático de EKS, el sistema aplica automáticamente un periodo de gracia por terminación predeterminado de 24 horas al NodeClaim asociado. Si bien los clientes del modo automático de EKS no verán un `terminationGracePeriod` predeterminado en sus configuraciones personalizadas de NodePool, sí lo podrán ver en el NodeClaim. La funcionalidad permanece constante tanto si el periodo de gracia se establece explícitamente en el NodePool como si se establece de forma predeterminada en el NodeClaim, lo que garantiza un comportamiento predecible de terminación de nodos en todo el clúster.
# Grupos de nodos con capacidad estática en el modo automático de EKS
El modo automático de Amazon EKS admite grupos de nodos con capacidad estática que mantienen un número fijo de nodos independientemente de la demanda de los pods. Los grupos de nodos con capacidad estática son útiles para las cargas de trabajo que requieren una capacidad predecible, instancias reservadas o requisitos de cumplimiento específicos cuando es necesario mantener una huella de la infraestructura coherente.
A diferencia de los grupos de nodos dinámicos que escalan en función de las exigencias de programación de los pods, los grupos de nodos con capacidad estática mantienen la cantidad de nodos que ha configurado.
## Configuración de un grupo de nodos con capacidad estática
Para crear un grupo de nodos con capacidad estática, defina el campo `replicas` en la especificación de NodePool. El campo `replicas` define el número exacto de nodos que conservará el grupo de nodos. Consulte [Ejemplos](#static-capacity-examples) para saber cómo configurar `replicas`.
## Consideraciones de los grupos de nodos con capacidad estática
Los grupos de nodos con capacidad estática tienen varias restricciones y comportamientos importantes:
**Restricciones de configuración:**
+ **No se puede cambiar de modo**: una vez que haya configurado `replicas` en un grupo de nodos, no puede eliminarlo. El grupo de nodos no puede cambiar entre los modos estático y dinámico.
+ **Límites de recursos limitados**: solo se admite el campo `limits.nodes` en la sección de límites. Los límites de CPU y memoria no son aplicables.
+ **Campo sin peso**: el campo `weight` no se puede configurar en grupos de nodos con capacidad estática, ya que la selección de nodos no se basa en la prioridad.
**Comportamiento operativo:**
+ **Sin consolidación**: los nodos de los grupos con capacidad estática no se tienen en cuenta para la consolidación en función del uso.
+ **Operaciones de escalado**: las operaciones de escalado eluden los presupuestos de interrupción de nodos, pero siguen respetando los PodDisruptionBudgets.
+ **Sustitución de nodos**: los nodos se siguen sustituyendo por desviación (como las actualizaciones de la AMI) y vencimiento en función de la configuración.
## Prácticas recomendadas
**Planificación de la capacidad:**
+ Establezca un valor de `limits.nodes` superior a `replicas` para permitir el escalado temporal durante las operaciones de sustitución de nodos.
+ Tenga en cuenta la capacidad máxima necesaria durante la desviación de nodos o las actualizaciones de la AMI al establecer los límites.
**Selección de instancias:**
+ Utilice tipos de instancias específicos cuando tenga instancias reservadas o requisitos de hardware específicos.
+ Evite los requisitos demasiado restrictivos que puedan limitar la disponibilidad de las instancias durante el escalado.
**Administración de interrupciones:**
+ Configure los presupuestos de interrupciones adecuados para equilibrar la disponibilidad con las operaciones de mantenimiento.
+ Tenga en cuenta la tolerancia de la aplicación con respecto a la sustitución de nodos al establecer los porcentajes del presupuesto.
**Supervisión de:**
+ Supervise el campo `status.nodes` periódicamente para garantizar que se mantenga la capacidad deseada.
+ Configure alertas para cuando el recuento real de nodos se desvíe de las réplicas deseadas.
**Distribución en zonas:**
+ Distribuya la capacidad estática en varias zonas de disponibilidad para una mayor disponibilidad.
+ Al crear un grupo de nodos con capacidad estática que abarca varias zonas de disponibilidad, el modo automático de EKS distribuye los nodos entre las zonas especificadas, pero no se garantiza que la distribución sea uniforme.
+ Para lograr una distribución predecible y uniforme entre las zonas de disponibilidad, cree grupos de nodos con capacidad estática independientes, cada uno fijado a una zona de disponibilidad específica según el requisito `topology.kubernetes.io/zone`.
+ Si necesita 12 nodos distribuidos uniformemente en 3 zonas, cree 3 grupos de nodos con 4 réplicas cada uno, en lugar de un grupo de nodos con 12 réplicas en 3 zonas.
## Escalado de un grupo de nodos con capacidad estática
Puede cambiar el número de réplicas de un grupo de nodos con capacidad estática mediante el comando `kubectl scale`:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Al reducir verticalmente, el modo automático de EKS terminará los nodos correctamente: respetará los PodDisruptionBudgets y permitirá reprogramar los pods en ejecución para los nodos restantes.
## Supervisión de grupos de nodos con capacidad estática
Utilice los siguientes comandos para supervisar los grupos de nodos con capacidad estática:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
El campo `status.nodes` muestra el número actual de nodos administrados por el grupo de nodos, que debería coincidir con el recuento de `replicas` deseado en condiciones normales.
## Solución de problemas
**Nodos que no llegan a las réplicas deseadas:**
+ Compruebe si el valor de `limits.nodes` es suficiente.
+ Compruebe que los requisitos no restrinjan demasiado la selección de instancias.
+ Revise las AWS Service Quotas para los tipos de instancias y las regiones que utiliza.
**Sustitución del nodo que tarda demasiado tiempo:**
+ Ajuste los presupuestos de interrupción para permitir más sustituciones simultáneas.
+ Compruebe si los PodDisruptionBudgets impiden la terminación del nodo.
**Terminación inesperada del nodo:**
+ Revise las configuraciones `expireAfter` y `terminationGracePeriod`.
+ Compruebe si hay terminaciones manuales del nodo o eventos de mantenimiento de AWS.
## Ejemplos
### Grupo de nodos básico con capacidad estática
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacidad estática con tipos de instancias específicos
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Grupo de nodos con capacidad estática multizona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacidad estática con reserva de capacidad
En el siguiente ejemplo se muestra cómo utilizar un grupo de nodos con capacidad estática con una reserva de capacidad de EC2. Para obtener más información sobre el uso de las reservas de capacidad de EC2 con el modo automático de EKS, consulte [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md).
`NodeClass` que define `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool` que hace referencia al `NodeClass` anterior y utiliza `karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Creación de una IngressClass para configurar el equilibrador de carga de aplicación
El modo automático de EKS automatiza las tareas rutinarias de equilibrio de carga, incluida la exposición de las aplicaciones del clúster a Internet.
AWS sugiere usar equilibradores de carga de aplicación (ALB) para atender el tráfico HTTP y HTTPS. Los equilibradores de carga de aplicación pueden dirigir las solicitudes en función del contenido de la solicitud. Para obtener más información sobre los equilibradores de carga de aplicación, consulte [¿Qué es un equilibrador de carga de aplicación?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
El modo automático de EKS crea y configura equilibradores de carga de aplicación (ALB). Por ejemplo, el modo automático de EKS crea un equilibrador de carga cuando se crea un objeto de Kubernetes de `Ingress` y lo configura de modo que dirija el tráfico a la carga de trabajo del clúster.
**Información general**
1. Cree una carga de trabajo que desea exponer a Internet.
1. Cree un recurso de `IngressClassParams` y especifique los valores de configuración específicos de AWS, como el certificado que se utilizará para SSL/TLS y las subredes de la VPC.
1. Cree un recurso de `IngressClass` y especifique que el modo automático de EKS será el controlador del recurso.
1. Cree un recurso de `Ingress` que asocie una ruta HTTP y un puerto a una carga de trabajo de clúster.
El modo automático de EKS creará un equilibrador de carga de aplicación que apunte a la carga de trabajo especificada en el recurso de `Ingress`, con la configuración del equilibrador de carga especificada en el recurso de `IngressClassParams`.
## Requisitos previos
+ El modo automático de EKS habilitado en un clúster de Amazon EKS
+ Kubectl configurado para establecer conexión con el clúster
+ Puede utilizar `kubectl apply -f ` para aplicar al clúster los archivos YAML de configuración de ejemplo que aparecen a continuación.
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Información sobre cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
## Paso 1: creación de una carga de trabajo
Para comenzar, cree una carga de trabajo que desee exponer a Internet. Puede ser cualquier recurso de Kubernetes que sirva tráfico HTTP, como una implementación o un servicio.
En este ejemplo, se utiliza un servicio HTTP simple llamado `service-2048` que escucha en el puerto `80`. Para crear este servicio y su implementación, aplique el siguiente manifiesto, `2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Aplique la configuración al clúster:
```
kubectl apply -f 2048-deployment-service.yaml
```
Los recursos enumerados anteriormente se crearán en el espacio de nombres predeterminado. Para verificarlo, ejecute el siguiente comando:
```
kubectl get all -n default
```
## Paso 2: creación de IngressClassParams
Cree un objeto de `IngressClassParams` para especificar opciones de configuración específicas de AWS para el equilibrador de carga de aplicación. En este ejemplo, creamos un recurso `IngressClassParams` denominado `alb` (que utilizará en el siguiente paso) que especifica el esquema del equilibrador de carga, tal como se muestra `internet-facing` en un archivo llamado `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Paso 3: creación de IngressClass
Cree una `IngressClass` que haga referencia a los valores de configuración específicos de AWS establecidos en el recurso `IngressClassParams` en un archivo llamado `alb-ingressclass.yaml`. Anote el nombre de la `IngressClass`. En este ejemplo, se asigna el nombre de `alb` tanto a la `IngressClass` como a los `IngressClassParams`.
Utilice la anotación `is-default-class` para controlar si los recursos de `Ingress` deben usar esta clase de forma predeterminada.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Para obtener más información acerca de las opciones de configuración, consulte [Referencia de IngressClassParams](#ingress-reference).
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingressclass.yaml
```
## Paso 4: creación del ingreso
Cree un recurso `Ingress` en un archivo llamado `alb-ingress.yaml`. El propósito de este recurso es asociar las rutas y los puertos del equilibrador de carga de aplicación a las cargas de trabajo del clúster. Para este ejemplo, creamos un recurso `Ingress` denominado `2048-ingress` que enruta el tráfico a un servicio denominado `service-2048` en el puerto 80.
Para obtener más información sobre la configuración de este recurso, consulte [Ingreso](https://kubernetes.io/docs/concepts/services-networking/ingress/) en la documentación de Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingress.yaml
```
## Paso 5: comprobación del estado
Utilice `kubectl` para encontrar el estado de `Ingress`. El equilibrador de carga puede tardar unos minutos en estar disponible.
Utilice el nombre del recurso de `Ingress` que definió en el paso anterior. Por ejemplo:
```
kubectl get ingress 2048-ingress
```
Una vez que el recurso esté listo, recupere el nombre de dominio del equilibrador de carga.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Para ver el servicio en un navegador web, revise el puerto y la ruta especificados en el recurso de `Ingress`.
## Paso 6: Efectúe una limpieza
Para limpiar el equilibrador de carga, utilice el siguiente comando:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
El modo automático de EKS eliminará automáticamente el equilibrador de carga asociado en la cuenta de AWS.
## Referencia de IngressClassParams
La siguiente tabla es una referencia rápida de las opciones de configuración que se utilizan con mayor frecuencia.
| Campo | Descripción | Ejemplo de valor |
| --- | --- | --- |
| `scheme` | Define si el equilibrador de carga de aplicación es interno o está orientado a Internet | `internet-facing` |
| `namespaceSelector` | Restringe los espacios de nombres que pueden usar esta IngressClass | `environment: prod` |
| `group.name` | Agrupa varios ingresos para compartir un único equilibrador de carga de aplicación | `retail-apps` |
| `ipAddressType` | Establece el tipo de dirección IP para el equilibrador de carga de aplicación | `dualstack` |
| `subnets.ids` | Lista de identificadores de subred para la implementación del equilibrador de carga de aplicación | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Etiquete los filtros para seleccionar las subredes del equilibrador de carga de aplicación | `Environment: prod` |
| `certificateARNs` | Los ARN de los certificados SSL que se van a utilizar | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | Etiquetas personalizadas para los recursos de AWS | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Atributos específicos del equilibrador de carga | `idle_timeout.timeout_seconds: 60` |
## Consideraciones
+ No puede usar las anotaciones en una IngressClass para configurar los equilibradores de carga con el modo automático de EKS. La configuración de IngressClass debe realizarse a través de IngressClassParams. Sin embargo, puede usar anotaciones en los recursos de entrada individuales para configurar el comportamiento del equilibrador de carga (por ejemplo, `alb.ingress.kubernetes.io/security-group-prefix-lists` o `alb.ingress.kubernetes.io/conditions.*`).
+ No puede configurar [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html) con el Modo automático de EKS.
+ Debe actualizar el rol de IAM del clúster para permitir la propagación de etiquetas desde Kubernetes a los recursos del equilibrador de carga de AWS. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Para obtener información sobre la asociación de recursos con el modo automático de EKS o con el controlador del equilibrador de carga de AWS autoadministrado, consulte [Referencia para las migraciones](migrate-auto.md#migration-reference).
+ Para obtener información sobre cómo solucionar problemas con los equilibradores de carga, consulte [Solución de problemas del modo automático de EKS](auto-troubleshoot.md).
+ Para conocer más aspectos a tener en cuenta a la hora de utilizar la capacidad de equilibrio de carga del modo automático de EKS, consulte [Equilibrio de carga](auto-networking.md#auto-lb-consider).
Las siguientes tablas proporcionan una comparación detallada de los cambios en las configuraciones de IngressClassParams, Ingress Annotations y TargetGroupBinding para el modo automático de EKS. Estas tablas destacan las principales diferencias entre la capacidad de equilibrio de carga del modo automático de EKS y el controlador del equilibrador de carga de código abierto, incluidos los cambios en la versión de la API, las características obsoletas y la actualización de los nombres de los parámetros.
### IngressClassParams
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.certificateArn` | `spec.certificateARNs` | Compatibilidad con múltiples ARN de certificados |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Se modificó el esquema de coincidencia de subredes |
| `spec.listeners.listenerAttributes` | No admitido | Etiquetas que aún no son compatibles con el Modo automático de EKS |
### Anotaciones de ingreso
| Anteriores | New | Descripción |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | No admitido | Utilice `spec.ingressClassName` en objetos de ingreso |
| `alb.ingress.kubernetes.io/group.name` | No admitido | Especifique grupos en IngressClass únicamente |
| `alb.ingress.kubernetes.io/waf-acl-id` | No admitido | En su lugar, utilice WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | No admitido | En su lugar, utilice WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | No admitido | Integración de Shield desactivada |
| `alb.ingress.kubernetes.io/auth-type: oidc` | No admitido | Actualmente, no se admite el tipo de autenticación OIDC |
### TargetGroupBinding
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.targetType` opcional | `spec.targetType` obligatorio | Especificación explícita del tipo de destino |
| `spec.networking.ingress.from` | No admitido | Ya no es compatible con equilibradores de carga de red sin grupos de seguridad |
Para utilizar la característica TargetGroupBinding personalizada, debe etiquetar el grupo de destino con la etiqueta eks:eks-cluster-name con el nombre del clúster para conceder al controlador los permisos de IAM necesarios. Tenga en cuenta que el controlador eliminará el grupo de destino cuando se elimine el recurso TargetGroupBinding o el clúster.
# Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red
Aprenda a configurar los equilibradores de carga de red (NLB) en Amazon EKS mediante anotaciones de servicio de Kubernetes. En este tema se explican las anotaciones que admite el modo automático de EKS para personalizar el comportamiento de los NLB, incluidos los modos de accesibilidad a Internet, las comprobaciones de estado, la terminación de SSL/TLS y la segmentación por IP.
Al crear un servicio de Kubernetes de tipo `LoadBalancer` en el modo automático de EKS, EKS aprovisiona y configura automáticamente un equilibrador de carga de red de AWS en función de las anotaciones que especifique. Este enfoque declarativo permite administrar las configuraciones del equilibrador de carga directamente a través de los manifiestos de Kubernetes, manteniendo las prácticas de infraestructura como código.
El modo automático de EKS administra el aprovisionamiento del equilibrador de carga de red de forma predeterminada para todos los servicios del tipo LoadBalancer, sin necesidad de instalar ni configurar ningún controlador adicional. La especificación `loadBalancerClass: eks.amazonaws.com/nlb` se establece automáticamente como la predeterminada del clúster, lo que agiliza el proceso de implementación y garantiza la compatibilidad con las cargas de trabajo de Kubernetes existentes.
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Información sobre cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
## Ejemplo de servicio
Para obtener más información sobre el recurso `Service` de Kubernetes, consulte la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
Revise el recurso de `Service` de muestra que aparece a continuación:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Anotaciones de uso frecuente
En la siguiente tabla se enumeran las anotaciones más utilizadas compatibles con el modo automático de EKS. Tenga en cuenta que es posible que el modo automático de EKS no admita todas las anotaciones.
**sugerencia**
Todas las anotaciones que aparecen a continuación deben ir precedidas de `service.beta.kubernetes.io/`
| Campo | Descripción | Ejemplo |
| --- | --- | --- |
| `aws-load-balancer-type` | Especifica el tipo de equilibrador de carga. Utilice `external` para nuevas implementaciones. | `external` |
| `aws-load-balancer-nlb-target-type` | Especifica si se debe dirigir el tráfico a las instancias de los nodos o directamente a las IP de los pods. Utilice `instance` para implementaciones estándar o `ip` para el enrutamiento directo a los pods. | `instance` |
| `aws-load-balancer-scheme` | Controla si el equilibrador de carga es interno o está expuesto a Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocolo de comprobación de estado correspondiente al grupo de destino. Las opciones más comunes son `TCP` (predeterminada) o `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | La ruta HTTP para las comprobaciones de estado cuando se utiliza el protocolo HTTP/HTTPS. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | El puerto que se utiliza para las comprobaciones de estado. Puede ser un número de puerto específico o `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Especifica en qué subredes se va a crear el equilibrador de carga. Puede usar nombres o ID de subred. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN del certificado SSL de AWS Certificate Manager para HTTPS/TLS. | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Especifica qué puertos deben usar SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Los rangos de CIDR permiten acceder al equilibrador de carga. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | Etiquetas de AWS adicionales para aplicarlas al equilibrador de carga y a los recursos relacionados. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Especifica si el equilibrador de carga usa IPv4 o pila dual (IPv4 \$1 IPv6). | `ipv4` o `dualstack` |
## Consideraciones
+ Debe actualizar el rol de IAM del clúster para permitir la propagación de etiquetas desde Kubernetes a los recursos del equilibrador de carga de AWS. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Para obtener información sobre la asociación de recursos con el modo automático de EKS o con el controlador del equilibrador de carga de AWS autoadministrado, consulte [Referencia para las migraciones](migrate-auto.md#migration-reference).
+ Para obtener información sobre cómo solucionar problemas con los equilibradores de carga, consulte [Solución de problemas del modo automático de EKS](auto-troubleshoot.md).
+ Para conocer más aspectos a tener en cuenta a la hora de utilizar la capacidad de equilibrio de carga del modo automático de EKS, consulte [Equilibrio de carga](auto-networking.md#auto-lb-consider).
Al migrar al modo automático de EKS para el equilibrio de carga, es necesario realizar varios cambios en las anotaciones de servicio y las configuraciones de recursos. En las tablas que aparecen a continuación se describen las principales diferencias entre las implementaciones anteriores y las nuevas, incluidas las opciones no compatibles y las alternativas recomendadas.
### Anotaciones del servicio
| Anteriores | New | Descripción |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | No admitido | Utilice `spec.loadBalancerSourceRanges` en el servicio |
| `service.beta.kubernetes.io/aws-load-balancer-type` | No admitido | Utilice `spec.loadBalancerClass` en el servicio |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | No admitido | Uso de `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| Varios atributos del equilibrador de carga | No admitido | Uso de `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
Para migrar desde anotaciones de atributos del equilibrador de cargas obsoletas, consolide estos ajustes en la anotación `service.beta.kubernetes.io/aws-load-balancer-attributes`. Esta anotación acepta una lista separada por comas de pares de clave y valor para varios atributos del equilibrador de carga. Por ejemplo, para especificar el registro de acceso y el equilibrio de carga entre zonas, utilice el siguiente formato:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Este formato consolidado proporciona una forma más coherente y flexible de configurar los atributos del equilibrador de carga y, al mismo tiempo, reduce la cantidad de anotaciones individuales necesarias. Revise las configuraciones de servicio existentes y actualícelas para usar este formato consolidado.
### TargetGroupBinding
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.targetType` opcional | `spec.targetType` obligatorio | Especificación explícita del tipo de destino |
| `spec.networking.ingress.from` | No admitido | Ya no es compatible con equilibradores de carga de red sin grupos de seguridad |
Nota: Para utilizar la característica TargetGroupBinding personalizada, debe etiquetar el grupo de destino con la etiqueta `eks:eks-cluster-name` con el nombre del clúster para conceder al controlador los permisos de IAM necesarios. Tenga en cuenta que el controlador eliminará el grupo de destino cuando se elimine el recurso TargetGroupBinding o el clúster.
# Creación de una clase de almacenamiento
Una `StorageClass` en el modo automático de EKS define cómo se aprovisionan automáticamente los volúmenes de Amazon EBS cuando las aplicaciones solicitan almacenamiento persistente. En esta página se explica cómo crear y configurar una `StorageClass` que funcione con el modo automático de Amazon EKS para aprovisionar volúmenes de EBS.
Al configurar una `StorageClass`, puede especificar la configuración predeterminada para los volúmenes de EBS, incluidos el tipo de volumen, el cifrado, las IOPS y otros parámetros de almacenamiento. También puede configurar `StorageClass` para que utilice claves de AWS KMS para la administración del cifrado.
El modo automático de EKS no crea una `StorageClass` en su nombre. Debe crear una `StorageClass` que haga referencia a `ebs.csi.eks.amazonaws.com` para utilizar la capacidad de almacenamiento del modo automático de EKS.
Primero, cree un archivo denominado `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
En segundo lugar, aplique la clase de almacenamiento al clúster.
```
kubectl apply -f storage-class.yaml
```
**Componentes principales:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utiliza el modo automático de EKS
+ `allowedTopologies`: al especificar `matchLabelExpressions` para que coincida con `eks.amazonaws.com/compute-type:auto`, se asegurará de que los pods no se programarán en nodos no automáticos si sus pods necesitan que un volumen se aprovisione automáticamente con el Modo automático.
+ `volumeBindingMode: WaitForFirstConsumer`: retrasa la creación del volumen hasta que un pod lo necesite
+ `type: gp3`: especifica el tipo de volumen de EBS
+ `encrypted: "true"`: EBS cifrará todos los volúmenes creados con la `StorageClass`. EBS utilizará el alias de clave de `aws/ebs` predeterminado. Para obtener más información, consulte [Cómo funciona el cifrado de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) en la Guía del usuario de Amazon EBS. Este valor es opcional, pero recomendado.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes utilizará esta clase de almacenamiento de forma predeterminada, a menos que se especifique una clase de volumen diferente en una reclamación de volumen persistente. Este valor es opcional. Tenga cuidado al establecer este valor si va a migrar desde un controlador de almacenamiento diferente.
## Utilice una clave de KMS autoadministrada para cifrar los volúmenes de EBS
Para utilizar una clave de KMS autoadministrada para cifrar los volúmenes de EBS automatizados mediante el modo automático de EKS, deberá:
1. Crear una clave de KMS autoadministrada.
+ Para obtener más información, consulte [Cómo crear una clave de KMS de cifrado simétrico](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) o [Cómo Amazon Elastic Block Store (Amazon EBS) usa KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) en la Guía del usuario de KMS.
1. Cree una nueva política que permita el acceso a la clave de KMS.
+ Utilice la política de IAM de muestra que aparece a continuación para crear la política. Inserte el ARN de la nueva clave de KMS autoadministrada. Para obtener más información, consulte [Cómo crear roles y asociar políticas (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) en la Guía de usuario de IAM AWS.
1. Asocie la política al rol de clúster de EKS.
+ Utilice la consola de AWS para buscar el ARN del rol de clúster de EKS. La información del rol aparece en la sección **Descripción general**. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md).
1. Actualice la `StorageClass` de modo que haga referencia al ID de la clave de KMS en el campo `parameters.kmsKeyId`.
### Ejemplo de política de IAM de KMS autoadministrada
Actualice los siguientes valores de la política que aparece a continuación:
+ ``: el ID de la cuenta de AWS, como `111122223333`
+ ``: la región de AWS del clúster, como `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Ejemplo de `StorageClass` de KMS autoadministrada
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Referencia de los parámetros de `StorageClass`
Para obtener información general sobre los recursos de `StorageClass` de Kubernetes, consulte [Clases de almacenamiento](https://kubernetes.io/docs/concepts/storage/storage-classes/) en la documentación de Kubernetes.
La sección `parameters` del recurso `StorageClass` es específica de AWS. Utilice la siguiente tabla para revisar las opciones disponibles.
| Parameters | Valores | Predeterminado | Descripción |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Tipo de sistema de archivos que se formateará durante la creación del volumen. Este parámetro distingue entre mayúsculas y minúsculas. |
| “tipo” | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Tipo de volumen de EBS. |
| “iopsPerGB” | | | Operaciones de E/S por segundo por GiB. Se puede especificar para los volúmenes IO1, IO2 y GP3. |
| “allowAutoIOPSPerGBIncrease” | true, false | false | Si es `"true"`, el controlador CSI aumenta las IOPS de un volumen si `iopsPerGB * ` es demasiado bajo para ajustarse en el rango de IOPS admitido por AWS. Esto permite que el aprovisionamiento dinámico siempre se realice correctamente, incluso si el usuario especifica una capacidad de PVC o un valor de `iopsPerGB` demasiado bajo. Por otro lado, esto puede generar costos adicionales, ya que dichos volúmenes tienen IOPS más altas que las solicitadas en `iopsPerGB`. |
| “iops” | | | Operaciones de E/S por segundo. Se puede especificar para los volúmenes IO1, IO2 y GP3. |
| “rendimiento” | | 125 | El rendimiento se indica en MB/s. Solo es efectivo cuando se especifica el tipo de volumen gp3. |
| “cifrado” | true, false | false | Especifica si el volumen debe estar cifrado o no. Los valores válidos son “verdadero” o “falso”. |
| “blockExpress” | true, false | false | Habilita la creación de volúmenes io2 Block Express. |
| “kmsKeyId” | | | El ARN completo de la clave que se va a utilizar al cifrar el volumen. Si no se especifica, AWS utilizará la clave de KMS predeterminada para la región en la que se encuentra el volumen. Será una clave generada automáticamente y se llamará `/aws/ebs`, si no se modifica. |
| “blockSize” | | | El tamaño del bloque que se utilizará al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “inodeSize” | | | El tamaño del nodo de índice que se utilizará al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “bytesPerInode” | | | Los `bytes-per-inode` que se utilizarán al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3` y `ext4`. |
| “numberOfInodes” | | | Los `number-of-inodes` que se utilizarán al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3` y `ext4`. |
| “ext4BigAlloc” | true, false | false | Cambia el sistema de archivos `ext4` de modo que utilice la asignación de bloques en clústeres, para lo que habilita la opción de formateo `bigalloc`. Advertencia: es posible que `bigalloc` no sea completamente compatible con el núcleo de Linux del nodo. |
| “ext4ClusterSize” | | | El tamaño del clúster que se utilizará al formatear un sistema de archivos `ext4`cuando la característica `bigalloc` esté habilitada. Nota: El parámetro `ext4BigAlloc` debe estar establecido en “verdadero”. |
Para obtener más información, consulte [Controlador de CSI de AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) en GitHub.
## Consideraciones
**nota**
Solo puede implementar cargas de trabajo que dependan de las clases de almacenamiento del modo automático de EKS en los nodos del modo automático de EKS. Si tiene un clúster con varios tipos de nodos, debe configurar sus cargas de trabajo para que se ejecuten únicamente en los nodos del modo automático de EKS. Para obtener más información, consulte [Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md).
La capacidad de almacenamiento en bloques del modo automático de EKS es diferente a la del controlador de CSI de EBS.
+ Aprovisionamiento estático
+ Si desea utilizar volúmenes de EBS creados externamente con el modo automático de EKS, tendrá que agregar manualmente una etiqueta `eks:eks-cluster-name` con la clave AWS y el valor del nombre del clúster.
+ Taint de inicio de nodos
+ No puede usar la característica de taint de inicio de nodos para evitar la programación de pods antes de que la capacidad de almacenamiento esté lista.
+ Etiquetas personalizadas en volúmenes aprovisionados dinámicamente
+ No puede utilizar la marca de la CLI de etiquetas adicionales para configurar etiquetas personalizadas en volúmenes de EBS aprovisionados dinámicamente
+ Puede utilizar el etiquetado de `StorageClass` para agregar etiquetas personalizadas. El modo automático de EKS agregará etiquetas a los recursos de AWS asociados. Deberá actualizar el rol de IAM del clúster para las etiquetas personalizadas. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Métricas de rendimiento detalladas de EBS
+ No puede acceder a las métricas de Prometheus para obtener el rendimiento detallado de EBS
## Instale el complemento de controlador de instantáneas de CSI
El modo automático de EKS es compatible con el complemento de Amazon EKS de controlador de instantáneas de CSI.
AWS sugiere configurar este complemento para que se ejecute en el grupo de nodos del `system` integrado.
Para obtener más información, consulte:
+ [Ejecución de complementos esenciales en instancias dedicadas](critical-workload.md)
+ [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md)
+ [Habilitación de la funcionalidad de instantáneas para volúmenes de CSI](csi-snapshot-controller.md)
### Para instalar el controlador de instantáneas en el grupo de nodos del sistema
1. Abra el clúster de EKS en la consola de AWS
1. En la pestaña **Complementos**, seleccione **Obtener más complementos**
1. Seleccione el **Controlador de instantáneas de CSI** y luego **Siguiente**
1. En la página **Configuración de los ajustes de los complementos seleccionados**, seleccione **Ajustes de configuración opcionales** para ver el **Esquema de configuración del complemento**
1. Inserte el siguiente yaml para asociar el controlador de instantáneas al grupo de nodos del `system`. El controlador de instantáneas incluye una tolerancia a la taint `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Seleccione **Siguiente**.
1. Revise la configuración del complemento y, a continuación, seleccione **Crear**
# Cómo desactivar el modo automático de EKS
Puede desactivar el modo automático de EKS en un clúster de EKS existente. Se trata de una operación destructiva.
+ EKS terminará todas las instancias de EC2 operadas por el modo automático de EKS.
+ EKS eliminará todos los equilibradores de carga operados por el modo automático de EKS.
+ EKS **no** eliminará los volúmenes de EBS aprovisionados por el modo automático de EKS.
El modo automático de EKS está diseñado para administrar completamente los recursos que crea. Las intervenciones manuales podrían provocar que el modo automático de EKS no limpie completamente esos recursos cuando está desactivado. Por ejemplo, si ha hecho referencia a un grupo de seguridad administrado desde las reglas de un grupo de seguridad externo y se olvida de eliminar esa referencia antes de desactivar el modo automático de EKS para un clúster, el grupo de seguridad administrado no se eliminará y quedará residual. Los siguientes pasos describen cómo eliminar un grupo de seguridad residual en caso de que eso ocurra.
## Desactivación del modo automático de EKS (Consola de AWS)
1. Abra la página de información general del clúster en la Consola de administración de AWS.
1. En **Modo automático de EKS**, seleccione **Administrar**
1. Desactivar el **Modo automático de EKS** con la opción `off`.
Si un grupo de seguridad administrado no se elimina al final de este proceso, podrá eliminarlo manualmente con las descripciones de [Eliminar un grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Desactivación del modo automático de EKS (AWS CLI)
Utilice el siguiente comando para desactivar el modo automático de EKS en un clúster existente.
Debe tener `aws` CLI instalada y haber iniciado sesión con los permisos suficientes para administrar los clústeres de EKS. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
**nota**
Las capacidades de computación, almacenamiento en bloque y equilibrio de carga se deben habilitar o desactivar en la misma solicitud.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Puede verificar si un grupo de seguridad del modo automático de EKS quedó residual y no se eliminó después de desactivar el modo automático de EKS de la siguiente manera:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Para después eliminar el grupo de seguridad:
```
aws ec2 delete-security-group --group-name=
```
# Actualización de la versión de Kubernetes de un clúster del modo automático de EKS
En este tema se explica cómo actualizar la versión de Kubernetes del clúster del modo automático. El modo automático simplifica el proceso de actualización de versiones al gestionar la coordinación de las actualizaciones del plano de control con las sustituciones de nodos, mientras mantiene la disponibilidad de la carga de trabajo gracias a los presupuestos de interrupción de pods.
Al actualizar un clúster del modo automático, muchos componentes que tradicionalmente requerían actualizaciones manuales ahora se administran como parte del servicio. Entender los aspectos automatizados del proceso de actualización y las responsabilidades asociadas contribuye a asegurar una transición de versión fluida para el clúster.
## Más información sobre las actualizaciones con el modo automático de EKS
Una vez iniciada la actualización del plano de control, el modo automático de EKS comenzará a actualizar los nodos del clúster. A medida que los nodos expiren, el modo automático de EKS los reemplazará con nodos nuevos. Los nuevos nodos cuentan con la nueva versión de Kubernetes correspondiente. El modo automático de EKS respeta los presupuestos de interrupción de pods al actualizar nodos.
Además, ya no tendrá que actualizar componentes como:
+ CNI de Amazon VPC
+ Controlador del equilibrador de carga de AWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ Controlador CSI de AWS EBS
El modo automático de EKS sustituye estos componentes por funciones de servicio.
Aún es responsable de la actualización de:
+ Aplicaciones y cargas de trabajo implementadas en el clúster
+ Complementos y controladores autoadministrados
+ Complementos de Amazon EKS
+ Información sobre cómo [Actualización de un complemento de Amazon EKS](updating-an-add-on.md)
Más información sobre las [prácticas recomendadas para la actualización de clústeres](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Cómo iniciar la actualización del clúster
Para iniciar una actualización del clúster, consulte [Actualización del clúster existente a la nueva versión de Kubernetes](update-cluster.md).
# Cómo habilitar o desactivar los NodePools integrados
El modo automático de EKS tiene dos NodePools integrados. Puede habilitar o desactivar estos NodePools mediante la consola de AWS, la CLI o la API.
## Referencia de NodePool integrado
+ `system`
+ Este NodePool tiene una taint `CriticalAddonsOnly`. Muchos complementos de EKS, como CoreDNS, toleran esta taint. Utilice este grupo de nodos del sistema para separar las aplicaciones críticas del clúster.
+ Admite tanto arquitecturas `amd64` como `arm64`.
+ `general-purpose`
+ Este NodePool admite el lanzamiento de nodos para cargas de trabajo de uso general en el clúster.
+ Utiliza solo la arquitectura `amd64`.
Ambos NodePools integrados:
+ Utilizan la NodeClass de EKS predeterminada
+ Utilizan únicamente la capacidad de EC2 bajo demanda
+ Utilizan las familias de instancias C, M y R de EC2
+ Exigen instancias de EC2 de generación 5 o posterior
**nota**
Es necesario habilitar al menos un NodePool integrado para que EKS aprovisione la NodeClass “predeterminada”. Si desactiva todos los NodePools integrados, tendrá que crear una NodeClass personalizada y configurar un NodePool para usarla. Para obtener más información acerca de NodeClasses, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## Procedimiento
### Requisitos previos
+ La versión más reciente de la Interfaz de Línea de Comandos de AWS (AWS CLI) instalada y configurada en el dispositivo. Para comprobar su versión actual, utilice `aws --version`. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ Inicie sesión en la CLI con permisos de IAM suficientes para crear recursos de AWS, como políticas de IAM, roles de IAM y clústeres de EKS.
### Habilitar con la CLI de AWS
Utilice el siguiente comando para habilitar ambos NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Puede modificar el comando para habilitar los NodePools de forma selectiva.
### Desactivar con la CLI de AWS
Utilice el siguiente comando para desactivar ambos NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS
Al ejecutar cargas de trabajo en un clúster de EKS con el modo automático de EKS, es posible que deba controlar si determinadas cargas de trabajo se ejecutan en nodos del modo automático de EKS o en otros tipos de computación. En este tema se describe cómo usar los selectores de nodos y las reglas de afinidad para garantizar que las cargas de trabajo estén programadas en la infraestructura de computación prevista.
Los ejemplos de este tema muestran cómo utilizar la etiqueta `eks.amazonaws.com/compute-type` para exigir o impedir la implementación de la carga de trabajo en los nodos del modo automático de EKS. Esto resulta especialmente útil en clústeres de modo mixto en los que se ejecutan tanto el modo automático de EKS como otros tipos de computación, como los aprovisionadores Karpenter autoadministrados o los grupos de nodos administrados por EKS.
Los nodos del modo automático de EKS han establecido el valor de la etiqueta `eks.amazonaws.com/compute-type` en `auto`. Muestra cómo utilizar esta marca para controlar si una carga de trabajo se implementa en nodos administrados por el modo automático de EKS.
## Es necesario implementar una carga de trabajo en los nodos del modo automático de EKS
**nota**
Este valor de `nodeSelector` no es obligatorio para el modo automático de EKS. Este valor de `nodeSelector` es relevante únicamente si ejecuta un clúster en un modo mixto, con tipos de nodos no administrados por el modo automático de EKS. Por ejemplo, es posible que haya capacidad de computación estática implementada en el clúster con grupos de nodos administrados por EKS, así como una capacidad de computación dinámica administrada por el modo automático de EKS.
Puede agregar este `nodeSelector` a las implementaciones u otras cargas de trabajo para exigir a Kubernetes que las programe en los nodos del modo automático de EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Requiere que una carga de trabajo no se implemente en nodos del modo automático de EKS.
Puede agregar esta `nodeAffinity` a las implementaciones u otras cargas de trabajo para exigir a Kubernetes que **no** las programe en los nodos del modo automático de EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Ejecución de complementos esenciales en instancias dedicadas
En este tema, aprenderá a implementar una carga de trabajo con una tolerancia `CriticalAddonsOnly` para que el modo automático de EKS la programe en el grupo de nodos de `system`.
El grupo de nodos del `system` integrado del modo automático de EKS está diseñado para ejecutar complementos esenciales en instancias dedicadas. Esta división asegura que los componentes esenciales dispongan de recursos dedicados y se mantengan aislados de las cargas de trabajo generales, mejorando así la estabilidad y el rendimiento global del clúster.
Esta guía muestra cómo implementar complementos en el grupo de nodos del `system` mediante la tolerancia `CriticalAddonsOnly` y los selectores de nodos adecuados. Si sigue estos pasos, podrá asegurarse de que las aplicaciones críticas se programen en los nodos dedicados del `system`, aprovechando las ventajas de aislamiento y asignación de recursos que ofrece la estructura especializada de grupos de nodos del modo automático de EKS.
El modo automático de EKS tiene dos grupos de nodos integrados: `general-purpose` y `system`. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
El propósito del grupo de nodos del `system` es segregar los complementos críticos en diferentes nodos. Los nodos aprovisionados por el grupo de nodos del `system` tienen una taint de Kubernetes `CriticalAddonsOnly`. Kubernetes solo programará los pods en estos nodos si tienen la tolerancia correspondiente. Para obtener más información, consulte [Taints y toleraciones](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en la documentación de Kubernetes.
## Requisitos previos
+ Clúster de modo automático de EKS con el grupo de nodos de `system` integrado habilitado. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md)
+ `kubectl` instalado y configurado Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Procedimiento
Revise el ejemplo de yaml que aparece a continuación. Tenga en cuenta las siguientes condiciones:
+ `nodeSelector`: esto asocia la carga de trabajo con el grupo de nodos integrado del `system`. Este grupo de nodos debe estar habilitado con la API AWS. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
+ `tolerations`: esta tolerancia supera la taint de `CriticalAddonsOnly` en los nodos del grupo de nodos del `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Para actualizar una carga de trabajo de modo que se ejecute en el grupo de nodos del `system`, deberá:
1. Actualizar la carga de trabajo existente para agregar las siguientes configuraciones descritas anteriormente:
+ `nodeSelector`
+ `tolerations`
1. Implementar la carga de trabajo actualizada en el clúster con `kubectl apply`
Tras actualizar la carga de trabajo, se ejecutará en nodos dedicados.
# Cómo utilizar las políticas de red con el modo automático de EKS
## Descripción general
A medida que los clientes escalan sus entornos de aplicaciones mediante EKS, el aislamiento del tráfico de la red se vuelve cada vez más fundamental para evitar el acceso no autorizado a los recursos tanto dentro como fuera del clúster. Esto es especialmente importante en un entorno de varios inquilinos con varias cargas de trabajo no relacionadas que se ejecutan en paralelo en el clúster. Las políticas de red de Kubernetes le permiten mejorar la posición de seguridad de la red para sus cargas de trabajo de Kubernetes y sus integraciones con los puntos de conexión externos al clúster. El modo automático de EKS admite distintos tipos de políticas de red.
### Aislamiento de las capas 3 y 4
Las políticas de red estándar de Kubernetes operan en las capas 3 y 4 del modelo de red OSI y le permiten controlar el flujo de tráfico en la dirección IP o el puerto dentro del clúster de Amazon EKS.
#### Casos de uso
+ Segmente el tráfico de red entre las cargas de trabajo para garantizar que solo las aplicaciones relacionadas puedan comunicarse entre sí.
+ Aísle los inquilinos del espacio de nombres mediante políticas que impongan la separación de la red.
### Aplicación basada en DNS
Los clientes suelen implementar cargas de trabajo en EKS que forman parte de un entorno distribuido más amplio, algunas de las cuales tienen que comunicarse con sistemas y servicios externos al clúster (tráfico en dirección norte). Estos sistemas y servicios pueden estar en la nube de AWS o completamente fuera de AWS. Las políticas basadas en el sistema de nombres de dominio (DNS) le permiten reforzar su posición de seguridad mediante la adopción de un enfoque más estable y predecible para evitar el acceso no autorizado desde los pods a los recursos o puntos de conexión externos al clúster. Este mecanismo elimina la necesidad de hacer un seguimiento manual de direcciones IP específicas y permitir incluirlas en una lista. Al proteger los recursos con un enfoque basado en DNS, también tiene más flexibilidad para actualizar la infraestructura externa sin tener que flexibilizar la posición de seguridad ni modificar las políticas de red en caso de cambios en los servidores y hosts ascendentes. Puede filtrar el tráfico de salida hacia puntos de conexión externos mediante un nombre de dominio completo (FQDN) o un patrón coincidente para un nombre de dominio de DNS. Esto le ofrece la flexibilidad adicional de ampliar el acceso a varios subdominios asociados a un punto de conexión externo al clúster en particular.
#### Casos de uso
+ Estandarice según un enfoque basado en DNS para filtrar el acceso desde un entorno de Kubernetes a los puntos de conexión externos al clúster.
+ Proteja el acceso a los servicios de AWS en un entorno de varios inquilinos.
+ Administre el acceso a la red desde los pods hasta las cargas de trabajo en las instalaciones en sus entornos de nube híbrida.
### Reglas de administración (o según el ámbito del clúster)
En algunos casos, como en los escenarios de varios inquilinos, es posible que los clientes tengan que aplicar un estándar de seguridad de red a todo el clúster. En lugar de definir y mantener de forma repetitiva una política distinta para cada espacio de nombres, puede usar una política única para administrar de forma centralizada los controles de acceso a la red para las diferentes cargas de trabajo del clúster, independientemente de su espacio de nombres. Estos tipos de políticas le permiten ampliar el ámbito de aplicación de las reglas de filtrado de red que se aplican en las capas 3 y 4 y cuando se utilizan las reglas de DNS.
#### Casos de uso
+ Administre de forma centralizada los controles de acceso a la red para todas las cargas de trabajo (o un subconjunto de ellas) del clúster de EKS.
+ Defina una posición de seguridad de red predeterminada en todo el clúster.
+ Amplíe los estándares de seguridad de la organización al ámbito del clúster de una manera más eficiente desde el punto de vista operativo.
## Introducción
### Requisitos previos
+ Un clúster de Amazon EKS con el modo automático de EKS habilitado
+ kubectl configurado para conectarse al clúster
### Paso 1: Habilitación del controlador de políticas de red
Para utilizar las políticas de red con el modo automático de EKS, primero debe habilitar el controlador de políticas de red, para lo cual se aplica un ConfigMap al clúster.
1. Cree un archivo denominado `enable-network-policy.yaml` con el siguiente contenido:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Aplique el ConfigMap al clúster
```
kubectl apply -f enable-network-policy.yaml
```
### Paso 2: Cómo crear y probar políticas de red
El clúster del modo automático de EKS ya está configurado para admitir las políticas de red de Kubernetes. Puede probar esto con la [Demostración de Stars de política de red para Amazon EKS](network-policy-stars-demo.md).
### Paso 3: Ajustar la configuración del agente de políticas de red en la clase de nodo (opcional)
Opcionalmente, puede crear una nueva clase de nodo para cambiar el comportamiento predeterminado del agente de políticas de red en los nodos o habilitar el registro de eventos de políticas de red. Para ello, sigue estos pasos:
1. Cree o edite un archivo YAML de Clase de nodo (por ejemplo, `nodeclass-network-policy.yaml`) con el siguiente contenido:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Aplique la configuración de Clase de nodo al clúster:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifique que se haya creado la Clase de nodo:
```
kubectl get nodeclass network-policy-config
```
1. Actualice el Grupo de nodos para utilizar esta Clase de nodo. 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).
## ¿Cómo funciona?
### Política de red basada en DNS
![\[Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/apply-dns-policy-2.png)
1. El equipo de la plataforma aplica una política basada en DNS al clúster de EKS.
1. El controlador de políticas de red es responsable de supervisar la creación de políticas dentro del clúster y, a continuación, conciliar los puntos de conexión de las políticas. En este caso de uso, el controlador de políticas de red indica al agente de nodos que filtre las solicitudes de DNS en función de los dominios permitidos en la política creada. Los nombres de dominio se enumeran en la lista de dominios permitidos mediante el FQDN o un nombre de dominio que coincida con un patrón definido en la configuración de recursos de Kubernetes.
1. La carga de trabajo A intenta resolver la IP de un punto de conexión externo al clúster. La solicitud de DNS pasa primero por un proxy que filtra dichas solicitudes en función de la lista de solicitudes permitidas aplicada a través de la política de red.
1. Una vez que la solicitud de DNS pasa por la lista de filtros de DNS permitidos, se envía por proxy a CoreDNS.
1. A su vez, CoreDNS envía la solicitud al Solucionador de DNS externo (Amazon Route 53 Resolver) para obtener la lista de direcciones IP detrás del nombre de dominio.
1. Las IP resueltas con TTL se devuelven en respuesta a la solicitud de DNS. A continuación, estas direcciones IP se escriben en un mapa de eBPF que se utiliza en el siguiente paso para la aplicación de la capa de IP.
1. A continuación, las sondas de eBPF conectadas a la interfaz veth del pod filtrarán el tráfico de salida de la carga de trabajo A al punto de conexión externo del clúster en función de las reglas vigentes. Esto garantiza que los pods solo puedan enviar tráfico externo al clúster a las IP de los dominios de la lista de dominios permitidos. La validez de estas IP se basa en el TTL obtenido del Solucionador de DNS externo (Amazon Route 53 Resolver).
#### Uso de la política de red de la aplicación
La `ApplicationNetworkPolicy` combina las capacidades de las políticas de red estándar de Kubernetes con el filtrado basado en DNS del espacio de nombres mediante una única definición de recursos personalizados (CRD). Por lo tanto, `ApplicationNetworkPolicy` se puede utilizar para:
1. Definir las restricciones en las capas 3 y 4 de la pila de red mediante bloques de IP y números de puerto.
1. Definir reglas que operen en la capa 7 de la pila de red y permitir filtrar el tráfico en función de los FQDN.
**importante**
Las reglas basadas en DNS definidas mediante `ApplicationNetworkPolicy` solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS. `ApplicationNetworkPolicy` admite todos los campos de la `NetworkPolicy` de Kubernetes estándar, con un filtro de FQDN adicional para las reglas de salida.
**aviso**
No utilice el mismo nombre para una `ApplicationNetworkPolicy` y una `NetworkPolicy` dentro del mismo espacio de nombres. Si los nombres colisionan, es posible que los objetos `PolicyEndpoints` resultantes no reflejen ninguna de las políticas correctamente. Ambos recursos se aceptan sin errores, lo que dificulta el diagnóstico de este problema.
Para resolver un conflicto de nomenclatura, cambie el nombre de `ApplicationNetworkPolicy` o de `NetworkPolicy` para que sean únicos dentro del espacio de nombres y, a continuación, compruebe que los objetos `PolicyEndpoints` correspondientes se hayan actualizado correctamente.
#### Ejemplo
Tiene una carga de trabajo en el clúster del modo automático de EKS que necesita comunicarse con una aplicación en las instalaciones que se encuentra detrás de un equilibrador de carga con un nombre de DNS. Para ello, puede utilizar la siguiente política de red:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
En la red de Kubernetes, esto permitiría salir de cualquier pod del espacio de nombres “galaxy” etiquetado con `role: backend` para conectarse al nombre de dominio **myapp.mydomain.com** en el puerto TCP 8080. Además, tendría que configurar la conectividad de red para el tráfico de salida de la VPC al centro de datos corporativo.
![\[Ilustración de la carga de trabajo en el modo automático de EKS que se comunica con las aplicaciones en las instalaciones\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Política de red de administración (o del clúster)
![\[Ilustración del orden de evaluación de las políticas de red en EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/evaluation-order.png)
#### Uso de la política de red del clúster
Cuando se usa una `ClusterNetworkPolicy`, las políticas del nivel de administración se evalúan primero y no se pueden anular. Una vez evaluadas las políticas del nivel de administración, se utilizan las políticas estándar del ámbito del espacio de nombres para ejecutar las reglas de segmentación de red aplicadas. Esto se puede lograr mediante el uso de `ApplicationNetworkPolicy` o `NetworkPolicy`. Por último, se aplicarán las reglas del nivel de línea de base que definen las restricciones de red predeterminadas para las cargas de trabajo de los clústeres. Si es necesario, las políticas del ámbito del espacio de nombres **pueden** anular estas reglas del nivel de línea de base.
#### Ejemplo
Tiene una aplicación en el clúster que desea aislar de las cargas de trabajo de otros inquilinos. Puede bloquear de forma explícita el tráfico del clúster desde otros espacios de nombres para impedir el acceso de la red al espacio de nombres confidencial de la carga de trabajo.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Consideraciones
### Descripción del orden de evaluación de políticas
Las capacidades de políticas de red compatibles con EKS se evalúan en un orden específico para garantizar una administración del tráfico predecible y segura. Por lo tanto, es importante comprender el flujo de evaluación para diseñar una posición de seguridad de red efectiva para el entorno.
1. **Políticas del nivel de administración (se evalúan primero)**: todas las ClusterNetworkPolicies del nivel de administración se evalúan antes que cualquier otra política. En el nivel de administración, las políticas se procesan por orden de prioridad (se comienza por el número de prioridad más baja). El tipo de acción determina lo que sucede a continuación.
+ **Acción de denegación (máxima prioridad)**: cuando una política de administración con una acción de denegación coincide con el tráfico, ese tráfico se bloquea inmediatamente, independientemente de cualquier otra política. No se procesan más reglas de ClusterNetworkPolicy ni NetworkPolicy. Esto garantiza que las políticas del espacio de nombres no puedan anular los controles de seguridad de toda la organización.
+ **Acción de permiso**: una vez evaluadas las reglas de denegación, las políticas de administración que incluyen acciones de permiso se procesan por orden de prioridad (se comienza por el número de prioridad más baja). Cuando una acción de permiso coincide, se acepta el tráfico y no se lleva a cabo ninguna otra evaluación de la política. Estas políticas pueden conceder el acceso a varios espacios de nombres en función de los selectores de etiquetas, lo que proporciona un control centralizado sobre qué cargas de trabajo pueden acceder a recursos específicos.
+ **Acción de transferencia**: las acciones de transferencia en las políticas del nivel de administración delegan la toma de decisiones a los niveles inferiores. Cuando el tráfico coincide con una regla de transferencia, la evaluación omite todas las reglas del nivel de administración restantes para ese tráfico y continúa directamente con el nivel de la NetworkPolicy. Esto permite a los administradores delegar explícitamente el control de determinados patrones de tráfico a los equipos de aplicaciones. Por ejemplo, puede usar reglas de transferencia para delegar la administración del tráfico dentro del espacio de nombres a los administradores del espacio de nombres y, al mismo tiempo, mantener controles estrictos sobre el acceso externo.
1. **Nivel de política de red**: si ninguna política del nivel de administración coincide con ninguna acción de denegación o permiso, o si coincide con una acción de transferencia, se evalúan los recursos de la ApplicationNetworkPolicy y de la NetworkPolicy tradicional del ámbito del espacio de nombres. Estas políticas proporcionan un control detallado dentro de los espacios de nombres individuales y las administran los equipos de aplicaciones. Las políticas relacionadas con el espacio de nombres solo pueden ser más restrictivas que las políticas de administración. No pueden anular ninguna decisión de denegación de una política de administración, pero pueden restringir aún más el tráfico permitido o transferido por las políticas de administración.
1. **Políticas de administración del nivel de línea de base**: si ninguna política de administración o del ámbito del espacio de nombres coincide con el tráfico, se evalúan las ClusterNetworkPolicies del nivel de línea de base. Proporcionan posiciones de seguridad predeterminadas que pueden ser anuladas por políticas del ámbito del espacio de nombres, lo que permite a los administradores establecer valores predeterminados para toda la organización y, al mismo tiempo, ofrecer a los equipos la flexibilidad necesaria para personalizarlas según sea necesario. Las políticas de referencia se evalúan por orden de prioridad (se comienza por el número de prioridad más baja).
1. **Denegación de forma predeterminada (si ninguna política coincide)**: este comportamiento de denegación de forma predeterminada garantiza que solo se permitan las conexiones explícitamente permitidas, lo que mantiene una posición de seguridad sólida.
### Aplicación del principio de privilegio mínimo
+ **Inicio con políticas restrictivas y adición de permisos gradualmente según sea necesario**: comience por implementar políticas de denegación de forma predeterminada en el clúster y, a continuación, agregue reglas de autorización de forma gradual según valide los requisitos de conectividad legítimos. Este enfoque obliga a los equipos a justificar de forma explícita cada conexión externa, lo que crea un entorno más seguro y auditable.
+ **Auditoría y eliminación periódicas de las reglas de políticas no utilizadas**: las políticas de red pueden acumularse con el tiempo a medida que las aplicaciones evolucionan y dejar atrás reglas obsoletas que amplían innecesariamente la superficie expuesta a ataques. Implemente un proceso de revisión periódico para identificar y eliminar las reglas de políticas que ya no sean necesarias, lo que garantiza que su posición de seguridad siga siendo estricta y fácil de mantener.
+ **Uso de nombres de dominio específico en lugar de patrones amplios cuando sea posible**: si bien los patrones de comodines como `*.amazonaws.com` proporcionan conveniencia, también otorgan acceso a una amplia gama de servicios. Siempre que sea posible, especifique nombres de dominio exactos como `s3.us-west-2.amazonaws.com` para limitar el acceso solo a los servicios específicos que requieren las aplicaciones, lo que reduce el riesgo de movimientos laterales si la carga de trabajo se ve comprometida.
### Uso de políticas basadas en DNS en EKS
+ Las reglas basadas en DNS definidas mediante la `ApplicationNetworkPolicy` solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS. Si ejecuta un clúster de modo mixto (compuesto por nodos de trabajo del modo automático de EKS y nodos que no son del modo automático de EKS), las reglas basadas en DNS solo son efectivas en los nodos de trabajo del modo automático de EKS (instancias administradas de EC2).
### Validación de las políticas de DNS
+ **Uso de clústeres de almacenamiento provisional que reflejen la topología de la red de producción para llevar a cabo pruebas**: el entorno de pruebas debe replicar la arquitectura de la red, las dependencias externas y los patrones de conectividad de la producción para garantizar la precisión de las pruebas de políticas. Esto incluye configuraciones de VPC coincidentes, comportamiento de resolución de DNS y acceso a los mismos servicios externos que requieren las cargas de trabajo de producción.
+ **Implementación de pruebas automatizadas para rutas de red críticas**: cree pruebas automatizadas que validen la conectividad con los servicios externos esenciales como parte del proceso de CI/CD. Estas pruebas deben verificar que se permiten los flujos de tráfico legítimos mientras se bloquean las conexiones no autorizadas, lo que permite validar continuamente que las políticas de red mantengan la posición de seguridad correcta a medida que la infraestructura evoluciona.
+ **Supervisión del comportamiento de las aplicaciones tras los cambios en las políticas**: tras implementar políticas de red nuevas o modificadas en el entorno de producción, supervise de cerca los registros de las aplicaciones, las tasas de errores y las métricas de rendimiento para identificar rápidamente cualquier problema de conectividad. Establezca procedimientos de reversión claros para poder revertir rápidamente los cambios en las políticas si provocan un comportamiento inesperado de las aplicaciones o interrupciones en el servicio.
### Interacción con el firewall de DNS de Amazon Route 53
Las políticas de administración y de red de EKS se evalúan primero en el pod cuando se inicia el tráfico. Si una política de red de EKS permite la salida a un dominio específico, el pod lleva a cabo una consulta de DNS que llega a Route 53 Resolver. En este punto, se evalúan las reglas de firewall de DNS de Route 53. Si el firewall de DNS bloquea la consulta del dominio, se produce un error en la resolución de DNS y no se puede establecer la conexión, aunque la política de red de EKS lo permita. Esto crea capas de seguridad complementarias: las políticas de red basadas en DNS de EKS proporcionan un control de salida de pods para los requisitos de acceso específicos de la aplicación y los límites de seguridad de varios inquilinos, mientras que el firewall de DNS proporciona protección en toda la VPC contra los dominios maliciosos conocidos y aplica las listas de bloqueo en toda la organización.
# Etiquetado de subredes para el modo automático de EKS
Si utiliza la capacidad de equilibrio de carga del modo automático de EKS, debe agregar etiquetas de AWS a las subredes de la VPC.
## Introducción
Estas etiquetas identifican las subredes como asociadas al clúster y, lo que es más importante, si la subred es pública o privada.
Las subredes públicas tienen acceso directo a Internet a través de una puerta de enlace de Internet. Se utilizan para recursos que deben ser de acceso público, como los equilibradores de carga.
Las subredes privadas no tienen acceso directo a Internet y utilizan puertas de enlace de NAT para el tráfico saliente. Se utilizan para recursos internos, como los nodos de EKS, que no necesitan direcciones IP públicas.
Para obtener más información sobre las puertas de enlace de NAT y las puertas de enlace de Internet, consulte [Conectar la VPC a otras redes](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) en la Guía del usuario de Amazon Virtual Private Cloud (VPC).
## Requisito
En este momento, las subredes que utiliza el modo automático de EKS para equilibrar la carga deben tener una de las siguientes etiquetas.
### Subredes públicas
Las subredes públicas se utilizan para los equilibradores de carga expuestos a Internet. Estas subredes deben tener las siguientes etiquetas:
| Clave | Valor |
| --- | --- |
| `kubernetes.io/role/elb` | `1` o `` |
### Subredes privadas
Las subredes privadas se utilizan para los equilibradores de carga internos. Estas subredes deben tener las siguientes etiquetas:
| Clave | Valor |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` o `` |
## Procedimiento
Antes de empezar, identifique qué subredes son públicas (con acceso a través de puertas de enlace de Internet) y cuáles son privadas (a través de puertas de enlace de NAT). Necesitará permisos para modificar los recursos de la VPC.
### Consola de administración de AWS
1. Abra la consola de Amazon VPC y vaya a **Subredes**.
1. Seleccione la subred que desea etiquetar.
1. Elija la pestaña **Etiquetas** y seleccione **Agregar etiqueta**.
1. Agregue la etiqueta adecuada:
+ Para subredes públicas: Clave=`kubernetes.io/role/elb`
+ Para subredes privadas: Clave=`kubernetes.io/role/internal-elb`
1. Defina el **Valor** en `1` o déjelo en blanco.
1. Guarde y repita el proceso para las subredes restantes.
### AWS CLI
Para subredes públicas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Para subredes privadas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Sustituya `subnet-ID` por su ID de subred real.
# Generación de informes de cumplimiento con el CIS desde los nodos de Kubernetes mediante la depuración de kubectl
En esta sección, se describe cómo generar informes de cumplimientos con el CIS (Center for Internet Security) para los nodos de Amazon EKS mediante el comando `kubectl debug`. El comando le permite crear temporalmente un contenedor de depuración en un nodo de Kubernetes y ejecutar comprobaciones de cumplimiento con el CIS mediante la herramienta `apiclient`. La herramienta `apiclient` forma parte del sistema operativo Bottlerocket, utilizado por los nodos del modo automático de EKS.
## Requisitos previos
Antes de comenzar, asegúrese de que dispone de lo siguiente:
+ Acceso a un clúster de Amazon EKS con `kubectl` configurado (la versión debe ser al menos la v1.32.0; escriba `kubectl version` para comprobarlo).
+ Los permisos de IAM adecuados para depurar los nodos.
+ Un perfil válido que permita realizar operaciones de depuración (por ejemplo, `sysadmin`).
Para obtener más información sobre el uso de perfiles de depuración con `kubectl`, consulte [Depuración de un pod o nodo durante la aplicación de un perfil](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) en la documentación de Kubernetes.
## Procedimiento
1. Determine el ID de instancia de AWS del nodo en el que quiere ejecutar el informe. Use el siguiente comando para enumerar todos los nodos en el clúster. El ID de instancia se encuentra en la columna de nombre y comienza por `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Ejecute el siguiente comando y reemplace `` con el ID de instancia del nodo que desea consultar:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Los componentes de este comando incluyen los siguientes:
+ `kubectl debug node/`: crea una sesión de depuración en el ID de instancia EC2 especificado.
+ `-it`: asigna un TTY (intérprete de línea de comandos) y mantiene stdin abierto para su uso interactivo.
+ `--profile=sysadmin`: utiliza el perfil `kubectl` especificado con los permisos adecuados.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`: utiliza `amazonlinux:2023` como imagen contenedora para la depuración.
+ `bash -c "…"`: ejecuta los siguientes comandos en un intérprete de comandos bash:
+ `yum install -q -y util-linux-core`: instala silenciosamente el paquete de utilidades necesario.
+ `nsenter -t 1 -m`: ejecuta `nsenter` para introducir el espacio de nombres del proceso del host (PID 1).
+ `apiclient report cis --level 1 --format text`: ejecuta el informe de conformidad con el CIS en el nivel 1 con salida de texto.
1. Revise el resultado de texto del informe.
## Interpretación del resultado
El comando genera un informe basado en texto que muestra el estado de cumplimiento de varios controles del CIS. El resultado incluye lo siguiente:
+ ID de control del CIS individual
+ Descripción de cada control
+ Estado de aprobación, rechazo u omisión de cada comprobación
+ Detalles que explican cualquier problema de cumplimiento
Este es un ejemplo del resultado del informe ejecutado en una instancia de Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Para obtener más información sobre los valores de referencia, consulte [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) del Center for Internet Security (CIS).
## Recursos relacionados
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) en la documentación del sistema operativo Bottlerocket.
+ [Depurar pods en ejecución](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) en la documentación de Kubernetes.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) del Center for Internet Security (CIS)
# Habilitación del cifrado de volúmenes de EBS con claves de KMS administradas por el cliente para el modo automático de EKS
Puede cifrar el volumen raíz efímero de las instancias en el modo automático de EKS con una clave de KMS administrada por el cliente.
El modo automático de Amazon EKS utiliza roles vinculados a servicios para delegar permisos a otros servicios de AWS al administrar volúmenes de EBS cifrados para los clústeres de Kubernetes. Este tema describe cómo configurar la política de claves que necesita al especificar una clave administrada por el cliente para el cifrado de Amazon EBS con el modo automático de EKS.
Consideraciones:
+ El modo automático de EKS no necesita autorización adicional para usar la clave administrada por AWS predeterminada para proteger los volúmenes cifrados en la cuenta.
+ Este tema aborda el cifrado de volúmenes efímeros, es decir, los volúmenes raíz de las instancias de EC2. Para obtener más información sobre el cifrado de volúmenes de datos utilizados para cargas de trabajo, consulte [Creación de una clase de almacenamiento](create-storage-class.md).
## Descripción general
Las siguientes claves de AWS KMS se pueden utilizar para el cifrado del volumen raíz de Amazon EBS cuando el modo automático de EKS lanza instancias:
+ **Clave administrada por AWS**: una clave de cifrado en la cuenta que Amazon EBS crea, posee y administra. Esta es la clave de cifrado predeterminada en las cuentas nuevas.
+ **Clave administrada por el cliente**: una clave de cifrado personalizada que usted crea, posee y administra.
**nota**
La clave debe ser simétrica. Amazon EBS no es compatible con claves asimétricas administradas por el cliente.
## Paso 1: configuración de la política de claves
Las claves de KMS deben tener una política de claves que permita al modo automático de EKS lanzar instancias con volúmenes de Amazon EBS cifrados mediante una clave administrada por el cliente.
Configure la política de claves con la siguiente estructura:
**nota**
Esta política solo incluye permisos para el modo automático de EKS. Es posible que la política de claves necesite permisos adicionales si otras identidades deben usar la clave o administrar concesiones.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Asegúrese de reemplazar `` con el ID real de cuenta de AWS.
Al configurar la política de claves:
+ El `ClusterServiceRole` debe tener los permisos necesarios de IAM para usar la clave de KMS en operaciones de cifrado.
+ La condición `kms:GrantIsForAWSResource` garantiza que las concesiones solo se puedan crear para servicios de AWS.
## Paso 2: configuración de NodeClass con la clave administrada por el cliente
Después de configurar la política de claves, haga referencia a la clave de KMS en la configuración de NodeClass del modo automático de EKS:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
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
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
Sustituya los valores de marcador de posición por los valores reales.
+ `` por la región de AWS
+ `` por el ID de cuenta de AWS
+ `` por el ID de la clave de KMS
Puede especificar la clave de KMS con cualquiera de los siguientes formatos:
+ ID de clave de KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN de clave de KMS: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nombre del alias de la clave: `alias/eks-auto-mode-key`
+ ARN del alias de la clave: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Use kubectl para aplicar la configuración de NodeClass:
```
kubectl apply -f nodeclass.yaml
```
## Activos relacionados
+ [Creación de una clase de nodo para Amazon EKS](create-node-class.md)
+ Consulte más información en la Guía para desarrolladores de AWS Key Management Service
+ [Permisos para servicios de AWS en políticas de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Cómo cambiar una política de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Concesiones en AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Actualización de los controles de organización para el modo automático de EKS
Algunos controles de organización pueden impedir que el modo automático de EKS funcione correctamente. Si es así, debe actualizar estos controles para permitir que el modo automático de EKS disponga de los permisos necesarios para administarr las instancias de EC2 en su nombre.
El modo automático de EKS utiliza un rol de servicio para ejecutar las instancias de EC2 que respaldan los nodos del modo automático de EKS. Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que se crea en su cuenta y que un servicio asume para realizar acciones en su nombre. [Las políticas de control de servicio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) siempre se aplican a las acciones realizadas con los roles de servicio. Esto permite que una SCP inhiba las operaciones del modo automático. Lo más común es cuando se utiliza una SCP para restringir las imágenes de máquina de Amazon (AMI) que se pueden ejecutar. Para permitir el funcionamiento del modo automático de EKS, modifique la SCP para permitir la ejecución de las AMI desde las cuentas del modo automático de EKS.
También puede utilizar la característica de [AMI permitidas por EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) para limitar la visibilidad de las AMI en otras cuentas. Si utiliza esta característica, debe ampliar los criterios de imagen para incluir también las cuentas de AMI del modo automático de EKS en las regiones de interés.
## Ejemplo de SCP para bloquear todas las AMI excepto las AMI del modo automático de EKS
La siguiente SCP impide realizar llamadas a `ec2:RunInstances` a menos que la AMI pertenezca a la cuenta de AMI del modo automático de EKS para us-west-2 o us-east-1.
**nota**
Es importante **no** utilizar la clave de contexto `ec2:Owner`. Amazon es propietario de las cuentas AMI del modo automático de EKS y el valor de esta clave siempre será `amazon`. Crear una SCP que permita ejecutar AMI si `ec2:Owner` es `amazon` permitirá ejecutar cualquier AMI propiedad de Amazon, no solo las del modo automático de EKS.\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Cuentas de AMI de modo automático de EKS
Cuentas de AWS que varían según la región alojan las AMI públicas del modo automático de EKS.
| | |
| --- |--- |
| Región de AWS | Cuenta |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Asociación de direcciones IP públicas
Cuando se llama a `ec2:RunInstances`, el campo `AssociatePublicIpAddress` para el lanzamiento de una instancia se determina automáticamente en función del tipo de subred en la que se lanza la instancia. Se puede usar una SCP para exigir que este valor se establezca explícitamente en falso, independientemente del tipo de subred en la que se lance. En este caso, el campo `spec.advancedNetworking.associatePublicIPAddress` de NodeClass también se puede establecer en falso para cumplir con los requisitos de la SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS
Puede controlar la implementación de las cargas de trabajo en las [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). El modo automático de EKS admite reservas de capacidad bajo demanda (ODCR) de EC2 y bloques de capacidad de EC2 para ML.
**sugerencia**
De forma predeterminada, el modo automático de EKS se puede iniciar en los ODCR abiertos mediante la coincidencia abierta, pero no los prioriza. Las instancias lanzadas mediante una coincidencia abierta se etiquetan con `karpenter.sh/capacity-type: on-demand`, no con `reserved`. Para priorizar el uso de ODCR y etiquetar las instancias con `karpenter.sh/capacity-type: reserved`, configure `capacityReservationSelectorTerms` en la definición de NodeClass. Los bloques de capacidad para ML siempre requieren `capacityReservationSelectorTerms` y no se utilizan automáticamente.
## Reservas de capacidad bajo demanda (ODCR) de EC2
Las reservas de capacidad bajo demanda (ODCR) de EC2 le permiten reservar capacidad de computación para sus instancias de Amazon EC2 en una zona de disponibilidad específica por cualquier período. Cuando utilice el modo automático de EKS, le recomendamos controlar si sus cargas de trabajo de Kubernetes se implementan en estas instancias reservadas para maximizar la utilización de la capacidad previamente adquirida o para garantizar que las cargas de trabajo críticas tengan acceso a los recursos garantizados.
De forma predeterminada, el modo automático de EKS se inicia automáticamente en las ODCR abiertas. Sin embargo, cuando configura `capacityReservationSelectorTerms` en una NodeClass, puede controlar de forma explícita cuáles ODCR utilizan sus cargas de trabajo. Los nodos aprovisionados mediante ODCR configuradas tendrán `karpenter.sh/capacity-type: reserved` y se priorizarán frente a los nodos bajo demanda y nodos de spot. Una vez habilitada esta característica, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas; deben seleccionarse explícitamente mediante una NodeClass, lo que le permite controlar con precisión el uso de las reservas de capacidad en todo el clúster.
**aviso**
Si configura `capacityReservationSelectorTerms` en una NodeClass de un clúster, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas para *ninguna* NodeClass del clúster.
### Ejemplo de NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Este ejemplo de NodeClass muestra dos enfoques para seleccionar las ODCR. El primer método hace referencia directamente a una ODCR específica mediante su ID (`cr-56fac701cc1951b03`). El segundo método utiliza la selección basada en etiquetas y se dirige a las ODCR con la etiqueta `Name: "targeted-odcr"`. También puede filtrar opcionalmente por la cuenta de AWS propietaria de la reserva, lo cual es particularmente útil en escenarios de varias cuentas o cuando se trabaja con reservas de capacidad compartida.
## Bloques de capacidad de EC2 para ML
Los bloques de capacidad para ML reservan instancias de computación acelerada basadas en GPU en una fecha futura para admitir cargas de trabajo de machine learning (ML) de corta duración. Las instancias que se ejecutan en un bloque de capacidad se colocan automáticamente cerca dentro de Amazon EC2 UltraClusters para conseguir redes que no generen bloqueos, de escala de petabits y de baja latencia.
Para obtener más información acerca de las plataformas y los tipos de instancias compatibles, consulte [Bloques de capacidad para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) en la Guía del usuario de EC2.
Puede crear una NodeClass del modo automático EKS que utilice un bloque de capacidad para ML, similar a una ODCR (descrita anteriormente).
Los siguientes ejemplos de definiciones crean tres recursos:
1. Una NodeClass que hace referencia a la reserva del bloque de capacidad
1. Un NodePool que usa la NodeClass y aplica una taint
1. Una especificación de pod que tolera la taint y solicita recursos de la GPU
### Ejemplo de NodeClass
Esta NodeClass hace referencia a un bloque de capacidad específico para ML mediante su ID de reserva. Puede obtener este ID en la consola de EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
### NodePool de muestra
Este NodePool hace referencia a la NodeClass `gpu` y especifica una configuración importante:
+ **Solo** usa la capacidad reservada mediante la configuración `karpenter.sh/capacity-type: reserved`.
+ Solicita familias de instancias de GPU específicas adecuadas para las cargas de trabajo de ML.
+ Aplica una taint `nvidia.com/gpu` para garantizar que solo las cargas de trabajo de GPU estén programadas en estos nodos
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
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).
### Pod de ejemplo
Este pod de ejemplo muestra cómo configurar una carga de trabajo para que se ejecute en los nodos del bloque de capacidad:
+ Utiliza un **nodeSelector** para usar como destino tipos de GPU específicos (en este caso, GPU H200).
+ Incluye una **tolerancia** a la taint `nvidia.com/gpu` aplicada por el NodePool.
+ **Solicita explícitamente los recursos de la GPU** mediante el tipo de recurso `nvidia.com/gpu`.
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Para obtener más información, consulte [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) en la documentación de Kubernetes.
### Activos relacionados
+ [Bloques de capacidad para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) en la Guía del usuario de Amazon EC2
+ [Búsqueda y compra de bloques de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) en la Guía del usuario de Amazon EC2
+ [Administración de los recursos computacionales para las cargas de trabajo de IA/ML en Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimización de recursos de GPU y administración de costos](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) en la Guía de prácticas recomendadas de EKS
# Implementación de nodos del modo automático de EKS en Zonas locales
El modo automático de EKS proporciona una administración de clústeres simplificada con aprovisionamiento automático de nodos. Las Zonas locales de AWS amplían la infraestructura de AWS a ubicaciones geográficas más cercanas a los usuarios finales, lo que reduce la latencia de las aplicaciones sensibles a la latencia. En esta guía, obtendrá los pasos del proceso de implementación de nodos del modo automático de EKS en Zonas locales de AWS, lo que le permite ejecutar aplicaciones en contenedores con una latencia más baja para los usuarios de áreas geográficas específicas.
Además, también se muestra cómo utilizar taints y tolerancias de Kubernetes para garantizar que solo se ejecuten cargas de trabajo específicas en los nodos de Zonas locales, lo que lo ayuda a controlar los costos y optimizar el uso de recursos.
## Requisitos previos
Antes de comenzar a implementar los nodos del modo automático de EKS en Zonas Locales, asegúrese de cumplir los siguientes requisitos previos.
+ [Un clúster del modo automático de EKS existente](create-auto.md)
+ [Uso de la Zona local en su cuenta de AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Paso 1: creación de la subred de la Zona local
El primer paso para implementar los nodos del modo automático de EKS en una Zona local es crear una subred en esa Zona local. Esta subred proporciona la infraestructura de red para los nodos y les permite comunicarse con el resto de la VPC. Siga las instrucciones de [Creación de una subred de Zona local](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (en la Guía del usuario de Zonas locales de AWS) para crear una subred en la Zona local que elija.
**sugerencia**
Anote el nombre de la subred de la Zona local.
## Paso 2: creación de NodeClass para la subred de la Zona local
Después de crear la subred de la zona local, debe definir una NodeClass que haga referencia a esta subred. NodeClass es un recurso personalizado de Kubernetes que especifica los atributos de infraestructura de los nodos, lo que incluye las subredes, los grupos de seguridad y las configuraciones de almacenamiento que se deben utilizar. En el siguiente ejemplo, creamos una NodeClass llamada “local-zone” que tiene como destino una subred de la Zona local basada en su nombre. También puede usar el ID de la subred. Deberá adaptar esta configuración para que su destino sea la subred de la Zona local.
Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Paso 3: creación de NodePool con NodeClass y Taint
Con la NodeClass configurada, ahora debe crear un NodePool que use esta NodeClass. Un NodePool define las características de computación de los nodos, lo que incluye los tipos de instancias. El NodePool usa la NodeClass como referencia para determinar dónde se lanzarán las instancias.
En el siguiente ejemplo, creamos un NodePool que hace referencia a nuestra NodeClass “local-zone”. También agregamos una taint a los nodos para asegurarnos de que solo se puedan programar los pods con una tolerancia coincidente en estos nodos de la Zona local. Esto es especialmente importante para los nodos de la Zona local, que suelen tener costos más elevados y solo deberían utilizarlos las cargas de trabajo que se beneficien específicamente de la reducción de la latencia.
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).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
La taint con la clave `aws.amazon.com/local-zone` y el efecto `NoSchedule` garantiza que los pods que no tengan una tolerancia igual no se programen en estos nodos. De este modo, se evita que las cargas de trabajo normales se ejecuten accidentalmente en la Zona local, lo que podría generar costos inesperados.
## Paso 4: implementación de cargas de trabajo con tolerancia y afinidad de nodos
Para tener un control óptimo de la ubicación de la carga de trabajo en los nodos de la Zona local, utilice simultáneamente taints y tolerancias con la afinidad de nodos. A continuación se enumeran las ventajas de este enfoque combinado:
1. **Control de costos**: esta taint garantiza que solo los grupos con tolerancias explícitas puedan utilizar recursos de la Zona local que podrían resultar costosos.
1. **Ubicación garantizada**: la afinidad de nodos garantiza que las aplicaciones sensibles a la latencia se ejecuten exclusivamente en la Zona local, no en los nodos normales de un clúster.
A continuación se muestra un ejemplo de una implementación configurada para ejecutarse específicamente en los nodos de la Zona local:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Esta implementación tiene dos configuraciones de programación clave:
1. La **tolerancia** permite programar los pods en los nodos con la taint `aws.amazon.com/local-zone`.
1. El requisito de **afinidad de nodos** garantiza que estos pods solo se ejecuten en los nodos con la etiqueta `node-type: local-zone`.
En conjunto, garantizan que la aplicación sensible a la latencia se ejecute solo en los nodos de la Zona local y que las aplicaciones normales no consuman los recursos de la Zona local a menos que estén configuradas explícitamente para hacerlo.
## Paso 5: verificar con la consola de AWS
Tras configurar la NodeClass, el NodePool y las implementaciones, debe comprobar que los nodos se aprovisionen en la Zona local según lo previsto y que las cargas de trabajo se ejecuten en ellos. Puede usar la Consola de administración de AWS para comprobar que las instancias de EC2 se estén lanzando en la subred de la Zona local correcta.
Además, puede consultar la lista de nodos de Kubernetes que utilizan `kubectl get nodes -o wide` para confirmar que los nodos se unen al clúster con las etiquetas y los caracteres correctos:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
También puede verificar que los pods de las cargas de trabajo estén programados en los nodos de la Zona local:
```
kubectl get pods -o wide
```
Este enfoque garantiza que solo las cargas de trabajo que toleren específicamente la taint de la Zona local se programen en estos nodos, lo que lo ayuda a controlar los costos y a hacer un uso más eficiente de los recursos de la Zona local.
# Configuración de ajustes avanzados de seguridad para los nodos
En este tema, se describe cómo configurar ajustes avanzados de seguridad para nodos del modo automático de Amazon EKS mediante la especificación `advancedSecurity` en la clase de nodo.
## Requisitos previos
Antes de comenzar, asegúrese de que dispone de lo siguiente:
+ Un clúster del modo automático de Amazon EKS. Para obtener más información, consulte [Cómo crear un clúster con el modo automático de Amazon EKS](create-auto.md).
+ `kubectl` instalado y configurado Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
+ Explicación sobre la configuración de la clase de nodo. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## Configuración de ajustes avanzados de seguridad
Para configurar ajustes avanzados de seguridad para los nodos, establezca los campos `advancedSecurity` en la especificación de la clase de nodo:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Aplique esta configuración:
```
kubectl apply -f nodeclass.yaml
```
Haga referencia a esta clase de nodo 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).
## Descripción del campo
+ `fips` (booleano, opcional): cuando se establece en `true`, aprovisiona nodos con AMI que incluyen módulos criptográficos validados conforme a FIPS 140-2. Este ajuste selecciona AMI compatibles con FIPS; los clientes son responsables de administrar sus requisitos de cumplimiento. Para obtener más información, consulte [Cumplimiento de FIPS en AWS](https://aws.amazon.com/compliance/fips/). Valor predeterminado: `false`.
+ `kernelLockdown` (cadena, opcional): controla el modo del módulo de seguridad de bloqueo del kernel. Valores aceptados:
+ `integrity`: bloquea los métodos para sobrescribir la memoria del kernel o modificar el código del kernel. Impide la carga de módulos del kernel sin firma.
+ `none`: desactiva la protección de bloqueo del kernel.
Para obtener más información, consulte la [documentación sobre el bloqueo del kernel de Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Consideraciones
+ Las AMI compatibles con FIPS están disponibles en las regiones de AWS Este/Oeste de EE. UU., AWS GovCloud (EE. UU.) y AWS Canadá (centro/oeste). Para obtener más información, consulte [Cumplimiento de FIPS en AWS](https://aws.amazon.com/compliance/fips/).
+ Cuando utilice `kernelLockdown: "integrity"`, asegúrese de que las cargas de trabajo no requieran cargar módulos del kernel sin firma ni modificar la memoria del kernel.
## Recursos relacionados
+ [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md): guía completa de configuración de la clase de nodo
+ [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md): configuración del grupo de nodos