домен поиска kubernetes DNS добавлен в некоторые запросы

У меня запущен кластер Kubernetes с главным и двумя рабочими узлами.

root@kube-master:~# kubectl get nodes
NAME           STATUS   ROLES    AGE     VERSION
kube-master    Ready    master   4d19h   v1.14.3
kube-node-01   Ready    <none>   4d18h   v1.14.3
kube-node-02   Ready    <none>   6h3m    v1.14.3

Теперь мой входной контроллер traefik не может разрешать запросы DNS.

/ # nslookup acme-v02.api.letsencrypt.org
nslookup: can't resolve '(null)': Name does not resolve

Name:      acme-v02.api.letsencrypt.org
Address 1: <my.public.ip> mail.xxx.xxx

Теперь с tcpdump в моем поле opnsense я получаю запросы с добавлением моего внутреннего поискового домена, разрешающего мой общедоступный IP-адрес, что неверно.

Но по какой-то причине ... запуск тестового модуля busybox работает ...

/ # nslookup acme-v02.api.letsencrypt.org
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      acme-v02.api.letsencrypt.org
Address 1: 2a02:26f0:ef:197::3a8e g2a02-26f0-00ef-0197-0000-0000-0000-3a8e.deploy.static.akamaitechnologies.com
Address 2: 2a02:26f0:ef:181::3a8e g2a02-26f0-00ef-0181-0000-0000-0000-3a8e.deploy.static.akamaitechnologies.com
Address 3: 104.74.120.43 a104-74-120-43.deploy.static.akamaitechnologies.com

Оба файла /etc/resolve.conf одинаковы, за исключением namespace

Так как kubernetes 1.11 coredns является системой разрешения DNS по умолчанию. На этой странице выполняется отладка система DNS с ядрами говорит, что я должен использовать

root@kube-master:~# kubectl get pods --namespace=kube-system -l k8s-app=coredns
No resources found.

Но это ничего не возвращает! Использование kube-dns возвращает coredns капсул!

root@kube-master:~# kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME                      READY   STATUS    RESTARTS   AGE
coredns-fb8b8dccf-jmhdm   1/1     Running   5          4d19h
coredns-fb8b8dccf-tfw7v   1/1     Running   5          4d19h

Что тут происходит?! Документация неправильная или что-то внутри моего кластера?


kubernetes coredns
person Pascal    schedule 24.06.2019    source источник

Ответы (2)


arrow_upward
2
arrow_downward

По умолчанию значение ndots: n равно 5. Это означает, что если имя содержит менее 5 точек внутри, системный вызов попытается разрешить его последовательно, сначала пройдя все локальные поисковые домены, и - в случае, если ни один из них не увенчается успехом - разрешит его как абсолютное имя только напоследок.

person Hang Du    schedule 30.07.2019
comment
Это также проблема в сочетании с поисковыми доменами, содержащими записи с подстановочными знаками - все внешние запросы получат ответ с подстановочными знаками. - person Gert van den Berg; 11.12.2020

arrow_upward
1
arrow_downward

Я покажу и объясню вам на примере контроллера входящего трафика nginx. Я считаю, что ситуация с контроллером входящего трафика traefik такая же.

Итак, прежде всего - что касается kube-dns и coredns беспорядка, который вы описываете: это реализовано в дизайне. вы можете обратиться к coredns github все еще помечены как проблема kube-dns, чтобы узнать больше.

В моем кластере у меня также есть coredns служба, которая называется kube-dns и относится к coredns модулям с меткой k8s-app=kube-dns.

kubectl describe service kube-dns -n kube-system
Name:              kube-dns
Namespace:         kube-system
Labels:            k8s-app=kube-dns
                   kubernetes.io/cluster-service=true
                   kubernetes.io/name=KubeDNS
Annotations:       prometheus.io/port: 9153
                   prometheus.io/scrape: true
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP:                10.96.0.10
Port:              dns  53/UDP
TargetPort:        53/UDP
Endpoints:         10.32.0.2:53,10.32.0.9:53
Port:              dns-tcp  53/TCP
TargetPort:        53/TCP
Endpoints:         10.32.0.2:53,10.32.0.9:53
Port:              metrics  9153/TCP
TargetPort:        9153/TCP
Endpoints:         10.32.0.2:9153,10.32.0.9:9153
Session Affinity:  None
Events:            <none>

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
NAME                      READY   STATUS    RESTARTS   AGE     IP          NODE                     NOMINATED NODE   READINESS GATES
coredns-fb8b8dccf-42285   1/1     Running   0          3h26m   10.32.0.9   kubernetessandbox-1-vm   <none>           <none>
coredns-fb8b8dccf-87j5v   1/1     Running   0          3h26m   10.32.0.2   kubernetessandbox-1-vm   <none>           <none>

Когда я запускаю новый модуль busybox - у него есть /etc/resolv.conf, который указывает на службу kube-dns (10.96.0.10) и имеет правильный поиск:

cat /etc/resolv.conf
search kube-system.svc.cluster.local svc.cluster.local cluster.local c.myproj.internal. google.internal.
nameserver 10.96.0.10
options ndots:5

Но в то же время мой модуль контроллера входящего трафика nginx имеет nameserver 169.254.169.254 и также не может выполнять nslookup даже на kubernetes.default

cat /etc/resolv.conf
search c.myproj.internal. google.internal.
nameserver 169.254.169.254

Не уверен, что у вас есть в /etc/resolv.conf на транспортном модуле, но проблема есть. И это /etc/resolv.conf, которое у вас есть, идет от вашего узла

Установка dnsPolicy: ClusterFirstWithHostNet вместо dnsPolicy: ClusterFirst должна решить эту проблему, если для входа используется hostNetwork.

Из документации dns-pod-service:

«ClusterFirstWithHostNet»: для модулей, работающих с hostNetwork, вы должны явно установить его политику DNS «ClusterFirstWithHostNet».

После редактирования развертывания nginx-ingress-controller из

  dnsPolicy: ClusterFirst
  hostNetwork: true

to 

  dnsPolicy: ClusterFirstWithHostNet
  hostNetwork: true

pod был воссоздан с желаемым /etc/resolv.conf:

cat /etc/resolv.conf
search kube-system.svc.cluster.local svc.cluster.local cluster.local c.myproj.internal. google.internal.
nameserver 10.96.0.10
options ndots:5

nslookup kubernetes.default
Server:         10.96.0.10
Address:        10.96.0.10#53

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

Несколько URL-адресов для вас с проблемами и объяснениями, связанными с hostNetwork / dnsPolicy. Это важная часть правильной настройки Traefik:

1) Traefik на k8 не слушает извне без изменения развертывания

2) Вопрос о стеке трафика

3) Статья Ingress с Traefik:

dnsPolicy: ClusterFirstWithHostNet

Эта настройка важна. Он настроит модули Traefik для использования внутреннего DNS-сервера кластера Kubernetes (скорее всего, KubeDNS или, возможно, CoreDNS). Это означает, что модули /etc/resolv.conf будут настроены для использования DNS-сервера Kubernetes. В противном случае будет использоваться DNS-сервер узла Kubernetes (в основном /etc/resolv.conf рабочего узла, но, например, он не может разрешить cluster.local DNS).

Надеюсь, это поможет

person Vit    schedule 27.06.2019