Helm: `helm upgrade --install` не выполняет установку / обновление, если первая установка не удалась

Это было сделано намеренно по адресу https://github.com/kubernetes/helm/pull/3097. По сути, сравнение с неудачным развертыванием вызывало нежелательное поведение, в первую очередь этот длинный список ошибок:

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

Если ваш первоначальный выпуск завершился неудачно, мы рекомендуем очистить выпуск с помощью helm delete --purge foo и повторить попытку. После успешного начального выпуска все последующие неудачные выпуски будут проигнорированы, и helm выполнит сравнение с последним известным успешным выпуском.

Теперь, как уже было сказано, может быть полезно не выполнять сравнение, если не было развернуто ни одного успешного выпуска. Опыт будет таким же, как если бы пользователь запустил helm install в первый раз, в том смысле, что не будет «текущей» версии, с которой можно было бы сравнивать. Хотя я был бы немного обеспокоен некоторыми крайними случаями. @adamreese, у тебя есть какие-нибудь мнения по этому

Предлагаемое исправление кажется совершенно неприемлемым в автоматизированной системе. Я определенно не хочу, чтобы все, вызывающие helm, знали о том, что «если первая версия не удалась, удалите и повторите попытку». Во-первых, большая часть моих инструментов не знает, установка это или обновление, а если это первый или сотый раз, почти всегда просто выполняется helm upgrade --install .

Я также хотел бы отметить, что я прокомментировал исходный PR https://github.com/kubernetes/helm/pull/3097#discussion_r151808599, спрашивая конкретно об этом случае.

Старое поведение было лучше для этого случая.
Я согласен с @chancez. Это делает upgrade --install неидемпотентным в общем случае.

@bacongobbler
Если нас беспокоит сбой выпусков и выход осколков из-за неисправных крюков, я бы сказал, что это проблема дизайна диаграммы. (Крючки работают лучше, когда они идемпотентны)
Пользователи могут создавать для helm обработку ошибок и неидемпотентное поведение.

Какие еще крайние случаи нас беспокоят?
Кажется, # 3097 заботится о многом 👍

Моя локальная разработка прошла бы намного более гладко, если бы я мог сделать helm upgrade -i идемпотентным даже против неудачных выпусков хотя бы по некоторой комбинации аргументов. Мой вариант использования - это когда у меня есть сценарий многих выпусков, которые я знаю, что хочу встать, чтобы начать локальную среду разработки.

Это может быть аналогично флагу --replace для helm install . Обратите внимание, что --replace - это один из двух флагов из helm install которые отсутствуют в helm upgrade , а другой - --name-template .

Чтобы быть абсолютно ясным, да, это было бы хорошо исправить. Кто-нибудь хочет попробовать, пока мы заняты другой работой?

Привет,
Я создал PR https://github.com/kubernetes/helm/pull/3437, который должен исправить эту проблему.

Я не уверен, зачем нам нужны команды install и upgrade , я всегда использую только команду upgrade --install и похоже, что многие люди делают то же самое. Мне просто нужна одна команда, которая выполняет upgrade --install и не срабатывает при неудачном запуске. Можем ли мы просто переименовать upgrade --install в deploy , сделать его действительно идемпотентным и отказаться от двух других?

(Я борюсь с новым вариантом этого проблемного поведения в 2.8.0. После обновления с 2.7.2 сейчас, если у меня была неудачная установка, а затем delete --purge it и upgrade --install it , Я все еще могу получить ошибку Error: UPGRADE FAILED: "xyz" has no deployed releases . Похоже, что --purge не работает в полной мере в 2.8.0, и у tiller какое-то состояние зависания, которое не отображается в list --all . Мне нужно затем к install чтобы вернуть культиватор в состояние, при котором я снова могу сделать обычный upgrade --install .)

Я согласен с @whereisaaron , мне было бы неплохо, если бы команда deploy работала больше как kubectl apply . Делает автоматизацию Helm намного проще, так как вам не нужно проверять выпуски, существующие в каком-то безумии сценариев оболочки :)

Возможно, решение состоит в том, чтобы Helm автоматически запускал helm delete --purge ?
Что-то типа:
1) Пользователь выполняет helm upgrade --install
2) Первая версия не удалась
3) Пользователь вносит некоторые изменения в диаграмму и снова выполняет helm upgrade --install
4) Helm пытается запустить команду
5) Он не работает, и есть только один предыдущий выпуск в состоянии сбоя.
6) Helm незаметно выполняет helm delete --purge
6) После очистки Helm автоматически повторяет helm upgrade --install и показывает результат

Возможно, это поведение может быть вызвано флагом --force который уже имеет аналогичное поведение для других сценариев.

