Comments 19
Мне кажется, проблема в данном случае в том, что выбор делается между 2 серверами или 4. При таком количестве серверов в целом использование Kubernetes мне кажется весьма сомнительной идеей. В случае же когда нужно выбрать, скажем, 50 более мощных серверов или 100 более слабых, как правило более мощные сервера предпочительны, поскольку добавление 1 сервера увеличивает емкость незначительно, так что не обязательно иметь маленькие сервера, чтобы плавнее масштабировать расходы на железо/виртуалки, и при этом возможна более полная утилизация ресурсов.
Думаю на цифрах 50, 100 и т.д. в первую очередь будет важен вопрос цены и затрат на электроенергию (в случае своего железа), чем логика управления k8s.
Сложный вопрос. Я бы исходил из оценки, что один разработчик обходится примерно в такое же количество денег, сколько и 10-20 физических серверов (всё зависит от конфигурации серверов, конечно же, от их общего количества и т.д.), так что по факту 50-100 серверов будут эквивалентны 5-10 разработчикам. Поддержка живого Kubernetes кластера, даже в весьма простых случаях, насколько я могу судить, обычно требует пару full-time инженеров (или отдавать на аутсорс, но не все компании готовы так делать, и не факт, что это покроет все use-кейсы). То есть, условно, по моим очень грубым оценкам, минимальная «цена Kubenetes» в плане стоимости поддержки этого решения в продакшене может составлять эквивалент 20-40 физических серверов :). То есть, электроэнергия в этом случае вряд ли является определяющим фактором.
Я и соглашусь, и не соглашусь — типовые кластеры или кластеры в облаке, наверное, легче обслуживать, чем баре метал. И что значит обслуживать — чисто сам кластер поддерживать или еще помогать разработчикам писать пайплайны, правильно деплоится и правильно строить структуру своих приложений ?
если настроен мониторинг, логирование и алерты.
Как будто сделать это два пальца обоссать, извините.
Все очень индивидуально. Я соглашусь, что вряд ли в отдельно взятой организации ХХХ будут раскатывать сильно разные кластера — это реально дорого с точки зрения обслуживания. Но если у парней баре метал — про терраформ скорее всего придется забыть. Есть, конечно, монстры вроде Г-на Халупа из Тинькофф, которые свой провайдер пишут, но у них масштабы сотни узлов — до этого ещё дорасти надо. А для бытовых нужд, коллеги подсказывают, и кьюбспрей ок.
Статья странная. Главные узлы? Модули? Я бы все-таки переводил по-другому
В связи с этим есть вопрос — буду признателен за ссылки и подсказки. Ситуация такая — есть свой небольшой проект — фронт на Angular, бек на NodeJS и облако на Яше. Пилил всегда все на локал хосте, ибо деплоем и т.д никогда не занимался. Но вот пришло время все это дело не просто перенести в облако, но и админить и обновлять и т.д С фронтом все понятно — его можно куда угодно вставить — хоть с беком вместе, хоть где угодно. А вот с беком вопрос — как и с помощью каких инструментов все организовать по уму?
Сейчас вот как сделал — фронт у меня отдельно, на отдельном домене — с ним нет проблем. А вот с беком печаль — пока временно у меня так — поднял сервак на nginx, подключил SSL. Рабочая скомпиленная версия бека у меня запущена на 7000 порту через PM2 и на нее nginx направляет путь мойдомен.ру/api.
А дев версию также запускаю в облаке через nodemon на 3000 порту и nginx направляет путь мойдомен.ру/dev. А редактирую файлы редактором через SSH напрямую. nodemon после сохранения автоматом перезапускает приложуху и становится доступны изменения. Но печаль в том что компилится и перезапускается это все тоже в облаке и забирает часть ресурсов.
Можно конечно пилить типа все на локалке, а в облако заливать уже компиленную версию — но сейчас как раз буду делать яндекс кассу и там вроде как запросы надо делать со своего сервака с SSL а не с локалхоста и надо сразу же пилить и тестить одновременно.
В связи с этим вопрос — как все это правильно организовать по уму? Что бы и пилить можно было, и тестить сразу же, и выкатывать обновления и в дальнейшем расширять потом.
В телеграм группах общался на эту тему — там толку 0 — одни разрабы сидят — каждый пилит как хочет.
все правильно — организовывать в кубернетесе несколько окружений. Можно по неймспейсам распихать и каждому окружению свои ресурсы выделить. Редактирование кода — только через гит. Никаких больше хотрелоадов и прочей дичи. Код в гитлабе — новая версия — оно собирается в образы, из них в кубернетесе разворачиваются сервисы. Далее тестируете. Потом обновляете прод. Не сложно, в общем
Единого рецепта не существует, а у каждой ситуации свои нюансы, и только продакшн покажет правду.
Как хорошо, что я читаю статьи с конца.
Рабочие узлы Kubernetes: много маленьких или несколько больших?