Helm: `helm upgrade --install`は、最初のインストールが失敗した場合、インストール/アップグレードを実行しません

これは、 https：//github.com/kubernetes/helm/pull/3097の設計による意図的なもの

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

最初のリリースが失敗した状態になった場合は、 helm delete --purge fooを介してリリースをパージし、再試行することをお勧めします。 最初のリリースが成功した後、その後の失敗したリリースはすべて無視され、helmは最後に成功した既知のリリースと差分を取ります。

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

提案された修正は、自動化されたシステムでは完全に受け入れられないようです。 ヘルムを呼び出すすべての人に、「最初のリリースが失敗した場合は、削除して再試行する」ことを知られたくないのは間違いありません。 一つには、私のツールのほとんどは、それがインストールなのかアップグレードなのか、あるいは初めてか100回目なのかを認識しておらず、ほとんどの場合、 helm upgrade --install実行しているだけです。

また、元のPR https://github.com/kubernetes/helm/pull/3097#discussion_r151808599にコメントして、このケースについて具体的に質問したことも伝えたいと思い

この場合、古い動作の方が優れていました。
@chancezに同意します。 これにより、 upgrade --installは一般的な発生に対してべき等ではなくなります。

@bacongobbler
リリースが失敗し、フックが失敗したために破片が残ることを心配している場合、それはチャートの設計上の問題だと思います。 （フックはべき等である場合にうまく機能します）
ユーザーは、舵の周りでエラー処理と非べき等の動作を自由に構築できます。

他にどのようなエッジケースが懸念されますか？
＃3097が大事にしているようです👍

少なくともいくつかの引数の組み合わせについて、失敗したリリースに対してもhelm upgrade -iべき等にすることができれば、私のローカル開発ははるかにスムーズになります。 私のユースケースは、ローカル開発環境を開始するために立ち上げたいとわかっている多くのリリースのスクリプトがある場合です。

これは、 helm installの--replaceフラグに類似している可能性があります。 なお、 --replaceから2つのだけのフラグの一つであるhelm installで欠落しているhelm upgrade 、他方は--name-template 。

完全に明確にするために、はい、これは修正するのに良いことです。 私たちが他の仕事でいっぱいになっている間に、誰かがそれをクラックしたいですか？

こんにちは、
この問題を修正するPRhttps：//github.com/kubernetes/helm/pull/3437を作成しました

installコマンドとupgradeコマンドが必要な理由がわかりません。 upgrade --installコマンドしか使用しておらず、多くの人が同じことをしているようです。 upgrade --installを実行し、失敗した実行をトリップしないコマンドが1つ必要です。 upgrade --install名前をdeploy 、それを真にべき等にして、他の2つを捨てることはできますか？

（私は2.8.0でこの問題の動作を新しいバリアントで苦労しています。インストールに失敗した場合は2.7.2からアップグレードしてから、 delete --purge 、そしてupgrade --install 、まだError: UPGRADE FAILED: "xyz" has no deployed releasesエラーが発生する可能性があります。2.8.0では--purgeが完全に有効ではなく、耕うん機のスタック状態がlist --allに表示されないようです。次に、 installして、耕うん機を通常のupgrade --install再度実行できる状態に戻します。）

@whereisaaronに同意します。 kubectl applyように機能するdeployコマンドがあればいいのですが。 一部のシェルスクリプトの狂気に存在するリリースをチェックする必要がないため、Helmの自動化もはるかに簡単になります:)

おそらく解決策は、ヘルムに自動的にhelm delete --purge実行させることですか？
何かのようなもの：
1）ユーザーがhelm upgrade --install実行します
2）最初のリリースが失敗する
3）ユーザーがチャートにいくつかの変更を加え、 helm upgrade --installを再実行します
4）ヘルムはコマンドを実行しようとします
5）失敗し、失敗した状態の以前のリリースが1つだけあります
6）ヘルムはサイレントにhelm delete --purge
6）パージ後、Helmはhelm upgrade --installを自動再試行し、そこからの出力を表示します

おそらく、この動作は、他のシナリオでも同様の動作をしている--forceフラグを介してトリガーされる可能性があります。

良いアイデアが、私たちはこれまで、ユーザーが明示的にそのデータを削除するために求めず、リリース台帳を削除する必要はないと思います。 Helmのオペレーターは、サービスが以前に失敗したリリースからアップグレードできなかった理由を知りたい、または元帳からそのデータを収集して失敗を推測したいと思うでしょう。

この問題の解決策を説明するコメントをスレッドの前半で提供しました。 実行中のソリューションに似ていますが、リリース元帳全体を削除する必要はありません。 ＃3437はそのソリューションをパッチとして適用しようとしていると思います。

