Проблема поиска DNS в Kubernetes и «недопустимый» файл /etc/resolv.conf - PullRequest
Новая
       60

Проблема поиска DNS в Kubernetes и «недопустимый» файл /etc/resolv.conf

0 голосов
/ 05 ноября 2019

Я развернул кластер Kubernetes, состоящий из мастера и двух рабочих, использующих kubeadm и сетевой драйвер Flannel (поэтому я передал флаг --pod-network-cidr=10.244.0.0/16 kubeadm init).

Эти узлы взаимодействуютвместе с использованием VPN, чтобы:

  • IP-адрес главного узла был 10.0.0.170
  • IP-адрес работника 1 - 10.0.0.247
  • IP-адрес работника 2 - 10.0.0.35

Когда я создаю новый модуль и пытаюсь проверить связь с Google, у меня появляется следующая ошибка: 

/ # ping google.com
ping: bad address 'google.com'

Я следовал инструкциям отладки Kubernetes DNSразрешение страница документации: 

$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.96.0.10
Address 1: 10.96.0.10

nslookup: can't resolve 'kubernetes.default'
command terminated with exit code 1

Сначала проверьте локальную конфигурацию DNS 

$ kubectl exec busybox cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local invalid
options ndots:5

Проверьте, работает ли модуль DNS 

$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME                       READY   STATUS    RESTARTS   AGE
coredns-5c98db65d4-cqzb7   1/1     Running   0          7d18h
coredns-5c98db65d4-xc5d7   1/1     Running   0          7d18h

Проверьте на ошибкив модуле DNS 

$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
.:53
2019-10-28T13:40:41.834Z [INFO] CoreDNS-1.3.1
2019-10-28T13:40:41.834Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-10-28T13:40:41.834Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843
.:53
2019-10-28T13:40:42.870Z [INFO] CoreDNS-1.3.1
2019-10-28T13:40:42.870Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-10-28T13:40:42.870Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843

Работает ли служба DNS? 

$ kubectl get svc --namespace=kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   7d18h

Открыты ли конечные точки DNS? 

$ kubectl get ep kube-dns --namespace=kube-system
NAME       ENDPOINTS                                               AGE
kube-dns   10.244.0.3:53,10.244.0.4:53,10.244.0.3:53 + 3 more...   7d18h

Получаются / обрабатываются запросы DNS?

Я сделал обновление для ConfigMap coredns, снова запустил команду nslookup kubernetes.default ивот результат: 

$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
.:53
2019-10-28T13:40:41.834Z [INFO] CoreDNS-1.3.1
2019-10-28T13:40:41.834Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-10-28T13:40:41.834Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843
[INFO] Reloading
2019-11-05T08:12:12.511Z [INFO] plugin/reload: Running configuration MD5 = 906291470f7b1db8bef629bdd0056cad
[INFO] Reloading complete
2019-11-05T08:12:12.608Z [INFO] 127.0.0.1:55754 - 7434 "HINFO IN 4808438627636259158.5471394156194192600. udp 57 false 512" NXDOMAIN qr,rd,ra 132 0.095189791s
.:53
2019-10-28T13:40:42.870Z [INFO] CoreDNS-1.3.1
2019-10-28T13:40:42.870Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-10-28T13:40:42.870Z [INFO] plugin/reload: Running configuration MD5 = 5d5369fbc12f985709b924e721217843
[INFO] Reloading
2019-11-05T08:12:47.988Z [INFO] plugin/reload: Running configuration MD5 = 906291470f7b1db8bef629bdd0056cad
[INFO] Reloading complete
2019-11-05T08:12:48.004Z [INFO] 127.0.0.1:51911 - 60104 "HINFO IN 4077052818408395245.3902243105088660270. udp 57 false 512" NXDOMAIN qr,rd,ra 132 0.016522153s

Похоже, что модули DNS получают запросы.

Но у меня уже была эта ошибка!

Эта ошибка произошла со мнойКогда я впервые развернул кластер.

В то время я заметил, что kubectl get nodes -o wide отображал открытый IP-адрес рабочего узла как "INTERNAL-IP" вместо частного.

Lookingдалее я обнаружил, что на рабочих узлах в kubelet отсутствует флаг --node-ip, поэтому я добавил его и перезапустил Kubelet, и проблема исчезла. Затем я пришел к выводу, что причина в отсутствующем флаге, но, похоже, это не так, поскольку команда kubectl get nodes -o wide отображает внутренние IP-адреса как «INTERNAL-IP» для рабочих.

А теперь

IP-адрес DNS-сервера 10.96.0.10 выглядит неправильно, и я не могу пропинговать его из модуля. У модулей DNS есть IP-адреса 10.244.0.3 и 10.244.0.4, которые я тоже не могу пропинговать.

Я только что попытался удалить модули coredns, чтобы они снова были запланированы, и теперь их IP-адреса изменилисьЯ могу пропинговать их из модуля, и kubectl exec -ti busybox -- nslookup kubernetes.default работает: 

$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

Но файл resolv.conf все еще имеет "недействительный" внутри: 

$ kubectl exec busybox cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local invalid
options ndots:5
  • Может кто-нибудь объяснить мне, что случилось, пожалуйста?
  • И как я могу решить этот "недействительный" из файла resolv.conf?

1 Ответ

2 голосов
/ 08 ноября 2019

Как настроено в CoreDNS ConfigMap восходящие серверы имен по умолчанию наследуются от узла, то есть всего, что находится за пределами кластерного домена (.cluster.local)

Таким образом, "недопустимая" запись скопирована изФайл /etc/resolv.conf узла при создании Pod.

Если вы вручную измените /etc/resolv.conf на своем узле, каждый Pod с dnsPolicy: ClusterFirst будет наследовать /etc/resolv.conf с этой модификацией.

Итак,после добавления флага --node-ip в kubelet и перезапуска модулей CoreDNS вы должны повторно развернуть свой модуль busybox, чтобы он мог наследовать /etc/resolv.conf от узла.

...