Комментарии 5
Вот тут ещё было много критики, одобренной в нашем корпоративном чатике… Мы и сами думали написать что-то подобное:
(И в комментариях к той статье обозначенная проблема звучала, кстати.)
Так или иначе — вы уже поспособствовали, и у нас теперь есть ещё один повод. Спасибо, а вы там держитесь… хотя бы за соломинку! :-)
(И в комментариях к той статье обозначенная проблема звучала, кстати.)
Так или иначе — вы уже поспособствовали, и у нас теперь есть ещё один повод. Спасибо, а вы там держитесь… хотя бы за соломинку! :-)
> UPGRADE FAILED: «foo» has no deployed releases
Хорошая статья. Хорошо, что не прочитал раньше, а то бы отказался от этой идеи :D
Я уже наступил на половину граблей из той статьи. Там конечно сказано, что в Helm совсем никакой пользы, но на самом деле она есть. Он убрал ряд бессмысленных вещей, которые приходилось постоянно делать. Самое главное в нём то, что он создаёт пакет из мелких частей и таки позволяет ограниченно темплейтить (хотя Go Templates — то ещё извращение) Я также поддерживаю идею, что Tiller сам по себе бесполезен (хотя неплохо видеть список релизов, а не отдельных ресурсов K8s). От идеи создавать мега-Chart с dependencies всех зависимых проектов я отказался сразу, на этапе Proof of Concept. Слишком уж много подозрительного. Но если не делать гигантские пакеты — то вроде ничего так. А вот то, что в статье указано, что иногда не обновляются лимиты для ресурсов — это печалит, так как это был следующий запланированный этап развития наших Chart. Предупрежу коллег.
Хорошая статья. Хорошо, что не прочитал раньше, а то бы отказался от этой идеи :D
Я уже наступил на половину граблей из той статьи. Там конечно сказано, что в Helm совсем никакой пользы, но на самом деле она есть. Он убрал ряд бессмысленных вещей, которые приходилось постоянно делать. Самое главное в нём то, что он создаёт пакет из мелких частей и таки позволяет ограниченно темплейтить (хотя Go Templates — то ещё извращение) Я также поддерживаю идею, что Tiller сам по себе бесполезен (хотя неплохо видеть список релизов, а не отдельных ресурсов K8s). От идеи создавать мега-Chart с dependencies всех зависимых проектов я отказался сразу, на этапе Proof of Concept. Слишком уж много подозрительного. Но если не делать гигантские пакеты — то вроде ничего так. А вот то, что в статье указано, что иногда не обновляются лимиты для ресурсов — это печалит, так как это был следующий запланированный этап развития наших Chart. Предупрежу коллег.
Очень понравился слог. Прям как у Тургенева. Но Куб далеко не Ася…
+
+
А по моему очевидно, что если вы деплоитесь хелмом, то не стоит лезть туда руками, ну и наоборот.
Это как поставить в дебиан пакет из убунту через dpkg, а потом негодовать, что apt-get сломался.
И да, и нет. Не совсем очевидно, если вы привыкли пользовать kubectl apply. Всё-таки Kubernetes — система немного отличающаяся от просто операционки. Механизм гарантирует применение отличий и за всё время использования я ни разу не сталкивался с какими-то неожиданными эффектами. И именно поэтому поведение Helm вызывает удивление.
Имея встроенный механизм в Kubernetes, разработчики не стали его использовать.
С точки зрения разработки Helm, мне лично не кажется хорошей идеей _запретить_ людям пользоваться kubectl. Очевидно, что существует вагон и тележка случаев, для которых Helm не проектировался. Но установка конкретной версии конфигурации должна гарантировать, что она вся будет применена, а не только какие-то куски, которые отличаются от предыдущей.
Да и с пакетом дебиан в убунту параллель не совсем удачная. Тут скорее иное: если вы ставите Nginx 1.15, затем редактируете какой-то его файл (не конфигурацию, а именно файл пакета), а затем снова ставите Nginx 1.16 (да или даже 1.15 заново), то врядли вы ожидаете, что apt-get оставит ваш файл нетронутым, верно? Особенно если он именно отчитывается, что поставил и перезапустил пакет, а не просто «эта версия уже установлена».
Имея встроенный механизм в Kubernetes, разработчики не стали его использовать.
С точки зрения разработки Helm, мне лично не кажется хорошей идеей _запретить_ людям пользоваться kubectl. Очевидно, что существует вагон и тележка случаев, для которых Helm не проектировался. Но установка конкретной версии конфигурации должна гарантировать, что она вся будет применена, а не только какие-то куски, которые отличаются от предыдущей.
Да и с пакетом дебиан в убунту параллель не совсем удачная. Тут скорее иное: если вы ставите Nginx 1.15, затем редактируете какой-то его файл (не конфигурацию, а именно файл пакета), а затем снова ставите Nginx 1.16 (да или даже 1.15 заново), то врядли вы ожидаете, что apt-get оставит ваш файл нетронутым, верно? Особенно если он именно отчитывается, что поставил и перезапустил пакет, а не просто «эта версия уже установлена».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как попасть в Hell из-за Helm, но ухватиться за соломинку