嗨-您能提供更多有关部署方式的详细信息吗？您是否有机会使用helm upgrade --install ？而且，如果这样做了，则当部署中断时（ helm ls ）的状态是什么-大概是Failed ？

如果是这种情况， helm delete --purge <deployment>应该可以解决问题。

reschex 于 2019-04-18

👍15 👎8 ❤2

嗨，很抱歉缺少信息。
是的，我正在使用helm upgrade --install
是的，部署永远停留在Failed 。
不幸的是，这里根本没有helm delete --purge <deployment>的选项。因此，我不能只删除生产服务:)

问题是为什么头盔在连续3次失败后无法恢复。

sta-szek 于 2019-04-18

👍2

排序而不删除版本的唯一方法是添加--force

rimusz 于 2019-04-18

👍2

--force是什么？到helm upgrade --install ？
如果是，那么这意味着上述问题实际上是预期的功能，我们应该在每次部署中使用--force吗？ -如果是，那么这意味着它将强制部署损坏的发行版？

sta-szek 于 2019-04-18

👍6 ❤1

是的，当然是helm upgrade --install :)
是的，您应该在每次部署中使用--force

rimusz 于 2019-04-18

👍2

这是否意味着--force也将强制部署损坏的版本？ -我的意思是，如果pod会一直损坏并重新启动，它将删除旧的pod并安排新的pod吗？
--force force resource update through delete/recreate if needed
delete条件是什么？您能详细说明一下它是如何工作的吗？对于这样的关键标志，描述绝对太短了-我希望它能在幕后完成数千件事情。

顺便说一句，我真的不想结束删除的生产服务，因此--force标志对我来说不是一个选择。

您真的认为这不是问题吗？
甚至错误消息是错误的：
app-name has no deployed releases
指出没有部署的版本
虽然有，但是状态Failed ，掌舵甚至没有尝试修复它:(-通过修复，我的意思是请尝试部署它，而不是一开始就放弃

sta-szek 于 2019-04-18

👍23

参见https://github.com/helm/helm/issues/3208

AmazingTurtle 于 2019-05-14

不能完全同意。我们的生产遇到同样的错误。因此，删除图表不是一种选择，强制安装似乎很危险。 Helm 3中仍然存在此错误。因此，最好包含一个修复程序或更安全的解决方法。

bappr 于 2019-11-08

👍36 😕2 👀1

可以通过删除storage.go：136中的“ status”：“ deployed”进行修复

参见： https :

有空的时候我会解决请求请求。

johannges 于 2019-11-12

👎2 👀1 👍1

适当的代码本来是正确的。从Helm查找要从其升级的最新版本的查询结果中删除status: deployed ，无论当前处于何种状态都可能导致意外结果。它可以暂时性地解决问题，但是会在以后引入更大的问题。

如果在遇到此错误时可以提供helm history的输出，那将很有帮助。确定发行分类帐在“已部署”状态下没有发行的情况下如何结束将更有用。

bacongobbler 于 2019-11-12

第一次部署到新集群时遇到了这个问题。我也应该使用--force吗？

bastoche 于 2019-11-19

在不使用--purge选项的情况下删除以前的发行版时遇到了此问题。

helm delete --purge <release-name>

头盔版本

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

japzio 于 2019-11-25

👍1

我也遇到这个问题。

tomaustin700 于 2019-11-26

@bacongobbler
我用helm3击中了这个。发生这种情况时，历史记录完全是空的，尽管尝试1以后k8s资源就在那里。

复制似乎真的很容易：

头盔升级-安装“带有带有错误退出的容器的容器的东西”
纠正导致容器退出的原因，例如容器内可执行文件的arg值无效，然后重试
->错误：升级失败：“ foo”没有部署的版本

henrikb123 于 2019-12-02

👍9

在我的（CI / CD）方案中，-atomic标志似乎是前进的方向。由于它可以彻底清除初始失败的发行版（好像从未发生过一样），因此我不会在下次尝试中遇到此问题。

henrikb123 于 2019-12-03

👍5

同样在这里，我看不到如何建议使用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

即使我没有更改grafana值中的任何内容

alex88 于 2019-12-10

@ alex88您可以提供helm history的输出吗？我需要知道其他人如何处理此案，以便我们可以找出根本原因并找到解决方案。

bacongobbler 于 2019-12-10

@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

基本上，我已经尝试过多次运行升级以更改某些env变量，因为尽管存在部署错误，但是env变量仍然发生了变化，所以我一直这样做而忽略了该错误

alex88 于 2019-12-10

您是如何进入每个发行都失败的状态的？版本1，版本2和版本3在哪里？

bacongobbler 于 2019-12-10

您是如何进入每个发行都失败的状态的？版本1，版本2和版本3在哪里？

更改环境变量（必须进行多次更改）并每次都运行升级，这是在更改环境变量，但是我不知道如何解决持久卷错误

更新：顺便说一句我正在使用

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

关于以前的版本，头盔可能只保留其中的10个

alex88 于 2019-12-10

Helm3：升级istio时遇到类似的问题，该版本失败了，即使修复了模板中的小错误，我也无法重新部署它。我无法删除生产版本，因为它还会删除带有istio-ingress服务的关联ELB。

ajitchahal 于 2019-12-16

当初始发行版以失败状态结束时，将来还有什么工作可以更改逻辑？

HamzaZo 于 2019-12-17

👍17

如果不接受停机，该怎么办？

% 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"}

com30n 于 2020-01-02

如果不接受停机，该怎么办？

现在，我只使用helm来生成模板，然后手动将其保存在本地并应用

alex88 于 2020-01-03

在我的（CI / CD）方案中，-atomic标志似乎是前进的方向。由于它可以彻底清除初始失败的发行版（好像从未发生过一样），因此我不会在下次尝试中遇到此问题。

@ 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

galindro 于 2020-01-14

👍3

我也遇到了Istio。

1.4.3存在一个Istio问题，如果无法到达Kubernetes API服务器，则安装运行的作业之一将失败。然后，它留下了一个作业，如果您尝试重新运行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

这是在Helm 3.0.2中。

tillig 于 2020-01-15

IMO这是一个关键问题，需要尽快解决。从版本2开始直到现在，我还看到许多其他类似问题针对相同的问题开放，直到现在看来它尚未得到解决。

我只是要求开发人员完全按照@ henrikb123在他的评论中所说的来模拟此问题。这是一种非常简单的模拟方法。您可以使用任何Helm版本（2.xx和3.xx）进行测试。我几乎可以肯定，所有这些都会发生。

也许--atomic应该是一个硬要求（而不是命令行参数）。它甚至和--cleanup-on-fail一样是多余的。不同之处在于--cleanup-on-fail不能像--atomic那样解决此问题。

galindro 于 2020-01-15

👍10

我们在生产中也遇到过这种情况，因此无法选择停机。我们找到了一种解决方法，方法是仅使用最新的命令来修补最新的FAILED configmap，使其贴上标签STATUS: DEPLOYED 。

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

在我们的案例中，我们确定kubernetes实际上最终成功部署了最新的FAILED版本。

我们如何进入这种状态？

基本上，我们的开发团队会忽略FAILED升级，因为Kubernetes在掌舵超时后仍在进行修改。

具体来说，我们正在使用Helm 2，并在分er部署中设置了TILLER_HISTORY_MAX=20 。我们将helm upgrade --wait --timeout 1080用于所有RollingUpdate升级，这些升级花费的时间更长。然后头盔升级开始超时，但是没有人惊慌（只是恼火），因为Kubernetes仍在成功进行修改。在20项升级超时（今天）之后，我们感到震惊，因为我们无法再部署，因为我们看到的是app-name has no deployed releases 。

补丁为何起作用？

我们发现我们只需要在configmap中打上STATUS标签，因为我们意识到Helm可能使用类似于...的请求来请求configmap。

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一致

carlosdoordash 于 2020-01-16

👍7

@bacongobbler而不是想知道如何进入失败状态，应该考虑一个有价值的修复程序，用于升级失败的安装，该安装不会失败。

但实际上，要回答您的问题：超时是发行失败的充分原因。该版本还将卡住，并且在升级并进入超时时无法回滚。

因此具有由权利要求动态创建的体积。在删除索赔（通过删除图表）时，卷也将被许多其他开发人员被困了几个月，并试图解决此问题。

您不喜欢从查询中删除status: deployed的想法。那么，添加一个实际上标记了最新版本的新标签怎么办，而不管其状态是部署还是失败？这实际上是有道理的。因为这就是您要执行的操作，所以您希望获得要从中进行升级的最新版本。如果没有，则应该检查是否有失败的版本。或者只是使用一个新标签直接标记最新标签。

_我很高兴听到您对此的看法。

AmazingTurtle 于 2020-01-16

👍1

完美搭配@AmazingTurtle。

galindro 于 2020-01-19

我不确定是否已经注意到这一点，但是如果图表的首次安装由于任何原因而失败（这是非常普遍的现象，尤其是对于可能需要迭代其图表的首次使用图表的用户，这是很常见的情况），也会出现此问题。配置以使一切正常运行）。

我相信，在这种情况下，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 于 2020-01-23

👍1

@jlegrone是否也可以使用helm delete --purge （v2）或helm uninstall （v3），因为它们都是失败的版本？

hickeyma 于 2020-01-24

@jlegrone指出的是正确的。
@hickeyma您的建议是

galindro 于 2020-01-24

这是过去2年的有害bug，掌上电脑将无法修复它
在大多数生产情况下， helm delete是不可接受的
使用helm3，我们无法kubectl edit secret sh.helm.release....因为它已加密
helm rollback <latest-successful>是正确的解决方法

因此，如果默认情况下您的历史记录为HISTORY_MAX = 10，并且您尝试了10次才能使某项工作正常进行，那么您将完全迷失方向...

如果您对安装和升级有一定的了解，则不能删除sh.helm.release ..... v *机密

头盔必须死掉或修复

kosta709 于 2020-01-30

👍4

找到解决方法
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）设置标签状态=已取代

下一个helm upgrade --install ...将起作用

kosta709 于 2020-01-30

👍9 ❤1

@ kosta709与我对Helm2的发现类似，Helm2将发布以ConfigMaps的形式存储在具有全部为CAPS标签的kube-system命名空间中，Helm3现在在应用程序的命名空间中将发布的内容作为Secrets进行存储，且所有标签均使用小写字母。

因此，对于Helm3，您可以使用稍有不同的kubectl patch命令...

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

carlosdoordash 于 2020-01-30

👍4

我希望我们不必讨论这些变通办法。在产品中修复此问题应是重中之重。提醒您此操作有多严重（不考虑变通方法）：

如果某个发行版首次部署失败，或者如果有足够的发行版本未能使上次成功退出历史记录，那么在没有人工干预的情况下无法修复该发行版。

鉴于连续部署管道中使用Helm可能是一种常见模式，或者至少是所需模式，因此这是行不通的。

henrikb123 于 2020-01-31

我完全同意，但至少要清楚地记录下解决方法，因为当您进入这种状态时，感觉别无选择，只能放弃发行并停电。

除了避免中断的补丁程序外，我们还停止使用helm --wait ，而是依靠自己的轮询逻辑来了解发布成功与否的时间。这需要做更多的工作，但是我们现在有了更多的可见性，当发布花费的时间比预期的长时，这很有用，而且我们可以比超时更早地检测到故障。

carlosdoordash 于 2020-01-31

👍3

对于我来说，在旧版本的helm上这不是问题，并且没有失败的部署，kubectl正在显示正在运行的服务，并且一切正常。

现在我只是尝试运行helm upgrade -f app.yaml --namespace prometheus prometheus prometheus而我刚得到错误： Error: UPGRADE FAILED: "prometheus" has no deployed releases但我无法尝试任何解决方法，因为这是在生产中...

zrsm 于 2020-02-03

@zrsm我们现在要做的是使用helm生成yaml文件，并使用kubectl diff / dry-run预览更改，然后手动应用它们

alex88 于 2020-02-03

👍1

@zrsm我们现在要做的是使用helm生成yaml文件，并使用kubectl diff / dry-run预览更改，然后手动应用它们

感谢您的答复，我降级到2.15.1，但是遇到了类似的问题，但是，我尝试了类似的操作，例如删除〜/ .helm，然后从kubectl重新初始化了分er器服务帐户，完成此操作后，我便可以将图表应用于kubernetes 。我将在今天晚些时候尝试使用头盔3对此进行测试，并通过修复进行回复。我觉得这可能是个问题。

zrsm 于 2020-02-05

嗨，我在这里测试了一下...看起来也删除了我之前的〜/ .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 -

我在想，如果您安装了新的掌舵版本，但没有找到您的serviceaccount东西（我擦拭了笔记本电脑，并在某个时候恢复了），那么就发生了，这就是解决方法。我希望它也对您有用。

zrsm 于 2020-02-06

此错误在Helm 3中仍在进行中，有计划的修复程序吗？

dudicoco 于 2020-02-09

👍33 👀6

由于超时，新群集和新部署也遇到了此问题。我不喜欢手动连接到集群来解决此问题，但是我想这是唯一的选择。

我们可以确保尽快解决此问题吗？

devedse 于 2020-02-18

这个问题是如此令人沮丧，这是完全停止使用helm 。

gretel 于 2020-02-20

😕4 👍2

我同意。这让我发疯。我要修复它。祝我好运。

yinzara 于 2020-02-21

👍16 ❤11

我同意。这让我发疯。我要修复它。祝我好运。

谢谢，祝你好运！

gretel 于 2020-02-21

我不介意让你们中的一些人去看PR＃7653。

我相信这将解决上述问题。

yinzara 于 2020-02-21

不能相信它仍然开放，维护者没有任何反应

yarax 于 2020-02-24

👍8

cc @bacongobbler @mattfarina

HamzaZo 于 2020-02-24

因为它们都是失败的版本，所以使用helm delete --purge（v2）或helm uninstall（v3）也可以吗？

@hickeyma并非总是如此；这也可能是掌舵版本元数据损坏的结果，因此在某些情况下，卸载可能会删除负载下的资源。

jlegrone 于 2020-02-26

有时发行不会失败，但是超时和掌舵将其标记为失败发行，下一次它显示为没有已部署的发行，但是该应用实际上功能齐全，它在我身上发生了很多次，因此我不得不更改发行标签为deployed个。它并非总是可以选择helm delete --purge (v2) or helm uninstall (v3)

rimusz 于 2020-02-26

👎2

@rimusz您如何更改发行标签？

dudicoco 于 2020-02-26

@dudicoco通过手动编辑helm v3最新版本的机密，可以自动执行此操作并使用kubectl patch

rimusz 于 2020-02-26

已经移至https://github.com/k14s/kapp ，它的工作原理就像是一种魅力。

gretel 于 2020-02-26

@rimusz这就是我的想法，谢谢。

dudicoco 于 2020-02-26

我也将自己的修复程序移植到＃7668中的头盔2，但仍在等待有关＃7653的反馈

yinzara 于 2020-02-26

😕3

这里同样的问题，

部署了--wait的发行版已超时，最终启动并运行。它仍然被标记为失败。
因此，以后的部署也将失败。

这意味着发布状态不是可靠的信息。

linkdd 于 2020-03-03

我们在公司中使用k8进行生产中的许多服务。
一个月中有几次，我们在不同应用程序上的掌舵都遇到了相同的问题（“ *没有部署的版本。”）。
我们使用了不同版本的头盔（从2.7到3.0.3）。
该问题未解决。
这会给我们的用户（在群集中部署应用程序的开发人员）带来很多不适
每当我们点击它时，我们都会修补最新的发行机密（已部署状态）。
是否有计划添加一种忽略上一发行版状态并安装新发行版的行为？

yuripastushenko 于 2020-03-05

👍6

将--history-max设置为10（默认值），第一个发行版成功。
然后，接下来的10个发行版在以下方面失败了：
Error: UPGRADE FAILED: timed out waiting for the condition （它是模拟的，因此是预期的）。
之后，下一个（第11个失败）发行版本失败了：
Error: UPGRADE FAILED: "app" has no deployed releases （就是问题！）

除了最近的10个版本（无论它们的状态如何）之外，helm能否始终保留历史上最新的成功发行版？

zkovac-devops 于 2020-03-10

👍2

我喜欢这个主意。需要修改存储功能，但我认为可以做到。

yinzara 于 2020-03-10

https://github.com/helm/helm/pull/4978被合并为Helm2。也许它没有移植到Helm3。如果有人有时间想移植，请随意。

bacongobbler 于 2020-03-10

我尝试用＃7806将其移植到Helm 3，并希望看到它尽快合并。谢谢，@ ultimateboy！

yurrriq 于 2020-03-25

👍2

_first_安装失败的版本（即没有过去的成功版本）怎么办？
我们将upgrade --install用于helm版本的幂等部署，当第一个版本失败时， upgrade --install所有后续调用都将失败，并出现“没有部署的版本”错误（此问题）。

krylovsk 于 2020-03-25

👍18 👀1

“首次发布失败”方案至少更具可管理性，因为您通常手动运行或监视它（并且可以在该位置然后在那里应用修复程序），而不是由刚刚开始出现故障的CI / CD系统运行头盔天，即使修复了代码也无法恢复。

当然，它应该仍然是固定的。

无论如何，保留上一个成功的发行版也很有价值，不仅仅是因为这个错误。例如，调试值文件等问题。

peterholak 于 2020-03-25

👍1

@peterholak “首次发行失败”方案有时也可以通过CI / CD完成，例如-我们限制了对群集的访问，甚至无法创建“ hels ls”，我们应该如何“管理”此文件？

son4etyyy 于 2020-04-01

👍4

看到大多数人在生产中使用头盔，这一问题应该是一个高度优先的问题。我可以使用--atomic运行helm安装，但是如果我想在部署之前检查失败的原因怎么办？在安装失败之前，我会因超时而受到限制，然后恢复。如果我可以成功升级，则在检查故障时不必费时。

javonclarke 于 2020-04-07

👍2

我们还使用upgrade --install来进行helm版本的幂等部署。因为这就是自动ci / cd管道的工作方式。我们不打算手动摆弄头盔，因为那样会绕过我们的部署管道。

在自动部署管道中，第一次部署几乎总是会失败。后续部署不得与第一次尝试不同地触发。

请考虑大幅提高此问题的优先级。

nemoo 于 2020-04-07

👍9

体验太糟糕了，我们不能简单地删除整个发行版，因为它正在生产中！它将导致服务器停机！到底我们该如何处理？

thetruechar 于 2020-04-10

👍9 😄1

另外，有人可以删除问题/支持标签吗？这个问题不是关于缺少文档，而是关于Helm的当前行为，这对于在自动部署管道中的使用不是很支持。

nemoo 于 2020-04-12

👍5

＃7806 PR已合并到主服务器上。它将在3.2中发布。我正在相应地解决此问题。

technosophos 于 2020-04-14

🎉3 👍3

伟大的！这解决了我们与Helm有关的大多数问题。

如果第一个发行版失败了，目前的行为是什么（尚未部署任何发行版）？

存在https://github.com/helm/helm/issues/3353 ，该地址由https://github.com/helm/helm/pull/3597处理，但仅当使用--force时才解决。

--force在Helm 3中有一些问题（https://github.com/helm/helm/issues/6378），并提出了解决方案（https://github.com/helm/helm/ Issues / 7082），再加上此线程中提到的其他注释，使用--force并不总是合适的。因此，整个情况仍不清楚。

peterholak 于 2020-04-14

👍1

@technosophos感谢您的修复。很好奇，什么时候会3.2。发行版可以安装吗？在现有的失败发行版上继续出现app-name has no deployed releases错误。而且它在CI / CD管道中是一种阻止器。

nareshnayini 于 2020-04-14

@peterholak参见＃7913。

bacongobbler 于 2020-04-14

👍1

3.2将在4月16日的公共开发电话会议上进行讨论。我已经将其分类为目前看起来可以立即包装的那些。然后，我们将开始测试版发布过程（假设维护人员都同意明天的电话会议）。

technosophos 于 2020-04-16

👍1

我在AKS解决上面临着相同的问题，可通过以下命令解决上述问题：

helm version : 3.1.2
我只是用命令从k8s集群中删除了软件包
helm delete <release-name>

并运行部署周期以解决问题

sachinmishra007 于 2020-05-06

该问题在3.2.0版本中仍然存在

deimosfr 于 2020-05-06

😕3

@deimosfr在＃7653中已修复，它将在3.2.1版中发布。它尚未发布，但是如果您要构建master，则可以获取修补程序。

hickeyma 于 2020-05-06

🎉2

我在3.2.1上，并且这种情况仍在发生

VengefulAncient 于 2020-05-22

👍1

仍然有可能发生此错误的原因。 3.2.1并没有简单地消除错误。它消除了一些原因。如果您仍然遇到问题，那么问题就出在解决问题之外。

yinzara 于 2020-05-22

@yinzara我有一个经典案例“ path b”，来自原始描述，没有任何问题。我还可以在Helm v2正常工作的另一个群集中重现此错误。当然，我们可以做经典的“这是由其他原因引起的，打开一个新问题”的舞蹈，但是我认为，如果仅仅意识到它并没有真正解决问题，它将更快。

VengefulAncient 于 2020-05-22

helm list的输出是什么？先前的失败版本的“状态”是什么？头盔2存在此问题，并且尚未完全解决，因此我仍然认为您的问题与您的想法无关。

yinzara 于 2020-05-22

在版本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

zodraz 于 2020-05-22

😕3

我在已部署图表上存在相同的问题，并且Pod运行正常

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

ismailyenigul 于 2020-05-26

我确认这件事也发生在我这边

deimosfr 于 2020-05-26

@zodraz您的头盔状态显示您的错误原因。最新版本未显示为失败，而是显示为“待安装”。这意味着管理上一次升级的过程在完成之前（即在错误或成功之前）被人为终止。

项目维护者决定不将挂起的安装状态作为允许升级的有效错误状态。（即，这按设计工作）

我建议您尝试确定为什么在升级之前取消您的头盔升级。那应该是可以避免的情况。

yinzara 于 2020-05-26

我在已部署图表上存在相同的问题，并且Pod运行正常

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 于 2020-05-26

嗨@yinzara ，

事情是，我没有取消它...据我所知，我启动的第三时间（并出错了，因为我在部署中出错导致失败）使它达到了“损坏的状态”。。

此状态不可恢复...因此解决此问题的唯一方法是删除图表...为了避免这种情况的解决方法是使用原子标志始终回滚并且永远不会达到此“损坏的状态” ...

我了解维护者的决定...但是这会导致混乱，根本没有可能的解决方案（如果不删除图表），好吧，就像我说的那样，当3个错误发生时就达到了此状态...没有取消它。。

无论如何，我们吸取了教训，并通过原子标记进行了回滚。

zodraz 于 2020-05-26

嗨@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

ismailyenigul 于 2020-05-26

我有一个同样的问题：'（而且我不能使用清除，因为我会丢失数据并且我不能这样做，我知道这个问题已经解决了，但是我只是在表达自己的痛苦。

GloriaPG 于 2020-06-08

因此，当部署关键的工作负载时，我们必须放弃头盔发布，甚至是istio沟槽头盔的istioctl也是如此（我认为）。我们使用头盔模板。

ajitchahal 于 2020-06-09

👍2

@GloriaPG您可以分享更多信息吗？您如何遇到同样的问题？正如@yinzara在线程前面提到的那样，您可能遇到了＃7652无法修复的情况。但是，在得出结论之前，我们需要更多信息来提供帮助。

bacongobbler 于 2020-06-15

嗨@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

如何解决？似乎带有--install标志的--force不起作用

因为这是生产环境，所以我不能只清除发行版并从头开始创建它:(

谢谢你的建议

sebarys 于 2020-07-09

您的错误似乎与https://github.com/kubernetes/client-go/issues/508有关
您不能在部署上更改选择器。您将不得不取消部署和重新部署。

yinzara 于 2020-07-09

@yinzara有趣的是，我没有在部署中更改选择器，所有功能都在9/10 releasone上运行。在部署过程中发生了某个错误，释放处于失败状态，我无法以任何方式从中恢复-部署本身正在运行，Pods正在运行，但我不再能够对其进行修改。

释放失败后，我无法再使用Helm更改它，这有点违反直觉。我希望标志--force将允许我替换整个部署或强制应用更改，但是我找不到解决现有发行版并使用它的方法。

sebarys 于 2020-07-09

是的，不幸的是，这实际上并不是一个掌舵的问题。您的发布失败了，它在kubernetes中处于不良状态。选择器很可能搞砸了，或者某些东西与您预期的不一样，但是您看到的有关“ app-name”的错误没有已发布的版本只是一个红色鲱鱼。

yinzara 于 2020-07-09

👎5

我已尝试回滚到以前的版本，现在发布的状态为deployed 。不幸的是，它并没有改变任何东西，因此我认为唯一的方法是不幸的是删除并再次部署。

sebarys 于 2020-07-10

因此，与此相关的我的特殊问题很容易重现。

开始使用helm3部署某些东西（带有--atomic和--cleanup-on-fail ），并在开始创建资源后按ctrl + c进行部署。没有任何回滚，资源仍然存在，并且随后运行install --upgrade任何尝试都会导致“没有部署的版本”错误。

实际上，当有人在构建已经在运行的情况下将新提交推送到我们CI系统中的分支时，就会发生ctrl + c的情况-舵升级将被取消，然后处于完全损坏的状态。

在这一点之后，我们可以做些什么来修复它？与该线程中的许多其他线程一样，不能选择删除。

编辑：一旦打破， helm ls不显示发行版， helm history显示为挂起安装状态。

AirbornePorcine 于 2020-07-21

👍5

其实-没关系。对于受此影响的用户，有一种解决方案：手动从kubernetes中删除历史记录。它被存储为秘密。如果删除有问题的pending-install状态条目，则可以再次成功运行upgrade --install ！

AirbornePorcine 于 2020-07-21

❤2

@AirbornePorcine-您能否详细说明kubernetes中所需的更改以删除挂起的安装条目。

tarunnarang0201 于 2020-07-30

@ tarunnarang0201 Helm为每个部署创建一个kubernetes机密，在部署到的同一个命名空间中，您将看到它的类型为'helm.sh/release.v1'，并命名为'sh.helm.release.v1.release。 -name.v1”。您只需要删除最新的机密（在示例中查看“ v1”后缀，对于每个部署，该机密都会增加），这似乎对我来说没有任何阻碍。

AirbornePorcine 于 2020-07-30

👍3 🚀1 🎉1

@AirbornePorcine谢谢！

ninja- 于 2020-08-13

@AirbornePorcine @ tarunnarang0201 @ ninja-您也可以仅修补状态标签...尤其是如果您以前没有任何DEPLOYED版本。

对于Helm 3，请参阅我的评论，网址为

有关Helm 2的更多详细信息和说明，请参阅我的评论，网址为

carlosdoordash 于 2020-08-13

这段对话太长了……每个评论都有一个解决方案……结论是什么？
我们一直使用旧的头盔2.12，但从未遇到过问题，但现在使用v3.2.4，以前失败的部署因此错误而失败。

顺便说一下，我们正在使用Terraform和最新的头盔提供商。所以我们应该使用--force还是--replace

xbmono 于 2020-09-01

@xbmono对话很长，因为有

有很多原因使您的发行版可以进入此状态
这在Helm 2上也是可能的，并且在那里和Helm 3上起作用的解决方案是不同的。
用户在此问题上采取了不同的途径
根据您要执行的操作以及是否愿意冒险/容忍PVC丢失以及各种可能的停机时间组合，有不同的选择。

如果您遇到“没有部署的版本”错误，则不确定install --replace或upgrade --install --force能否单独为您提供帮助。

一个明智的建议可能只能给出

如果您为发行版提供helm history ，以便人们可以看到发生了什么
如果您分享失败的原始原因/您到达那里所做的工作-以及您是否认为原始问题已得到解决

我的可能选项摘要

如果您根本不关心现有的k8s资源或停机，则可以选择helm uninstall && helm install
如果是第一次安装失败，则可以删除发布秘密元数据并再次helm install 。如果由于故障而导致的剩余数据丢失，则可能需要手动清理k8s资源，具体取决于您是否使用了--atomic等。
如果您放弃了--wait安装，而helm history显示最新版本在pending-install ，则可以删除最新版本的秘密元数据或修补发布状态
在场景中的某些其他组合，它也有可能以补丁的发布状态的一种或多种释放的秘密，看看后续upgrade可以进行，但据我所知，大部分案件得到解决＃7653（确保历史上某个地方有deployed版本可以回溯），所以如果这现在有用，我会感到惊讶。

由于这是一个已解决的问题，因此我怀疑存在根本原因，无论如何，调试和记录不同，更具体的故障单都将是一件好事。

chadlwilson 于 2020-09-01

@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每小时都会自动部署我们的环境。使用terraform我不能使用helm upgrade ，这是舵手提供者正在做的事情

在terraform代码中，我将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，如果部署失败并且开发人员对其进行了修复，则下一个部署将升级失败的部署。

xbmono 于 2020-09-01

👍1

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故障似乎很奇怪（错字？错过了命名空间？错舵版本？），但考虑到它的修订1的list上面好像你正在尝试做的第一新图表的首次安装失败，并且首次安装失败。如果您尝试取消阻止操作，则可以按上述方式删除发布秘密元数据或修补其状态，然后重试。从Helm或Helm Terraform Provider的角度来看，这可能表明元数据处于不良状态，但不是从那里到达的。

无论如何，自从＃7653被合并以来，在使用Helm 3.2.1进行失败的首次部署时，我不会遇到upgrade问题。您可能需要仔细检查提供商实际使用的特定Helm版本？ Helm Terraform提供程序在install失败后找出发布状态的方式也可能与此有关。我没有与该提供程序的任何经验，并且个人不赞成将Helm用另一种声明性抽象（例如TF）进行包装，因为当出现问题时我发现它更加不透明，但是您可能想在那儿继续深入研究。

在任何情况下，如我上面所述，如果您因第一次部署失败而遇到的错误是has no deployed releases ，我认为replace或force不会可能会在没有其他干预的情况下帮助您恢复现状，因此最好进一步调试它，并在其他地方进行任何对话，因为在有51位参与者的这张旧的封闭票上来回走动似乎对所有有关方面都不起作用。

chadlwilson 于 2020-09-02

不，没有错字。此外，无论是先部署还是以后部署，都会发生这种情况。

如前所述，我们使用--wait选项来等待Jenkins中的部署，然后通知部署是否失败。

似乎，如果达到超时并且部署不成功，则helm将部署标记为failed ，除了手动删除该版本外，没有其他方法可以恢复。而且我们也不想自动删除发行版，因为这很可怕。

因此，如果我们删除--wait选项，则helm会将部署标记为successful 。

解决方法：

现在，我找到了另一个解决方案。对于那些有相同问题并希望其自动化能够像以前一样正常工作的人，这里是我的解决方法：

从helm部署中删除--wait选项
使用此命令可检索要针对其部署的名称空间的部署列表： kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
您可以使用split将上面的逗号分隔列表转换为数组
然后，您可以并行运行多个命令（我们使用Jenkins，因此很容易做到）为kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
如果在timeout ，例如7m表示7分钟，则部署仍不成功，则命令退出并出现错误
问题解决了。

xbmono 于 2020-09-03

其实-没关系。对于受此影响的用户，有一种解决方案：手动从kubernetes中删除历史记录。它被存储为秘密。如果删除有问题的pending-install状态条目，则可以再次成功运行upgrade --install ！

或者，这对我有用：

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

LasTshaMAN 于 2020-09-16

由kubectl -n $namespace delete secret -lstatus=pending-upgrade
现在再次运行头盔。

abdennour 于 2020-09-29

👍5 🚀4 ❤3 😄3 🎉2 👀1

我不确定为什么要关闭它，我只是用全新的Helm 3.3.4来实现。如果初始安装失败，则第二次头盔升级--install --force仍然显示相同的错误。所有这些变通办法都可以使用，但是都是

有没有人想到只是添加一个标志，它是第一个版本，因此自动删除它应该是安全的？还是添加诸如“-失败时强制删除”之类的内容？忽略该问题将无济于事。

nick4fake 于 2020-10-08

👍4

@ nick4fake AFIK已被PR＃7653关闭。 @yinzara也许可以提供更多详细信息。

hickeyma 于 2020-10-08

维护者的决定是不允许覆盖未决的升级版本。但是您关于所有变通办法都是在CI / CD管道中不起作用的变通办法的说法是不正确的。可以在运行头盔升级之前将最后建议的变通办法添加为构建步骤（我也不会在CI / CD pipieline中使用--force）。它具有与您建议的效果相同的效果，只是它会在安装下一个版本之前删除该版本，而不是在此之后立即删除，以便您调试失败原因。

yinzara 于 2020-10-08

在运行升级命令之前，我还在自动生成中使用了以下命令卸载所有“待处理”版本（确保将NS_NAME环境变量设置为要部署到的名称空间）：
``

！/ usr / bin / env bash

RELEASES = $（helm list --namespace $ NS_NAME --pending --output json | jq -r'。[] | select（.status ==“ pending-install”）| .name'）
如果 [[ ！ -z“ $ RELEASES”]]; 然后
删除头盔--namespace $ NS_NAME $ RELEASES
科幻

yinzara 于 2020-10-08

👍1

@yinzara谢谢您的摘录，对于那些发现此线程的人非常有帮助。

我的观点仍然有效-仅删除发行版并不安全。如果单个资源失败，为何Helm无法强制升级？用新版本替换发行版似乎比完全删除更好。我可能不了解Helm的一些核心基础知识（例如它如何管理状态），所以可能做不到，但是我仍然不明白为什么最好在首次安装失败后强制用户手动进行干预。

我的意思是，仅检查此讨论线程，人们仍然会遇到问题。您如何考虑可能在Helm错误消息中添加一些附加信息，并带有指向该线程的链接以及有关该怎么做的一些建议？

nick4fake 于 2020-10-10

@ nick4fake我认为您将“失败”与“待安装”

图书馆维护者同意您发布失败的原因，这就是他们接受我的PR的原因。

可以升级“失败”的发行版。那就是我的公关所做的。如果由于某个资源失败而导致发行失败，则只需升级该发行版（即，升级--install也可以使用），并且不会给出“ app-name”没有已部署发行版本的错误。

您正在谈论的是“待安装”版本。维护人员认为允许您升级暂挂安装版本（强制或其他方式）是不安全的，因为它可能仍在进行中或处于无法完全解决的部分完整状态。我的PR最初允许此状态，维护人员要求我将其删除。

如果发现此状态的发行版，则可能需要重新考虑您的部署配置。在正确配置的CI / CD管道中，绝对不要发生这种情况。它应该失败或成功。 “待定”表示安装仍在进行中而被取消。

我不是维护者，所以我对您的建议没有任何意见，但是我在代码库中找不到任何实际上印在错误或消息中的Github问题的提法，因此我敢打赌他们不会这样做，但是您欢迎将PR放在一起，请参阅:-)

yinzara 于 2020-10-10

👍1

话虽如此，我不同意您的说法，即您的观点仍然有效。我的建议可能会删除暂挂的发行版，但是， @ abdennour的建议就在您之前，只是删除描述暂挂的安装发行版的机密。如果这样做，您不会从发行版中删除任何资源，而是可以升级发行版。

yinzara 于 2020-10-10

您如何考虑可能在Helm错误消息中添加一些附加信息，并带有指向该线程的链接以及有关该怎么做的一些建议？

为此+1。我们仍然必须四处搜寻，以找到该线程，以了解pending-install版本，因此我们可以开始对此错误消息进行推理。

omnibs 于 2020-10-13

我遇到了helm upgrade ，这使我陷入困境。通过添加-n <namespace> 。也许它将帮助某个人。

sajtrus 于 2020-10-20

对于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可以看到

Jenishk56 于 2020-10-27

👍6 🎉5

Helm: app-name没有部署的版本

最有用的评论

所有120条评论

解决方法：

！/ usr / bin / env bash

相关问题