Предположительно, Ansible терпит неудачу при «сборе хостов» потому что SSH медленно подключается. Установка ʻUseDNS no` решает проблему

У меня возникла проблема, связанная с DNS, и я был бы признателен за помощь в разрешении .

Я использую Ansible для подготовки кластера Kubernetes на моем сервере Proxmox. Проект работает двумя способами, позволяя пользователю изменять site.yml для развертывания с использованием контейнеров Linux (LXC) или виртуальных машин из образа CentOS7 qcow2 .

При развертывании с LXC проект не испытывает проблем и правильно загружает кластер Kubernetes. Однако при использовании образа qcow2 Я столкнулся с проблемой, связанной с DNS. Это происходит, когда происходит переключение между playbook, который подготавливает мои виртуальные машины, и той, которая подключается к ним в первый раз для их подготовки.

Что происходит, так это то, что этап Сбор фактов в конечном итоге истекает, и Ansible выдает следующую ошибку:

TASK [Gathering Facts] *******************************************************************************************************************************************************************************************************************************************************
fatal: [pluto.sol.milkyway]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host pluto.sol.milkyway port 22: Operation timed out\r\n", "unreachable": true}
fatal: [ceres.sol.milkyway]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host ceres.sol.milkyway port 22: Operation timed out\r\n", "unreachable": true}
fatal: [eris.sol.milkyway]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host eris.sol.milkyway port 22: Operation timed out\r\n", "unreachable": true}
fatal: [haumea.sol.milkyway]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host haumea.sol.milkyway port 22: Operation timed out\r\n", "unreachable": true}

Если после этого я попытаюсь вручную подключиться к серверам по SSH, я могу убедиться, что Подключение по SSH занимает очень много времени. Я хотел бы напомнить вам, что этого НЕ происходит с экземплярами LXC, которые используют одни и те же точные имена хостов, IP-адреса и серверы имен.

Проблема может быть решена путем установки директивы UseDNS no в моем файле sshd_config на каждом из серверов. И снова запустить playbook после перезапуска службы sshd.service .

Итак, естественно, это похоже на проблему с DNS. Однако, поскольку с LXC этого не происходит, я настроен скептически. Итак, вот еще несколько данных о моей конфигурации DNS.

1) DNS-сервер, который все они используют, - это BIND и установлен на сервере с именем IO.Sol.Milkyway по адресу 192.168.1.10 . В моей домашней лаборатории нет виртуальных сетей, подсетей или чего-либо еще, а шлюз правильно настроен на мой маршрутизатор, 192.168.1.1 , поэтому нет проблем с маршрутизацией на этот сервер.

2) Вот соответствующие части зон DNS на моем сервере BIND.

• Зона прямого просмотра
• Зона обратного просмотра

3) Вот некоторые nslookup , выполненные с сервера Proxmox и добавленные с командой time для демонстрации что мой сервер BIND правильно отвечает в течение <= 0,01 секунды.

$> time nslookup pluto.sol.milkyway
Server:     192.168.1.100
Address:    192.168.1.100#53

Name:   pluto.sol.milkyway
Address: 192.168.1.170

nslookup pluto.sol.milkyway  0.00s user 0.02s system 39% cpu 0.042 total

-и-

$> time nslookup 192.168.1.170
Server:     192.168.1.100
Address:    192.168.1.100#53

170.1.168.192.in-addr.arpa  name = pluto.sol.milkyway.

nslookup 192.168.1.170  0.01s user 0.01s system 96% cpu 0.013 total

4) И, наконец, вы можете видеть, что мои серверы имен правильно настроены на виртуальных машинах через cloud-init строки 104, 115, 126 и 137 здесь . Которые ссылаются на переменные, определенные здесь .

----- РЕДАКТИРОВАТЬ НИЖЕ -----

5) Я могу успешно выполнить прямой и обратный поиск nslookup из следующего. Каждый ответ занимает <1,5 секунды:

• Моя личная рабочая станция (выполняет Ansible)
• Мой сервер Proxmox (выполняет команды Ansible и ВМ)
• 4 виртуальных машины

Вот пример того, что могло бы быть главным сервером Kubernetes.