测评：使用Kustomize自定义上游Helm图表

1 介绍

Helm图表存储库在过去一年中取得了惊人的增长。现在有200多个应用程序可以使用单个命令安装到Kubernetes集群中。伴随着Charts存储库中维护的应用程序数量增加，新的贡献数量也出现了大幅增长。Charts存储库为社区提供了一个集中的地方，让大家分享对如何部署应用的最佳实践，以及应该为这些应用提供哪些配置旋钮的理解。

正如我之前在Kubecon的演讲中所提到的，这些旋钮（由Helm values.yaml文件提供）好比一个频谱。你从左开始，不可避免地向右走：

 

首次引入图表时，可能会遇到其作者的用例。其他人可以对该图表进行旋转，并找出它在配置方式上更灵活的地方，以适用于自己的用例。随着更多配置值的增加，图表变得更难以进行测试和推理。这种权衡是一种难以管理的权衡，并且通常以图表值变得越来越灵活而结束。

我们在Chart存储库中经常看到的一类更改是自定义，它们可以对Kubernetes清单进行低级更改，以便检测到值文件。这样的例子有：Node Selectors、PVC config 、Taints/ Tolerations、Pod资源（限制/请求）。

到目前为止，大多数流行的图表都允许这种灵活性，因为用户需要对图表进行这些调整才能在其环境中可行。这些类型的值的标志是它们通过K8s API特定配置探测用户与之交互的values.yaml。此时，高级用户很高兴能够调整他们需要的东西，但是如果没有深入的Kubernetes知识，values.yaml文件会变得更长、更难以理解。

上游图表的PR有很大一部分用于将这些“最后一英里”的自定义添加到图表中。虽然这些非常受欢迎并且帮助其他人不必在下游分叉或更改图表，但还有另一种方法可以使上游图表在你的环境中更好地工作。

Kustomize是一个来自CLI特殊兴趣小组的项目。Kustomize“允许你出于多种目的而自定义原始的、无模板的YAML文件，而最初的YAML不受影响并且可以原样使用。”那么，基于自定义原始Kubernetes YAML这一功能，我们如何利用它来自定义上游Helm图表？

答案在于helm template命令，它允许你使用Helms模板和values.yaml参数化，但不是安装到集群中，而是将清单输出到标准输出。一旦完全由Helm渲染，Kustomize就可以修补我们图表的清单。

 

2 教程

这在实践中是什么样的呢？让我们自定义上游Jenkins图表。虽然此图表包含大量使用扩展值文件对其进行参数化的方法，但我将尝试使用默认配置和Kustomize完成类似的操作。

在这个例子中我想： 覆盖默认插件并包含Google Compute Engine插件、增加Jenkins PVC的大小、将内存和CPU提供给Jenkins（毕竟它是Java）、设置默认密码、确保通过JAVA_OPTS环境变量传递-Xmx和-Xms标志。

让我们看看流程会是什么样子：

1.首先，我将上游jenkins / chart渲染到一个名为jenkins-base.yaml的文件中：

git clone https://github.com/kubernetes/charts.gitmkdir charts/stable/my-jenkinscd charts/stablehelm template -n ci jenkins > my-jenkins/jenkins-base.yaml

2.现在我将让helm模板单独渲染出我想要覆盖的模板

helm template -n ci jenkins/ -x templates/jenkins-master-deployment.yaml > my-jenkins/master.yaml

helm template -n ci jenkins/ -x templates/home-pvc.yaml > my-jenkins/home-pvc.yaml

helm template -n ci jenkins/ -x templates/config.yaml > my-jenkins/config.yaml

3.接下来，我可以根据自己的喜好自定义每个资源。请注意，在我的修补清单中未设置的任何内容都将采用来自图表默认值的基本清单（jenkins-base.yaml）的值。最终结果可以在这个库中找到：

https://github.com/viglesiasce/jenkins-chart-kustomize/tree/master

4.一旦有了想用的补丁，我们将通过kustomization.yaml文件告诉Kustomize我们的布局是什么样的。

resources: - jenkins-base.yaml patches: - config.yaml - home-pvc.yaml - master.yaml

5.现在我们可以将自定义图表安装到我们的集群中。

cd my-jenkinskustomize build | kubectl apply -f -

我在这里遇到了一个问题—— Helm由于图表启用/禁用部署某些资源的方式而渲染了空资源。Kustomize没有正确处理这些空资源，所以我不得不从我的jenkins-base.yaml中手动删除它们。

6.现在我们可以移植到Jenkins实例并使用用户名admin和密码foobar登录http：// localhost：8080：

export JENKINS_POD=$(kubectl get pods -l app=ci-jenkins -o jsonpath='{.items[0].metadata.name}')kubectl port-forward $JENKINS_POD 8080

7.现在我可以检查我的自定义是否有效。首先，我能够使用我的自定义密码登录，好极了。

接下来，在Installed Plugins列表中，我可以看到已经安装了Google Compute Engine插件，太棒了。

3 权衡

缺点

这似乎是一个自定义上游Helm图表的好方法，但是这么做会错过什么呢？首先，Helm不再控制集群中的清单发布。这意味着你无法使用helm rollback、helm list或任何与helm release相关的命令来管理部署。使用Helm + Kustomize模式，你可以通过还原提交并重新应用先前的清单，或前滚到可以按预期工作的配置并再次通过CD管道运行更改来进行回滚。

Helm hook在这个模式中有点不稳定，因为helm模板不知道你当前处于发布的哪个阶段，它会将所有hook转储到你的清单中。例如，在此示例中，你将看到Jenkins图表包含一个创建了但由于部署未准备好而失败的的测试hook Pod。通常，测试hook在安装的带外运行。

优点

这个模式的一个好处是，我可以调整图表的实现，而无需向上游提交更改以保持同步。例如，我可以根据需要将自定义标签和注释添加到资源中。当我依赖的图表有更新时，我可以使用helm模板重新计算base，并使得补丁完好。

将Helm与Kustomize一起使用的另一个好处是，我可以将特定于组织的更改与基本应用程序分开。这允许开发人员能够更清楚地看到正在进行的每个环境更改，因为他们需要解析更少的代码。

最后一个好处是，由于Helm不再处理发布管理，我不必安装Tiller，我可以使用kubectl、Weave Flux或Spinnaker等工具来管理部署。

4 下一步是什么

我想与Helm、Charts和Kustomize团队合作，尽可能简化这种模式。如果你有关于如何使这些事情更顺畅的想法，请通过Twitter与我联系。

 

原文链接：

https://testingclouds.wordpress.com/2018/07/20/844/