在 Helm 3 中，“install --dry-run”、“template --validate”和“lint”到底在做什么？

Question

关于所有这些东西的作用，我看到了相互矛盾的信息。例如：

helm install --dry-run --debug或者helm template --debug：我们已经见过这个技巧了。这是让服务器渲染模板，然后返回生成的清单文件的好方法。

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

这意味着试运行都会 template --debug将其发送到服务器。真的吗？

我还看到过一些地方，如果你有一个模式，template --validate也会做 linting。真的吗？试运行也会掉毛吗？

这是我的“猜测”：

• helm templatelint 即使您不添加也会调用--validate
  • 并且helm template --debug不会将其发送到服务器，而只是打印出更多调试信息
• --validate不执行常规模板调用未完成的任何操作
• helm install --dry-run将使用以下命令将生成的每个 YAML 发送到 K8s：kubectl apply --validate=true --dry-run=true --f myyaml.yaml
  • 它是否正确？Helm 就是这样进行演练的吗？（在 helm 3 中没有 Tiller）

Answer 1

简短的答案：

1. helm templatewithout--validate根本不联系 Kubernetes 服务器。 helm template --validate并helm install --dry-run进行一些涉及联系 API 服务器的额外检查。
2. helm lint是不同的，两个命令都运行链接。

在底层，helm install和helm template非常相似：都创建一个action.Install对象并配置它。

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

helm install --dry-run --debug就helm install --validate它们推入核心安装程序逻辑的选项而言，它们看起来非常相似。在这两种情况下，它们实际上都在不与 Kubernetes 服务器通信的情况下渲染图表。完成渲染后，他们会向 Kubernetes 客户端检查生成的 YAML 对于集群支持的对象是否有效，并且检查集群中当前是否存在任何创建的对象。

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

helm lint是一个完全独立的动作。它对未渲染的图表运行额外的检查；例如，如果templates目录中存在不是*.tpl、*.yml、*.yaml或*.txt文件的文件，您将收到投诉。没有任何安装或模板路径运行它。