【云原生】kuberneter中Helm入门到实践

引言

helm是k8s的包管理工具，使用helm，可以使用更为简化和系统化的方式对k8s应用进行部署、升级。

helm是CNCF已毕业的项目，社区也是相当活跃的，在 https://artifacthub.io/ 上，能找到很多现成的helm chart，稍作修改就能用到生产环境中，非常方便。

本文会介绍helm的核心概念，并用一个例子帮助大家更直观的认识helm，大家可以跟着这个例子操作一遍，相信对理解helm会有非常大的作用。

（教程地址：cloud-native-tutorial）

什么是helm

初识helm

helm在希腊语中的意思是：舵；驾驶盘。据说是helm创始人mutt butcher翻遍了航海手册找出来的，目的是为了找一个和kubernetes主题相匹配的词语。

官网地址：https://helm.sh/

官方给出的解释是：Helm is the best way to find, share, and use software built for Kubernetes. 意思是helm是kubernetes中查找、分享、构建应用的最佳方式。

这种说法当然不算夸张，Helm其实是一个Kubernetes应用的包管理工具，用来管理chart（一种预先配置好的安装包资源），有点类似于Ubuntu 的APT和CentOS中的YUM。因此，helm的出现解决了k8s应用管理能力缺失的问题。

另外helm也是dev和ops的桥梁，运维人员在使用helm的时候，一方面不需要理解大量在chart中的各种k8s元素，只需要配置少量的环境变量即可安装；另一方面，helm也给初级运维人员提供了学习的机会，他们可以在chart中学习并理解各种k8s元素，从而能够更快的掌握k8s。

下面列举了helm的一些关键信息

2019 年11 月13 日，Helm 3 发布；
2020 年4 月30 日，从CNCF 中毕业；
目前github上接近有1.9w个Star；
最新版本：3.5.0；
主要作者：Mutt Butcher，目前在Microsoft，主要关注DevOps领域。

helm与apt对比

在我们接触一个新事物的时候，最好的学习方式就是和我们熟悉的事务来做类比，能够帮助我们快速的掌握其中的核心概念。

由于Mutt Butcher在设计helm的时候，大量参考了apt和homebrew的设计，这里我们用apt来做对比，帮助大家更好的理解helm。

从下表中可以看到，helm和apt之间概念的对比，相信熟悉apt的同学能够很快的对helm有一个初步的认识。

helm总览

对helm有了一个初步的印象之后，我们来对helm做一个总览，包括helm的的核心概念、运行流程、常用命令、chart做一个概要性的了解，这样的话，对我们后续深入helm的学习和实践起一个纲领的作业，避免只见树木、不见森林。

helm三大概念

chart：chart就是helm package，包含了一个k8s app应用运行起来的所有要素，比如service, deployment, configmap, serviceaccount, rbac, 等，这些要素都是以template文件的形式存在，再结合values文件，最终渲染出能够被k8s执行的yaml文件；
repository：仓库是charts的集合，方便进行分享和分发。下面是官网仓库和阿里云仓库的地址，大家可以进去看看，感受一下；
- https://artifacthub.io/
- https://developer.aliyun.com/hub
release：release是helm chart在kubernetes的一个运行实例，你可以用不同的release name多次安装同一个chart，比如：当集群中需要多个redis实例，你可以使用不同的配置文件安装redis chart。

helm运行流程

下面这张图我建议大家多看几遍，可以说掌握了这张图，就掌握了helm的核心。

从下图可以看到，helm的核心运行流程分为以下几步：

从chart仓库中获取chart；
使用者配置自己的values文件，根据自己的运行环境对values进行修改；
默认values文件和使用者values文件会进行一个merge，形成最终的values文件；
使用最终的values文件，渲染chart的template，形成可以被kubernetes执行的yaml；
调用kube apply提交yaml到kubernetes

在这里，需要注意chart开发者和使用者的界限，正是由于在跨越这个界限的时候，从需要理解大量的配置到只需要理解少量的配置，使得ops的工作变得简便，这也是helm核心的设计哲学。看完整个文章，即使你什么都没记住，只记住了这张图，你也会有很大的收获了。

helm常用命令

在helm的时候，你可以使用第三方开发的chart，也可以自己开发chart，以下是两种情况下使用的常见命令。更为详细的命令，可以安装好helm之后，使用helm help来查看，或查看官方文档。

使用第三方开发的chart

部署前

repo: add, list, remove, update, and index chart repositories
search: search for a keyword in charts

部署后

