Tecnología de contenedores de Docker-red de contenedores

Tabla de contenido

La tendencia de desarrollo de la red de contenedores

CNI

CNI (Container Network Interface) es un estándar de red de contenedores liderado por Google y CoreOS. Se desarrolla sobre la base de la propuesta de red RKT, teniendo en cuenta factores como flexibilidad, escalabilidad, asignación de IP y múltiples tarjetas de red. .

CNI tiene como objetivo proporcionar estandarización de red para plataformas de contenedores. Diferentes plataformas de contenedores (por ejemplo, Kubernetes, Mesos y RKT) pueden llamar a diferentes componentes de red a través de la misma interfaz. Este protocolo conecta dos componentes:

1. Sistema de gestión de contenedores
2. Complemento de red

Los complementos implementan cosas específicas, que incluyen: crear un espacio de red contenedor (espacio de nombres de red), colocar una interfaz de red (interfaz) en el espacio de red correspondiente y asignar IP a la interfaz de red.

Actualmente, las soluciones que brinda CNI generalmente se dividen en dos tipos

1. Plano de túnel
2. Esquema de enrutamiento

En concreto: Soluciones de red Flannel, Callico, Weave y macvlan. En términos de dificultad, Callico es el más simple, seguido de Flannel, y Weave es el más complicado. Desde la perspectiva de la tecnología de red, tanto Weave como Flannel son tecnologías de túnel de encapsulación de red. La diferencia radica en la ubicación del encapsulado en el dispositivo de red o en el host.

Franela

Flannel es una solución de red propuesta por CoreOS para resolver la comunicación entre hosts en clústeres de contenedores. Flannel es esencialmente una red superpuesta, es decir, los datos TCP se empaquetan en otro paquete de red para enrutamiento, reenvío y comunicación. Actualmente, es compatible con UDP, VXLAN, AWS VPC, enrutamiento GCE y otros métodos de reenvío de datos, entre los cuales la tecnología VXLAN es la más Muchos centros de datos son populares y consideran cambiarse a la red VXLAN de Flannel al considerar la introducción de contenedores.

Flannel asigna una subred a cada host y el contenedor asigna una IP desde esta subred. Estas IP se pueden enrutar entre hosts y los contenedores se pueden comunicar entre hosts sin NAT ni mapeo de puertos. Flannel permite que diferentes hosts de nodos en el clúster tengan una dirección IP virtual única en todo el clúster al crear contenedores y conectarse a la red de nodos de host. Flannel puede volver a planificar las reglas de uso de direcciones IP para todos los nodos del clúster, de modo que los contenedores de diferentes nodos puedan obtener direcciones IP "de la misma intranet" y "no duplicadas", lo que permite que los contenedores de diferentes nodos pasen directamente a través de la intranet. Para la comunicación IP, la parte de encapsulación de red es invisible para el contenedor. El servicio de host de origen encapsula el contenido de datos original en UDP y lo entrega al nodo de destino de acuerdo con su propia tabla de enrutamiento. Una vez que llegan los datos, se desempaqueta y luego ingresa directamente a la tarjeta de red virtual del nodo de destino y luego llega directamente a la tarjeta de red virtual del contenedor del host de destino para lograr el propósito de la comunicación de red.

Aunque Flannel tiene altos requisitos en la red, se introduce la tecnología de encapsulación y la eficiencia del reenvío también se ve afectada, pero puede realizar una transición sin problemas a la red SDN. La tecnología VXLAN puede integrarse bien con SDN y es digna de implementación automática y operación inteligente y mantenimiento de toda la red. Y gestión, más adecuada para la implementación de redes de nuevos centros de datos.

Callico

La mayor diferencia entre la red de contenedores de Callico y otras redes virtuales es que no utiliza una red superpuesta para el reenvío de paquetes y proporciona un modelo de red puro de tres capas. El modelo de comunicación de tres capas significa que cada contenedor se comunica directamente a través de IP. Para que el enrutamiento funcione correctamente, el nodo host donde se encuentra cada contenedor debe tener alguna forma de conocer la información de enrutamiento de todo el clúster. Callico usa el protocolo de enrutamiento BGP para hacer que toda la red El nodo y el equipo de red de la red registran la ruta a toda la red.

