Привет, не могли бы вы подробнее рассказать о том, как вы развертываете? вы случайно не используете helm upgrade --install ? И если вы это сделаете, каково состояние развертывания, когда оно сломано ( helm ls ) - предположительно, это Failed ?

Если это так, helm delete --purge <deployment> должен помочь.

привет, извините за недостающую информацию.
Да, я использую helm upgrade --install
И да, развертывание остается в Failed навсегда.
К сожалению, helm delete --purge <deployment> вообще не подходит. Я не могу просто удалить продакшн из-за этого :)

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

единственный способ отсортировать это без удаления выпуска добавить --force

--force к чему? в helm upgrade --install ?
и если да, то это означает, что указанная выше проблема на самом деле является ожидаемой функцией, и мы должны использовать --force при каждом развертывании? - если да, то значит, сломанные релизы будут развертывать принудительно?

да конечно на helm upgrade --install :)
и да, вы должны использовать --force при каждом развертывании

Означает ли это, что --force также принудительно развернет сломанные выпуски? - Я имею в виду, если pod будет сломан и постоянно перезапускаться, он будет удалять старые pod'ы и планировать новые?
--force force resource update through delete/recreate if needed
что такое условие delete ? Вы можете уточнить, как именно это работает? описание определенно слишком короткое для такого критического флага - я полагаю, что оно скрывает тысячи вещей.

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

и вы действительно думаете, что это не проблема?
даже сообщение об ошибке неверное:
app-name has no deployed releases
в котором говорится, что нет развернутых выпусков
пока есть, но с состоянием Failed и helm даже не пытается это исправить :( - исправляя, я имею в виду, просто попробуйте развернуть его, вместо того, чтобы отказываться от самого начала

См. Https://github.com/helm/helm/issues/3208

Не может согласиться. На нашем производстве возникает такая же ошибка. Таким образом, удаление диаграммы не вариант, а принудительная установка кажется опасной. Эта ошибка все еще присутствует в Helm 3. Так что было бы неплохо включить исправление или более безопасный обходной путь.

это можно исправить, удалив "status": "deployed" в storage.go: 136

См. Https://github.com/helm/helm/pull/6933/commit/638229c3d3646e78d0fd5157309f8aeadfd01af1

Я исправлю Pull Request, когда у меня будет время.

Код на месте изначально был правильным. Удаление status: deployed из результатов запроса, когда Helm находит последний выпуск для обновления, независимо от того, в каком состоянии он сейчас находится, может привести к непредвиденным результатам. Это временно обходит проблему, но в дальнейшем она приводит к гораздо более серьезным проблемам.

Если вы можете предоставить вывод helm history когда столкнетесь с этой ошибкой, это будет полезно. Более полезно определить, как заканчивается в случае, когда в книге выпусков нет выпусков в «развернутом» состоянии.

Я сталкиваюсь с этой проблемой при первом развертывании в новом кластере. Стоит ли мне также использовать --force ?

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

helm delete --purge <release-name>

Версия Шлема

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

Я тоже сталкиваюсь с этой проблемой.

@bacongobbler
Я ударил это с помощью helm3. Когда это происходит, история полностью пуста, хотя сломанные ресурсы k8s присутствуют с попытки 1.

Воспроизведение кажется действительно простым:

1. helm upgrade --install «что-то с модулем, у которого есть контейнер, который завершается с ошибкой»
2. исправьте причину выхода контейнера, например значение с недопустимым аргументом для исполняемого файла внутри контейнера, и повторите попытку
   -> Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: "foo" не имеет развернутых выпусков

Кажется, флаг --atomic может быть шагом вперед в моем сценарии (CI / CD). Поскольку он полностью очищает первоначальный неудачный выпуск, как будто этого никогда не было, я не затрагиваю эту проблему при следующей попытке.

То же самое здесь, я не понимаю, как можно посоветовать использование delete или --force , особенно когда есть постоянные тома на месте, я уже потерял все панели инструментов Grafana из-за этого однажды, не выполняя это снова :)

Обновление: кстати, в моем случае выпуск не работает из-за:

Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

даже если я ничего не изменил в значениях графаны

@ alex88 можете ли вы предоставить вывод из helm history ? Мне нужно знать, как другие относятся к этому делу, чтобы мы могли попытаться определить основную причину и найти решение.

@bacongobbler уверен, что мне бы очень хотелось, чтобы это было исправлено, так как я очень осторожно использую helm из-за того, что пару раз потерял постоянные тома (вероятно, моя вина)

REVISION    UPDATED                     STATUS  CHART           APP VERSION DESCRIPTION
4           Wed Dec  4 02:45:59 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5           Mon Dec  9 12:27:22 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6           Mon Dec  9 12:33:54 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7           Mon Dec  9 12:36:02 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8           Mon Dec  9 13:06:55 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9           Mon Dec  9 13:38:19 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10          Mon Dec  9 13:38:51 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11          Mon Dec  9 13:41:30 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12          Mon Dec  9 13:56:01 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13          Mon Dec  9 15:15:05 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

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

как вы попали в такое состояние, когда все релизы провалились? Где выпуск 1, 2 и 3?

как вы попали в такое состояние, когда все релизы провалились? Где выпуск 1, 2 и 3?

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

Обновление: кстати, я использую

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

что касается предыдущего выпуска, вероятно, у руля осталось только 10 из них

Helm3: У меня возникла аналогичная проблема при обновлении istio, выпуск не удался, теперь я не могу повторно развернуть его, хотя небольшая ошибка в шаблонах исправлена. Я не могу удалить производственный выпуск, так как он также удалит связанный ELB со службой istio-ingress.

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

Что мне делать, если простои не принимаются?

% helm upgrade prometheus-thanos --namespace metrics -f values.yaml . 
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .                                                                                                               
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

Что мне делать, если простои не принимаются?

сейчас я просто использую helm для создания шаблонов, вручную сохраняю их локально и применяю

Кажется, флаг --atomic может быть шагом вперед в моем сценарии (CI / CD). Поскольку он полностью очищает первоначальный неудачный выпуск, как будто этого никогда не было, я не затрагиваю эту проблему при следующей попытке.

@ henrikb123 вышеупомянутое работает, только если вы всегда использовали --atomic . Иначе не получится. Например: попробуйте установить сломанный график без него, и они запустят ту же команду с флагом --atomic . Это сломается. К вашему сведению, я использую последнюю версию Helm -> 3.0.2

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

@bacongobbler, почему бы вам просто не сделать то, что сказал здесь @ henrikb123, чтобы смоделировать проблему? Как указывает @ henrikb123 , история полностью пуста . Я тоже могу это подтвердить. Взгляните, пожалуйста:

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

Я тоже столкнулся с этим с Istio.

В версии 1.4.3 существует проблема Istio, из-за которой одно из заданий, запускаемых при установке, завершится ошибкой, если оно не сможет попасть на сервер Kubernetes API. Затем он оставляет задание позади, и если вы попытаетесь повторно запустить команду Helm, произойдет сбой, потому что задание уже существует. Я попытался удалить задание, настроить все и повторно запустить обновление, но безуспешно ... и теперь я застрял.

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

REVISION    UPDATED                     STATUS  CHART       APP VERSION DESCRIPTION                                                                                                                                                                                                         
10          Tue Jan 14 09:17:00 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11          Tue Jan 14 09:22:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12          Tue Jan 14 09:23:10 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13          Tue Jan 14 09:25:58 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
14          Tue Jan 14 09:35:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15          Tue Jan 14 09:38:08 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
16          Tue Jan 14 14:02:47 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17          Tue Jan 14 14:19:44 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18          Tue Jan 14 14:33:36 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19          Tue Jan 14 14:36:59 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

Это с Helm 3.0.2.

ИМО, это критическая проблема, которую необходимо исправить как можно скорее. Я видел много других подобных проблем, которые были открыты для той же проблемы, начиная с версии 2, и до сих пор кажется, что она не исправлена.

Я просто прошу разработчиков сделать именно то, что @henrikb123 сказал в своем комментарии, чтобы смоделировать эту проблему. Это очень простой способ смоделировать это. Вы можете протестировать его с любой версией Helm (2.xx и 3.xx). Я почти уверен, что это произойдет со всеми из них.

Возможно, --atomic должно быть жестким требованием (а не аргументом командной строки). Это даже довольно избыточно, поскольку --cleanup-on-fail . Разница в том, что --cleanup-on-fail не решает эту проблему, как --atomic .

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

kubectl -n kube-system patch configmap app-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

В нашем случае мы были уверены, что последняя версия FAILED действительно была успешно развернута kubernetes.

Как мы попали в это состояние?

По сути, наша команда разработчиков проигнорировала FAILED обновления, потому что Kubernetes все еще вносил изменения после тайм-аута Helm.

В частности, мы используем Helm 2 и устанавливаем TILLER_HISTORY_MAX=20 при развертывании tiller-deploy. Мы использовали helm upgrade --wait --timeout 1080 для всех наших обновлений RollingUpdate, которые со временем занимали больше времени. Затем время обновления руля начало истекать, но никто не был обеспокоен (просто раздражен), потому что Kubernetes все еще успешно вносил изменения. После того, как истекло время 20 обновлений (сегодня), мы были встревожены, потому что больше не могли развертывать, потому что вместо этого мы видели app-name has no deployed releases .

Почему работает патч?

Мы выяснили, что нам просто нужно исправить метку STATUS в configmap, потому что мы поняли, что Helm, вероятно, запрашивал configmaps, используя запрос, похожий на ...

kubectl -n kube-system get configmap -l NAME=app-name,STATUS=DEPLOYED

Подсказка была найдена, когда мы просмотрели файл configmap yaml и заметили следующие метки ...