install: install a chart
list: list releases
status: display the status of the named release
upgrade: upgrade a release
rollback: roll back a release to a previous revision
uninstall: uninstall a release

自己开发chart

lint: examine a chart for possible issues
package: package a chart directory into a chart archive
push: push helm chart to chartmuseum
chart push: push helm chart to OCI repository

chart

chart可以说是helm里面最重要的概念了，关于chart也有很多内容需要掌握，在这里做一个列举。

chart开发：主要是指利用模板技术开发一个chart，会在后面做详细介绍；
chart hooks：在chart的生命周期中，提供一些hooks，方便进行一些前置或后置操作
- 在chart安装前，创建应用需要的Secret
- 在chart安装前，备份数据库
- 在chart卸载后，做一些清理工作
chart test：当你install了一个chart后，如何知道这个release是否运行正常呢？chart test提供了一种测试的方式，来验证你的应用是否正常运行，比如：
- 校验mysql应用能够正常连接并接受请求
- 校验services能够正常做load balance
library chart：一种以library形式存在的chart，可以在application chart之间进行共享避免重复逻辑；类似于编程语言中的public library；
chart校验：基于PKI、GnuPG等技术，对helm package进行签名，保证传输或发布过程中的安全性；
OCI（Open Container Initiative，容器发型规范）支持：helm 3引入（EXPERIMENTAL），能够将chart推送到支持OCI的仓库中，比如harbor, nexus，等，比如，将chart保存到harbor中：
保存chart：helm chart save kubeedge/ some-harbor-repo/kubeedge-cloud-chart:1.0.0
登录repo：helm registry login https://some-harbor-repo
推送chart：helm chart push some-harbor-repo/kubeedge-cloud-chart:1.0.0
高级特性
- post rendering: 提供在helm install之前对manifests进行操作、配置的一种机制；一般结合kustomize使用。比如：
  - 在install时插入sidecar，从而为deployment增加功能
  - 不修改原chart的情况下，更改manifests的配置

这可能不是非常好理解，这里举一个例子，假设我需要对一个第三方的chart做少量的修改，以满足我的部署要求，那么我可以fork一份这个chart，然后在上面做修改，但是这样我需要一些额外的维护工作，当这个chart升级之后，我还需要做merge的工作，十分不便。

因此post rendering提供了一种机制，你只需要使用post rendering+kustomize编写的一个脚本，就可以在install前，对原始chart的内容做一些定制化的修改，避免了额外的维护工作。如下图所示。（kustomize是一个开源的配置工具，可以方便的对现有的k8s app配置做一些定制化的修改，官网地址：https://kustomize.io/）

go sdk：helm提供了golang sdk，方便在go语言中使用；
storage backend：指定release信息的存储类型，默认是secret；可以指定configmap、secret和postgreSQL；下图显示helm的版本信息存放在secret中的情况。

helm plugin：支持以插件的形式拓展helm的功能。

helm demo

下面我们一起用一个demo来对helm有一个更为直观的了解。在这个demo中，我们的目标是部署一个redis集群，包括以下几个步骤：

安装helm
使用helm install单节点redis
使用helm upgrade升级到master-slave
使用helm rollback，回滚到单节点模式

步骤1：安装helm（通过apt）

以下是通过apt安装helm的命令，其他的安装方式可参考官网：

curl https://baltocdn.com/helm/signing.asc | sudo apt-key add – 
sudo apt-get install apt-transport-https --yes 
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list 
sudo apt-get update 
sudo apt-get install helm=3.4.2-1

步骤2：添加仓库并找到redis chart

添加仓库：helm repo add stable https://charts.helm.sh/stable
查看已经添加的仓库：helm repo list
搜索仓库有哪些chart：helm search repo stable
更新仓库列表到本地：helm repo update
搜索redis：helm search repo redis
查看redis chart详情：helm show chart stable/redis
查看redis values（values：相当于chart的配置文件）：helm show values stable/redis

步骤3：install/upgrade/rollback/uninstall

建立单master的配置文件，名为only-master.values

## Cluster settings   
cluster:     
  enabled: false

## Redis pod Security Context   
securityContext:     
  enabled: false

## Use password authentication   
usePassword: true   

## Redis password (both master and slave)   
password: "admin"

## Redis Master parameters   
master:     
  persistence:       
    enabled: false

然后--dry-run一下，看看生成出来的yaml文件是否存在问题：

helm install redis-demo stable/redis -f ./only-master.values --dry-run

如果没有问题，则进行实际的安装

