<p>helm upgrade--installは機能しなくなりました</p>

同じ問題が発生していると思いましたが、古い削除（パージされていない）があり、リリースがぶら下がっていたことがわかりました。 helm list -aを確認し、リリースが存在する場合は、helm delete --purgereleasenameを確認します。 helm upgrade -iは2.7.2で正常に動作しています。

これは、悪い状態にあったリ​​リースのアップグレードに関する問題を修正することの副作用です。 https://github.com/kubernetes/helm/pull/3097がこの問題を修正したPRでした。 ここでキャッチできなかったエッジケースはありますか？

@tcolgateが述べたように、 helm list -aを確認してください。おそらく、それを再現する方法も説明しているので、それがキャッチされていないエッジケースなのかバグなのかを判断するのにも役立ちます。

また、同じ問題があり、リリース名が重複しています。

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

アップグレードするときに、どのようなメッセージが表示されましたか？

上記のdiffと同じエラーですが、インストールすると、すでにインストールされていると表示されます。

つまり、以前のアップグレードの試行では、FAILEDステータスになりました。 すべてのリリースが失敗状態になっている状況にどうやって入るのか知りたいです。

ああ、重複したリリース名の展開ですか？ よくわかりませんが、よくわかります。 それらがすべてDEPLOYED状態にある場合もあれば、FAILEDとDEPLOYEDが混在している場合もあります。 すべてのPRマージを常に更新するCI / CD Jenkinsサーバーを使用しているため、通常は新しいコンテナタグのみを使用して1日に数helm upgrade 'を実行します。 通常、重複は展開されたものを見ると煩わしいだけです。これは、私たちがそれらに難しい問題を抱えたのは初めてであり、通常、この場合のように入力コントローラーをアップグレードしません。

私は似たようなものになってしまったようです。リリースリストにいくつかの重複があります。

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

それらはすべてDEPLOYED状態にあるように見えますが、私がそのバグを数回ヒットしたため、以前のアップグレードがいずれかの時点で失敗した可能性があります。 私はまだK8S1.7を使用しているので、まだhelm2.7に更新していません。

同じ問題、失敗したデプロイをアップグレードできません

ここでは2.7.2を使用して同じです。 リリースの最初の試行は失敗しました。 次に、upgrade --installを実行しようとすると、「エラー：アップグレードに失敗しました：「$ {RELEASE}」にはデプロイされたリリースがありません」というエラーが発生します。

ここで2.7.2と同じ問題が発生し、 helm upgrade --install場合に失敗します。

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

リリースがhelm del --purge APPNAME完全にパージされた場合、後続のupgrade --installは正常に機能します。

同じ問題が発生しています。 回避策のスクリプトなしで自動べき等展開のオプションを残さない＃3134と組み合わせる。

@winjerは--purgeを使用して削除しようとしましたが、エラーが変更されても機能しませんでした
/＃helm upgrade foo / charts / foo / -i --wait
エラー：アップグレードに失敗しました：「foo」にはデプロイされたリリースがありません
/＃helm delete --purge foo
リリース「foo」が削除されました
/＃helm upgrade foo / charts / foo / -i --wait
リリース「foo」は存在しません。 今すぐインストールします。
エラー：fooのリリースに失敗しました：deployments.extensions "foo-foo-some-service-name"は既に存在します

@preinこれは、helmによって「所有者」ではないが、クラスターにすでに存在するサービスがあるためです。 あなたが経験している行動は私には正しいようです。 ヘルムは、以前は所有していなかったAPIオブジェクトの「所有権を取得」する必要があるため、デプロイは成功しません。

新しいマニフェストが実際に正しく、クラスター内の他のリソースに満足していない場合は、FAILEDリリースをアップグレードできることは理にかなっています。

contentというリリースでもこの動作が見られます：

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

デプロイを続行できるようにするには、これを削除する必要があります。これをデバッグするためにできることがあればお知らせください。
（重複に関する問題なので、問題の名前を変更する必要があると思いますか？）
（ 2.7.2も実行します）

デバッグに役立つコマンドを実行するためのコマンドがある場合、実際にはクラスターに別の重複リリースがありますか？ お知らせ下さい！

ティラー2.7.2にアップグレードしたところ、同じことがわかりました。 helm delete RELEASE_NAMEが続くhelm upgrade RELEASE_NAME .で失敗Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases 。 upgradeは、削除された（ただしパージされていない）リリースを復元するための意図された方法ですよね？

削除したバージョンにロールバックすることで、リリースを復元できるようです。

v2.7.2で同じ問題が発生し、以前に正常にデプロイされたリリースがない場合は失敗します

また、この問題の2つの潜在的なバージョンが表示されます。

CIの場合：

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

私のローカルマシンで：

（私のOSXbashとgcloud / kubectlコンテナの両方で）

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

警告は、チャートでは正常です。
サブチャートの1つにpvc.yamlれているため、エラーは興味深いものです。

