Requisitos de red de Amazon EKS para VPC y subredes
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 Creación de una Amazon VPC para su clúster de Amazon EKScrear una utilizando una plantilla de AWS CloudFormation proporcionada por Amazon EKS. Si está creando un clúster local o extendido en AWS Outposts, consulte Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts 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ónv0.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 disponibilidadus-west-2b
, y la cuarta subred está en la zona de disponibilidadus-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 CIDRIPv6
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ónDNS
. De lo contrario, los nodos no podrán registrarse en su 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 |
---|---|
|
|
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 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
in its description.
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 Mantenimiento de nodos por cuenta propia con nodos autoadministradosnodos 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 | Direcciones IPv4 | Direcciones IPv6 | Direcciones de pila doble |
---|---|---|---|
Punto de conexión público de la API de EKS |
Sí1.3 |
Sí1.3 |
Sí1.3 |
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 (Pod Identity de EKS) |
Sí1 |
Sí1 |
Sí1 |
Punto de conexión de VPC de la API de autenticación de EKS (Pod Identity 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í |
No |
No |
Punto de conexión público del clúster de Kubernetes |
Sí1,4 |
Sí1,4 |
Sí4 |
Punto de conexión privado del clúster de Kubernetes |
Sí1,4 |
Sí1,4 |
Sí4 |
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 |
URL de los emisores de OIDC para IRSA |
Sí1.3 |
Sí1.3 |
Sí1.3 |
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.
3 El punto de conexión de doble pila se introdujo en agosto de 2024. Para usar los puntos de conexión de doble pila con la AWS CLI, consulte la configuración de los puntos de conexión de doble pila y FIPS en la Guía de referencia de SDK y herramientas de AWS. A continuación se enumeran los nuevos puntos de conexión:
- Punto de conexión público de la API de EKS
-
eks.
region
.api.aws - URL de los emisores de OIDC para IRSA
-
oidc-eks.
region
.api.aws
4 El punto de conexión de clúster de doble pila se introdujo en octubre de 2024. EKS crea el siguiente punto de conexión para los nuevos clústeres que se creen después de esta fecha y que seleccionen IPv6
en la configuración de familia IP (ipFamily) del clúster:
- Punto de conexión público o privado del clúster de EKS
-
eks-cluster.
region
.api.aws
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 CIDRIPv6
y un bloque de CIDRIPv4
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 direccionesIPv4
yIPv6
. 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ónIPv6
. Sin embargo, a las interfaces de red que Amazon EKS crea para el clúster y los nodos se les asigna una direcciónIPv4
yIPv6
. -
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 direccionesIPv6
. Si implementa nodos en una subred privada que tiene un bloque CIDRIPv6
asociado, la subred privada también debe asignarse automáticamente a direccionesIPv6
. Si utilizó una Creación de una Amazon VPC para su clúster de Amazon EKSPlantilla de AWS CloudFormation de 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 Modificación del atributo de direcciones IPv4 públicas para su subred y Modificación del atributo de direcciones IPv6 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 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 AWSPrivateLink. 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 |
---|---|
|
|
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 Enrutamiento del tráfico de internet con el controlador del equilibrador de carga de AWScontrolador de equilibrador de carga de AWS 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:
-
Creación de un grupo de nodos administrados para un clústerGrupos de nodos administrados: si el grupo de nodos se implementa en una subred pública a partir del 22 de abril de 2020, la subred pública debe tener habilitada la asignación automática de direcciones IP públicas. Para obtener más información, consulte Modificación del atributo de direcciones IPv4 públicas de su subred.
-
Grupos de nodos autoadministrados de Creación de nodos autoadministrados de Amazon LinuxLinux, Creación de nodos autoadministrados de Microsoft WindowsWindows o AMI de Amazon Linux optimizada para Amazon EKS ArmArm: si el grupo de nodos se implementa en una subred pública a partir del 26 de marzo de 2020, la asignación automática de direcciones IP públicas deben estar habilitadas para la subred pública. De lo contrario, los nodos deben iniciarse con una dirección IP pública en su lugar. Para obtener más información, consulte Modificación del atributo de direcciones IPv4 públicas de su subred o Asignación de una dirección IPv4 pública durante el lanzamiento de la instancia.
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 rol de IAM de clúster y los roles de IAM de nodo deben crearse en esa cuenta. Para obtener más información, consulte Rol de IAM del clúster de Amazon EKS y Rol de IAM de nodo de Amazon EKS.
-
Todos los nodos debe crearlos el mismo participante, incluidos los grupos de nodos administrados.
-
-
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 de 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 Implementación de pods en subredes alternativas con redes personalizadas.
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.