¿Cuál es el mecanismo de equilibrio de carga interno junto con el enjambre de docker v1.12?

El modo Docker Swarm logra el balance de carga interno, y hasta donde yo sé, nginx se llama equilibrio de carga dura, zookeeper es un equilibrio de carga suave.

Entonces, ¿cuál es el mecanismo del Equilibrio interno de carga que viene junto con Docker v1.12?

¿Incorpora un nginx dentro o methods similares como zookeeper?

¿Equilibrio de carga "interno"? No exactamente.
Commit ea4fef2 lo documenta ( docs/swarm/key-concepts.md ) como

Swarm utiliza el equilibrio de carga de input para exponer los services que desea que estén disponibles externamente para Swarm.
Swarm puede asignar automáticamente el service a PublishedPort o puede configurar un puerto PublishedPort para el service en el range 30000-32767.
Los componentes externos, como los equilibradores de carga en la nube, pueden acceder al service en el PublishedPort de cualquier nodo del clúster, incluso si el nodo no está actualmente ejecutando el service.

Swarm tiene un componente interno de DNS que asigna automáticamente cada service en la input de Swarm DNS.
Swarm utiliza el equilibrio de carga interno para distribuir requestes entre services dentro del clúster en function del nombre DNS de los services.

En este momento (docker 1.12 agosto de 2016), ese balanceo interno de carga no funciona de manera consistente: problema 25325

 ➜ ~ time curl http://10.218.3.5:30000 I'm 272dd0310a95 curl http://10.218.3.5:30000 0.01s user 0.01s system 6% cpu 0.217 total ➜ ~ time curl http://10.218.3.5:30000 curl: (7) Failed to connect to 10.218.3.5 port 30000: Operation timed out 

Y el número 1077 de swarmkit ilustra que aún no hay un plan para

proporcionar capacidades para la coinheritance de session (basada en cookies, etc.) en esta malla de enrutador.
Tan increíble como sería, no todas las aplicaciones son apátridas, y tenemos que enrutar a los usuarios al contenedor adecuado en ciertos casos

Porque:

dado que hacemos equilibrio de carga en L3 / L4, no puede ser base en cosas como la cookie de session.
Lo mejor que se puede hacer es tener pegajosidad basada en IP de origen.

Y la fuente IP no siempre es lo suficientemente buena:

Eso no funcionaría para nuestro caso.
Tendríamos un equilibrador de carga ascendente (F5) que haría que el tráfico pareciera provenir de una única IP, la IP del "set SNAT" en el F5, ya que es un proxy completo.
Efectivamente, la rigidez basada en IP de origen haría que todas las requestes vayan a un contenedor dado que todas las direcciones IP de origen vendrían de la misma dirección.

Por lo tanto, el equilibrador de carga interno sigue siendo bastante "básico":

El problema principal con la adición de "pegajosidad de session" es que hay cientos de maneras de hacerlo.
También es una característica L7, mientras que nuestro equilibrio de carga funciona en L3 / 4 .

Hay dos paths de alto nivel aquí:

  • Controle los events provenientes de la API del acoplador para modificar el estado F5 para enrutar directamente las ranuras de tarea.
  • Integre con libnetwork y haga que loadbalancer funcione como lo haría L7 LB si se ejecutara directamente en el enjambre.

La conclusión por ahora es:

Si desea manejar todos los aspectos del equilibrio de carga y no usar IPVS, puede deshabilitarlo ejecutando services en modo DNSRR. Puede ejecutar cualquier equilibrador de carga dentro de un enjambre para equilibrar la carga, eludir el service VIP y completar los back-end con las inputs de DNSRR.

Es por eso que la última versión 1.12 tiene, con la PR 827 , soporte adicional para el modo DNSRR y la inhabilitación de ingreso.