文章目录
- 一、Helm介绍
- 1、背景
- 2、介绍
- 3、核心概念
- 4、chart的基本结构
- 5、helm官网
- 二、部署Helm
- 1、安装helm客户端
- 2、安装Tiller
- 三、常用指令
- 1、仓库相关 helm repo
- 2、chart相关
- 四、入门案例
- 1、构建第一个chart
- 2、将chart包发布到Repository
- 3、在 Kubernetes 中部署应用
- 4、升级和回退
- 5、删除
- 五、其他补充
- 1、helm的v2和v3版本
- 2、与K8s的版本适配
Helm is the best way to find, share, and use software built for Kubernetes.
即helm是kubernetes中查找、分享、构建应用的最佳方式。
一、Helm介绍
1、背景
使用K8s部署一个应用,涉及到很种K8s资源的协作,如Deployment 用于部署应用控制pod、Service 提供服务发现、Secret 配置存储用户名和密码,可能还需要 pv 和 pvc 来提供持久化数据。
这么多资源,且过于分散,使用kubectl来进行维护和创建,体验极差。
由此产生了这三个思考:
- 如何
统一管理
、配置和更新这些分散的 k8s 的应用资源文件 - 如何分发和复用一套应用
模板
- 如何将应用的一系列资源
当做一个软件包来管理
基于以上,helm出现。
2、介绍
Helm 是 Kubernetes 的包管理器。包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 、在Python中使用 pip,能快速查找、下载和安装软件包。
helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。helm可以理解成k8s的资源整合和再封装。
我的理解,仅供参考:
docker产出一个集装箱,kubectl产出一个货轮去载着这个集装箱,但每次把集装箱搬上货轮很烦,因此helm则直接连货轮带搬好的集装箱一起扔了下来。
docker | kubectl | helm |
---|---|---|
3、核心概念
Helm 包含两个组件,分别是 helm 客户端 和 Tiller 服务器:
- helm :一个命令行工具,Helm的客户端,用于本地开发及管理chart,chart仓库管理等
- Tiller :Helm 的服务端。Tiller 负责接收 Helm 的请求,
与 k8s 的 apiserver 交互
,根据chart 来生成一个 release 并管理 release - chart:Helm的打包格式叫做chart,chart就是一系列k8s文件, 它描述了一组相关的 k8s 集群资源
- release :chart的运行实例,你可以用不同的release name多次安装同一个chart。有点像镜像和容器的关系。
- Repoistory:Helm chart 的仓库,存chart包的
4、chart的基本结构
chart就是一系列文件,包含了一个k8s app应用运行起来的所有要素,比如service, deployment, configmap, serviceaccount, rbac,等。其结构如图:
- charts 目录存放依赖的chart
- Chart.yaml 包含Chart的基本信息,包括chart版本,名称等
- templates 目录下存放应用一系列 k8s 资源的 yaml 模板
- _helpers.tpl 此文件中定义一些可重用的模板片断,此文件中的定义在任何资源定义模板中可用
- NOTES.txt 介绍chart 部署后的帮助信息,如何使用chart等
- values.yaml 包含了必要的值定义(默认值), 用于存储 templates 目录中模板文件中用到变量的值
这些要素都是以template文件的形式存在,再结合values文件,最终渲染出能够被k8s执行的yaml文件 。
5、helm官网
官网:https://helm.sh
helm仓库地址:http://hub.helm.sh/
helm阿里云仓库地址:https://developer.aliyun.com/hub
二、部署Helm
1、安装helm客户端
方式一:手动安装
$ 下载 Helm 二进制文件
$ wget https://storage.googleapis.com/kubernetes-helm/helm-v2.9.1-linux-amd64.tar.gz
$ 解压缩
$ tar -zxvf helm-v2.9.1-linux-amd64.tar.gz
$ 复制 helm 二进制 到bin目录下
$ cp linux-amd64/helm /usr/local/bin/
$ chmod a+x /usr/local/bin/helm
方式二:官方脚本一键安装
$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh
2、安装Tiller
方式一:指令安装
helm init
# 这个地方默认使用 “https://kubernetes-charts.storage.googleapis.com” 作为缺省的 stable repository 的地址
# googleapis.com 国内是不能访问的,可以使用阿里云的源来配置
helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
# 查看安装情况
kubectl get po -n kube-system |grep -i tiller
但kubernetes 从1.6 版本开始加入了 RBAC 授权。当前的 Tiller 没有定义用于授权的 ServiceAccount, 访问 API Server 时会被拒绝,需要给 Tiller 加入授权:
# 创建 Kubernetes 的服务帐号和绑定角色
# 我直接绑定了admin角色,可以对所有namespace下的资源进行操作
$ kubectl create serviceaccount --namespace kube-system tiller
serviceaccount "tiller" created
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io "tiller-cluster-rule" created
# 给 Tiller 的 deployments 添加刚才创建的 ServiceAccount
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
deployment.extensions "tiller-deploy" patched
# 查看 Tiller deployments 资源是否绑定 ServiceAccount
$ kubectl get deploy -n kube-system tiller-deploy -o yaml | grep serviceAccount
serviceAccount: tiller
serviceAccountName: tiller
# 查看 Tiller 是否安装成功
$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
# 想删除卸载Tiller
# 删除 Tiller 的 deployment
kubectl delete deployment tiller-deploy --namespace kube-system
#或者使用
helm reset
方式二:配置文件安装
和方式一类似,不同的是创建用户绑定角色的操作直接在yaml文件中完成了
apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller # 创建tiller用户
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: tiller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin # 绑定admin角色
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
$ kubectl create -f rbac-config.yaml
serviceaccount/tiller created
clusterrolebinding.rbac.authorization.k8s.io/tiller created
$ helm init --service-account tiller --skip-refresh
# 查看 Tiller 是否安装成功
$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
三、常用指令
helm --help
指令汇总:
helm completion - 为指定的shell生成自动补全脚本
helm create - 使用给定的名称创建chart
helm dependency - 管理chart依赖
helm env - helm客户端环境信息
helm get - 下载命名版本的扩展信息
helm history - 检索发布历史
helm install - 安装chart
helm lint - 验证chart是否存在问题
helm list - 列举发布版本
helm package - 将chart目录打包
helm plugin - 安装、列举或卸载Helm插件
helm pull - 从仓库下载chart并(可选)在本地目录中打开
helm push - 推送chart到远程
helm registry - 从注册表登录或登出
helm repo - 添加、列出、删除、更新和索引chart仓库
helm rollback - 回滚发布到上一个版本
helm search - helm中搜索关键字
helm show - 显示chart信息
helm status - 显示命名版本的状态
helm template - 本地渲染模板
helm test - 执行发布的测试
helm uninstall - 卸载版本
helm upgrade - 升级版本
helm verify - 验证给定路径的chart已经被签名且是合法的
helm version - 打印客户端版本信息
1、仓库相关 helm repo
添加一个chart仓库
helm repo add 起名 仓库地址
$ helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
$ helm repo add --username admin --password password myharbor https://harbor.csdn.cn/chartrepo/charts
查看已添加的chart仓库列表
helm repo list
chart仓库内容更新频繁时,update确保本地仓库的数据最新
helm repo update
从本地删除一个仓库
helm repo remove 仓库名
$ helm repo remove stable
2、chart相关
四、入门案例
通过一个例子,演示使用helm来创建、打包、分发、安装、升级、回退K8s应用
1、构建第一个chart
创建一个名为mychart的Chart
# 该指令会在当前目录创建一个mychart目录
helm create mychart
查看结构
[centos@root helm]$ tree mychart
mychart
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
# Chart.yaml 用于描述这个 Chart的相关信息,包括名字、描述信息以及版本等。
# values.yaml 用于存储 templates 目录中模板文件中用到变量的值。
# NOTES.txt 用于介绍 Chart 部署后的一些信息,例如:如何使用这个 Chart、列出缺省的设置等。
# Templates 目录下是 YAML 文件的模板,该模板文件遵循 Go template 语法。
查看下Chart.yaml文件的内容
$ cat mychart/Chart.yaml
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: mychart
version: 0.1.0
查看values.yaml文件(默认部署的是一个nginx),可以看到这里定义了一些当前chart的默认值,这些值会填充到templates下k8s资源的yaml文件中,完成渲染
# Default values for test.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
repository: nginx
tag: stable
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 80
ingress:
enabled: false
annotations: {}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
path: /
hosts:
- chart-example.local
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.local
resources: {}
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources, such as Minikube. If you do want to specify resources, uncomment the following
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
# limits:
# cpu: 100m
# memory: 128Mi
# requests:
# cpu: 100m
# memory: 128Mi
nodeSelector: {}
tolerations: []
affinity: {}
查看templates目录下的k8s资源文件,以service.yaml为例:
apiVersion: v1
kind: Service
metadata:
name: {{ template "nginx-test.fullname" . }}
labels:
app: {{ template "nginx-test.name" . }}
chart: {{ template "nginx-test.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
selector:
app: {{ template "nginx-test.name" . }}
release: {{ .Release.Name }}
- {{ }}是Go语言的标准
- .Values 对象访问 values.yaml 文件的内容
- .Chart 对象用来访问 Chart.yaml 文件的内容
- .Release、.Chart 开头的预定义值可用于任何的模板中
- .Release 对象是 Helm的内置对象之一, 使用 Helm 安装一个 release 时,由 Tiller 分配 release 的名称
检查依赖和模板配置是否正确
# .是当前目录,我就在mychart目录下
$ helm lint .
==> Linting .
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures
将应用打包:
# 还是.
# 因为我就在mychart目录下
$ helm package .
Successfully packaged chart and saved it to: /home/k8s/mychart/mychart-0.1.0.tgz
此时mychart目录被打包成一个mychart-0.1.0.tgz压缩包,存在当前目录下,并同时被保存到了 Helm 的本地缺省仓库目录中。
# 打包时向输出更加详细的信息,加--debug参数
# 在这里可以看到helm本地缺省仓库目录
$ helm package mychartDir --debug
Successfully packaged chart and saved it to: /home/k8s/mychart-0.1.0.tgz
[debug] Successfully saved /home/k8s/mychart-0.1.0.tgz to /home/k8s/.helm/repository/local
2、将chart包发布到Repository
打包了chart并发布到了helm本地仓库目录,但helm search找不到:
$ helm search mychart
No results found
# 这是因为 Repository 目录中的 Chart 包还没有被 Helm 管理
# 查看已配置的仓库的信息
$ helm repo list
# 注:新版本中执行 helm init 命令后默认会配置一个名为 local 的本地仓库。
# 如果helm repo list 可以看到local选项,则为默认添加了,下面就可以跳过了
接下来在本地启动一个仓库服务,并将其加入到Helm Repo列表中
# 启动仓库服务
# Now serving you on 127.0.0.1:8879
helm server
# 直接helm server,则默认是127.0.0.1
# 仓库的存储目录默认是$HOME/.helm/repository/local
我这里指定路径来做Helm仓库的存储目录,再指定服务器IP:
helm serve --address 10.4.129.177:8888 --repo-path /root/.helm/repository/local --url http://10.4.129.177:8888/charts/
# --address
# --repo-path 我上面指定就是默认目录,写不写效果一样
# --url
如果–repo-path指定了其他目录,而非helm本地仓库默认目录。还要通过 helm repo index 命令将 Chart 的 Metadata 记录更新在 index.yaml 文件中
# 更新 Helm Repository 的索引文件
# $HOME
$ cd $HOME/.helm/repository/local
$ helm repo index --url=http://10.4.129.177:8888 .
接下来将本地 Repository 加入 Helm 的 Repo 列表
$ helm repo add local http://10.4.129.177:8888
"local" has been added to your repositories
再次查找刚构建的mychart包,搜索成功
$ helm repo update
$ helm search mychart
NAME CHART VERSION APP VERSION DESCRIPTION
local/mychart 0.1.0 1.0 A Helm chart for Kubernetes
3、在 Kubernetes 中部署应用
Chart 被发布到仓储后,就可以通过 helm install 命令部署该 Chart。
helm install做的事实际是结合values.yaml将 templates 目录下的模板文件渲染成 Kubernetes能够识别的 YAML 格式。
部署前先执行helm install --dry-run --debug <chart_dir> --name <release_name>
命令来验证 Chart 的配置。该输出中包含了模板的变量配置与最终渲染的 YAML 文件。
$ helm install --dry-run --debug local/mychart --name mike-test
[debug] Created tunnel using local port: '46649'
[debug] SERVER: "127.0.0.1:43588"
[debug] Original chart version: ""
[debug] Fetched local/mychart to /root/.helm/cache/archive/mychart-0.1.0.tgz
[debug] CHART PATH: /root/.helm/cache/archive/mychart-0.1.0.tgz
NAME: tylertest
REVISION: 1
RELEASED: Mon Jul 23 10:39:49 2018
CHART: mychart-0.1.0
USER-SUPPLIED VALUES:
{}
COMPUTED VALUES:
affinity: {}
image:
pullPolicy: IfNotPresent
repository: nginx
tag: stable
ingress:
annotations: {}
enabled: false
hosts:
- chart-example.local
path: /
tls: []
nodeSelector: {}
replicaCount: 1
resources: {}
service:
port: 80
type: ClusterIP
tolerations: []
HOOKS:
MANIFEST:
---
# Source: mychart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: tylertest-mychart
labels:
app: mychart
chart: mychart-0.1.0
release: tyler-test
heritage: Tiller
spec:
type: ClusterIP
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
selector:
app: mychart
release: mike-test
---
# Source: mychart/templates/deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: tylertest-mychart
labels:
app: mychart
chart: mychart-0.1.0
release: tyler-test
heritage: Tiller
spec:
replicas: 1
selector:
matchLabels:
app: mychart
release: tyler-test
template:
metadata:
labels:
app: mychart
release: tyler-test
spec:
containers:
- name: mychart
image: "nginx:stable"
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
protocol: TCP
livenessProbe:
httpGet:
path: /
port: http
readinessProbe:
httpGet:
path: /
port: http
resources:
{}
验证通过,接下来部署:
# 部署时需指定 Chart 名及 Release(部署的实例)名。
$ helm install local/mychart --name chart-test
NAME: chart-test
LAST DEPLOYED: Mon Jul 23 10:41:20 2018
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
chart-test-mychart ClusterIP 10.254.120.177 <none> 80/TCP 1s
==> v1beta2/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
chart-test-mychart 1 0 0 0 0s
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
chart-test-mychart-6d56f8c8c9-d685v 0/1 Pending 0 0s
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app=mychart,release=mike-test" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl port-forward $POD_NAME 8080:80
列出的所有已部署的 Release 以及其对应的 Chart
# Revision(更改历史)字段,该字段用于表示某一个 Release 被更新的次数,
# 我们可以用该特性对已部署的 Release 进行回滚
$ helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
chart-test 1 Mon Jul 23 10:41:20 2018 DEPLOYED mychart-0.1.0 default
helm status 查询一个特定的 Release 的状态
$ helm status chart-test
4、升级和回退
升级和回退的关键就是helm list 输出的结果中的 Revision(更改历史)字段
修改Chart.yaml文件,将版本号从 0.1.0 修改为 0.2.0,然后helm package重新打包并发布到本地仓库
$ cat mychart/Chart.yaml
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: mychart
version: 0.2.0
$ helm package mychart
Successfully packaged chart and saved it to...
[centos@k8s-master helm]$ helm search mychart -l
NAME CHART VERSION APP VERSION DESCRIPTION
local/mychart 0.2.0 1.0 A Helm chart for Kubernetes
local/mychart 0.1.0 1.0 A Helm chart for Kubernetes
helm upgrade 命令将已部署的release升级到新版本,–version 参数指定需要升级的版本号,不指定默认升级到最新
[centos@k8s-master helm]$ helm upgrade chart-test mychart
Release "chart-test" has been upgraded. Happy Helming!
LAST DEPLOYED: Thu Apr 25 09:19:53 2019
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
chart-test-mychart 1/1 1 1 25m
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
chart-test-mychart-545479dd4b-hj9ml 1/1 Running 0 25m
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
chart-test-mychart ClusterIP 10.103.51.57 <none> 80/TCP 25m
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=mychart,app.kubernetes.io/instance=tylertest" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl port-forward $POD_NAME 8080:80
升级成功:
接下来回滚,首先查看这个release的所有变更记录
# 查看一个 Release 的所有变更记录
helm history chart-test
# 回滚
# 1 是history指令结果中的Revision字段
[centos@k8s-master helm]$ helm rollback chart-test 1
Rollback was a success! Happy Helming!
5、删除
helm delete删除一个已部署的 Release
[centos@k8s-master helm]$ helm delete chart-test
release "chart-test" deleted
helm ls --deleted查看这个release已被标记为delete
但此时这个release的变更记录数据还在,helm history数据正常
且此时想回滚,还是能成功
如果要移除指定 Release 所有相关的 Kubernetes 资源和 Release 的历史记录,可以加--purge
参数
五、其他补充
1、helm的v2和v3版本
Helm目前有v2和v3版本,v3在v2的基础上做了大大简化,且安全性增强。如图,在v2中,Helm依赖Tiller组件,Tiller组件用于接收Helm客户端发出的指令,与k8s的APIServer交互。
从v3开始,Helm不再使用Tiller组件,而是将与k8s的APIServer交互的功能整合到了Helm客户端程序中。
v2版本迁移到v3版本,参考:https://www.zhaowenyu.com/helm-doc/install/v2_v3_migration.html
2、与K8s的版本适配
不推荐将 Helm 用于比编译它所依赖的版本更高的 Kubernetes 版本,因为 Helm 并没有做出任何向前兼容的保证。
Helm 版本 | 支持的 Kubernetes 版本 |
---|---|
3.7.x | 1.22.x - 1.19.x |
3.6.x | 1.21.x - 1.18.x |
3.5.x | 1.20.x - 1.17.x |
3.4.x | 1.19.x - 1.16.x |
3.3.x | 1.18.x - 1.15.x |
3.2.x | 1.18.x - 1.15.x |
3.1.x | 1.17.x - 1.14.x |
3.0.x | 1.16.x - 1.13.x |
2.16.x | 1.16.x - 1.15.x |
2.15.x | 1.15.x - 1.14.x |
2.14.x | 1.14.x - 1.13.x |
2.13.x | 1.13.x - 1.12.x |
2.12.x | 1.12.x - 1.11.x |
2.11.x | 1.11.x - 1.10.x |
2.10.x | 1.10.x - 1.9.x |
2.9.x | 1.10.x - 1.9.x |
2.8.x | 1.9.x - 1.8.x |
2.7.x | 1.8.x - 1.7.x |
2.6.x | 1.7.x - 1.6.x |
2.5.x | 1.6.x - 1.5.x |
2.4.x | 1.6.x - 1.5.x |
2.3.x | 1.5.x - 1.4.x |
2.2.x | 1.5.x - 1.4.x |
2.1.x | 1.5.x - 1.4.x |
2.0.x | 1.4.x - 1.3.x |