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

【云原生】kuberneter中Helm入门到实践_第1张图片

 

引言

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领域。

【云原生】kuberneter中Helm入门到实践_第2张图片

helm与apt对比

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

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

【云原生】kuberneter中Helm入门到实践_第3张图片

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

【云原生】kuberneter中Helm入门到实践_第4张图片

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核心的设计哲学。看完整个文章,即使你什么都没记住,只记住了这张图,你也会有很大的收获了。

【云原生】kuberneter中Helm入门到实践_第5张图片

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/)

【云原生】kuberneter中Helm入门到实践_第6张图片

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

【云原生】kuberneter中Helm入门到实践_第7张图片

  • 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目录结构,每个元素的解释如下:

【云原生】kuberneter中Helm入门到实践_第8张图片

  • 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

【云原生】kuberneter中Helm入门到实践_第9张图片

  • 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中可以使用变量、控制语句、函数等,功能非常丰富。

【云原生】kuberneter中Helm入门到实践_第10张图片

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的示例:

【云原生】kuberneter中Helm入门到实践_第11张图片

可以看到,整个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这么一个“多余”的组件来做权限管理了,另外的几个修改如下图所示,要了解细节,请参考官方的文档。

【云原生】kuberneter中Helm入门到实践_第12张图片

你可能感兴趣的:(kubernetes,云原生,云原生,kubernetes,容器)