Descripción de la pregunta:
Tengo un clúster HCI recolector (RKE2), donde los pods no resuelven las direcciones IP correctas para los dominios de Internet.
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>en este caso resulta ser la dirección IP pública de la red en la que reside el clúster (y no una de serverfault.comlas direcciones IP).
Sin embargo, dentro del mismo contenedor, nslookupaparece la dirección IP correcta:
/ # 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:
Esto no es reproducible en el nodo anfitrión:
# 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
El clúster en sí es una nueva instalación deHarvester HCI v1.2.0sin cambios de configuración adicionales posteriores a la instalación.
Estoy buscando más consejos sobre cómo solucionar este problema y descubrir por qué se resuelve la dirección IP incorrecta.
Contexto:
/etc/resolve.confen el anfitrión:
### /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.confen contenedor de cápsulas:
search default.svc.cluster.local svc.cluster.local cluster.local harvester.<redacted domain>
nameserver 10.53.0.10
options ndots:5
/etc/nsswitch.confen el anfitrión:
#
# /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.confen contenedor de cápsulas:
# /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/hostsen ambos casos no contienen entradas adicionales/sospechosas.
Respuesta1
Encontré que el problema estaba en la ndotsopción en resolve.conf:
options ndots:5
Esta opción significa que sólo si el nombre de host contiene 5 o más puntos no se agregará al dominio de búsqueda.
Sospecho que esta opción es necesaria porque Kubernetes utiliza internamente muchos nombres de host con varios puntos.
Sin embargo, serverfault.compor ejemplo, solo tiene un punto, por lo que lo agrego al dominio local y harvester.<redacted domain>lo convierte en serverfault.com.harvester.<redacted domain>. Resulta que teníamos un *registro comodín () en ese dominio que apuntaba a la dirección IP pública de la red. Como resultado serverfault.com.harvester.<redacted domain>se resolvería con el registro comodín, explicando ese comportamiento.
Para solucionar este problema, hemos eliminado temporalmente el registro DHCP del dominio local. Como resultado, la searchconfiguración result.confya no lo incluiría y, por lo tanto, el dominio de Internet ya no se agregaría al dominio local.
En el futuro planeamos eliminar el dominio comodín.