Если вкратце: хочу разворачивать версии приложения (мультиконтейнерного) на разных сабдоменах. Есть мысль запускать каждую версию как отдельный сервис, при этом каждый контейнер будет отдельным подом. А вот как запрос по сабдомену пробросить на конкретный сервис и где в сервисе описать, какой сабдомен он слушает – с этим вообще непонятно. Буду рад услышать, в каком направлении копать

Если вкратце: хочу разворачивать версии приложения (мультиконтейнерного) на разных сабдоменах. Есть мысль запускать каждую версию как отдельный сервис, при этом каждый контейнер будет отдельным подом. А вот как запрос по сабдомену пробросить на конкретный сервис и где в сервисе описать, какой сабдомен он слушает – с этим вообще непонятно. Буду рад услышать, в каком направлении копать

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

Мимими :) Всем вполный вперёд!

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

Я нууб, вопрос такой. Есть 4-5 железных серверов, по которым рукми мигруют разные доккер конетейнеры с микросервисами. Конечно надоело, но там довольно старое всё, на заре докера сделано. Авто-масштабирования и такое всякое не нужны. Скорее решаются задачи резервирования. Кубернетес большой оверкилл для этого? или можно/нужно посмотреть/попробовать.

а теперь к вопросам: в конце первого сообщения философские вопросы почему-то интересны. 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