**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. # Más información sobre cómo funciona el modo automático de EKS Utilice este capítulo para aprender cómo funcionan los componentes de los clústeres del modo automático de Amazon EKS. **Topics** + [Más información sobre las instancias administradas del modo automático de Amazon EKS](automode-learn-instances.md) + [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md) + [Más información sobre las redes de VPC y el equilibrio de carga en el modo automático de EKS](auto-networking.md) # Más información sobre las instancias administradas del modo automático de Amazon EKS En este tema se explica la forma en que el modo automático de Amazon EKS administra las instancias de Amazon EC2 en el clúster de EKS. Al habilitar el modo automático de EKS, EKS aprovisiona y administra automáticamente los recursos de computación del clúster, lo que cambia la forma en que se interactúa con las instancias de EC2 que se desempeñan como nodos en el clúster. Comprender la forma en que el modo automático de Amazon EKS administra las instancias es esencial para planificar la estrategia de implementación de cargas de trabajo y los procedimientos operativos. A diferencia de las instancias de EC2 tradicionales o los grupos de nodos administrados, estas instancias siguen un modelo de ciclo de vida diferente en el que EKS asume la responsabilidad de varios aspectos operativos, a la vez que restringe ciertos tipos de acceso y personalización. El modo automático de Amazon EKS automatiza las tareas rutinarias de creación de nuevas instancias de EC2, a las que asocia como nodos al clúster de EKS. El modo automático de EKS detecta cuándo una carga de trabajo no cabe en los nodos existentes y crea una nueva instancia de EC2. El modo automático de Amazon EKS se encarga de crear y eliminar instancias de EC2, así como de aplicarles revisiones. Usted es responsable de los contenedores y pods implementados en la instancia. Las Instancias de EC2 creadas por el modo automático de EKS son diferentes de otras instancias de EC2, ya que se trata de instancias administradas. Estas instancias administradas son propiedad de EKS y tienen más restricciones. No puede acceder directamente ni instalar software en instancias administradas por el modo automático de EKS. AWS sugiere ejecutar el modo automático de EKS o el Karpenter autoadministrado. Puede instalar ambos durante una migración o en una configuración avanzada. Si ambos están instalados, configure los grupos de nodos de modo que las cargas de trabajo se asocien a Karpenter o al modo automático de EKS. Para obtener más información, consulte [Instancias administradas de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) en la Guía del usuario de Amazon EC2. ## Tabla de comparación | Instancia de EC2 estándar | Instancia administrada del modo automático de EKS | | --- | --- | | Usted es responsable de aplicar revisiones a la instancia y de actualizarla. | AWS aplica revisiones y actualizaciones a la instancia de forma automática. | | EKS no se hace responsable del software presente en la instancia. | EKS es responsable de cierto software en la instancia, como `kubelet`, el tiempo de ejecución del contenedor y el sistema operativo. | | Puede eliminar la Instancia de EC2 mediante la API de EC2. | EKS determina la cantidad de instancias implementadas en la cuenta. Si elimina una carga de trabajo, EKS reducirá la cantidad de instancias en la cuenta. | | Puede utilizar SSH para acceder a la Instancia de EC2. | Puede implementar pods y contenedores en la instancia administrada. | | Usted determina el sistema operativo y la imagen (AMI). | AWS determina el sistema operativo y la imagen | | Puede implementar cargas de trabajo que se basen en la funcionalidad de Windows o Ubuntu. | Puede implementar contenedores basados en Linux, pero sin dependencias específicas del sistema operativo. | | Usted determina qué tipo de instancia y familia lanzar. | AWS determina qué tipo de instancia y familia lanzar. Puede utilizar un grupo de nodos para limitar los tipos de instancias de los que el modo automático de EKS puede seleccionar. | La siguiente funcionalidad funciona tanto para instancias administradas como para instancias de EC2 estándar: + Puede ver la instancia en la consola de AWS. + Puede usar el almacenamiento de instancias como almacenamiento efímero para las cargas de trabajo. ### Soporte de AMI Con el modo automático de EKS, AWS determina la imagen (AMI) utilizada para los nodos de computación. AWS supervisa el despliegue de las nuevas versiones de la AMI del modo automático de EKS. Si tiene problemas de carga de trabajo relacionados con una versión de la AMI, cree un caso de soporte. Para obtener más información, consulte [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) en la Guía del usuario de AWS Support. Por lo general, EKS lanza una nueva AMI cada semana que contiene correcciones de seguridad y CVE. ## Referencia de instancias compatibles con el modo automático de EKS El modo automático de EKS solo crea instancias de los tipos compatibles y que cumplen con un requisito de tamaño mínimo. El modo automático de EKS admite los siguientes tipos de instancias: | Familia | Tipos de instancias | | --- | --- | | Optimizadas para la computación (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 | | Uso general (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 | | Optimizada para memoria (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 | | Ampliable (T) | t4g, t3, t3a, t2 | | Memoria elevada (Z/X) | z1d, x8g, x2gd | | Optimizadas para el almacenamiento (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | Computación acelerada (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | Computación de alto rendimiento (X2) | x2iezn, x2iedn, x2idn | Además, el modo automático de EKS solo creará instancias de EC2 que cumplan los siguientes requisitos: + Más de 1 CPU + El tamaño de la instancia no es nano, micro ni pequeño Para obtener más información, consulte [Convenciones de nomenclatura de tipos de instancias de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html). ## Servicio de metadatos de instancias + El modo automático de EKS aplica IMDSv2 con un límite de saltos de 1 de forma predeterminada, siguiendo las prácticas recomendadas de seguridad de AWS. + Esta configuración predeterminada no se puede modificar en el modo automático. + Para los complementos que normalmente requieren acceso al IMDS, proporcione parámetros (como la región de AWS) durante la instalación para evitar búsquedas en el IMDS. Para obtener más información, consulte [Determinación de los campos que se pueden personalizar para los complementos de Amazon EKS](kubernetes-field-management.md). + Si un pod requiere acceso al IMDS cuando se ejecuta en modo automático, debe configurar el pod para que se ejecute con `hostNetwork: true`. Esto permite que el pod acceda directamente al servicio de metadatos de la instancia. + Tenga en cuenta las implicaciones de seguridad a la hora de conceder a los pods acceso a los metadatos de la instancia. Para obtener más información acerca del servicio de metadatos de instancias (IMDS) de Amazon EC2, consulte [Configuración de las opciones del servicio de metadatos de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) en la *Guía del usuario de Amazon EC2*. ## Consideraciones + Si el almacenamiento efímero configurado en NodeClass es más pequeño que el almacenamiento local NVMe de la instancia, el modo automático de EKS elimina la necesidad de realizar una configuración manual, ya que toma automáticamente las siguientes medidas: + Utiliza un volumen de datos de Amazon EBS más pequeño (20 GiB) para reducir los costos. + Formatea y configura el almacenamiento local NVMe para el uso efímero de datos. Esto incluye configurar una matriz RAID 0 si hay varias unidades NVMe. + Cuando `ephemeralStorage.size` iguala o supera la capacidad de NVMe local, se producen las siguientes acciones: + El Modo automático omite el volumen pequeño de EBS. + Las unidades NVMe se exponen directamente a su carga de trabajo. + El modo automático de Amazon EKS no admite las siguientes acciones del servicio de inyección de errores de AWS: + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + El modo automático de Amazon EKS admite las acciones de pods de EKS del servicio de inyección de errores de AWS. Para obtener más información, consulte [Administración de experimentos del servicio de inyección de errores](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) y [Uso de las acciones aws:eks:pod del FID de AWS](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) en la Guía del usuario de AWS Resilience Hub. + No es necesario instalar el `Neuron Device Plugin` en los nodos del modo automático de EKS. Si tiene otros tipos de nodos en el clúster, deberá configurar el complemento Neuron Device de modo que no se ejecute en nodos de modo automático. 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). # Más información sobre las identidades y el acceso en el modo automático de EKS En este tema se describen los roles y permisos de Identity and Access Management (IAM) que se necesitan para utilizar el modo automático de EKS. El modo automático de EKS utiliza dos roles de IAM principales: un rol de IAM de clúster y un rol de IAM del nodo. Estos roles funcionan conjuntamente con EKS Pod Identity y las entradas de acceso de EKS para proporcionar una administración de acceso completa para los clústeres de EKS. Al configurar el modo automático de EKS, deberá establecer estos roles de IAM con permisos específicos que permitan a los servicios de AWS interactuar con los recursos del clúster. Esto incluye permisos para administrar recursos de computación, volúmenes de almacenamiento, equilibradores de carga y componentes de red. Comprender estas configuraciones de roles resulta esencial para el correcto funcionamiento y la seguridad del clúster. En el modo automático de EKS, los roles de AWS IAM se asignan automáticamente a los permisos de Kubernetes a través de las entradas de acceso de EKS, por lo que no es necesario configurar manualmente ConfigMaps `aws-auth` ni vínculos personalizados. Al crear un nuevo clúster en modo automático, EKS crea automáticamente los permisos de Kubernetes correspondientes mediante entradas de acceso, lo que garantiza que los servicios de AWS y los componentes del clúster cuenten con los niveles de acceso adecuados en los sistemas de autorización de AWS y Kubernetes. Esta integración automatizada reduce la complejidad de la configuración y ayuda a evitar los problemas relacionados con los permisos que se producen por lo general al administrar clústeres de EKS. ## Rol de IAM de clúster El rol de IAM del clúster es un rol de AWS Identity and Access Management (IAM) que Amazon EKS utiliza para administrar los permisos de los clústeres de Kubernetes. Este rol concede a Amazon EKS los permisos necesarios para interactuar con otros servicios de AWS en nombre del clúster y se configura automáticamente con los permisos de Kubernetes mediante las entradas de acceso de EKS. + Debe asociar las políticas de AWS IAM a este rol. + El modo automático de EKS asigna permisos de Kubernetes a este rol automáticamente mediante entradas de acceso de EKS. + Con el modo automático de EKS, AWS sugiere crear un único rol de IAM de clúster por cuenta de AWS. + AWS sugiere asignar el nombre `AmazonEKSAutoClusterRole` a este rol. + Este rol requiere permisos para varios servicios de AWS para administrar recursos, incluidos volúmenes de EBS, equilibradores de carga elásticos e instancias de EC2. + La configuración sugerida para este rol incluye múltiples políticas de IAM administradas de AWS, relacionadas con las diferentes capacidades del modo automático de EKS. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` Para obtener más información sobre el rol de IAM de clúster y las políticas de IAM administradas por AWS, consulte: + [Políticas administradas de AWS para Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md) Para obtener más información sobre el acceso a Kubernetes, consulte: + [Revisión de los permisos de la política de acceso](access-policy-permissions.md) ## Rol de IAM de nodo El rol de IAM del nodo es un rol de AWS Identity and Access Management (IAM) utilizado por Amazon EKS para administrar los permisos de los nodos de trabajo en los clústeres de Kubernetes. Este rol concede a las instancias de EC2 que se ejecutan como nodos de Kubernetes los permisos necesarios para interactuar con servicios y recursos de AWS, y se configura automáticamente con permisos RBAC de Kubernetes mediante entradas de acceso de EKS. + Debe asociar las políticas de AWS IAM a este rol. + El modo automático de EKS asigna permisos de RBAC de Kubernetes a este rol automáticamente mediante entradas de acceso de EKS. + AWS sugiere asignar el nombre `AmazonEKSAutoNodeRole` a este rol. + Con el modo automático de EKS, AWS sugiere crear un único rol de IAM del nodo por cuenta de AWS. + Este rol tiene permisos limitados. Los permisos clave incluyen asumir un rol de Pod Identity y extraer imágenes de ECR. + AWS sugiere las siguientes políticas de IAM administradas por AWS: + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` Para obtener más información sobre el rol de IAM de clúster y las políticas de IAM administradas por AWS, consulte: + [Políticas administradas de AWS para Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Rol de IAM de nodo de Amazon EKS](create-node-role.md) Para obtener más información sobre el acceso a Kubernetes, consulte: + [Revisión de los permisos de la política de acceso](access-policy-permissions.md) ## Rol vinculado a servicios Amazon EKS utiliza un rol vinculado al servicio (SLR) para determinadas operaciones. Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre. AWS crea y configura automáticamente el SLR. Solo puede eliminar un SLR después de haber eliminado primero sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos. La política del SLR concede a Amazon EKS permisos para observar y eliminar componentes básicos de la infraestructura: recursos de EC2 (instancias, interfaces de red, grupos de seguridad), recursos de ELB (equilibradores de carga, grupos de destino), capacidades de CloudWatch (registro y métricas) y roles de IAM con prefijo “eks”. También permite la conexión en red de puntos de conexión privados mediante la asociación de VPC/zonas alojadas e incluye permisos para la supervisión de EventBridge y la limpieza de recursos etiquetados con EKS. Para obtener más información, consulte: + [Política administrada de AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## Etiquetas personalizadas de AWS para los recursos del modo automático de EKS De forma predeterminada, las políticas administradas relacionadas con el modo automático de EKS no permiten aplicar etiquetas definidas por el usuario a los recursos de AWS aprovisionados en modo automático. Si desea aplicar etiquetas definidas por el usuario a los recursos de AWS, debe asociar permisos adicionales al rol de IAM del clúster con permisos suficientes para crear y modificar etiquetas en los recursos de AWS. A continuación, aparece un ejemplo de política que permitirá el acceso sin restricciones al etiquetado: ### Ver ejemplo de política de etiquetas personalizadas ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## Referencia de política de acceso Para obtener más información sobre los permisos de Kubernetes utilizados por el modo automático de EKS, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md). # Más información sobre las redes de VPC y el equilibrio de carga en el modo automático de EKS En este tema se explica cómo configurar las características de red y equilibrio de carga de la nube privada virtual (VPC) en el modo automático de EKS. Aunque el modo automático de EKS administra la mayoría de los componentes de red automáticamente, aún puede personalizar ciertos aspectos de la configuración de red del clúster a través de los recursos `NodeClass` y las anotaciones del equilibrador de carga. Al utilizar el modo automático de EKS, AWS administra la configuración de la interfaz de red de contenedores (CNI) de la VPC y el aprovisionamiento del equilibrador de carga de su clúster. Para influir en los comportamientos de red, puede definir objetos `NodeClass` y aplicar anotaciones específicas a los recursos de servicio y de ingreso, al tiempo que mantiene el modelo operativo automatizado que proporciona el modo automático de EKS. ## Capacidad de redes El modo automático de EKS tiene una nueva capacidad de red que gestiona las redes de nodos y pods. Para configurarla, puede crear un objeto `NodeClass` de Kubernetes. Las opciones de configuración de la CNI de AWS VPC anterior no se aplicarán al modo automático de EKS. ### Configuración de las redes con una `NodeClass` El recurso `NodeClass` del modo automático de EKS permite personalizar ciertos aspectos de la capacidad de la red. A través de `NodeClass`, puede especificar selecciones de grupos de seguridad, controlar la colocación de nodos a través de subredes de la VPC, establecer políticas SNAT, configurar políticas de red y habilitar el registro de eventos de red. Este enfoque mantiene el modelo operativo automatizado del modo automático de EKS a la vez que ofrece flexibilidad a la hora de personalizar la red. Puede utilizar `NodeClass` para: + Seleccionar un grupo de seguridad para los nodos + Controlar cómo se colocan los nodos en las subredes de la VPC + Establecer la política SNAT del nodo en `random` o `disabled` + Habilite las *políticas de red* de Kubernetes, que incluyen: + Establecer la política de red en Denegar de forma predeterminada o Permitir de forma predeterminada + Habilitar el registro de eventos de red en un archivo. + Conectar los pods a diferentes subredes para aislar el tráfico de los pods del tráfico de los nodos. Más información sobre la [Creación de una NodeClass de Amazon EKS](create-node-class.md). ### Consideraciones El modo automático de EKS admite: + Políticas de red de EKS. + Las opciones `HostPort` y `HostNetwork` para los pods de Kubernetes. + Nodos y pods en subredes públicas o privadas. + Almacenamiento en caché de las consultas de DNS en el nodo. El modo automático de EKS **no** admite: + Grupos de seguridad por pod (SGPP). Para aplicar grupos de seguridad independientes al tráfico del pod en modo automático, use `podSecurityGroupSelectorTerms` en `NodeClass` en su lugar. Para obtener más información, consulte [Subredes y grupos de seguridad independientes para pods](create-node-class.md#pod-subnet-selector). + Redes personalizadas en `ENIConfig`. Puede colocar los pods en varias subredes o aislarlos exclusivamente del tráfico del nodo con [Subredes y grupos de seguridad independientes para pods](create-node-class.md#pod-subnet-selector). + Configuraciones de IP en calentamiento, prefijos en calentamiento y ENI en calentamiento. + Configuración mínima de destinos de la IP. + Otras configuraciones admitidas por la CNI de VPC de AWS de código abierto. + Configuraciones de políticas de red, como la personalización del temporizador conntrack (el valor predeterminado es 300s). + Cómo exportar registros de eventos de red a CloudWatch. ### Administración de recursos de red El modo automático de EKS gestiona la administración de prefijos, direcciones IP e interfaces de red mediante la supervisión de los recursos de NodeClass para las configuraciones de red. El servicio realiza varias operaciones clave de forma automática: **Delegación de prefijos** El modo automático de EKS utiliza de forma predeterminada la delegación de prefijos (prefijos /28) para las redes de pods y mantiene un grupo de calentamiento predefinido de recursos de IP que se escala en función del número de pods programados. Cuando se detecta la fragmentación de la subred de los pods, el modo automático aprovisiona direcciones IP secundarias (/32). Gracias a este algoritmo de red de pods predeterminado, el modo automático calcula el número máximo de pods por nodo en función del número de ENI e IP que se admiten por tipo de instancia (con la suposición del peor de los casos de fragmentación). Para obtener más información sobre la cantidad máxima de ENI e IP que se admiten por tipo de instancia, consulte [Máximo de direcciones IP por interfaz de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) en la Guía del usuario de Amazon EC2. Las familias de instancias de nueva generación (Nitro v6 y versiones posteriores) suelen tener más ENI e IP por tipo de instancia, y el modo automático ajusta el cálculo del número máximo de pods en consecuencia. En el caso de los clústeres IPv6, solo se utiliza la delegación de prefijos y el modo automático siempre utiliza un límite máximo de 110 pods por nodo. **Gestión de la recuperación** El servicio implementa un conjunto de recuperación para los prefijos o las direcciones IPv4 secundarias que ya no se utilizan. Una vez transcurrido el periodo de recuperación, estos recursos se devuelven a la VPC. Sin embargo, si los pods reutilizan estos recursos durante el periodo de recuperación, se restauran del conjunto de recuperación. **Compatibilidad con IPv6** Para los clústeres de IPv6, el modo automático de EKS proporciona un prefijo de IPv6 `/80` por nodo en la interfaz de red principal. Cuando se usa `podSubnetSelectorTerms`, el prefijo se asigna en una interfaz de red secundaria en la subred del pod en su lugar. El servicio también garantiza una administración adecuada y la recopilación de elementos no utilizados de todas las interfaces de red. ## Equilibrio de carga Se configuran los equilibradores de carga elásticos de AWS aprovisionados por el modo automático de EKS mediante anotaciones en los recursos de servicio y de ingreso. Para obtener más información, consulte [Creación de una IngressClass para configurar el equilibrador de carga de aplicación](auto-configure-alb.md) o [Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red](auto-configure-nlb.md). ### Consideraciones para el equilibrio de carga con el modo automático de EKS + El modo de asignación de destino predeterminado es el modo de IP, no el modo de instancia. + El modo automático de EKS solo admite el modo de grupo de seguridad para los equilibradores de carga de red. + AWS no admite la migración de los equilibradores de carga del controlador del equilibrador de carga de AWS autoadministrado a la administración mediante el modo automático de EKS. + No se admite el campo `networking.ingress.ipBlock` en la especificación `TargetGroupBinding`. + Si los nodos de trabajo utilizan grupos de seguridad personalizados (no un patrón de nomenclatura `eks-cluster-sg- `), el rol del clúster necesitará permisos de IAM adicionales. La política administrada por EKS predeterminada solo permite a EKS modificar los grupos de seguridad denominados `eks-cluster-sg-`. Sin permiso para modificar los grupos de seguridad personalizados, EKS no podrá agregar las reglas de ingreso necesarias que permitan que el tráfico del equilibrado de carga de aplicaciones y del equilibrador de carga de red (ALB/NLB) llegue a los pods. #### Consideraciones de CoreDNS El modo automático de EKS no utiliza la implementación tradicional de CoreDNS para proporcionar resolución de DNS dentro del clúster. En cambio, los nodos del modo automático utilizan CoreDNS que se ejecuta como un servicio del sistema directamente en cada nodo. Si está llevando a cabo la transición de un clúster tradicional al modo automático, puede eliminar la implementación de CoreDNS del clúster una vez que las cargas de trabajo se hayan trasladado a los nodos del modo automático. **importante** Si tiene previsto mantener un clúster con nodos del modo automático y nodos que no lo sean, debe retener la implementación de CoreDNS. Los nodos que no son del modo automático dependen de los pods de CoreDNS tradicionales para la resolución de DNS, ya que no pueden acceder al servicio de DNS del nodo que proporciona el modo automático.