>> Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче.
> В реальности это не облегчает HA. 99% всего HA - это логика
> самого софта, у которого нет единой точки отказа, который сам умеет
> ходить на несколько адресов, если один из сервисов недоступен, который использует
> базу данных умеющую собственный кластер. Если софт этого не умеет, то
> кубер тебе ничем не поможет.Короче -- софт должен быть интегрирован с service discovery, который вы выбрали при проектировании системы. Ну дык, как будто это какая-то особенная логика. Нынче иначе и не проектируют. Но честное слово, это простая интеграция с zookeeper / etcd (или даже через банальный dns), о каких 99% речь?
> А 1%, про который ты говоришь - это добавление физического сервера или
> создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов
> и амазонов. Известна нормальная нагрузка, всегда есть запас на случай багов
> в софте или в случае публичного сервиса на случай подарков от
> отдела маркетинга. Ну и если тебе раз в месяц понадобилось добавить
> виртуалку у тебя есть ансибл, который это сделает одной командой.
Клиент идёт в облака за удобством и дешевизной. Вот взгляни на тот же амазон. Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада. Так что в итоге получается дешевле, чем vds-ки арендовать или же тем более -- чем держать запас, как Вы предлагаете.
> А вот вреда от кубера и докера довольно много. Ты видимо не
> программист, а админ, и поэтому не знаешь и не понимаешь, что
> система должна быть максимально простой - минимум абстракций, прослоек. Чем проще
> технологический стек, тем проще программистам и поддержке предсказывать возможные ситуации
> на проде, а также чинить поломки.
Да, система должна быть максимально простой. Вот только тут важно понимать, что такое "просто". Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации. Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает.
Плюс к тому, тут важен и социальный аспект. Сейчас уже не начало нулевых, сейчас двадцатые пошли. IT стал массовым явлением. Большинство developers -- из разряда "почему это я не могу создать 10 тысяч файлов в одной директории". Большинство operations engineers -- из разряда "я хз, что там случилось, если рестарт не поможет, то напишу в супорт". Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции.
> Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой.
> Если что-то случилось, тебе помимо обычной головной боли о самом приложении
> надо ещё думать - а не докер ли тут виноват?
Да, с overlayfs было много косяков в своё врмя. Но во-первых уже давно сделали overlay2, который более стабилен, и меньше удивляет своим поведением, а во-вторых не одним оверлеем докерные storage driver-ы живы. Я держал на zfs например. Слышал, что некоторые на btrfs-е гоняли. Плюс к тому, некоторые вон просто блочное устройство в контейнер прокидывают, и сервис с ним делает что хочет, безо всяких там прослоек fs. Mount-ы из хост-системы работают по схожему принципу, так что в принципе ничто не мешает вам гонять postgresql или ноду btc таким макаром, вообще не связываясь с оверлеем.
> И такая же ситуация с кубером, только большего масштаба. Это охереть какая
> сложная система, и каждый раз думать кубер это виноват или докер
> или проблема где-то ещё лежит - нахера это надо? Кому и
> зачем?
Ну это тонкий момент, и я с вами даже частично соглашусь. Если нам нужна производительность, то я безусловно за вынос стейтфулов за пределы куба. Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб. Если мы говорим про стейтлесс, спроектированный как twelve factor app, то в куб однозначно.
> Плюс всё это говно надо обновлять, поддерживать, находить какие-то костыли для ситуаций,
> когда кубер только мешает и так далее.
Вы тут заблуждаетесь. Обновления в кубе как раз гораздо проще. Вы просто прописываете новую версию чарта в helmfile и деплоитесь. Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам. Вот давеча мне потребовалось увеличить message.max.size в кафке. Я просто инкрементировал число в конфиге и применил новую конфигурацию кластера. Kafka-operator это дело подхватил, и сам последовательно применил к каждой ноде, причём по очереди, чтобы не было даунтайма. Операторы вообще сейчас повально для всего пишутся и хорошо поддерживаются.
> Не, я понимаю что технология интересная, но любое усложнение системы должно быть
> очень хорошо обосновано, и если ты не облако мирового масштаба, то
> обосновать ты ничего не сможешь.
Я думаю, что мне вполне удалось это сделать. "Не мужчина, а облако в штанах". =)
PS:
> Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь
1) Не админ, а опс
2) Перешёл в эту сферу аккурат из разработки
=)