Sin embargo, este método producirá muchas rutas no válidas, lo que requiere muchas especificaciones de enrutamiento del equipo de red, y toda la red no puede tener equipos con especificaciones de enrutamiento bajas. Además, Callico realiza el enrutamiento desde el contenedor de origen al host de origen, a través del centro de datos, luego al host de destino y finalmente al contenedor de destino. Todo el proceso siempre se enruta y reenvía de acuerdo con el protocolo BGP, sin paquetización ni desembalaje. Proceso, por lo que la eficiencia del reenvío será mucho más rápida, que es la ventaja técnica de la red de contenedores de Callico.

Tejido

Weave es esencialmente una red superpuesta. Weave puede virtualizar la red conectando contenedores en diferentes hosts en una red similar a una red local. Los diferentes hosts usan sus propias direcciones IP privadas. Cuando los contenedores se distribuyen en varios hosts diferentes En ese momento, la comunicación entre estos contenedores se puede simplificar a través de Weave.

Los contenedores en la red Weave usan puertos estándar para proporcionar servicios (por ejemplo, MySQL usa 3306 por defecto), y administrar microservicios es muy sencillo y simple. Cada contenedor puede comunicarse con otros contenedores a través de un nombre de dominio o comunicarse directamente sin usar NAT y sin mapeo de puertos o conexiones complicadas.

La mayor ventaja de implementar la red de contenedores Weave es que no necesita modificar el código de su aplicación. Weave inicia un enrutador virtual en cada host del clúster de contenedores y utiliza el host como un enrutador para formar una topología de red interconectada, sobre esta base, realiza la comunicación entre hosts del contenedor.

Para implementar Weave, debe asegurarse de que la versión del kernel de Linux del host sea superior a 3.8, Docker 1.10 o superior. Si hay un firewall para el acceso entre hosts, los firewalls deben permitir números de puerto como TCP 6783 y UDP 6783/6784. Estos son los puertos de datos y control de Weave. Los nombres no pueden ser iguales, Weave necesita identificar la subred por el nombre de host.

La red Weave es similar a la tecnología de superposición del host, que encapsula directamente el tráfico de paquetes en el host, para realizar el acceso mutuo entre el host y el host a través de la red subyacente de tres capas. Esta es la mayor diferencia con la red Flannel. Flannel es una solución de superposición de red. .

Macvlan

Macvlan es una característica relativamente nueva del kernel de Linux. Permite configurar múltiples interfaces de red virtual en una interfaz de red del host. Estas interfaces de red tienen sus propias direcciones MAC independientes y también se pueden configurar con direcciones IP para la comunicación. La máquina virtual o la red de contenedores en macvlan y el host están en el mismo segmento de red y comparten el mismo dominio de transmisión. Macvlan y bridge son similares, pero debido a que elimina la existencia de bridge, la configuración y la depuración son relativamente simples y la eficiencia es relativamente alta. Además, macvlan también es perfectamente compatible con VLAN.

ServicioMesh + CNI

ServiceMesh y CNI son una relación combinada. ServiceMesh no reemplaza a CNI. Trabajan en diferentes niveles de SDN. CNI trabaja más en el nivel L2-4 y ServiceMesh funciona en el nivel L5-7 Application SDN. ServiceMesh no se puede implementar de forma independiente de CNI y, junto con CNI, proporciona los servicios de red requeridos por las aplicaciones de microservicio jerárquico. Según un informe de Gartner, en 2020, casi el 100% de las nubes de contenedores tendrán la tecnología ServiceMesh incorporada. El Istio de código abierto actual solo proporciona gobernanza de microservicios dentro de un solo clúster de Kubernetes y carece de capacidades de nube de contenedores heterogéneos y de nube cruzada.

