Red de contenedores: inventario, explicación y análisis
Este artículo se centra en el desglose de los tipos de redes de contenedores actuales, que incluyen:
? ¿Nadie
? ¿Mantillo
? Transatlánticos
Con el avance y desarrollo de la tecnología de contenedores, la anterior red de contenedores. Los siguientes dos modos de soluciones de red han desaparecido.
Enlaces y embajadores
Antes de usar Swarm para respaldar y organizar redes de múltiples hosts, Docker comenzó con redes de un solo host y facilitó la conectividad de red a través de enlaces como mecanismo para permitir el paso de contenedores. Las variables de entorno o las entradas del archivo /etc/hosts se descubren entre sí y transfieren información entre contenedores. La capacidad de vincular a menudo se combina con el modo embajador para facilitar las conexiones de contenedores entre hosts y reducir la vulnerabilidad de los enlaces codificados. El mayor problema de este método es que es demasiado estático. Una vez que se crea un contenedor y se definen las variables de entorno, no es posible actualizar los valores de estas variables si el contenedor o servicio relacionado se mueve a una nueva dirección IP.
Red mapeada por contenedor
En este modo de red, un contenedor reutiliza (mapa) el espacio de nombres de red de otro contenedor. Este modo de red solo se puede utilizar de la siguiente manera: -net:container:some_container_name_or_id.
Este indicador de ejecución de comando le indica a Docker que coloque el proceso de este contenedor en una pila de red que se ha creado en otro contenedor. Si bien comparten las mismas direcciones IP y MAC y números de puerto que el primer contenedor, los procesos del nuevo contenedor aún están sujetos a su propio sistema de archivos, lista de procesos y restricciones de recursos. Los procesos en ambos contenedores podrán conectarse entre sí a través de la interfaz loopback.
Este método de red es útil para realizar diagnósticos en contenedores en ejecución, pero los contenedores carecen de las herramientas de diagnóstico necesarias (como curl o dig). Puede crear un contenedor temporal con las herramientas de diagnóstico necesarias y conectarlo a la red del primer contenedor.
La red de contenedores mapeados se puede utilizar para simular la red de pods, donde varios contenedores * * * comparten el mismo espacio de nombres de red. * * * Ventajas como la comunicación localhost compartida, * * compartir la misma dirección IP, etc. son inherentes al concepto de contenedores que se ejecutan en el mismo pod, que es el comportamiento de los contenedores rkt.
Red de contenedores actual Ninguna
Ninguna es un contenedor relativamente sencillo que recibe una pila de red pero carece de una interfaz de red externa. Sin embargo, recibe una interfaz loopback. Tanto el proyecto de contenedor rkt como el de Docker proporcionan un comportamiento similar cuando no se utiliza una red o cuando se utiliza una red vacía. Este modelo de red de contenedores tiene muchos usos, incluida la prueba de contenedores, la asignación de contenedores para futuras conexiones de red y la asignación de contenedores que no requieren comunicación externa.
Puente
El puente de Linux proporciona una red interna del host en la que los contenedores en el mismo host pueden comunicarse, pero la dirección IP asignada a cada contenedor no se puede transferir desde el acceso externo del host. Las redes puenteadas utilizan iptables para NAT y mapeo de puertos, proporcionando redes de un solo host. Una red puenteada es el tipo de red Docker predeterminado (es decir, docker0), donde un extremo de un par de interfaces de red virtual está conectado entre el puente y el contenedor.
El siguiente es un ejemplo del proceso de creación:
1. Cree un puente en el host.
2. El espacio de nombres de cada contenedor se proporciona en este puente.
3. El ethX del contenedor se asigna a la interfaz del puente privado.
4. Utilice iptables con NAT para mapear la interfaz pública de cada contenedor y host privado.
NAT se utiliza para proporcionar comunicación fuera del host. Si bien las redes puenteadas resuelven el problema de los conflictos de puertos y proporcionan aislamiento de red para los contenedores que se ejecutan en el host, conllevan algunos costos de rendimiento asociados con NAT.
Hosting
En este enfoque, el contenedor recién creado comparte su espacio de nombres de red con el host, lo que proporciona un mayor rendimiento (casi básico) y elimina la necesidad de NAT. tener conflictos portuarios. Aunque el contenedor puede acceder a todas las interfaces de red del host, es posible que no pueda reconfigurar la pila de red del host a menos que se implemente en modo privilegiado.
La red de host es el tipo predeterminado utilizado en Mesos. En otras palabras, si el marco no especifica un tipo de red, el nuevo espacio de nombres de red no se asociará con el contenedor, sino con la red host. A veces denominada red local, la red de host es un concepto simple que es fácil de entender, solucionar problemas y usar.
Superposiciones
Las superposiciones utilizan túneles de red para pasar el tráfico entre hosts. Esto permite que los contenedores canalicen subredes de red de un host a otro para que se comporten como si estuvieran en la misma máquina; de hecho, una red abarca varios hosts. Actualmente existen muchas tecnologías de tunelización, como la LAN virtual extensible VXLAN.
VXLAN es la tecnología de túnel preferida para Docker libnetwork y su red multihost es una característica nativa de la versión 1.9. Con la introducción de esta característica, Docker ha optado por utilizar Serf de HashiCorp como protocolo de chismes y para el intercambio de tablas vecinas y la eficiencia del tiempo de convergencia.
La franela puede ser una opción para quienes necesitan admitir otras tecnologías de túneles. Admite udp, vxlan, host-gw, aws-vpc o gce. Cada tipo de túnel de proveedor de nube crea una ruta para su cuenta o VPC en la tabla de rutas del proveedor. El soporte para nubes públicas es particularmente importante para los controladores de superposición, porque las superposiciones pueden resolver mejor los escenarios de nube híbrida y proporcionar expansión y redundancia sin abrir puertos públicos.
Las redes multihost requieren parámetros adicionales al iniciar el demonio Docker y almacenar valores clave. Algunas superposiciones se basan en almacenes de valores clave distribuidos. Si está organizando contenedores, ya tiene un almacén de valores clave distribuido.
La superposición se centra en los desafíos de comunicación entre hosts. Los contenedores conectados a dos redes superpuestas diferentes en el mismo host no pueden comunicarse entre sí a través de puentes locales: están segmentados entre sí.
Se convierte en la base de...
El controlador de red subyacente expone directamente la interfaz del host (es decir, la interfaz de red física de eth0) al contenedor o máquina virtual que se ejecuta en el host. Dos de estos controladores son MACVLAN e IPVLAN. Los ingenieros de redes están muy familiarizados con el funcionamiento y la funcionalidad de los controladores MACVLAN e IPVLAN. Ambos controladores de red son conceptualmente más simples que las redes puenteadas, no requieren mapeo de puertos y son más eficientes. Además, IPVLAN tiene un modo L3 que prefieren muchos ingenieros de redes. Dadas las limitaciones (o falta de capacidad) en la mayoría de las nubes públicas, la base es especialmente útil cuando hay cargas de trabajo locales, preocupaciones de seguridad, priorización del tráfico o requisitos de cumplimiento. En lugar de un puente por VLAN, la red subyacente permite una VLAN por subinterfaz.
MacFarlane
MACVLAN permite la creación de múltiples interfaces de red virtuales detrás de una única interfaz física en un host. A cada interfaz virtual se le asigna una dirección MAC e IP única, pero existe una restricción: la dirección IP debe estar en el mismo dominio de transmisión que la interfaz física. Si bien muchos ingenieros de redes pueden estar más familiarizados con el término subinterfaz (que no debe confundirse con interfaz auxiliar), los términos utilizados para describir las interfaces virtuales MACVLAN suelen ser interfaces superiores o inferiores. La conexión en red MACVLAN es un método que elimina la necesidad de puentes LINUX, NAT y mapeo de puertos, lo que le permite conectarse directamente a interfaces físicas.
Cada contenedor de MACVLAN utiliza una dirección MAC única, lo que puede causar problemas a los conmutadores de red que utilizan esta política de seguridad para evitar la suplantación de MAC (solo se permite una dirección MAC por interfaz de conmutador físico).
El tráfico del contenedor se filtra y no puede comunicarse con el host subyacente, aislando completamente el host de los contenedores que se ejecutan en él. El anfitrión no puede alcanzar el contenedor. Los contenedores están aislados del anfitrión. Esto es útil para proveedores de servicios o escenarios de múltiples inquilinos y proporciona un mejor aislamiento que el modelo puente.
MACVLAN requiere modo mixto; MACVLAN tiene cuatro modos de trabajo y Docker 1.12 solo admite el modo puente. El modo puente MACvlan y el modo IPvlan L2 son funcionalmente equivalentes. Ambos modos permiten tráfico de difusión y multidifusión. Estos protocolos subyacentes están diseñados teniendo en cuenta casos de uso internos. El kilometraje de su nube pública variará ya que la mayoría de sus interfaces de VM no admiten el modo híbrido.
Nota: el modo puente MACVLAN puede ser beneficioso para rastrear el tráfico de la red y la visibilidad de un extremo a otro al asignar una dirección MAC única a cada contenedor; sin embargo, para las interfaces de red típicas existe un límite superior de 512 únicas; Direcciones MAC Las tarjetas (NIC), como BR OADCOM, deben considerar este límite superior.
IPVLAN
IPVLAN es similar a MACVLAN en que crea una nueva interfaz de red virtual y asigna una dirección IP única a cada dirección IP. La diferencia es que las direcciones MAC de todas las interfaces físicas de pods y contenedores en el host son las mismas. Este comportamiento es necesario principalmente porque muchos conmutadores suelen configurarse con un estado de seguridad que cierra los puertos del conmutador al tráfico de varias direcciones MAC.
El mejor kernel para ejecutar es la versión 4.2 o superior, e IPVLAN puede ejecutarse en modo L2 o L3. Al igual que MACVLAN, el modo IPVLAN L2 requiere que la dirección IP asignada a la subinterfaz esté en la misma subred que la interfaz física. Sin embargo, el modo IPvlan L3 requiere que la red del contenedor y la dirección IP estén en una subred diferente a la de la interfaz física principal.
La configuración 802.1q en un host Linux (cuando se crea mediante un enlace IP) es efímera, por lo que la mayoría de los operadores utilizan scripts de inicio de red para guardar la configuración. La automatización puede mejorar el motor de contenedor que ejecuta el controlador subyacente y exponer las API para configurar las VLAN mediante programación. Por ejemplo, cuando se crean nuevas VLAN en un conmutador de rack, estas VLAN se pueden enviar a hosts Linux a través de la API.ico de Container Engine expuesta.
MACVLAN e IPVLAN
Al elegir entre estos dos tipos subyacentes, considere si necesita una red para ver la dirección MAC de un contenedor individual.
Para el Protocolo de resolución de direcciones (ARP) y comunicaciones de difusión, independientemente del modo L2 del controlador subyacente, al igual que el servidor conectado al conmutador, aprenderá a operar a través de una gran cantidad de paquetes 802.1D. . Sin embargo, en el modo IPVLAN L3, la pila de red se maneja en el contenedor y no se permite el tráfico de multidifusión o difusión. En este sentido, el modo IPVLAN L3 se comportará como se esperaría que se comportara un enrutador L3.
Tenga en cuenta que el enrutador L3 ascendente necesita conocer la red creada utilizando IPvlan. Aún queda por hacer la reasignación de la publicidad en línea y la creación de redes. Hoy, Docker está experimentando con el protocolo Border Gateway (BGP). Si bien se pueden crear rutas estáticas sobre conmutadores de rack, proyectos como goBGP han evolucionado rápidamente hasta convertirse en una forma ecológica para que los contenedores proporcionen capacidades de intercambio de rutas y peering.
Aunque un host determinado admite múltiples modos de red, MACVLAN e IPVLAN no se pueden utilizar simultáneamente en la misma interfaz física. En resumen, si está acostumbrado a ejecutar relés en el host, puede usar el modo L2. Si su enfoque es la escala, L3 tiene el potencial de escalar.
Enrutamiento directo
Por la misma razón, el modo IPVLAN L3 es el preferido por los ingenieros de redes que pueden optar por centrarse en resolver las complejidades de la red de la Capa 3. Este enfoque se beneficia del uso de la infraestructura de red existente para gestionar redes de contenedores. Las soluciones de redes de contenedores centradas en L3 utilizan protocolos de enrutamiento para proporcionar conectividad y posiblemente tengan más probabilidades de interoperar con la infraestructura del centro de datos existente, conectando contenedores, máquinas virtuales y servidores bare metal. Además, las redes L3 se expanden y proporcionan un control detallado para filtrar y aislar el tráfico de la red.
CALICO es uno de esos proyectos que utiliza BGP para distribuir rutas a cada red, especialmente cargas de trabajo que utilizan /32, lo que le permite integrarse perfectamente con la infraestructura del centro de datos existente y no requiere cobertura de necesidades. No hay sobrecarga de superposición o encapsulación, y el resultado es una red con un rendimiento y escala excepcionales. La dirección IP enrutable de un contenedor expone la dirección IP y el puerto al mundo exterior. Los ingenieros de redes que están capacitados y acostumbrados a implementar, diagnosticar y operar redes utilizando protocolos de enrutamiento pueden encontrar el enrutamiento directo más fácil de entender. Sin embargo, vale la pena señalar que CALICO no admite direcciones IP superpuestas.
Fan Network
Fan Network es una forma de acceder a más direcciones IP, expandiéndose desde una dirección IP asignada a 250 direcciones IP. Esta es una forma eficaz de obtener más IP sin superponer redes. Este tipo de red es particularmente útil cuando se ejecutan contenedores en nubes públicas, donde se asigna una única dirección IP a un host y está prohibido iniciar redes adicionales, o ejecutar otra instancia de equilibrio de carga es costoso.
Peer-to-Peer
Peer-to-Peer es probablemente el tipo de red más simple y la red predeterminada utilizada por CoreOS rkt. De forma predeterminada, al usar NAT o IPMASQ, esto creará un par de Ethernet virtual, colocando uno en el host y el otro en el pod del contenedor. La red peer-to-peer proporciona reenvío de puertos no solo para el tráfico entrante, sino también para la comunicación interna entre otros contenedores en el pod a través de la interfaz loopback.
Además de la conectividad, la funcionalidad también debe considerar el soporte para otras funciones y servicios de red. Muchos modos de redes de contenedores utilizan NAT y reenvío de puertos, o evitan intencionalmente su uso. Gestión de direcciones IP IPAM, multidifusión, difusión, IPv6, equilibrio de carga, descubrimiento de servicios, políticas, calidad de servicio, filtrado avanzado y rendimiento requieren consideraciones adicionales al seleccionar una red.
La pregunta es si estas funciones son compatibles. Incluso si su tiempo de ejecución, motor de orquestación o complemento admite redes de contenedores, es posible que su infraestructura no lo admita. Si bien algunos proveedores de nube pública de nivel 2 ofrecen soporte para IPv6, la falta de soporte para IPv6 en las nubes públicas de primer nivel también aumenta la demanda de los usuarios de otros tipos de redes, como superposiciones y fannets.
En términos de IPAM, para mejorar la disponibilidad, la mayoría de los motores de ejecución de contenedores utilizan de forma predeterminada el host local para asignar direcciones a los contenedores cuando se conectan a la red. IPAM local de host consiste en definir un bloque de direcciones IP fijas para seleccionar. Los proyectos de redes entre contenedores a menudo admiten el Protocolo de configuración dinámica de host (DHCP). Tanto el modelo de red de contenedores (CNM) como la interfaz de red de contenedores (CNI) tienen marcos IPAM integrados y complementarios para la integración con sistemas IPAM, una característica clave adoptada en muchos entornos existentes.
Para obtener más detalles técnicos sobre el modelo de red de contenedores (CNM) y la interfaz de red de contenedores (CNI), consulte el artículo olvidado: Container Network Focus: CNM y CNI.
Beneficios al final del artículo: siga la cuenta oficial de WeChat "Wise2C" y responda al grupo. Fox Assistant lo incorporará al grupo de práctica de implementación empresarial de Docker lo antes posible. Los expertos técnicos y representantes de usuarios de varios proyectos de casos empresariales que compartimos lo están esperando. Esperamos su consulta y discusión con los expertos del grupo sobre más detalles y temas del proyecto.
Para obtener más detalles sobre los proyectos de clientes de Ruiyun Hezhi, consulte el menú de mejores prácticas en la cuenta oficial de WeChat de Wise2C.
Serie de distribución de carga seca (1): Caso práctico de aplicación de tecnología de contenedores Fude Life Insurance
Serie de distribución de carga seca (2): China Ping Un caso práctico de aplicación de tecnología de contenedores
Serie de entrega de carga seca (3): Casos prácticos de aplicación de la tecnología de contenedores en los medios de vida de las personas
Serie de entrega de carga seca (4): Casos prácticos de planificación y consultoría de transformación de la arquitectura de sistemas para una vida media compañía de seguros
Serie de inventario anual: Inventario anual 2016 Aplicación de tecnología de contenedores en la industria financiera - Seguros
Serie de inventario anual: Inventario anual 2016 Aplicación de tecnología de contenedores en la industria financiera - Banca |
Para obtener más detalles sobre los productos Wise PaaS, comuníquese con nuestro equipo de marketing:
contact@wise2c.com