Хорошая идея, но я не думаю, что мы должны когда-либо удалять книгу релизов без явного запроса пользователя на удаление этих данных. Операторы Helm захотят узнать, почему сервис не удалось обновить с ранее неудачных выпусков, или выявить сбои, собирая эти данные из бухгалтерской книги.

Ранее в ветке я дал

@rchernobelskiy случается и со мной. Точно так, как вы описываете.

Я сталкиваюсь с этой проблемой, возможно, раз в день при развертывании новых приложений.
Какая боль!

@gmanolache По этой причине мы все еще используем Helm 2.7.0.
Мне неясно, безопасно ли обновление до использования флага --force : комментарий

Если вам нужно перейти на более раннюю версию , вот хороший способ сделать это:

Что это за полезная диагностическая информация «рулевой книги» и как к ней добраться? :улыбка:

Я беспокоюсь, что приведенное ниже может быть прочитано как угрюмое, это действительно просто приглашение для указателей о том, как мы можем получить диагностическую информацию, когда у вас не удалось развернуть. Потому что это действительно похоже на то, что я чего-то упускаю. Похоже, что состояние сбоя должно иметь какую-то полезность для операторов? Я снова пролистал сайт с инструкциями по управлению штурвалом; будет ли что-то вроде 'helm get manifest' работать в состоянии сбоя для извлечения полезной диагностической информации?

В моем пользовательском опыте, когда я получаю неудачное развертывание, вы не получаете никакой полезной информации. Хелм отключает все частично созданные / оставшиеся ресурсы, так что в «статусе руля» ничего не отображается. Все, что вы можете сделать, это «откатить» или «удалить - очистить» (вы не можете просто «удалить», иначе ваш CI «upgrade --install» будет терпеть неудачу). Состояние сбоя только кажется, что служит нарушению идемпотентности «обновление - установка», которую мы все жаждем для наших развертываний CI.

Было бы разумно иметь параметр --auto-rollback для ситуаций CI, например, «upgrade --install --auto-rollback». Я обычно предпочитаю откат назад, когда мне нужно встать с постели, чтобы справиться с неудавшимся состоянием 😆 😴 💤

Что это за полезная диагностическая информация «рулевой книги» и как к ней добраться? 😄

helm help history

Спасибо @bacongobbler. Хорошо, я понимаю, что под реестром подразумевается этот список. И если у вас все еще есть бухгалтерская книга, вы можете использовать helm get manifest --revision 123 чтобы увидеть, что было развернуто, что не удалось? Это, безусловно, полезно сохранить. И если мы rollback мы не потеряем эту информацию.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

Если бы у нас было helm upgrade --install --auto-rollback то и неудачное развертывание, и откат были бы записаны в бухгалтерскую книгу и доступны операторам. И это будет иметь большое значение для предотвращения перехода развертываний CI в неразрешимое состояние «сбой», когда «helm upgrade --install» перестает работать. Неудачные развертывания CI обычно возникают из-за того, что разработчики вводят опечатки / ошибки в систему развертывания. С помощью '--auto-rollback' они могут проверить сообщение об ошибке команды helm сохраненное в журнале сервера развертывания, исправить и развернуть исправленные значения.

Я предполагаю, что даже без параметра --auto-rollback мы могли бы использовать автоматическую оболочку для запуска helm rollback любое время, когда helm update --install возвращает ошибку «FAILED». И, возможно, определить, где это первоначальная установка, и вместо этого helm delete --purge .

То есть мы могли бы создать сценарий оболочки, чтобы гарантировать, что результат CI 'helm upgrade --install' всегда будет состоять в том, что следующий CI 'helm upgrade --install' всегда будет возможен. Сохраняя информацию из бухгалтерской книги для любых неудачных попыток (по крайней мере, для выпусков, первоначальная установка которых сработала).

helm deploy =

• helm upgrade --install
• если FAIL, то
  
  
  
  • если ревизия = 1
  
  
  • затем helm delete --purge
  
  
  • еще helm rollback
  
  

@whereisaaron, это было бы элегантно 👍

Есть ли простой способ получить последний рабочий выпуск, отличный от helm history ${name} | tail -2 | head -1 | awk '{print $1}' , который будет использоваться helm rollback ?

Привет,

Я использую Helm 2.12.2, но проблема в том, что он не работает, когда первое развертывание не удается. Может быть, это регресс?

Я не уверен, что это регресс, но на самом деле он никогда не был «исправлен».

@ RickS-C137 Я думаю, это должно быть исправлено с помощью helm upgrade --install --force который «удалит», а затем «установит - заменит» неудачный выпуск.

Я все еще пытаюсь исправить эту проблему в конвейере Jenkins, который я пытаюсь использовать.
Я пытаюсь развернуть новый образ своего приложения, и мне все равно, существует ли развертывание уже или нет.
Я хочу запустить одну команду, которая либо заменяет текущее развертывание, либо просто устанавливает его, если оно не существует.
Я пробовал helm install --replace Я часто получаю Error: a released named xyz is in use, cannot re-use a name that is still in use что, очевидно, убивает мой конвейер, и сборка завершается ошибкой.

