web-dev-qa-db-ja.com

おそらくSSHの接続が遅いため、Ansibleは「ホストの収集」で失敗します。 「UseDNSno」を設定すると問題が解決します

DNS関連の問題と思われる問題が発生しているので、解決していただければ幸いです。

Ansibleを使用してProxmoxサーバーにKubernetesクラスターをプロビジョニングしています。プロジェクトは2つの方法で機能します。つまり、ユーザーがsite.ymlを変更して、 Linux Containers（LXC） またはCentOS7の仮想マシン qcow2 image を使用してデプロイできるようにします。

LXCを使用してデプロイする場合、プロジェクトで問題は発生せず、Kubernetesクラスターを正しくブートストラップします。ただし、qcow2イメージを使用すると、DNS関連の問題と思われる問題が発生します。これは、仮想マシンをプロビジョニングするプレイブックと、仮想マシンを準備するために初めて仮想マシンに接続するプレイブックの間で切り替えが発生したときに発生します。

何が起こるかというと、Gathering Factsステージが最終的にタイムアウトになり、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の接続に非常に長い時間がかかっていることを確認できます。この時点で、まったく同じホスト名、IPアドレス、ネームサーバーを使用するLXCインスタンスではこれは発生しないことをお知らせします。

この問題は、各サーバーのUseDNS noファイルにsshd_configディレクティブを設定することで解決できます。そして、sshd.serviceを再起動した後、プレイブックを再度実行します。

したがって、当然、これはDNSの問題のように見えます。ただし、LXCでは発生しないため、私は懐疑的です。それで、ここに私のDNS構成に関するいくつかのデータポイントがあります。

1）すべてが使用しているDNSサーバーはBINDであり、IO.Sol.Milkywayという名前のサーバーの192.168.1.10にインストールされています。ホームラボにはVNetやサブネットなどがなく、ゲートウェイがルーター192.168.1.1に正しく設定されているため、このサーバーへのルーティングの問題はありません。

2）これが私のBINDサーバーのDNSゾーンの関連部分です。

3）これは、Proxmoxサーバーから実行されたnslookupsであり、私のBINDを示すためにtimeコマンドが追加されています。サーバーは<=。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、＆を介してVM上で正しく構成されていることがわかります。 137 ここ 。定義された変数を参照するもの ここ 。

-----以下の編集-----

5）以下から順方向および逆方向のnslookupを正常に実行できます。各応答には1.5秒未満かかります。

  • 私のパーソナルワークステーション（Ansibleを実行）
  • 私のProxmoxサーバー（AnsibleコマンドとVMを実行します）
  • 4つの仮想マシン

ここに例があります Kubernetesマスターサーバーとなるものから。

domain-name-systemsshansibleproxmoxqcow2
3
TJ Zimmerman

私は問題を見つけました。結果のVMには、qemuによって自動的に導入された追加のネームサーバーが含まれているようです。これは、VMが作成され、ネットワークデバイスが指定されていない場合に発生します。qmのProxmoxドキュメントから：

net [n]：[model =] [、bridge =] [、firewall = <1 | 0>] [、link_down = <1 | 0>] [、macaddr =] [、queues =] [、rate =] [ 、tag =] [、trunks =] [、=]
ネットワークデバイスを指定します。

ブリッジ=
ネットワークデバイスを接続するブリッジ。 ProxmoxVE標準ブリッジはvmbr0と呼ばれます。

ブリッジを指定しない場合は、DHCPおよびDNSサービスを提供するkvmユーザー（NATed）ネットワークデバイスを作成します。次のアドレスが使用されます。

10.0.2.2ゲートウェイ
10.0.2.3DNSサーバー
10.0.2.4 SMBサーバー
DHCPサーバーは10.0.2.15からゲストにアドレスを割り当てます。

私の手順は次のとおりです。

1） Proxmox_KVM AnsibleModuleを介してProxmoxAPIを使用してVM）を作成します。
2）このVMから4つのKubernetesVMのクローンを作成します。
）各KubernetesVMを順番に設定します。

ステップ1）の間に、実際にブリッジを宣言しました。ただし、ステップ2）では、単純なqm cloneであるため、実行しませんでした。ドキュメントによると、これは渡されるnet[n]フラグをサポートしていません。この時点で、ランダムネームサーバーが導入されました。次に、ステップ3）が発生し、cloud-initを介してネームサーバーを設定すると、それが/etc/resolv.confファイルに追加されました。 2番目のネームサーバーとして。

現在、Playbookを作り直して、ステップ1）との間で次のタスクを実行して、これを回避しようとしています。ステップ2）：

- name: Setting the name server for the template to ensure that QEMU doesn't automatically configure the clones to use 10.0.2.3. 
  Shell: >
      qm set {{ proxmox_template_id }}
      --ipconfig0 gw={{ k8s_master_gw }},ip={{ k8s_master_ip }}{{ k8s_master_sn }} 
      --nameserver {{ k8s_master_ns }} 
      --searchdomain {{ k8s_master_sd }}

これで問題が解決することを指を交差させます。

-----編集-----

それはしませんでした。また、qm cloneを実行するときに、ネットワークアダプタをプロビジョニングすることはできないようです。つまり、テンプレートからクローンを作成するのではなく、プレイブックを作り直して4つの個別のインスタンスをプロビジョニングする必要があります。

-----編集2 -----

また、安っぽいProxmox_kvmAnsibleモジュールがcloudinit関連のAPI関連のものをサポートしているようには見えません。つまり、シェルコマンドを使用してすべてを実行し、代わりにqmを利用する必要があります。 :(

-----編集3 -----

そのネームサーバーは実際にはデフォルトでベースイメージにあるように見えます。 WTF CENTOS？

root@hypervisor-1:/rpool/data# modprobe nbd max_part=8

root@hypervisor-1:/rpool/data# qemu-nbd --connect=/dev/nbd0 /tmp/CentOS7.qcow2c 

root@hypervisor-1:/rpool/data# fdisk -l /dev/nbd0
Disk /dev/nbd0: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000b2638
Device      Boot Start      End  Sectors Size Id Type
/dev/nbd0p1 *     2048 16777215 16775168   8G 83 Linux

root@hypervisor-1:/rpool/data# mount /dev/nbd0p1 /mnt/tmp

root@hypervisor-1:/rpool/data# cd /mnt/tmp

root@hypervisor-1:/mnt/tmp# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

root@hypervisor-1:/mnt/tmp# cat etc/resolv.conf 
# Generated by NetworkManager
nameserver 10.0.2.3
0
TJ Zimmerman