Комментарии 6
Обижаете nomad. Это лучшее решение, если катить в кластер нужно, но в команде 0-1 devops человека. Будет на порядок дешевле, проще и меньше инцидентов.
Проще не иметь ролей, чем криво настроенные.
Проще не использовать CNI, чем кое как ее запустить.
Проще писать только stateless и не ставить как попало условный rook одной командой, ради того, чтобы дать прогерам писать в /uploads вместо s3
И тп.
Куб офигенный, но он часто избыточен. Направление понятно… за куб занесут больше организаторам.
Swarm, по-моему, рано закапывать. Да, возможностей меньше, но далеко не факт, что все возможности k8s вам нужны. Потратив полгода на перевод системы с docker-compose на managed k8s, до сих пор не уверен, что это правильное решение было. Да, большой потенциал к развитию системы в будущем, но то, что получилось на Swarm можно было бы сделать раза в 3 быстрее.
По курсам: уже имея эти полгода опыта, есть смысл в базовом?
Мне кажется Swarm и k8s — это разные масштабы. То есть если проект растёт постепенно, от одной машины к десятку — Swarm хорошее решение. Сначала пишем dockerfile для каждого подпроекта, потом compose, потом практически меняем версию композ файла и добавляем описание ресурсов/тэгов. Понятно как расти.
Если есть раскатанное на сотню серверов решение, то лучше внедрять k8s. Гугл же это делал для своего кейса. Может у вас в проекте было не так много серверов, что особой радости от перехода на куберы не случилось? Ну или апдейты продукта не настолько частые например.
Kubernetes за 3 дня. Просто о сложном