Мы запускаем среду из 6 движков с 30 контейнерами в каждом. Два движка запускают контейнеры с прокси nginx. Эти два контейнера — единственный путь в сеть.

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

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

Еще немного деталей:

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

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

на контейнере nginx (10.10.0.37 на prod-3) запускаем пинг и как видим: 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 (брандмауэр не отвечает, аппамор тоже).

Внутри ответственного контейнера (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, которую использует докер, поэтому, если у кого-нибудь есть подсказка, не могли бы вы помочь нам ссылкой или инструментом об этом?

Заранее большое спасибо. Андре

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

Только что снова возникла та же ситуация после обновления docker-ce с 18.06 до 18.09.

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

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

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

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