Мне нужна помощь в отладке следующей настройки:
У меня есть 3 экземпляра VP Cloud от хостинговой компании. (Я думаю, что VPS — это VMWare, но я не могу найти никакой документации на сайте хостинговой компании.)
- Все работают под управлением Ubuntu 18.04.
- Я установил Docker на всех трех.
Все версии докера одинаковы:
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
На одном узле 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
Токен взят из значения, которое мне дал Node 1. Я решил предыдущую проблему, указав data-path-port. Я думаю, это потому, что VPS — это VMWare, и это конфликтует со стандартным dataport
Мой облачный провайдер предоставляет мне пользовательский интерфейс для применения правил брандмауэра к отдельным 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 было добавлено в набор правил брандмауэра моего облачного провайдера после некоторого исследования проблемы.
Я пробовал перезагрузить кластер, но безуспешно.
Теперь я застрял. Есть ли какие-нибудь рекомендации, как мне продолжить отладку? Спасибо, Роберт
Обновление 1
Для отладки я изменил тест так, чтобы веб-сервис работал только на одном экземпляре на 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 попадает один пакет. Я не уверен, расшифровывается ли он и отправляется ли обратно в контейнер.
Обновление 2
Одна область конфигурации, о которой я забыл упомянуть, заключается в том, что у меня есть следующая настройка /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 для удаленного подключения. Этот файл был настроен на всех узлах до того, как я создал swarm.
Поскольку расшифровка пакетов выглядит как возможная причина, я изменил свой daemon.json на следующее:
{
"hosts": []
}
Затем я перезагрузил каждую машину. Результаты теста те же — все еще не работает.
Затем я запустил команду: docker swarm ca --rotate и снова запустил тесты. Результат тот же.
Я не удалил и не переинициализировал кластер с новой конфигурацией. (Я мог бы это сделать, если кто-то считает, что это поможет, но у меня много секретов и конфигураций Docker, которые я потеряю в процессе.)
Обновление 3
Я сейчас полностью удалил и заново инициализировал кластер. Это не сработало.
Некоторые источники утверждают, что следующая команда:
sudo tcpdump -p esp
При запуске на узлах должен отображаться трафик. Я запустил это на всех узлах в кластере и повторил все тесты, но нигде нет вывода.
ufw неактивен на всех узлах:
robert@metcaac6:/var/log$ sudo ufw status
[sudo] password for robert:
Status: inactive
но когда я запускаю iptables -LI, получаю одни и те же правила на каждом узле:
robert@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 в поисках возможных проблем, но ничего не нашел.
Я до сих пор не имею ни малейшего представления, где мне следует искать проблему.