helm del --purge <release>は問題を軽減します。
これにより、CIパイプラインのアップグレードが困難になります。

@adamreeseこの問題の最終的な解決策は何ですか？ 現在2.8を使用していますが、以前のFAILEDリリースをhelm list変更してアップグレードすることはできません。

特に、次のタイプの問題が発生しています。

• リリースをデプロイします、OK
• upgrade --install --waitですが、小さなバグがあり、 --waitが成功しない可能性があります（たとえば、活性プローブがそれを補うことはありません）
• チャートを修正した後、 upgrade --install --waitはxxx has no deployed releases失敗します

ここでは、削除/パージは望ましくないか、受け入れられません。リリースには、上昇しない1つのリソースの影響を受けない複数のリソース（ポッド、ロードバランサー）が含まれている場合があります。 以前のHelmバージョンでは、 upgrade --install使用すると、すべてのリソースを削除せずに、完全なリリースを壊した変更にのみパッチを適用できました。

Helmは、ここで常に関係するすべてのリソースの所有者です。 --waitがすべてのリソースが良好な状態になるのを待つことに成功しなかったため、リソースはFAILEDとのみマークされます。 ポッドの起動が少し遅すぎる場合や、多くの同様のケースで同じことが起こると思います。

@peayフォローアップディスカッションについては、＃3353を参照してください。

ありがとう-それはそれをクリアします。 そもそもリリースが成功しなかったときだけ、私たちはそれを打っていたことに実際に気づきました。 その場合、パージは適切な回避策です。

これは、インストールが失敗した場合でも発生します。
パージして再試行する必要があります。

UPGRADE FAILED: "API" has no deployed releases
次に、手動でパージする必要があります
helm delete --purge API
そしてそれは動作します。

helm 2.9以降では、 helm upgrade --install --forceも実行できるため、パージする必要はありません。 以前のリリースの場合：

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

@bacongobbler私はまだこの振る舞いについて混乱しています。
時間があるときにhttps://github.com/kubernetes/helm/pull/3597#issuecomment-382843932に回答できますか？

これにご協力いただきありがとうございます。

もちろん。 私は現在AFKですが、今晩遅くに答えることができます。 混乱を完全に理解し、私はあなたの質問にできる限り答えようとします。 KubeConEUのために他のものを準備しているオフィスに夢中です。 :)

私はこれをハックしたり、ドキュメントを改善したりするのを手伝ってくれます。
絶対に会いましょう：+1：

@bacongobblerはこのアドレス＃3353を実行し、＃4004の一部として記述した

私の場合、 helm upgrade --install --forceはdelete --purge 、その後インストールしました。

これは予想される動作ですか？ このため、私はほぼ2か月の仕事を失いました。 forceがdeleteを意味し始めたのはいつですか？

^ kubeconの人々と会話をしたところ、この動作の変更により、かなりの数のチームがv2.7.0に固定されていることがわかりました。

--forceが何を意味する場合でも、 upgrade installが決して破壊的であってはならないことに同意します。

@bacongobbler 、申し訳ありませんが、CPHに出ていたときに会うことができませんでした。
失敗したリリースのアップグレードを許可しないように動作を変更する理由の背後にあるドキュメントはありますか？
古い動作は、現在の動作よりもはるかに望ましいようです。

その変更を行う必要がある理由の背景コンテキストについては、 https：//github.com/kubernetes/helm/issues/3353の2番目のコメントを参照して

今後の提案案を聞いて本当に興味があります。 ＃3353で示された問題のため、＃3097を取り消すことはできません。そのため、この問題を修正するための正しい道であるとコミュニティが考えていることを聞きたいと思います。 ＃3597を取り消すことはできますが、私が聞いたところによると、 helm upgrade --install問題を修正するための良い解決策はありません。 ：残念だった：

Helm 3の適用ロジックの再作成に取り組んでいることはわかっていますが、それは遠い道のりです。

その@bacongobblerをリンクしてくれてありがとう:)
ここでのあなたの提案は、合理的なアプローチのように聞こえます。

成功したリリースがデプロイされていない場合は、差分を実行しないことが重要な場合があります。 差分をとる「現在の」リリースがないという意味で、ユーザーが初めてhelminstallを実行した場合と同じエクスペリエンスになります。 ただし、特定のエッジケースについては少し心配します。 @adamreeseこれについて何か意見はありますか？

これにより、＃3597を取り消すことができます。これは、唯一の障害ケース（相違点がない）に対処するためです。
これにより、 upgrade --install再び非破壊になり、 kubectl apply似たものになります。

直感的には、それがupgrade --forceに期待されることです。差分とパッチの操作は行わず、現在の場所を無視して、完全なテンプレートを適用するだけです。 これが不可能な技術的な理由はよくわかりませんが、ヘルムの内部の仕組みについてもよく知りません。
それでも危険な操作になる可能性がありますが、 --forceフラグを使用する人は通常、更新を強制することで特定のリスクを予期します。 私は主張しますが、これによってデプロイメントが削除および再作成されることはなく、ダウンタイムが発生する可能性があります。

