云原生部署之Helm最佳实践(上)
Posted 持续交付实践指南
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生部署之Helm最佳实践(上)相关的知识，希望对你有一定的参考价值。
半年多前，我们从传统的Ansible自动化部署迁移到了云原生部署。我们没有通过Rancher或者KubeSphere这些平台的可视化界面部署，而是选择了Helm这个命令行工具。原因有以下几点：
1.坚持一切版本化，一切自动化的原则；2.Helm在声明式思维方面相对其它工具更友好；3.方便配置与制品分离；
Helm目前有两个版本：v2和v3。幸运的是，我们正准备大规模使用时，v3版本发布。所以，我们没有经历升级之苦。特此说明以下最佳实践基于Helm3。
注：本文针对对Helm有一定基础的同学，如果没有基础，可以先收藏。
正片开始：
自行版本化chart
maven、npm等构建工具的包会有一个唯一的官方源，但是，Helm的chart包似乎没有，你会遇到很多不同的源。这对chart的版本控制非常不利，因为你不知道哪天，远端的源就不见了。所以，最好的做法，使用helm pull命令将chart下载本地，然后指定一个版本上传制品库Nexus的Helm仓库中。上传命令为：
curl -s -u '${USER_PASS}' --upload-file ${chart_name}-${charts_version}.tgz http://xxx-nexus.com/repository/helm-repo/
使用upgrade —install子命令部署应用
刚开始学习Helm时，我们通常使用helm install来安装chart。但是，第二次执行helm install，就会报错，因为K8s中已经存在了该chart的release了。这个过程对流水线是不友好的，所以，在流水线，我们使用的是helm upgrade —install xx ./xx.tgz来部署。
尽早标准化应用，标准化chart
如果存在100个微服务，我们是不是要创建100个chart呢？事实上，一开始，我们团队就是这样的。这是因为我们的微服务一开始不够标准化，所以，chart也跟着不同。后来，我们逐渐标准化了应用。chart也变成了标准。也就是所有的后端服务使用的是同一个chart。这样做的还有利于提高我们创建新的微服务的速度。
所谓标准化，指的是pod对外提供服务的端口号、优雅停机、设置环境变量的方法等等这些通用的领域的配置都应该是统一的。
尽量少使用if-else判断
以chart中，我们应该尽量少使用if-else判断。有时，宁愿多写几个YAML也不要在同一个文件嵌套if-else。因为要尽可能的让chart本身所见即所得。
下篇预告：
•Helm下，如何实现同一应用多版本部署？•chart工程该如何安排更合理？•密码该如何管理？•如何更好的调试chart？
以上是关于云原生部署之Helm最佳实践(上)的主要内容，如果未能解决你的问题，请参考以下文章
云原生之kubernetes实战使用helm在k8s集群下部署DataEase可视化分析平台
云原生之kubernetes实战在k8s下部署Redis集群
云原生之kubernetes实战在k8s环境下部署Wordpress应用服务