こんにちは-展開方法についてもう少し詳しく教えていただけますか？ 万が一helm upgrade --installを使っていますか？ もしそうなら、それが壊れたときの展開の状態は何ですか（ helm ls ）-おそらくそれはFailedですか？

この場合、 helm delete --purge <deployment>でうまくいくはずです。

こんにちは、情報が不足してすみません。
はい、 helm upgrade --install
そして、はい、展開はFailed永久にとどまります。
残念ながら、 helm delete --purge <deployment>はここではまったくオプションではありません。 そのため、本番サービスを削除することはできません:)

問題は、ヘルムが3回連続して失敗した後に回復できない理由です。

リリースを削除せずにそれをソートする唯一の方法は--force追加します

--force何に？ helm upgrade --install ？
はいの場合、上記の問題は実際に予想される機能であり、すべての展開で--forceを使用する必要があることを意味しますか？ -はいの場合、壊れたリリースを強制的にデプロイすることを意味しますか？

はい、もちろんhelm upgrade --install :)
はい、すべての展開で--forceを使用する必要があります

--forceが壊れたリリースも強制的にデプロイすることを意味しますか？ -つまり、ポッドが壊れて常に再起動する場合、古いポッドを削除して新しいポッドをスケジュールしますか？
--force force resource update through delete/recreate if needed
delete条件とは何ですか？ それがどのように正確に機能するかを詳しく説明できますか？ 説明は、そのような重要なフラグには間違いなく短すぎます-私はそれが内部で何千ものことをすることを期待しています。

ところで、私は本当に本番サービスを削除したくないので、 --forceフラグは私にとってオプションではありません。

本当に問題ではないと思いますか？
エラーメッセージでさえ間違っています：
app-name has no deployed releases
これは、展開されたリリースがます
状態ではなくそこにいる間にFailedと舵がさえ:(それを修正しようとしない-私が意味を固定することによってだけではなく、非常に始まりにあきらめるのは、それを展開してみてください

https://github.com/helm/helm/issues/3208を参照して

大賛成です。 私たちのプロダクションでも同じエラーが発生しています。 したがって、チャートを削除することはオプションではなく、インストールを強制することは危険なようです。 このエラーはHelm3でも引き続き発生します。そのため、修正またはより安全な回避策を含めることをお勧めします。

storage.go：136の「status」：「deployed」を削除することで修正できます

参照： https ：

時間があるときにプルリクエストを修正します。

配置されているコードは元々正しいものでした。 クエリ結果から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で叩きました。 これが発生すると、履歴は完全に空になりますが、試行1以降、壊れたk8sリソースが存在します。

複製は本当に簡単なようです：

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永続的なボリュームを数回失ったため、ヘルムの使用には本当に慎重なので、これが修正されるのを本当に見たいと思います（おそらく私のせいです）

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

基本的に、アップグレードを実行していくつかの環境変数を変更しようとしましたが、デプロイエラーが発生したため、とにかく環境変数が変更されたため、エラーを無視して変更を続けました。

どのようにしてすべてのリリースが失敗した状態になりましたか？ リリース1、2、および3はどこにありますか？

どのようにしてすべてのリリースが失敗した状態になりましたか？ リリース1、2、および3はどこにありますか？

環境変数を変更し（複数の変更を行う必要がありました）、毎回アップグレードを実行すると、環境変数が変更されていましたが、永続的なボリュームエラーを修正する方法がわかりませんでした

更新：ところで私は使用しています

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

以前のリリースに関しては、おそらくヘルムはそれらのうちの10個しか保持していません

Helm3：istioのアップグレード中に同様の問題が発生し、リリースが失敗しました。テンプレートの小さなエラーが修正されても、再デプロイできません。 istio-ingressサービスに関連付けられているELBも削除されるため、製品リリースを削除できません。

最初のリリースが失敗した状態になったときにロジックを変更する将来の作業はありますか？

ダウンタイムが受け入れられない場合はどうすればよいですか？

% 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にはアクセスできない場合、インストールが実行するジョブの1つが失敗します。 その後、ジョブが残され、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

これはHelm3.0.2です。

IMOこれは重大な問題であり、できるだけ早く修正する必要があります。 バージョン2以降、同じ問題に対して開かれていた他の多くの同様の問題を確認しましたが、現在までは修正されていないようです。

この問題をシミュレートするために、 @ henrikb123がコメントで言ったことを正確に実行するように開発者にお願いします。 それをシミュレートする非常に簡単な方法です。 Helmの任意のバージョン（2.xxおよび3.xx）でテストできます。 私はそれがそれらすべてで起こるとほぼ確信しています。

たぶん--atomicは難しい要件であるはずです（コマンドライン引数ではありません）。 --cleanup-on-failようにかなり冗長です。 違いは、 --cleanup-on-failは、 --atomicようにこの問題を修正しないことです。

また、本番環境でこれに遭遇したばかりであり、ダウンタイムはオプションではありません。 最新のFAILEDconfigmapにパッチを適用して、代わりに次のようなコマンドを使用してラベルSTATUS: DEPLOYEDを設定することで、回避策を見つけました...

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

私たちの場合、最後のFAILEDリビジョンが実際にkubernetesによって正常にデプロイされたと確信していました。

どのようにしてこの状態になりましたか？

基本的に、ヘルムがタイムアウトした後もKubernetesが変更を行っていたため、開発チームは失敗したアップグレードを無視しました。

具体的には、Helm 2を使用しており、tiller-deployデプロイメントにTILLER_HISTORY_MAX=20を設定しています。 RollingUpdateのアップグレードにはすべてhelm upgrade --wait --timeout 1080を使用していましたが、時間の経過とともに時間がかかりました。 その後、ヘルムのアップグレードがタイムアウトになり始めましたが、Kubernetesがまだ正常に変更を行っていたため、誰も心配していませんでした（ただイライラしていました）。 20回のアップグレードがタイムアウトした後（今日）、代わりにapp-name has no deployed releasesが表示されていたため、デプロイできなくなったため、心配しました。

パッチが機能するのはなぜですか？

Helmがおそらく次のようなリクエストを使用してconfigmapをリクエストしていることに気付いたため、configmapのSTATUSラベルにパッチを適用する必要があることがわかりました...

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 deleteは、ほとんどの本番ケースでは受け入れられません
helm3では、暗号化されているためkubectl edit secret sh.helm.release....はできません
helm rollback <latest-successful>は正しい回避策にすぎません

したがって、デフォルトでHISTORY_MAX = 10があり、何かを機能させるために10回試行した場合、完全に失われます...

また、インストールとアップグレードにロジックがある場合は、sh.helm.release ..... v *シークレットを削除できません。

ヘルムは死ぬか、それを修正する必要があります

回避策が見つかりました
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についても同様で、ラベルstatus = deployedを設定します
そしてそれ以前のリリース（v35）の場合はlabel status = supersededを設定します

次のhelm upgrade --install ...は機能します

@ kosta709リリースをすべて大文字のラベルでkube-system名前空間にConfigMapsとして格納するHelm2の私の発見と同様に、Helm3は、すべて小文字のラベルでアプリケーションの名前空間にリリースをシークレットとして格納するようになりました。

したがって、Helm3の場合は、わずかに異なるkubectlpatchコマンドを使用できます...

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現在行っているのは、helmを使用してyamlファイルを生成し、kubectl diff / dry-runを使用して、変更を手動で適用する前にプレビューすることです。

@zrsm現在行っているのは、helmを使用してyamlファイルを生成し、kubectl diff / dry-runを使用して、変更を手動で適用する前にプレビューすることです。

返信のおかげで、2.15.1にダウングレードしましたが、同様の問題が発生しましたが、〜/ .helmを削除してから、kubectlからティラーサービスアカウントを再初期化しました。これを行った後、チャートをkubernetesに適用できました。 。 今日の後半にヘルム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エディションをインストールし、serviceaccountのものが見つからない場合（ラップトップをワイプして、ある時点で復元した場合）、これが発生し、これが修正されたと思います。 それがあなたにも役立つことを願っています。

このバグはHelm3で進行中ですが、修正が計画されていますか？

また、タイムアウトが原因で、新しいクラスターと新しいデプロイメントでこの問題が発生します。 これを修正するためにクラスターに手動で接続するのは好きではありませんが、現在はそれが唯一のオプションだと思います。

この問題ができるだけ早く解決されることを確認できますか？

この問題は非常に苛立たしいので、 helm完全にやめる理由です。

同意する。 これは私を狂わせています。 私はそれを修正することに取り組むつもりです。 幸運を祈ります。

同意する。 これは私を狂わせています。 私はそれを修正することに取り組むつもりです。 幸運を祈ります。

おかげで、幸運を！

何人かでPR＃7653を見てもかまいません。

これで上記の問題が解決すると思います。

メンテナからの反応もなく、まだ開いているなんて信じられない

cc @bacongobbler @mattfarina

ヘルム削除--purge（v2）またはヘルムアンインストール（v3）を使用しても、すべて失敗したリリースであるため、機能しますか？

@hickeymaは常にではありません。 これは、ヘルムリリースメタデータの破損の結果である可能性もあるため、場合によっては、アンインストールによって負荷がかかっているリソースが削除される可能性があります。

時々リリースは失敗しませんが、タイムアウトとヘルムはそれを失敗したものとしてラベル付けします、そして次にそれが展開されたリリースがないと表示されるとき、アプリは実際には完全に機能しています、それは私に何度も起こりました、それで私はリリースを変更しなければなりませんでしたdeployed 1にラベルを付けます。 helm delete --purge (v2) or helm uninstall (v3)を実行することは必ずしもオプションではありません

@rimuszリリースレーベルをどのように変更していますか？

@dudicocoは、helm v3の最新リリースシークレットを手動で編集することで、それを自動化し、 kubectl patchを使用できます。

チャームのように機能するhttps://github.com/k14s/kappに移動しました。

@rimuszそれは私が思ったことです、ありがとう。

また、修正を＃7668のヘルム2にバックポートしましたが、＃7653に関するフィードバックを待っています。

ここで同じ問題、

--waitデプロイされたリリースはタイムアウトし、最終的に稼働しています。 それでも失敗としてマークされます。
そのため、後の展開も失敗しています。

これは、リリースステータスが信頼できる情報ではないことを意味します。

当社では、本番環境の多くのサービスにk8sを使用しています。
月に数回、さまざまなアプリケーションのヘルムで同じ問題が発生します（ " *にはリリースがデプロイされていません。"）。
さまざまなバージョンのヘルムを使用しました（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 （それが問題です！）

ヘルムが、最新の10個のリリース（ステータスに関係なく）に加えて、履歴内の常に保持することは可能でしょうか？

私はその考えが大好きです。 ストレージ機能を変更する必要がありますが、それは可能だと思います。

https://github.com/helm/helm/pull/4978が

私はこれを＃7806でHelm 3に移植しようとしましたが、できるだけ早くマージされることを望んでいます。 ありがとう、@ ultramateboy！

_first_インストールで失敗するリリース、つまり過去に成功したリリースがないリリースはどうですか？
ヘルムリリースのべき等展開にupgrade --installを使用しており、最初のリリースが失敗すると、その後のupgrade --install呼び出しはすべて、「展開されたリリースがありません」エラーで失敗します（この問題）。

「最初のリリースが失敗する」シナリオは、通常は手動で実行または監視するため（そして、その場で修正を適用できるため）、少なくとも管理しやすくなります。これは、失敗し始めたばかりのCI / CDシステムでヘルムを実行するのとは対照的です。日、コードを修正した後でも回復しません。

もちろん、それでも修正する必要があります。

このバグのためだけでなく、とにかく最後に成功したリリースを保持することにも価値があります。 たとえば、値ファイルなどの問題のデバッグ。

@peterholak 「最初のリリースが失敗する」シナリオはCI / CDでも行われることがあります。たとえば、クラスターへのアクセスが制限されており、「ヘルムls」を作成することすらできません。どのように「これを管理」するのでしょうか。

この問題は、ほとんどの人が生産でヘルムを使用していることを考えると、優先度の高い問題であるはずです。 --atomicしてhelmインストールを実行できますが、デプロイする前に失敗の理由を調べたい場合はどうすればよいですか？ インストールが失敗する前にタイムアウトによってタイムボックス化され、その後元に戻ります。 正常にアップグレードできれば、障害を検査するときにタイムボックスを感じる必要はありません。

また、helmリリースのべき等展開にupgrade--installを使用しています。 それが自動化されたci / cdパイプラインの仕組みだからです。 展開パイプラインをバイパスするため、手動でヘルムをいじる予定はありません。

自動展開パイプラインでは、最初の展開はほとんどの場合失敗します。 後続の展開は、最初の試行とは異なる方法でトリガーしてはなりません。

この問題の優先順位をかなり上げることを検討してください。

経験はすっごく悪いです、それが生産中であるので、我々はリリース全体を単に削除することはできません！ サーバーのダウンタイムが発生します。 最終的にこの問題にどのように対処できますか？

また、誰かが質問/サポートラベルを削除してもらえますか？ この問題は、ドキュメントの欠落に関するものではなく、自動展開パイプラインでの使用をあまりサポートしていないHelmの現在の動作に関するものです。

＃7806PRはマスターにマージされました。 3.2でリリースされます。 それに応じて、この問題を解決します。

すごい！ これにより、Helmに関するほとんどの問題が解決されます。

ただし、最初のリリースが失敗した場合（まだデプロイされたリリースはありません）、現在の動作はどうなりますか？

https://github.com/helm/helm/pull/3597によってアドレス指定されたhttps://github.com/helm/helm/issues/3353がありましたが、 --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は、4月16日のパブリック開発コールで議論されます。 私はそれを、現在すぐにまとめることができるように見えるものだけにトリアージしました。 次に、ベータリリースプロセスを開始します（メンテナ全員が明日電話に同意すると仮定します）。

次のコマンドで前述の問題を修正するために、AKS解決で同じ問題に直面していました。

helm version : 3.1.2
コマンドを使用してk8sクラスターからパッケージを削除するだけです
helm delete <release-name>

展開サイクルを実行して問題を修正します

この問題は3.2.0バージョンでもまだ存在します

@deimosfrこれは、リリース3.2.1に含まれる＃7653で修正されています。 まだリリースされていませんが、マスターを構築したい場合は修正を入手できます。

私は3.2.1を使用していますが、これはまだ発生しています

このエラーが発生する理由はまだあります。 3.2.1は単にエラーを取り除くだけではありません。 それはいくつかの原因を取り除きました。 それでも問題が解決しない場合は、問題が修正されたものとは別の問題です。

@yinzara問題のない新しいクラスターの元の説明からの「パスb」の古典的なケースがあります。 Helm v2が正常に機能する別のクラスターでも、このエラーを再現できます。 もちろん、古典的な「これは何かが原因で、新しい問題を開く」ダンスを行うことはできますが、それが実際には修正されていないことを単に認識した方が早いと思います。

helm listの出力は何ですか？ 以前に失敗したリリースの「ステータス」は何ですか？ ヘルム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回目の起動（およびエラー...展開でエラーが発生して失敗したため）が、その「破損した状態」に到達したことを理解しています。 。

この状態は回復できません...したがって、それを修正する唯一の方法は、チャートを削除することです...これを回避するための回避策は、アトミックフラグを使用して常にロールバックし、この「破損した状態」に到達しないようにすることです...

メンテナの決定を理解しています...しかし、これは混乱を招き、解決策はまったくありません（チャートを削除しない場合）。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

私は同じ問題を抱えています： '（そして私はデータを失うのでパージを使うことができません、そしてそれをすることができません、私はこの問題が閉じられていることを知っていますが、私だけが私の痛みを表現しています。

重要なワークロードをデプロイするときは、ヘルムリリースを破棄する必要があります。この理由から、istioのistioctlでさえヘルムを破棄します（私は推測します）。 ヘルムテンプレートを使用しkubctl -f-この問題を回避するためですが、もちろんこれにより、削除されたリソースについて覚えておく必要がある問題が発生します。

@GloriaPGより多くの情報を共有できますか？ 同じ問題をどのように経験していますか？ スレッドで前述した@yinzaraのように、＃7652が修正されない場合があります。 ただし、その結論に達する前に、役立つ情報がさらに必要です。

こんにちは@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フラグが動作していません

これは本番環境であるため、リリースをパージして最初から作成することはできません:(

提案をありがとう

エラーはhttps://github.com/kubernetes/client-go/issues/508に関連しているようです
デプロイメントでセレクターを変更することはできません。 アンデプロイして再デプロイする必要があります。

@yinzara面白いのは、デプロイメントでセレクターを変更していないことです。すべてが9/10リリースで機能しています。 展開中の1つで、リリースが失敗し、リリースが失敗した状態になり、それから回復することができません。展開自体は機能し、ポッドは実行されていますが、変更できなくなりました。

リリースが失敗した状態になった後、helmを使用してそれを変更できなくなるのは少し直感に反します。 フラグ--forceを使用すると、展開全体を置き換えたり、変更を強制的に適用したりできると思いますが、既存のリリースを修正して操作する方法が見つかりませんでした。

残念ながら、これは実際には舵取りの問題ではないようです。 リリースに関して問題が発生し、kubernetesでは状態が悪いです。 セレクターがめちゃくちゃになっているか、何かが期待どおりではない可能性がありますが、「app-name」にリリースがデプロイされていないことについて表示されるエラーは、単なる赤いニシンです。

以前のバージョンへのロールバックを試しましたが、リリースはdeployedステータスになりました。 残念ながら何も変わらないので、残念ながら削除して再度デプロイするしか方法はないと思います。

したがって、これに関する私の特定の問題は簡単に再現できます。

helm3（ --atomicと--cleanup-on-fail ）を使用して何かのデプロイを開始し、リソースの作成を開始した後、プロセスをctrl + cします。 何もロールバックされず、リソースはまだ存在し、その後install --upgradeを実行しようとすると、「リリースがデプロイされていません」というエラーが発生します。

このctrl + cは、本質的に、ビルドがすでに実行されているときに誰かがCIシステムのブランチに新しいコミットをプッシュしたときに発生します。ヘルムのアップグレードはキャンセルされ、完全に壊れた状態になります。

この時点以降に修正するためにできることはありますか？ このスレッドの他の多くの場合と同様に、削除はオプションではありません。

編集：これが壊れると、 helm lsはリリースを表示せず、 helm historyは保留中のインストール状態で表示します。

実際、気にしないでください。 この影響を受けるユーザーには、1つの解決策があります。kubernetesから履歴レコードを手動で削除します。 シークレットとして保存されます。 問題のあるpending-install状態エントリを削除すると、 upgrade --install再度正常に実行できます。

@ AirbornePorcine-保留中のインストールエントリを削除するためにkubernetesで必要な変更について詳しく教えてください。

@ tarunnarang0201 Helmは、デプロイ先と同じ名前空間に、デプロイごとにkubernetesシークレットを作成します。タイプは「helm.sh/release.v1」で、「sh.helm.release.v1.release」のような名前が付けられています。 -name.v1 '。 最新のシークレットを削除する必要があります（例の「v1」サフィックスを見てください。デプロイごとに増分されます）。これにより、ブロックが解除されたようです。

@AirbornePorcineありがとう！

@AirbornePorcine @ tarunnarang0201 @ ninja-ステータスラベルにパッチを適用することもできます...特に以前のDEPLOYEDリリースがない場合はそうです。

Helm 3については、 https： //github.com/helm/helm/issues/5595#issuecomment-580449247で私のコメントを参照して

Helm 2の詳細と手順については、 https： //github.com/helm/helm/issues/5595#issuecomment-575024277のコメントを参照して

この会話は長すぎます...そして各コメントには1つの解決策があります....結論は何ですか？
古いhelm2.12を使用していて、問題が発生したことはありませんが、v3.2.4では、以前に失敗した展開がこのエラーで失敗します。

ちなみにTerraformと最新のヘルムプロバイダーを使用しています。 したがって、 --forceまたは--replaceを使用する必要があります

@xbmonoあるので会話が長い

• リリースがこの状態になる理由はたくさんあります
• これはHelm2でも可能であり、そこで機能したソリューションとHelm3で機能したソリューションは異なります。
• この号のユーザーがそこにたどり着くまでにたどったさまざまな道があります
• 何をしようとしているのか、PVCの損失やダウンタイムのさまざまな組み合わせをリスク/許容できるかどうかに応じて、さまざまなオプションがあります。

「リリースがデプロイされていません」というエラーが発生した場合、 install --replaceもupgrade --install --forceもそれだけで役立つかどうかはわかりません。

賢明な提案はおそらく与えられるだけです

• リリースにhelm history提供して、人々が何が起こったかを確認できるようにすると
• 失敗の元の理由/そこにたどり着くために何をしたか、そして元の問題が解決されたと感じているかどうかを共有する場合

可能なオプションの要約

• 既存のk8sリソースやダウンタイムをまったく気にしない場合は、 helm uninstall && helm installがオプションになる可能性があります
• チャートのインストールが初めて失敗した場合は、リリースシークレットメタデータをhelm install再度削除できます。 --atomicなどを使用したかどうかに応じて、障害が原因でcruftが残った場合は、k8sリソースを手動でクリーンアップする必要があるかもしれません。
• --wait edインストールを途中で放棄し、 helm historyが最後のリリースがpending-installことを示している場合は、最新のリリースシークレットメタデータを削除するか、リリースステータスにパッチを適用でき
• シナリオの特定の他の組み合わせで、それもすることが可能であり得る解放状態にパッチを当て、その後の場合は、1つの以上のリリースの秘密のと見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によって1時間ごとに自動的にデプロイされます。 テラフォームではhelm upgrade使用できません、それはヘルムプロバイダーが行っていることです

テラフォームコードでは、 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だろうか？ したがって、以前のデプロイが失敗した理由は、クラスターがdockerリポジトリと通信できなかったため、 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失敗は奇妙に思えます（タイプミス？名前空間の欠落？ヘルムバージョンの間違い？）が、上記のlistのリビジョン1を考えると、最初にやろうとしているようです新しいチャートの時間インストールと最初のインストールが失敗しました。 ブロックを解除しようとしている場合は、上記のようにリリースシークレットメタデータを削除するか、ステータスにパッチを適用して、再試行してください。 これは、HelmまたはHelm Terraform Providerの観点からはメタデータが悪い状態にあることを示している可能性がありますが、どのようにしてそこに到達したかは示していません。

いずれにせよ、＃7653がマージされて以来、Helm 3.2.1失敗した初回デプロイに対してupgradeを実行することに問題はありません。 プロバイダーが実際に使用している特定のHelmバージョンを再確認することをお勧めしますか？ また、HelmTerraformプロバイダーがinstall失敗後のリリースの状態を把握する方法に関係している可能性もあります。 私はそのプロバイダーの経験がなく、問題が発生するとさらに不透明になるため、個人的にはTFなどの別の宣言型抽象化でHelmをラップすることに賛成しませんが、同じようにさらに掘り下げたいと思うかもしれません。 。

いずれにせよ、上で述べたように、最初の展開が失敗した後、発生したエラーがhas no deployed releasesである場合、 replaceもforceも考えられません。 51人の参加者がいるこの古いクローズドチケットを行ったり来たりすることは、関係者全員にとってそれほど生産的ではないように思われるため、他の介入なしに状況を復活させるのに役立つ可能性があります。

タイプミスはありませんでした。 また、これは、最初の展開かそれ以降かに関係なく発生します。

前述したように、 --waitオプションを使用して、Jenkinsでの展開を待機し、展開が失敗したかどうかを通知します。

タイムアウトに達して展開が成功しなかった場合、 helmは展開をfailedとしてマークし、そのリリースを手動で削除する以外に回復する方法はないようです。 そして、それが怖いので、リリースを自動的に削除したくありません。

したがって、 --waitオプションを削除すると、 helmは、展開に関係なくsuccessfulとしてマークを付けます。

回避策：

今、私は別の解決策を見つけました。 同じ問題があり、自動化が以前と同じようにうまく機能することを望んでいる人のために、これが私の回避策です：

• helmデプロイから--waitオプションを削除します
• このコマンドを使用して、デプロイ先の名前空間のデプロイメントのリストを取得します： kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• splitを使用して、上記のカンマ区切りのリストを配列に変換できます
• 次に、複数のコマンドをkubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}として並行して実行できます（Jenkinsを使用しているため、簡単に実行できます）。
• timeout後、たとえば7m 7分を意味する場合、展開はまだ成功せず、コマンドはエラーで終了します
• 問題が解決しました。

実際、気にしないでください。 この影響を受けるユーザーには、1つの解決策があります。kubernetesから履歴レコードを手動で削除します。 シークレットとして保存されます。 問題のあるpending-install状態エントリを削除すると、 upgrade --install再度正常に実行できます。

あるいは、これは私のために働いた：

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

kubectl -n $namespace delete secret -lstatus=pending-upgrade修正
もう一度ヘルムを実行します。

なぜこれが閉じられているのかわかりません。真新しいHelm3.3.4でヒットしました。 初期インストールが失敗した場合でも、2番目のhelm upgrade --install--forceは同じエラーを表示します。 これらの回避策はすべて機能しますが、

これが最初のリリースであるというフラグを単に追加することを考えた人はいるので、自動的に削除するだけで安全です。 または、「-force-delete-on-failure」のようなものを追加しますか？ 問題を無視しても役に立ちません。

@ nick4fake AFIKそれはPR＃7653によって閉じられました。 @yinzaraはより多くの詳細を提供できるかもしれません。

アップグレード待ちのリリースを上書きしないようにすることは、メンテナによる決定でした。 しかし、すべての回避策はCI / CDパイプラインでは機能しない回避策であるというあなたの声明は真実ではありません。 最後に提案された回避策は、ヘルムアップグレードを実行する前にビルドステップとして追加できます（CI / CDパイプラインでは--forceも使用しません）。 これは、失敗の原因をデバッグできるようにするのではなく、次のリリースをインストールする直前にリリースを削除することを除いて、提案したものと同じ効果があります。

また、自動ビルドで以下を使用して、アップグレードコマンドを実行する前に「保留中」のリリースをアンインストールしました（NS_NAME環境変数をデプロイ先の名前空間に設定してください）。
`` `bash

！/ usr / bin / env bash

RELEASES = $（helm list --namespace $ NS_NAME --pending --output json | jq -r '。[] | select（.status == "pending-install"）| .name'）
if [[！ -z "$ RELEASES"]]; その後
helm delete --namespace $ NS_NAME $ RELEASES
fi

@yinzaraスニペットをありがとう、それはこのスレッドを見つける人にとって非常に役に立ちます。

私の主張はまだ有効です-単にリリースを削除するのは安全ではありません。 単一のリソースに障害が発生した場合、Helmがリリースを強制的にアップグレードできないのはなぜですか？ リリースを新しいバージョンに置き換えることは、完全に削除するよりも良い解決策のようです。 Helmのコアの基本（状態の管理方法など）を理解できないため、理解できない可能性がありますが、最初のインストールが失敗した場合にユーザーに手動で介入させる方がよい理由はまだわかりません。

つまり、このディスカッションスレッドを確認するだけで、人々はまだ問題に直面しています。 このスレッドへのリンクといくつかの提案を含むHelmエラーメッセージにいくつかの追加情報を追加する可能性についてどう思いますか？

@ nick4fake 「失敗」と「保留中のインストール」を

図書館のメンテナは、失敗したリリースについてあなたに同意します。それが彼らが私のPRを受け入れた理由です。

「失敗した」リリースはアップグレードできます。 それが私のPRがしたことです。 リソースの1つが失敗したためにリリースが失敗した場合は、そのリリースをアップグレードするだけで（つまり、upgrade --installも機能します）、「app-name」にリリースがデプロイされていないというエラーは表示されません。

あなたは「保留中のインストール」リリースについて話している。 メンテナは、保留中のインストールリリース（強制またはその他）をアップグレードできるようにするのは安全ではないと考えています。これは、まだ進行中であるか、自動的に解決できるとは思わない部分的に完全な状態になっている可能性があるためです。 私のPRは当初この状態を許可し、メンテナは私にそれを削除するように依頼しました。

この状態のリリースを見つけた場合は、デプロイメント構成を再検討することをお勧めします。 これは、適切に構成されたCI / CDパイプラインでは発生しないはずです。 失敗するか成功するはずです。 「保留中」は、インストールがまだ処理中にキャンセルされたことを意味します。

私はメンテナではないので、あなたの提案に対する私の意見は無関係ですが、実際にエラーやメッセージで出力されるGithubの問題についての言及がコードベースに見つからないので、彼らはそれを許可しないと思いますが、あなたは'PRをまとめて参照してください:-)

そうは言っても、私はあなたの主張がまだ有効であるというあなたの声明に同意しません。 私の提案は保留中のリリースを削除する可能性がありますが、あなたの直前の@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から見ることができます