$ kubectl -n kube-system describe configmap app-name.v123
Name:         app-name.v123
Namespace:    kube-system
Labels:       MODIFIED_AT=1579154404
              NAME=app-name
              OWNER=TILLER
              STATUS=FAILED
              VERSION=123
Annotations:  <none>
Data
====
release:
----
H4sIAAAAAAAC...snipped...

И это соответствует https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler вместо того, чтобы гадать, как вы попадете в состояние

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

Таким образом, объемы динамически создаются по претензиям. При удалении претензий (путем удаления диаграммы) объемы также удаляются безвозвратно . Тебе это не нравится. Я и многие другие разработчики застряли на несколько месяцев и пытаемся решить эту проблему.

Вам не понравилась идея удалить из запроса status: deployed . Итак, как насчет добавления новой метки, которая фактически отмечает последний выпуск, независимо от того, был ли его статус развернут или

_ Я очень рад услышать ваше мнение по этому поводу.

Идеальное словосочетание @AmazingTurtle.

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

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

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

package foo

import (
    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/release"
    "helm.sh/helm/v3/pkg/storage/driver"
)

// DangerouslyApplyRelease allows installing or upgrading any release from a failed state,
// but does not enforce Helm's standard resource ownership checks.
func DangerouslyApplyRelease(cfg *action.Configuration, rel *release.Release) error {
    // Forcibly mark the last release as successful and increment the version
    rel.Info = &release.Info{
        Status: release.StatusDeployed,
    }
    rel.Version++

    var err error

    // Attempt to create the release
    err = cfg.Releases.Create(rel)

    // If release already exists, update it
    if err == driver.ErrReleaseExists {
        err = cfg.Releases.Update(rel)
    }

    return err
}

@jlegrone Будет ли также helm delete --purge (v2) или helm uninstall (v3), поскольку все они являются неудавшимися выпусками?

То, что указал @jlegrone , правда.
@hickeyma, ваше предложение - это обходной путь, который может сработать. Но мне нужно окончательное решение.

это вредоносная ошибка за последние 2 года, и helm не собирается ее исправлять
helm delete неприемлемо в большинстве производственных случаев
с helm3 мы не можем kubectl edit secret sh.helm.release.... потому что он зашифрован
helm rollback <latest-successful> - единственный правильный обходной путь

так что если у вас по умолчанию HISTORY_MAX = 10 и вы 10 раз пытались заставить что-то работать - вы полностью потерялись ...

и если у вас есть какая-то логика по установке и обновлению, вы не можете удалить sh.helm.release ..... v * secrets

Шлем должен умереть или починить его

найдено обходное решение
helm3 навешивает ярлыки на свои секреты:
kubectl get secrets --show-labels | grep sh.helm.release.v1

....
sh.helm.release.v1.helm-must-die.v34                 helm.sh/release.v1                    1         13h       modifiedAt=1580326073,name=helm-must-die,owner=helm,status=failed,version=34
sh.helm.release.v1.helm-must-die.v35                 helm.sh/release.v1                    1         13h       modifiedAt=1580326228,name=helm-must-die,owner=helm,status=failed,version=35
sh.helm.release.v1.helm-must-die.v36                 helm.sh/release.v1                    1         1h        modifiedAt=1580370043,name=helm-must-die,owner=helm,status=failed,version=36
...

так сделайте для последнего kubectl edit secret sh.helm.release.v1.helm-must-die.v36 и установите статус метки = развернуто
а для выпуска до него (v35) установите label status = superseded

следующий helm upgrade --install ... будет работать

@ kosta709 Подобно тому, что я обнаружил для Helm2, который хранит выпуски в виде ConfigMaps в пространстве имен kube-system с метками, состоящими только из CAPS, Helm3 теперь хранит выпуски в виде секретов в пространстве имен приложения с метками, написанными строчными буквами.

Итак, для Helm3 вы можете просто использовать немного другую команду kubectl patch ...

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

Я бы хотел, чтобы нам не приходилось обсуждать эти обходные пути. Исправление этого в продукте должно быть главным приоритетом. Напоминание о том, насколько это плохо (без учета обходных путей):

Если выпуск завершился неудачно при первом развертывании ИЛИ если достаточное количество выпусков не смогли вывести последний успех из истории, выпуск не может быть исправлен без ручного вмешательства.

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

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

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

Для меня это не было проблемой в более старых версиях helm, и здесь нет неудачных развертываний, kubectl показывает запущенные службы, и все работает.

Теперь я просто пытаюсь запустить helm upgrade -f app.yaml --namespace prometheus prometheus prometheus и получаю сообщение об ошибке: Error: UPGRADE FAILED: "prometheus" has no deployed releases но я не могу попробовать какие-либо решения, потому что это находится в продукте ...

@zrsm то, что мы сейчас делаем, - это создание файлов yaml с помощью helm и использование kubectl diff / dry-run для предварительного просмотра изменений перед их применением вручную.

@zrsm то, что мы сейчас делаем, - это создание файлов yaml с помощью helm и использование kubectl diff / dry-run для предварительного просмотра изменений перед их применением вручную.

Спасибо за ответ, я понизил версию до 2.15.1, но столкнулся с аналогичными проблемами, однако я попытался что-то вроде удаления моего ~ / .helm, а затем повторно инициализировал сервисный аккаунт tiller из kubectl, после этого я смог применить диаграммы к кубернетам . Я попробую протестировать это с помощью helm 3 сегодня же и отвечу исправлением. У меня такое чувство, что, возможно, в этом проблема.

Привет, я проверил это ... и, похоже, выполнил следующую команду после удаления моего предыдущего ~ / .helm / решил это ...

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

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

Эта ошибка сохраняется в Helm 3, есть ли запланированное исправление?

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

Можем ли мы решить эту проблему как можно скорее?

эта проблема настолько неприятна, что это повод вообще отказаться от использования helm .

Я согласен. Это сводит меня с ума. Я собираюсь исправить это. Пожелай мне удачи.

Я согласен. Это сводит меня с ума. Я собираюсь исправить это. Пожелай мне удачи.

спасибо и удачи!

Я был бы не против заставить некоторых из вас взглянуть на PR # 7653.

Я считаю, что это решит проблемы, описанные выше.

Не могу поверить, что он все еще открыт без реакции со стороны сопровождающих

cc @bacongobbler @mattfarina

Будет ли работать использование helm delete --purge (v2) или helm uninstall (v3), поскольку все они являются неудачными выпусками?

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

иногда выпуск не завершается неудачно, но таймаут и штурвал помечают его как неудачный, и в следующий раз, когда он показывает, что не имеет развернутого выпуска, но приложение на самом деле полностью функционально, это случалось со мной много раз, поэтому мне пришлось изменить выпуск label на deployed one. это не всегда вариант сделать helm delete --purge (v2) or helm uninstall (v3)

@rimusz как вы меняете лейбл релиза?

@dudicoco , вручную отредактировав секрет последней версии helm v3, вы можете автоматизировать это и использовать kubectl patch

перешли на https://github.com/k14s/kapp, который работает как шарм.

@rimusz вот что я подумал, спасибо.

Я также перенес исправление на helm 2 в # 7668, но все еще жду отзывов о # 7653.

Такая же проблема здесь,

Релиз, развернутый с --wait , прошел таймаут и, наконец, запущен. Он по-прежнему помечен как сбойный.
Итак, более поздние развертывания тоже терпят неудачу.

Это означает, что статус выпуска не является достоверной информацией.

Мы используем k8s в нашей компании для многих услуг на производстве.
Несколько раз в месяц у нас возникают одни и те же проблемы с Helm в разных приложениях (« * не имеет развернутых выпусков»).
Мы использовали разные версии helm (от 2.7 до 3.0.3).
Проблема не устранена.
Это доставляет массу неудобств нашим пользователям (разработчикам, развертывающим приложения в кластере).
Каждый раз, когда мы попадаем в него, мы просто исправляем последний секрет выпуска (статус «развернуто»).
Есть ли план добавить поведение, которое игнорирует состояние последних выпусков и устанавливает новые выпуски?

Если для --history-max установлено значение 10 (значение по умолчанию), первый выпуск выполнен успешно.
Затем следующие 10 выпусков потерпели неудачу:
Error: UPGRADE FAILED: timed out waiting for the condition (Это было смоделировано, следовательно, ожидалось).
После этого вышел следующий (11-й неудачный) релиз:
Error: UPGRADE FAILED: "app" has no deployed releases (вот в чем проблема!)

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

Мне нравится эта идея. Потребуется изменить функциональность хранилища, но я думаю, что это можно сделать.

https://github.com/helm/helm/pull/4978 был объединен для Helm 2. Возможно, он не был перенесен на Helm 3. Если у кого-то есть время и он хочет перенести его, пожалуйста, не стесняйтесь.

Я попробовал портировать это на Helm 3 с # 7806, и хотел бы, чтобы он был объединен как можно скорее. Спасибо, @ultimateboy!

А как насчет выпусков, которые не удается _first_ установить, т.е. не имеют прошлых успешных выпусков?
Мы используем upgrade --install для идемпотентного развертывания выпусков Helm, и когда первый выпуск выходит из строя, все последующие вызовы upgrade --install завершаются с ошибкой «не имеет развернутых выпусков» (эта проблема).

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

Конечно, это еще нужно исправить.

Также имеет смысл сохранить последний успешный выпуск в любом случае, не только из-за этой ошибки. Например, проблемы с отладкой файла значений и т. Д.

@peterholak Сценарий «сбой первого выпуска» иногда также

Этот вопрос должен быть приоритетным, поскольку большинство людей используют helm в продакшене. Я мог бы запустить установку helm с помощью --atomic , но что, если бы я хотел проверить причину сбоя перед развертыванием? Я был бы ограничен таймаутом до того, как установка не удалась, а затем она вернется. Если бы я мог успешно обновить, мне не пришлось бы чувствовать себя ограниченным во времени при проверке сбоя.

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

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

