> Короче -- софт должен быть интегрирован с service discoveryНе обязательно. Что обязательно, так это механизм повторных запросов. SD может выдать нерабочий адрес, а значит повторы на клиенте всё равно должны быть реализованы - это всё надо запрогать.
Кроме того, все компоненты должны иметь избыточность, а значит не могут иметь состояния, влияющего на исход, т.е. должны быть равноправны и взаимозаменяемы - это надо продумывать и прогать наперёд, а то потом устанешь переделывать систему.
Плюс все эти компоненты должны уметь останавливаться или наоброт просыпаться, при failover-е на другой DC к примеру. Переодические процессы, обработка входящего трафика и так далее. Graceful shutdown, выход из standby - самые слабые места, такие вещи всегда задним числом пытаются прикрутить и делают это криво.
Плюс все эти компоненты должны уметь backpressure и fail-fast, что бы не умирать под нагрузкой. А это тоже надо отдельно прогать и проектировать.
И нет, "все так проектируют" неверный тезис, так проектируют очень немногие, а точнее почти никто. Обычно есть некое говно в котором никогда в жизни не было HA, и вдруг принимают решение HA таки сделать (то есть всё вышеозначенное и больше). Если у тебя приложение уже готово к тому, что все компоненты можно размножить, нет единой точки отказа, работают всевозможные фейловеры - ну, через пару лет, когда ты всё это запрогаешь и протестируешь - вот тогда ты можешь якобы облегчить себе жизнь тем, что деплоить эти компоненты за тебя будет не ансибл, а кубер. И виртуалки он же создавать. Но сначала всё равно придётся перелопатить всю архитектуру продукта, что бы быть к этому готовым.
> Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада.
Если приложение уже к этому готово, если оно вообще может скейлиться - да. Но скейлинг != HA. И этот аргумент работает только там, где нагрузка реально сильно скачет. Если мы говорим о внутренних сервисах компании, то там вся нагрузка известна и стабильна. Если о публичных, то обычно тоже стабильна, правда какая-нибудь особо удачная реклама или промо-акция может создать аномальный пик. Но тут надо осторожно - это может быть и ддос, и чей-то кривой скрипт. Ты не хочешь автоматически скейлится под ддос, ддос всё равно победит. Поэтому нужно ли тут мега-быстрое, автоматическое наращивание серверов - спорный момент, от продукта зависит. Да, админ руками это сделает не так быстро, но всё равно через ансибл. То есть речь только про время принятия человеком решения, остальное всё равно автоматика сделает.
> Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации.
Кубер никак не связан с архитектурой приложения вообще. Это такая накрутка сверху которая тебе виртуалку создаст и контейнеры запустит. Он по определению вообще ничего про архитектуру приложения не знает и знать не может. То, что запускается под кубером также запускается и без кубера, при этом вообще без изменений кода. Что бы как намекает.
> Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает.
У тебя есть продукт, про который ты должен понимать где что находится и кто за что отвечает. От продукта ты избавиться не можешь, эта часть по-любому есть. А потом сверху этого у тебя ещё появляется кубер, который начинает мутить воду с миллионами ресурсов, контроллерами этим ресурсов, кластером etcd, собственными особенностями работы, правилами поведения и так далее. И ещё тебе и сам кубер надо сделать HA. То есть у тебя будет голова за кластер etcd болеть, за куберовский HA, за все эти манипуляции с сетевым трафиком, за прокси которые сервисы ресолвят и так далее, плюс за весь продукт который внутри этого всего запущен.
> Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции.
Эти разделения существуют и без кубера прекрасно. А специалисты "такого уровня" всё равно ничего толком не сделают, хоть с кубером хоть без. Только с кубером им будет ещё сложнее разобраться в проблемах на продакшене, т.к. технологий становится больше, сложность понимания всё это внутри устроено возрастает. Ну реально, возьми доку на Кубер, прочитай там всё, потом наберись кучу опыта работы с ним и посмоти на эти накопленные знания. Есть наверно разница - всё это себе в голову заливать, или нет?
> Но во-первых уже давно сделали overlay2
Есть у тебя виртуалка - запускай там софт. Докер-то зачем? В тестовом окружении - офигенно удобно. На проде - зачем?
> Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб
На продакшене в первую очередь всегда стоит надёжность и скорость решения проблем. Чем короче путь от юзера до бизнес-логики и чем он проще, предсказуемее и понятнее - тем быстрее и легче будет решена проблема. Кубер делает кучу магии - сам меняет правила iptables, например. Админам и программистам точно нужна эта головная боль? Я понимаю ценность виртуальных адресов, и это действительно одно из возможных решений, но далеко не единственное и не лучшее.
Вы, такое ощущение, что рассуждаете о простоте с точки зрения когда всё само собой магически работает. Это-то как раз мало кому интересно - когда всё работает. Вопрос что делать когда оно работать перестало. И именно к такой ситуации продукт должен быть максимально готов.
Это как какой-нибудь Hibernate - херак херак он за тебя миллион селектов сгенерил, во как круто. А потом что-то сломалось. И как это чинить непонятно - устанешь понимать все нюансы его работы, что бы вычислить в чём проблема.
> Обновления в кубе как раз гораздо проще.
Я про обновление самого Кубера. Который зависит от докера. И от каких-то кусков линукса типа iptables. И самого докера. И ядра, от которого зависит докер.
> Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам.
Не знаю что такое операторы, но если сами приложения не поддерживают конфигурирование через кластер, то непонятно как может быть что-то проще, чем запуск одной команды ansible, которая тоже кусками, последовательно запушит конфиги и перезапустит приложения? Что и зачем тут надо упрощать? :)
> Не админ, а опс
Да ладно, хипстерская тема какая-то, все знают что Operations - т.е. служба эксплуатации по-русски - это админы. :)