@rchernobelskiyは私にも起こります。 あなたが説明する通りです。

新しいアプリをデプロイするときに、おそらく1日に1回この問題が発生します。
痛い！

@gmanolacheこの理由で、私たちはまだ舵取り2.7.0を使用しています。
--forceフラグを使用するようにアップグレードしても安全かどうかはわかりません：コメント

ダウングレードする必要がある場合は、次の良い方法があります。2.7.0にダウングレードします。

この便利なサウンドの「ヘルム台​​帳」診断情報とは何ですか？また、どのようにしてそれを取得しますか？ ：スマイル：

以下が不機嫌と読まれるのではないかと心配しています。これは、デプロイに失敗したときに診断情報を取得する方法についてのポインタへの単なる招待です。 何かが足りないように聞こえるからです。 失敗国家はオペレーターにとって何らかの有用性があると思われますか？ 私は再び舵取りマニュアルサイトをトロールしました。 「helmgetmanifest」のようなものは失敗した状態で機能して有用な診断情報を抽出しますか？

展開に失敗したときの私のユーザーエクスペリエンスは、有用な情報が得られないことです。 Helmは、「helm status」に何も表示されないように、部分的に作成された/残っているすべてのリソースを否認します。 実行できるのは、「rollback」または「delete --purge」だけです（「delete」だけを実行することはできません。そうしないと、CIの「upgrade--install」が失敗し続けます）。 失敗国家は、私たち全員がCI展開に切望している「upgrade--install」のべき等性を破るのに役立つように思われます。

CIの状況に「--auto-rollback」オプションを設定するのは合理的でしょうか。たとえば、「upgrade --install--auto-rollback」などです。 私は通常、失敗国家に対処するためにベッドから出なければならないロールバックを望んでいます😆😴💤

この便利なサウンドの「ヘルム台​​帳」診断情報とは何ですか？また、どのようにしてそれを取得しますか？ 😄

helm help history

@bacongobblerに感謝します。 わかりました。リストが元帳の意味するところだと理解しています。 また、元帳がまだある場合は、 helm get manifest --revision 123を使用して、何が展開され、失敗したかを確認できますか？ それは確かに保存するのに役立ちます。 そして、 rollbackあれば、その情報を失うことはありません。

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

helm upgrade --install --auto-rollback場合、失敗した展開の両方が元帳に記録され、オペレーターが利用できるようになります。 そして、それは、CIデプロイメントが「helmupgrade--install」が機能しなくなる「失敗した」状態になるのを防ぐのに大いに役立ちます。 失敗したCIデプロイメントは通常、開発者がデプロイメントシステムにタイプミス/間違いを挿入することです。 '--auto-rollback'を使用すると、デプロイメントサーバーログに保持されているhelmコマンドエラーメッセージを検査し、修正してデプロイされた修正値を確認できます。

'--auto-rollback'オプションがなくても、ラッパー自動化を使用して、 helm update --installが 'FAILED'エラーを返すたびにhelm rollbackを実行できると思います。 そして、おそらくそれが最初のインストールである場所を検出し、そのような場合は代わりにhelm delete --purgeを検出します。

つまり、ラッパースクリプトを作成して、CIの「helmupgrade --install」の結果が、次のCIの「helmupgrade--install」が常に可能な状態になるようにすることができます。 失敗した試行の元帳情報を保持しながら（少なくとも最初のインストールが機能したリリースの場合）。

helm deploy =

• helm upgrade --install
• 失敗した場合
  
  
  
  • リビジョン= 1の場合
  
  
  • 次にhelm delete --purge
  
  
  • それ以外の場合helm rollback
  
  

エレガントな@whereisaaron👍

helm history ${name} | tail -2 | head -1 | awk '{print $1}'ようなもの以外に、 helm rollbackで使用される最新の作業リリースを入手する簡単な方法はありますか？

こんにちは、

Helm 2.12.2を使用していますが、最初の展開が失敗すると、helmが失敗するという問題がまだあります。 これはおそらく回帰ですか？

リグレッションかどうかはわかりませんが、実際に「修正」されたことはありません。

@ RickS-C137これは、失敗したリリースを「削除」してから「インストール-置換」するhelm upgrade --install --forceを使用することで修正されるはずだと思います。

私が使用しようとしているJenkinsパイプラインでこの問題を修正しようとしています。
アプリケーションの新しいイメージをデプロイしようとしていますが、デプロイメントがすでに存在するかどうかは気になりません。
現在のデプロイメントを置き換えるか、存在しない場合は単にインストールするコマンドを1つ実行したいと思います。
私が試したhelm install --replace私は、多くの場合、取得Error: a released named xyz is in use, cannot re-use a name that is still in use 、明らかに私のパイプラインを殺すと、ビルドに失敗しています。

