使用Helm的一点心得体会

Helm 理解

官方的说法是Helm类似于Yum做依赖包管理，其实我倒是觉得Helm更像一个saltsatack/ansible/puppet之类的描述文件或者称之为状态管理

Helm 结合了Yum打包的概念，称之为Chart-> Chart能存入Chart repo仓库形成版本管理

 

学习路线

学习Helm技能的前提条件和路线大致如下:

Linux(了解基本操作) -> Docker (Dockerfile的编写和registry镜像仓库使用) -> Kubernetes（搭建与基本操作，以及网络、存储、负载均衡等内容）->Kubectl 描述文件编写 -> 正式开始学习Helm（有一些脚本语言流程控制基础上手就容易了）

 

Helm 安装

国外没什么说的安装什么版本直接github看一下release，先应用RBAC创建一个角色以便于调用apiserver: 如tiller， 国内建议使用阿里云的镜像

 

Helm 使用场景

适合场景：

1. 比如reids, zookeeper之类的集群那再适合不过了，一键安装效率高
2. 公司那些标准化做的比较好的软件产品或应用，一键安装多个依赖应用程序的

不适合场景：

1.    高速迭代并需要变更基础机构比如， 网络，磁盘的应用
2.    标准化做的不好，一直需要变更deployment而不是Values，每个应用都需要重新写一次的应用

Helm 一些使用经验：

examples/
  Chart.yaml          # Yaml文件，用于描述Chart的基本信息，包括名称版本等
  LICENSE             # [可选] 协议
  README.md           # [可选] 当前Chart的介绍
  values.yaml         # Chart的默认配置文件
  requirements.yaml   # [可选] 用于存放当前Chart依赖的其它Chart的说明文件
  charts/             # [可选]: 该目录中放置当前Chart依赖的其它Chart
  templates/          # [可选]: 部署文件模版目录，模版使用的值来自values.yaml和由Tiller提供的值
  templates/NOTES.txt # [可选]: 放置Chart的使用指南

• 先写kubectl的yaml描述文件，有了描述文件测试通过了再替换变量成为Helm的模板
• 必须要有类生产验证环境，一旦使用代码描述基础架构，真有点故障或问题，上生产之后想再去改代码脑子肯定一片空白，沉着冷静异常重要，更新及时要在验证环境进行测试，高风险高收益，DevOps要对自己每一行代码负责，一行代码可能毁掉所有的荣耀和财富！！
• 建议使用Kubeapps来管理仓库，图形化界面查看部署情况操作友好一些（但是要注意一点，该应用里的repo刷新和命令行的repo update并不同步）
• Chart仓库可以使用chartmuseum，存储用S3或者本地也行毕竟这个负载不如registry这么大，但是一定要备份！备份！备份非常重要

• 在NOTES中写必要的注释，启动后再次验证项目选择了正确的资源：磁盘、网络、负载均衡
• Docker仓库、Chart仓库都使用内网私有或者公有云上私有的仓库也可以，公网这个环境变数太大！
• 多云的基础架构都要在values中抽出来描述，通过参数选择
• 使用git来管理helm相关目录，每次迭代版本必须要有明确commit标识提交，特别是有values.yaml更改的发布的版本，代码即基础架Code as Infrastruture 构最怕的就是Code没有办法Review

总结

     Helm 主要能帮助我们从繁琐反复的日常安装工作中解放出来。各个云都有自己的发布平台，如果不想被某朵云捆绑，建议尽造的抽象到Helm模板，只要代码在，你的基础架构迁移、构建在不考虑业务的层面上来说就是在分钟级别

 

 

 

 

转载于:https://my.oschina.net/gibsonxue/blog/3083469