Пожалуйста, подумайте о значительном повышении приоритета этого вопроса.

Опыт оооочень плохой, мы не можем просто удалить весь выпуск, потому что он находится в продакшене! Это приведет к простою сервера! Как мы можем решить эту проблему в конце концов?

Кроме того, может кто-нибудь удалить метку вопроса / поддержки? Эта проблема связана не с отсутствием документации, а с текущим поведением Helm, которое не очень способствует использованию в конвейерах автоматизированного развертывания.

PR # 7806 был объединен с мастером. Он будет выпущен в версии 3.2. Соответственно, закрываю этот вопрос.

Большой! Это решает большинство наших проблем с Helm.

Каково текущее поведение в случае сбоя первого выпуска (еще не развернутых выпусков)?

Был https://github.com/helm/helm/issues/3353, который был адресован https://github.com/helm/helm/pull/3597, но только при использовании --force .

--force есть некоторые проблемы в Helm 3 (https://github.com/helm/helm/issues/6378) с предложением по их устранению (https://github.com/helm/helm/ issues / 7082), плюс, как упоминалось в других комментариях в этой ветке, использование --force любом случае не всегда подходит. Так что вся ситуация до сих пор в некоторой степени неясна.

@technosophos благодарит за исправление. Любопытно, когда будет 3.2. релиз доступен для установки? Продолжайте получать ошибку app-name has no deployed releases в существующем неудавшемся выпуске. И это своего рода блокиратор конвейеров CI / CD.

@peterholak см. № 7913.

3.2 будет обсуждаться на открытой конференции разработчиков 16 апреля. Я отсортировал его до тех, которые в настоящее время выглядят так, как будто их можно сразу упаковать. Затем мы начнем процесс выпуска бета-версии (при условии, что все сопровождающие согласятся на завтра).

Я столкнулся с той же проблемой при решении AKS, чтобы исправить упомянутую проблему, с помощью следующей команды:

helm version : 3.1.2
Я просто удаляю пакет из кластера k8s командой
helm delete <release-name>

и запустите цикл развертывания, чтобы исправить проблему

Проблема все еще существует в версии 3.2.0.

@deimosfr Это исправлено в # 7653, который будет в версии 3.2.1. Он еще не выпущен, но вы можете получить исправление, если хотите создать мастер.

Я использую 3.2.1, и это все еще происходит

По-прежнему есть причины, по которым эта ошибка может возникать. 3.2.1 не просто устранил ошибку. Это устранило некоторые причины. Если вы все еще испытываете это, ваша проблема не в том, что проблема устранена.

@yinzara У меня есть классический случай "пути b" из исходного описания на новом кластере без проблем. Я также могу воспроизвести эту ошибку в другом кластере, где Helm v2 работает нормально. Мы, конечно, можем сделать классический танец «это вызвано чем-то другим, откройте новую проблему», но я думаю, что это будет быстрее, если будет просто признано, что это не совсем исправлено.

Что будет на выходе helm list ? Каков «статус» предыдущей неудавшейся версии? У Helm 2 есть эта проблема, и она совсем не исправлена, поэтому я все еще думаю, что ваша проблема не в том, что вы думаете.

По-прежнему бывает на версии 3.2.1.

Если первоначальное развертывание терпит неудачу 3 раза, все застревает ... Невозможно исправить это, если вы не удалите диаграмму и не развернете хорошую.

Подробности:

helm history t3-mac -n t3                                                                                                                                                                 REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

У меня такая же проблема с развернутой диаграммой, и модуль работает нормально

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Но я не могу его обновить.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm      default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Я подтверждаю, что это произошло и на моей стороне

@zodraz Статус вашего руля показывает причину вашей ошибки. Самый последний выпуск не отображается как неудачный, он отображается как «ожидающая установка». Это будет означать, что процесс, который управлял последним обновлением, был искусственно завершен до его завершения (то есть до того, как он дал ошибку или был успешным).

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

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

У меня такая же проблема с развернутой диаграммой, и модуль работает нормально

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Но я не могу его обновить.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME  NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm    default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Я скажу, что ваша проблема меня очень озадачивает. Я не могу понять, как это могло случиться, учитывая тот вывод журнала, который у вас есть. Выпуск исправления в 3.2.1 определенно не поможет в вашей ситуации, поскольку у вас нет неудачного выпуска. Я предполагаю, что каким-то образом из Kubernetes были удалены некоторые секреты, содержащие информацию о выпуске руля. Я бы посоветовал полностью удалить выпуск и переустановить, если сможете.

Привет @yinzara!

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

Это состояние не подлежит восстановлению ... Так что единственный способ исправить это - удалить диаграмму ... Мой обходной путь, чтобы избежать этого, использовать атомарный флаг, чтобы всегда откатываться и никогда не достигать этого "поврежденного состояния" ...

Я понимаю решение сопровождающих ... Но это приводит к путанице, к отсутствию возможного решения (если не удалять диаграмму) и ну, как я уже сказал, это состояние было достигнуто, когда произошло 3 ошибки ... без его отмены .. .

В любом случае урок усвоен и откат через атомарный флаг.

Привет @yinzara

Я нашел причину, по которой это не удается.

Я установил неправильный параметр -selfScrapeInterval=10 он должен быть server.extraArgs.selfScrapeInterval = 10

Итак, проблема с - в параметре.
Может быть, ошибка руля не имела смысла для этого типа ошибки переменной?

Неудачный:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases

Успех:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

Это тоже работает:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

У меня та же проблема: '(и я не могу использовать очистку, потому что я потеряю данные, и я не могу этого сделать, я знаю, что эта проблема закрыта, но только я выражаю свою боль.

При развертывании критических рабочих нагрузок нам приходится отказываться от выпусков Helm, даже если istioctl istio отказывается от Helm по этой причине (я полагаю). Используем шаблон штурвала .... |

@GloriaPG, можешь поделиться дополнительной информацией? Как вы столкнулись с той же проблемой? Как ранее упоминал

Привет @bacongobbler

Мы используем helm upgrade с флагами --install и --force :

helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

К сожалению, когда выпуск находится в неудачном состоянии:

$ helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
PROJECT_NAME                CHART_NAME      136         2020-07-09 14:13:09.192381483 +0000 UTC failed      CHART_NAME-0.1.0

это приводит к:

Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Как это можно решить? Похоже, что --force с флагом --install не работает

Поскольку это производственный env, я не могу просто удалить релиз и создать его с нуля :(

Спасибо за любые предложения

Кажется, ваша ошибка связана с https://github.com/kubernetes/client-go/issues/508
Вы не можете изменить селектор при развертывании. Вам придется развернуть и повторно развернуть.

@yinzara, самое смешное, что я не меняю селектор при развертывании, все работает на выпуске 9/10. В одном из них во время развертывания что-то пошло не так, выпуск находится в состоянии сбоя, и я не могу восстановить его каким-либо образом - развертывание работает, модули работают, но я больше не могу его изменять.

Немного нелогично, что после того, как релиз находится в состоянии ошибки, я больше не могу его изменить с помощью helm. Я ожидал, что флаг --force позволит мне полностью заменить развертывание или принудительно применить изменения, но я не мог найти способ исправить существующий выпуск и работать с ним.

Да, к сожалению, это не похоже на проблему с рулем. Что-то не удалось с вашим релизом, и он находится в плохом состоянии в кубернетах. Скорее всего, селектор испорчен или что-то не так, как вы ожидали, но ошибка, которую вы видите, когда "app-name" не имеет развернутых выпусков, - это просто отвлекающий маневр.

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

Так что мою конкретную проблему с этим легко воспроизвести.

Начните развертывание чего-либо с помощью helm3 (с --atomic и --cleanup-on-fail ) и ctrl + c процесса после того, как он начнет создавать ресурсы. Ничего не откатывается, ресурсы все еще существуют, и любые последующие попытки запустить install --upgrade приводят к ошибке «не имеет развернутых выпусков».

Этот ctrl + c - это то, что, по сути, происходит, когда кто-то отправляет новую фиксацию в ветку в нашей системе CI, когда уже запущена сборка - обновление руля будет отменено, а затем оно будет полностью остановлено.

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

РЕДАКТИРОВАТЬ: как только это сломано, helm ls не отображает выпуск, helm history показывает его в состоянии ожидания установки.

На самом деле - неважно. Для тех, кого это затронуло, есть одно решение: удалить запись истории из кубернетов вручную. Это хранится в секрете. Если я удалю некорректную запись состояния pending-install , то снова смогу успешно запустить upgrade --install !

@AirbornePorcine - Не могли бы вы

@ tarunnarang0201 Helm создает секрет кубернетов для каждого развертывания, в том же пространстве имен, в котором вы развернули, вы увидите, что он имеет тип helm.sh/release.v1 и называется примерно так: sh.helm.release.v1.release -name.v1 '. Вам просто нужно удалить самый последний секрет (посмотрите на суффикс «v1» в примере, он увеличивается для каждого развертывания), и это, казалось, разблокировало для меня вещи.

@AirbornePorcine, спасибо!

@AirbornePorcine @ tarunnarang0201 @ ninja - Вы также можете просто пропатчить метку статуса ... особенно, если у вас нет предыдущих РАЗЛОЖЕННЫХ выпусков.

Для Helm 3 см. Мой комментарий на https://github.com/helm/helm/issues/5595#issuecomment -580449247

Дополнительные сведения и инструкции для Helm 2 см. В моем комментарии по адресу https://github.com/helm/helm/issues/5595#issuecomment -575024277.

Этот разговор слишком длинный ... и у каждого комментария есть одно решение ... какой вывод?
Мы использовали старый Helm 2.12, и у нас никогда не было проблем, но теперь с v3.2.4 ранее неудачное развертывание завершается с этой ошибкой.

Кстати, мы используем Terraform и последнюю версию Helm-провайдера. Итак, следует ли нам использовать --force или --replace

@xbmono Разговор долгий, потому что есть

• есть целый ряд причин, по которым ваш релиз может попасть в это состояние
• это было возможно и в Helm 2, и решения, которые работали там и в Helm 3, отличаются.
• есть разные пути, которыми воспользовались пользователи, столкнувшиеся с этой проблемой
• Существуют разные варианты в зависимости от того, что вы пытаетесь сделать, и готовы ли вы терпеть потерю PVC и различные возможные комбинации простоев.

Если вы столкнулись с ошибкой «нет развернутых выпусков», я не уверен, что ни install --replace ни upgrade --install --force помогут вам сами по себе.

Разумное предложение, наверное, можно дать только

• если вы предоставите helm history для выпуска, чтобы люди могли видеть, что произошло
• если вы расскажете об исходной причине неудачи / о том, что вы сделали для этого, и считаете ли вы, что исходная проблема решена

Мое резюме возможных вариантов

• если вас вообще не заботят существующие ресурсы k8s или время простоя, helm uninstall && helm install может быть вариантом
• если это первая неудачная установка диаграммы, вы, вероятно, можете просто удалить секретные метаданные выпуска и снова helm install . Возможно, вам потребуется вручную очистить ресурсы k8s, если из-за сбоя не осталось ничего лишнего, в зависимости от того, использовали ли вы --atomic и т. Д.
• если вы отказались от установки --wait ed на полпути, а helm history показывает, что последний выпуск находится в pending-install вы можете удалить секретные метаданные последнего выпуска или исправить статус выпуска
• в некоторых других комбинациях сценариев также может быть возможно исправить статус выпуска одного или нескольких секретов выпуска и посмотреть, может ли продолжаться последующий upgrade , однако, насколько мне известно, большинство этих случаев были рассмотрены автор # 7653 (чтобы убедиться, что где-нибудь в истории есть выпуск deployed к которому можно вернуться), поэтому я был бы удивлен, если бы это было полезно сейчас.

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

@chadlwilson Спасибо за ваш ответ.

helm history возвращает строк!

Error: release: not found

но helm list возвращает неудачное развертывание

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

Мы используем Terraform, и наши среды автоматически развертываются Jenkins каждый час. С terraform я не могу использовать helm upgrade , это то, что делает поставщик руля

В коде terraform я установил force_update на true , не повезло, и я установил replace на true , снова не повезло

resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

Так что мне интересно, связано ли это с wait=true ? Таким образом, причина сбоя предыдущего развертывания заключалась в том, что кластер не мог взаимодействовать с репозиторием докеров, и поэтому достигнуто значение timeout и статус failed но мы исправили проблему и pods перезапущен успешно, теперь очевидно, что helm delete работает, но если бы я делал это каждый раз, мои менеджеры и разработчики были бы счастливы.

При использовании helm v2, если развертывание завершится неудачно и разработчики исправят его, следующее развертывание обновит неудачное развертывание.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

Ошибка helm history кажется странной (опечатка? Пропущенное пространство имен? Неправильная версия руля?), Но, учитывая ее ревизию 1 в list выше, кажется, что вы пытаетесь сделать первую время установки новой диаграммы и первая установка не удалась. Если вы пытаетесь разблокировать что-то, вы, вероятно, можете удалить метаданные секрета выпуска, как указано выше, или исправить его статус и попробовать еще раз. Это может указывать на то, что метаданные находятся в плохом состоянии с точки зрения Helm или Helm Terraform Provider, но не с точки зрения того, как они туда попали.

В любом случае, у меня нет проблем с выполнением upgrade за неудачных первоначальных развертываний с помощью Helm 3.2.1 с момента объединения # 7653. Возможно, вы захотите дважды проверить конкретную версию Helm, которую на самом деле использует провайдер? Также возможно, что это может быть связано с тем, как поставщик Helm Terraform определяет состояние выпуска после сбоя install . У меня нет опыта работы с этим провайдером, и лично я не сторонник того, чтобы оборачивать Helm другой декларативной абстракцией, такой как TF, потому что я нахожу его еще более непрозрачным, когда что-то пойдет не так, но вы все равно можете копать дальше .

В любом случае, как я сказал выше, если ошибка, на которой вы застряли, - это has no deployed releases после неудачного первого развертывания, я не думаю, что ни replace ни force вероятно, помогут вам воскресить ситуацию без какого-либо другого вмешательства, и было бы лучше отладить ее дальше и поговорить в другом месте, так как переход туда и обратно по этому старому закрытому билету с 51 участником не кажется таким продуктивным для всех, кого это касается.

Нет, опечатки не было. Кроме того, это происходит независимо от того, выполняется первое развертывание или позднее.

Как я уже упоминал, мы используем опцию --wait для ожидания развертывания в Jenkins, а затем для уведомления о том, завершилось ли развертывание ошибкой или нет.

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

Поэтому, если мы удалим опцию --wait , helm отметит развертывание как successful любом случае.

Обходной путь:

Теперь нашел другое решение. Для тех, у кого такая же проблема, и кто хочет, чтобы их автоматизация работала так же хорошо, как раньше, вот мой обходной путь:

• Удалить опцию --wait из helm deploy
• Используйте эту команду, чтобы получить список развертывания для того пространства имен, в котором вы развертываете: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Вы можете использовать split чтобы превратить список, разделенный запятыми выше, в массив
• Затем вы можете запускать несколько команд параллельно (мы используем Jenkins, чтобы это было легко сделать) как kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Если после timeout , например, 7m означает 7 минут, развертывание все еще не выполнено, команда завершается с ошибкой.
• Задача решена.

На самом деле - неважно. Для тех, кого это затронуло, есть одно решение: удалить запись истории из кубернетов вручную. Это хранится в секрете. Если я удалю некорректную запись состояния pending-install , то снова смогу успешно запустить upgrade --install !

В качестве альтернативы это сработало для меня:

helm uninstall {{release name}} -n {{namespace}}

исправлено kubectl -n $namespace delete secret -lstatus=pending-upgrade
Беги, руль снова.

Я не уверен, почему это закрыто, я только что получил новый Helm 3.3.4. Если первоначальная установка не удалась, второе обновление Helm --install --force по-прежнему показывает ту же ошибку. Все эти обходные пути работают, но выполняются вручную , они не помогают, когда вы хотите полностью, 100% автоматический CI / CD, когда вы можете просто нажать исправление, чтобы запустить другое развертывание, не выполняя очистку вручную.

Кто-нибудь думал о том, чтобы просто добавить флаг, что это первый выпуск, поэтому должно быть безопасно просто удалить его автоматически? Или добавить что-то вроде "--force-delete-on-failure"? Игнорирование проблемы не поможет.

@ nick4fake AFIK был закрыт PR №7653. @yinzara может предоставить более подробную информацию.

Сопровождающие приняли решение не разрешать перезапись ожидающего обновления выпуска. Но ваше утверждение, что все обходные пути - это обходные пути, которые не работают в конвейере CI / CD, неверно. Последний предложенный обходной путь можно добавить в качестве этапа сборки перед запуском обновления вашего руля (я бы также не использовал --force в строке CI / CD). Он имеет тот же эффект, что и то, что вы предложили, за исключением того, что он удаляет выпуск прямо перед установкой следующего выпуска, а не сразу после этого, позволяя вам отладить причину сбоя.

Я также использовал следующее в своей автоматической сборке для удаления любых «ожидающих» выпусков перед запуском моей команды обновления (не забудьте установить переменную среды NS_NAME в пространство имен, в которое вы развертываете):
Баш

! / usr / bin / env bash

RELEASES = $ (helm list --namespace $ NS_NAME --pending --output json | jq -r '. [] | Select (.status == "pending-install") | .name')
если [[ ! -z "$ RELEASES"]]; тогда
helm delete --namespace $ NS_NAME $ RELEASES
фи

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

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

Я имею в виду, просто проверьте эту ветку обсуждения, люди все еще сталкиваются с проблемой. Что вы думаете о возможности добавления дополнительной информации в сообщение об ошибке Helm со ссылкой на эту ветку + некоторые предложения о том, что делать?

@ nick4fake Я думаю, вы

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

«Неудачный» выпуск МОЖЕТ быть обновлен. Вот что сделал мой пиар. Если выпуск выходит из строя из-за сбоя одного из ресурсов, вы можете просто обновить этот выпуск (т.е. upgrade --install тоже работает), и он не выдаст ошибку «app-name» has no deployed Releases.

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

Если вы обнаружите, что ваши выпуски находятся в этом состоянии, вы можете пересмотреть конфигурацию развертывания. Этого никогда не должно происходить в правильно настроенном конвейере CI / CD. Он должен либо потерпеть неудачу, либо удастся. «ожидает» означает, что установка была отменена, пока она еще обрабатывалась.

Я не являюсь сопровождающим, поэтому мое мнение о вашем предложении не имеет значения, однако я не нахожу упоминания в кодовой базе о проблеме Github, которая на самом деле напечатана в сообщении об ошибке или сообщении, поэтому я держу пари, что они этого не допустят, но вы добро пожаловать в пиар и посмотрите :-)

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

Что вы думаете о возможности добавления дополнительной информации в сообщение об ошибке Helm со ссылкой на эту ветку + некоторые предложения о том, что делать?

+1 к этому. Нам все еще нужно погуглить, чтобы найти эту ветку, чтобы понять, что такое выпуск pending-install , чтобы мы могли начать рассуждать об этом сообщении об ошибке.

У меня были проблемы с helm upgrade и это привело меня сюда. Решилось добавлением -n <namespace> . Может быть, это кому-то поможет.

Для Helm3 можно было решить через патч
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name и version - видно из kubectl get secrets -n <namespace> | grep helm