helm delete releaseを介してHelmからリリースを完全に削除することはできますが、実行可能な解決策ではありません。

Helmが現在インストールされているものを上書きできないのはなぜですか？ Kubernetesのある宣言型の世界に住んでいませんか？

ちょうど同じことを手に入れました...それは新しい問題のようですが、私にとってはまったく新しいものです。 リソースを削除すると修正されます。
v2.7.2とKubernetes1.7.7。
以前はかなりうまくいきました...

私はこの問題を抱えていました-それは私が作成したPersistentVolumeが原因でした。 解決するために、PVとPVCを削除しました。 helm upgrade XXX XXX 、正常に動作しました。 おそらく、PVが存在したので、まだ調査する必要があるものがあります。

私はそれが悪いpvに関連しているかもしれないと感じました...しかしそれからエラーはかなり誤解を招きます！
また、耕うん機からのいくつかの奇妙なログ...それは同時に2つのバージョンで動作しているようです...

運がなく2.7.1で試してみました...

[メイン] 2017/12/21 15:30:48 Tiller v2.7.1の開始（tls = false）
[メイン] 2017/12/21 15:30:48 GRPCリスニング：44134
[メイン] 2017/12/21 15:30:48プローブがリッスンしている：44135
[メイン] 2017/12/2115：30：48ストレージドライバーはConfigMapです
[メイン] 2017/12/2115：30：48リリースごとの最大履歴は0です
[耕うん機] 2017/12/21 15：30：55xxxの更新の準備
[ストレージ] 2017/12/2115：30：55「xxx」履歴からリリースをデプロイ
[耕うん機] 2017/12/21 15:30:56 xxx（v65）から新しいリリースに値をコピーします。
[ストレージ] 2017/12/2115：30：56「xxx」の最終リビジョンを取得
[ストレージ] 2017/12/2115：30：56「xxx」のリリース履歴を取得
[耕うん機] 2017/12/2115：30：59値を使用してhelm-xxxチャートをレンダリングする
2017/12/21 15:30:59情報：マニフェスト "helm-xxx / templates / scheduler-deploy.yaml"が空です。 スキップします。
2017/12/21 15:30:59情報：マニフェスト "helm-xxx / templates / recomposer-deploy.yaml"が空です。 スキップします。
2017/12/21 15:31:00情報：マニフェスト「helm-xxx / templates /recomposer-pvc.yaml」が空です。 スキップします。
2017/12/21 15:31:00情報：マニフェスト "helm-xxx / templates / scheduler-pvc.yaml"が空です。 スキップします。
2017/12/21 15:31:00情報：マニフェスト「helm-xxx / templates /scheduler-secret.yaml」が空です。 スキップします。
2017/12/21 15:31:00情報：マニフェスト「helm-xxx / templates /recomposer-secret.yaml」が空です。 スキップします。
[耕うん機] 2017/12/21 15：31：09xxxの更新されたリリースを作成しています
[ストレージ] 2017/12/2115：31：09リリース「xxx.v80」を作成しています
[耕うん機] 2017/12/21 15：31：09xxxの更新を実行しています
[耕うん機] 2017/12/21 15：31：09xxxのアップグレード前フックを0個実行
[耕うん機] 2017/12/2115：31：09アップグレード前のxxxのフックが完了しました
[耕うん機] 2017/12/21 15：31：11xxxの更新を準備しています
[ストレージ] 2017/12/2115：31：11「xxx」履歴からデプロイされたリリースを取得
[ストレージ] 2017/12/2115：31：11「xxx」の最終リビジョンを取得
[ストレージ] 2017/12/2115：31：11「xxx」のリリース履歴を取得
[耕うん機] 2017/12/2115：31：18値を使用してhelm-xxxチャートをレンダリングする
2017/12/21 15:31:18情報：マニフェスト「helm-xxx / templates /scheduler-secret.yaml」が空です。 スキップします。
2017/12/21 15:31:18情報：マニフェスト「helm-xxx / templates /scheduler-pvc.yaml」が空です。 スキップします。
2017/12/21 15:31:19情報：マニフェスト「helm-xxx / templates /scheduler-deploy.yaml」が空です。 スキップします。
[kube] 2017/12/2115：31：28更新されたマニフェストからリソースを構築する
[耕うん機] 2017/12/21 15：31：46xxxの更新されたリリースを作成しています
[ストレージ] 2017/12/2115：31：46リリース「xxx.v81」の作成
[耕うん機] 2017/12/21 15：31：47xxxの更新を実行しています
[耕うん機] 2017/12/21 15：31：47xxxのアップグレード前フックを0個実行
[耕うん機] 2017/12/2115：31：47アップグレード前のxxxのフックが完了しました
[kube] 2017/12/21 15：31：497つのリソースの変更を確認しています
[kube] 2017/12/2115：31：49シークレット「xxx-helm-xxx-nginx-secret」に変更はないようです
[kube] 2017/12/2115：31：50シークレット「xxx-application-secret」に変更はないようです
[kube] 2017/12/2115：31：50シークレット「azure-secret」に変更はないようです
[kube] 2017/12/21 15：31：51ConfigMap「xxx-helm-xxx-nginx-config」に変更はないようです
[kube] 2017/12/21 15：31：51ConfigMap「xxx-application-config」に変更はないようです
[kube] 2017/12/2115：31：51サービス「xxx-application-svc」に変更はないようです
[kube] 2017/12/21 15:31:51 StatefulSet "xxx-application"に変更はないようです
[耕うん機] 2017/12/21 15：31：51xxxのアップグレード後のフックを0個実行
[耕うん機] 2017/12/2115：31：51アップグレード後のxxxのフックが完了しました
[ストレージ] 2017/12/2115：31：51リリース「xxx.v65」の更新
[耕うん機] 2017/12/21 15：31：51xxxの更新されたリリースのステータスを更新しています
[ストレージ] 2017/12/2115：31：51リリース「xxx.v80」の更新
[kube] 2017/12/2115：31：57更新されたマニフェストからリソースを構築する
[kube] 2017/12/21 15：32：1011のリソースの変更を確認
[kube] 2017/12/2115：32：10シークレット「xxx-helm-xxx-nginx-secret」に変更はないようです
[耕うん機] 2017/12/21 15:32:10警告：「xxx」のアップグレードに失敗しました：「xxx-recomposer-secret」という名前のリソースが見つかりません
[ストレージ] 2017/12/2115：32：10リリース「xxx.v65」の更新
[ストレージ] 2017/12/2115：32：10リリース「xxx.v81」の更新

