apapacy Feb 24 2019 at 20:44

Load Balancers для систем оркестрации

6 min

29K

DevOps*Kubernetes*

Tutorial

+16

Comments 12

usego Feb 24 2019 at 22:19

> В haproxy только недавно появилась возможность рестартовать процесс в «мягком» режиме, но при этом все равно контейнер докер останавливается

Это точно? Сам не пробовал, но в официальном докере написано:

Reloading config
If you used a bind mount for the config and have edited your haproxy.cfg file, you can use HAProxy's graceful reload feature by sending a SIGHUP to the container:

$ docker kill -s HUP my-running-haproxy

apapacy Feb 25 2019 at 00:08

Спасибо за дополнение. Я дополнил статью Вашим примером из документации.
В этом случае будет «жесткая» перегрузка haproxy. Т.к. механизм «мягкой загрузки» подразумевает одновременную работу двух процессов. В документации haproxy, на которую ссылается Ваш источник это процесс описан так:

The graceful stop is triggered when the
SIGUSR1 signal is sent to the haproxy process. It consists in only unbinding
from listening ports, but continue to process existing connections until they
close. Once the last connection is closed, the process leaves.

citius Feb 25 2019 at 00:27

Про fabio зря сказано, что он работает только с Nomad, т.к. на самом деле работает он только с Consul, но сервисы в консуле можно регистрировать как угодно, хоть Nomad, хоть простые виртуалки, хоть другие системы окрестрации.

apapacy Feb 25 2019 at 00:41

Исправил в тексте

powerman Feb 25 2019 at 07:23

Было бы интересно почитать общее сравнение разных способов реализовать балансировщик, начиная с вариантов "для бедных" вроде DNS плюс обычный nginx (через resolver a.b.c.d; и proxy_pass $backend;), встроенный балансировщик docker swarm, AWS ELB, вышеупомянутые træfik и haproxy, платный NGINX Plus, …

alexesDev Feb 25 2019 at 09:15

Оно есть на английском
www.hashicorp.com/blog/load-balancing-strategies-for-consul

Там не указан traefik, но это можно просто в его доке посмотреть (в разделе Consul Catalog).

Valsha Feb 25 2019 at 18:28

Добрый день. Очень интересная тема, как раз последние 2-3 дня разбираюсь с Load Balancers для систем оркестрации, в моем случае это Docker Swarm.

Подскажите пожалуйста, я использовал этот материал для развертывания и деплоя — habr.com/ru/post/344324 (запущен 1 manager и 3 воркера)
В данном примере используется nginx как Load Balancers, но там он работает в моем случае (возможно я что то упустил) очень плохо, часто вижу ошибку 502 Bad Gateway (тайминги/задержки в nginx выставил по 900ms)

При этом в логах

dz6prru com.docker.swarm.node.id=tyllayuan6hd5uhtkr9nlz55y,com.docker.swarm.service.id=aincbpoo6d4etcrcat4upmba7,com.docker.swarm.task.id=dz6prrugfy9lypymsvdxomxdp 2019/02/24 22:21:00 [emerg] 1#1: host not found in upstream «web» in /etc/nginx/conf.d/flask.conf:26

mvchude 10.255.0.2 — - [24/Feb/2019:22:23:38 +0000] «GET / HTTP/1.1» 499 0 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6» "-"

54ukzuf 10.255.0.2 — - [24/Feb/2019:22:25:50 +0000] «GET / HTTP/1.1» 502 157 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6» "-"

54ukzuf 10.255.0.2 — - [25/Feb/2019:08:41:05 +0000] «GET / HTTP/1.1» 499 0 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6» "-"

mvchude 2019/02/24 22:39:53 [error] 6#6: *3 connect() failed (110: Connection timed out) while connecting to upstream, client: 10.255.0.2, server:, request: «GET / HTTP/1.1», upstream: «10.0.1.94:5000/», host: «192.168.21.66:88»

54ukzuf 2019/02/24 22:25:50 [error] 6#6: *1 connect() failed (110: Connection timed out) while connecting to upstream, client: 10.255.0.2, server:, request: «GET / HTTP/1.1», upstream: «10.0.1.94:5000/», host: «192.168.21.66:88»

mvchude 10.255.0.2 — - [24/Feb/2019:23:00:42 +0000] «GET / HTTP/1.1» 200 71 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6» "-"

Я по ману пробовал настроить Traefik docs.traefik.io/user-guide/swarm-mode
1. docker network create --driver=overlay traefik-net

2. docker service create \

 --name traefik \

 --constraint=node.role==manager \

 --publish 90:90 --publish 9090:9090 \

 --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \

 --network traefik-net \

 traefik \

 --docker \

 --docker.swarmMode \

 --docker.domain=traefik \

 --docker.watch \

 --api

Но на manager_swarm_ip:9090 ничего не открывает тоже.
Даже и не знаю куда еще «копать».
Может вы что то посоветуете,
Спасибо.

apapacy Feb 25 2019 at 19:52

Я со swarm не разбирался. Судя по строчке в логах host not found in upstream не настроена сеть.

powerman Feb 25 2019 at 20:14

В swarm встроенный балансировщик: подключение на открытый внешний порт любого узла swarm-а автоматически перенаправляет запрос на внутренний порт одного из тех узлов swarm, на котором сейчас запущен данный сервис (контейнер).

Valsha Feb 26 2019 at 12:50

Это понятно, что в «swarm встроенный балансировщик», просто не могу разобратся чего одна и та же нода, может так вот работать:

54ukzuf 10.255.0.2 - - [24/Feb/2019:22:25:50 +0000] "GET / HTTP/1.1" 502 157 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [25/Feb/2019:08:41:05 +0000] "GET / HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [25/Feb/2019:20:44:59 +0000] "GET / HTTP/1.1" 200 71 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [25/Feb/2019:20:45:00 +0000] "GET / HTTP/1.1" 200 71 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [25/Feb/2019:20:45:06 +0000] "GET / HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [26/Feb/2019:04:40:13 +0000] "GET / HTTP/1.1" 499 0 "-" "NetSystemsResearch studies the availability of various services across the internet. Our website is netsystemsresearch.com" "-"

54ukzuf 10.255.0.2 - - [26/Feb/2019:08:56:37 +0000] "GET / HTTP/1.1" 200 71 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6" "-"

54ukzuf 10.255.0.2 - - [26/Feb/2019:08:56:39 +0000] "GET / HTTP/1.1" 200 72 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6"

Понтяно было бы если разные ноды и может проблема была с каким то из узлов, а так…

powerman Feb 26 2019 at 16:50

Я отвечал не Вам. А по Вашей проблеме смотреть надо логи backend-сервиса, в который эти запросы передаются, плюс смотреть не перезапускаются ли постоянно какие-нибудь контейнеры. 499 обычно означает, что backend слишком долго обрабатывал запрос и клиент отвалился, 502 что nginx не достучался до backend — в общем, проблема не с nginx, и его логи тут не сильно помогут.

Valsha Mar 1 2019 at 15:09

powerman
Вы правы. Проблема была не с nginx.
Проблема с OVH и их «кастомными ядрами».
Уже и раньше с ними (с проблемами что эти ядра доставляли) сталкивался, но уже и забыл за это.
Потом зашел на сервера и посмотрел логи уже в самих серверах (/var/log/messages), увидел ошибки на «vxlan»
Начал гуглить и нашел упоминание тут —
stackoverflow.com/questions/52762893/starting-container-failed-subnet-sandbox-join-failed-for-10-255-0-0-16

The VPS / root server hoster OVH does use a custom kernel, which did not have activated vxlan support.

Благо что у OVH при установке можно указать что бы ставилось оригинальное ядро, с чем проблема была и решена.
Спасибо.