在Helm 3中，"install --dry-run"，"template --validate"到底是什么?和“棉绒"正在做?

问题描述

我已经看到关于所有这些事情的信息相互矛盾.例如:

I've seen conflicting information on what all of these things do. For example:

来自: https://helm.sh/docs/chart_template_guide/debugging/#helm

这意味着两者 template --debug 和试运行会将其发送到服务器.是真的吗?

That implies that both template --debug and the dry run send it to the server. Is that true?

我还看到了一些地方，如果您具有模式，那么 template --validate 也会起作用.真的吗?试车赛还会起毛吗?

I've also seen some places that if you have a schema, that template --validate will also do linting. Is that true? And does the dry run also lint?

这是我的猜测":

如果不添加-validate ，
• 头盔模板将调用 lint even
  • helm模板--debug 不会不将其发送到服务器，但只会打印出更多调试信息
  • helm template calls lint even if you don't add --validate
    • And helm template --debug does not send it to the server, but just prints out more debug info
    • 这是正确的吗?这是Helm进行空转的方式吗?(在头盔3中没有耕种机)

    推荐答案

    简短答案:

    没有-validate 的
    1. helm模板根本不会与Kubernetes服务器联系. helm模板--validate 和 helm install --dry-run 进行了其他一些检查，这些检查确实涉及与API服务器的联系.
    2. helm lint 是不同的，并且两个命令都不会运行链接.
    1. helm template without --validate doesn't contact the Kubernetes server at all. helm template --validate and helm install --dry-run do some additional checks that do involve contacting the API server.
    2. helm lint is different and neither command runs linking.

    在后台， helm install 和 helm模板 非常相似:两者都创建 action.Install 对象并对其进行配置.

    Under the hood, helm install and helm template are very similar: both create an action.Install object and configure it.

    helm template 始终为-dry-run .如果您未指定 helm template --validate ，那么Helm将使用一组默认的API版本，并且实际上在不联系Kubernetes服务器的情况下呈现图表.如果图表包含自定义资源定义(CRD)，则没有-validate 的 helm template 将不会抱怨未在处理它们. helm template --debug 的关键重要作用是，如果模板生成无效的YAML，则无论如何都会将其打印出来.

    helm template is always --dry-run. If you don't specify helm template --validate, then Helm uses a default set of API versions, and in fact renders the chart without contacting a Kubernetes server at all. If the chart includes custom resource definitions (CRDs), helm template without --validate won't complain that they're not being processed. The key important effect of helm template --debug is that, if the template produces invalid YAML, it will get printed out anyways.

    helm install --dry-run --debug 和 helm install --validate 看起来极为相似.在这两种情况下，他们实际上都在不与Kubernetes服务器对话的情况下渲染图表.完成渲染后，他们会与Kubernetes客户端一起检查所产生的YAML对于集群支持的对象是否有效，并且他们都检查集群中当前是否存在任何创建的对象.

    helm install --dry-run --debug and helm install --validate seem extremely similar, in terms of the options they push into the core installer logic. In both cases they actually render the chart without talking to the Kubernetes server. After doing the render, they do check with the Kubernetes client that the produced YAML is valid for what objects the cluster supports, and they both check whether any of the created objects currently exist in the cluster.

    Helm实际上没有运行 kubectl .相反，它直接使用Kubernetes Go客户端库.

    Helm doesn't actually run kubectl. It instead directly uses the Kubernetes Go client library.

    helm lint 是完全独立的动作.它在未渲染的图表上运行其他检查；例如，如果 templates 目录中有一个不是 *.tpl ， *.yml ， *.yaml的文件或 *.txt 文件，您会收到投诉.没有安装路径或模板路径都可以运行它.

    helm lint is a totally separate action. It runs additional checks on the unrendered chart; for example, if there is a file in the templates directory that's not a *.tpl, *.yml, *.yaml, or *.txt file, you'll get a complaint. None of the install or template paths run it.

    这篇关于在Helm 3中，"install --dry-run"，"template --validate"到底是什么?和“棉绒"正在做?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！