Блог

Главная - Вопросы по программированию - coredns не дает IP, а только имя

coredns не дает IP, а только имя

#kubernetes #nslookup #dig #coredns

#kubernetes #nslookup #копать #coredns

Вопрос:

Выполняя команду dig для службы в моем кластере kubernetes, coredns просто дает имя службы, но не IP. Кто-нибудь знает, почему это происходит?

Комментарии:

1. Нужны подробности или ясность, откуда вы запускаете command и что вы хотите ?. kubectl get svc -n kube-system может напрямую предоставлять детали или IP-адреса CoreDNS, если они каким-либо образом представлены.

2. kubectl exec -ti busybox nslookup myservicename …. это команда, которую я использую, а busybox — это модуль, в котором я работаю…. он не дает IP, а только имя

3. Полезно прикрепить вывод nslookup.

4. Пожалуйста, обновите свой вопрос с помощью ресурсов, запрошенных пользователями Харш Манвар и Кун Ли. Также, пожалуйста, добавьте результат: $ kubectl describe service svc-name-you-are-trying-to-query .

Ответ №1:

Это связано с тем, как работают утилита dig и DNS.

Обратите внимание, что при запуске:

 dig <your-service-name>

вы спрашиваете свои CoreDNS буквально об этой конкретной строке, а простое имя службы даже не является допустимым доменным именем. Просто взгляните на следующий пример:

 root@python-client:/# dig my-release-mysql

; <<>> DiG 9.11.5-P4-5.1 deb10u2-Debian <<>> my-release-mysql
;; global options:  cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27445
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;my-release-mysql.              IN      A

;; AUTHORITY SECTION:
.                       86399   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021012500 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 16:22:12 UTC 2021
;; MSG SIZE  rcvd: 120

Как вы можете видеть, он даже не содержит "ANSWER" section ( ANSWER: 0 ), и если вы внимательно посмотрите на "QUESTION" раздел:

 ;; QUESTION SECTION:
;my-release-mysql.              IN      A

вы заметите, что dig запрашивает у A CoreDNS запись для my-release-mysql. , которая, как я уже упоминал, даже не является допустимым доменным именем.

Обратите внимание, что CoreDNS не хранит никаких записей my-release-mysql. , поэтому, когда вы спрашиваете его о таком «домене», он ничего об этом не знает.

Если вместо этого вы запросите A запись для действительного полностью подтвержденного доменного имени (FQDN), вы получите ожидаемый ответ:

 root@python-client:/# dig my-release-mysql.default.svc.cluster.local

; <<>> DiG 9.11.5-P4-5.1 deb10u2-Debian <<>> my-release-mysql.default.svc.cluster.local
;; global options:  cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

;; Query time: 0 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 15:59:55 UTC 2021
;; MSG SIZE  rcvd: 76

Опять же, внимательно посмотрите на оба "QUESTION" "ANSWER" раздела и:

 ;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

Как вы можете видеть, когда мы запрашиваем у QUESTION SECTION A CoreDNS запись, для my-release-mysql.default.svc.cluster.local. которой является действительным полным доменным именем (в отличие my-release-mysql. от), для которого этот DNS-сервер хранит записи, мы получаем правильный ответ в нашем ANSWER SECTION .

Обратите внимание, что утилита dig не использует записи в вашем /etc/resolv.conf , которые могут выглядеть следующим образом:

 root@python-client:/# cat /etc/resolv.conf
nameserver 10.3.240.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

но вместо этого он запрашивает DNS-сервер о необработанной строке my-release-mysql. .

Такие инструменты, как host или nslookup , в отличие от dig, используют содержимое /etc/resolv.conf при выполнении поиска DNS. Поэтому вместо запроса CoreDNS о raw my-release-mysql default.svc.cluster.local добавляется суффикс, и такой запрос отправляется в CoreDNS, например:

 root@python-client:/# host my-release-mysql
my-release-mysql.default.svc.cluster.local has address 10.3.244.87

Обратите внимание, что, хотя мы указываем my-release-mysql в качестве аргумента для нашей host команды, она сопоставляет ее с первой записью в search разделе нашего /etc/resolv.conf файла, которая, оказывается default.svc.cluster.local , и запрашивает DNS-сервер не о my-release-mysql , а о полностью подтвержденном доменном имени my-release-mysql.default.svc.cluster.local , для которого он ведет записи.

То же самое с nslookup инструментом:

 root@python-client:/# nslookup my-release-mysql
Server:         10.3.240.10
Address:        10.3.240.10#53

Name:   my-release-mysql.default.svc.cluster.local
Address: 10.3.244.87
Метки: