Полное удаление релиза из Helm с помощью helm delete release работает, но не является жизнеспособным решением.

Почему Helm не может просто перезаписать то, что установлено в данный момент? Разве мы не живем в декларативном мире с Kubernetes?

Получил то же самое ... совсем новое для меня, кажется, это новый выпуск. удалить ресурс исправит это.
v2.7.2 с Kubernetes 1.7.7.
довольно, это работало раньше ...

У меня была эта проблема - она ​​была связана с созданным мной PersistentVolume. Чтобы решить эту проблему, я удалил PV и PVC. Запустил helm upgrade XXX XXX и все

У меня возникло ощущение, что это может быть связано с плохим pv ... но тогда ошибка вводит в заблуждение!
также некоторые странные журналы от tiller ... кажется, что он работает над двумя версиями одновременно ...

просто попробовал с 2.7.1 безуспешно ...

[main] 2017.12.21 15:30:48 Запуск Tiller v2.7.1 (tls = false)
[главная] 2017/12/21 15:30:48 GRPC слушает: 44134
[главная] 2017/12/21 15:30:48 Зонды прослушивают: 44135
[главная] 2017/12/21 15:30:48 Драйвер хранилища - ConfigMap
[main] 2017/12/21 15:30:48 Максимальное количество историй на выпуск - 0
[tiller] 2017/12/21 15:30:55 готовится обновление для ххх
[хранилище] 2017/12/21 15:30:55 получение развернутой версии из истории "xxx"
[tiller] 2017/12/21 15:30:56 копирование значений из xxx (v65) в новую версию.
[хранение] 2017/12/21 15:30:56 получение последней ревизии "xxx"
[хранилище] 2017/12/21 15:30:56 получение истории выпусков для "xxx"
[tiller] 2017/12/21 15:30:59 рендеринг диаграммы helm-xxx с использованием значений
2017/12/21 15:30:59 информация: манифест "helm-xxx / templates / scheduler-deploy.yaml" пуст. Пропуская.
2017/12/21 15:30:59 информация: манифест "helm-xxx / templates / Recomposer-deploy.yaml" пуст. Пропуская.
2017/12/21 15:31:00 информация: манифест "helm-xxx / templates / Recomposer-pvc.yaml" пуст. Пропуская.
2017/12/21 15:31:00 информация: манифест "helm-xxx / templates / scheduler-pvc.yaml" пуст. Пропуская.
2017/12/21 15:31:00 информация: манифест "helm-xxx / templates / scheduler-secret.yaml" пуст. Пропуская.
2017/12/21 15:31:00 info: манифест "helm-xxx / templates / Recomposer-secret.yaml" пуст. Пропуская.
[tiller] 21.12.2017 15:31:09 создание обновленного релиза для xxx
[хранение] 21.12.2017 15:31:09 создание релиза "xxx.v80"
[tiller] 2017/12/21 15:31:09 выполнение обновления для xxx
[tiller] 21.12.2017 15:31:09 выполнение 0 обработчиков перед обновлением для xxx
[tiller] 2017/12/21 15:31:09 крючки завершены для предварительного обновления xxx
[tiller] 2017/12/21 15:31:11 готовится обновление для ххх
[хранилище] 2017/12/21 15:31:11 получение развернутой версии из истории "xxx"
[хранение] 2017/12/21 15:31:11 получение последней ревизии "xxx"
[хранилище] 2017/12/21 15:31:11 получение истории выпусков для "xxx"
[tiller] 2017/12/21 15:31:18 рендеринг диаграммы helm-xxx с использованием значений
2017/12/21 15:31:18 информация: манифест "helm-xxx / templates / scheduler-secret.yaml" пуст. Пропуская.
2017/12/21 15:31:18 информация: манифест "helm-xxx / templates / scheduler-pvc.yaml" пуст. Пропуская.
2017/12/21 15:31:19 информация: манифест "helm-xxx / templates / scheduler-deploy.yaml" пуст. Пропуская.
[kube] 2017/12/21 15:31:28 создание ресурсов из обновленного манифеста
[tiller] 2017/12/21 15:31:46 создание обновленного релиза для xxx
[хранилище] 2017/12/21 15:31:46 создание релиза "xxx.v81"
[tiller] 2017/12/21 15:31:47 выполнение обновления для xxx
[tiller] 21.12.2017 15:31:47 выполнение 0 обработчиков перед обновлением для xxx
[tiller] 2017/12/21 15:31:47 крючки завершены для предварительного обновления xxx
[kube] 2017/12/21 15:31:49 проверка 7 ресурсов на наличие изменений
[kube] 21.12.2017 15:31:49 Похоже, для секрета "xxx-helm-xxx-nginx-secret" изменений нет
[kube] 21.12.2017 15:31:50 Похоже, для секрета "xxx-application-secret" изменений нет
[kube] 21.12.2017 15:31:50 Похоже, для Секрета "лазурно-секретный" изменений нет
[kube] 21.12.2017 15:31:51 Похоже, для ConfigMap "xxx-helm-xxx-nginx-config" изменений нет
[kube] 21.12.2017 15:31:51 Похоже, для ConfigMap "xxx-application-config" изменений нет
[kube] 21.12.2017 15:31:51 Похоже, для службы "xxx-application-svc" изменений нет
[kube] 21.12.2017 15:31:51 Похоже, для StatefulSet "xxx-application" изменений нет
[tiller] 21.12.2017 15:31:51 выполнение 0 обработчиков после обновления для xxx
[tiller] 2017/12/21 15:31:51 крючки завершены для пост-апгрейда xxx
[хранение] 21.12.2017 15:31:51 обновление релиза "xxx.v65"
[tiller] 2017/12/21 15:31:51 обновление статуса обновленной версии для xxx
[хранение] 21.12.2017 15:31:51 обновление релиза "xxx.v80"
[kube] 2017/12/21 15:31:57 создание ресурсов из обновленного манифеста
[kube] 2017/12/21 15:32:10 проверка 11 ресурсов на наличие изменений
[kube] 21.12.2017 15:32:10 Похоже, для секрета "xxx-helm-xxx-nginx-secret" изменений нет
[tiller] 2017/12/21 15:32:10 предупреждение: обновление «xxx» не удалось: ресурс с именем «xxx-Recomposer-secret» не найден
[хранение] 21.12.2017 15:32:10 обновление релиза "xxx.v65"
[хранение] 21.12.2017 15:32:10 обновление релиза "xxx.v81"

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

просто повторно применил ту же конфигурацию дважды ...

[tiller] 2017/12/21 15:50:46 готовится обновление для ххх
[хранилище] 2017/12/21 15:50:46 получение развернутой версии из истории "xxx"
[хранение] 2017/12/21 15:50:46 получение последней ревизии "xxx"
[хранилище] 2017/12/21 15:50:46 получение истории выпусков для "xxx"
[tiller] 2017/12/21 15:50:50 рендеринг диаграммы helm-xxx с использованием значений
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / scheduler-pvc.yaml" пуст. Пропуская.
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / Recomposer-deploy.yaml" пуст. Пропуская.
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / scheduler-secret.yaml" пуст. Пропуская.
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / scheduler-deploy.yaml" пуст. Пропуская.
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / Recomposer-secret.yaml" пуст. Пропуская.
2017/12/21 15:50:50 информация: манифест "helm-xxx / templates / Recomposer-pvc.yaml" пуст. Пропуская.
[tiller] 2017/12/21 15:50:58 создание обновленного релиза для xxx
[хранилище] 21.12.2017 15:50:58 создание релиза "xxx.v85"
[tiller] 2017/12/21 15:50:59 выполнение обновления для xxx
[tiller] 2017/12/21 15:50:59 выполнение 0 обработчиков перед обновлением для xxx
[tiller] 2017/12/21 15:50:59 крючки завершены для предварительного обновления xxx
[kube] 2017/12/21 15:51:13 создание ресурсов из обновленного манифеста
[kube] 2017/12/21 15:51:22 проверка 7 ресурсов на наличие изменений
[kube] 21.12.2017 15:51:22 Похоже, для секрета "xxx-helm-xxx-nginx-secret" изменений нет
[kube] 21.12.2017 15:51:23 Похоже, для секрета "xxx-application-secret" изменений нет
[kube] 21.12.2017 15:51:23 Похоже, для Секрета "лазурно-секретный" изменений нет
[kube] 21.12.2017 15:51:23 Похоже, для ConfigMap "xxx-helm-xxx-nginx-config" изменений нет
[kube] 21.12.2017 15:51:23 Похоже, для ConfigMap "xxx-application-config" изменений нет
[kube] 21.12.2017 15:51:24 Похоже, для Сервиса "xxx-application-svc" изменений нет
[kube] 21.12.2017 15:51:24 Удаление "xxx-Recomposer-secret" в xxx ...
[kube] 21.12.2017 15:51:24 Не удалось удалить "xxx-recposer-secret", ошибка: секреты "xxx-Recomposer-secret" не найдены
[kube] 21.12.2017 15:51:24 Удаление "xxx-Recomposer-config" в xxx ...
[kube] 21.12.2017 15:51:24 Не удалось удалить «xxx-Recomposer-config», ошибка: configmaps «xxx-Recomposer-config» не найден
[kube] 21.12.2017 15:51:24 Удаление "xxx-Recomposer-pv" в ...
[kube] 21.12.2017 15:51:24 Не удалось удалить «xxx-Recomposer-pv», ошибка: постоянные тома «xxx-Recomposer-pv» не найдены
[kube] 21.12.2017 15:51:24 Удаление "xxx-Recomposer-pvc" в xxx ...
[kube] 21.12.2017, 15:51:24 Не удалось удалить "xxx-Recomposer-pvc", ошибка: persistentvolumeclaims "xxx-Recomposer-pvc" не найден
[kube] 21.12.2017 15:51:24 Удаление "xxx-Recomposer" в xxx ...
[kube] 21.12.2017 15:51:24 Использование reaper для удаления "xxx-Recomposer"
[kube] 21.12.2017 15:51:24 Не удалось удалить «xxx-Recomposer», ошибка: deployments.extensions «xxx-Recomposer» не найден
[tiller] 2017/12/21 15:51:24 выполнение 0 обработчиков после обновления для xxx
[tiller] 2017/12/21 15:51:24 крючки завершены для пост-апгрейда xxx
[хранение] 21.12.2017 15:51:24 обновление релиза "xxx.v68"
[tiller] 2017/12/21 15:51:24 обновление статуса обновленной версии для xxx
[хранение] 21.12.2017 15:51:24 обновление релиза "xxx.v85"
[хранение] 2017/12/21 15:51:25 получение последней ревизии "xxx"
[хранилище] 2017/12/21 15:51:25 получение истории выпусков для "xxx"
[kube] 2017/12/21 15:51:38 Получение секрета: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 21.12.2017 15:51:39 Выполнение get for Secret: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / Secret / xxx-application-secret
[kube] 21.12.2017 15:51:39 Делаем get for Secret: "лазурно-секретный"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / Secret / azure-secret
[kube] 21.12.2017 15:51:39 Выполнение get для ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 21.12.2017 15:51:39 Выполнение get для ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / ConfigMap / xxx-application-config
[kube] 21.12.2017 15:51:39 Получение услуги: "xxx-application-svc"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / Service / xxx-application-svc
[kube] 21.12.2017 15:51:39 Выполнение get для StatefulSet: "xxx-application"
[kube] 2017/12/21 15:51:39 получить модуль отношения объекта: xxx / StatefulSet / xxx-application

может быть связано с # 2941

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

Это все нормально и красиво. До тех пор, пока вам не придется удалить что-то критическое из производственного пространства имен. Что, по совпадению, случилось со мной только сейчас. : c

Я также столкнулся с проблемой, когда мы обновляем выпуск, если есть несколько состояний DEPLOYED этого выпуска, необходимо исправить это, удалив соответствующие файлы конфигурации.

Та же проблема. Вчера все было прекрасно, и я сделал несколько обновлений. Сегодня я только что добавил новый yaml с блоками service и deployment разделенными --- и обновление не удалось.

Интересно то , что helm создал service а затем пожаловался на это (и не выполнил развертывание).
Я закомментировал service и просто запустил обновление с блоком deployment - это сработало. Однако helm не удалил службу, которая должна была быть удалена из файла yaml.

Обновление : я вручную удалил service , раскомментировал его из yaml и запустил обновление - на этот раз оно сработало отлично!

У меня была именно эта ошибка. Похоже, проблема связана с шаблонами с несколькими объектами API, похожими на то, что видел @amritb . В моем случае у меня был шаблон с несколькими объектами API, которые можно было включать и выключать аналогично:

{{ if .Values.enabled }}
---
...

Разбив это на отдельный файл шаблона и очистив потерянные объекты, которые Helm создал и забыл, проблема для меня решена. Похоже, есть ошибка в том, как helm получает предыдущую конфигурацию, если количество объектов в шаблоне изменяется между выпусками.

Добавление еще одной точки данных: похоже, у меня такая же проблема, как и у @awwithro. Мы используем цикл jinja для создания нескольких заданий cron через шаблон, и когда новое обновление заставило этот цикл заполнить дополнительное задание cron, мы столкнулись с ошибкой. Похоже, сработал и # 2941 (или, возможно, одна ошибка вызывает другую), и удаление конфигурационных карт зомби исправляет это.

Просто попал в ловушку даже без использования каких-либо конфигурационных карт

Дополнительный цвет для тех, кто может застрять:
Я столкнулся с этим, когда вводил в свой выпуск новые поддиаграммы и объекты. Мне удалось решить эту проблему, проверив каждый добавляемый тип объекта и удалив все существующие объекты, которые могли вызвать конфликт имен.

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

Также встречается это = \

Мне также нужно было удалить затронутые ресурсы. Не подходит для производственной среды = _ (

Я вижу нечто похожее. Проблема заключается в том, что helm upgrade не имеет --reuse-values ​​из предыдущего развертывания. Если я укажу тот же набор значений в командной строке, что и при первоначальной установке, тогда helm upgrade работать. Не знаю, помогает ли это (или кто-то еще может это подтвердить).

Как и @amritb , после того, как я вручную удалил объект, на котором изначально

Та же проблема с использованием helm 2.8.0 . Версии Kubernetes client=v1.8.6 и server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

Но конфигурационная карта существует в $ kubectl get configmap . Если я вручную удалю карту конфигурации, она будет работать, но в следующий раз снова выйдет из строя.

Вот карта конфигурации:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Я удалил релиз и снова установил заново. Кроме того, я использовал версию api extensions/v1beta для развертывания, я перешел на apiVersion: apps/v1beta2 , я не знаю, помогло это или нет.
Также в настоящее время я использую локально tiller .

Прямо сейчас вроде все работает.

Это действительно легко воспроизвести, если в манифесте есть ошибка.

Как и у нас есть resource1 и resource2, resource2 зависит от первого. Когда мы обновляем выпуск, создается ресурс 1 (например, PV и PVC), но ресурс 2 не работает. После этого помогает только удаление ресурса1, поскольку helm всегда сообщает о проблеме при обновлении (PersistentVolume с именем ... не найден)

У нас была такая же проблема (ресурс, который нам достался, был Секретами). Удаление новых секретов и повторное развертывание исправили это.

Обратите внимание, что из-за сбоев у нас теперь есть 11 различных выпусков, когда мы делаем helm list , 10 ОТКАЗАННЫХ и 1 РАЗЛОЖЕННЫЙ. Этого не ожидали, правда? Та же проблема, что и здесь: https://github.com/kubernetes/helm/issues/2941

Это в значительной степени сделало helm непригодным для обычного производственного развертывания для нас :( В настоящее время мы изучаем такие вещи, как передача --dry-run в helm и подключение его к kubectl apply ... Поскольку это, похоже, затрагивает только часть пользователей , я не уверен, что мы делаем не так :(

После просмотра журналов tiller я обнаружил, что tiller одновременно пытался обновить старую версию:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

Удаление старой карты конфигурации для s2osf.v10 и последующее обновление сработали.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Имея ту же проблему, что и @binoculars :

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

Вызывает странные проблемы с UPGRADE FAILED: no Secret with the name "foobar" found .
Я даже попытался удалить этот секрет, который затем вызвал ошибки в некоторой карте конфигурации, и при 3-м запуске он снова пожаловался на предыдущий секрет.

Это могло произойти после обновления helm 2.7.x до 2.8.1.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

если ваше последнее средство - удалить старый выпуск, может быть менее разрушительная работа, как мой комментарий https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

в основном находя эту старую ревизию в журналах и вручную редактируя конфигурационную карту, где tiller хранит развернутый статус. Не должно быть двух ревизий со статусом DEPLOYED afaik.

Нашел новое решение этой проблемы.

kubectl -n kube-system edit cm name_of_your_release.v2 , где v2 - это номер последней версии, помеченный как FAILED в helm list . Вы также можете отредактировать один из РАЗЛОЖЕННЫХ выпусков и изменить статус на ЗАМЕНИТЫЙ, чтобы у нас не было двух развернутых выпусков одновременно.

@zuzzas это то, о чем я говорил. Работал и на меня

@balboah проблема в том, что у нас есть только одно развертывание в состоянии DEPLOYED, но если оно не из последних (которые в большинстве сценариев отмечены как FAILED), оно все равно строя . В большинстве наших случаев проблема не связана с наличием двух или более развертываний в состоянии DEPLOYED.

@zuzzas, у вас много релизов в одном пространстве имен или только один? Однажды у меня была проблема с двумя выпусками, обновляющими одни и те же объекты, тогда они будут конфликтовать друг с другом.

Если только один, сколько у вас сбоев до развернутой версии? как вы проверили, что развернут только один?

Мы считаем, что это было исправлено (в дальнейшем) с помощью # 3539. Пожалуйста, откройте снова, если мы ошиблись. :)

Спасибо всем за вашу работу!

Обратите внимание, что это не было исправлено для существующих диаграмм в этом состоянии; вам все равно нужно удалить старые выпуски, которые находятся в состоянии РАЗВЕРТЫВАЕТСЯ, чтобы все снова заработало. @balboah просто предотвратил случай, когда вы можете попасть в состояние «несколько выпусков, отмеченных как DEPLOYED». :)

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

У меня есть небольшая большая диаграмма управления с вложенными зависимостями; может это быть так?

Я наблюдаю ту же проблему с привязкой кластера. Я добавил новый ресурс в свою диаграмму, и upgrade а также upgrade --install завершатся ошибкой с Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

У меня та же проблема, что и у @ramyala, с ClusterRole. ClusterRole существует, но создание RoleBinding не удается из-за этой ошибки.

На Helm 2.9.1 я столкнулся с той же проблемой:

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

Пока я вижу эту ConfigMap на своем кластере.

У меня возникает эта проблема, если у меня есть несколько ресурсов с перехватчиками в одном файле.

+1, это снова происходит с 2.9.1. Пожалуйста, откройте снова.

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

@bacongobbler

Я тоже это вижу, когда пытаюсь развернуть новый Ingress в моей диаграмме управления. По общему признанию, я новичок в Ingress, но, судя по всем примерам, это правильно, и я уже пару месяцев занимаюсь другими вещами для helm / k8s.

Я уже развернул схему штурвала stable/nginx-ingress поэтому контроллер присутствует. Похоже, ошибка предполагает, что он пытается найти тот, который я пытаюсь создать. Вот команда, которую я выполняю:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm где deploy/helm содержит манифесты моей диаграммы.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

ОБНОВИТЬ
Я удалил /* с обоих моих путей, и он больше не выдавал ошибки при попытке обновления / установки. Может быть, это просто неверный синтаксис

Привет,
Вот шаги, которые привели к возникновению проблемы в моем окружении:

1. У меня несколько раз была развернута и обновлена ​​диаграмма управления штурвалом.
2. Создал новый объект CronJob на графике и снова обновился - задание cron было успешно создано.
3. Все последующие обновления завершаются неудачно с сообщением об ошибке «Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: не найдено ни одного CronJob с именем« cronjob-name »»

Я также вижу проблему, когда добавляю секрет, которого раньше не было. Я пробовал добавить "db-credentials"
секрет, который привел к:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

потенциально актуальное исправление: # 4146

если бы кто-нибудь, столкнувшийся с этой ошибкой, мог проверить этот PR и посмотреть, исправит ли он это, то мы сможем подтвердить, что это, вероятно, регресс в API k8s, и продолжить работу с этим исправлением. Спасибо!

Я не могу на 100% подтвердить, будет ли это всегда воспроизводиться, но я заметил, что это обычно происходит в следующей ситуации:

1. Я обновляю карту Helm, включая новый ресурс
2. Это обновление не удалось, но ресурс был создан как часть неудачного обновления.
3. Все последующие обновления терпят неудачу

Если я сделаю helm rollback до последнего успешного развертывания, а затем попытаюсь выполнить повторное обновление, похоже, это сработает.

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

1. Возьмите диаграмму и разверните ее (но опустите один ресурс, скажем, услугу)
2. Добавить пропущенный ресурс вручную (например, с помощью «kubectl create»), но с именем, соответствующим выпуску.
3. Добавьте пропущенный ресурс обратно в диаграмму, а затем попробуйте обновить его, helm должен сообщить «ОБНОВЛЕНИЕ НЕ выполнено: нет.с именемнашел"

Шаги разные, но основная причина все та же. Поправьте меня, если я ошибаюсь в своем предположении, но мне кажется, что в последней версии DEPLOYED релиза нет информации о конкретном ресурсе либо потому, что он был добавлен «вне» Helm (например, вручную), либо потому, что последнее обновление не удалось. на каком-то этапе (скажем, при обновлении неизменяемого задания), одновременно развертывая другие объекты и затем записывая их в FAILED ревизии (но по-прежнему без какого-либо трека в DEPLOYED ревизии, что ожидается, иначе это означало бы изменение истории) . При следующем запуске клиент kube Tiller видит ресурсы в кластере, то есть они должны быть уже развернуты и, таким образом, записаны, он проверяет последнюю DEPLOYED ревизию (кажется, что с FAILED ревизия не связывается вообще) и не видит их в списке. поэтому он сообщает об ошибке.

@bacongobbler Я тестировал # 4146 с пользовательским образом румпеля, и эта проблема была исправлена! Для тех, кто ищет решение, вы можете применить исправление проблемы к текущему мастеру и скомпилировать:

make bootstrap build docker-build

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

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

спасибо @ramyala за тестирование исправления! Я упомяну об этом завтра во время разговора с разработчиками и посмотрю, увидят ли другие разработчики ядра какие-либо крайние случаи, которые могут возникнуть с исправлением. Если нет, давайте объединимся.

Итак, я обнаружил несколько ошибок в # 4146, которые делают его нежелательным для продвижения вперед. Я сообщил о своих выводах между master, # 4146, и # 4223 здесь: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese и мне удалось идентифицировать основную ошибку, которая вызывает эту конкретную ошибку, и рассмотреть различные сценарии и крайние случаи с каждым из предложенных PR. Если бы кто-нибудь еще мог подтвердить мои выводы или найти другие крайние случаи, это было бы очень полезно!

Да, и кое-что, что я не упомянул: поскольку кластер находится в несогласованном состоянии, это можно легко обойти, вмешавшись вручную и удалив ресурс, о котором ошибка сообщает как «не найден». Следуя примеру, который я продемонстрировал в https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

В интересах сохранения целостности, я собираюсь закрыть это как дубликат № 1193, так как два билета идентичны. Пожалуйста, сообщайте здесь о любых обнаруженных результатах, чтобы мы все могли работать по единой заявке. Спасибо!

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

selector:
    app: {{ template "mything.name" . }}

к

selector:
    app: mything

Возможно, есть какая-то проблема с использованием переменной в этом контексте?

Попробуйте helm delete RELEASE_NAME --purge
и установите его снова.

Я тоже сталкиваюсь с этой проблемой. Я попытался добавить поддиаграмму с развертыванием в свою диаграмму, она преуспела при обновлении с помощью helm upgrade chart chart-1.0.1.tgz только в первый раз, после этого, когда я попробовал helm upgrade chart chart-1.0.1.tgz это не удалось с ошибкой Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

Журналы румпеля просто регистрируют ту же ошибку. Кто-нибудь тоже испытывает это?

Та же проблема. Вчера все было прекрасно, и я сделал несколько обновлений. Сегодня я только что добавил новый yaml с блоками service и deployment разделенными --- и обновление не удалось.

Интересно то , что helm создал service а затем пожаловался на это (и не выполнил развертывание).
Я закомментировал service и просто запустил обновление с блоком deployment - это сработало. Однако helm не удалил службу, которая должна была быть удалена из файла yaml.

Обновление : я вручную удалил service , раскомментировал его из yaml и запустил обновление - на этот раз оно сработало отлично!

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

см. https://github.com/helm/helm/issues/1193#issuecomment -419555433.

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

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

Листинг секретов показал, что он был создан. Секрет удален вручную, и обновление прошло успешно.

То же самое, @thedumbtechguy. Я регулярно сталкиваюсь с этой проблемой. Это особенно весело, когда Хелм решает, что вам нужно удалить _все_ ваши секреты, карты конфигурации, роли и т. Д. Обновление становится игрой в шутку с постоянно растущим списком аргументов до kubectl delete . Я должен был отказаться от этой сизифовой задачи несколько месяцев назад, но для этого уже слишком поздно. Надеюсь, что эту и десятки подобных проблем можно исправить!

Пользуюсь рулем уже неделю и уже столкнулся со всем изложенным
здесь https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Здесь многое нужно исправить.

15 марта 2019 г., 22:49 Том Дэвис [email protected] написал:

То же самое, @thedumbtechguy https://github.com/thedumbtechguy . Я сталкиваюсь с
этот выпуск привычно. Особенно весело, когда Хелм решает, что тебе нужно
удалите все свои секреты, карты конфигурации, роли и т. д. Обновление становится
игра в крота с постоянно растущим списком аргументов для kubectl
Удалить. Я должен был бросить полотенце на эту сизифову задачу месяцами
назад, но сейчас уже слишком поздно. Конечно, надеюсь, что это и десятки
подобные проблемы можно исправить!

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

Я испытал то же самое с Helm v2.10. У меня уже была развернута диаграмма, я добавил еще одну configMap в диаграмму. Он сообщил, что развертывание не удалось, потому что не удалось найти configMap «blah». я сделал

helm upgrade <NAME> chart --debug --dryrun 

Чтобы убедиться, что configMap действительно отображается, это было. Проверил configMaps в кластере и нашел его там. Удалил бла configMap, повторно запустил обновление, все заработало.

https://github.com/helm/helm/pull/5460 должен лучше прояснить сообщение об ошибке в будущем.

Честная оценка.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

Следите за хорошей работой рулевой команды.

Если это важно для кого-то еще, подумал, что хочу указать, что https://github.com/helm/helm/pull/4871 должен исправить эти проблемы.

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

Имея ту же проблему и единственный обходной путь, кажется, helm delete --purge release и установите снова!

Я столкнулся с той же проблемой. @fbcbarbosa похоже было объединено 2 недели назад. Надеюсь, он станет частью следующего выпуска

Имея ту же проблему и единственный обходной путь, кажется, helm delete --purge release и установите снова!

Менее разрушительный вариант - выполнить helm rollback для / current / version (т.е. с шагом 0). Я не могу гарантировать успех, но до сих пор для нас это всегда успешно помогало.

Есть ли идея, будет ли это в следующем выпуске, и если это произойдет, когда он выйдет?

5460 был объединен 2 месяца назад, что означает, что он должен быть в Helm 2.14.0.

Я исправил проблему

1. удалите те ресурсы, на которые пожаловались "обновление руля". (Там написано, что не найдено, но на самом деле его можно найти). Не удаляйте релиз целиком, иначе, если в продакшене, вы полностью запутаетесь.
2. повторить апгрейд руля. Теперь на этот раз должно появиться "Happy Helming". :)

Мы столкнулись с этой проблемой в PROD, когда требование к нашей зонтичной диаграмме штурвала добавляло конфигурационную карту на основе условного. Для нас проблема заключалась в том, чтобы

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

У нас всегда работал простой откат на текущую ревизию :

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel вы знаете, как работает ваше исправление?