Pull to refresh

Comments 6

Обижаете nomad. Это лучшее решение, если катить в кластер нужно, но в команде 0-1 devops человека. Будет на порядок дешевле, проще и меньше инцидентов.


Проще не иметь ролей, чем криво настроенные.
Проще не использовать CNI, чем кое как ее запустить.
Проще писать только stateless и не ставить как попало условный rook одной командой, ради того, чтобы дать прогерам писать в /uploads вместо s3
И тп.


Куб офигенный, но он часто избыточен. Направление понятно… за куб занесут больше организаторам.

Номад прекрасен, спасибо за комментарий.

Swarm, по-моему, рано закапывать. Да, возможностей меньше, но далеко не факт, что все возможности k8s вам нужны. Потратив полгода на перевод системы с docker-compose на managed k8s, до сих пор не уверен, что это правильное решение было. Да, большой потенциал к развитию системы в будущем, но то, что получилось на Swarm можно было бы сделать раза в 3 быстрее.


По курсам: уже имея эти полгода опыта, есть смысл в базовом?

Мне кажется Swarm и k8s — это разные масштабы. То есть если проект растёт постепенно, от одной машины к десятку — Swarm хорошее решение. Сначала пишем dockerfile для каждого подпроекта, потом compose, потом практически меняем версию композ файла и добавляем описание ресурсов/тэгов. Понятно как расти.
Если есть раскатанное на сотню серверов решение, то лучше внедрять k8s. Гугл же это делал для своего кейса. Может у вас в проекте было не так много серверов, что особой радости от перехода на куберы не случилось? Ну или апдейты продукта не настолько частые например.

Да, надо было уточнить в комментарии, что речь о проектах в пределах максимум полусотни сервисов, раскатанных по, максиум, 9-11 серверов, а чаще 3-5, без требований к любому автомасштабированию.

Ну в этом случае да, k8s можно использовать скорее в образовательных целях)
Я пока что использую Swarm, K8s для моих проектов выглядит слишком большим решением. Тоже считаю, что рановато Swarm хоронить)
Sign up to leave a comment.