今天也对我造成了困扰。

看起来可能是由于此提交：
https://github.com/helm/helm/commit/32d7f1a3fc226c1745a58b51e318b7362bc7a0bf

TL; DR-修正清单验证

不幸的是，如果您已经部署了带有空字符串的东西，那么您将无法部署“固定”的东西，因为已经部署的组件将无法通过验证。 您唯一的办法是使用helm delete --purge从历史记录中删除有问题的模板并继续前进。 或回滚头盔/翻土机

正如今天早些时候与社区成员讨论的那样，＃5576是更改。 在2.14之前，Helm静默接受架构验证错误，但从2.14开始，所有清单均得到验证，包括先前已接受的清单。 最终结果是升级到2.14会导致Tiller无法在先前接受的图表上进行清单验证，从而阻止了升级。 对于那个很抱歉！

缓解起来很容易：降级到2.13.1可以立即升级，直到发布修复程序为止。

5643应该解决此问题，因为仅对添加到发行版中的新清单进行验证，并且我们很想听听是否能解决此处提出的问题。 如果是这样，我们可能需要使用此修复程序剪切2.14.1。

编辑：＃5576是进行更改的PR。 ＃5643是应该解决此问题的PR。 :)

除非有人击败我，否则我明天可以尝试＃5643。

谨慎地采取行动，以解决之前“悄无声息”失败的表面验证错误，并警告说在将来的版本中会变成错误吗？ 或至少遵守一种强制标志或一些使用户能够选择如何处理它的标志？

谢谢大家的答复！
我尝试从最新的Helm Canary版本下载二进制文件，但问题仍然存在。 我不确定这些二进制文件是否与master的最新版本相对应。
我在本地构建Helm时遇到问题，所以我会对您的测试@ fooka03的结果非常感兴趣！

我不确定这些二进制文件是否与master的最新版本相对应。

检查helm version的输出-应该可以告诉您您的头盔客户端和耕作机以什么提交方式运行。 由于＃5643中的补丁是服务器端补丁，因此您必须确保分was已更新。

同样，使用k8s 1.8.4：

