Comments
добавление ядер-процессоров не бесплатное — шина памяти ограничена, например.

Мне кажется, проблема в данном случае в том, что выбор делается между 2 серверами или 4. При таком количестве серверов в целом использование Kubernetes мне кажется весьма сомнительной идеей. В случае же когда нужно выбрать, скажем, 50 более мощных серверов или 100 более слабых, как правило более мощные сервера предпочительны, поскольку добавление 1 сервера увеличивает емкость незначительно, так что не обязательно иметь маленькие сервера, чтобы плавнее масштабировать расходы на железо/виртуалки, и при этом возможна более полная утилизация ресурсов.

Думаю на цифрах 50, 100 и т.д. в первую очередь будет важен вопрос цены и затрат на электроенергию (в случае своего железа), чем логика управления k8s.

Сложный вопрос. Я бы исходил из оценки, что один разработчик обходится примерно в такое же количество денег, сколько и 10-20 физических серверов (всё зависит от конфигурации серверов, конечно же, от их общего количества и т.д.), так что по факту 50-100 серверов будут эквивалентны 5-10 разработчикам. Поддержка живого Kubernetes кластера, даже в весьма простых случаях, насколько я могу судить, обычно требует пару full-time инженеров (или отдавать на аутсорс, но не все компании готовы так делать, и не факт, что это покроет все use-кейсы). То есть, условно, по моим очень грубым оценкам, минимальная «цена Kubenetes» в плане стоимости поддержки этого решения в продакшене может составлять эквивалент 20-40 физических серверов :). То есть, электроэнергия в этом случае вряд ли является определяющим фактором.

Один инженер нужной квалификации и владеющий автоматизацией может обслуживать до 5-10 кластеров, даже не самых простых. Кубер сейчас довольно устойчив к автопилоту из коробки, если настроен мониторинг, логирование и алерты.

Я и соглашусь, и не соглашусь — типовые кластеры или кластеры в облаке, наверное, легче обслуживать, чем баре метал. И что значит обслуживать — чисто сам кластер поддерживать или еще помогать разработчикам писать пайплайны, правильно деплоится и правильно строить структуру своих приложений ?


если настроен мониторинг, логирование и алерты.

Как будто сделать это два пальца обоссать, извините.

Это автоматизируется, причем неплохо — как установка ELK+fluentd для логов, так и прометеус с базовыми алертами из коробки. Используя тот же Terraform production-ready кластер представляет собой небольшой yaml. И да, это касается только самого кластера k8s.
Деплои и построение структуры это совсем другой разговор, тут пока что все очень индивидуально

Все очень индивидуально. Я соглашусь, что вряд ли в отдельно взятой организации ХХХ будут раскатывать сильно разные кластера — это реально дорого с точки зрения обслуживания. Но если у парней баре метал — про терраформ скорее всего придется забыть. Есть, конечно, монстры вроде Г-на Халупа из Тинькофф, которые свой провайдер пишут, но у них масштабы сотни узлов — до этого ещё дорасти надо. А для бытовых нужд, коллеги подсказывают, и кьюбспрей ок.

У меня он (сервер) вообще один. Просто при использовании k8s резко упрощается конфигурация приложения — мне достаточно создать ветку в мерке и через 2-3 минуты на сервере доступна версия приложения собранная из этой ветки со своей базой, доменным именем, сертификатом и.т.д.
Наверняка вы правы, но k8s тоже использует докер и если посмотреть на этот докер, то там просто помойка. Думаю, что ансибл сделает тоже самое из докера, но не предоставит того уровня абстракции, который дает k8s.
За on-premise не скажу, не использовал, но в облаке кажется куда выгоднее и надежнее использовать множество серверов например per product, чем один большой с кучей продуктов per namespace. Kubernetes-on-Kubernetes типа Gardener — это вообще вершина оркестрации, но слишком большой оверхэд, если небольшая компания и нет своего KaaS

Вообще в облаке можно кластер per product делать, заодно не болит голова о rbac в кластере

Статья странная. Главные узлы? Модули? Я бы все-таки переводил по-другому

Еще я совсем забыл — совершенно не рассмотрен вопрос компоновки кластера из год с разными параметрами cpu (в первую очередь — частота процессора)

Хорошая тема, как раз по ней копаю, только азы пока.
В связи с этим есть вопрос — буду признателен за ссылки и подсказки. Ситуация такая — есть свой небольшой проект — фронт на Angular, бек на NodeJS и облако на Яше. Пилил всегда все на локал хосте, ибо деплоем и т.д никогда не занимался. Но вот пришло время все это дело не просто перенести в облако, но и админить и обновлять и т.д С фронтом все понятно — его можно куда угодно вставить — хоть с беком вместе, хоть где угодно. А вот с беком вопрос — как и с помощью каких инструментов все организовать по уму?
Сейчас вот как сделал — фронт у меня отдельно, на отдельном домене — с ним нет проблем. А вот с беком печаль — пока временно у меня так — поднял сервак на nginx, подключил SSL. Рабочая скомпиленная версия бека у меня запущена на 7000 порту через PM2 и на нее nginx направляет путь мойдомен.ру/api.
А дев версию также запускаю в облаке через nodemon на 3000 порту и nginx направляет путь мойдомен.ру/dev. А редактирую файлы редактором через SSH напрямую. nodemon после сохранения автоматом перезапускает приложуху и становится доступны изменения. Но печаль в том что компилится и перезапускается это все тоже в облаке и забирает часть ресурсов.
Можно конечно пилить типа все на локалке, а в облако заливать уже компиленную версию — но сейчас как раз буду делать яндекс кассу и там вроде как запросы надо делать со своего сервака с SSL а не с локалхоста и надо сразу же пилить и тестить одновременно.
В связи с этим вопрос — как все это правильно организовать по уму? Что бы и пилить можно было, и тестить сразу же, и выкатывать обновления и в дальнейшем расширять потом.
В телеграм группах общался на эту тему — там толку 0 — одни разрабы сидят — каждый пилит как хочет.

все правильно — организовывать в кубернетесе несколько окружений. Можно по неймспейсам распихать и каждому окружению свои ресурсы выделить. Редактирование кода — только через гит. Никаких больше хотрелоадов и прочей дичи. Код в гитлабе — новая версия — оно собирается в образы, из них в кубернетесе разворачиваются сервисы. Далее тестируете. Потом обновляете прод. Не сложно, в общем

Может и не сложно, если уже с этим работаешь ))
А пока кубернетес для меня темный лес )
Спасибо за подсказки.
Единого рецепта не существует, а у каждой ситуации свои нюансы, и только продакшн покажет правду.


Как хорошо, что я читаю статьи с конца.
Only those users with full accounts are able to leave comments. Log in, please.