CNI debe entregarse a cada contenedor POD dentro del microservicio en la capa L2-4 de la nube de contenedores. La entrega del terminal de aplicación requería conexión de red L2, enrutamiento L3, aislamiento de seguridad de capa L2-4, seguridad general en la nube de contenedores, equilibrio de carga, etc.

ServiceMesh está más comprometido con la gobernanza del servicio a nivel de aplicación de microservicio y está comprometido con los servicios de red de capa L5-7. La malla de servicio implementa un proxy de aplicación Sidecar Envoy frente a cada contenedor de aplicaciones para proporcionar enrutamiento inteligente entre microservicios y cargas distribuidas. Equilibrio, gestión del tráfico, azul-verde, lanzamiento canario, elasticidad de microservicio, disyuntor de límite de corriente, reintento de timeout, visualización entre microservicios, seguridad, etc.
·

Red de contenedores de Docker

Docker proporciona varios tipos de redes, que determinan la forma de comunicación entre contenedores y entre contenedores y el mundo exterior.

• Tipo de red básica
  

• Ver todos los tipos de redes de contenedores:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
c79756cf9cde        bridge              bridge              local
204025a5abbc        host                host                local
9b9024f5ac40        macvlan             macvlan             local
6478888548d8        none                null                local
p2e02u1zhn8x        overlay             overlay             swarm

Modo Puente

La red Docker en modo puente se implementa en base a la tecnología de red virtual de Linux. Las interfaces de red de Container Docker son interfaces virtuales de forma predeterminada, que pueden aprovechar al máximo la eficiencia del reenvío de datos entre diferentes contenedores o entre contenedores a través de hosts. Esto se debe a que la tecnología de red virtual de Linux realiza el reenvío de datos entre interfaces virtuales copiando datos en el kernel, es decir: los paquetes de datos en el búfer de envío de la interfaz de envío se copiarán directamente al búfer de recepción de la interfaz de recepción sin pasar por Se intercambia equipo de red físico externo.

Cuando se inicia el Docker Daemon, se creará un puente de Linux llamado docker0 en el host, y los contenedores de Docker iniciados en el host se conectarán a este puente virtual. Docker Daemon asignará una IP desde la subred docker0 (una red virtual L2) al contenedor para su uso, y establecerá la dirección IP de docker0 como la puerta de enlace predeterminada del contenedor. Al mismo tiempo, cree un par de dispositivos de cable de red virtual de cinco pares en el host. Docker Daemon inserta un extremo del dispositivo de cinco pares en el contenedor recién creado y lo nombra eth0 (la tarjeta de red del contenedor), e inserta el otro extremo en el puente de Linux docker0 en formato vethxxx nombre.

Los contenedores en esta red pueden comunicarse entre sí. Si el mundo exterior quiere acceder a los contenedores en esta red, también necesitan acceder a la red puente e implementar reglas DNAT a través de iptables para lograr la conversión de direcciones internas y externas.

$ ip a
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever

$ docker run -itd --name box1 busybox

$ docker exec -it box1 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

/ # ip r
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

$ brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.024246c300eb	no		vethd4ae072

modo anfitrión

Si se utiliza el modo de host al iniciar el contenedor, el contenedor no obtendrá un espacio de nombres de red independiente, pero compartirá un espacio de nombres de red con el host. En otras palabras, Container no virtualizará su propia tarjeta de red, configurará su propia IP, etc., sino que utilizará directamente la IP y el puerto del host.

Por supuesto, otros aspectos del contenedor, como el sistema de archivos, la lista de procesos, etc., aún están aislados del host. Los contenedores que solo usan este tipo de red usarán la red del host. Este tipo de red está completamente abierta al mundo exterior. Si puede acceder al host, puede acceder al contenedor.

$ docker run -itd --network host --name box2 busybox

$ docker exec -it box2 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:94:84:10 brd ff:ff:ff:ff:ff:ff
    inet 172.18.22.204/24 brd 172.18.22.255 scope global dynamic eth0
       valid_lft 48054sec preferred_lft 48054sec
    inet6 fe80::f816:3eff:fe94:8410/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever
7: vethd4ae072@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0
    link/ether ce:95:19:64:d0:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::cc95:19ff:fe64:d0d4/64 scope link
       valid_lft forever preferred_lft forever

modo macvlan

Para algunas aplicaciones, como la necesidad de monitorear el tráfico de la red y esperar conectarse directamente a la red física, en este caso, puede usar el modo de red macvlan. El controlador macvlan no solo asigna la dirección IP al contenedor, sino que también asigna la dirección MAC física al envase. A través de macvlan, también se puede realizar la comunicación antes del contenedor entre hosts.

1. Cree una red macvlan:

docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=eth0 macvlan1

2. Configure la tarjeta de red en modo promiscuo:

ip link set eth0 promisc on

3. Cree un contenedor usando la red macvlan:

docker run -it --network macvlan1  --ip=172.16.86.2 busybox /bash

Modo contenedor

El modo contenedor, también conocido como enlaces Docker, es un mecanismo de comunicación entre contenedores Docker. Si un nuevo contenedor está vinculado a un contenedor existente, el nuevo contenedor obtendrá la información del enlace del contenedor existente a través de variables de entorno. La comunicación entre contenedores se realiza proporcionando información de enlace sobre contenedores existentes a contenedores confiables.

El modo contenedor es similar al modo host, excepto que el contenedor creado en el modo contenedor comparte la IP y el puerto de otros contenedores en lugar de la máquina física. En este modo, el contenedor en sí no configura la red ni el puerto. Después de crear este modo, lo encontrará dentro. La IP es la IP del contenedor que especificó y el puerto también se comparte. Por supuesto, otros están aislados entre sí, como los procesos.

docker run -it --network container:<container ID>

modo ninguno

En modo ninguno, el contenedor tendrá su propio espacio de nombres de red, pero no realiza ninguna configuración de red para el contenedor. En otras palabras, este Contenedor no tendrá información como tarjeta de red, IP, enrutamiento, etc. Debe agregar tarjetas de red manualmente y configurar la IP para el contenedor. Los contenedores que utilicen este tipo de red estarán completamente aislados.

Después de usar el modo ninguno, el contenedor se cierra y no participará en la comunicación de la red, por lo que se puede garantizar la seguridad del contenedor.

$ docker run -itd --network none --name box3 busybox

$ docker exec -it box3 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

Modo de superposición

El modo de superposición se utiliza en clústeres Swarm para conectar contenedores Docker entre hosts, lo que permite que los contenedores en diferentes hosts se comuniquen entre sí. El modo de superposición agrega una capa de red virtual entre los nodos del clúster de Docker. Tiene un segmento de red virtual independiente. Por lo tanto, el contenido enviado por el contenedor se enviará primero a la subred virtual y luego la subred virtual se empaquetará como la URL real del host para la entrega. .

# 初始化 manager node。
$ docker swarm init

# 添加 worker node 到 manager。
$ docker swarm join --token <token> <manager_host>:2377

# 新建一个 Overlay 网络
$ docker network create --driver=overlay --attachable overlay

# 分别在不同的 worker node 上启动一个 busybox 容器，并连接到 Overlay 网络
$ docker run -it --network overlay --name box4 sh

De esta manera, los contenedores entre hosts en la misma red superpuesta pueden comunicarse entre sí.

Basándonos en Swarm, también podemos administrar los servicios de clúster de contenedores. Por ejemplo, crear un clúster de Nginx con cinco copias conectadas a la red Overlay, y el puerto expuesto es 80:

$ docker service create --name my-nginx --publish target=80,published=80 --replicas=5 --network overlay nginx

En este clúster de Nginx, si algún nodo finaliza una copia, el servicio de clúster reiniciará una nueva copia para mantener el número de copias de Nginx en todos los nodos de trabajo en cinco.

Mapeo de puertos de contenedores

Opciones principales:

• -p Puerto de host: asigna el puerto de escucha de la aplicación en el contenedor a un puerto específico en el host físico.

Ejemplo:

• Mapeo personalizado:

docker run -d -p 8888:80  nginx:latest 

• Mapeo aleatorio

# 需要镜像支持
docker run -P