helm install redis-demo stable/redis -f ./only-master.values

安装成功之后，可以登录redis进行操作，做进一步的校验：

redis-cli -h `kubectl get svc redis-demo-master -o=jsonpath="{.spec.clusterIP}"` -a admin
set name zhangsan  
get name
info replication
# 可以看到这时候没有slave连接

建立master-slave配置文件，名为master-slave.values

## Cluster settings   
cluster:     
  enabled: true     
  slaveCount: 1

securityContext:     
  enabled: false

## Use password authentication   
usePassword: true   
password: "admin"

## Mount secrets as files instead of environment variables   
usePasswordFile: false

## Redis Master parameters   
master:     
  persistence:       
    enabled: false

## Redis Slave properties   
slave:     
  persistence:       
  enabled: false

--dry-run一下，看看生成出来的yaml文件是否存在问题；由于在系统中已经有redis-demo的release，因此使用upgrade来进行升级：

helm upgrade redis-demo stable/redis -f ./master-slave.values --dry-run   helm upgrade redis-demo stable/redis -f ./master-slave.values

检查slave是否安装成功，以及是否同步成功

redis-cli -h `kubectl get svc redis-demo-slave -o=jsonpath="{.spec.clusterIP}"` -a admin   
get name

最后，回滚至单master模式
查看部署历史：helm history redis-demo
回滚到对应的单master版本：helm rollback redis-demo REVISION
再连接slave已经不成功了：

redis-cli -h `kubectl get svc redis-demo-slave -o=jsonpath="{.spec.clusterIP}"` -a admin

只有master能连接：

redis-cli -hkubectl get svc redis-demo-master -o=jsonpath="{.spec.clusterIP}"` -a admin
# 输入命令测试一下
get age

卸载redis-demo

helm uninstall redis-demo

chart详解

总体结构

下图是wordpress的helm chart目录结构，每个元素的解释如下：

Chart.yaml: chart的信息，包括chart的版本信息、描述信息、依赖关系，等
LICENSE: (可选)chart的LICENSE信息
README.md: (可选)chart的说明文件
values.yaml: chart的默认配置信息
values.schema.json: (可选) values配置信息的元信息（字段类型、字段描述、字段之间的依赖等），格式json
charts: 依赖的其他chart
crds: Custom Resource Definitions
templates: 部署模板，结合values.yaml会渲染出kubernetes yaml文件
templates/NOTES.txt: (可选)安装说明

Chart.yaml

Chart.yaml相当于chart的说明书，说明了这个chart的功能、版本、依赖关系、关键字等信息。

下图是redis的Chart.yaml

apiVersion: chart api version, 目前helm 3固定为v2
name: chart名字
description: chart描述
type:
- application: 可部署的chart
- library: 不可部署，可在不同chart间共享公用逻辑
version: chart的版本
appVersion: chart内应用的版本，比如redis的版本
kubeVersion: 兼容的k8s版本
keywords: 关键词，在helm search中用到
dependencies: 依赖的chart
mantainers: chart的开发人员
icon: chart图标，会在hub中展示

template

template存放chart中的主要内容，主要以模板的形式存在，template中可以使用变量、控制语句、函数等，功能非常丰富。

chart hub & chart repo

chart hub：可以理解为chart仓库的汇总，官方地址：https://artifacthub.io/
chart repo：chart仓库，存放具体的chart
- 示例：https://charts.bitnami.com/bitnami
- 开源的仓库：harbor (https://goharbor.io/)（利用helm OCI的支持）
- helm官方提供的仓库：chartmuseum - https://github.com/helm/chartmuseum
chart repo UI：https://github.com/helm/monocular

helm CICD

可以使用helm来构建CICD pipeline，下面是一个CICD的示例：

可以看到，整个CICD分为3个步骤，当然这只是一个例子，开发者可以根据实际的需要对这个步骤进行调整：

stage1：开发人员编码、自测通过后，提交feature分支，并触发pipeline构建，并分别产生具有相同tag的docker image和helm chart，并部署helm chart
stage2：reviewer review代码，测试通过后merge到release分支，修改版本号，并产生new tag的docker image和helm chart，并部署到集群
stage3：测试、产品、客户，在staging上验证通过后，直接把helm chart部署到生产环境

从helm v2 到 v3 都有哪些变化

从下图中看到，最大的变化就是移出了tiller，主要原因是k8s早已支持了RBAC，不再需要tiller这么一个“多余”的组件来做权限管理了，另外的几个修改如下图所示，要了解细节，请参考官方的文档。