错误：错误验证“”：错误验证数据：[ValidationError（Deployment.spec.template.spec.containers [1] .ports [0]）：io.k8s.api.core.v1中的未知字段“ exec”。 ContainerPort，ValidationError（Deployment.spec.template.spec.containers [1] .ports [0]）：io.k8s.api.core.v1.ContainerPort中的未知字段“ initialDelaySeconds”

错误：错误验证“”：错误验证数据：ValidationError（StatefulSet.spec）：io.k8s.api.apps.v1beta1.StatefulSetSpec中缺少必填字段“ serviceName”错误：升级失败：错误验证“”：错误验证数据： ValidationError（StatefulSet.spec）：缺少io.k8s.api.apps.v1beta1.StatefulSetSpec`中的必填字段“ serviceName”

我不确定这些二进制文件是否与master的最新版本相对应。

检查helm version的输出-应该可以告诉您您的头盔客户端和耕作机以什么提交方式运行。 由于＃5643中的补丁是服务器端补丁，因此您必须确保分was已更新。

谢谢@bacongobbler ！ 根据您的评论，我升级了耕作机：

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

但是，在运行helm install时，我仍然遇到完全相同的错误。 :(
错误：验证失败：错误验证“”：错误验证数据：Deployment.spec.template.metadata.annotations.buildID中的未知对象类型“ nil”

该提交对应于https://github.com/helm/helm/commit/9fb19967bab21ecb9748440a99487f2fb0560f63 ，因此，尽管已修复，但看来我的问题仍然存在。

我们可以获取此修补程序的ETA吗？ 我真的很想避免使用自建头盔/耕作机修补服务器。 谢谢！

@ daniv-msft您可以尝试在模板Yaml中执行此操作吗？

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

现在， @ SeriousM可以回滚到2.13.1并等待2.14.1发布。 我尝试了提交9fb19967 ，它对我有用

现在， @ SeriousM可以回滚到2.13.1并等待2.14.1发布。 我尝试了提交9fb19967 ，它对我有用

我们有很多天蓝色的devops发布管道（超过30个），并且每个管道都在努力使头盔保持最新的稳定版本。 我现在可以降级，但是一旦开始下一个构建管道，该版本将恢复为2.14.0，我真的不会遍历所有30+版本来禁用该步骤并稍后再次启用它。 抱歉，但是我需要等待此修复程序。

修复程序上有任何ETA吗？

@ daniv-msft您可以尝试在模板Yaml中执行此操作吗？

template:
  metadata:
    labels:
      app: {{ template "gateway.name" . }}
      draft: {{ default "draft-app" .Values.draft }}
      release: {{ .Release.Name }}
    annotations:
      buildID: {{ .Values.buildID | quote }}

这是我的Deployment.yaml文件的内容，该文件与路径Deployment.spec.template.metadata.annotations.buildID相匹配：

spec:
  template:
    metadata:
      annotations:
        buildID: {{ .Values.buildID }}
      labels:
        app: {{ template "fullname" . }}
        env: {{ .Values.labels.env }}

您认为| quote可以解决此问题吗？

@SeriousM哦。 您目前遇到什么错误？ 我用主提交而不是发行版尝试了| quote ，它基本上将值用双引号引起来，并且当值为空时非常有用，因为yaml表示为

  annotations:
    buildID: ""

如果您不使用| quote ，它将显示为

  annotations:
    buildID: 

这将导致问题中描述的验证错误。 我使用创建的虚拟图表对此进行了验证：

issue-5750.tar.gz

@SeriousM哦。 您目前遇到什么错误？

我的错误Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID但我不明白为什么。 首先，我认为buildID没有从azure devops传递到cli命令中，但是由于@ daniv-msft出现了相同的错误，我想这是由于服务器验证所致。

@SeriousM哦。 您目前遇到什么错误？

我试图通过添加| quote甚至甚至删除metadata/annotations/buildID来修改我的deployment.yaml，但这没有帮助。

这是我删除buildID注释时遇到的错误：

Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID

关于2.14.1版本，我们可能要等到KubeCon之后才能削减版本。

关于2.14.1版本，我们可能要等到KubeCon之后才能削减版本。

为了确保正确无误，您是说这个KubeCon吗？

KubeCon欧盟，下周而不是11月。 :)

KubeCon欧盟，下周而不是11月。 :)

因此，我们可以期待在24.5.19上以v2.14.1的形式进行修复吗？
我可以自己编译吗？

@SeriousM您遇到的第一个错误是
Error: UPGRADE FAILED: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
是由于图表模板yamls中的问题，您似乎已经用| quote

下一个错误
Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID
这是由于现有版本中的清单不正确所致。 为避免这种情况，分till器不应验证发布清单，而应仅检查用户提供的清单，这就是PR https://github.com/helm/helm/pull/5643 （修复）所做的并具有被合并为主人。 您可以使用分ary的金丝雀图像来检查它是否对您有用。 如果失败的发行版被修复了一次（通过使用适当的清单进行升级），那么如果管道使用2.14版本，则不会有任何验证问题

您可以使用分ary的金丝雀图像来检查它是否对您有用。

如何部署此映像？

@SeriousM对于任何头盔客户端版本，您都可以使用

helm init --tiller-namespace <namespace> --upgrade --canary-image

要获取最新的helm客户端（主服务器），可以使用以下命令： https: //helm.sh/docs/using_helm/#from -canary-builds

因此，看起来＃5643确实解决了清单验证问题：

helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

Release "belligerent-horse" has been upgraded.
LAST DEPLOYED: Fri May 17 10:32:12 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                             DATA  AGE
<redacted>-belligerent-horse  1     181d
<redacted>                      2     181d

==> v1/Pod(related)
NAME                               READY  STATUS       RESTARTS  AGE
<redacted>-belligerent-horse-0  1/1    Running      0         5m16s
<redacted>-belligerent-horse-1  1/1    Terminating  0         17h

==> v1/Service
NAME           TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)   AGE
<redacted>  ClusterIP  None        <none>       8080/TCP  181d

==> v1/StatefulSet
NAME                             READY  AGE
<redacted>-belligerent-horse  2/2    181d

当然，仍然必须在“新”模板中设置所有缺少的验证字段，但是至少可以让您在现有版本上进行部署。

@SeriousM对于任何头盔客户端版本，您都可以使用

helm init --tiller-namespace <namespace> --upgrade --canary-image

要获取最新的helm客户端（主服务器），可以使用以下命令： https: //helm.sh/docs/using_helm/#from -canary-builds

非常感谢，我会尽快尝试

@ fooka03 >感谢您分享测试结果！ 尽管已解决问题，但我仍在用自己的图表和@ karuppiah7890 （ issue-5750.tar.gz ）提供的图表来重现该问题。 您能否分享您正在使用的图表，或者让我们知道您是否发现与该图表相比有什么不同？

@ karuppiah7890 >使用提供的图表，要成功完成头盔安装，我必须将| quote到deployment.yaml，并且还必须在values.yaml中提供buildID。 如果我将行注释为#buildID: ""或删除| quote ，则将重现该错误，但在v2.13.1上运行正常。

不幸的是，就我而言，实际上不可能升级图表的文件，因此，不暗示对现有图表进行任何更改的修复程序将更容易处理。

尽管已修复，但我是唯一一个重现此问题的人吗？ Helm版本似乎返回了正确的版本，但是还有什么我应该验证以确保我使用的是最新版本吗？

Client: &version.Version{SemVer:"v2.14+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}
Server: &version.Version{SemVer:"canary+unreleased", GitCommit:"9fb19967bab21ecb9748440a99487f2fb0560f63", GitTreeState:"clean"}

@ daniv-msft在我的图表中，无效的模板完全丢失了密钥（statefulset的serviceName）。 由于头盔已自动将其设置为部署清单中的空字符串（serviceName：“”），因此我只需在模板中添加serviceName: {{ .Values.serviceName | default "" | quote }} 。 在这种情况下， default过滤器意味着我不必为serviceName提供值。

正如我在评论中提到的那样，固定版本仍然需要您对新清单进行更改才能通过验证。 唯一不同的是，固定版本也不会对已部署的图表执行验证，这使您无需先清除就可以进行部署。

最终，我认为在无法更新图表文件的情况下，您将不得不使用2.13.1进行更改，直到将其更改为通过验证为止。

@ fooka03 >感谢您的回复！ 我以前不了解该修复程序仅适用于正在升级的已部署图表，而不适用于新图表。

就我而言，不幸的是，坚持使用v2.13.1也不是一种选择。 :(
我们创建并适用于v2.13.1的图表是作为工具的一部分提供给我们的用户的，即使我们要推送解决此问题的新版本，也不能强迫我们的用户使用我们工具的最新版本。
推送新版本的工具/图表可能会减少影响，但是无论如何我们都会让一些用户尝试使用Helm v2.14.0安装图表的早期版本，从而得到验证错误。

即使我了解我的情况是特定的，但此更改是否也不会破坏以前生成的其他一些图表（我想到的是https://github.com/helm/charts/tree/master/稳定的）？

如果是这样，是否可以将验证更改推迟到Helm v3，和/或在上面应用@StephanX的建议并

对缓解策略有任何想法吗，@ mortent？ 也许我们应该把它拿出来，移到Helm 3上。虽然它确实有用，但似乎破坏了以前可以使用的现有用例。 您如何看待？

@bacongobbler我同意我们应该把它拔出来。 基于此处的讨论，我不相信仅将验证限制在新清单（如＃5643中）就足以帮助所有用户。 我有一个PR在所有情况下都禁用架构验证：＃5760。

如果有问题的人可以验证这确实可以解决他们的问题，那就太好了。

我只使用了金丝雀图像，但和以前一样出现了相同的错误： Error: failed decoding reader into objects: error validating "": error validating data: unknown object type "nil" in Deployment.spec.template.metadata.annotations.buildID 。
因此，我做了我能做的最接近的事情，并从deployment.yaml删除了annotations.buildID属性。 这可能不是其他人可以解决此问题的方式，但是您可以将其删除。
我运行2.14.0分till映像没有问题。

@SeriousM似乎canary构建仅基于master分支，您需要自己构建＃5760，因为尚未合并。

我在这里发生了严重的故障，因此我今天可能无法自己进行测试。

谢谢您的回复！ 我也想测试该错误修复，但在本地构建Helm时仍然遇到问题。
我查看了请求请求，尽管我对代码库不熟悉，但更改看起来非常简单。

是否可以完成请求请求，以便我可以在下一个Canary版本中尝试一下？
最坏的情况是，如果确实出现问题，仍然有可能在此提交到达实际用户之前将其还原，对吗？

过去两年来，我们一直在values.yaml使用YAML前向引用，没有任何问题。 这不是有效的YAML，但是它可以正常工作，并使我们的开发人员的生活更加轻松。
对于更复杂的配置，YAML过于简单和受限，但这是Helm到目前为止使用的声明性语言。

请考虑通过标志启用此验证，或者在即将到来的Helm 3.0中提供使用标志禁用该验证的选项。

我们支持此更改并削减2.14.1。

听起来不错，谢谢@bacongobbler和参与解决此问题的每个人！
修复程序可用后，我会尽快尝试。

有趣的是，我在AKS上的restartPolicy上收到相同的验证错误“”（与OP相同），对于GCP，DigitalOcean和Kubernetes Desktop本地而言，这根本不会发生。

每个有此问题的人都使用AKS？

编辑：

我可以确认我的情况（不使用头盔或kubectl后面的任何其他工具）由于某种原因问题出在AKS中。 即使我注释掉它抱怨的领域，该错误仍然发生。

我不确定为什么会这样，但这仅在AKS集群中。

v2.14.1何时可用的任何想法？

@WoLfulus我在GKE上使用2.14.0看到了这一点：

$ helm upgrade my-release --install --namespace test ./my-chart/ -f ./my-chart/values.yaml
UPGRADE FAILED
Error: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec
Error: UPGRADE FAILED: failed decoding reader into objects: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "annotations" in io.k8s.api.core.v1.PodTemplateSpec

$ helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}

@WoLfulus我正在使用手动旋转群集，因此它绝对不限于AKS。 我不确定您将如何进行测试，以使您对为什么遇到这种不一致的行为有任何见解。

@bacongobbler早些时候所说的@andyast ，最早应该在本周的某个时候。 由于上周的kubecon，他们被推迟了。
https://github.com/helm/helm/issues/5750#issuecomment -493464958

@ fooka03和@achton

实际上，这真的很奇怪。

我认为这与AKS（在我的情况下）有关，但是我的问题略有不同。

我试图为部署的initContainers设置restartPolicy （在Container的规范中不存在，但是有些供应商（DigitalOcean）接受了它，就像kubectl是用--validate=false调用的。

我必须删除restartPolicy才能使其在AKS上运行。

因此，我认为就我而言，这与Helm无关，即使错误格式与此问题完全相同。

我们什么时候可以期望对此进行修复？

禁用验证的pull-request https://github.com/helm/helm/pull/5760已由@bacongobbler合并到master（谢谢！）。
我假设，正如@ fooka03所提到的，版本2.14.1将在几天之内不可用，但是我想分享这个好消息。 :)

所做的更改已合并到主服务器上，因此您现在应该能够拉出更改。

对于那些想要尝试canary构建的人： https: //helm.sh/docs/using_helm/#from -canary-builds

有没有人能够测试金丝雀并确认应用于母版的补丁是否解决了此问题？ 我想先验证并修复此错误，然后再切掉2.14.1，避免需要2.14.2。 谢谢！

我将在今天的金丝雀构建中测试此修复程序，并让您知道结果。

我可以确认对我们来说确实有效

同样的事情：我测试了最新的Canary版本中的修复程序，它也对我们有用。

@SeriousM对于任何头盔客户端版本，您都可以使用

helm init --tiller-namespace <namespace> --upgrade --canary-image

要获取最新的helm客户端（主服务器），可以使用以下命令： https: //helm.sh/docs/using_helm/#from -canary-builds

这对我有用，非常感谢

有谁知道如何防止gitlab管道使用helm：latest？ 由于gitlab使用2.14，因此我们正在通过笔记本电脑部署所有内容。 这花了我们很多时间。

@pulpbill如何在GitLab中安装或获取helm客户端？ 您是否从发行版下载？ 或使用docker映像？ 而您想安装2.13.1对吗？

我试图找到一个掌舵的码头工人形象，但找不到任何正式的形象。 如果需要，可以通过下载并在其中放入helm二进制文件来构建docker映像，然后可以在gitlab ci config中使用该映像。 您可以从发布页面-https://github.com/helm/helm/releases中找到用于下载二进制文件（所有版本）的URL。 如果您不想在gitlab中使用docker image和dockerRunner，也可以在gitlab作业中执行相同的操作（下载并安装在$PATH ）。

让我们尝试使主题保持主题不变。 @pulpbill，如果您不介意向掌舵用户的邮件列表发送电子邮件，或者直接询问gitlab团队，那就太好了； 这似乎是gitlab的问题，而不是Helm的问题，而且似乎与此处出现的问题无关。

如果您在此处查看以下内容，则AutoDevops在运行部署作业时会下载头盔： https ://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-
我认为，如果您在cicd变量中设置env var HELM_VERSION，则可能会允许您覆盖它，但不确定。

谢谢@ karuppiah7890和@mitchellmaler感谢您的提示！ 我记得我提出并向gitlab发布autodevops。 我将不得不等待2.4.1的发布，现在没有时间建立新的管道:(

@bacongobbler对不起，主题

Helm v2.14.1已发布： https :

您好，我们在新发布的v3中也遇到了此问题，但在beta版本v3.0.0-beta.4中却没有。 请帮助解决。

这仍然在v3.2.4 。 v3.2.3可以正常工作。

这仍然在v3.2.4 。 v3.2.3可以正常工作。

在Mac上也发生在3.2.3上

头盔版本
version.BuildInfo {版本：“ v3.2.3”，GitCommit：“ 8f832046e258e2cb800894579b1b3b50c2d83492”，GitTreeState：“ clean”，GoVersion：“ go1.13.12”}

我没有访问旧代码的权限，但是图表上确实有一个真正的问题，导致v3.3.0出现错误，并且在修复它时错误消失了