Я покажу и объясню вам на примере nginx ingress controller. Я считаю, что ситуация с входным контроллером traefik такая же.
Итак, прежде всего - относительно kube-dns
и coredns
беспорядка, который вы описываете:
это реализовано по замыслу. вы можете сослаться на github coredns по-прежнему помечен как проблема 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
на traefic pod, но проблема есть. И что /etc/resolv.conf
у вас идет от вашего узла
Установка dnsPolicy: ClusterFirstWithHostNet вместо dnsPolicy: ClusterFirst должна решить эту проблему, если вход использует hostNetwork.
Из документации dns-pod-service :
«ClusterFirstWithHostNet»: для модулей, работающих с hostNetwork, вы
должен явно установить свою политику DNS «ClusterFirstWithHostNet».
После редактирования развертывания nginx-ingress-controller из
dnsPolicy: ClusterFirst
hostNetwork: true
до
dnsPolicy: ClusterFirstWithHostNet
hostNetwork: true
модуль был воссоздан с желаемым /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) Трафик на k8s без внешнего прослушивания без изменения развертывания
2) Вопрос о стеке traefik
3) Вход с Traefik статья:
dnsPolicy: ClusterFirstWithHostNet
Этот параметр важен. Это настроит использование модулей Traefik
внутренний DNS-сервер кластера Kubernetes (скорее всего KubeDNS или
возможно CoreDNS). Это означает, что файлы /etc/resolv.conf будут
настроен на использование DNS-сервера Kubernetes. В противном случае DNS-сервер
узла Kubernetes будет использоваться (в основном /etc/resolv.conf
рабочий узел, но он не может разрешить cluster.local DNS, например).
Надеюсь, это поможет