질문 설명:
포드가 인터넷 도메인에 대한 올바른 IP 주소를 확인하지 못하는 수확기 HCI 클러스터(RKE2)가 있습니다.
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.comIP 주소 중 하나가 아님).
그러나 동일한 컨테이너 내에서는 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에 추가하여 . 해당 도메인에 네트워크의 공용 IP 주소를 가리키는 와일드카드( ) 레코드가 있었습니다 . 결과적으로 해당 동작을 설명하는 와일드카드 레코드로 해결됩니다.harvester.<redacted domain>serverfault.com.harvester.<redacted domain>*serverfault.com.harvester.<redacted domain>
이 문제를 해결하기 위해 로컬 도메인에 대한 DHCP 레코드를 일시적으로 제거했습니다. 결과적으로 search구성에 result.conf더 이상 포함되지 않으므로 인터넷 도메인이 더 이상 로컬 도메인에 추가되지 않습니다.
장기적으로는 와일드카드 도메인을 제거할 계획입니다.