Мне нужна помощь в отладке следующей настройки:
У меня есть 3 экземпляра Cloud от хостинговой компании. (Я считаю, что VPS - это VMWare, но я не могу найти никакой документации на сайте хост-компаний.)
Все версии докеров одинаковые:
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:29:52 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:28:22 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.4
GitCommit: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc:
Version: 1.0.0-rc6+dev
GitCommit: 6635b4f0c6af3810594d2770f662f34ddc15b40d
docker-init:
Version: 0.18.0
GitCommit: fec3683
One Node 1 Я выполнил следующую команду инициализации:
docker swarm init --advertise-addr NODE_1_IP --data-path-port=7789
И на узлах 2 и 3 я выполнил следующие команды соединения
docker swarm join --token XXX -advertise-addr NODE_2/3_IP NODE_1_IP:2377
Токен взят из значения, которое мне дал Узел 1. Я решил предыдущую проблему, указав порт-путь к данным. Я думаю, это потому, что VPS - это VMWare, и он конфликтует со стандартным портом данных.
Мой облачный провайдер предоставляет мне пользовательский интерфейс для применения правил брандмауэра к отдельным VPS. Я использовал группу брандмауэра, чтобы применить следующие правила ко всем 3 серверам:
TCP ACCEPT to dest ports 80, 443, (and my SSH port)
ICMP ACCEPT any
TCP ACCEPT 2376
TCP, UDP ACCEPT 7789
UDP ACCEPT 7789
TCP ACCEPT 2377
ESP ACCEPT
Чтобы проверить это, я выполнил следующие команды на узле 1
docker network create --driver=overlay --attachable testnet
docker network create --opt encrypted --driver=overlay --attachable testnet_encrypted
docker service create --network=testnet --name web --publish 80 --replicas=5 nginx:latest
После запуска службы в кластере я делаю следующее:
docker run --rm --name alpine --net=testnet -ti alpine:latest sh
apk add --no-cache curl
Затем я завиваю завиток 5 раз:
curl web
Все 5 раз получаю ответ. Если я продолжу, я продолжу получать ответы. Я думаю, это означает, что все контейнеры получают трафик.
Затем я переключаю сервер на зашифрованную сеть и повторяю тот же тест:
docker service rm web
docker service create --network=testnet_encrypted --name web --publish 80 --replicas=5 nginx:latest
docker run --rm --name alpine --net=testnet_encrypted -ti alpine:latest sh
apk add --no-cache curl
Снова запускаю curl 5 раз:
curl web
Иногда он будет работать, а иногда просто будет сидеть и зависать, пока я не нажму ctrl-c.
Если я запускаю его кратно 5 раз, образец рабочего и сломанного повторов повторяется. Я думаю, это потому, что некоторые контейнеры работают на NODE_1, и они работают, но связь с узлами 2 и 3 не работает.
Правило ESP ACCEPT было добавлено в мой набор правил брандмауэра облачного провайдера после некоторого исследования проблемы.
Я попытался перезагрузить кластер, но безуспешно.
Теперь я застрял. Есть ли какие-либо рекомендации, как я могу продолжить отладку. Спасибо Роберт
Для отладки я изменил тест, чтобы веб-служба работала только на одном экземпляре на NODE_3. Затем я загрузил две консоли для узла 3 и выполнил следующие команды:
sudo tcpdump src NODE_1_IP and dst NODE_3_IP and port 7789
sudo tcpdump src NODE_3_IP and dst NODE_1_IP and port 7789
Одна консоль будет показывать мне трафик в NODE_3, а другая - из NODE_3.
Затем я снова провел незашифрованный тест. Я вижу около 7 строк на входящей консоли и 5 строк на исходящей консоли. Итак, есть трафик, идущий в NODE_3, и трафик, выходящий из NODE_3, и тест работает
Затем я запустил зашифрованный тест. На этот раз я вижу одну строку на входящей консоли и ничего на исходящей консоли. Итак, один пакет попадает в NODE_3. Я не уверен, что он расшифровывается и отправляется обратно в контейнер.
Одна область конфигурации, о которой я не упомянул, - это то, что у меня есть следующая настройка /etc/docker/daemon.json:
{
"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"],
"tlscacert": "/var/docker/ca.pem",
"tlscert": "/var/docker/server-cert.pem",
"tlskey": "/var/docker/server-key.pem",
"tlsverify": true
}
Это позволяет мне использовать сертификаты клиента ssl для удаленного подключения. Этот файл был настроен на всех узлах до того, как я создал рой.
Поскольку расшифровка пакетов выглядит как возможная причина, я изменил свой daemon.json на следующее:
{
"hosts": []
}
Затем я перезагрузил каждую машину. Результаты тестов такие же - все равно не работает.
Затем я выполнил команду: docker swarm ca --rotate и повторно запустил тесты. Результат тот же.
Я не удалял и не переустанавливал кластер с новой конфигурацией. (Я мог бы это сделать, если бы кто-то подумал, что это поможет, но у меня есть много секретов и настроек докеров, которые я потеряю в процессе.)
Теперь я полностью удалил и повторно инициализировал кластер. Это не сработало.
В некоторых источниках говорится, что следующая команда:
sudo tcpdump -p esp
При запуске на узлах должен показывать трафик. Я запустил это на всех узлах кластера и повторил все тесты, и нигде нет вывода.
ufw он неактивен на всех узлах:
robert@metcaac6:/var/log$ sudo ufw status
[sudo] password for robert:
Status: inactive
но когда я запускаю iptables -L, я получаю одни и те же правила на каждом узле:
Роберт @ metcaac6: / var / log $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere policy match dir in pol ipsec udp dpt:7789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100300"
DROP udp -- anywhere anywhere udp dpt:7789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100300"
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
Chain DOCKER-INGRESS (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:30001
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:30001
ACCEPT tcp -- anywhere anywhere tcp dpt:30000
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:30000
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Я проверил dmesg и / var / log / syslog на предмет возможных проблем, но не нашел их.
У меня все еще нет идей, где мне искать проблему.