Requisitos y consideraciones de Amazon EKS VPC y subred - Amazon EKS
Requisitos y consideraciones de la VPCRequisitos y consideraciones de la subredRequisitos y consideraciones de la subred compartida

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Requisitos y consideraciones de Amazon EKS VPC y subred

Al crear un clúster, especifica una VPC y al menos dos subredes que se encuentran en diferentes zonas de disponibilidad. En este tema se proporciona una descripción general de los requisitos y consideraciones específicos de Amazon EKS para la VPC y las subredes que utiliza con el clúster. Si no dispone de una VPC para usar con Amazon EKS, puede crear una utilizando una plantilla de AWS CloudFormation proporcionada por Amazon EKS. Si está creando un clúster local o extendido en AWS Outposts, consulte Requisitos y consideraciones de VPC y subred del clúster local de Amazon EKS en lugar de este tema.

Requisitos y consideraciones de la VPC

Al crear un clúster, la VPC que especifique debe cumplir los siguientes requisitos y consideraciones:

  • La VPC debe tener un número suficiente de direcciones IP disponibles para el clúster, los nodos y otros recursos de Kubernetes que desee crear. Si la VPC que desea utilizar no tiene un número suficiente de direcciones IP, intente aumentar el número de direcciones IP disponibles.

    Para ello, puede actualizar la configuración del clúster para cambiar las subredes y los grupos de seguridad que utiliza el clúster. Puede actualizar desde la AWS Management Console, la última versión de la AWS CLI, AWS CloudFormation, y eksctl versión v0.164.0-rc.0 o posterior. Es posible que tenga que hacer esto para proporcionar a las subredes más direcciones IP disponibles con las que poder actualizar correctamente la versión de un clúster.

    importante

    Todas las subredes que agregue deben estar en el mismo conjunto de zonas de disponibilidad proporcionadas originalmente cuando creó el clúster. Las nuevas subredes deben cumplir todos los demás requisitos; por ejemplo, deben tener suficientes direcciones IP.

    Por ejemplo, suponga que creó un clúster y especificó cuatro subredes. En el orden en que las especificó, la primera subred está en la zona de disponibilidad us-west-2a, la segunda y tercera subredes están en la zona de disponibilidad us-west-2b, y la cuarta subred está en la zona de disponibilidad us-west-2c. Si desea cambiar las subredes, debe proporcionar al menos una subred en cada una de las tres zonas de disponibilidad, y las subredes deben estar en la misma VPC que las subredes originales.

    Si necesita más direcciones IP de las que tienen los bloques de CIDR de la VPC, puede agregar bloques de CIDR adicionales asociando bloques de enrutamiento entre dominios sin clases (CIDR) adicionales a la VPC. Puede asociar bloques CIDR privados (RFC 1918) y públicos (RFC 1918) a su VPC antes o después de crear el clúster. Un clúster puede tardar hasta cinco horas en reconocer un bloque CIDR asociado a una VPC.

    Puede conservar el uso de direcciones IP usando una puerta de enlace de tránsito con una VPC de servicios compartidos. Para obtener más información, consulte VPC aisladas con servicios compartidos y Patrones de conservación de direcciones IP enrutables de VPC de Amazon EKS en una red híbrida.

  • Si quiere que Kubernetes asigne direcciones IPv6 a Pods y servicios, asocie un bloque de CIDR IPv6 con su VPC. Para obtener más información, consulte Asociar un bloque de CIDR IPv6 a su VPC en la Guía del usuario de Amazon VPC.

  • La VPC debe tener un nombre de host DNS y admitir la resolución DNS. De lo contrario, los nodos no podrán unirse al clúster. A fin de obtener más información, consulte Atributos de DNS para su VPC en la Guía del usuario de Amazon VPC.

  • Es posible que la VPC requiera puntos de conexión de VPC mediante AWS PrivateLink. Para obtener más información, consulte Requisitos y consideraciones de la subred.

Si ha creado un clúster con Kubernetes 1.14 o anterior, Amazon EKS agregó la siguiente etiqueta a la VPC:

Clave Valor
kubernetes.io/cluster/my-cluster owned

Esta etiqueta solo la utilizó Amazon EKS. Puede quitar la etiqueta sin afectar a sus servicios. No se utiliza con clústeres que son versión 1.15 o posterior.

Requisitos y consideraciones de la subred

Al crear un clúster, Amazon EKS crea de 2 a 4 interfaces de red elásticas en las subredes que usted especifique. Estas interfaces de red permiten la comunicación entre el clúster y la VPC. Estas interfaces de red también habilitan características de Kubernetes como kubectl exec y kubectl logs. Cada interfaz de red creada con Amazon EKS cuenta con el texto Amazon EKS cluster-name en su descripción.

Amazon EKS puede crear sus interfaces de red en cualquier subred que especifique al crear un clúster. Puede cambiar en qué subredes Amazon EKS crea sus interfaces de red después de crear el clúster. Al actualizar la versión de Kubernetes de un clúster, Amazon EKS elimina las interfaces de red originales que creó y crea nuevas interfaces de red. Estas interfaces de red se pueden crear en las mismas subredes que las interfaces de red originales o en subredes distintas de las interfaces de red originales. Para controlar en qué subredes se crean las interfaces de red, puede limitar el número de subredes especificadas a solo dos al crear un clúster, o bien actualizar las subredes después de crear el clúster.

Requisitos de la subred para los clústeres

Las subredes que especifique al crear o actualizar un clúster deben cumplir los siguientes requisitos:

  • Las subredes deben tener al menos seis direcciones IP para que Amazon EKS las utilice. Sin embargo, recomendamos al menos 16 direcciones IP.

  • Las subredes no pueden residir en AWS Outposts, AWS Wavelength o una AWS Local Zone. Sin embargo, si los tiene en la VPC, puede implementar nodos autoadministrados y recursos de Kubernetes para este tipo de subredes.

  • Las subredes pueden ser públicas o privadas. Sin embargo, le recomendamos que especifique subredes privadas, si es posible. Una subred pública es una subred con una tabla de enrutamiento que incluye una ruta a una puerta de enlace de Internet, mientras que una subred privada es una subred con tabla de enrutamiento que no incluye ruta a la puerta de enlace de internet.

  • Las subredes no pueden residir en las siguientes zonas de disponibilidad:

    Región de AWS Nombres de las regiones ID de zona de disponibilidad que no están permitidos
    us-east-1 Este de EE. UU. (Norte de Virginia) use1-az3
    us-west-1 Oeste de EE. UU. (Norte de California) usw1-az2
    ca-central-1 Canadá (centro) cac1-az3

Uso de familias de direcciones IP por componente

La siguiente tabla contiene la familia de direcciones IP que utiliza cada componente de Amazon EKS. Puede utilizar una traducción de direcciones de red (NAT) u otro sistema de compatibilidad para conectarse a estos componentes desde las direcciones IP de origen en familias con el valor "No" para una entrada de la tabla.

La funcionalidad puede variar según la configuración IP family (ipFamily) del clúster. Esta configuración cambia el tipo de direcciones IP utilizadas para el bloque CIDR que Kubernetes le asigna a Services. Un clúster con el valor de configuración de IPv4 se denomina IPv4 cluster y un clúster con el valor de configuración de IPv6 se denomina IPv6 cluster.

Componente Solo direcciones IPv4 Solo direcciones IPv6 Direcciones de pila doble
Punto de conexión público de la API de EKS Sí No No
Punto de conexión de VPC de la API de EKS Sí No No
Punto de conexión público de la API de autenticación de EKS Sí1 Sí1 Sí1
Punto de conexión de VPC de la API de autenticación de EKS Sí1 Sí1 Sí1
Punto de conexión público del clúster de Kubernetes Sí No No
Punto de conexión privado del clúster de Kubernetes Sí2 Sí2 No
Subredes de clústeres de Kubernetes Sí2 No Sí2
Direcciones IP principales del nodo Sí2 No Sí2
Rango de CIDR del clúster para direcciones IP de Service Sí2 Sí2 No
Direcciones IP del Pod del CNI de VPC Sí2 Sí2 No
nota

