Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

Проблемы с разрешением DNS в кластере Microk8s

На чтение 9 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. 1. Основные симптомы и диагностика
  4. 2. Конфигурация CoreDNS
  5. 3. Проверка конфигурации сетевого окружения
  6. 4. Альтернативные тесты с использованием команды dig
  7. 5. Рекомендации по дальнейшим действиям
  8. 6. Заключение

Вопрос или проблема

Мой кластер microk8s работает на виртуальной машине centos8, и у меня есть некоторые проблемы с разрешением DNS для моих подов. DNS-серверы находятся по адресу x.x.x.101 и x.x.x.100, оба из которых доступны по ping из подов, и я также могу пинговать 8.8.8.8

nslookup из пода выглядит так:

root@debug-7857894f66-mnklp:/# nslookup kubernetes.default
Сервер:         10.152.183.10
Адрес:        10.152.183.10#53

Имя:   kubernetes.default.svc.cluster.local
Адрес: 10.152.183.1

Конфигурация coredns выглядит так:

apiVersion: v1
data:
  Corefile: ".:53 {\n    errors\n    health {\n      lameduck 5s\n    }\n    ready\n
    \   log . {\n      class error\n    }\n    kubernetes cluster.local in-addr.arpa
    ip6.arpa {\n      pods insecure\n      fallthrough in-addr.arpa ip6.arpa\n    }\n
    \   prometheus :9153\n    forward .  x.x.x.101 x.x.x.100 \n    cache 30\n
    \   loop\n    reload\n    loadbalance\n}\n"
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"Corefile":".:53 {\n    errors\n    health {\n      lameduck 5s\n    }\n    ready\n    log . {\n      class error\n    }\n    kubernetes cluster.local in-addr.arpa ip6.arpa {\n      pods insecure\n      fallthrough in-addr.arpa ip6.arpa\n    }\n    prometheus :9153\n    forward .  x.x.x.101 x.x.x.100 \n    cache 30\n    loop\n    reload\n    loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"EnsureExists","k8s-app":"kube-dns"},"name":"coredns","namespace":"kube-system"}}
  creationTimestamp: "2021-08-31T08:57:27Z"
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    k8s-app: kube-dns
  name: coredns
  namespace: kube-system
  resourceVersion: "2420090"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 471b258a-253d-4b51-aaf7-7e934ab300d1

файл /etc/resolv.conf в моих подах выглядит так:

search default.svc.cluster.local svc.cluster.local cluster.local xxx.xxxxx
nameserver 10.152.183.10
options ndots:5

когда я смотрю логи моего kube-dns с помощью $ microk8s kubectl logs --namespace=kube-system -l k8s-app=kube-dns, я получаю следующий ответ:

[INFO] 10.1.107.105:47549 - 5288 "AAAA IN www.google.com. udp 36 false 512" NOERROR - 0 0.000256103s
[ERROR] plugin/errors: 2 www.google.com. AAAA: read udp 10.1.107.127:51486->x.x.x.101:53: read: no route to host

Служба DNS работает:

$ microk8s kubectl get svc --namespace=kube-system
ИМЯ                        ТИП        CLUSTER-IP       EXTERNAL-IP   ПОРТ(Ы)                  ВРЕМЯ
[...]
kube-dns                    ClusterIP   10.152.183.10    <none>        53/UDP,53/TCP,9153/TCP   21d

Точки подключения DNS открыты:

$ microk8s kubectl get endpoints kube-dns --namespace=kube-system
ИМЯ       ТЧК ПОДКЛЮЧЕНИЯ                                           ВРЕМЯ
kube-dns   10.1.107.127:53,10.1.107.127:53,10.1.107.127:9153   21d

Виртуальная машина, на которой работает кластер, использует тот же DNS-сервер без проблем. Это что-то, о чем мне нужно беспокоить наших администраторов, или я пропустил что-то, что неправильно настроено?

РЕДАКТИРОВАНИЕ:

Хорошо, я попробовал немного больше, и есть какое-то странное поведение, которое, как мне кажется, связано с неправильным созданием конфигурационного файла coredns. Я полностью сбросил кластер и попробовал снова, все равно та же ошибка, когда я использую 8.8.8.8 или 8.8.4.4 в качестве DNS-серверов. Но когда я выполняю следующую команду: $ microk8s enable dns:x.x.x.101,x.x.x.100, она наконец начинает работать. Затем я попытался настроить это с помощью $ microk8s kubectl -n kube-system edit configmap/coredns, и когда я добавляю оба DNS в конфигурацию, она перестает работать, и я снова получаю ошибку: [ERROR] plugin/errors: 2 www.google.com. AAAA: read udp 10.1.107.127:51486->x.x.x.101:53: read: no route to host, так что что не так с моей конфигурацией, что автоматически правильно настраивается с $ microk8s enable dns:x.x.x.101,x.x.x.100?

2-е редактирование

Я попытался использовать dig, и даже когда я указываю DNS-сервер, ничего не работает. Есть ли причина, по которой ping проходит, а DNS заблокирован системой? Это происходит только на кластере microk8s, на хостовой системе docker работает нормально…
вот выводы:
это из пода:

root@debug-865cb7fb4-wfhw4:/# dig www.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @x.x.x.101 www.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @x.x.x.101 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @8.8.8.8 www.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@debug-865cb7fb4-wfhw4:/# dig @x.x.x.100 www.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @x.x.x.100 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

и это из хостовой системы:

$ dig www.google.com

; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25735
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         113     IN      A       142.250.185.228

;; Query time: 0 msec
;; SERVER: x.x.x.101#53(x.x.x.101)
;; WHEN: Fri Oct 08 15:10:21 CEST 2021
;; MSG SIZE  rcvd: 59



$ dig @8.8.8.8 www.google.com

; &;<<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3924
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         300     IN      A       142.250.185.228

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Oct 08 15:10:49 CEST 2021
;; MSG SIZE  rcvd: 59

$ dig @x.x.x.101 www.google.com

; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> @x.x.x.101 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60305
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         70      IN      A       142.250.185.228

;; Query time: 0 msec
;; SERVER: x.x.x.101#53(x.x.x.101)
;; WHEN: Fri Oct 08 15:11:04 CEST 2021
;; MSG SIZE  rcvd: 59

Я не имею ни малейшего представления о том, что происходит ….

Я опубликовал ответ в Сообществе вики для лучшей видимости. Как упомянул Thagor в комментарии, проблема была решена и связана с внешним DNS:

Я перестроил кластер в инфраструктуре, которая полностью находится под моим контролем, где DNS работает.

Попробуйте отключить iptables и брандмауэр на хосте и посмотрите, сможете ли вы это сделать через конфигурацию coredns.

Больше информации о DNS вы можете найти в официальной документации.

Ответ или решение

Проблемы с разрешением DNS в кластере Microk8s на CentOS 8: детальное руководство по диагностике и устранению неполадок

Если вы столкнулись с проблемами разрешения DNS в вашем кластере Microk8s, работающем на виртуальной машине CentOS 8, необходимо пройтись по нескольким ключевым моментам, чтобы обнаружить и устранить источник неполадок.

1. Основные симптомы и диагностика

Вы указали, что имена серверов DNS x.x.x.101 и x.x.x.100 доступны для пинга внутри подов, а также что запросы к DNS-серверу Kubernetes возвращают корректные адреса:

nslookup kubernetes.default

Таким образом, можно подтвердить, что локальная служба DNS (CoreDNS) работает и возвращает нужные адреса.

Однако, согласно вашим логам CoreDNS, DNS-запросы к внешним адресам (например, www.google.com) завершаются ошибкой:

[ERROR] plugin/errors: 2 www.google.com. AAAA: read udp 10.1.107.127:51486->x.x.x.101:53: read: no route to host

Это указывает на проблему с маршрутизацией или доступом к внешним DNS-серверам.

2. Конфигурация CoreDNS

Ваша конфигурация CoreDNS выглядит следующим образом:

forward . x.x.x.101 x.x.x.100

Однако, когда вы редактируете конфигурацию вручную, ваша служба DNS перестает работать. Это может быть связано с синтаксической ошибкой или неправильным определением порядка приоритетов в конфигурации. Использование команды microk8s enable dns:x.x.x.101,x.x.x.100 автоматически настраивает правильный конфигурационный файл, что, скорее всего, исключает возможные ошибки.

3. Проверка конфигурации сетевого окружения

Следующий шаг – это убедиться, что ваш кластер Kubernetes имеет доступ к внешним DNS-серверам. Для этого:

  1. Проверьте настройки iptables или firewall. Они могут блокировать выходящий трафик:

    sudo iptables -L
sudo firewall-cmd --list-all

    Отключите их временно, чтобы проверить, не в этом ли проблема:

    sudo systemctl stop firewalld

  2. Проверьте настройки сетевого интерфейса вашей виртуальной машины. Убедитесь, что VM может отправлять пакеты к DNS-серверам:

    curl -I x.x.x.101
curl -I x.x.x.100

  3. Убедитесь, что сетевые маршруты верны:

    ip route show

4. Альтернативные тесты с использованием команды dig

Команда dig позволяет выполнить более детальную диагностику DNS-запросов:

dig @x.x.x.101 www.google.com

Если команда dig также завершилась неудачей, это подтверждает проблемы на уровне сети.

5. Рекомендации по дальнейшим действиям

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

  • Обратитесь к вашему сетевому администратору. Возможно, доступ к DNS-серверам ограничен на уровне сети.
  • Полная перезагрузка кластера. Изначальные настройки могли быть не сохранены.

6. Заключение

Ваш случай с проблемами DNS в кластере Microk8s может быть вызван множеством факторов, начиная от ошибок конфигурации до проблем с доступом к внешним DNS-серверам. Проведя диагностику и устранив возможные проблемы с сетью и конфигурацией CoreDNS, вы сможете обеспечить стабильную работу вашего кластера.

Следуйте документации Kubernetes для получения дополнительной информации о настройках DNS здесь, и удачи в ваших дальнейших настройках!

domain-name-system kubernetes microk8s
Оцените материал
Добавить комментарий

Капча загружается...

© 2025 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности