Fragebeschreibung:
Ich habe einen Harvester-HCI-Cluster (RKE2), bei dem Pods nicht die richtigen IP-Adressen für Internetdomänen auflösen.
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>ist in diesem Fall die öffentliche IP-Adresse des Netzwerks, in dem sich der Cluster befindet (und nicht eine der serverfault.comIP-Adressen).
Im selben Container nslookupwird jedoch die richtige IP-Adresse aufgelistet:
/ # 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:
Dies ist auf dem Hostknoten nicht reproduzierbar:
# 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
Der Cluster selbst ist eine Neuinstallation vonHarvester HCI v1.2.0ohne weitere Konfigurationsänderungen nach der Installation.
Ich suche nach weiteren Tipps zur Behebung dieses Problems und um herauszufinden, warum die falsche IP-Adresse aufgelöst wird.
Kontext:
/etc/resolve.confauf dem Host:
### /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.confauf Pod-Container:
search default.svc.cluster.local svc.cluster.local cluster.local harvester.<redacted domain>
nameserver 10.53.0.10
options ndots:5
/etc/nsswitch.confauf dem Host:
#
# /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.confauf Pod-Container:
# /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/hostsin beiden Fällen keine weiteren/verdächtigen Einträge enthalten.
Antwort1
Ich habe festgestellt, dass das Problem bei der ndotsOption in liegt resolve.conf:
options ndots:5
Diese Option bedeutet, dass der Hostname nur dann nicht an die Suchdomäne angehängt wird, wenn er 5 oder mehr Punkte enthält.
Ich vermute, dass diese Option erforderlich ist, da Kubernetes intern viele Hostnamen mit mehreren Punkten verwendet.
Allerdings serverfault.comhat beispielsweise nur ein Punkt, also wird I an die lokale Domäne angehängt, harvester.<redacted domain>sodass es wird serverfault.com.harvester.<redacted domain>. Wir hatten zufällig einen Platzhaltereintrag ( *) in dieser Domäne, der auf die öffentliche IP-Adresse des Netzwerks verwies. Das Ergebnis serverfault.com.harvester.<redacted domain>würde mit dem Platzhaltereintrag aufgelöst werden, was dieses Verhalten erklärt.
Um dies zu beheben, haben wir den DHCP-Eintrag für die lokale Domäne vorübergehend entfernt. Dies würde dazu führen, dass die searchKonfiguration result.confihn nicht mehr enthält und die Internetdomäne somit nicht mehr an die lokale Domäne angehängt wird.
Langfristig planen wir die Entfernung der Wildcard-Domäne.