El contenedor no puede acceder al nombre de dominio.
Después de instalar Docker, el demonio de Docker creará automáticamente tres redes para nosotros, de la siguiente manera:
De hecho, Docker tiene cuatro modos de comunicación de red, a saber: puente, host y inalámbrico, contenedor.
El modelo de red predeterminado es puente, que también se utiliza en nuestra producción.
A continuación, compartiré con ustedes los principios de interoperabilidad de contenedores acoplables. En ese momento también se utilizaba el modelo de red puente.
Además, después de instalar Docker, Docker creará un dispositivo de red llamado docker0 para nosotros.
Puedes verlo a través del comando ifconfig. Parece ser equivalente al estado de la red eth0, como una tarjeta de red. Sin embargo, docker0 es en realidad un puente de Linux.
¿Por qué lo ves? Puede ver información del puente en el sistema operativo con el siguiente comando.
Entonces, ¿cómo entender el concepto de puente Linux?
De hecho, ¡puedes entender docker0 como un conmutador virtual! Entonces, por analogía y comprensión de lo siguiente, de repente os iluminaréis.
1. Es como el gran interruptor que hay al lado del profesor en la sala de ordenadores de la universidad.
2. Conecte todas las computadoras en la sala de computadoras al conmutador y compárelas con el contenedor acoplable. El contenedor acoplable está conectado a docker0 en el host como dispositivo.
3. Coloque la IP del conmutador y la máquina en la sala de computadoras en el mismo segmento de red y compárela con docker0. La IP del contenedor acoplable que inició también pertenece al segmento de red 172.
La analogía es esta:
Acabamos de usar una analogía para entender docker0: conecte todas las computadoras en la sala de computadoras al conmutador, compárelo con un contenedor acoplable y sirva como un host El dispositivo conectado a docker0. Entonces, ¿qué tecnología se utiliza para lograr la implementación?
La respuesta es: quinto par.
El nombre completo del quinto par es: virtual Ethernet, que es una tarjeta Ethernet virtual.
Cuando se trata de tarjetas Ethernet, todo el mundo las conoce. ¿No se llaman dispositivos de red comunes eth0 o ens?
Entonces, ¿cómo juega este par de veth? ¿De qué sirve? Puedes ver la imagen a continuación.
Los dispositivos Veth-pair siempre aparecen en pares para conectar dos espacios de nombres de red diferentes.
Como se muestra en la figura anterior, los datos enviados por veth0 de network-namespace1 aparecerán en el dispositivo veth1 de network-namespace2.
Aunque esta característica es excelente, si tiene varios contenedores, encontrará que la estructura organizativa se volverá cada vez más compleja y confusa.
Afortunadamente, aquí hemos comprendido gradualmente el puente de Linux (docker0) y el dispositivo de par veth, por lo que podemos volver a dibujar el diagrama de arquitectura general de la siguiente manera.
Debido a que los diferentes contenedores tienen sus propios espacios de nombres de red aislados, cada uno tiene su propia pila de protocolos de red.
Entonces, ¿podemos averiguar qué tarjeta en el contenedor y en la máquina física es un par de dispositivos de red vethpair?
Como se muestra a continuación:
Regrese a la computadora principal
En otras palabras, la tarjeta de red eth0 del contenedor 545ed62d3abf y el número de dispositivo de red visto por el host a través del comando ip addr. Se forma un par de dispositivos vethpair para los 55 dispositivos, ¡y el tráfico puede comunicarse entre sí!
Veamos un método simple para intercambiar datos entre diferentes hosts A y B en la misma LAN. Como se muestra a continuación
Bueno, dado que están en la misma LAN, significa que las direcciones IP de A y B están en el mismo segmento de red. Como se muestra en la figura anterior, supongamos que ambos están en el segmento de red 192.168.1.0.
Hay que fijarse en el modelo de red OSI de 7 capas que aparece a continuación.
El host A envía datos al host B. Para el host A, los datos se transferirán desde la capa de aplicación superior a la capa inferior. Por ejemplo, ¿qué sucede cuando se utiliza la capa de aplicación?
¿Tiene las reservas de conocimiento anteriores? No es difícil examinar las cuestiones que vamos a discutir hoy.
La parte roja es la siguiente: ¿Cómo se comunican entre sí diferentes contenedores en el mismo host?
Luego iniciamos sesión en los contenedores respectivamente y registramos sus IP.
Veamos primero los resultados experimentales: curl9002 en 9001.
¡El resultado experimental es la interoperabilidad de la red!
Mejoremos la imagen de arriba y agreguemos docker0 y las IP de los dos contenedores, como se muestra a continuación:
Las dos máquinas deben seguir el modelo de red OSI y el protocolo Ethernet antes de comunicarse.
Llamamos al 172 438+07.0.2 Contenedor 2.
Llamamos al 172 438+07.0.3 contenedor 3.
Por ejemplo, si ahora sacamos el contenedor 3 del contenedor 2, entonces el contenedor 2 también debe encapsular el paquete de acuerdo con el protocolo Ethernet como se muestra a continuación.
Entonces la pregunta ahora es ¿cuál es la dirección mac del contenedor número 3?
El contenedor 2 primero comprobará su caché local. Si no se ha accedido antes, ¡no habrá ningún registro en el caché!
Pero no importa, también existe un mecanismo arp, por lo que el contenedor 2 enviará un paquete de solicitud arp, más o menos de la siguiente manera.
El contenedor 2 consultará su propia tabla de enrutamiento y emitirá esta solicitud arp desde su propia puerta de enlace.
Descubrimos que la IP del dispositivo de red correspondiente a la puerta de enlace del contenedor 2 es la dirección IP de docker0 y se envía a través de eth0.
¿Eh? ¿No es eth0 el dispositivo de cinco pares que mencionamos antes?
Con el siguiente comando, podemos saber a qué dispositivo de red del host corresponde el otro extremo:
Y podemos hacer el siguiente pequeño experimento para verificar si el punto de vista anterior es correcto.
Por lo tanto, el mensaje de solicitud arp de eth0 del contenedor 2 aparecerá en el dispositivo de red número 53 del host al mismo tiempo.
Como se puede ver en la figura siguiente, el dispositivo de red número 53 es en realidad veth0-1 en la figura siguiente.
Por lo tanto, este paquete de solicitud arp se enviará a docker0. Cuando docker0 recibe este mensaje arp, descubre que la IP de destino es 172.17.0.3, no él mismo, por lo que docker0 transmitirá aún más este mensaje de solicitud arp y todos los contenedores en el segmento de red 172.17.0.0 pueden recibir este mensaje. ¡Incluido el contenedor número 3!
Después de recibir este mensaje arp, el contenedor 3 juzgará, ¡oh! La IP de destino es su propia IP, así que complete su propia dirección mac en el mensaje arp y devuélvala a docker0.
Del mismo modo, podemos verificarlo tomando el paquete en el host.
Entonces el contenedor 2 obtiene la dirección mac del contenedor 3 y la información necesaria para el paquete Ethernet está completa. Como se muestra a continuación:
Después de eso, el contenedor 2 se puede conectar al contenedor 3 normalmente.
El contenedor 3 recibirá muchos paquetes, entonces, ¿cómo sabe qué paquetes se envían a sí mismo y cuáles no? Puede consultar la siguiente lógica de juicio.