Всем привет! Подскажите, пожалуйста, либо я долюблюсь в глаза, либо опечатка. Хочу

добавить DNS апстримы для coreDNS в кубере. Чтобы сначала запросы были в рамках кубера, а потом использовались инфраструктурные DNS сервера.

В доке сказано, что для указания апстримов можно юзать любой режим

В шаблоне конфига говорится, что апстримы можно только для resolvconf_mode: host_resolvconf

https://github.com/kubernetes-sigs/kubespray/blob/77149e5d89695f66f1e92d8ab096e8a7b5848f6f/roles/kubernetes-apps/ansible/templates/coredns-config.yml.j2#L44

Короче, как понять, какие DNS юзает coreDNS в качестве апстримов, если их в конфигмапе нет?

К сожалению уже не у компа. Просто вчера как раз обновлял корднс. Мы forward используем с указанием файла /etc/resolv.conf хостовой системы. С моей точки зрения, держать корднс в кубспрее - ошибка. Когда десятки нод в кубе - оно оочень долго работает ) Все что могли вынесли из кубспрея.

я недавно вынес ингресс-контроллер из кубспрея, т.к. катать этот комбайн для мизерной настройки — то ещё удовольствие, особенно, если зафейлился ран Как будет возможность, напишите) мне ещё интересно, какой resolvconf_mode вы ранее использовали? docker_dns или host_resolvconf?

а положить в /etc/resolv.conf на узлах нельзя ?

там и лежат

нда. там какая-то ансибловая жесть в роли preinstall. можно на тесте попробовать.. но мне кажется держать аплинки в /etc/resolv.conf на узлах прощее

посоветуй плиз, как бы ты законфижил resolvconf_mode с использованием upstream_dns_servers. У меня довольно простое требование. Хочу, чтобы сначала DNS отрабатывал запросы внутри кубера, а потом использовал апстримы, которые указываю в upstream_dns_servers

какой DNS ?

coreDNS

ну ты выиграл. оно так и работает, как ты хочешь. в чем твои проблемы?

проблема в том, что периодически не резолвятся внешние запросы, а они критически важны на стадиях запуска приложений. И я так и не врубился, как coreDNS знает про апстримы, если в конфигмапе их нет

берет их из файлика /etc/resolv.conf, который на узле лежит

хм, тогда почему иногда фейлятся резолвы? иногда проходят, иногда такое nslookup dev.example.com Server: 10.234.0.3 Address: 10.234.0.3:53 ** server can't find dev.example.com: NXDOMAIN

а nodelocaldns есть у тебя ?

enable_nodelocaldns: false

А нужны? В доке по кубспрею скудное описание

ну да. плюс в configmap dns-autoscaler можно побольше инстансов coredns запускать. у меня было когда приложуха активно спамила DNS и он не справлялся

подскажи ещё, пожалуйста, зачем в кубспрее определили с таким адресом? nodelocaldns_ip: 169.254.25.10 С какой целью?

https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/#configuration Note: The local listen IP address for NodeLocal DNSCache can be any IP in the 169.254.20.0/16 space or any other IP address that can be guaranteed to not collide with any existing IP. This document uses 169.254.20.10 as an example.

Даже тут в чатике можешь поиском воспользоваться и увидишь, что coredns без nodelocaldns работает плохо. Точнее там дело не столько в самом coredns, но тем не менее. Скажем одна из распространённых проблем (может быть ее уже и пофиксили): один из подов с корднс упал или переезжает на другую ноду, но запросы ещё некоторое время идут на адрес умершего пода.

интересный кейс вы описали. Спасибо!

Это разве проблема coredns? У меня с любыми dns подкапотом все грустно

https://github.com/kubernetes/kubernetes/issues/56903 https://m.habr.com/ru/post/503032/ Если в чатике не накрутил

Ещё нет. Спасибо за ссылки

Link-local ip, кажись зовётся приблуда.

для переездов вроде graceful shutdown придумали, правда не уверен насколько хорошо оно работает с udp

Ммм а какая разница - там же в любом случае с грейсфули он должен сначала убрать свои ендпоинты из сервайс а потом терминейтнутся не?

Идея graceful shutdown в том чтобы дождаться завершения всех сессий, только потом умереть, но полагаю с udp это не работает

Не имеет значения же. Всё зависит от того, как процесс обрабатывает SIGTERM/

Нет, кубер посылает SIGTERM и переводит под в статус Terminating, а как быстро успеет endpoints controller удалить endpoint - ещё вопрос.

В этом идея, да, но никаких механизмов искаропки, которые следят за сессиями — хоть tcp, хоть udp — нет. Это на совести разработчика приложения.

Я делал хельм чарт даже для него более удобный, чем официальный: https://github.com/Nastradamus/myhelmcharts/tree/master/nodelocaldns Изучение его поможет время сэкономить :)

Спасибо) схоронил

Официальный kube-proxy вроде как следит, я с nfs-server-provisioner и ipvs сталкивался с проблемой что последний коннекшены не тушил на клиентах, в результате чего всё намертво висло)

Это настолько внезапно, что я б даже не в документацию посмотрел, а в код)

И дождаться, пока все правила уберутся со всех нод

apipa

Поставил. nslookup все также фейлятся через раз. Чтобы посоветовали потюнить, посмотреть?

а в поду точно правильный reslolv.conf приехал?

для дебага я использую команду kubectl run -n spb-dev -i --tty busybox --image=registry.example.com:9080/busybox:1.32 --restart=Never -- sh внутри пода в файле resolv.conf nameserver 10.234.0.3 search ex-dev.svc.k8s.dev.example.com svc.k8s.dev.example.com k8s.dev.example.com dev.example.com lan.example.com options ndots:5

Дык не верный приехал)

cat /etc/resolv.conf nameserver 169.254.20.10 search test.svc.cluster.local svc.cluster.local cluster.local test.test.test options ndots:5

Ты после установки рестартил под?

верность не хранит?) А как вообще в nameserver 169.254.20.10 попадает в поды? он из докер опций подкидывается?

да

@stef_kkk

спасиб