**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.

# Implementación de pods en subredes alternativas con redes personalizadas
<a name="cni-custom-network"></a>

 **Aplicación**: en nodos de `IPv4` de Linux de Fargate, y nodos de Linux con instancias de Amazon EC2

![\[Diagrama de un nodo con múltiples interfaces de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/cn-image.png)


De forma predeterminada, cuando el complemento CNI de Amazon VPC para Kubernetes crea [interfaces de red elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) secundarias (interfaces de red) para el nodo de Amazon EC2, las crea en la misma subred que la interfaz de red principal del nodo. También asocia los mismos grupos de seguridad a la interfaz de red secundaria asociada a la interfaz de red principal. Por uno o varios de los siguientes motivos, es posible que desee que el complemento cree interfaces de red secundarias en una subred diferente o desee asociar distintos grupos de seguridad a las interfaces de red secundarias, o ambas:
+ Hay un número limitado de direcciones `IPv4` que están disponibles en la subred en la que se encuentra la interfaz de red principal. Esto podría limitar el número de pods que puede crear en la subred. Si utiliza una subred diferente para las interfaces de red secundarias, puede aumentar el número de direcciones `IPv4` disponibles para pods.
+ Por motivos de seguridad, sus pods podrían tener que utilizar distintos grupos de seguridad o subredes que la interfaz de red principal del nodo.
+ Los nodos se encuentran configurados en subredes públicas y debe ubicar los pods en subredes privadas. La tabla de enrutamiento asociada a una subred pública incluye una puerta de enlace de Internet. La tabla de enrutamiento asociada a una subred privada no incluye ninguna puerta de enlace de Internet.

**sugerencia**  
También puede agregar una subred nueva o existente directamente al clúster de Amazon EKS, sin necesidad de utilizar redes personalizadas. Para obtener más información, consulte [Cómo agregar una subred de VPC existente a un clúster de Amazon EKS desde la consola de administración](eks-networking.md#add-existing-subnet).

## Consideraciones
<a name="cni-custom-network-considerations"></a>

A continuación, se detallan consideraciones que se deben tener a la hora de utilizar esta característica.
+ Con las redes personalizadas habilitadas, no se asignan direcciones IP asignadas a la interfaz de red principal a los pods. Solo se asignan direcciones IP de interfaces de red secundarias a pods.
+ Si el clúster utiliza la familia `IPv6`, no puede utilizar redes personalizadas.
+ Si planea utilizar redes personalizadas solo para ayudar a aliviar el agotamiento de direcciones `IPv4`, puede crear un clúster mediante la familia `IPv6` en su lugar. Para obtener más información, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
+ Si bien los pods implementados en las subredes especificadas para interfaces de red secundarias pueden utilizar subredes y grupos de seguridad diferentes a los de la interfaz de la red principal del nodo, las subredes y los grupos de seguridad deben estar en la misma VPC que el nodo.
+ En el caso de Fargate, las subredes se controlan mediante el perfil de Fargate. Para obtener más información, consulte [Cómo definir los pods que deben lanzarse en AWS Fargate](fargate-profile.md).