@bacongobbler Что вы думаете о https://github.com/helm/helm/issues/3353#issuecomment -385222233?

Я не понимаю, как возникнут простои или потеря данных, если мы уничтожим и воссоздадим первоначальный выпуск, если начальный выпуск не удастся.

Я реализовал это в нашей сборке:

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

Имея в настоящее время helm, вы не знаете, какую комбинацию команды helm + параметры использовать, не проверив текущее состояние. И для данной команды руля вы не знаете, что получите, потому что это зависит от текущего состояния. Это не совсем декларативная мечта о желаемом состоянии ☁️ 💤 😄

В Helm 3 мы потенциально можем отказаться от install / upgrade / --replace / --upgrade / --force и заменить их все идемпотентом helm deploy который либо достигает желаемого состояния, либо оставляет состояние без изменений. Возможно, используя алгоритм, аналогичный приведенному выше , который в случае сбоя helm deploy откатывается (версия> 1) или удаляет + чистки (версия = 1), чтобы оставить состояние, как было раньше. Неудачный манифест по-прежнему будет доступен через helm history/get . И может быть даже опция --no-rollback для людей, которые хотят сохранить развертывание в состоянии сбоя для расследования.

Вариант helm upgrade --install --force приближается, за исключением того, что вместо отката и обновления он удаляет и заменяет неудавшиеся выпуски (даже для ревизий> 1), что многих злит на # 3208 ... 😮 ⚡️ 💥

На данный момент мы можем использовать сценарии-оболочки или мета-инструменты, такие как helmsman , список функций которых частично предназначен для использования helm но для смягчения этой проблемы:

• Идемпотентность : пока желаемый файл состояния не изменяется, вы можете выполнить Helmsman несколько раз и получить тот же результат. _ [... независимо от текущего состояния] _
• Продолжить после сбоев : в случае частичного развертывания из-за определенного сбоя развертывания диаграммы исправьте диаграмму управления и снова выполните Helmsman без необходимости сначала откатывать частичные успехи.

замените их все развертыванием идемпотентного шлема, который либо достигает желаемого состояния, либо оставляет состояние без изменений

Оглядываясь назад, можно сказать, что это поразительно очевидная цель дизайна.

Привет,
В нашем случае первоначальный выпуск не был действительно неудачным ... Просто либо наше приложение не было полностью запущено по истечении времени ожидания установки, либо была исправлена ​​какая-то другая странная проблема. В любом случае приложение работает отлично, и поэтому необходимость его удаления будет для нас проблемой (у нас есть подключенное постоянное хранилище, которое также будет удалено !!).

Есть ли обходной путь для развертывания диаграммы, когда первоначальная версия «явно не удалась», но на самом деле все в порядке?

Итак, вывод о том, что upgrade --force слишком силен, т.е. бывают случаи, когда удаление + замена + retry_upgrade не является правильным средством от неудачного обновления?

Есть ли отдельная проблема, отслеживающая идею объединения install & upgrade в команду deploy ?

Не то, чтобы я знал о @dcow. Каков вариант использования команды helm upgrade --install ?

https://github.com/helm/helm/issues/3353#issuecomment -362497951

Я не уверен, зачем нам нужны команды установки и обновления, я всегда использую только команду upgrade --install, и, похоже, многие люди делают то же самое. Мне просто нужна одна команда, которая выполняет обновление - установить и не срабатывает при неудачном запуске. Можем ли мы просто переименовать обновление - установить для развертывания, сделать его действительно идемпотентным и отказаться от двух других?
...

и

https://github.com/helm/helm/issues/3353#issuecomment -469109854

Имея в настоящее время helm, вы не знаете, какую комбинацию команды helm + параметры использовать, не проверив текущее состояние. И для данной команды руля вы не знаете, что получите, потому что это зависит от текущего состояния. Это не совсем декларативное желаемое облако мечты состояния zzz smile

В helm 3 мы потенциально можем отказаться от install / upgrade / --replace / --upgrade / --force и заменить их все идемпотентным развертыванием Helm, которое либо достигает желаемого состояния, либо оставляет состояние неизменным.
...

Я в целом согласен с тем, что helm должен работать как kubectl apply и пытаться достичь желаемой реальности, а не запускать разные типы команд в зависимости от состояния вашего кластера. Надеялся добавить поддержку для специальной проблемы, если она существует, или, по крайней мере, выяснить, каково было решение, поскольку deploy в настоящее время не реализовано, и мы находимся на руле 3.2.

@dcow Хорошо, вы хотите создать проблему со своим предложением?

@hickeyma готово https://github.com/helm/helm/issues/8415!