Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>Кубер нужен если нужно поддерживать сотню и более серверов, тысячи сервисов и нужна изоляция опсов от разработки.
ДФ>Если команда не очень большая и нет ненависти между опсами и разработкой, то кубер не очень нужен, так как реально покрывает очень небольшую часть реально важной функциональности. При этом нормальная эксплуатация своего кубера — очень непростая штука.
ДФ>Впрочем, раз у вас только один ДЦ, то надежность вам не очень важна, так что может и кубер, поставленный без опыта — тоже сойдет. Ну полежите несколько дней в первые полгода...
ДФ>Кстати, к куберу еще придется придумывать сторадж, а ceph — тоже штука крайне неприятная.

Я тут вообще со всем не согласен.

Моё мнение — кубер нужен вообще всегда, если в команде есть хотя бы один человек, который имел с ним дело или хочет этому научиться. Даже на одном сервере кубер даёт профита больше, чем геморроя.

Я сейчас работаю в компании, где кубера не было. Где сервисы работают в докере. Где поверх докера наворотили кривых скриптов со всякими автобэкапами. Где перед докером стоит нгинкс с километровым конфигом, в котором никто не разбирается. Где сертификаты постоянно протухают, т.к. сертбот постоянно ломается. Где ни о какой избыточности речи не идёт.

И я перевожу всё это на кубер, имея изначально нулевые знания по куберу. При этом у нас нет возможности использовать управляемый кубер, поэтому я всё настроил руками через kubeadm.

По итогу:

1. Надёжность у кубера хорошая. У нашего провайдера вот буквально вчера сеть штормило, пинги толком не ходили. Ничего, не развалилось, какие-то системные поды рестартовали по 50 раз, сервисы отвечали через раз, но пока я в kubectl get pods -A не посмотрел — я даже не заметил этого. А если бы юзеры этих сервисов сделали retry, то вообще ничего не заметили бы.

2. Кубер покрывает очень важную часть:

2.1. Он даёт унифицированный язык для описания сервисов, заменяя километровые скрипты или разбросанные по всему серверу в домашних каталогах докер-композы.

2.2. Он даёт унифицированный ингресс, заменяя километровые конфиги нгинкса.

2.3. Он даёт унифицированный механизм работы с letsencrypt абсолютно нулевыми усилиями. cert-manager это вообще мой любимый компонент в кубере. Хочешь — через DNS подтверждай. Хочешь — через HTTP.

3. Кубер даёт возможность органично расти дальше. Просто добавлять новые серверы и тд.

4. Кубер в итоге будет дешевле, чем куча серверов. Ну это у нас так.

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

Здравствуйте, andsm, Вы писали:

A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?

Кубер настолько упрощает все жто дело что вобщем то непонятно зачем думать про альтернативы.

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

Ни в коем случае не говорю, что он серебрянная пуля но времена до него вспоминаю с ужасом.

Зыж: я больше с точки зрения девелопера говорю не админа.

Здравствуйте, MaximVK, Вы писали:

A>>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
MVK>ИМХО, без кубера будет очень тяжко.
На ansible деплой пишется и без куберов.