во https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/405-ingress-controllers

хорошая ссылка, спасибо.

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

ну т.е. я пока не вижу ЗНАЧИТЕЛЬНЫХ преимуществ перед kops/kubespray у EKS

есть надежда, что сделают получше

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

преимущество простое - решение проблем через создание тикета

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

ну таки у меня катаются мастера + ноды одним конфигом терраформа за 11-12 минут

преимущество простое - решение проблем через создание тикета

Если у тебя саппорт куплен нужный

Иначе - сасай

ну конечно энтерпрайз саппорт есть

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

будешь выгребать все их тупые баги когда ломается какой-то managed service типа elasticache и дальше первого уровня индусов саппорта не пробьешься

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

Ну тут такое, но крупный интерпрейз все же чаще покупает саппорт

ну конечно, а как ещё

а эти статы прометеус умеет собирать из нод экспортера или еще откуда?

из cadvisor'а

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

Насколько помню, как в днс, 64 максимум на сегмент, 256 все целиком. Но лучше свериться со спекой.

кстати, может кто-то может подсказать как мне заставить kube-dns не пытаться резолвить некоторые домены сначала внутри кластера? т.е. у меня есть route53 зона и я хочу чтобы на резолв доменов вида *.companydomain.com он сразу отправлял запрос в dns server выданный амазон в vpc (т.е. в случае дефолтного cidr это 10.0.0.2)? пробовал по вот этой доке настроить https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/ stubDomains: | {“companydomain.com”: [“10.0.0.2”]} но вижу в логах он всё равно пытается сначала зарезовлить внутри кластера добавляю .svc.local в конец и т.п.

может конечно днс под не увидел configmap после того как я его создал как в статье описано и рестартанул под (внутрь контейнера не заходил не проверял появился ли маунт, надо бы проверить)

а может я что-то не понимаю и это вообще не так надо делать? И вопрос в догонку, может это можно сделать с помошью coredns? У меня сейчас 1.10 но в 1.11 coredns из коробки - может стоит сразу переехать на coredns если это решит все эти бесконечные проблемы с днс

само по себе то что резолвить сначала пытается внутри кластера не проблема но у меня я так понимаю вот эта проблема https://github.com/kubernetes/dns/issues/96 - т.е. иногда рандомно приложение не может зарезолвить днс. Я уже поднял количество реплик kube-dns чтобы было по 1 реплике на ноду (так я спасался от этих проблем во времена 1.4) но что-то не помогло ?

у тебя же в resolv.conf в подах вписано ndots:2 или 3

куда копать как задебажить проблему нормально если она рандомно вылазит время от времени - теряюсь в догадках. Включил логи запросов в kube-dns но там их столько сыпется что там фиг что найдешь

ну то есть в днс-сервер будет прилетать всегда с подстановкой куберовского днс сначала

у тебя же в resolv.conf в подах вписано ndots:2 или 3

у меня вообще 5 кажется стоит - как по дефолту в копсе

ну там задранное значение, я не помню точно

да, а как это можно исправить? я вот думал stubDomains опция должна это исправить

но что-то ничего не поменялось

ну настройки резолв.конф она точно не исправит

честно говоря даже не знаю

короче надо дебажить дальше :(

так уж резолвер работает

coredns у меня что-то с полпинка не взлетел (как обычно есть хелм чарт который stable но ни фига не работает), вот думаю стоит попытаться докрутить coredns или там будет та же проблема

ну проблема-то не в днс-сервер

так уж резолвер работает

я понимаю но по статье (вот картинка https://1.bp.blogspot.com/-IeFx2Uuq_i0/WORRuQpxG_I/AAAAAAAABBA/g1P3ljd7YGYMShoHJnPRK1IfX5h3o9GvACEw/s400/dns.png не должен kube-dns ломиться на кластерный резолвер а должен сразу идти на апстрим)

вернее dnsmasq

а ты можешь настройки днсмаск подкрутить?

хотя тебе же под всё равно посылает сначала днс-запрос с приаттаченым твоим днс-адресом

конечно могу и я уже подкрутил - включил логирование запросов

хотя тебе же под всё равно посылает сначала днс-запрос с приаттаченым твоим днс-адресом

вот тут не уверен что понял, можно поподробнее?

под ломится на что-то типа mysql.demo.company.com который есть CNAME или A ALIAS в амазоновском route53 для RDS, elasticache и т.п.

ну ты же знаешь как ndots работает и кто его читает

может ломится и по прямому урлу зостед сервиса, т.е. типа <какакая-то херня из букв и цифр>.amazonaws.com

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

кажется до меня дошло, у меня же сначала resolv.conf внутри каждого пода

ну!

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

надо ходить в один (но может стать больше)

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

если да, то просто сделай ndots:0

ну или типа того

для этого пода

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 и снова вылезла старая добрая проблема

ERROR: S client not available

которая?

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

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

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

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

я включил логи 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: ...благо всё в хелм чартах деплоится. Работы много но хоть понятно что делать а не дебажить непонятно что и где

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