Helm: アップグレードに失敗しました：「」という名前のリソースが見つかりません

依存関係がバンドルされたグラフがあるという同様の問題が発生しています。 新しい依存関係を追加してhelm upgradeを実行すると、結果は説明と同じになります。 リソースは適切に作成されますが、helmはエラーを返します。

したがって、これがインストールされている場合： helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

次に、依存関係として新しいグラフが追加されます。

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

リリースを次のようにアップグレードすると、 helm upgrade my-release my-thingヘルムは次のエラーを生成します。

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devthこの問題をマスターで再現することはできません。 あなたはまだこの問題を見ていますか？ どのバージョンのヘルム/ティラーを実行していますか？

ありがとう！

@elementalvoidマスターで新しい依存関係エラーを再現することもできませんでした。 あなたはまだこの問題を見ていますか？ どのバージョンのヘルム/ティラーを実行していますか？

ありがとうございました。

当時、私はアルファ4を使用していました。アルファ5と@devthの例を使用すると、問題を再現することもできませんでした。

了解しました。 とりあえずこれを閉じます。 これらの問題のいずれかが再度発生した場合は、遠慮なく問題を報告してください。

再度、感謝します。

@michelleNありがとう！ 申し訳ありませんが、今週はマスターで再現を試みる時間がありませんでした。 すぐにアップグレードするのを楽しみにしています！

hostPath Deployment / Volume仕様をPVCに移動するときも同じです。
バグは、アップグレードマニフェストが新しいマニフェストに依存している場合のようです（古いマニフェストに「欠落」していますか？）
バージョン：2.7.2

奇妙なことに、バージョン2.7.2のチャートを新しい役割でアップグレードしようとすると同じ動作が見られます。 Tillerは、実際に役割を作成したにもかかわらず、役割が見つからず、展開に失敗したと不平を言います。

私の状況は、新しいリソースがあり、新しいリソースを使用して新しいバージョンのヘルムチャートを展開したことです。 その展開は失敗しましたb / c私はいくつかのyamlを太く指で触れました。 さて、新しいオブジェクトはkubernetesで作成されました。 yamlを修正し、チャートでアップグレードを再度実行すると、リソースが見つからないというエラーメッセージが表示されます。 kubernetesにアクセスして、失敗したデプロイによって作成された新しいリソース（私の場合はロールとロールバインディング）を削除する必要がありました。 その後、現在のオブジェクトが存在するかどうかを確認するヘルムチェックが失敗し（https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257）、リソースが作成されます再び。 バグのようですが、失敗したチャートの新しいリソースをどこで説明する必要がありますか？

アップグレード中に同様のエラーが発生する：

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

構成マップが作成されます

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

私のconfigmap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

同じ問題があります。

リリース全体を削除してから、再度インストールしました。 現在は動作しているようです。

$ helm del --purge bunny

私もこの問題を抱えています

クライアント：＆version.Version {SemVer： "v2.8.0"、GitCommit： "14af25f1de6832228539259b821949d20069a222"、GitTreeState： "clean"}
サーバー：＆version.Version {SemVer： "v2.8.0"、GitCommit： "14af25f1de6832228539259b821949d20069a222"、GitTreeState： "clean"}

これはヘルムの使用で頻繁に発生し、完全な--purgeです。 それは解決策ではありません。

CI / CDを使用している場合は適用されません。
アップグレードが失敗し、ローリング更新戦略を使用するとどうなりますか。 まだ機能しているリリースを削除する必要がありますか？

デプロイメントの問題などがあるが、secret / cmが作成されたが、Helmがそれを追跡できなくなり、多くのことを実行できない場合にも、同じ問題が発生します。

壊れていないリリースでも発生することはめったにありませんが（つまり、完了したように見えます）、何が原因であるかはまだわかりません。

既存のヘルムデプロイメントにリソースを追加するときに、この問題（サーバーv2.8.2）を再現することもできます。 新しいリソースを追加する必要があるたびにデプロイメントを削除して再デプロイする必要があることは、本番環境では大きな問題になります。

私たちの場合、構成マップをチャートに追加していましたが、チャートは次のようにアップグレードできませんでした。

エラー：アップグレードに失敗しました：「」という名前のリソースがありません"見つかった

注：2.7.2を使用しています。

これは、helmが何が変更されたかを判断するときに、古いリリースの新しいconfigmapリソースを探し、それを見つけられないために発生すると思います。 このエラーの原因となるコードについては、 https： //github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276-L280を参照して

失敗したアップグレードの耕うん機ログ：

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

この問題は、デプロイされたサービスのnameラベルを変更するときにも発生します。おそらく、他のことも同様です。

リリースでサービスの名前を変更していますが、次の方法でアップグレードできません。

エラー：アップグレードに失敗しました：「new-service-name」という名前のサービスが見つかりません

この動作を修正するためにPRを作成したいと思いますが、これを処理するための意図された方法または提案された方法を知りたいです。 --forceを優先できるCLIフラグでさえ素晴らしいでしょう。

重要性について同意します。

デプロイメントを単純に削除できない場合、この問題は奇妙なものになる可能性があります。

問題はデプロイの失敗が原因であることがわかりました。

Helmは、デプロイが失敗した後のクリーンアップを試みません。つまり、上記で追加した新しいConfigMapのようなものが作成されますが、「前の」デプロイには参照がありません。 つまり、次のデプロイが発生すると、helmはk8sでリソースを見つけ、それが最新のデプロイされたリビジョン（または何か。「以前の」リリースを見つけるために使用する正確なロジックがわからない）で参照されることを期待して、何をチェックするかを確認します。変更があります。 そのリリースには含まれていないため、リソースを見つけることができず、失敗します。

これは主に、デプロイが失敗するとk8がヘルムが適切に追跡しない状態になるため、チャートを作成するときに問題になります。 これが起こっていることを理解したとき、k8sからConfigMapを削除して、デプロイを再試行する必要があることがわかりました。

@krishicksはい、これはそれを再現する1つの方法です。 失敗したデプロイ+作成されていないリソース（つまり、無効なconfigmap）も、これを引き起こす可能性があります。これは、回復不能な状態につながります。

私たちもこれを打っています。 @krishicksと@jaredallardが言及しているのと同じ問題です。

1. 展開に失敗しました：
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. それ以降の変更は、他のリリースに対しても、次のような警告で失敗します。
   Error: UPGRADE FAILED: no Service with the name "…" found

helm upgrade --timeout …フラグを使用して最初の問題を軽減しようとしますが、すべてをブロックする展開の失敗は私たちにとってかなりの問題です。 また、 helm rollback …してもこれは解決されません

helm upgrade …はユースケースで自動的に実行されるため、 helm upgrade --auto-rollbackフラグは非常に役立ち、失敗した変更を元に戻します。

これは、v2.7.2でチャートに新しいリソースを追加するときに発生します。
これに対する修正がいつ行われるかについての見積もりはありますか？

これは＃4146で修正する必要があります。

編集：以下を参照

そのため、＃4146にいくつかのバグがあり、前進するのは望ましくないPRになっています。 マスター、＃4146、＃4223の間の調査結果をここに報告しました： https ：

@adamreeseと私は、この特定のエラーの原因となる根本的なバグを特定し、提案された各PRでさまざまなシナリオとエッジケースを経験しました。 他の誰かが私の発見を確認したり、他のエッジケースを見つけたりできれば、それは大いにありがたいです！

ああ、そして私が言及しなかったことがあります。クラスターが一貫性のない状態にあるため、エラーが「見つかりません」と報告するリソースに手動で介入して削除することで、これを簡単に回避できます。 https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568で示した例に従って、次のようにし

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

@bacongobblerそれは常に機能するとは限りません。 削除しても機能する場合と、削除しても機能しない場合があります。

これは、リソースに手動で介入して削除することで簡単に回避できます

@bacongobblerこのリソースは、本番名前空間のServiceまたはDeploymentオブジェクトである可能性があり、サービス保証を大幅に混乱させる可能性があることを理解してください。

はい、知っています。 バグの動作を説明して観察しているだけなので、他の人は何が関係しているのかを知ることができます。 :)

異なるクラスターでこの問題が2回発生するだけです。 毎回configmapsを使用します。 リソースを削除しても問題は解決しなかったため、リリース全体を削除する必要がありました。

こっちも一緒。 Configmapだけでなく、ServiceAccountを持つものもあります。

ここにPVC。 :)

基本的に、あらゆる種類の優先オブジェクトがこのバグの影響を受けます。

これを修正するために割り当てられた誰かがいますか？ これに対するPRはすでにありますか？ 何かお手伝いできますか？

入りやすい状況なので、この問題に何度も噛まれてきましたが、どうやら簡単に抜け出す方法はありません。 私の場合の「良い」部分は、リリースのエラーがあってもリソースが更新されることだと思います（それが私を幸せにするか心配するかはわかりません）

ヘルムは、ユーザーがこの間違った状態になることを禁止するか、正しく処理する必要があると思います。
すべてを削除する以外に、これに対する実際の修正はありますか（これは非実稼働での使用にのみ実行可能です）？

リソースを削除しても問題が解決しなかった他のエッジケースを他の誰かが特定できる場合、それはその特定の問題を解決する根本原因を特定するのに非常に役立ちます。 同じエラーが発生する可能性のあるパスが複数存在する場合があります。

@Draikenいいえ、問題に対して複数の解決策を試みましたが、どちらも合理的ではないようです。

a）意図したとおりにアップグレードを実行しない、または
b）新しいバグを導入する

私はここでそれらの解決策とそれらが機能しない理由について書きました。 別の解決策を見つけられたら、喜んで検討させていただきます。

ユーザーがこの間違った状態になるのをゲートキーピングすることもできません。 私たちは解決策を見てきましたが、やはりそれらはすべて異なる一連の問題をもたらします。 インストールに一貫性のない状態になると、手動で介入せずにインストールを「修正」することは困難です。 😢

私にとってうまくいった回避策は、障害が発生する直前にhelm rollback ...を実行することです。 次に、チャートがhelm install -n new-test-release .新しいリリースで機能することを検証します。

すべてが機能したら、テストリリースをクリーンアップし、古いリリースに対してhelm upgrade ...を実行します。 そしてすべてがうまくいった。 これは厄介な回避策ですが、うまくいくようです。

これがまったく役立つかどうかはわかりませんが、テストクラスターと本番クラスターの両方でこの問題が発生しました。

ヘルムファイルに加えた変更は非常に簡単でした。
1つの既存のデプロイメントがあり、関連するサービスとpoddisruptionbudgetが変更されていませんでした。
独自のサービスとpoddisruptionbudgetを使用して2番目のデプロイメントを追加しました。
チャートのバージョン番号を増やしました。

ヘルムを実行しているときに、初めてこのエラーが発生しました。

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

ヘルムを再度実行すると、このエラーが何度も発生します。

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

もちろん、ヘルムチャートは、すべてを削除して再デプロイしたときにテストで機能しました。 しかし、それは実際には製品のオプションではありません。

@veqrynこれに何度も

編集：誰かがそれを試すことに興味があるなら、私はそれをパブリックドッカーリポジトリにプッシュして、それを使用する方法の簡単なスニペットを含めることができます。

@jaredallard興味があります。 ありがとう！

メンテナがそれを勧めないかもしれないことを私は知っています、しかしそれは何もないよりはましです。

@jaredallardパッチ自体が機能しないという理由だけで、そのパッチを推奨することはできませんでした（参照：https：//github.com/helm/helm/pull/4223#issuecomment-397413568）。 エラーをバイパスしますが、リソースをアップグレードしないため、パッチはユーザーが本来意図していたことを実行しません。 1つの問題は修正されますが、ユーザーが実行しようとしている元の問題、つまりリソー​​スのアップグレードを修正せずに別の問題が発生します。

ただし、これは興味深いものです。

私は基本的に、この問題が発生するたびに＃4146のビルドを使用してから、メインラインのビルドに戻します。

私がこの権利を読んでいるなら、あなたはあなたがその回避策を見つけたことを示唆しています

a）エラーをバイパスします
b）当初の意図どおりにリソースをアップグレードできるようにする

2つのhelm upgrade実行することによって：1つはパッチあり、もう1つはパッチなし？ これは、根本原因とこのエラーの修正方法をより適切に特定するのに役立ちます。

@bacongobblerこれを100％再検討して、それが動作であることを確認する必要があります。 このコメントを更新するか、必要に応じて別のコメントを投稿します。

メンテナがそれを勧めないかもしれないことを私は知っています、しかしそれは何もないよりはましです。

また、明確にするために、私はそこに日陰を投げようとはしていません！ 今振り返ってみると少しひどい言葉ですごめんなさい

そもそもなぜ私の舵が初めて失敗したのか、私はまだ混乱しています。
2回目に適用しようとするまで、 no X with the name Yエラーは発生しませんでした。

@veqryn上記でリンクした問題の最初の場所で、この問題がどのように発生するかについて書きました。 コメントをお読みください。 問題が不明な場合は、問題をより詳細に明確にするために喜んでお手伝いします。

怠け者の場合： https ：

私は実際にそれを読みました、そして私の理解はあなたがあなたのサービスの名前を変えたのであなたに問題が起こったということでした。

ただし、私のサービスやリソースの名前が変更されることはありませんでした。

そして、あなたのコメントを読み直して私の乗組員と話した後、私たちはエラーの原因を突き止めました：
ヘルムチャートのバージョンをぶつけました。
そのチャートバージョンは、私のデプロイメントとサービスによってラベルとして参照されました。
ラベルが変更されたとき、Kube / helmはそれを気に入らず、これが元のエラーの原因です。

（私にとっての）解決策は、helmを使用して最後に成功したデプロイに戻し、次にチャートバージョンの変更を元に戻して、チャートバージョンが同じままになるようにすることでした。これにより、成功しました。

この（醜い）修正は私のために働きます：

1. エラーが発生します：

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1.最後に展開されたリビジョンを見つける

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4.（重要）最後にデプロイされてから追加された既存の新しいリソース（v16）をすべて検索し、それらを削除します。たとえば、
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

helm upgrade ...を実行して、HappyHelmingを参照してください

@ kosta709が言ったように、最後にデプロイされたリリースに戻り、チャートまたは現在のステータス（問題が何であれ）を（手動で）修正し、新しいアップグレードを実行すると、通常は機能します。

Helmは、コマンドの結果が安定していない場合に、一部の自動ワークフロー（CI / CD）で破棄できる優れたソフトウェアです。

このよく知られている（そして少し厄介な）問題を解決するために、既知のソリューションが最終的に舵取りに実装されるオプションはありますか？ ありがとう。

ですから、最近私もこれに頻繁にぶつかり、自分でこの問題に取り組むことができます。 手始めに、回避策を作成しました（
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686）これにより、基本的にTillerは、古いマニフェストから取得したリソースではなく、既存のリソースを開始点として取得します。 私にとっては魅力のように機能しますが、ハードコードされた動作が含まれているため、コア開発者はそれをマージしたくないと思います。

同じ動作で2つのバグが隠されている可能性が

それで、私はそれを適切な方法で解決する方法を考えてきました。 以下に説明します。 コア開発者は、ここで私を修正し、同意する場合は検討してください。 はいの場合、私はこの取り組みを主導し、それを修正するためのPRを提供する用意があります。

一般に、helmは「パッチ」モードで動作しているようです。ユーザーが何らかの方法でリソースを変更し、新しいリリースバージョンが他のパラメーターを変更した場合、helmは2つのリビジョン間のパッチを計算して適用します。これは、ユーザーの変更をそのまま維持しようとしていると思います。

古いマニフェストから取得したリソースバージョン、新しいマニフェストから取得した別のバージョン、現在生きているリソースから取得した別のバージョンがあるため、残念ながら3方向マージの問題が残ります。 そして、ヘルムは、衝突が発生したときに、衝突を解決するのが明らかに苦手です。

適切な方法は、より適切なデフォルトを選択するか（基本的に、ブランチをマージすると大いに役立ちます）、ユーザーにフラグを提供することだと思います。 例：このように：

• --ignore-old-manifest=never （デフォルト、現在の動作）
• --ignore-old-manifest=create-only （この場合に適用されます。古いマニフェストにリソースの概念がなく、リソースがすでに存在する場合、これを新しいベースとして取得し、必要に応じてパッチを適用できます）-これを新しいものにすることをお勧めしますデフォルト。 これにより、ヘルムは手動で作成されたリソースの所有権を取得し始めることもできます。
• --ignore-old-manifest=always -完全を期すためだけに、おそらく厳密には必要ありません。 それは常に現在のリソースと最新のマニフェストの間にパッチを作成し、基本的にすべてのユーザーの変更を削除します。

もちろん、フラグの名前を変更して、逆のロジックを使用することもできます： --use-current-resources=never(currently default)/create-only/alwaysなど。

後で、このフラグは、次のようなリソース注釈から取得できます。

annotations:
  helm.io/ignore-old-manifest: always

どのヘルムがこの戦略をリソースごとに認識して適用できるか。 ヘルム開発者がそこに行きたいかどうかはわかりませんが;）

では、この提案についてどう思いますか？

Helm開発者が3ウェイマージパッチを検討している問題＃3805も参照してください。

ここで同じ問題。
グーグルクラウドビルドでCD / CI環境をセットアップしようとしています。
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

面白いのは、デプロイメントが存在することです。

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

これは私が作成する最初のグラフであり、CI / CD環境で複雑なアプリケーションをデプロイする複雑さを処理するソリューションとして、 helmが期待されていました。

ヘルムの目的は、CI / CDパイプラインで機能できるようにすることですか？

ありがとう

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

私もこれに遭遇し、ヘルム0.8.0をヘルム1.0.0にアップグレードしようとしています。

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

チャートの要件をアップグレードするときにも、これに遭遇しました。 Istioでもこのバグが発生していることがわかります。インストールドキュメントでは、 helm templateます。 これはこの問題の回避策ですか？

https://github.com/helm/helm/issues/3805で最近の議論を確認して

これもありますが、最新のヘルム2.10でも発生します

この問題を真剣に検討する時が来ました。2年が経ちました。多くの人が同じ問題を報告しているため、ヘルムは本番環境ではまったく使用できなくなり、展開がヘルムに依存している場合は非常に苦痛です。

多くのGitHubスターには、大きな責任が伴います

@ brendan-riusこの問題を修正するためのコードを投稿したり、アイデアを考えたりすることを歓迎します。 いくつかのポインタについては、＃3805および＃4146を参照してください。

@ brendan-rius、特に＃3805には、このバグに関する最新の議論があります。 そのスレッドを読んで、私たちが何に反対しているのかを理解することを強くお勧めします。

3ウェイマージ戦略よりもこの問題に関連しているため、ここにコメントを再投稿します。

Helm 2.yzの新しい展開で3方向マージが実行できない場合、＃1193はいつ修正されますか？ バグは2年近く開いており、Helm2.0の明確な解決策は計画されていません。

この時点で、私たちはどのように進めるかで困惑しています。 バグについて数週間議論してきましたが、新しいバグを導入したり、耕うん機のアップグレード動作を大幅に変更したりしても、提案された解決策はすべての場合に機能するわけではありません。

たとえば、 @ michelleNと私は今週初めにブレインストーミングを行い、2つの可能な解決策を考えましたが、どちらも特に素晴らしいものではありません。

1. アップグレードが失敗すると、このリリース中に作成されたリソースを自動的にロールバックして削除します。

アップグレードに失敗した後、クラスターが不明な状態になる可能性があるため、

1. アップグレード中に、新しいリソースを作成していて、それがすでに存在していることがわかった場合は、代わりにそれらの変更を既存のリソースに適用するか、削除/再作成します。

Helmは、他のパッケージまたはkubectl createを介してインストールされたオブジェクトを削除する可能性があるため、

これまでのところ最も安全なオプションは、この競合が発生した場合にユーザーに手動で介入するように依頼することでした。これについては、以下で説明します。

誰かが提案/フィードバック/代替提案を持っているなら、私たちはあなたの考えを聞いてみたいです。

@ bacongobbler 、3方向マージ機能のサポートが計画されていない場合は、代替手段または回避策が必要です。 そうでなければ、＃1193はひどく痛いボッカーです。

問題と回避策を繰り返すには：

新しいリソースをインストールするアップグレードが失敗すると、リリースはFAILED状態になり、アップグレードプロセスを停止します。 次にhelm upgradeを呼び出すと、Helmは最後のDEPLOYEDリリースに対して差分を取ります。 前回のDEPLOYEDリリースでは、このオブジェクトは存在しなかったため、新しいリソースを作成しようとしますが、すでに存在しているため失敗します。 @arturictusが指摘しているように、エラーメッセージは完全に誤解を招くもの

これは、エラーが「見つかりません」と報告したリソースに手動で介入して削除することで簡単に回避できます。 https://github.com/helm/helm/pull/4223#issuecomment -397413568で示した例に従って、次のようにし

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

つまり、FAILEDリリース中に作成されたリソースを削除すると、問題が回避されます。

@bacongobbler最初に、この数週間にわたってこの問題をより詳細に見ていただきありがとうございます。 問題の原因となるIstio0.8.0からIstio1.0.0へのアップグレードの問題、または問題の説明と完全に一致するかどうかは、正確にはわかりません。 私の推測では、リリースの約3日前に、以前は管理されていなかった（つまり、インストール後のジョブで追加された）一部のオブジェクトが、インストール後のジョブにインストールされないように移行されました。

Helmの経験が豊富なIstioオペレーターコミュニティと話をしたところ、Helmの管理されていないリソースは悪いニュースであり、アップグレードの失敗につながることが多いとのことです。 Istioチャートの実装に、Helm 2.yzとのアップグレードと互換性がないという欠陥がある場合、それらの非互換性を修正することは素晴らしいことです。したがって、将来的にアップグレードに失敗することはありません。

0.8.0から1.0.0へのアップグレードで1回のヒットを喜んで受けます。 アップグレードが常に不安定な場合、それは別の問題です。

Istioでバイセクトを実行しました-アップグレードは7月27日（Istio 1.0.0リリースの3日前）まで機能していたため、このコミットに問題があることがわかりました： https ：

このPRは、基本的にインストール後のジョブからオブジェクト登録を削除しました。 Istio 1.0.0までの3日間の準備期間中に、インストール後のジョブのすべてのインスタンスを削除したと思いますが、確かではありません。

アップグレードに関連するIstioの特定のヘルムチャートについてアドバイスを提供できますか？ インストール後のジョブからオブジェクト登録を除外することで、アップグレードの問題を永続的に解決できますか？

ヘルムの最近の経験を持つ人々は一般化された解決策を見つけることができなかったので（そして問題を見ていないためではないので）、ヘルム全体でこの問題を修正するための強力なアドバイスや提案を実際に提供することはできません。 私はもっ​​とうまくやれるとは思わない。

乾杯
-スティーブ

エラーをより適切に反映するようにタイトルを更新しました。

この問題の影響も受けています。 最新のヘルム2.10とGKE10.6を使用しています。
いつ修正されると思いますか？
この問題に対する合理的な回避策はありますか？ --purgeオプションを使用してデプロイメント全体を削除するのは非常に貧弱です。

私の最後のコメントを自由に検討してください。 ここで最善の方法を実行する方法についてのフィードバックが本当に必要です。

このスレッドでは、回避策が複数回繰り返されています。 https://github.com/helm/helm/issues/1193#issuecomment-419555433をお読みください。

この問題を解決するためのヘルム自動ロールバック機能（オプション1 ）のアイデアが気に入ってい

アップグレードに失敗した後、クラスターが不明な状態になる可能性があるため、これは非常に危険です。そのため、Helmはクリーンな方法で続行できず、アプリケーションのダウンタイムが発生する可能性があります。

多くのヘルムユーザーは、CDまたはCMツールを介して自動化された方法でヘルムを使用していると思います。ヘルムリリースをFAILED状態のままにしておく方がリスクが高くなります。 失敗したリリース内のこれらの不完全なリソースは、他のリソースに予期せず影響を及ぼし、それ自体がダウンタイムを引き起こす可能性があります。 たとえば、ポッドの仕様に、何らかの理由で本番環境に移行した欠落したイメージバージョンが含まれている場合、ワークロードは機能しないImagePullBackOff状態になります。 私たちの会社にとっては、UIを介して自分自身をアップグレードできるオンプレミスの顧客がいて、失敗した場合はデバッグのためにシステムにアクセスする必要があるため、さらに悪いことになります。

この問題を修正できるという事実を無視しても、自動ロールバックは便利な機能であり、Helmリリースが本質的によりトランザクション的であることを保証するのに役立ちます。 これは、Helmをベストエフォートの展開から、安定性と成功した展開の優先順位に転換します。

@bacongobblerは、次のアプローチが新しい展開で実行可能です。

• フラグを追加します- -three-way-merge
• そのフラグがhelm installのみ消費されることを許可する（新規展開）
• このフラグを有効にすると、アップグレードでは常に3ウェイマージが使用されます
• 既存の展開は移行パスなしでスタックします-この時点で人々が使用しているように見える標準的な回避策はhelm delete --purge後にhelm reinstall続くので、これは最初に表示されるほど不快ではないかもしれません。

これは実際に問題を解決しますか？

一部の個人は、このヘルム制限を回避するためにオペレーターの実装を検討しています。 それは深刻な恥です。 https://github.com/istio/istio/issues/8841#issue-361871147を参照して

乾杯
-スティーブ

@bacongobblerの以前のコメントに戻る：

1. アップグレード中に、新しいリソースを作成していて、それがすでに存在していることがわかった場合は、代わりにそれらの変更を既存のリソースに適用するか、削除/再作成します。
   Helmは、他のパッケージまたはkubectl createを介してインストールされたオブジェクトを削除する可能性があるため、これは非常に危険です。どちらのユーザーも必要ない場合があります。

新しい動作をオプトインすることで、このリスクを軽減できるでしょうか。 特定の名前空間内では、通常、helmを排他的に使用しますが、これは多くの場合に当てはまると思います。 Helmにインストール/アップグレードのフラグを付けて、既存のリリースの一部ではない特定の名前空間内のすべてを削除/上書きしても問題がないことを通知できるとしたら、それは役に立ちますか？

「他のパッケージ経由」とも言ったので、リリースの実行の一部としてHelmが他のリリースを調べる必要はないと思います。したがって、名前空間ごとの単一リリースモデルを除いて、私の提案は機能しません。 その反対意見に答えるには、名前空間内の複数のパッケージを管理し、それでもこの動作を実現したい場合は、必要なグラフの依存関係を指定することを唯一の目的とする包括的なグラフを作成します。 次に、そのアンブレラチャートを展開するときに、新しいフラグ（ "--exclusive"？）を使用します。

明らかに、これはすべてのユースケースの問題を解決するわけではありませんが、おそらくそれで十分な回避策です。

@bacongobbler私はここから離れている可能性があります。 アップグレードでも同様の問題に直面しています。 この問題を解決するのがどれほど難しいかを判断すると、もっと根本的なことを再考する必要があるのではないかと思います。 複雑さの一部は、Helmが、実際の信頼できる情報源であるkubernetesとは別に、既知の構成の独自のバージョンを維持しているためと思われます。 Helmが履歴とロールバックの目的で以前に展開されたヘルムチャートのコピーのみを保持し、アップグレード中にそれをまったく使用しなかった場合、システムはより信頼性が高くなりますか？ 代わりに、Helmはkubectl自体から真実を取得し、実行するために常に双方向の差分を持っていますか？

ヘルムチャートにリソースXが必要であると示され、kubectlが既存のリソースXを認識している場合、次のようになります。

• 既存のリソースがHelmによって制御されているものとしてタグ付けされている場合、Helmは必要なアップグレードを実行します
• 既存のリソースがHelmによって制御されているものとしてタグ付けされていない場合、Helmはクリーンなエラーメッセージで失敗します（または、コマンドラインフラグを使用してアップグレードを強制し、Helmに既存のリソースXの所有権を取得させることができます）。

ヘルムチャートにリソースXが必要であり、kubectlによるとリソースがない場合、ヘルムはそれを作成します。

kubectlが、このヘルムチャートによって制御されているとタグ付けされたリソースYがあり、このヘルムチャートにリソースYがないことを報告した場合、helmはリソースを削除します。

このヘルムチャートによって制御されているとタグ付けされていないリソースは、アップグレードを実行するときに常にヘルムによって無視されます。ただし、ヘルムチャートにリソースXが必要であり、Xが存在するがタグ付けされていない場合を除きます。

何らかの理由でヘルムチャートのロールアウトが発生して失敗し、リソースの半分だけがロールアウトされた場合、ロールバック中にヘルムは以前に成功した展開から保存された構成ファイルを使用し、まったく同じアルゴリズムを実行します。一部のヘルムコマンドラインフラグに関連して、壊れた状態のままになる可能性があります。 ユーザーが再度アップグレードを試みる場合、kubernetesが真実のソースとして使用され、最後に成功した展開ではないため、新しいヘルムチャートとシステムの既存の状態との間の単純な双方向の差分である必要があります。

この問題も発生しています。 私たちの再現手順：

1. helm installデプロイメントを正常にインストールするチャート
2. チャートを更新して、既存の展開に加えてカスタムリソースを含めます
3. デプロイメントpodspecのイメージを変更して、デプロイメントの失敗を模倣します
4. helm install新しいチャート。 これにより、意図的に失敗するように設定したデプロイメントのローリング更新が発生します。
5. ヘルムのインストールは失敗するはずです。 ただし、カスタムリソースはk8sなどに残しておく必要があります。 （ kubectlを使用して確認します）
6. （この時点で、ヘルムは悪い状態です）
7. チャートを修正します-デプロイメントpodspecにgootイメージを配置します。
8. helm install 。 これが機能することを期待していますが、機能しません。 「___という名前のリソースがありません」を報告します。 名前はカスタムリソースの名前です。
9. 回復方法： kubectlを使用して残りのカスタムリソースを削除します。 これでhelm installが機能します。

チャートに新しく導入されたカスタムリソースを使用してhelm installを最初に試行すると、この状態にならないことに注意してください。

@ rbair23以前に試しましたが、うまくいきませんでした。 kubectl applyを修正し、ロジックをクライアントからサーバーに改善しようとしているアプライワーキンググループがあり

＃3275がその複製としてクローズされたため、＃3275と同様の状況が発生します。

実行中のジョブmy-long-running-jobがすでにあります。 リリースをアップグレードしようとしています：

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

仕事は存在します：

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

そのジョブの削除：

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

その障害を解決します：

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

少なくともメッセージno Job with the name "my-long-running-job" foundは誤解を招く可能性がありますが、私の期待は、ジョブも更新されることでした。

v2.9.1（現在リリースされている安定バージョン）でもこれが見られます

アップグレードを取り消すことは「非常に危険」であることに同意しません。 そうすることが正しい解決策だと思います。

Kubernetesは宣言型です。 アップグレードを試みる前に、クラスターの状態をスナップショットします。
途中でエラーが発生した場合は、スナップショットにロールバックします。
これを行うときにクラスターを悪い状態のままにするスクリプトフックがある場合、それは彼ら自身の責任です。 （多分それはロールバックフックでも解決できるでしょう）

もちろん、アップグレードが事前に実行され、そもそも可能な限りファイルを提出しなかったとしたら、それは素晴らしいことです。
たとえば、値または--set引数によって生成された依存関係チャートのエラーは、何かを変更しようとする前に確認できる必要があります。 バージョン番号を上げるのを忘れるなどのことも、機能しないときに変更を加えないようにプリフライトすることができます。

こんにちは、

同じ問題がありました：

クライアント：v2.10.0 + g9ad53aa
サーバー：v2.10.0 + g9ad53aa

Helmにリリースをアップグレードさせる唯一の方法は、serviceAccount、configMap、およびserviceを削除することでした。

こんにちは、

@dilumrで説明したのと同じ問題があります...バージョン2.11.0では：

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

v2.9.1でこれに遭遇しました。

私が実行していたチャートのアップグレードは、多くの変更を加えたプライベートチャートのいくつかのメジャーバージョンをジャンプしていたため、エラーが発生した正確な原因はわかりませんが、展開が最初にFAILED状態になった理由--waitフラグがあり、タイムアウトしたということでした。

最終的にhelm listいくつかの重複したFAILEDデプロイメントが発生しましたが、最後に機能したデプロイメントはDEPLOYED 。 新しいデプロイメントを作成すると、 No resource with the name x found 。

helm list DEPLOYED状態にあった最後のバージョンにhelm rollbackを実行することで、修正できました。 そのアップグレードの後、エラーなしで実行できました。

https://github.com/helm/helm/pull/4871をチェックして

他の人と同じように、このエラーは、最後の展開が失敗し、その展開からの新しいアセットがインストールされたままになっているときに、私にとって最も頻繁に発生するようです（常にわかりません）。

失敗したHelmデプロイからコンポーネントをアンインストールするのがいかに難しいか、望ましくないかを理解していますが、この種の状況でのHelmの理想的な動作は何ですか？

まず、Helmは、名前空間やその他のリソースを（再）インストールしようとしている場合、それらがすでに存在していても問題ないと思います。 Kubernetesは、「構成を正しく行い、世界を構成に一致させる方法をkubeに理解させる」ことを目的としています。
第二に、ヘルムはオールオアナッシングであるべきだと思います。 デプロイが失敗した場合、クラスターはデプロイが開始される前の状態になっている必要があります。
名前空間Xを作成したいリリースが2つある場合は、参照カウントの問題があります。 名前空間Xを作成したいリリースが存在するが、それがすでに存在する場合は、来歴の問題があります。 ただし、ヘルムはオブジェクトの注釈を使用してこれを記録し、正しいことを行うことができます。

最新のhelm2.12.0とkubernetes1.10.11でもこの問題が発生しています。 @ aguilarmが提案したように最新の良好なリリースにロールバックしても

環境が非常に似ている2つのクラスターがあり、2つのクラスターの主な違いはノードの総数です。 あるケースではhelm delete --purge続いて新しいhelm install機能しましたが、別のケースでは機能せず、最新のテンプレート変更にそれをもたらす方法をまだ理解していません。

これにETAはありますか？

helm rollbackを使用してこれを回避し、最新のリビジョン（失敗したリビジョン）を指定することができました。

今日も同じ問題がありましたが、
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback機能しました。

ヘルメットのアップグレードを行っている間、これはかなり定期的に発生しています。これは、展開が失敗しただけでなく、展開が成功した後に発生します。 これらは、1）使用できず、2）ゼロから完全に回復するには時間がかかりすぎて受け入れられない、重要なコンポーネントを備えた本番システムであるため、削除-パージを実行することはできません。

上記で投稿した診断と回避策を参照してください。 それがあなたのために働くかどうか私に知らせてください。

@bacongobblerご回答ありがとうございます。 これは実際、私が思いついた回避策でもあり、今のところはそれで十分ですが、CICDを介して1日に数十回ヘルムアップグレードを使用しているため、これは頭痛の種になるほど頻繁に発生します。 上記が全体像であるかどうかはわかりませんが、指定されたリソースはすでに存在していることが多く、成功した展開の一部であり、現在の展開では変更されていません-iircは、ほとんどの場合、最後に成功した展開の最新のリソースセットです興味深いことに十分ですが。

@ajcannに+1し、
私はまったく同じ状況にあります。
CICDは自動化されており、多くの場合、展開は低環境向けのSlackボットによって行われます。
失敗した場合は、手動でヘルムロールバックを実行して再度デプロイする必要があります。
この問題はまったく一貫していませんが、頻繁に発生します。
私にとっては、これまでのところ、チャート/リソースの2回目のデプロイ中にのみ発生します。
リソースは常に存在します。

同じ問題が見られます。 次のいずれかのテンプレートがある場合に発生します。

• {{if $condition -}}ステートメントで
• または{{ range $index, $value := $array-}}

@jkroepkeは、PR＃5143がこれに対する良い回避策を提供することを私に指摘しました。 次のマイナーバージョンで--atomicフラグがリリースされると、エラーが発生したときにそれを使用して自動的にパージまたはロールバックできるようになります。

@bacongobblerは、これについてほとんどの--atomicフラグで十分でしょうか？

@distorheadはそれを見て、 https：//github.com/helm/helm/pull/4871で提起した彼の懸念も解決するかどうかを確認したいと思うかもしれません--atomicフラグを使用すると仮定すると、 --atomicで問題に対処する必要があるようです。

この特定の状態になったときに問題に対処するための提案された解決策はないと思いますが、私は間違っている可能性があります。 この問題の緩和戦略が

• クラスターのライブ状態を手動で確認し、回避策に従って修正します
• Helm 2.13.0にアップグレードし、今後helm upgrade --atomicを使用します

それなら、これは安全に閉じることができると思います。

うまくいけば、Helm2.13.0はそれほど遠くありません。
このバグは、リリースのどこかでエラーが発生した場合にCIを破壊します。

アトミックは問題を解決しません

チャートの例： https ：

1. マスターをチェックアウトし、デプロイを実行します。

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

グラフには2つの展開が含まれています- myserver1とmyserver2 ：

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. 重大な変更を加えます。 チャートからデプロイメントmyserver1を削除し、ユーザーエラーでデプロイメントmyserver2を変更します（たとえば、画像フィールドを削除します）。

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. デプロイを実行します。

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

もう一度友達に挨拶してください。

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorheadこのシナリオで予想される動作は何でしたか？

ロールバックについては少しオフトップですが、とにかく。

ロールバックを使用したいが、何らかの理由で--atomicようにデプロイ直後にロールバックを発生させたくない人のために。 たとえば、ユーザーが障害後に不良クラスターの状態を手動で検査する方法がなく、 --waitフラグによって、デプロイされているリソースの障害に関する情報がヘルムにログに記録されないためです。 次に、いくつかの方法があります。アップグレード前の次の実行でのロールバック（詳細はhttps://github.com/helm/helm/issues/3149#issuecomment-462271103）

問題と回避策を繰り返すには：

新しいリソースをインストールするアップグレードが失敗すると、リリースはFAILED状態になり、アップグレードプロセスを停止します。 次にhelm upgradeを呼び出すと、Helmは最後のDEPLOYEDリリースに対して差分を取ります。 前回のDEPLOYEDリリースでは、このオブジェクトは存在しなかったため、新しいリソースを作成しようとしますが、すでに存在しているため失敗します。 @arturictusが指摘しているように、エラーメッセージは完全に誤解を招くもの

これは、エラーが「見つかりません」と報告したリソースに手動で介入して削除することで簡単に回避できます。 ＃4223（コメント）で示した例に従って：

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

つまり、FAILEDリリース中に作成されたリソースを削除すると、問題が回避されます。

この回避策を@bacongobblerにまとめてくれてありがとう-それは本質的に私たちがプロセスとしてやってきたことでもあります。 ここでの1つの厄介な問題は、複雑なアップグレード中に、多くの新しいリソース（場合によってはいくつかの依存関係レベルが深い）がこの状態になる可能性があることです。 関連するすべてのリソースの「検索」へのアップグレードに繰り返し失敗する必要がある状況につながる、これらの状態を自動的に完全に列挙する方法をまだ見つけていません。 たとえば、最近、新しく追加された依存関係自体がpostgresqlチャートに依存関係を持っていました。 この問題を解決するには、シークレット、configmap、サービス、デプロイメント、およびpvcを削除する必要がありました。

前回のリリースで作成されたテンプレートを列挙するhelm diffようなプラグインを作成できます。 Helmから直接pkg/kube消費することもできます。 client.Updateは、ヘルムのリソース追跡/削除用に記述されたビジネスロジックがあり、Tillerから2つのリリースをフェッチし、比較順序を逆にすることで再利用できます。 target.Difference(original)は、前のリリース以降に導入されたすべてのリソースの結果を提供するはずです。

@bacongobblerリリースAの一部としてデプロイされたアプリケーション（たとえば、複数のアプリケーションで構成されるより大きなリリース）を取得し、ダウンタイムを発生させずにリリースAから独自のリリースに分割する（またはその逆）ことをお勧めします。 （リソースを削除するための回避策は、ダウンタイムを引き起こす可能性があります）...別のリリースを介してリソースを更新しようとすると、このGithubの問題で説明されているエラーが発生します。

この新しいチャートがインストールされ、デプロイが成功する前でも古いチャートを置き換えているように聞こえます。 アップグレードが失敗した場合も同じです--install。 チャートが間違っているとインストールできません。
エラーが発生した場合は前の状態にロールバックするか、成功した場合は耕うん機チャートを更新します。

これは私がこの問題から回復するために使用するプロセスです（これまでのところ、問題なく毎回機能しています...しかしとにかく注意してください）：

1. helm listを実行し、影響を受けるチャートの最新のリビジョンを見つけます

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. そこから移動して、 DEPLOYED状態の最新リビジョンを見つけます
   kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. DEPLOYEDの最後のリビジョンを見つけたら、その状態をDEPLOYEDからSUPERSEDEDし、ファイルを保存します
4. もう一度helm upgradeを実行してみてください。成功した場合は、完了です。
5. 次のようなアップグレードエラーが発生した場合：
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   次に、最後のリビジョンのステータスをFAILEDからDEPLOYED編集します
   kubectl -n kube-system edit cm fetlife-web.v381
6. helm upgradeもう一度やり直してみてください。もう一度失敗した場合は、テーブルをめくってください...

@bacongobbler @michelleN
この問題のエラーメッセージを改善するのが難しい理由はありますか？

エラーメッセージには、「リソースがヘルムによって作成されておらず、手動による介入が必要なため、競合が発生している」と記載されている必要があり、「見つかりません」と記載されている必要があります。 エラーに対するこの小さな変更だけで、ユーザーエクスペリエンスが大幅に向上します。

@selslackエラーメッセージの改善に大いに賛成です👍

@michelleNエラーテキストを変更するためのPRを用意しました：＃5460。

この問題が発生していて、解決方法がわからない状況にあります。

@reneklacanによってリストされているすべての手順をここでhttps ：

残念ながら、それはうまくいきませんでした。 この問題を解決する唯一の方法は、エラーメッセージを生成しているリソースを削除してから、もう一度helm upgradeを削除することです。これにより、成功します。

ただし、次のヘルムアップグレードは同じエラーで失敗するため、リソースを再度削除して再アップグレードする必要があります...これは持続可能でも適切でもありません。

CIプロセスの一部としてhelmを使用してデプロイする2つの環境があります。QA環境と本番環境です。

QA環境でも同じ問題が発生したため、 helm delete --purgeを使用してから、 helm upgrade 。これにより、問題は永続的に解決されました。

ただし、本番環境ではこれを行うことはできません。単に消去して再アップグレードすることはできないため、現在、各デプロイの前にリソースを削除することで立ち往生しています。 幸運なことに、それはインポートリソースではありません。

@zacharyw現在、どのようなエラーに直面していますか？ No resource with the name ...または"fetlife-web" has no deployed releases ？

これをデバッグするのに役立つ追加情報を共有できますか？

たぶんkubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS=出力（ YOUR_RELEASE_NAME置き換えます）

潜在的に無関係なデータ（rene（at）klacan（dot）sk）でこの問題をスパムしたくない場合は、詳細を記載した電子メールを私に送ってください。

考えられる診断と回避策については、 https： //github.com/helm/helm/issues/1193#issuecomment-419555433を参照して

@reneklacanこれはno resource with the name ...エラーです。 私たちの場合、イングレスを追加しましたが、それは機能しているように見えましたが、その後のアップグレードはこのエラーで失敗し始めました...イングレスはすでに存在していましたが。

私の最新のリリースのステータス（問題のあるイングレスを削除し、ヘルムのアップグレードで再作成できるようにした後）はDEPLOYEDです：

STATUS=DEPLOYED
VERSION=197

ただし、もう一度アップグレードしようとすると失敗します。

@bacongobbler誤解しない限り、私はすでにそのコメントで回避策を実行していると思います。リソースを削除して再作成させます...問題は毎回これを実行する必要があることです。

で@reneklacan https://github.com/helm/helm/issues/1193#issuecomment -470208910私の命を救いました。

ヘルムがこのように失敗するのは失望です。 ほとんどすべての環境で物事を削除することは理想からほど遠いです。

この種のエラーが発生したときにhelmが自身のデータベースを更新してから、再試行するとよいでしょう。

--cleanup-on-failフラグを有効にすると、このエラーケースはなくなるはずです。 ＃4871および＃5143を介して解決されたとおりに終了します。

これらのフラグなしでさらに問題が発生する場合は、新しい問題を再度開いてください。 ありがとう！

ヘルムリリースや実行中のデプロイメントを削除せずに問題に対処する方法についてコメントを追加しようと思ったため、問題は解決しました。

そこで、次の手順で問題を再現しました。

1. チャートtest-chart-failureをサービステンプレートとともにインストールします。
2. サービスのポートに文字列（「test」など）が含まれるサービステンプレートを使用してサブチャートを追加します
3. チャートをアップグレードします。 エラーService in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...失敗します

http://centosquestions.com/helm-how-to-delete-bad-deploymentで提案を適用することにより、 helm deleteを実行せずに、ポートを数値に修正した後にアップグレードすることができました。

1. helm history test-chart-failure失敗したリビジョンが見つかりました
2. kubectl delete cm -n kube-system test-chart-failure.v2を使用して特定のリビジョンの構成マップを削除しました
3. 修正されたチャートでhelm upgradeを実行しました