<p>helm upgrade - установка больше не работает</p>

Я думал, что испытываю ту же проблему, но оказалось, что у меня просто было старое удаление (но не очищенное), релиз зависает. проверьте список helm -a, и, если ваш выпуск есть, helm delete --purge releasename. helm upgrade -i у меня успешно работает над 2.7.2.

Это побочный эффект устранения проблем, связанных с обновлением выпусков, которые были в плохом состоянии. https://github.com/kubernetes/helm/pull/3097 был PR, который исправил эту проблему. Есть ли здесь крайний случай, который нам не удалось уловить?

Отметьте helm list -a как упоминалось в @tcolgate , возможно, также объяснив, как воспроизвести, также было бы полезно определить, является ли это неперехваченным пограничным случаем или ошибкой.

Также есть та же проблема, а также повторяющиеся названия выпусков:

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

Какое сообщение отображалось при обновлении?

та же ошибка, что и в приведенном выше различии, но при установке будет сказано, что она уже установлена.

Я имею в виду предыдущие попытки обновления, которые заканчивались статусом FAILED. Я хочу знать, как мы попадаем в ситуацию, когда все выпуски находятся в неисправном состоянии.

Ох, дублирующиеся развертывания имени выпуска? В этом я не уверен, но получаю это довольно часто. Иногда все они находятся в состоянии РАЗВЕРТЫВАНИЕ, иногда - в состоянии ОТКАЗАНО и РАЗВЕРТЫВАЕТСЯ. Мы используем сервер Jenkins CI / CD, который постоянно обновляет каждое слияние PR, поэтому мы делаем несколько helm upgrade день, обычно имея только новый тег контейнера. Обычно дубликаты просто раздражают, глядя на то, что развернуто, это был первый раз, когда у нас возникла серьезная проблема с ними, и обычно мы не обновляем контроллер входящего трафика, как в этом случае.

У меня вроде получилось что-то похожее, я вижу несколько дубликатов в своих списках релизов:

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

Кажется, что все они находятся в РАЗВЕРТАННОМ состоянии, но вполне может быть, что предыдущее обновление в какой-то момент не удалось, так как я несколько раз сталкивался с этой ошибкой. Я все еще использую K8S 1.7, поэтому еще не обновился до Helm 2.7.

Та же проблема, невозможно выполнить обновление после неудачного развертывания

То же самое здесь с использованием 2.7.2. Первая попытка выпуска не удалась. Затем, когда я попробовал выполнить обновление --install, у меня возникла ошибка «Ошибка: ОБНОВЛЕНИЕ НЕ выполнено:« $ {RELEASE} »не имеет развернутых выпусков».

Та же проблема здесь с 2.7.2, helm upgrade --install не работает с:

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

Если выпуск полностью очищен с помощью helm del --purge APPNAME то последующий upgrade --install работает нормально.

У меня такая же проблема. В сочетании с # 3134, который не оставляет возможности для автоматического развертывания идемпотентов без сценариев обходного пути.

@winjer просто попытался удалить с помощью --purge, и для меня это не сработало, хотя ошибка изменилась
/ # обновление руля foo / charts / foo / -i --wait
Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: "foo" не имеет развернутых выпусков
/ # helm delete --purge foo
выпуск "foo" удален
/ # обновление руля foo / charts / foo / -i --wait
Релиз "foo" не существует. Устанавливаю сейчас.
Ошибка: не удалось освободить foo: deployments.extensions "foo-foo-some-service-name" уже существует

@prein Это связано с тем, что у вас есть служба, которая не является «владельцем» по рулю, но уже существует в кластере. Мне кажется правильным ваше поведение. Развертывание не может быть успешным, потому что helm должен «стать владельцем» объекта API, которым он раньше не владел.

Имеет смысл иметь возможность обновить FAILED-выпуск, если новый манифест действительно правильный и не соответствует каким-либо другим ресурсам в кластере.

Я также наблюдаю такое поведение в версии под названием content :

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

Мне придется удалить это, чтобы продолжить развертывание, дайте мне знать, если я могу что-нибудь сделать, чтобы помочь отладить это.
(Думаю, нам стоит переименовать проблему, так как она больше касается дубликатов?)
(мы также запускаем 2.7.2 )

На самом деле у меня есть еще один дублирующий выпуск в моем кластере, есть ли у меня какая-нибудь команда, которую я могу запустить, чтобы помочь отладить ее? Дай мне знать!

только что обновился до tiller 2.7.2, и мы наблюдаем то же самое. helm delete RELEASE_NAME за которым следует helm upgrade RELEASE_NAME . терпит неудачу с Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade - это предполагаемый способ восстановления удаленной (но не очищенной) версии, верно?

Похоже, вы можете восстановить выпуск, откатившись к удаленной версии.

наблюдая ту же проблему с v2.7.2 , происходит сбой, если нет предыдущих успешно развернутых выпусков

Также наблюдаются две возможные версии этой проблемы:

в CI:

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

на моей локальной машине:

(как на моем OSX bash, так и в контейнере gcloud / kubectl)

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

Предупреждения нормальны для нашего графика.
Ошибки интересны, потому что в одной из наших поддиаграмм есть pvc.yaml .

helm del --purge <release> действительно смягчает проблему.
Это действительно затрудняет обновление нашего конвейера CI.

@adamreese каково окончательное решение этой проблемы? У нас версия 2.8, и мы по-прежнему не можем обновить предыдущую версию FAILED с изменением на helm list .

В частности, мы сталкиваемся со следующим типом проблем:

• развернуть релиз, хорошо
• upgrade --install --wait , но, возможно, есть небольшая ошибка, и --wait не удается (например, зонды живучести никогда не исправляют ее)
• после исправления диаграммы upgrade --install --wait не работает с xxx has no deployed releases

Удаление / очистка здесь нежелательны или приемлемы: в выпуске может быть несколько ресурсов (подов, балансировщиков нагрузки), на которые не влияет один ресурс, который не будет увеличиваться. В предыдущих версиях Helm upgrade --install позволяло нам исправлять только то изменение, которое нарушило полную версию, без необходимости удаления всех ресурсов.

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

@peay см. # 3353 для дальнейшего обсуждения.

Спасибо - это проясняет. На самом деле мы поняли, что достигаем этого только тогда, когда у нас не было успешного релиза с самого начала. В этом случае чистка - прекрасное решение.

Это все еще происходит, если установка не удалась.
Вам нужно очистить и попробовать еще раз.

UPGRADE FAILED: "API" has no deployed releases
тогда вам нужно вручную очистить
helm delete --purge API
и это будет работать.

Начиная с Helm 2.9 вы также можете выполнить helm upgrade --install --force поэтому нет необходимости в очистке. Для предыдущих выпусков:

helm delete API
helm install --replace --name API ./mychart

@bacongobbler Я до сих пор не понимаю этого поведения.
Сможете ли вы ответить https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932, когда у вас будет время?

Спасибо за вашу работу над этим.

Конечно. Я сейчас увлечен, но могу ответить сегодня вечером. Полностью осознайте путаницу, и я постараюсь ответить на ваши вопросы как можно лучше. Это просто безумие в офисе, готовящем другие вещи для KubeCon EU. :)

Я готов помочь разобраться в этом и / или улучшить документы, когда мы будем там.
Давай обязательно встретимся: +1:

@bacongobbler использует этот адрес # 3353 и отменяет кучу кода, который я написал как часть # 4004?

В моем случае helm upgrade --install --force выполнил delete --purge и после этого установил.

Это ожидаемое поведение? Я почти потерял 2 месяца работы из-за этого. Когда force стало означать delete ?

^ Я поговорил с ребятами из kubecon и обнаружил, что довольно много команд привязано к версии 2.7.0 из-за этого изменения поведения.

Я согласен с тем, что upgrade install никогда не должно быть разрушительным, даже с тем, что --force может означать.

@bacongobbler , извини, я не смог встретиться, когда мы были в CPH.
Есть ли документация по обоснованию изменения поведения, чтобы не допустить обновления неудавшейся версии?
Старое поведение кажется намного более желательным, чем то, что мы имеем сейчас.

См. Второй комментарий в https://github.com/kubernetes/helm/issues/3353 для

Мне действительно любопытно услышать, каков будет предложенный путь в будущем. Мы не можем отказаться от # 3097 из-за проблем, продемонстрированных в # 3353, поэтому я хотел бы услышать, что сообщество считает правильным путем для решения этой проблемы. Мы можем отказаться от # 3597, но, насколько я слышал, нет хорошего решения для решения проблемы helm upgrade --install . :разочарованный:

Я знаю, что мы работаем над переработкой логики применения для Helm 3, но это долгий путь

Спасибо за ссылку на этот
Ваше предложение здесь звучит как разумный подход:

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

Это позволит нам отказаться от # 3597, поскольку будет решен единственный случай сбоя (нечего сравнивать).
Это снова делает upgrade --install неразрушающим и более похожим на kubectl apply .

Интуитивно это именно то, что я ожидал от upgrade --force : не выполняйте операции сравнения и исправления, а просто применяйте полный шаблон, игнорируя то, что есть в данный момент. Я не могу придумать никаких технических причин, по которым это было бы невозможно, но я также не знаком с внутренним устройством Helm.
Это все еще может быть опасной операцией, но любой, кто использует флаг --force обычно ожидает определенного риска, форсируя обновления. Хотя я бы сказал, что никто не ожидает, что это приведет к удалению и воссозданию вашего развертывания с возможным временем простоя.

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

В текущей стабильной версии, как я могу добиться этого с помощью автоматизированного сценария? Мне нужно иметь возможность развертывать в неинтерактивном режиме без использования delete --purge , даже если предыдущая попытка не удалась.

Что касается планов на будущее, я изначально ожидал именно такого поведения от upgrade --install :

• Установить, если предыдущие установки не производились
• Обновите ранее успешную установку
• Заменить ранее неудачную установку
• Если установка не удалась, старые ресурсы все еще должны быть на месте, без простоев, где это возможно.
• Никаких деструктивных операций (таких как автоматический delete --purge упомянутый выше)

По моему личному мнению, для такого поведения не требуется дополнительных флагов. Так обычно ведут себя менеджеры пакетов. Если я не неправильно понял требования, я не думаю, что, например, флаг --force необходим.

Были ли обновления по этому поводу? Как правильно запустить обновление существующей установки без необходимости выполнять очистку в случае сбоя?

@MythicManiac FWIW:
Из-за такого поведения наши команды до сих пор привязаны к версии 2.7.0.
Похоже, у нас нет проблем с обновлением и удалением ресурсов, когда они должны использовать helm upgrade --install с этой версией.

У нас тоже есть эта проблема. Очень неприятно, что мне нужно удалить сервисы K8s и связанные с ними AWS ELB, потому что helm has no deployed releases . Менеджер пакетов хорош, но эта проблема приводит к простоям в производстве, что нехорошо.

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

Пт, 5.10.2018, 18:13 Евгений Глотов, [email protected] написал:

У нас тоже есть эта проблема. Очень обидно, что мне нужно удалить K8s
сервисов и связанных с ними AWS ELB, потому что у helm нет развернутых выпусков. В
менеджер пакетов хорош, но эта проблема приводит к простою производства, что
не хорошо.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/helm/helm/issues/3208#issuecomment-427436187 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , спасибо! Я только что исправил другую проблему (https://github.com/helm/helm/issues/2426#issuecomment-427388715) с помощью вашего обходного пути и попытаюсь протестировать его на наличие существующих ELB, когда на следующей неделе я разверну новую диаграмму поверх существующих ресурсов. .

Выполнение отката к исходной неудавшейся версии может сработать.

@tcolgate , я только что тестировал и нет, в случае первого

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

Мне любопытно, если Helm не может развернуть диаграмму поверх существующих ресурсов, тогда почему helm delete вызывает удаление именно этих ресурсов?

@ thomastaylor312 , мы столкнулись с этой проблемой ~, а также с https://github.com/helm/helm/issues/2426~ (вверху: я нашел настоящую основную причину для 2426) с helm 2.11.0. Как вы думаете, их нужно открывать заново?

Я нашел эту тему после Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Пока это было видно из руля ls -a.

Я решил проверить, не возникла ли проблема из-за неправильного значения --set, а --debug --dry-run --force на самом деле ВСЕ ЕЩЕ удалил мой работающий модуль ... я ожидал, что действие пробного запуска НИКОГДА не изменит ресурсы кластера.

Тем не менее, это сработало, и впоследствии сервис можно было повторно развернуть, но мы столкнулись с простоями.

Я ожидал, что пробный запуск НИКОГДА не изменит ресурсы кластера.

Это справедливое ожидание - мы должны сделать так, чтобы этого ... не произошло

Я считаю, что это было исправлено на https://github.com/helm/helm/pull/4402, но было бы неплохо, если бы кто-то проверил. Извини за это!

та же проблема после обновления до 2.11.0

Перекрестная публикация:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

Почему это закрыто? Есть ли у нас правильный способ справиться с этим сейчас?

@gerbsen , в текущих версиях Helm нет способа
Мы по-прежнему используем Helm 2.7.0 для всего в моей организации. Это очень старая версия, в которой есть другие ошибки, но в ней нет этой проблемы.

Только что helm upgrade --install --force сделал delete --purge и уничтожил мой ПВХ / ПВХ, не сказав мне (о переработке). У него было несколько неудачных выпусков, поэтому он был в состоянии, когда он работал в кубернетах, но helm подумал, что запущенных выпусков нет. Совсем не хорошие времена.

@notque после потери всей панели инструментов Grafana дважды Я начал делать резервные копии, прежде чем делать какие-либо обновления, такой риск устраняет все преимущества использования helm

Для тех, кто ищет помощи, проблема исчезла после обновления helm до v.2.15.2.

По-прежнему наблюдается эта проблема на 2.16.0

Почему он до сих пор закрыт? 2.16.1 все еще затронут

@ nick4fake Я думаю, это дубликат https://github.com/helm/helm/issues/5595