
質問の説明:
ハーベスター HCI クラスター (RKE2) がありますが、ポッドがインターネット ドメインの正しい IP アドレスを解決しません。
kubectl run debug --image=busybox -i --tty --rm -- sh
/ # ping serverfault.com
PING serverfault.com (<redacted IP address>): 56 data bytes
64 bytes from <redacted IP address>: seq=0 ttl=63 time=0.362 ms
64 bytes from <redacted IP address>: seq=1 ttl=63 time=0.312 ms
64 bytes from <redacted IP address>: seq=2 ttl=63 time=0.319 ms
64 bytes from <redacted IP address>: seq=3 ttl=63 time=0.449 ms
64 bytes from <redacted IP address>: seq=4 ttl=63 time=0.317 ms
64 bytes from <redacted IP address>: seq=5 ttl=63 time=0.363 ms
64 bytes from <redacted IP address>: seq=6 ttl=63 time=0.296 ms
64 bytes from <redacted IP address>: seq=7 ttl=63 time=0.361 ms
^C
--- serverfault.com ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0.296/0.347/0.449 ms
<redacted IP address>
この場合、これはクラスターが存在するネットワークのパブリック IP アドレスになります ( serverfault.com
IP アドレスの 1 つではありません)。
ただし、同じコンテナ内ではnslookup
正しい IP アドレスがリストされます。
/ # nslookup serverfault.com
Server: 10.53.0.10
Address: 10.53.0.10:53
Non-authoritative answer:
Name: serverfault.com
Address: 104.18.23.101
Name: serverfault.com
Address: 104.18.22.101
Non-authoritative answer:
これはホストノードでは再現できません。
# ping serverfault.com
PING serverfault.com (104.18.23.101) 56(84) bytes of data.
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=1 ttl=57 time=1.27 ms
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=2 ttl=57 time=1.30 ms
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=3 ttl=57 time=1.33 ms
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=4 ttl=57 time=1.29 ms
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=5 ttl=57 time=1.23 ms
64 bytes from 104.18.23.101 (104.18.23.101): icmp_seq=6 ttl=57 time=1.28 ms
^C
--- serverfault.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 1.231/1.284/1.333/0.030 ms
クラスタ自体は、Harvester HCI v1.2.0
インストール後に追加の構成変更は必要ありません。
この問題のトラブルシューティング方法と、間違った IP アドレスが解決される理由を調べる方法についてのさらなるヒントを探しています。
コンテクスト:
/etc/resolve.conf
ホスト上:
### /etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf
### autogenerated by netconfig!
search harvester.<redacted domain> 1
nameserver 10.10.0.1
/etc/resolve.conf
ポッドコンテナ上:
search default.svc.cluster.local svc.cluster.local cluster.local harvester.<redacted domain>
nameserver 10.53.0.10
options ndots:5
/etc/nsswitch.conf
ホスト上:
#
# /etc/nsswitch.conf
#
passwd: compat
group: compat
shadow: compat
# Allow initgroups to default to the setting for group.
# initgroups: compat
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files dns
aliases: files usrfiles
ethers: files usrfiles
gshadow: files usrfiles
netgroup: files nis
protocols: files usrfiles
publickey: files
rpc: files usrfiles
services: files usrfiles
automount: files nis
bootparams: files
netmasks: files
/etc/nsswitch.conf
ポッドコンテナ上:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: files
group: files
shadow: files
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
/etc/hosts
どちらの場合も、追加/疑わしいエントリは含まれていません。
答え1
問題は次ndots
のオプションにあることがわかりましたresolve.conf
:
options ndots:5
このオプションは、ホスト名に 5 個以上のドットが含まれている場合にのみ、検索ドメインに追加されないことを意味します。
kubernetes は内部的に複数のドットを含むホスト名を多く使用するため、このオプションが必要であると思われます。
ただし、serverfault.com
たとえば にはドットが 1 つしかないため、ローカル ドメインに追加されて になりますharvester.<redacted domain>
。serverfault.com.harvester.<redacted domain>
たまたま、そのドメインに、ネットワークのパブリック IP アドレスを指すワイルドカード ( ) レコードがありました*
。結果として、serverfault.com.harvester.<redacted domain>
ワイルドカード レコードで解決され、その動作が説明されます。
この問題を解決するために、ローカル ドメインの DHCP レコードを一時的に削除しました。その結果、search
構成にresult.conf
それが含まれなくなり、インターネット ドメインがローカル ドメインに追加されなくなりました。
長期的にはワイルドカードドメインを削除する予定です。