а теперь к вопросам: в конце первого сообщения философские вопросы почему-то интересны. 1. глобальный кэш etcd - ощущение, что к нему ни у кого нет критики вообще ни у кого, это нравится, но настораживает. хочется про траблы и "грабли" 2. недоработки, ограничения внутренних днс, что там с srv поддоменами, нескольким a записям или можно ли подружить с внешними днс (роут58, например) 3. вычислительно все красиво и здорово, но что курить для раздумления правил фэн-шуйного хранения данных (ок, шардинг, реплики...), а какие есть coreos ориентированые идеи для распределенных fs, хранилищах ключей и внутрикластерной CA, например (были кейсы, когда микросервисам внутри системы нельзя было доверять друг-другу и вообще все где фигурируют финансы нужно было подписывать, а в ряде случаев, шифровать при общении с кем угодно, навернякак кто-то это уже продумал). 4. какие реальные ощущения от скорости реакции кластера на то, что происходит с его содержимым (образно, если я запущу вагрантовый вариант coreos на десктопе, проброшу все порты к нему, добавлю в кластер и решу все сервисы готовить и обкатывать на локальной ноде кластера, а в продакшн оно улетает не по команде, а просто ради ресурсов и само же "множится до нужного количества и расселяется" после клонирования сервиса/пачки сервисов с признаками продакшн хотелок. странный кейс, но идею "ждать от кластера того что бы он продолжал себя вести идеально" описывает корректно, думаю.) 5. если верно понимаю, то у нод порты для "общения между собой" обычно торчат наружу и можно повынимать кучу разных конфигов просто зная что спрашивать (или мне показалось?)

5 - https://github.com/kayrus/kubelet-exploit это единственная уязвимость такого рода, о которой слышал. kayrus сидит здесь же, скорее всего подскажет позже, актуально ли это еще. В GKE это решают просто фаерволлом.

Про хранение данных - тоже уточнить бы, в каком контексте идет вопрос. Правила непосредственно разнесения узлов приложения (будь то база данных или распределенная фс) устанавливает скорее само приложение. Общая рекомендация - стараться не заносить в куб хранение данных, если иначе никак, то либо хранить на подключаемом сетевом хранилище (это не [только] nfs, полный список https://kubernetes.io/docs/user-guide/persistent-volumes/#types-of-persistent-volumes), либо - самый опасный путь - хранить прямо на машине и разгребать всякие проблемы управления шедулингом.

Про кэш etcd впервые слышу, можно поподробней? Про dns не уверен, что правильно понял вопрос, но внутренний сервис резолвится либо в один псевдоайпишник (который разруливает iptables/userland proxy), либо в несколько "прямых" айпишников, либо указывает на другой адрес (внешний или внутренний). SRV-записи должны создаваться.

я сейчас только в контексте куба говорю. корку тут вряд ли много народа гоняет, но я практически уверен, что и в корке, и в кубе etcd кэшем не является

Если вопрос в применимости в качестве кэша, то он под это дело не очень хорошо заточен, шардинга нет, держаться in-memory он, насколько знаю, не умеет.

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

etcd все-таки про консенсус

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

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

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

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

Нет, если запрос идет не с weak consistency, даже мастер обязан обратиться к кластеру и убедиться, что он является мастером. Иначе ни о каком linearizability нельзя говорить, потому что история может разойтись на двух нодах, которые одновременно считают себя мастеарми. Я не с потолка это беру https://github.com/coreos/etcd/issues/741

Замечу, что etcd не только k-v хранилище, но ещё и очереди отлично реализованы. используем, конечно, отдельный от k8s инстанс

просто балансировщик поставить, который разбирает хост и скидывает на соответствующий неймспейс или сервис, составляя имя этого неймспейса или сервиса на лету я буквально вчера сюда же за советом по подобной штуке обращался, у меня просто стоит nginx, который ловит <build>.<project>.<environment>.ci.company.name и перебрасывает на ingress.<project>-<environment>-<build>.svc.cluster.local

http://docs.grafana.org/alerting/notifications/#slack вот это?

это баг 1.13... вообще очень нехороший релиз вышел 1.13, ожидаем патчей...