同時にリリースするのは混乱しているようです...

同じ設定を2回再適用しただけです...

[耕うん機] 2017/12/21 15：50：46xxxの更新を準備しています
[ストレージ] 2017/12/2115：50：46「xxx」履歴からデプロイされたリリースを取得
[ストレージ] 2017/12/2115：50：46「xxx」の最終リビジョンを取得
[ストレージ] 2017/12/2115：50：46「xxx」のリリース履歴を取得
[耕うん機] 2017/12/2115：50：50値を使用してhelm-xxxチャートをレンダリングする
2017/12/21 15:50:50情報：マニフェスト「helm-xxx / templates /scheduler-pvc.yaml」が空です。 スキップします。
2017/12/21 15:50:50情報：マニフェスト "helm-xxx / templates / recomposer-deploy.yaml"が空です。 スキップします。
2017/12/21 15:50:50情報：マニフェスト「helm-xxx / templates /scheduler-secret.yaml」が空です。 スキップします。
2017/12/21 15:50:50情報：マニフェスト「helm-xxx / templates /scheduler-deploy.yaml」が空です。 スキップします。
2017/12/21 15:50:50情報：マニフェスト "helm-xxx / templates / recomposer-secret.yaml"が空です。 スキップします。
2017/12/21 15:50:50情報：マニフェスト「helm-xxx / templates /recomposer-pvc.yaml」が空です。 スキップします。
[耕うん機] 2017/12/21 15：50：58xxxの更新されたリリースを作成しています
[ストレージ] 2017/12/2115：50：58リリース「xxx.v85」を作成しています
[耕うん機] 2017/12/21 15：50：59xxxの更新を実行しています
[耕うん機] 2017/12/21 15：50：59xxxのアップグレード前フックを0個実行
[耕うん機] 2017/12/2115：50：59アップグレード前のxxxのフックが完了しました
[kube] 2017/12/2115：51：13更新されたマニフェストからリソースを構築する
[kube] 2017/12/21 15：51：227つのリソースの変更を確認
[kube] 2017/12/2115：51：22シークレット「xxx-helm-xxx-nginx-secret」に変更はないようです
[kube] 2017/12/2115：51：23シークレット「xxx-application-secret」に変更はないようです
[kube] 2017/12/2115：51：23シークレット「azure-secret」に変更はないようです
[kube] 2017/12/21 15：51：23ConfigMap「xxx-helm-xxx-nginx-config」に変更はないようです
[kube] 2017/12/21 15：51：23ConfigMap「xxx-application-config」に変更はないようです
[kube] 2017/12/2115：51：24サービス「xxx-application-svc」に変更はないようです
[kube] 2017/12/21 15：51：24xxxの「xxx-recomposer-secret」を削除しています...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-secret"の削除に失敗しました、エラー：シークレット "xxx-recomposer-secret"が見つかりません
[kube] 2017/12/21 15：51：24xxxの「xxx-recomposer-config」を削除しています...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-config"の削除に失敗しました、エラー：configmaps "xxx-recomposer-config"が見つかりません
[kube] 2017/12/2115：51：24「xxx-recomposer-pv」を削除しています...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-pv"の削除に失敗しました、エラー：persistentvolumes "xxx-recomposer-pv"が見つかりません
[kube] 2017/12/21 15：51：24xxxの「xxx-recomposer-pvc」を削除しています...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-pvc"の削除に失敗しました、エラー：persistentvolumeclaims "xxx-recomposer-pvc"が見つかりません
[kube] 2017/12/21 15：51：24xxxの「xxx-recomposer」を削除しています...
[kube] 2017/12/2115：51：24「xxx-recomposer」を削除するために刈り取り機を使用する
[kube] 2017/12/21 15:51:24 "xxx-recomposer"の削除に失敗しました、エラー：deployments.extensions "xxx-recomposer"が見つかりません
[耕うん機] 2017/12/21 15：51：24xxxのアップグレード後のフックを0個実行
[耕うん機] 2017/12/2115：51：24アップグレード後のxxxのフックが完了しました
[ストレージ] 2017/12/2115：51：24リリース「xxx.v68」の更新
[耕うん機] 2017/12/21 15：51：24xxxの更新されたリリースのステータスを更新しています
[ストレージ] 2017/12/2115：51：24リリース「xxx.v85」の更新
[ストレージ] 2017/12/2115：51：25「xxx」の最終リビジョンを取得
[ストレージ] 2017/12/2115：51：25「xxx」のリリース履歴を取得
[kube] 2017/12/21 15:51:38シークレットを取得する： "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得：xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39シークレットを取得する： "xxx-application-secret"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39シークレットを取得する：「azure-secret」
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 ConfigMapの取得を実行しています： "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 ConfigMapの取得を実行しています： "xxx-application-config"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39サービスを取得しています： "xxx-application-svc"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 StatefulSetの取得を実行しています： "xxx-application"
[kube] 2017/12/21 15:51:39オブジェクトのリレーションポッドを取得します：xxx / StatefulSet / xxx-application

＃2941に関連している可能性があります

他のスレッドで述べたように、問題を修正する方法の1つは、バグのあるconfigmapsを削除することでした...現在私のためにそれを行っているようです...

それはすべて大丈夫でダンディです。 それまでは、本番名前空間から重要なものを削除する必要があります。 偶然にも、それはちょうど今私に起こりました。 ：c

我々はリリースをアップグレードするとき、私は複数存在する場合にも問題に直面してきましたDEPLOYEDこのリリースの状態は、削除して、それらの対応するconfigmapsをそれを修正する必要があります。

同じ問題。 昨日はすべて順調で、複数のアップグレードを行いました。 今日、 serviceとdeploymentブロックが---区切られた新しいyamlを追加したところ、アップグレードに失敗しました。

興味深いのは、ヘルムがserviceを作成し、それについて不平を言ったことです（そして展開をしませんでした）。
私はserviceをコメントアウトし、 deploymentブロックでアップグレードを実行しました-それは機能しました。 ただし、helmはサービスを削除しませんでした-yamlファイルから削除されたために必要なサービスです。

更新： serviceを手動で削除し、yamlからコメントを外してアップグレードを実行しました。今回は、魅力のように機能しました。

私はこの正確なエラーを抱えていました。 この問題は、 @ amritbが見たものと同様の複数のAPIオブジェクトを持つテンプレートに関連しているよう

{{ if .Values.enabled }}
---
...

それを独自のテンプレートファイルに分割し、helmが作成して忘れてしまった孤立したオブジェクトをクリーンアップすると、問題が解決しました。 テンプレートごとのオブジェクトの数がリリース間で変更された場合、helmが以前の構成を取得する方法にバグがあるようです。

別のデータポイントの追加：@awwithroとまったく同じ問題が発生しているようです。 jinjaループを使用して、テンプレートを介して複数のcronジョブを作成しています。新しいアップグレードにより、このループが追加のcronジョブを埋めるときに、バグが発生しました。 ＃2941もトリガーするようで（または1つのバグが他のバグを引き起こす可能性があります）、ゾンビconfigmapを削除すると修正されます。

configmapを使用しなくても、これに閉じ込められただけです

立ち往生している可能性のある人のためのいくつかの余分な色：
私のリリースに新しいサブチャートとオブジェクトを導入したとき、私はこれに遭遇していました。 追加されたすべてのオブジェクトタイプをチェックし、名前の衝突を引き起こす可能性のある既存のオブジェクトを削除することで解決できました。

これは、削除が現時点で解決する唯一の方法であるという他の人の証拠と一致しているようです😕

また、これにまたがって実行= \

また、影響を受けるリソースを削除する必要がありました。 実稼働環境には適していません= _（

私は私が似ていると思う何かを見ています。 問題は、 helm upgradeが以前のデプロイの値を--reuse-valuesしないことであるように見えます。 コマンドラインで最初のインストールと同じ値のセットを指定すると、 helm upgrade機能します。 これが役立つかどうか（または他の誰かがこれを確認できる場合）

@amritbのように、helmが最初に失敗したオブジェクトを手動で削除した後、次のアップグレード後に成功しました。 ＃2941は経験していません。

ヘルム2.8.0を使用した同じ問題。 Kubernetesバージョンclient=v1.8.6およびserver=v1.8.5-gke.0 。

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

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

ただし、configmapは$ kubectl get configmap存在します。 configmapを手動で削除すると機能しますが、次回は再び失敗します。

configmapは次のとおりです。

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

リリースを削除して、再インストールしました。 また、デプロイにapiバージョンextensions/v1betaを使用していましたが、 apiVersion: apps/v1beta2に変更しました。これが役に立ったかどうかは、わかりません。
また、現在、ローカルでtillerいます。

現在、すべてが機能しているようです。

これは非常に簡単に再現でき、マニフェストにエラーがある場合に発生します。

resource1とresource2があるように、resource2は最初に依存します。 リリースをアップグレードすると、resource1が作成されます（PVとPVCなど）が、resource2は失敗します。 この後、helmはアップグレード時に常に問題を報告するため、resource1の削除のみが役立ちます（名前が...見つからないPersistentVolume）

同じ問題が発生しました（私たちを獲得したリソースはSecretsでした）。 新しいシークレットを削除して再デプロイすると、修正されました。

失敗のため、 helm listを実行すると、11の異なるリリースがあり、10の失敗したリリースと1つのDEPLOYEDがあることに注意してください。 それは予想外ですよね？ ここと同じ問題のようです： https ：

これにより、通常の本番環境でのデプロイではヘルムが使用できなくなりました:(現在、-dry-runをヘルムに渡してkubectlapplyにパイプするなどの処理を調査しています...これは一部のユーザーにのみ影響するようです。 、私たちが間違っていることが何であるかわからない:(

ティラーログをテーリングした後、ティラーが同時に古いリリースを更新しようとしていることがわかりました。

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

s2osf.v10の古いconfigmapを削除してから、アップグレードが機能しました。

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

@binocularsと同じ問題があり

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

UPGRADE FAILED: no Secret with the name "foobar" found奇妙な問題を引き起こします。
このシークレットを削除しようとしたところ、代わりにいくつかのconfigmapでエラーが発生し、3回目の実行で、前のシークレットにもう一度文句を言いました。

これは、helm2.7.xから2.8.1にアップグレードした後にトリガーされた可能性があります。

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

最後の手段が古いリリースの削除に関するものである場合は、私のコメントhttps://github.com/kubernetes/helm/issues/3513#issuecomment-366918019のように破壊的でない回避策がある可能性があり

基本的に、ログでその古いリビジョンを見つけ、ティラーがデプロイされたステータスを保存する構成マップを手動で編集します。 DEPLOYEDステータスafaikの2つのリビジョンがあってはなりません。

この問題の新しい解決策を見つけました。

kubectl -n kube-system edit cm name_of_your_release.v2 、ここでv2は、 helm list FAILEDとしてマークされた最新のリビジョン番号です。 また、DEPLOYEDリリースの1つを編集し、ステータスをSUPERSEDEDに変更して、2つのリリースが同時にデプロイされないようにすることもできます。

@zuzzasこれは私が言及したものです。 私のためにも働いた

@balboah問題は、

@zuzzas同じ名前空間に多くのリリースがありますか、それとも1つだけですか？ かつて、同じオブジェクトを更新する2つのリリースで問題が発生した場合、それらは互いに競合します。

1つしかない場合、デプロイされたバージョンまでにいくつの障害がありますか？ 1つだけが展開されていることをどのように確認しましたか？

これは＃3539で修正された（前進している）と思われます。 間違っている場合は、再度開いてください。 :)

みなさん、ありがとうございました！

この状態の既存のチャートでは、これは修正されていないことに注意してください。 正常に動作させるには、DEPLOYED状態の古いリリースを削除する必要があります。 @balboahは、「

うーん、Helm 2.8.2でもこの問題が発生します（最新ではありませんが、2.9.0で試しましたが、同じエラーが発生します）。通常、問題のあるリソースを手動で削除すると修正できますが、多くの場合、複数のリソースにカスケードされます。正常にアップグレードする前に、すべてを削除する必要があります。

依存関係がネストされた大きなヘルムチャートが少しあります。 それでいいのでしょうか？

clusterrolebindingでも同じ問題が発生しています。 新しいリソースをチャートに追加すると、 upgradeとupgrade --installがError: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found失敗します

ClusterRoleで@ramyalaと同じ問題が

Helm 2.9.1 、同じ問題が発生しました。

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

クラスターにこのConfigMapが表示されている間。

1つのファイルにフックを持つ複数のリソースがある場合、この問題が発生します

+1、これは2.9.1で再び発生しています。 再度開いてください。

これをバグとして再ラベル付けします。 このリグレッションが発生した原因はわかりませんが、2.9.1でこのバグを再現する方法を誰かに教えていただければ幸いです。

@bacongobbler

ヘルムチャートに新しいイングレスをデプロイしようとすると、これも表示されます。 私は確かにIngressを初めて使用しますが、すべての例に基づいて正しいようで、他のhelm / k8sを数か月間実行しています。

ヘルムチャートstable/nginx-ingressを既に展開しているので、コントローラーが存在します。 エラーは、私が作成しようとしているものを見つけようとしていることを示唆しているようです。 これが私が実行しているコマンドです：

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helmここで、 deploy/helmにはチャートマニフェストが含まれています。

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

更新
両方のパスから/*を削除しましたが、アップグレード/インストールしようとしたときにエラーが発生しなくなりました。 多分それは有効な構文ではありません

こんにちは、
これが私の環境で問題を引き起こしたステップです：

1. ヘルムチャートを数回展開してアップグレードしました。
2. チャートに新しいCronJobオブジェクトを作成し、再度アップグレードしました-cronジョブは正常に作成されました。
3. 次のすべてのアップグレードは、「エラー：アップグレードに失敗しました：「cronjob-name」という名前のCronJobが見つかりません」というエラーが報告されて失敗します。

以前に存在しなかったシークレットを追加したときにも問題が発生します。 「db-credentials」を追加してみました
につながった秘密：

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

関連する可能性のある修正：＃4146

このエラーが発生した場合に、そのPRをテストして修正できるかどうかを確認できれば、k8s APIのリグレッションである可能性が高いことを確認し、修正を進めることができます。 ありがとう！

これが常に再現されるかどうかを100％確認することはできませんが、これは次の状況で発生する傾向があることに気付きました。

1. 新しいリソースを含むヘルムチャートをアップグレードします
2. そのアップグレードは失敗しますが、リソースは失敗したアップグレードの一部として作成されました
3. 以降のアップグレードはすべて失敗します

最後に成功したデプロイに対してhelm rollbackを実行してから再アップグレードを試みると、機能しているように見えます。

有害な変更（たとえば、不変のJobオブジェクトの変更）でチャートを意図的にアップグレードしようとせずに、手動で再現するのは非常に簡単なようです。

1. いくつかのチャートを取り、それをデプロイします（ただし、1つのリソース、たとえばサービスを省略します）
2. 省略されたリソースを手動で追加します（たとえば、「kubectl create」を使用）が、リリースに対応する名前を使用します
3. 省略したリソースをチャートに追加し直してからアップグレードしようとすると、ヘルムは「アップグレードに失敗しました：いいえ」と報告するはずです。名前で見つかりました」

手順は異なりますが、根本的な原因は同じようです。 仮定が間違っている場合は訂正してください。ただし、最後のDEPLOYEDリリースのリビジョンには、Helmの「外部」に追加された（手動など）か、最新のアップグレードが失敗したため、特定のリソースに関する情報が含まれていないようです。あるステップ（たとえば、不変のジョブのアップグレード）で、同時に他のオブジェクトをデプロイし、それらをFAILEDリビジョンに記録します（ただし、DEPLOYEDリビジョンに期待されるトラックがない場合は、履歴を変更することになります） 。 次回の実行時に、Tillerのkubeクライアントはクラスター上のリソースを確認します。つまり、リソースは既にデプロイされているため、記録されているはずです。最新のDEPLOYEDリビジョンをチェックし（FAILEDリビジョンにはまったく接続されていないようです）、そこにリストされているリソースは表示されません。そのため、エラーが報告されます。

@bacongobblerカスタムティラーイメージで＃4146をテストしましたが、この問題は修正されました。 解決策を探している他の人のために、あなたは現在のマスターの問題のパッチを適用してコンパイルすることができます：

make bootstrap build docker-build

ティラーイメージをリポジトリにアップロードし、ティラーをクラスターに再インストールする必要があります。 現在のリリースを破壊することなく、強制的にリセットして再インストールすることができました。

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

修正をテストしてくれてありがとう@ramyala ！ 明日の開発コールでそれについて言及し、他のコアメンテナのいずれかがパッチを思い付く可能性のあるエッジケースを確認するかどうかを確認します。 そうでない場合はマージしましょう。

そのため、＃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

2つのチケットが同一であるため、すべてをまとめるために、これを＃1193の複製として閉じます。 調査結果があれば報告してください。そうすれば、全員が1つのチケットで作業できます。 ありがとう！

警告：この情報は大雑把で理解できませんが、誰かに役立つ場合に備えて、サービスセレクターを次のように変更することでこの問題を回避しました。

selector:
    app: {{ template "mything.name" . }}

に

selector:
    app: mything

おそらく、このコンテキストで変数を使用することに何らかの問題がありますか？

helm delete RELEASE_NAME --purge試しください
もう一度インストールしてください。

私もこの問題にぶつかっています。 チャートにデプロイを使用してサブチャートを追加しようとしましたが、初めてhelm upgrade chart chart-1.0.1.tgzアップグレードすると成功し、その後helm upgrade chart chart-1.0.1.tgzを試行すると、エラーError: UPGRADE FAILED: no Deployment with name "subchart-deployment" foundで失敗しました。

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

ヘルムティラーログは、同じエラーをログに記録するだけです。 これを経験している人もいますか？

同じ問題。 昨日はすべて順調で、複数のアップグレードを行いました。 今日、 serviceとdeploymentブロックが---区切られた新しいyamlを追加したところ、アップグレードに失敗しました。

興味深いのは、ヘルムがserviceを作成し、それについて不平を言ったことです（そして展開をしませんでした）。
私はserviceをコメントアウトし、 deploymentブロックでアップグレードを実行しました-それは機能しました。 ただし、helmはサービスを削除しませんでした-yamlファイルから削除されたために必要なサービスです。

更新： serviceを手動で削除し、yamlからコメントを外してアップグレードを実行しました。今回は、魅力のように機能しました。

こんにちは、私もこの問題を抱えています、そして私はそれを解決することができません、あなたは私にいくつかのプロンプトを与えたいですか？

https://github.com/helm/helm/issues/1193#issuecomment-419555433を参照して

私が同じ問題を目撃していることを確認するだけで、原因も前述のとおりです。

新しいシークレットを追加し、ボリュームで参照しました（無効な構文）。 アップグレードが失敗し、後続のアップグレードが上記のエラーで失敗しました。

リストの秘密は、それが作成されたことを示しました。 シークレットを手動で削除し、アップグレードは正常に完了しました。

同じ、@ thedumbtechguy。 私は日常的にこの問題に遭遇します。 ヘルムがあなたの秘密、構成マップ、役割などをすべて削除する必要があると判断したときは特に楽しいです。アップグレードは、 kubectl deleteへの引数のリストが増え続ける奇抜なゲームになります。 私は数ヶ月前にこのシーシュポスの仕事にタオルを投げるべきでしたが、今では手遅れです。 これと数十の同様の問題が修正されることを願っています！

私はヘルムを1週間使用していて、すでに概説されているすべてに直面しています
ここhttps://medium.com/@7mind_dev/the-problems-with-helm-72a48c50cb45

ここで多くの修正が必要です。

金、2019年3月15日には、午前10時49分PMトム・デイビス[email protected]は書きました：

同じ、 @ thedumbtechguyhttps ：//github.com/thedumbtechguy 。 私は遭遇します
この問題は日常的に発生します。 ヘルムがあなたがする必要があると決定したとき、それは特に楽しいです
シークレット、構成マップ、ロールなどをすべて削除
kubectlへの引数のリストが増え続けるwack-a-moleのゲーム
削除します。 私はこのシーシュポスの仕事の月にタオルを投げるべきだった
前ですが、今では手遅れです。 確かにこれと数十の
同様の問題を修正できます！

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

私はHelmv2.10でも同じことを経験しました。 すでにチャートを展開し、チャートに別のconfigMapを追加しました。 configMap "blah"が見つからなかったため、展開が失敗したと報告されました。 やった

helm upgrade <NAME> chart --debug --dryrun 

configMapが実際にレンダリングされていることを確認するために、レンダリングされました。 クラスター内のconfigMapsを確認し、そこで見つけました。 何とかconfigMapを削除し、アップグレードを再実行しましたが、機能しました。

https://github.com/helm/helm/pull/5460は、今後のエラーメッセージをより明確にする必要があります。

フェアポイント。

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

良い仕事の舵取りチームを続けてください。

これが他の誰かにとって大きな問題である場合は、 https：//github.com/helm/helm/pull/4871でこれらの問題を修正する必要があることを指摘したいと思います。

まだHelmチームによって承認されていないようです。 さらに、自動削除リソースについていくつかの懸念がありました。 誰かがソースからそれを構築して試してみたい場合に備えて、それについて言及するだけです。

同じ問題があり、回避策はhelm delete --purge release 、再インストールしてください。

私は同じ問題に遭遇しました。 @ fbcbarbosa2週間前にマージされたようです。 うまくいけば、次のリリース2.14.0の一部になるはず

同じ問題があり、回避策はhelm delete --purge release 、再インストールしてください。

より破壊的でないオプションは、/ current /バージョンにhelm rollbackを実行することです（つまり、0ステップで）。 私は成功を保証することはできませんが、これまでのところ、それは常に物事をうまく解決してきました。

これが次のリリースで行われるかどうか、そしてそれが来るときに行われるかどうかについての考えはありますか？

5460は2か月前に統合されました。つまり、舵取り2.14.0になっているはずです。

私は問題を修正しました

1. 「ヘルムアップグレード」で文句を言ったリソースを削除します。 （「見つかりません」と表示されますが、実際には見つかります）。 リリース全体を削除しないでください。削除しないと、本番環境で完全に失敗してしまいます。
2. ヘルムのアップグレードをやり直します。 今回は「HappyHelming」が表示されるはずです。 :)

アンブレラヘルムチャートの要件が条件に基づいた構成マップを追加したときに、PRODでこの問題が発生しました。 私たちにとって、修正の回避策は

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

私たちにとって、現在のリビジョンへの単純なロールバックは常に機能していました。

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel修正がどのように機能するか考えていますか？