Есть 6 серверов, они ESXi 7.0 + Vcenter. И на них порядка 50 виртуальных машин.
Проект коммерческий, но закрытого типа. Т.е нет публичных каких-то сервисов вещающих в паблик. Что еще важно, нет левых людей в разработке и все через github
Сейчас все очень просто:
Нужна среда для разработки – нажал и с шаблона 5 секунд готовая виртуалка и поехали. Надоела – удалил. Сломалась на разработке – удалил и снова создал. Вообщем-то проблем никаких нет, за ресурсами следит ESXi. Нужен прод? нажал и готово
Но есть программисты которые говорят: "давай по контейнерам распихаем. Это удобно, нажал кнопку и готовый контейнер открылся со всеми зависимости и работает".
Я почитал много статей на Habr, наткнулся на то что Kubernetes можно сцепить с Vcenter – что удобно. Но я так и не понял в чем сакральный смысл с учетом вводных данных. Да, микросервисов обслуживающих основное ядро – много. Почти 80% виртуальных машин наплодили именно для микросервисов обслуги.
Единственное что меня заставляет думать о Kubernetes – когда виртуалок стало за 30, если честно я уже хотел наоборот их немного порезать потому что нет проблем с ресурсами, нет никакой бюрократии...можно распихать по 3 машинам все с повышенными ресурсами и пусть коптятся там вместе.
Исходя из статей пока лично мой вывод такой: если рут доступ к ресурсам, то ровным счетом это дополнительное ненужное нагромождение.
Встает логичный вопрос сейчас, стоит ли инвестировать время в то чтобы в это переходить при текущих вводных? Какие плюсы можно получить по сравнению просто с виртуалками?
Но есть программисты которые говорят: "давай по контейнерам распихаем. Это удобно, нажал кнопку и готовый контейнер открылся со всеми зависимости и работает".
Против таких прекрасно работает одна схема.
Запоминай фразу:
Идея - огнище. Вот тебе пара виртуалок - разверни на них ту систему, которую ты предлагаешь использовать. Если действительно работать с ней легче и всё работает лучше - посмотрим.
Большинство отваливаются на этом этапе, тк не ожидают, что они сами и должны это реализовать.
Если эксперимент успешен - тогда вот тебе ещё два вопроса:
1. Кто это будет поддерживать? На ком ответственность в случае сбоя?
2. Сколько будет стоить на это переехать?
Встает логичный вопрос сейчас, стоит ли инвестировать время в то чтобы в это переходить при текущих вводных? Какие плюсы можно получить по сравнению просто с виртуалками?
Вообще выигрыш будет только тогда, когда ещё все эти 80 приложений ещё и перепишут, чтобы они адекватно работали в кубере.
Я бы попробовал для начала как раз развернуть небольшой кластер и попробовал бы в нём запустить несколько наименее рискованных сервисов.
На практике оценить гораздо легче, обычно.
Sanes, Это я для себя спрашиваю чтоб понять в чем там соль. По поводу переписывания вопрос интересный с учетом того что все на исполняемых файлах завязано golang/C++. Т.е уже готовые исполнительные уходят на прод. виртуалки после тестов. И я не понимаю че там переписывать. Но сам ваш комментарий что надо что-то переписывать...заставляет задуматься. Тут вопрос уже в другом ключе: готов ли я платить за "непонятные движухи"
PS: Хочу сказать большое спасибо за то что прокомментировали подробно, вы как будто сталкивались уже с ситуацией и понимаете о чем идет речь.
alexdora, чисто в теории K8s может упросить раскатку, выделение новых ресурсов, и сбор логов/метрик. + может повысить доступность, надёжность и безопасность, но только при условии, что все умеют с ним работать.
Короче тут в любом случае нужна задача на:
1. Оценку потенциального выигрыша
2. Оценку готовности самих приложений к работе в кубере
3. Оценку готовности самих разрабов и опсов
Контейнеры ресурсов жрут меньше, с кубером есть ряд плюсов он будет поддерживать работу системы в случаях неких факапах, на виртуалках хз как такое делать. Ну типа как отследить что некий процесс в виртуальной машине стал выжрал всю положенную память и должен быть перезапущен или просто упал. Я думаю что внедрить куб можно не разом постепенно переводя часть сервисов.
Василий Банников,
> Кто это будет поддерживать? На ком ответственность в случае сбоя?
возникает вопрос ты там в этой схеме зачем?
вот если программист начнет в таком ключе реагировать на задачи бизнеса, его просто уволят.
Прям бесят такие "коллеги" я это не умею тебе надо делай....
вот если программист начнет в таком ключе реагировать на задачи бизнеса, его просто уволят.
Я описал вопросы не от разработчика к бизнесу, а наоборот. Если обратите внимание - вопрос задаёт менеджер, а не разраб.
Прям бесят такие "коллеги" я это не умею тебе надо делай....
А как по твоему ещё нужно реагировать на хотелку из ряда?
Что-то не удобно на виртуалках работать. Давайте все на кубер переедем. Я сам экспертизой не владею - давайте вы сами это сделаете.
Зачем? Какую выгоду это нам даст?
А вот везде пишут, что кубер это модно
Очевидно, что в случае реализации такой хотелки будет так:
1. Будет потрачено много ресурсов на поднятие кластера
2. N приложений будут адаптированы под кластер
3. Кое как эти приложения будут раскатаны, но от k8s в лучшем случае будет только Deployment использоваться, тк экспертизы на более сложные вещи нет.
4. Рано или поздно произойдёт сбой и никто не будет знать, как с ним разбираться, тк ответственности нет, а экспертизы у зачинщика тоже нет.
По тому я и предлагаю сначала разобраться, а действительно ли компания осилит, и вообще на сколько это нужно
> А как по твоему ещё нужно реагировать на хотелку из ряда?
>Что-то не удобно на виртуалках работать.
Что то не удобно таскать, давайте колеса прикрутим.
Неее давайте таскать как раньше мы это умеем нас отцы деды научили.
Я вот с чем согласен, что сразу перезжать на 100% не стоит. Но возможно стоит поднять куб завести на него часть сервисов и посмотреть как оно живет.
Да это займет много времени и возможно будет больно. но жить на виртуалках очень дорого.
Василий,
"Ну типа как отследить что некий процесс в виртуальной машине стал выжрал всю положенную память"
В приложениях встроен мониторинг или отдельное приложение с мониторингом? У нас везде промитей+графа в базе. Я понимаю с точки зрения кубов что приложение работающее в ноде не выйдет за рамки и не подавит другие приложения на виртуальной машине. Но с таким же успехом я могу ограничить виртуальной машиной.
Ну пример из практики, был сервис где всплыла утечка памяти. Он стоял на виртуалке где еще стояло 4-5 микросервисов. По базе Vcenter кинул алерт, что 85% памяти исчерпано. Зашли на виртуалку, посмотрели кто там жрун – перезапустили и отправили исправление чтоб нашли утечку.
Чтобы дал куб – просто контейнер вырос бы и наверное ребутнулся с ошибкой самостоятельно.
alexdora, На самом деле платите, но неявно. Более явно это проявится в ситуации, когда виртуалок окажется не 50, а 500 и им будет маловато железа... И железо потребуется докупить... Вот тут куберодокероподобные варианты позволят втиснуться.
Ну и так, чисто моментики: подъём полсотни подов ~5 минут, те же полсотни виртуалок - думаю несколько подольше
Но, естественно, просто так кубернизировать приложения - не вариант - своя идеология, подходы = переделывать архитектуру и это скорее всего окажется препятствием.
На самом деле платите, но неявно. Более явно это проявится в ситуации, когда виртуалок окажется не 50, а 500 и им будет маловато железа... И железо потребуется докупить... Вот тут куберодокероподобные варианты позволят втиснуться.
Я понимаю о чем вы говорите, что запихнуть еще больше в отведенные ресурсы без риска обвала. Т.е утилизировать ресурсы максимально. Безусловно, я спорить не буду что таким образом можно это сделать. Потому что как бы не были прекрасны виртуалки, каждая требует RAM и CPU IO, 50 виртуалок будут жрать тупо больше даже на режиме простоя.
Собственно сейчас благодаря тому что вы написали мне стало ясно что в моем проекте на текущий момент овчинка не стоит выделки. Поясню кратко: вытягивание последних каплей ресурса из каждого сервера – не приоритетная задача. Вообще в целом получилось что сервера кроме первых двух изначально докупались как хранилище. Да можно было по феншую СХД купить, но рассматривался вариант: Хранилище и вдруг нужно будет резервно раскрыть виртуалки там. Так что кроме первых двух серверов остальные в пиках создают 20-30% нагрузки. И мощности свободной как и RAM – слишком много.
Ну и так, чисто моментики: подъём полсотни подов ~5 минут, те же полсотни виртуалок - думаю несколько подольше
Не спора ради, но отвечу на это. В текущей реализации у нас, мы делаем из шаблона с указанием имени машины. 20 секунд и инстанс готов, со всеми настройками в том числе гитом и прочей херней, то что заведено было в шаблон. Так как это редкость создание нового инстанса – делаем так. Но я зашел в VCenter, там есть необходимый функционал для Auto Deploy. И думаю что за минуту можно раскрыть штук 50 одним нажатием кнопки. Тут сложно сказать сколько их раскроется за минуту т.к все упрется в массив. Там где NVME можно свыше 100 запустить одной командой. Но опять же не тестил т.к нет необходимости
p.s. а как у вас с изоляцией вмок?
Не очень понимаю вопроc. Все что ограничивает виртуалки это либо Resource pool который введен на не критические виртуалки с микросервисами, чтоб они если что не мешали. Критические сервисы и ядро стоят с Reservation
alexdora, по ресурсам и их утилизации - это выглядит так: железки -> вмки -> поды - грубо следующий уровень
по скорости развертывания немного несравниваемое сравниваем - поднять по сути клон подготовленной виртуалки это немного другое (на все бесконечные случаи - надо будет бесконечное число темплейтов)
с изоляцией - это когда одна вм может постучаться в другую или не может, если незадекларировано что ей можно по конкретному протоколу и порту
Если все работает надежно и автоматизировано, то не надо никуда переходить.
Ну или сделать небольшой PoC и посмотреть насколько легко-удобно получилось.
Насчет преимуществ - не согласен с Alexey Dmitriev - все это легко получить и без K8S. На мой взгляд преимуществ два - portability и работа с контейнерами. То есть если решили использовать контейнеры, то K8S выбор по умолчанию, так как самый популярный.
Простой
Средний