@bacongobbler https://github.com/helm/helm/issues/3353#issuecomment -385222233に​​ついてどう思いますか？

初期リリースが失敗した場合に初期リリースを破棄して再作成した場合、ダウンタイムやデータ損失がどのように発生するかわかりません。

私はこれをビルドに実装しました：

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

現在helmを使用している場合、現在の状態を調べないと、どのhelmコマンドとオプションの組み合わせを使用するかがわかりません。 また、特定のヘルムコマンドについては、現在の状態に依存するため、何を取得するのかわかりません。 それは実際には宣言的な望ましい状態の夢ではありません☁️💤😄

ヘルム3では、 install / upgrade / --replace / --upgrade / --forceを非推奨にし、それらすべてをべき等helm deploy置き換えることができます。 上記と同様のアルゴリズムを使用して、 helm deployが失敗した場合、ロールバック（リビジョン> 1）または削除+パージ（リビジョン= 1）して、以前の状態のままにします。 失敗したマニフェストは、引き続きhelm history/getから入手できます。 また、調査のために展開を失敗した状態で保持したい人のために、「-no-rollback」オプションもあります。

helm upgrade --install --forceのオプションが近づいていますが、ロールバックしてアップグレードするのではなく、失敗したリリースを削除して置き換えます（リビジョンが1より大きい場合でも）。これにより、一部の人々は＃3208に腹を立てます...😮⚡️ 💥

今のところ、ラッパースクリプトまたはhelmsmanようなメタツールを使用できます。その機能リストの一部はhelmいますが、この問題は軽減されています。

• べき等：目的の状態ファイルが変更されない限り、Helmsmanを数回実行して、同じ結果を得ることができます。 _ [...現在の状態に関係なく] _
• 失敗から続行：特定のチャート展開​​の失敗が原因で部分展開された場合は、最初に部分的な成功をロールバックする必要なしに、ヘルムチャートを修正してヘルムスマンを再度実行します。

それらすべてを、目的の状態を達成するか、状態を変更しないままにするべき等ヘルム展開に置き換えます

振り返ってみると、これは息を呑むほど明白な設計目標です。

こんにちは、
私たちの場合、最初のリリースは実際には失敗しませんでした...インストールタイムアウトが経過したときにアプリケーションが完全に起動していなかったか、その他の奇妙な問題が修正されただけです。 いずれにせよ、アプリケーションは完全に正常に実行されているため、削除する必要があることは私たちにとって問題になります（永続ストレージが接続されていて、それも削除されます!!）。

最初のリリースが「明らかに失敗した」ときにチャートをデプロイするための回避策はありますが、実際には問題ありませんか？

それで、 upgrade --forceが強すぎるという結論はありますか？つまり、delete + replace + replace_upgradeがアップグレードの失敗に対する正しい救済策ではない場合がありますか？

installとupgradeをdeployコマンドにマージするというアイデアを追跡する別の問題はありますか？

@dcowを知っているわけではありません。 helm upgrade --installコマンドの使用例は何ですか？

https://github.com/helm/helm/issues/3353#issuecomment -362497951

installコマンドとupgradeコマンドが必要な理由がわかりません。upgrade--installコマンドのみを使用しており、多くの人が同じことをしているようです。 必要なのは、upgrade --installを実行し、失敗した実行につまずかないコマンドを1つだけです。 upgrade --installの名前を変更してデプロイし、真にべき等にし、他の2つを捨てることはできますか？
..。

そして

https://github.com/helm/helm/issues/3353#issuecomment -469109854

現在helmを使用している場合、現在の状態を調べないと、どのhelmコマンドとオプションの組み合わせを使用するかがわかりません。 また、特定のヘルムコマンドについては、現在の状態に依存するため、何を取得するのかわかりません。 それは実際には宣言的な望ましい状態の夢の雲zzz笑顔ではありません

ヘルム3では、インストール/アップグレード/ --replace / --upgrade / --forceを非推奨にし、それらすべてを、目的の状態を実現するか、状態を変更しないままにするべき等のヘルムデプロイに置き換えることができます。
..。

私は一般的に、ヘルムがkubectl applyように機能し、クラスターの状態に応じて異なるタイプのコマンドを実行する必要はなく、目的の現実を達成しようとすることに同意します。 deployが現在実装されておらず、私たちが舵取りをしているので、専用の問題が存在する場合、または少なくとも解決策が何であるかを理解する場合は、専用の問題にサポートを追加することを望んでいました。

@dcowわかりました、それではあなたの提案で問題を作成しますか？

@hickeyma完了https://github.com/helm/helm/issues/8415！