1 El punto de conexión es de pila doble con ambas direcciones, IPv4 y IPv6. Las aplicaciones fuera de AWS, los nodos del clúster y los pods dentro del clúster pueden alcanzar este punto de conexión mediante IPv4 o IPv6.

2 Cuando se crea un clúster, se elige entre un clúster IPv4 y un clúster IPv6 en la configuración IP family (ipFamily) del clúster, y esto no se puede cambiar. En su lugar, es necesario elegir una configuración diferente al momento de crear otro clúster y migrar las cargas de trabajo.

Requisitos de la subred para los nodos

Puede implementar nodos y recursos de Kubernetes en las mismas subredes que especifique al crear el clúster. Sin embargo, esto no es necesario. Esto se debe a que también puede implementar nodos y recursos de Kubernetes en subredes que no especificó al crear el clúster. Si implementa nodos en subredes diferentes, Amazon EKS no crea interfaces de red de clúster en esas subredes. Cualquier subred en la que implemente nodos y recursos de Kubernetes debe cumplir los siguientes requisitos:

  • Las subredes deben tener suficientes direcciones IP disponibles para implementar todos sus nodos y recursos de Kubernetes.

  • Si quiere que Kubernetes asigne direcciones IPv6 a Pods y servicios, entonces debe tener un bloque de CIDR IPv6 y un bloque de CIDR IPv4 asociado a su subred. Para obtener más información, consulte Asociar un bloque de CIDR IPv6 a su subred en la Guía del usuario de Amazon VPC. Las tablas de enrutamiento asociadas a las subredes deben incluir rutas a direcciones IPv4 y IPv6. Para obtener más información, consulte Rutas en la Guía del usuario de Amazon VPC. A los pods solo se les asigna una dirección IPv6. Sin embargo, a las interfaces de red que Amazon EKS crea para el clúster y los nodos se les asigna una dirección IPv4 y IPv6.

  • Si necesita acceso entrante desde Internet a sus Pods, asegúrese de tener al menos una subred pública con suficientes direcciones IP disponibles para implementar equilibradores de carga e ingresar a ellos. Puede implementar un equilibrador de carga en una subred pública. Los equilibradores de carga pueden equilibrar la carga de los Pods en subredes privadas o públicas. Recomendamos implementar los nodos en subredes privadas, si es posible.

  • Si planea implementar nodos en una subred pública, la subred debe asignar automáticamente direcciones IPv4 públicas o direcciones IPv6. Si implementa nodos en una subred privada que tiene un bloque de CIDR IPv6 asociado, la subred privada también debe asignar automáticamente direcciones IPv6. Si utilizó una Plantilla de AWS CloudFormation Amazon EKS para implementar la VPC después del 26 de marzo de 2020, esta configuración está habilitada. Si ha utilizado las plantillas para implementar la VPC antes de esta fecha o utiliza su propia VPC, debe habilitar esta configuración manualmente. Para obtener más información, consulte Modificar el atributo de direcciones IPv4 públicas para su subred y Modificar laIPv6atributo de direcciones de su subred en la Guía de usuario de Amazon VPC.

  • Si la subred en la que implementa un nodo es una subred privada y su tabla de enrutamiento no incluye una ruta a un dispositivo de traducción de direcciones de red (NAT) (IPv4) o una puerta de enlace solo de salida (IPv6), agregue puntos de conexión de la VPC mediante AWS PrivateLink a su VPC. Se necesitan puntos de conexión de VPC para todos los Servicios de AWS con los que sus nodos y Pods necesitan comunicarse. Algunos ejemplos incluyen Amazon ECR, equilibradores de carga elástica, Amazon CloudWatch, AWS Security Token Service y Amazon Simple Storage Service (Amazon S3). El punto de conexión debe incluir la subred en la que se encuentran los nodos. No todos los Servicios de AWS admiten los puntos de conexión de VPC. Para obtener más información, consulte ¿Qué es AWS PrivateLink¿ y Servicios de AWS que se integran con AWS PrivateLink. Para obtener una lista de más requisitos de Amazon EKS, consulte Implementación de clústeres privados con acceso limitado a Internet.

  • Si desea implementar equilibradores de carga en una subred, la subred debe tener la siguiente etiqueta:

    • Subredes privadas

      Clave Valor
      kubernetes.io/role/internal-elb 1

    • Subredes públicas

      Clave Valor
      kubernetes.io/role/elb 1

