Почему helm upgrade --install не удалось, если предыдущая установка завершилась неудачно?

Это версия для руля и румпеля:

> helm version --tiller-namespace data-devops
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Предыдущая установка Helm завершилась неудачно:

helm ls --tiller-namespace data-devops
NAME            REVISION        UPDATED                         STATUS  CHART                   NAMESPACE
java-maven-app  1               Thu Aug  9 13:51:44 2018        FAILED  java-maven-app-1.0.0    data-devops

Когда я попытался снова установить его с помощью этой команды, это не удалось:

helm --tiller-namespace data-devops upgrade java-maven-app helm-chart --install \
        --namespace data-devops \
        --values helm-chart/values/stg-stable.yaml
Error: UPGRADE FAILED: "java-maven-app" has no deployed releases

Будет ли команда helm upgrade --install завершиться ошибкой, если предыдущая установка завершилась неудачно? Я ожидаю, что он установит принудительно. Любая идея?


kubernetes kubernetes-helm
person Agung Pratama    schedule 09.08.2018    source источник
comment
Вы можете удалить релиз? Может быть, вы могли бы сделать helm delete java-maven-app --purge --no-hooks, а затем выполнить установку Helm   -  person Ryan Dawson    schedule 09.08.2018
comment
К сожалению, в моем случае это не нормально. Я использую ci / cd для развертывания нашего приложения в gke, поэтому я хочу достичь идемпотентного выполнения.   -  person Agung Pratama    schedule 09.08.2018
comment
Если это вообще помогает, я использовал jenkins-x, и он запускает ту же команду. Иногда я сталкивался с той же ошибкой, и мне приходилось вмешиваться вручную, удаляя выпуск, исправляя проблему и снова запуская конвейер. Я думаю, что это происходит только в определенных условиях, когда первая установка диаграммы идет не так, но я не уверен, в каких именно условиях.   -  person Ryan Dawson    schedule 09.08.2018
comment
Понятно, значит, это происходит только при первой установке графика? Думаю, я смогу это вытерпеть, удалив релиз. Я боялся, что ошибка также произошла в существующем работающем выпуске, поэтому удаление работающего выпуска повлияет на мое работающее приложение.   -  person Agung Pratama    schedule 10.08.2018

Ответы (4)


arrow_upward
11
arrow_downward

Пытаться:

helm delete --purge <deployment>

Это поможет

а для helm3 и далее вам необходимо удалить, например.

helm uninstall <deployment>  -n <namespace>
person Dhiraj Surve    schedule 02.04.2020

arrow_upward
25
arrow_downward

Это проблема руля. Это влияет только на ситуацию, когда первая установка диаграммы завершается ошибкой и до Helm 2.7 требовалось ручное удаление неудачной версии перед исправлением проблемы и повторной установкой. Однако теперь для решения этой проблемы доступен флаг --force - https://github.com/helm/helm/issues/4004

person Ryan Dawson    schedule 10.08.2018
comment
Почему-то --force не помогают в этой ситуации. И я бы предпочел, чтобы этот неудавшийся выпуск был исправлен без принуждения. Так что это больше похоже на ошибку в Helm - person esboych; 06.10.2020

arrow_upward
5
arrow_downward

Это происходит, когда развертывание неожиданно завершается неудачей.

Сначала проверьте статус развертывания выпуска Helm;

❯ helm ls  -n $namespace

NAME    NAMESPACE   REVISION    UPDATED STATUS  CHART   APP VERSION

Скорее всего, вы ничего не увидите о проблемном развертывании руля. Итак, проверьте статус развертывания с помощью опции -a;

❯ helm list -n $namespace -a
NAME            NAMESPACE       REVISION    UPDATED          STATUS             CHART         APP VERSION
$release_name   $namespace      7           $update_date     pending-upgrade    $chart_name   $app_version

Как видите, развертывание застряло со статусом pending-upgrade.

Проверить секреты развертывания руля;

❯ kubectl get secret -n $namespace                                                                                                                                             42s ⎈ eks_non-prod/monitoring
NAME                                 TYPE                  DATA   AGE
sh.helm.release.v1.$namespace.v1     helm.sh/release.v1    1      2d21h
sh.helm.release.v1.$namespace.v2     helm.sh/release.v1    1      21h
sh.helm.release.v1.$namespace.v3     helm.sh/release.v1    1      20h
sh.helm.release.v1.$namespace.v4     helm.sh/release.v1    1      19h
sh.helm.release.v1.$namespace.v5     helm.sh/release.v1    1      18h
sh.helm.release.v1.$namespace.v6     helm.sh/release.v1    1      17h
sh.helm.release.v1.$namespace.v7     helm.sh/release.v1    1      16h

и опишите последний;

❯ kubectl describe secret sh.helm.release.v1.$namespace.v7
Name:         sh.helm.release.v1.$namespace.v7
Namespace:    $namespace
Labels:       modifiedAt=1611503377
              name=$namespace
              owner=helm
              status=pending-upgrade
              version=7
Annotations:  <none>

Type:  helm.sh/release.v1

Data
====
release:  792744 bytes

Вы увидите, что секрет имеет тот же статус, что и неудачное развертывание. Так что удали секрет;

❯ kubectl delete secret sh.helm.release.v1.$namespace.v7

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

❯ helm list -n $namespace -a
NAME            NAMESPACE       REVISION    UPDATED          STATUS       CHART         APP VERSION
$release_name   $namespace      7           $update_date     deployed     $chart_name   $app_version
person hbceylan    schedule 25.01.2021

arrow_upward
1
arrow_downward

Просто чтобы добавить ...

Я часто видел ошибку Error: UPGRADE FAILED: "my-app" has no deployed releases в Helm 3. Почти каждый раз ошибка была либо в kubectl, aws-cli, либо aws-iam-authenticator, но не в Helm. Похоже, что из-за этого исключения возникает множество проблем, что не идеально.

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

Например:

aws-cli - aws --version, чтобы убедиться, что у вас установлен cli.

aws-iam-Authenticator - aws-iam-authenticator version, чтобы убедиться, что он установлен правильно.

kubectl - kubectl version покажет, установлен ли инструмент.

kubectl - kubectl config current-context покажет, предоставили ли вы действительную конфигурацию, которая может подключаться к Kubernetes.

person JDTLH9    schedule 04.03.2020
comment
@SomeGuyWhoCodes Я обычно использую: kubectl version или kubectl config current-context - person JDTLH9; 05.03.2020
comment
Это позволит вам увидеть, доступен ли kubectl и правильно ли вы настроены для подключения к Kubernetes. - person JDTLH9; 05.03.2020