--dry-run标志
helm install和helm upgrade等命令提供了一个名为--dry-run的标志。
当在命令行中添加此标志时，将导致Helm逐步完成前四个阶段（加载chart、确定值、渲染模板、格式化为YAML）。
但是当第四阶段结束时，Helm会将大量信息转储到标准输出，包括所有渲染的模板。然后它将退出，而不将对象发送给Kubernetes，也不创建任何发布记录。
例如，这里是以前的Drupal安装的一个版本，附加了--dry run标志：
$ helm install mysite bitnami/drupal --values values.yaml --set \
drupalEmail=foo@example.com --dry-run
在输出的最前面，它将打印有关此发布版本的信息
前面的内容显示了安装的名称、上次的部署时间（在本例中是当前日期和时间）、它将部署到哪个命名空间、它处于版本的哪个阶段（pending-install）以及版本号。因为这是一个安装，所以修订版本是1。升级时，它将是2或更大的数字。
最后，如果这个chart声明了任何钩子，它们将在这里被枚举。
乍一看，这个元数据条目似乎有很多不必要的数据。
毕竟，如果我们没有实际安装，LAST DEPLOYED有什么用处呢？事实上，这部分信息是整个Helm中使用的标准集。
它是发布记录的一部分：关于发布的一组信息。helm get等命令会使用这些相同的字段。
接下来，在信息块之后，所有渲染的模板都被转储到标准输出：
渲染的Drupal chart有数千行，因此前面只显示了输出的前几行。
在试运行输出的最后，Helm打印面向用户的发行版本说明：
这个试运行（dry-run）特性为Helm用户提供了一种在chart把输出发送到Kubernetes之前调试它的方法。
通过渲染所有模板，可以准确地检查提交给集群的内容。通过发布版本数据，可以验证是否按照预期创建了发布版本。
--dry-run标志的主要目的是让人们有机会在将输出发送到Kubernetes之前检查和调试输出。
在它被引入后不久，Helm维护人员就注意到了用户中的一种趋势：人们希望使用--dry-run将Helm用作模板引擎，然后使用其他工具（如kubectl）将渲染的输出发送到Kubernetes。
但是编写--dry-run时没有考虑到这个用例，这导致了一些问题：
1.--dry-run将非YAML信息与渲染的模板混合。这意味着在将数据发送到kubectl等工具之前，必须对其进行清理。
2.--dry-run在升级时可能会产生与其安装时不同的YAML输出，这可能会让人困惑。
3.它会联系Kubernetes API服务器进行验证，这意味着Helm必须拥有Kubernetes凭据，即使它只是用来试运行一个发行版本。
4.它还将特定于集群的信息插入模板引擎。因此，某些渲染过程的输出可能是特定于集群的。
为了解决这些问题，Helm维护人员引入了一个完全独立的命令：helm template。
helm template命令
虽然--dry-run是为调试而设计的，但helm template是为了将Helm的模板渲染过程与安装或升级逻辑隔离开来。
之前，我们研究了Helm安装或升级的5个阶段,
template命令执行前4个阶段（加载chart、解析值、渲染模板、格式化为YAML）。
但它也有一些额外的注意事项：
- 在helm template执行期间，Helm从不联系远程Kubernetes服务器。
- template命令的作用始终类似于安装。
- 通常需要联系Kubernetes服务器的模板函数和指令将只返回默认数据。
- chart只能访问默认的Kubernetes类型。
关于最后一项，helm template做了一个显著的简化假设。Kubernetes服务器支持内置种类（Pod、Service、ConfigMap等）以及由CRD生成的自定义类型。
当运行安装或升级时，Helm在处理chart之前从Kubernetes服务器获取这些类型。
但是，helm template执行此步骤的方式不同。
在编译Helm时，它是针对Kubernetes的特定版本编译的。Kubernetes库包含该版本的内置类型列表。Helm使用这个内置列表，而不是它从API服务器获取的列表。因此，Helm在helm template运行期间不能访问任何CRD，因为CRD安装在集群上，并且不包含在Kubernetes库中。
如果针对使用新类型或新版本的chart运行旧版本的Helm，会在helm template运行期间产生错误，因为Helm不会把最新类型或版本编译进去。
作为这些决策的结果，helm template在运行之后生成一致的输出。更重要的是，它可以在不能访问Kubernetes集群的环境中运行，比如持续集成（CI）管道。
输出也不同于--dry-run。下面是一个命令示例：
helm template mysite bitnami/drupal --values values.yaml --set \
drupalEmail=foo@example.com
前面是一个大大简化了的输出版本，只显示了命令、开始数据和结束数据的示例。
不过，需要重点注意的是，默认情况下只打印YAML格式的Kubernetes清单。
因为Helm在helm template运行期间不联系Kubernetes集群，所以它不会对输出进行完全验证。
在这种情况下，Helm可能不会发现一些错误。
如果你想要对输出进行完全验证，可以选择使用--validate标志，但是在这种情况下，Helm需要一个有效的kubeconfig文件，其中包含集群的凭据。
helm template命令有大量的标志，这些标志对应于helm install中的标志。因此，在许多情况下，可以像执行helm install一样执行helm template命令，随后捕获YAML并将其与其他工具一起使用。
有时需要截取YAML，用自己的工具修改它，然后将其加载到Kubernetes中。
Helm提供了一种执行这个外部工具的方法，而不必使用helm template。
install、upgrade、rollback和template上的--post-renderer标记会导致Helm将YAML数据发送到命令，然后将结果读回Helm。这是使用Kustomize等工具的好方法。
总而言之，helm template是一个用于将Helm chart渲染到YAML中的工具，--dry-run标志是一个用于调试安装和升级命令，而无须将数据加载到Kubernetes中的工具。