Cuando se crea un clúster de Kubernetes que es una versión 1.18 y anterior, Amazon EKS agrega la siguiente etiqueta a todas las subredes especificadas.

Clave Valor
kubernetes.io/cluster/my-cluster shared

Cuando crea un nuevo clúster de Kubernetes ahora, Amazon EKS no agrega la etiqueta a sus subredes. Si la etiqueta estaba en subredes usadas por un clúster que anteriormente tenía una versión anterior a la 1.19, la etiqueta no se eliminó automáticamente de las subredes cuando el clúster se actualizó a una versión más reciente. La versión 2.1.1 o anterior del AWS Load Balancer Controller requiere esta etiqueta. Si está usando una versión más reciente del controlador de equilibrador de carga, puede eliminar la etiqueta sin interrumpir sus servicios.

Si ha implementado una VPC mediante eksctl o con alguna de las plantillas de VPC de AWS CloudFormation de Amazon EKS, aplica lo siguiente:

  • A partir del 26 de marzo de 2020: las subredes públicas asignan de manera automática direcciones IPv4 públicas a los nodos nuevos implementados en subredes públicas.

  • Antes del 26 de marzo de 2020: las subredes públicas no asignan de forma automática las direcciones IPv4 públicas a los nodos nuevos implementados en subredes públicas.

Este cambio afecta a los nuevos grupos de nodos implementados en subredes públicas de las siguientes formas:

Requisitos y consideraciones de la subred compartida

Puede usar Uso compartido de VPC para compartir subredes con otras cuentas de AWS dentro de la misma AWS Organizations. Puede crear clústeres de Amazon EKS en subredes compartidas, teniendo en cuenta las siguientes consideraciones:

  • El propietario de la subred de VPC debe compartir una subred con una cuenta participante antes de que esa cuenta pueda crear un clúster de Amazon EKS en ella.

  • No puede lanzar recursos mediante el grupo de seguridad predeterminado de la VPC porque pertenece al propietario. Además, los participantes no pueden lanzar recursos mediante grupos de seguridad que sean propiedad de otros participantes o del propietario.

  • En una subred compartida, el participante y el propietario controlan por separado los grupos de seguridad de cada cuenta respectiva. El propietario de la subred puede ver estos grupos de seguridad creados por los participantes, pero no puede realizar ninguna acción en ellos. Si el propietario de la subred quiere eliminar o modificar estos grupos de seguridad, el participante que ha creado el grupo de seguridad debe realizar la acción.

  • Si un participante crea un clúster, se deben tener en cuenta las siguientes consideraciones:

  • El propietario de la VPC compartida no puede ver, actualizar ni eliminar un clúster que un participante cree en la subred compartida. Esto se suma a los recursos de VPC a los que cada cuenta tiene un acceso diferente. Para obtener más información, consulte Responsabilidades y permisos de los propietarios y los participantes en la Guía del usuario de Amazon VPC.

  • Si usa la característica de redes personalizadas del Amazon VPC CNI plugin for Kubernetes, debe utilizar las asignaciones de ID de zona de disponibilidad que figuran en la cuenta del propietario para crear cada ENIConfig. Para obtener más información, consulte Redes personalizadas para los pods.

Para obtener más información sobre el uso compartido de la subred de VPC, consulte Compartir su VPC con otras cuentas en la Guía del usuario de Amazon VPC.