Комментарии 10
Хорошо, статья интересная но так и не увидел сравнения с докером и обьяснений почему кубик лучше докера.
Много чего было, но зачастую контейнеры всегда делаются через докер.
Даже сложные вещи спокойно собираются через doker-compouse, а кубик реально переусложнен как по мне
Он просто не для случая десятка-другого контейнеров в кластере. Плюс — всякие GKE и EKS позволяют не заботиться об инфраструктуре и, как и в swarm, конфигурировать сервисы через yaml.
А если вы не про кластер docker swarm, а про докер на единственном сервере, то, извините, вы сравниваете не те уровни абстракции.
Да все просто, пока у вас вокруг композов, не развелось куча костылей подозрительно напоминающих кубер, можно спокойно жить с композами.
А вот если вы запилили оверлейную сеть, service discovery, что-напоминающее оператор кубера на питоне и т.д. - тогда уже можно задумываться об оркестраторе
Жизнь оркетстров за пределами амазона и подобных площадок полна подводных камней)
А относительно кубика - он все равно упирается в ведомый/ведущий и асинхронную дублированую сеть синхронизованых нод на нем сложно поднять без костылей.
Точнее такое только на своих рещениях и вере в императора и поднимается, но докер в этом плане получился удобнее куба. На сервере запускаются контейнеры по конфигурационному файлу и давльше все на уровне кода уже.
Кубик хорош для централизованого кластера, когда разные контейнеры на разных серверах, но не более. Увы.
Может быть я не прав, было бы интересно услышать в чем именно. Работаю в основном с докером, кубер несколько раз пробовали и не то явно. От задачи зависит понятное дело, но в рамках малых виртуализаций (локально или иное) докер на коне. В рамках распределенного кластера и быстрой развертки докер так же на коне.
Просто ваше приложение ещё не вышло на такой уровень сложности вероятно, когда требуется более сложная логика управления контейнерами. Вроде автоскейлинга по какой-нибудь определенной метрики у приложения. Или логики размещения подов на нодах, чтобы например инстансы приложения не попадали на одну ноду для отказоустойчивости, ну или каким-то приложениям необходимо наличие видеокарты на хосте и прочего. Ну и сервис дискаверинг тот же. Придется какой-нибудь consul прикручивать. Я тоже считаю, что кубер сильно переусложнили в погоне за универсальностью и нужно внедрять его когда он нужен, и ты четко понимаешь плюсы и минусы. А не гнаться за модой и хайпом.
уже есть оператор куба на питоне) и кажется не один(
А вот если вы запилили оверлейную сеть, service discovery, что-напоминающее оператор кубера на питоне и т.д. - тогда уже можно задумываться об оркестраторе
…то уже немного поздно задумываться об оркестраторе
Корректно сравнивать не с докером, а с оркестраторами - docker compose, docker swarm, Nomad, AWS ECS.
А caddy это что если не ингресс ?
Такой же прокси
А что за оператор нужен для helm ?
С 3 версии он работает как и нативный kubectl ничего лишнего не нужно
И как то все пришли к тому что это стандартный пакетный менеджер для куба а вам не нравиться
Повторять все в компоузе тоже не очень практика
Ту же стратегию апдецтов не протестить
Хелс пробы тоже у докера конечно тоже есть но это далеко не то же самое
А если есть интеграция с внешними сервисами то вообще досвидос ( какой нибудь vault и инжект сикретов)
Да и как раз хельм и ямл одинаковый и там и там и косяк можно словить заранее
А caddy это что если не ингресс? Такой же прокси
Я так понял, они конфигурируют его "родными" файлами конфигурации, и не используют для этого ingress ресурсы в кубе.
И как то все пришли к тому что это стандартный пакетный менеджер для куба а вам не нравиться
Возможно, это как-то связано с "качеством" сторонних пакетов. Или же задача написания качественных пакетов не имеет решения вовсе...
Руководство по Kubernetes для хейтеров Kubernetes