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.
Elección de un modo de red
Los enfoques mencionados anteriormente para diseñar conexiones de red entrantes y salientes se pueden aplicar a cualquiera de sus cargas de trabajo enAWS, incluso si no están dentro de un contenedor. Cuando se ejecutan contenedores enAWS, debe considerar otro nivel de red. Una de las principales ventajas de usar contenedores es que puede empaquetar varios contenedores en un único host. Al hacer esto, debe elegir cómo desea conectar en red los contenedores que se ejecutan en el mismo host. Las siguientes son las opciones para elegir.
Modo de host
Lahostes el modo de red más básico compatible con Amazon ECS. Usando el modo host, la red del contenedor está vinculada directamente al host subyacente que ejecuta el contenedor.
Supongamos que está ejecutando un contenedor Node.js con una aplicación Express que escucha en el puerto3000De forma similar a la ilustrada en el diagrama anterior. Cuando se utiliza lahost, el contenedor recibe tráfico en el puerto 3000 utilizando la dirección IP de la instancia de Amazon EC2 del host subyacente. No recomendamos el uso de este modo.
Hay inconvenientes importantes en el uso de este modo de red. No puede ejecutar más de una sola instancia de una tarea en cada host. Esto se debe a que solo la primera tarea puede enlazar a su puerto requerido en la instancia de Amazon EC2. Tampoco hay forma de reasignar un puerto contenedor cuando está usandohosten el modo de red. Por ejemplo, si una aplicación necesita escuchar un número de puerto determinado, no puede volver a asignar el número de puerto directamente. En su lugar, debe administrar cualquier conflicto de puertos cambiando la configuración de la aplicación.
También hay implicaciones para la seguridad cuando se utiliza elhosten el modo de red. Este modo permite a los contenedores suplantar el host y permite que los contenedores se conecten a los servicios de red de bucle invertido privados en el host.
Lahostsolo se admite en tareas de Amazon ECS alojadas en instancias de Amazon EC2. No se admite cuando se utiliza Amazon ECS en Fargate.
Modo de puente
conbridge, está utilizando un puente de red virtual para crear una capa entre el host y la red del contenedor. De esta forma, puede crear asignaciones de puertos que reasignen un puerto host a un puerto contenedor. Las asignaciones pueden ser estáticas o dinámicas.
Con una asignación de puertos estáticos, puede definir explícitamente qué puerto host desea asignar a un puerto contenedor. Usando el ejemplo anterior, puerto80en el host se está asignando al puerto3000en el contenedor. Para comunicarse con la aplicación contenedorizada, envía tráfico al puerto80En la dirección IP de la instancia de Amazon EC2. Desde la perspectiva de la aplicación en contenedores, ve que el tráfico entrante en el puerto3000.
Si solo desea cambiar el puerto de tráfico, entonces las asignaciones de puertos estáticos son adecuadas. Sin embargo, esto todavía tiene la misma desventaja que usar elhosten el modo de red. No puede ejecutar más de una sola instancia de una tarea en cada host. Esto se debe a que una asignación de puertos estáticos sólo permite asignar un único contenedor al puerto 80.
Para solucionar este problema, considere la posibilidad de utilizar elbridgeCon una asignación de puertos dinámica, tal y como se muestra en el siguiente diagrama.
Al no especificar un puerto host en la asignación de puertos, puede hacer que Docker elija un puerto aleatorio no utilizado del rango de puertos efímero y lo asigne como puerto de host público para el contenedor. Por ejemplo, la aplicación Node.js que escucha en el puerto3000en el contenedor se le puede asignar un puerto de número alto aleatorio, como47760en el host de Amazon EC2. Hacer esto significa que puede ejecutar varias copias de ese contenedor en el host. Además, a cada contenedor se le puede asignar su propio puerto en el host. Cada copia del contenedor recibe tráfico en el puerto3000. Sin embargo, los clientes que envían tráfico a estos contenedores utilizan los puertos de host asignados aleatoriamente.
Amazon ECS le ayuda a realizar un seguimiento de los puertos asignados aleatoriamente para cada tarea. Lo hace actualizando automáticamente los grupos de destino del equilibrador de carga yAWS Cloud Mappara tener la lista de direcciones IP y puertos de tareas. De ese modo resulta más sencillo utilizar los servicios que operan conbridgecon puertos dinámicos.
Sin embargo, una desventaja de usar elbridgees que es difícil bloquear las comunicaciones de servicio a servicio. Debido a que los servicios pueden asignarse a cualquier puerto aleatorio no utilizado, es necesario abrir amplios rangos de puertos entre hosts. Sin embargo, no es fácil crear reglas específicas para que un servicio determinado solo pueda comunicarse con otro servicio específico. Los servicios no tienen puertos específicos para usar para reglas de red de grupos de seguridad.
Labridgesolo se admite en tareas de Amazon ECS alojadas en instancias de Amazon EC2. No se admite cuando se utiliza Amazon ECS en Fargate.
Modo AWSVSVSVPC
Con elawsvpc, Amazon ECS crea y administra una interfaz de red elástica (ENI) para cada tarea y cada tarea recibe su propia dirección IP privada dentro de la VPC. Este ENI es independiente de los hosts subyacentes ENI. Si una instancia de Amazon EC2 ejecuta varias tareas, el ENI de cada tarea también es independiente.
En el ejemplo anterior, la instancia de Amazon EC2 se asigna a un ENI. El ENI representa la dirección IP de la instancia EC2 utilizada para las comunicaciones de red en el nivel de host. Cada tarea también tiene una ENI correspondiente y una dirección IP privada. Debido a que cada ENI es independiente, cada contenedor puede vincularse al puerto80en la tarea ENI. Por lo tanto, no es necesario realizar un seguimiento de los números de puerto. En su lugar, puede enviar tráfico al puerto80En la dirección IP de la ENI.
La ventaja de usar elawsvpces que cada tarea tiene un grupo de seguridad separado para permitir o denegar el tráfico. Esto significa que tiene mayor flexibilidad para controlar las comunicaciones entre tareas y servicios a un nivel más detallado. También puede configurar una tarea para denegar el tráfico entrante de otra tarea ubicada en el mismo host.
Laawsvpces compatible con las tareas de Amazon ECS alojadas tanto en Amazon EC2 como en Fargate. Tenga en cuenta que, al usar Fargate, elawsvpces necesario el modo de red.
Cuando se utiliza laawsvpchay algunos desafíos que debe tener en cuenta.
Aumento de la densidad de tareas con ENI Trunking
La mayor desventaja de usar elawsvpcCon las tareas alojadas en las instancias de Amazon EC2, las instancias EC2 presentan un límite en cuanto al número de ENI que pueden tener asociadas. Esto limita el número de tareas que puede colocar en cada instancia. Amazon ECS proporciona la función de enlace troncal ENI que aumenta el número de ENI disponibles para lograr una mayor densidad de tareas.
Cuando se utiliza el enlace troncal ENI, se utilizan dos adjuntos ENI de forma predeterminada. El primero es el ENI principal de la instancia, que se utiliza para cualquier proceso de nivel de host. El segundo es el ENI troncal, que Amazon ECS crea. Esta característica solo se admite en tipos de instancias de Amazon EC2.
Considere este ejemplo. Sin el enlace troncal ENI, unc5.largeque tiene dos vCPUs sólo puede alojar dos tareas. Sin embargo, con el enlace troncal ENI, unc5.largeque tiene dos vCPU puede alojar hasta diez tareas. Cada tarea tiene una dirección IP y un grupo de seguridad diferentes. Para obtener más información acerca de los tipos de instancias disponibles y su densidad, consulteTipos de instancias de Amazon EC2 admitidosen laGuía de Amazon Elastic Container Service.
El enlace troncal ENI no tiene ningún impacto en el rendimiento del tiempo de ejecución en términos de latencia o ancho de banda. Sin embargo, aumenta el tiempo de inicio de la tarea. Debe asegurarse de que, si se utiliza el enlace troncal ENI, las reglas de escalado automático y otras cargas de trabajo que dependen del tiempo de inicio de la tarea siguen funcionando como espera.
Para obtener más información, consulteTrunking de interfaz de red elásticaen laGuía de Amazon Elastic Container Service.
Prevención del agotamiento de direcciones IP
Al asignar una dirección IP independiente a cada tarea, puede simplificar su infraestructura general y mantener grupos de seguridad que proporcionan un gran nivel de seguridad. Sin embargo, esta configuración puede provocar el agotamiento de IP.
La VPC predeterminada en suAWScuenta con subredes preaprovisionadas que tienen un/20Gama de CIDR. Esto significa que cada subred tiene 4.091 direcciones IP disponibles. Tenga en cuenta que varias direcciones IP dentro del/20están reservados para uso específico de AWS. Considere este ejemplo. Las aplicaciones se distribuyen en tres subredes en tres zonas de disponibilidad para lograr una alta disponibilidad. En este caso, puede utilizar aproximadamente 12.000 direcciones IP en las tres subredes.
Mediante la conexión troncal ENI, cada instancia de Amazon EC2 que inicie requiere dos direcciones IP. Una dirección IP se utiliza para la ENI principal y la otra dirección IP para la ENI troncal. Cada tarea de Amazon ECS de la instancia requiere una dirección IP. Si está iniciando una carga de trabajo extremadamente grande, podría quedarse sin direcciones IP disponibles. Esto puede dar lugar a errores de inicio de Amazon EC2 o errores en el inicio de tareas. Estos errores se producen porque los ENI no pueden agregar direcciones IP dentro de la VPC si no hay direcciones IP disponibles.
Cuando se utiliza laawsvpc, debe evaluar sus requisitos de dirección IP y asegurarse de que los rangos CIDR de subred satisfagan sus necesidades. Si ya ha comenzado a utilizar una VPC que tiene subredes pequeñas y comienza a quedarse sin espacio de direcciones, puede agregar una subred secundaria.
Mediante el enlace troncal ENI, el CNI de Amazon VPC se puede configurar para utilizar ENI en un espacio de direcciones IP diferente al del host. De este modo, puede proporcionar a su host de Amazon EC2 y a sus tareas distintos rangos de direcciones IP que no se superponen. En el diagrama de ejemplo, la dirección IP del host EC2 se encuentra en una subred que tiene la propiedad172.31.16.0/20Rango de IP. Sin embargo, las tareas que se ejecutan en el host se asignan direcciones IP en el100.64.0.0/19Rango de. Al usar dos rangos de IP independientes, no necesita preocuparse por las tareas que consumen demasiadas direcciones IP y no dejan suficientes direcciones IP para las instancias.
Uso del modo de pila dual IPv6
Laawsvpces compatible con VPC configuradas para el modo de pila dual IPv6. Una VPC que utiliza el modo de pila doble puede comunicarse mediante IPv4, IPv6 o ambos. Cada subred de la VPC puede tener un intervalo CIDR IPv4 y un intervalo CIDR IPv6. Para obtener más información, consulteDirecciones IP en su VPCen laGuía del usuario de Amazon VPC.
No puede deshabilitar la compatibilidad con IPv4 para su VPC y sus subredes para solucionar problemas de agotamiento de IPv4. Sin embargo, con la compatibilidad con IPv6, puede utilizar algunas capacidades nuevas, específicamente la gateway de Internet de solo salida. Una gateway de Internet de solo salida permite a las tareas utilizar su dirección IPv6 de enrutamiento público para iniciar las conexiones salientes a Internet. Pero la gateway de Internet de solo salida no permite las conexiones de Internet. Para obtener más información, consulteGateways de Internet de solo salidaen laGuía del usuario de Amazon VPC.
