helm --dry-run --debug這個可選參數做調試

我們用模板來生成資源文件的清單，但是如果我們想要調試就非常不方便了，不可能我們每次都去部署一個release實例來校驗模板是否正確，所幸的時 Helm 為我們提供了--dry-run --debug這個可選參數，在執行helm install的時候帶上這兩個參數就可以把對應的 values 值和生成的最終的資源清單文件打印出來，而不會真正的去部署一個release實例，比如我們來調試上面創建的 chart 包：

$ helm install . --dry-run --debug ./mychart [debug] Created tunnel using local port: '35286' [debug] SERVER: "127.0.0.1:35286" [debug] Original chart version: "" [debug] CHART PATH: /root/course/kubeadm/helm/mychart NAME: wrapping-bunny REVISION: 1 RELEASED: Fri Sep 7 23:23:09 2018 CHART: mychart-0.1.0 USER-SUPPLIED VALUES: {} COMPUTED VALUES: ... HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: wrapping-bunny-configmap data: myvalue: "Hello World" 

現在我們使用--dry-run就可以很容易地測試代碼了，不需要每次都去安裝一個 release 實例了，但是要注意的是這不能確保 Kubernetes 本身就一定會接受生成的模板，在調試完成后，還是需要去安裝一個實際的 release 實例來進行驗證的。

 

Debugging Templates

Debugging templates can be tricky because the rendered templates are sent to the Kubernetes API server, which may reject the YAML files for reasons other than formatting.

There are a few commands that can help you debug.

• helm lint is your go-to tool for verifying that your chart follows best practices
• 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.
• helm get manifest: This is a good way to see what templates are installed on the server.

When your YAML is failing to parse, but you want to see what is generated, one easy way to retrieve the YAML is to comment out the problem section in the template, and then re-run helm install --dry-run --debug:

apiVersion: v2 # some: problem section # {{ .Values.foo | quote }}

The above will be rendered and returned with the comments intact:

apiVersion: v2 # some: problem section # "bar"

This provides a quick way of viewing the generated content without YAML parse errors blocking.