ディスカッションを読みましたが、べき等のupgrade --installコマンド（または一連のコマンド）を使用する方法がまだわかりません。

現在の安定バージョンでは、自動スクリプトでこれをどのように実現できますか？ 以前の試行が失敗した場合でも、 delete --purgeを使用せずに非対話的にデプロイできる必要があります。

将来の計画に関しては、これは私が最初にupgrade --installから期待した動作です：

• 以前にインストールが行われなかった場合はインストールします
• 以前に成功したインストールをアップグレードする
• 以前に失敗したインストールを置き換える
• インストールが失敗した場合でも、可能な限りダウンタイムが発生することなく、古いリソースがそのまま残っているはずです。
• 破壊的な操作はありません（上記の自動delete --purge ）

私の個人的な意見では、この動作に追加のフラグは必要ありません。 これは、パッケージマネージャーが一般的にどのように動作するかです。 要件を誤解しない限り、たとえば--forceフラグは必要ないと思います。

これに関する更新はありますか？ 何かが失敗した場合にパージを実行することなく、既存のインストールでアップグレードを確実に実行する適切な方法は何ですか？

@MythicManiac FWIW：
この動作のため、チームはまだv2.7.0に固定されています。
このバージョンでhelm upgrade --installを使用することになっている場合、リソースのアップグレードと削除に問題はないようです。

この問題もあります。 ヘルムがhas no deployed releasesため、K8sサービスと関連するAWSELBを削除する必要があるのは非常に面倒です。 パッケージマネージャーは素晴らしいですが、この問題は生産のダウンタイムにつながり、それは良くありません。

非常にハッキーな回避策として、オリジンデプロイの問題が
解決可能（例：既存のサービス）、元のサービスへのロールバックを実行
失敗したリリースは機能します。

2018年10月5日金曜日、18：13 Eugene Glotov、 notifications @ github.comは次のように書いています。

この問題もあります。 K8を削除する必要があるのは非常に面倒です
helmにはリリースがデプロイされていないため、サービスと関連するAWSELB。 The
パッケージマネージャーは素晴らしいですが、この問題は生産のダウンタイムにつながります
よくない。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/helm/helm/issues/3208#issuecomment-427436187 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
。

@tcolgate 、ありがとう！ 回避策に関する別の問題（https://github.com/helm/helm/issues/2426#issuecomment-427388715）を修正しました。来週、既存のリソースに新しいグラフを展開するときに、既存のELBをテストしようとします。 。

失敗した元のリリースへのロールバックを実行すると、機能する可能性があります。

@tcolgate 、テストしたばかり

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

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

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

Helmが既存のリソースにグラフをデプロイできない場合、なぜhelm deleteによってこれらのリソースが正確に削除されるのでしょうか。

@ thomastaylor312 、〜https ： //github.com/helm/helm/issues/2426〜 （上：2426の本当の根本原因を見つけました）。 再開すべきだと思いますか？

Error: UPGRADE FAILED: "xxx-service" has no deployed releases後にこのスレッドを見つけました
それは舵から見えたがls-a。

--set値が正しくないために問題が発生したかどうかを確認することにしましたが、-debug --dry-run--forceは実際には実行中のポッドを削除しました...ドライランアクションは決して変更されないことを期待していましたクラスターリソース。

それでも機能し、サービスは後で再デプロイできましたが、ダウンタイムが発生しました。

私の期待は、ドライランアクションがクラスターリソースを変更しないことでした。

これは公正な期待です-私たちはそれをする必要があります...起こらない

https://github.com/helm/helm/pull/4402でパッチが適用されたと思い

2.11.0にアップグレードした後も同じ問題

クロスポスト：
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

なぜこれは閉鎖されているのですか？ これを処理する適切な方法はありますか？

@gerbsen 、非破壊的なHelmの現在のバージョンではこれを回避する方法はありません。
私たちは今でも私の組織のすべてにHelm2.7.0を使用しています。 他のバグがある非常に古いバージョンですが、この問題はありません。

helm upgrade --install --force delete --purgeを実行させ、（リサイクルについて）通知せずにpvc / pvを破棄しました。 いくつかのリリースが失敗したため、kubernetesで実行されている状態でしたが、ヘルムは実行中のリリースがないと考えました。 まったく良い時期ではありません。

@notqueすべてのgrafanaダッシュボードを2回失った後、あらゆる種類のアップグレードを行う前にバックアップを開始しました。この種のリスクがあると、helmを使用する利点がすべて失われます。

助けを求めている人のために、helmをv.2.15.2にアップグレードした後、問題はなくなりました

2.16.0まだこの問題が発生しています

なぜまだ閉鎖されているのですか？ 2.16.1はまだ影響を受けています

@ nick4fakeそれはhttps://github.com/helm/helm/issues/5595の複製だと思い