Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts
Al crear un clúster local, especifica una VPC y al menos una subred privada que se ejecuta en Outposts. En este tema, se proporciona una descripción general de los requisitos y las consideraciones de la VPC y las subredes para el clúster local.
Requisitos y consideraciones de la VPC
Al crear un clúster local, la VPC que especifique debe cumplir los siguientes requisitos y consideraciones:
-
Asegúrese de que la VPC tenga suficientes direcciones IP para el clúster local, los nodos y otros recursos de Kubernetes que desee crear. Si la VPC que desea utilizar no tiene suficientes direcciones IP, aumente el número de direcciones IP disponibles. Puede hacerlo asociando bloques adicionales de enrutamiento entre dominios sin clase (CIDR) con su VPC. Puede asociar bloques de CIDR privados (RFC 1918) y públicos (no 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 de CIDR asociado a una VPC.
-
La VPC no puede tener prefijos IP ni bloques de CIDR IPv6 asignados. Debido a estas restricciones, la información incluida en Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos y Obtenga información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios no aplica a su VPC.
-
La VPC tiene un nombre de host de DNS y la resolución de DNS habilitados. Sin estas características, se produce un error en la creación del clúster local y tendrá que habilitarlas y volver a crear el 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.
-
Para acceder al clúster local a través de la red local, la VPC debe estar asociada a la tabla de enrutamiento de la puerta de enlace local del Outpost. Para obtener más información, consulte Asociaciones de la VPC en la Guía del usuario de AWS Outposts.
Requisitos y consideraciones de la subred
Debe especificar al menos una subred privada al crear el clúster. Si especifica más de una subred, las instancias del plano de control de Kubernetes se distribuyen de manera uniforme en las subredes. Si se especifica más de una subred, las subredes deben existir en el mismo Outpost. Además, las subredes también deben tener las rutas y los permisos de grupos de seguridad adecuados para comunicarse entre sí. Las subredes que especifique al crear un clúster local deben cumplir los siguientes requisitos:
-
Todas las subredes están en el mismo Outpost lógico.
-
En conjunto, las subredes tienen al menos tres direcciones IP disponibles para las instancias del plano de control de Kubernetes. Si se especifican tres subredes, cada subred debe tener al menos una dirección IP disponible. Si se especifican dos subredes, cada subred debe tener al menos dos direcciones IP disponibles. Si se especifica una subred, la subred debe tener al menos tres direcciones IP disponibles.
-
Las subredes tienen una ruta a la puerta de enlace local del bastidor del Outpost para acceder al servidor de API de Kubernetes a través de su red local. Si las subredes no tienen una ruta a la puerta de enlace local del bastidor del Outpost, debe comunicarse con su servidor de API de Kubernetes desde dentro de la VPC.
-
Las subredes deben utilizar nombres basados en direcciones IP. La nomenclatura basada en recursos de Amazon EC2 no es compatible con Amazon EKS.
Acceso a los servicios de AWS de la subred
Las subredes privadas del clúster local en Outposts deben poder comunicarse con los servicios de AWS regionales. Para ello, puede utilizar una puerta de enlace NAT para el acceso saliente a Internet o, si desea mantener la privacidad de todo el tráfico dentro de su VPC, mediante los puntos de conexión de la interfaz de la VPC.
Uso de una puerta de enlace NAT
Las subredes privadas del clúster local en Outposts deben tener una tabla de enrutamiento asociada con una ruta a una puerta de enlace NAT en una subred pública en la zona de disponibilidad principal del Outpost. La subred pública debe tener una ruta hacia una puerta de enlace de Internet. La puerta de enlace NAT permite el acceso a Internet saliente y evita las conexiones entrantes no solicitadas desde Internet hacia las instancias del Outpost.
Uso de los puntos de conexión de VPC de interfaz
Si las subredes privadas del clúster local en Outposts no tienen una conexión a Internet de salida o si desea mantener todo el tráfico privado dentro de su VPC, debe crear los siguientes puntos de conexión de VPC de interfaz y un punto de conexión de puerta de enlace en una subred regional antes de crear el clúster.
| Punto de conexión | Tipo de punto de conexión |
|---|---|
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Interfaz |
|
|
Puerta de enlace |
Los puntos de conexión debe cumplir los siguientes requisitos:
-
Deben crearse en una subred privada ubicada en la zona de disponibilidad principal de su Outpost
-
Deben tener habilitados los nombres de DNS privados
-
Deben tener un grupo de seguridad adjunto que permita el tráfico HTTPS entrante desde el rango CIDR de la subred de Outpost privada.
La creación de puntos de conexión incurre en costos. Para obtener más información, consulte Precios de AWS PrivateLink
Creación de una VPC
Puede crear una VPC que cumpla los requisitos anteriores mediante una de las siguientes plantillas de AWS CloudFormation:
-
Plantilla 1
: esta plantilla crea una VPC con una subred privada en el Outpost y una subred pública en la región de AWS. La subred privada tiene una ruta a Internet a través de una puerta de enlace NAT que reside en la subred pública de la región de AWS. Esta plantilla se puede usar para crear un clúster local en una subred con acceso a Internet de salida. -
Plantilla 2
: esta plantilla crea una VPC con una subred privada en el Outpost y el conjunto mínimo de puntos de conexión de VPC necesarios para crear un clúster local en una subred que no tenga acceso a Internet de entrada o salida (también denominada subred privada).
