Фон
Мы поддерживаем «кластер» хостов Ubuntu, на котором работают наши производственные приложения.Хосты запускают множество различных док-контейнеров, таких как
- консул для мониторинга контейнеров и обнаружения службы Prometheus
- эластичный кластер поиска с несколькими logstash и kibana
- prometheus
- grafana
- внутренне разработанные приложения (службы с A по K на диаграмме ниже)
Каждый хост также работает
- filebeat
- nginx
- keepalived
- консул для оверлейной сети Docker
Настройка следующая: 
Информация об изображении
- Host consul открывает порты в 2xxx, а не в стандартном 8xxx
- Не все док-контейнеры открыты для внешнего мира, дляНапример,
elasticsearch-slave1 не имеет открытых портов, но внутренние порты отображаются как :9200 - . Докер-консул использует оверлейную сеть для всех соединений, и только
consul-master на хосте 1 имеет порт 8500, видимый извне.
Конфигурация
Часть этой информации может вообще не относиться к проблеме.
Хост: Ubuntu 16.04.3 LTS
Услуги хоста
| Application | Version |
| ----------- | ---------- |
| docker | 18.03.1-ce |
| consul | v1.0.2 |
Службы Docker
| Application | Version |
| ------------- | ------- |
| consul | v1.0.2 |
| elasticsearch | 5.6.4 |
| logstash | 5.6.4 |
| kibana | 5.6.4 |
| prometheus | 2.0.0 |
docker.service
Докер на каждом хосте настроен следующим образом:
[Service]
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise ${THIS_MACHINES_IP}:2375 --cluster-store consul://${THIS_MACHINES_IP}:2500 --label com.domain.hostname=host05.domain.com
Проблемы
Когда мы впервые развернули эту конфигурацию, она работала невероятно хорошо.Но со временем сеть наложения Docker становится все менее надежной. Контейнеры на HostX просто не смогут обмениваться данными с другими контейнерами на HostY, используя оверлейную сеть .
Например, prometheus на Host5 собирает информацию с service A на Host1, но частосообщить "no route to host" или "context deadline exceeded".Если я docker exec в prometheus контейнер и пытаюсь пинговать или свернуть service A, я просто получаю тайм-ауты.Однако, если я docker exec в service A и попытаюсь пропинговать и свернуть prometheus, пакеты проходят, и это, кажется, "пробуждает" сеть.Теперь prometheus может снова увидеть службу.
Та же проблема возникает между несколькими службами - это часто приводит к тому, что logstash не может отправлять сообщения elasticsearch или elasticsearch-master не может связаться сslaves, что нарушает работу кластера.
Поскольку эта установка активно используется в нашей производственной среде, мы не можем позволить себе простои в сети, подобные этой.Я реализовал набор запланированных заданий, которые скручиваются между различными службами, чтобы поддерживать работу сети.Это, очевидно, не очень хорошее долгосрочное решение!
Что делает ситуацию еще хуже, были случаи, когда сеть становилась настолько плохой, что задания скручивания / пинга не помогали, и перезагрузка хоста или докеранет эффекта.Единственное решение, которое я нашел, это
- Создать новую
temporary overlay сеть - Отключить каждый контейнер от
primary overlay и подключить их к temporary overlay - Удалить
primary overlay - Создать новый
primary overlay - Отключить каждый контейнер от
temporary overlay и подключить их к primary overlay - Удалить
temporary overlay
Этот подход был лучшим решением, которое я нашел до сих пор для полного восстановления сети.Затем он будет работать хорошо в течение некоторого времени, прежде чем снова упадет.
Вопросы
Актуальный вопрос для меня: Как я могу отладить эту проблему и найти причину?
Есть несколько человек, которые сталкивались с этой проблемой, но, как правило, в небольших установках и не в том же масштабе, что и выше.В настоящий момент мне кажется, что я работаю в сети Шредингера ...
Вторично к этому - Есть ли лучший способ реализовать оверлейную сеть?
Я началэкспериментируя с weave и Open vSwitch, но ни одна из них не является хорошей заменой текущей сети.
Weave потребует повторного развертывания всех контейнеров (что возможно), но он добавляет дополнительный сетевой интерфейс к каждому контейнеру, а интерфейс ethwe не является основным интерфейсом, который вызывает проблемы с consul иprometheus, которые привязываются к определенному интерфейсу / адресу.
Open vSwitch выглядит как капля замены, но я не мог заставить его работать с версией LTS (2.5.x) и должен был собрать 2.10.x из исходного кода.Сначала казалось, что это работает, но elasticsearch не кластеризован, а consul, похоже, действительно изо всех сил пытается общаться по сети.prometheus также не может запросить consul по некоторым причинам.Я предполагаю, что некоторые пакеты отбрасываются коммутатором, что может быть просто проблемой конфигурации.
Редактировать - 28/09/2018
С момента публикации этого вопроса я тестировал использование Docker Swarm для управления оверлейной сетью.
Пока что он работает довольно хорошо, и сеть не перестает работать случайно, как это было при использовании хранилища кластеров консулов.Тем не менее, есть некоторые ключевые различия и некоторые общие ошибки.Например:
- Выполнение
docker network inspect <my overlay network> на хосте only покажет контейнеры, работающие на этом хосте.При использовании Consul в качестве хранилища кластеров вы можете видеть всю сеть с любого хоста. - Все еще можно перевести сеть в плохое состояние, когда контейнеры не могут видеть друг друга.Это возможно путем остановки, удаления и повторного создания контейнера (с тем же именем, что и раньше) относительно быстро.В этом сценарии существующие контейнеры продолжают использовать old DNS-запись и не могут подключиться.