Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas para la creación de redes
**sugerencia**
[Explore](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) las mejores prácticas a través de los talleres de Amazon EKS.
Es fundamental comprender las redes de Kubernetes para operar el clúster y las aplicaciones de manera eficiente. Las redes de pods, también denominadas redes de clústeres, son el centro de las redes de Kubernetes. Kubernetes admite los complementos de [interfaz de red de contenedores](https://github.com/containernetworking/cni) (CNI) para redes de clústeres.
Amazon EKS es compatible oficialmente con el complemento CNI [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) para implementar la red Kubernetes Pod. La VPC CNI proporciona una integración nativa con la VPC de AWS y funciona en modo subyacente. En el modo subyacente, los pods y los hosts se encuentran en la misma capa de red y comparten el espacio de nombres de la red. La dirección IP del pod es coherente desde el punto de vista del clúster y la VPC.
Esta guía presenta la [interfaz de red de contenedores de Amazon VPC](https://github.com/aws/amazon-vpc-cni-k8s) (VPC CNI) en el contexto de las redes de clústeres de Kubernetes. El CNI de VPC es el complemento de red predeterminado compatible con EKS y, por lo tanto, es el tema central de la guía. La CNI de VPC es altamente configurable para admitir diferentes casos de uso. Además, esta guía incluye secciones dedicadas a diferentes casos de uso, modos de funcionamiento y subcomponentes de la CNI de VPC, seguidas de recomendaciones.
Amazon EKS ejecuta Kubernetes en sentido ascendente y cuenta con la certificación de conformidad con Kubernetes. Si bien puede usar complementos de CNI alternativos, esta guía no ofrece recomendaciones para administrar CNI alternativos. Consulte la documentación de los [CNI alternativos de EKS](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html) para obtener una lista de socios y recursos para gestionar los CNI alternativos de forma eficaz.
## Modelo de red de Kubernetes
Kubernetes establece los siguientes requisitos para las redes de clústeres:
+ Los pods programados en el mismo nodo deben poder comunicarse con otros pods sin utilizar la NAT (traducción de direcciones de red).
+ Todos los daemons del sistema (procesos en segundo plano, por ejemplo, [kubelet](https://kubernetes.io/docs/concepts/overview/components/)) que se ejecutan en un nodo concreto pueden comunicarse con los pods que se ejecutan en el mismo nodo.
+ Los pods que utilizan la [red host](https://docs.docker.com/network/host/) deben poder ponerse en contacto con todos los demás pods de todos los demás nodos sin utilizar la NAT.
Consulta [el modelo de red de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model) para obtener más información sobre lo que Kubernetes espera de las implementaciones de redes compatibles. La siguiente figura ilustra la relación entre los espacios de nombres de la red del pod y el espacio de nombres de la red del host.
## Interfaz de red de contenedores (CNI)
Kubernetes admite las especificaciones y los complementos del CNI para implementar el modelo de red de Kubernetes. Un CNI consta de una [especificación](https://github.com/containernetworking/cni/blob/main/SPEC.md) (versión actual 1.0.0) y bibliotecas para escribir complementos para configurar las interfaces de red en contenedores, además de una serie de complementos compatibles. La CNI se ocupa únicamente de la conectividad de red de los contenedores y de eliminar los recursos asignados cuando se elimina el contenedor.
El complemento CNI se habilita pasando a kubelet la opción de línea de comandos. `--network-plugin=cni` Kubelet lee un archivo `--cni-conf-dir` (predeterminado etc/cni /net.d) y usa la configuración CNI de ese archivo para configurar la red de cada Pod. El archivo de configuración del CNI debe coincidir con la especificación del CNI (versión 0.4.0 como mínimo) y todos los complementos de CNI necesarios a los que haga referencia la configuración deben estar presentes en el directorio (predeterminado //bin). `--cni-bin-dir` opt/cni Si hay varios archivos de configuración CNI en el directorio, el kubelet utiliza el archivo de configuración que aparece primero por su nombre en orden lexicográfico.
## Amazon Virtual Private Cloud (VPC) CNI
El CNI de AWS-provided VPC es el complemento de red predeterminado para los clústeres de EKS. El complemento CNI de VPC se instala de forma predeterminada al aprovisionar clústeres de EKS. La CNI de VPC se ejecuta en los nodos de trabajo de Kubernetes. El complemento CNI de VPC consta del binario CNI y del complemento de administración de direcciones IP (ipamd). La CNI asigna una dirección IP de la red de VPC a un pod. El ipamd administra las interfaces de red elásticas (ENI) de AWS en cada nodo de Kubernetes y mantiene el conjunto caliente de IP. La CNI de VPC ofrece opciones de configuración para la preasignación de ENI y direcciones IP para acelerar los tiempos de inicio del pod. Consulte el [CNI de Amazon VPC para obtener información sobre las prácticas](vpc-cni.md) recomendadas de administración de complementos.
Amazon EKS recomienda especificar subredes en al menos dos zonas de disponibilidad al crear un clúster. La CNI de Amazon VPC asigna direcciones IP a los pods desde las subredes de los nodos. Recomendamos encarecidamente comprobar las direcciones IP disponibles en las subredes. Tenga en cuenta las recomendaciones de [VPC y subred](subnets.md) antes de implementar clústeres de EKS.
El CNI de Amazon VPC asigna un conjunto caliente de ENI y direcciones IP secundarias de la subred conectada al ENI principal del nodo. Este modo de CNI de VPC se denomina modo IP [secundario](vpc-cni.md). El número de direcciones IP y, por lo tanto, el número de pods (densidad de pods) se define por el número de ENI y la dirección IP por ENI (límites), según lo definido por el tipo de instancia. El modo secundario es el predeterminado y funciona bien para clústeres pequeños con tipos de instancias más pequeños. Considere la posibilidad de utilizar el [modo de prefijo](prefix-mode-linux.md) si tiene problemas con la densidad de los pods. También puedes aumentar las direcciones IP disponibles en el nodo para los pods asignando prefijos a los ENI.
El CNI de Amazon VPC se integra de forma nativa con AWS VPC y permite a los usuarios aplicar las prácticas recomendadas de seguridad y redes de VPC de AWS existentes para crear clústeres de Kubernetes. Esto incluye la capacidad de usar registros de flujo de VPC, políticas de enrutamiento de VPC y grupos de seguridad para aislar el tráfico de la red. De forma predeterminada, la CNI de Amazon VPC aplica a los pods el grupo de seguridad asociado al ENI principal del nodo. Considere la posibilidad [de habilitar grupos de seguridad para los pods](sgpp.md) cuando desee asignar reglas de red diferentes a un pod.
De forma predeterminada, la CNI de VPC asigna direcciones IP a los pods de la subred asignada al ENI principal de un nodo. Es habitual experimentar una escasez de direcciones IPv4 cuando se ejecutan clústeres grandes con miles de cargas de trabajo. AWS VPC le permite ampliar las IP disponibles mediante la [asignación de un CIDR secundario para evitar el agotamiento de los bloques de CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions) de IPv4. El CNI de VPC de AWS le permite usar un rango CIDR de subred diferente para los pods. [Esta función de la VPC CNI se denomina red personalizada.](custom-networking.md) Podría considerar la posibilidad de utilizar redes personalizadas para utilizar los `100.64.0.0/10` `198.19.0.0/16` CIDR (CG-NAT) con EKS. De hecho, esto le permite crear un entorno en el que los pods ya no consuman ninguna dirección IP RFC1918 de su VPC.
Las redes personalizadas son una opción para solucionar el problema del agotamiento de las direcciones IPv4, pero requieren una sobrecarga operativa. Para resolver este problema, recomendamos utilizar clústeres IPv6 en lugar de redes personalizadas. En concreto, recomendamos migrar a [clústeres de IPv6](ipv6.md) si ha agotado por completo todo el espacio de direcciones IPv4 disponible para su VPC. Evalúe los planes de su organización para admitir IPv6 y considere si invertir en IPv6 puede tener un valor a más largo plazo.
El soporte de EKS para IPv6 se centra en resolver el problema de agotamiento de la IP provocado por un espacio de direcciones IPv4 limitado. En respuesta a los problemas de los clientes relacionados con el agotamiento del IPv4, EKS ha priorizado los pods en lugar de los IPv6-only pods de doble pila. Es decir, los pods pueden acceder a los recursos de IPv4, pero no se les asigna una dirección IPv4 del rango CIDR de la VPC. La CNI de VPC asigna direcciones IPv6 a los pods del bloque CIDR de IPv6 de VPC administrado por AWS.
## Calculadora de subredes
Este proyecto incluye un documento de [Excel sobre la calculadora de subredes](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx). Este documento de calculadora simula el consumo de direcciones IP de una carga de trabajo específica en diferentes opciones de configuración de ENI, como `WARM_IP_TARGET` y. `WARM_ENI_TARGET` El documento incluye dos hojas, una primera para el modo ENI cálido y una segunda para el modo IP cálido. Consulte la [guía del CNI de VPC para obtener](vpc-cni.md) más información sobre estos modos.
Entradas:
+ Tamaño CIDR de subred
+ Objetivo ENI cálido *o objetivo IP* cálido
+ Lista de instancias
+ tipo, número y cantidad de módulos de carga de trabajo programados por instancia
Salidas:
+ Número total de pods alojados
+ Número de direcciones IP de subred consumidas
+ Número de direcciones IP de subred restantes
+ Detalles a nivel de instancia
+ Número de Warm IPs/ENIs por instancia
+ Número de activos IPs/ENIs por instancia