nslookup seltsames Verhalten in 2 Pods auf demselben Knoten in Kubernetes

nslookup seltsames Verhalten in 2 Pods auf demselben Knoten in Kubernetes

Ich habe 2 Container, die im selben Namespace laufen.

  • In-Pod-DNS des Podsxflügellöst den Hostnamen nicht auf, löst aber den FQDN auf
  • AberIn-Pod-DNS des PodsDienstprogrammelösen Sie es richtig.
✗  kgpo  
NAME                         READY   STATUS    RESTARTS   AGE
deathstar-7848d6c4d5-g248j   1/1     Running   0          15m
deathstar-7848d6c4d5-qnsp8   1/1     Running   0          15m
tiefighter                   1/1     Running   0          15m
utils                        1/1     Running   0          11m
xwing                        1/1     Running   0          15m

➜ kgsvc         
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
deathstar    ClusterIP   172.20.41.112   <none>        80/TCP    15m
kubernetes   ClusterIP   172.20.0.1      <none>        443/TCP   46d

➜ k ice image               
PODNAME                     CONTAINER  PULL    IMAGE                          TAG
deathstar-7848d6c4d5-g248j  deathstar  Always  docker.io/cilium/starwars      -
deathstar-7848d6c4d5-qnsp8  deathstar  Always  docker.io/cilium/starwars      -
tiefighter                  spaceship  Always  docker.io/tgraf/netperf        -
utils                       utils      Always  saritasallc/network-multitool  -
xwing                       spaceship  Always  docker.io/tgraf/netperf        -

die folgenden Pods:

  • xflügel (docker.io/tgraf/netperf)Und
  • Dienstprogramme (saritasallc/network-multitool)

Pods zeigen die gleichen /etc/resolv.confWerte, verhalten sich bei nslookupAbfragen jedoch unterschiedlich.

➜ kex xwing -- cat /etc/resolv.conf  
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
nameserver 172.20.0.10
options ndots:5

➜ kex utils -- cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
nameserver 172.20.0.10
options ndots:5

UndUtils-Podkann Dienstnamen abfragenTodessternAberX-Wing-Kapselgeht nicht. Nur über den FQDN des Dienstes:

➜ kex utils -- nslookup deathstar  
Server:     172.20.0.10
Address:    172.20.0.10#53

Name:   deathstar.default.svc.cluster.local
Address: 172.20.41.112

➜ kex xwing -- nslookup deathstar
nslookup: can't resolve '(null)': Name does not resolve

➜ kex xwing -- nslookup deathstar.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'deathstar': Name does not resolve
command terminated with exit code 1

Name:      deathstar.default.svc.cluster.local
Address 1: 172.20.41.112 deathstar.default.svc.cluster.loca

Beide Pods laufen auf demselben EKS-Knoten.

Nachdem ich Protokolle in Coredns aktiviert habe, sehe ich Folgendes:

// kex utils -- nslookup deathstar (success)
[INFO] 10.120.133.213:45918 - 30670 "A IN deathstar.default.svc.cluster.local. udp 53 false 512" NOERROR qr,aa,rd 104 0.000298996s
[INFO] 10.120.133.213:45293 - 18650 "AAAA IN deathstar.default.svc.cluster.local. udp 53 false 512" NOERROR qr,aa,rd 146 0.000405998s

// kex xwing -- nslookup deathstar (failure)
[INFO] 10.120.134.84:32840 - 45185 "AAAA IN deathstar. udp 27 false 512" NXDOMAIN qr,rd,ra 102 0.003295317s
[INFO] 10.120.134.84:32840 - 44875 "A IN deathstar. udp 27 false 512" NXDOMAIN qr,rd,ra 102 0.003334905s

verwandte Informationen