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

Question

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

helm install --dry-run --debug or helm template --debug: We've seen this trick already. It's a great way to have the server render your templates, then return the resulting manifest file.

发件人:https://helm.sh/docs/chart_template_guide/debugging/#helm

这意味着 both template --debug 和空运行将它发送到服务器。是真的吗？

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

这是我的“猜测”:

• helm template 调用 lint 即使 如果您不添加 --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

简短的回答:

没有 --validate 的
1. helm template 根本不会联系 Kubernetes 服务器。 helm template --validate 和 helm install --dry-run 执行一些额外的检查，这些检查确实涉及联系 API 服务器。
2. helm lint 不同，两个命令都不会运行链接。

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

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

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

Helm 实际上并不运行 kubectl。它直接使用 Kubernetes Go 客户端库。

helm lint是一个完全独立的 Action 。它对未呈现 图表进行额外检查；例如，如果 templates 目录中的文件不是 *.tpl、*.yml、*.yaml 或 *.txt 文件，您会收到投诉。安装或模板路径均未运行它。