https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods и вот они предлагают для каждого пода прописать типа dnsPolicy: "None" dnsConfig: nameservers: - 1.2.3.4 searches: - ns1.svc.cluster.local - my.dns.search.suffix options: - name: ndots value: "2" - name: edns0

0 конечно будет слишком

ну да, я примерно это же предлагаю

а приемлимо ли будет ходить по полным внутрикуберовским адресам?

можно, я приложению напихиваю через енв переменные куда ходить

блин но это для каждого подка надо крутить выходить, неприятно как-то

это да

а, ну ты же можешь проще сделать

сказать приложению чтобы всегда точки в конце всех днс-запросов делало

хорошо бы какую-то глобальную опцию типа ты под давай сам не пытайся добавлять домен, иди сразу в кубднс - он знает что куда

типа запрос в www.example.com. сразу уйдёт куда надо

может можно глобально сделать ndots:0

хз

типа запрос в www.example.com. сразу уйдёт куда надо

ну тут не совсем могу, там всякие валидации в приложении на имена хоста, Да и это не решит проблемы запросов на внешние адреса типа app123.another-team.<company|A|B|C>.<com|org|ещё миллион вариантов> которые тоже нет смысла резолвить внутри кластера а надо сразу чтобы шло наружу кластера :(

я так понял у тебя подобных подов целая куча?

но с мускулом надо попробовать с точкой в конце, если что валидацию подправить (или убрать нафиг вообще)

у меня 24 инсталляции 4-6 приложений, каждая инсталляция настроена отдельно и ходит в свои мускули, внешние сервисы и т.п.

куда ему ходить в мускуль, редис и т.п. - напихивается через переменные окружения, а вот ссылки на внешние сервисы они и в базе могут хранить и в коде хардкодить и в целом хз что там где и как

на прошлой неделе два кластера перевезли на 1.10 с 1.5 и снова вылезла старая добрая проблема

которая?

рандомно не резовлится что-то, по логам это по большей части наши амазон базы и редисы

ну вот эта самая 😃

рандомно не резовлится что-то, по логам это по большей части наши амазон базы и редисы

но это может потому что приложение в редис или мускуль ходит сильно чаще чем на внешние сервисы, а может таки для амазон реусрсов только такая проблема - нужно тоже изучить поподробнее

я включил логи dnsmasq а там вот эти все миллионы резолвов на svc.local сначала

включи в днсмаск негатив кеш

там вроде был

https://github.com/kubernetes/dns/issues/239 о, как раз

да вот пишут его надо отключить и он раньше был включен а теперь в апстриме отключили

включи, но небольшое значение выставь

типа 10 секунд

может даже меньше

https://rsmitty.github.io/KubeDNS-Tweaks/

A minor extra is the --no-negcache flag. Because we’re sending so many NXDOMAIN responses around, we don’t want to cache them because it’ll eat our whole cache.

Duct Tape It!

могу попробовать размре кеша увеличить но тогда боюсь можно огрести от RDS - что-то на этой неделе уже 3 раза failover у одной из баз приключился

--address=/org.cluster.local/org.svc.cluster.local/org.d

вот это кажется то что надо

Duct Tape It!

так отож, я почитал эту статью и как-то грустно всё стало

я бы выставил негатив кеш в низкое значение и вписал --address

есть еще другая статья где чувак про ube-dns тоже накидывает и даже собирался патчить ядро из-за альпайновского muslc

--address=/org.cluster.local/org.svc.cluster.local/org.d

я не уверен, что сейчас правильно отвечу, но по-моему тут --server нужен, и это будет фоллбечить на указанный сервак все нужные домены

ну то есть в статье со всем согласен кроме выключения негатив кеша

я не уверен, что сейчас правильно отвечу, но по-моему тут --server нужен, и это будет фоллбечить на указанный сервак все нужные домены

там по ссылке --server тоже указан

я не уверен, что сейчас правильно отвечу, но по-моему тут --server нужен, и это будет фоллбечить на указанный сервак все нужные домены

я пробовал, но насколько я понимаю - это эквивалетно stubDomains в конфигмапе. Они конфигмапу добавили не так давно чтобы люди не лазили редактировать деплоймент а могли в конфигмапе поменять

в любом случае что с --server что с stubDomains - все равно есть рандомные бока резолва и ndots:5 в каждом поде от этого не исчезает и есть куча месорных запросов

(в моих двух кластерах на 1.10)

у меня был локальный dnsmasq в очень поехавшем сетапе, с которым я обходил дефолтные правила резолва этого поехавшего сетапа вот этим вот —server, все работало

ну у тебя выбор либо держать эти запросы (и включить кеширование их), либо шаманить с ndots

либо и то и то

поэтому глядя а весь этот цирк с конями у меня и вопрос возник - может сразу переехать на coredns? А теперь еще выходит надо для каждого пода накрутить dnsPolicy: "None" dnsConfig: ...благо всё в хелм чартах деплоится. Работы много но хоть понятно что делать а не дебажить непонятно что и где

почему-то мне кажется что там будет то же самое

Но сначала хотелось бы увидеть живого человека кто пробовал coredns и у него работало

вот этого я и боюсь :( продолбаюсь день-два фикся кривой чарт а толку не будет

https://github.com/coredns/coredns/issues/1757

https://github.com/coredns/coredns/issues/648 + https://github.com/coredns/perf-tests/issues/4

вот ещё баг по теме https://github.com/kubernetes/kubernetes/issues/47142 читал долго

как обычно, хипстеры решили что юзать готовый dnsmasq не круто

и вот та статья про альпайн и прочее https://blog.quentin-machu.fr/2018/06/24/5-15s-dns-lookups-on-kubernetes/

и вот там он на coredns переехал

нифига у него там костыли подложены

подпорочки

так а я за что 😃

> Edit: As mentioned by Duffie Cooley, it would also be possible to run the DNS server on every nodes using a DaemonSet, and specify the node’s IP as the clusterDNS in kubelet’s configuration. This solution is unfortunately unusable for us, as containers with cluster-wide permissions (even read-only) are unable to run on our worker nodes, and as containers do not have direct network access to any of our nodes for security reasons. хммм

что костыльнее - прописывать dnsPolicy: "None" и т.д. каждому поду или вот это решение

наверное эскобар.пнг

редис в проц упирался? он же однопоточный, на сервере одно ядро было чтоли?

Он больше одного проца сейчас сьесть может только в ряде случаев на бэкграунд таски и при форке. Нагрузка была такая, что он утилизировал одно ядро. В rps к сервису это выглядело как полка, в числе команд выполняемых редисом тоже

Он больше одного проца сейчас сьесть может только в ряде случаев на бэкграунд таски и при форке. Нагрузка была такая, что он утилизировал одно ядро. В rps к сервису это выглядело как полка, в числе команд выполняемых редисом тоже

так собственно в этом и мой вопрос - как может редис упереться в проц? Там максимум надо 3 ядра (а обычно и 2 хватит) - одно на редис, одно не бекап процесс и одно на систему

https://www.yangcs.net/posts/setting-up-ssl-in-envoy/#.W0CD9zRTEMg.telegram 为 Envoy 启用证书验证

так собственно в этом и мой вопрос - как может редис упереться в проц? Там максимум надо 3 ядра (а обычно и 2 хватит) - одно на редис, одно не бекап процесс и одно на систему

Упирался в IPC одного ядра процессора, понятно же вроде.

если в этом смысле - тут хоть кластер хоть на металле одинокий редис, куб тут причем? но ладно, смысл обсуждать

так собственно в этом и мой вопрос - как может редис упереться в проц? Там максимум надо 3 ядра (а обычно и 2 хватит) - одно на редис, одно не бекап процесс и одно на систему

Не знаю какие ещё слова подобрать, утилизировал он свой максимум. Он такое может

Вопрос был ставить в куб или нет, я посоветовал бенчить

помогите советом, плиз) Развёрнута мастер-нода kubernetes (kvm guest VM, Ubuntu 16.04), создаю cert-manager + issuer (Letsencrypt). В списке event'ов issuer'а вижу вот это https://pastebin.com/eg1JhBNP Правильно ли я понимаю, что нужен работающий ipv6 внутри виртуалки (ping6 всегда выдаёт 'Network is unreachable') ? если кто сталкивался, натолкните на мысль) ЗЫ: я не сисадмин и с кубом тоже не большой спец

letsencrypt сайт резолвит?

да

по урлу всё пингуется

вот такие "dial tcp [2a02:26f0:eb:198::3a8e]:443: connect: network is unreachable" штуки меня сущают

будто он пытается туда по ipv6 достучаться

нагуглил вот такую тему https://github.com/jetstack/cert-manager/issues/291

но пока не докурил

Оторви ipv6 от контейнеров