Проблемы с наложением Docker-сети при подключении контейнеров

Question

Мы работаем в среде из 6 двигателей, каждый с 30 контейнерами. Два двигателя работают с контейнерами с прокси nginx. Эти два контейнера - единственный путь в сеть.

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

Оба контейнера nginx не могут получить доступ к некоторым контейнерам на других машинах. Только один физический движок имеет эту проблему, все остальные в порядке. Это началось с таймаутов некоторых машин, и теперь через 24 часа все контейнеры на этой машине имеют проблемы.

Еще несколько деталей:

Nginx работает на машине Prod-3. Второй Nginx работает на машине Prod-6. Контейнеры с проблемами работают на Prod-7. Оба nginx не могут достигнуть контейнеров, но контейнеры могут достигнуть nginx через "ping".

В начале и сегодня утром мы могли добраться до некоторых контейнеров, а другие - нет. Это началось с тайм-аутов, теперь мы не можем пропинговать контейнеры в оверлейной сети. На этот раз мы можем посмотреть трафик с помощью tcpdump:

в контейнере nginx (10.10.0.37 на prod-3) мы запускаем ping и, как вы можете видеть: 100% потерянных пакетов:

root@e89c16296e76:/# ping ew-engine-evwx-intro
PING ew-engine-evwx-intro (10.10.0.177) 56(84) bytes of data.

--- ew-engine-evwx-intro ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7056ms

root@e89c16296e76:/# 

На целевой машине prod-7 (не внутри контейнера) - мы видим, что все пакеты ping получены (поэтому оверлейная сеть правильно маршрутизируется на prod-7):

wurzel@rv_____:~/eventworx-admin$ sudo tcpdump -i ens3 dst port 4789 |grep 10.10.0.177
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 10.10.0.37.35270 > 10.10.0.177.http: Flags [S], seq 2637350294, win 28200, options [mss 1410,sackOK,TS val 1897214191 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37.35270 > 10.10.0.177.http: Flags [S], seq 2637350294, win 28200, options [mss 1410,sackOK,TS val 1897214441 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37.35326 > 10.10.0.177.http: Flags [S], seq 2595436822, win 28200, options [mss 1410,sackOK,TS val 1897214453 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 1, length 64
IP 10.10.0.37.35326 > 10.10.0.177.http: Flags [S], seq 2595436822, win 28200, options [mss 1410,sackOK,TS val 1897214703 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 2, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 3, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 4, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 5, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 6, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 7, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 8, length 64
^C304 packets captured
309 packets received by filter
0 packets dropped by kernel

wurzel@_______:~/eventworx-admin$ 

Сначала - вы можете видеть, что нет ответа ICMP (брандмауэр не отвечает, также не appamor).

Внутри ответственного контейнера (evwx-intro = 10.10.0.177) ничего не получено, интерфейс eth0 (10.10.0.0) просто молчит:

root@ew-engine-evwx-intro:/home/XXXXX# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@ew-engine-evwx-intro:/home/XXXXX# 

Это действительно странно.

Любой другой инструмент из докера, который может помочь нам увидеть, что происходит?

Мы ничего не меняли в брандмауэре, также не было автоматических обновлений системы (возможно, безопасности).

Единственным действием было то, что некоторые старые контейнеры были реактивированы после длительного периода (возможно, 1-2 месяца бездействия).

Мы действительно потерялись, если бы вы испытали что-то сопоставимое, было бы очень полезно понять шаги, которые вы предприняли.

Большое спасибо за любую помощь с этим.

================================================== ===========

6 часов спустя

После попытки почти всего за целый день, мы сделали последнюю попытку: (1) остановить все контейнеры (2) остановить службу докера (3) остановить службу сокета докера (4) перезапустить машину (5) запустить контейнеры

... сейчас это выглядит хорошо в данный момент. В заключение: (1) мы понятия не имеем, что вызвало проблему. Это плохо. (2) Мы узнали, что оверлейная сеть не является проблемой, потому что трафик достигает целевой машины, на которой живет контейнер (3) Мы можем отслеживать сетевой трафик, пока он не достигнет целевой машины. Почему-то это не "вход" в контейнер. Потому что внутри контейнера сетевой интерфейс вообще не показывает активности.

Мы ничего не знаем о виртуальной сети vxnet, которая используется Docker, поэтому, если у кого-нибудь есть подсказка, не могли бы вы помочь нам с ссылкой или инструментом об этом?

Большое спасибо заранее. Andre

================================================== ==== 4 дня спустя...

Просто опять была такая же ситуация после обновления докер-се 18.06 до 18.09.

У нас есть две машины, использующие docker-ce 18 в сочетании с ubuntu 18.04, и я только что обновил docker-ce до 18.09 из-за этой проблемы (контейнер Docker не должен разрешать DNS в Ubuntu 18.04 ... новая разрешенная служба).

Я остановил все машины, обновил докер, перезагрузил машину, запустил все машины.

Проблема: та же проблема, которая описана в этом посте. Пинг был получен целевой операционной системой, но не был перенаправлен в контейнер.

Решение: 1. остановить все контейнеры и докер 2. уйти из консула, 3. очистить все записи в хранилище ключей консула на других машинах (не был удален из отпуска) 3. запустить консул 4. перезапустить все enigines 5. перезапустить контейнер nginx... готча Сеть работает сейчас.

Answer 1

Я столкнулся с точной проблемой при настройке Docker Swarm в оверлейной сети. Я обнаружил, что это не проблема ОС или Docker. Затронутые серверы используют Intel NIC серии X. Другие серверы с сетевым адаптером I серии работают нормально. Вы используете локальные серверы? Или любой облачный провайдер? Мы используем OVH, и это может быть вызвано неправильной конфигурацией сети центра обработки данных.

Answer 2

Еще раз та же самая проблема ударила нас. У нас есть 7 серверов (на каждом из которых работает докер, как описано выше), две точки входа nginx.

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

В нашей конфигурации все 7 серверов имеют собственный экземпляр локального консула, который синхронизируется с остальными. Для настройки сети каждая докерская служба выполняет поиск в своем локальном хранилище ключей консула.

На прошлой неделе мы заметили, что в то же время о проблеме доступности сети также клиенты консула сообщают о проблемах с синхронизацией (проблемы выбора лидера, повторы и т. Д.).

Окончательное решение состояло в том, чтобы остановить механизмы докеров и консулов. Удалите базу данных консула на некоторых серверах, снова присоедините ее к другим. Запустите докер двигателей.

Похоже, что служба консула является важной частью конфигурации сети...

В ходе выполнения...