Мы работаем в среде из 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, поэтому, если у кого-нибудь есть подсказка, не могли бы вы помочь нам с ссылкой или инструментом по этому поводу?
Большое спасибо вавансовый.Андре
=========================================================== Через 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. перезапустить все enigines 5. перезапустить контейнер nginx ... понял, сеть сейчас работает.