Helm基本介绍
- 微服务和容器化给复杂应用部署与管理带来了极大的挑战。
Helm
是目前Kubernetes
服务编排领域的唯一开源子项目,做为Kubernetes
应用的一个包管理工具,可理解为Kubernetes
的apt-get / yum
,由Deis
公司发起,该公司已经被微软收购。Helm
通过软件打包的形式,支持发布的版本管理和控制,很大程度上简化了Kubernetes
应用部署和管理的复杂性。 - 随着业务容器化与向微服务架构转变,通过分解巨大的单体应用为多个服务的方式,分解了单体应用的复杂性,使每个微服务都可以独立部署和扩展,实现了敏捷开发和快速迭代和部署。但任何事情都有两面性,虽然微服务给我们带来了很多便利,但由于应用被拆分成多个组件,导致服务数量大幅增加,对于
Kubernetest
编排来说,每个组件有自己的资源文件,并且可以独立的部署与伸缩,这给采用Kubernetes
做应用编排带来了诸多挑战:K8s K8s
-
Helm
把Kubernetes
资源(比如deployments
、services
或ingress
)等打包到一个chart
中,而chart
被保存到chart
仓库。通过chart
仓库可用来存储和分享chart
。Helm
使发布可配置,支持发布应用配置的版本管理,简化了Kubernetes
部署应用的版本控制、打包、发布、删除、更新等操作。 - 项目地址: https://github.com/helm/helm
Helm
术语
-
Chart
: 一个helm
程序包,是创建一个应用的信息集合,包含各种Kubernetes
对象的配置模板、参数定义、依赖关系、文档说明等。可以将Chart
比喻为yum
中的软件安装包 -
Repository
:Charts
仓库,用于集中存储和分发Charts
-
config
: 包含了应用发布配置信息 -
Release
: 特定的Chart
部署于目标集群上的一个实例,代表这一个正在运行的应用。当chart被安装到Kubernetes
集群,就会生成一个release
,chart
可以多次安装到同一个集群,每次安装都是一个新的release
Helm系统架构
helm
采用客户端/服务端架构,有如下组件组成:
-
Helm
客户端:用户命令行工具,负责本地chart
开发、仓库管理、与Tiller server
交互、发送预安装的chart
、查询release
信息和要求升级或卸载已存在的release
-
Tiller Server
:部署在Kubernetes
集群内部的server
,其与Helm client
、Kubernetes API Server
进行交互。负责监听来自Helm client
的请求、通过chart
及其配置构建一次发布、安装chart
到Kubernetes
集群并跟踪随后的发布、通过与Kubernetes
交互升级或卸载chart
。 -
Repository
:Chart
仓库,Helm
客户端通过HTTP
协议来访问仓库中Chart
的索引文件和压缩包
Helm
工作原理
-
Helm
包括两部分,Helm
客户端和Tiller
服务端。 -
Helm
客户端是一个命令行工具,采用go
语言编写,负责管理charts
、repository
和release
。它通过gPRC API
向Tiller server
发送请求。 -
Tiller
服务端同样采用go
语言编写,提供了gPRC server
接受来自Helm
客户端的请求,利用Kubernetes client
库把相关资源的操作发送到Kubernetes
,负责管理(安装、查询、升级或删除)和跟踪Kubernetes
资源。为了方便管理,Tiller
服务端把release
的相关信息保存在Kubernetes
的ConfigMap
中。
Helm
安装
- 准备一套
Kubernetes
集群并在每个节点都安装依赖包socat
$ yum -y install socat
- 从
Helm
项目地址下载v2.15.1
版本,将压缩包解压后的二进制文件复制到可执行文件目录/usr/local/bin
中
$ tar xvf helm-v2.15.1-linux-amd64.tar.gz $ cp /root/helm/linux-amd64/helm /usr/local/bin/helm
-
Helm Tiller
是Helm
的server
端,以Pod
形式部署到Kubernetes
集群中。通过命令helm init
初始化Helm
服务,该命令会检查Helm
本地环境设置是否正确,helm init
会连接kubelet
默认连接的Kubernetes
集群,一旦连接集群成功,Tiller
服务会被安装到Kubernetes
集群中的kube-system
命名空间中
$ helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.15.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
- 查看
Tiller
服务相关的Pod
是否正常启动
$ kubectl get pods -n kube-system -o wide |grep tiller
- 创建
serviceAccount
来授权Tiller
服务可能访问Kubernetes
集群中的资源
$ kubectl create serviceaccount --namespace kube-system tiller $ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller $ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
- 验证
Tiller
服务是否正常,如果Helm
客户端可以正常连接Tiller
服务则输出信息如下。
$ helm version Client: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.15.1", GitCommit:"cf1de4f8ba70eded310918a8af3a96bfe8e7683b", GitTreeState:"clean"}
Chart
私有仓库
chart
仓库用来存储和分享打包的 chart
,官方 chart
仓库由 Kubernetes Charts
维护, Helm
允许我们创建私有 chart
仓库。 chart
仓库是一个可用来存储 index.yml
与打包的 chart
文件的 HTTP server
,当要分享 chart
时,需要上传 chart
文件到 chart
仓库。任何一个能能够提供 YAML
与 tar
文件的 HTTP server
都可以当做 chart
仓库,比如 Google Cloud Storage (GCS) bucket、Amazon S3 bucket、Github Pages
或创建你自己的web服务器
Chart
仓库结构
- 一个
chart
仓库由多个chart
包与index.yaml
文件组成,index.yaml
记录了chart
仓库中全部chart
的索引
创建并添加 Chart
私有仓库到本地仓库列表中
- 创建
Chart
私有仓库存储目录并启动一个私有仓库绑定该目录
$ mkdir -p /root/helm-dir/charts/ $ helm serve --address 0.0.0.0:8879 --repo-path /root/helm-dir/charts/
- 当私有仓库服务启动后会在
/root/helm-dir/charts
目录中自动创建一个index.yaml
文件,内容如下
apiVersion: v1 entries: {} generated: "2020-03-27T14:50:43.3791484+08:00"
- 创建一个
chart
包并打包、移动压缩包到Chart
私有仓库存储目录中
$ helm create test01 $ helm package test01 $ mv test01-0.1.0.tgz /root/helm-dir/charts/
- 通过
helm repo index
命令重新生成index.yaml
文件,命令会根据现有的chart
压缩包来生成索引。新的索引文件index.yaml
中会包含添加的chart
压缩包信息
$ helm repo index /root/helm-dir/charts/ --url http://192.168.31.221:8879/charts $ ls -l /root/helm-dir/charts/ total 8 -rw-r--r-- 1 root root 386 Mar 10 14:51 index.yaml -rw-r--r-- 1 root root 3248 Mar 10 14:03 test01-0.1.0.tgz $ cat /root/helm-dir/charts/index.yaml apiVersion: v1 entries: test01: - apiVersion: v1 appVersion: "1.0" created: "2020-03-10T14:51:27.781754825+08:00" description: A Helm chart for Kubernetes digest: cec95ca0e38174d080cc9e3d81380a0f077cd28a30b28571e76b035bc051a9b6 name: test01 urls: - http:// 192.168.31.221:8879/test01-0.1.0.tgz version: 0.1.0 generated: "2020-03-10T14:51:27.781091459+08:00"
- 添加
Chart
私有仓库到本地仓库列表中,并更新本地仓库列表资源缓存
$ helm repo add localRegistry http://192.168.31.221:8879/charts "localRegistry" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "localRegistry" chart repository ...Successfully got an update from the "stable" chart repository Update Complete.
- 查看本地仓库列表并搜索刚上传的
test01
的chart
包
$ helm repo list NAME URL stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts localRegistry http://192.168.31.221:8879/charts [root@node1 helm-dir]# helm search test01 NAME CHART VERSION APP VERSION DESCRIPTION localregistry/test01 0.1.0 1.0 A Helm chart for Kubernetes
管理本地仓库列表
通过 helm
客户端可以对本地仓库列表进行管理,和 Tiller
服务没有任何关系,所有添加的本地仓库列表信息都存储在 /root/.helm/repository
目录中
- 查看本地仓库列表
$ helm repo list NAME URL stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts localRegistry http://192.168.31.221:8879/charts
- 添加一个
Chart
仓库名称为binami
到本地仓库列表中并查看
$ helm repo add binami https://charts.bitnami.com/bitnami "binami" has been added to your repositories $ helm repo list NAME URL stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts localRegistry http://192.168.31.221:8879/charts binami https://charts.bitnami.com/bitnami
- 更新本地仓库列表资源缓存并查找一个
chart
包
$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "localRegistry" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "binami" chart repository Update Complete. $ helm search mysql NAME CHART VERSION APP VERSION DESCRIPTION binami/mysql 6.9.2 8.0.19 Chart to create a Highly available MySQL cluster stable/mysql 0.3.5 Fast, reliable, scalable, and easy to use open-source rel... binami/phpmyadmin 4.3.3 5.0.1 phpMyAdmin is an mysql administration frontend stable/percona 0.3.0 free, fully compatible, enhanced, open source drop-in rep... stable/percona-xtradb-cluster 0.0.2 5.7.19 free, fully compatible, enhanced, open source drop-in rep... binami/mariadb 7.3.12 10.3.22 Fast, reliable, scalable, and easy to use open-source rel... binami/mariadb-cluster 1.0.1 10.2.14 Chart to create a Highly available MariaDB cluster binami/mariadb-galera 0.8.2 10.4.12 MariaDB Galera is a multi-master database cluster solutio... stable/gcloud-sqlproxy 0.2.3 Google Cloud SQL Proxy stable/mariadb 2.1.6 10.1.31 Fast, reliable, scalable, and easy to use open-source rel...
- 从本地仓库列表中删除一个
Chart
仓库名称为binami
$ helm repo remove binami "binami" has been removed from your repositories $ helm repo list NAME URL stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts localRegistry http://192.168.31.221:8879/charts
Chart
包
通过命令 helm create test01
可以创建一个 test01
的 Chart
目录,目录中包含了多个配置文件,如下所示
$ tree test01 test01 ├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _helpers.tpl │ ├── ingress.yaml │ ├── NOTES.txt │ └── service.yaml └── values.yaml
-
生成
Chart
目录中有Chart.yaml
、values.yaml
和NOTES.txt
等文件,下面分别对chart
中几个重要文件解释:-
Chart.yaml
:包含了chart
的metadata
,描述了Chart
名称、描述信息和版本号 -
values.yaml
:存储了模版文件的变量 -
templates
:记录全部模板文件 -
charts
:依赖chart
存储路径 -
NOTES.txt
:给出了部署后的信息,例如如何使用char、列出默认的设置等等
-
-
chart
安装有以下几种方式-
指定chart
:helm install stable/mariadb
-
指定打包的chart
:helm install ./nginx-1.2.3.tgz
-
指定打包目录
:helm install ./nginx
- 指定
chart
包URL
:helm install https://example.com/charts/nginx-1.2.3.tgz
-
Helm
应用部署
创建并部署 Chart
包
- 通过
helm create
命令可以创建一个Chart
包,其中包含了Chart
包的基本文件并且可以用来作为测试用途部署到Kubernetes
集群环境中
$ helm create nginx Creating nginx
- 创建完成后,可以使用命令
helm lint
检查chart
包是否存在问题
$ helm lint nginx ==> Linting nginx [INFO] Chart.yaml: icon is recommended 1 chart(s) linted, no failures
- 检查过后,可以使用命令
helm install
来完成Chart
包的部署,可以通过-n
参数来指定部署的release
名称,如果不指定会随机生成一个。部署过程中会打印出Chart
包的描述信息、资源信息及提示信息
$ helm install -n nginx nginx NAME: nginx LAST DEPLOYED: Fri Mar 27 16:06:20 2020 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE nginx-5bb789b86d-zf7b9 0/1 Pending 0 0s ==> v1/Service NAME AGE nginx 0s ==> v1beta2/Deployment nginx 0s NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -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
信息及Kubernetes
集群中创建的Pod
、Service
及serviceAccount
信息。
$ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE nginx 1 Tue Mar 10 16:14:59 2020 DEPLOYED nginx-0.1.0 1.0 default $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-594bb9f979-5rtkz 1/1 Running 0 3m $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d nginx ClusterIP 10.102.126.72 <none> 80/TCP 3m $ kubectl get sa NAME SECRETS AGE default 1 6d nginx 1 3m
升级、回滚部署的 Release
- 在部署
Chart
包后,如果需要对已部署的Release
进行修改,可以通过命令helm upgrade
来进行升级操作。修改Chart
包内values.yaml
文件内的镜像配置参数后进行升级操作
$ helm upgrade -f nginx/values.yaml --description "set image tag 1.8.0" nginx nginx/ Release "nginx" has been upgraded. Happy Helming! LAST DEPLOYED: Fri Mar 27 16:14:43 2020 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME AGE nginx 8m ==> v1beta2/Deployment nginx 8m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE nginx-5bb789b86d-zf7b9 1/1 Running 0 8m nginx-8486957c66-2xnk5 0/1 ContainerCreating 0 0s NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -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
包目录,升级后查看该Chart
包当前版本号已经滚动并且UPDATED
时间会刷新
$ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE nginx 6 Tue Mar 10 16:33:52 2020 DEPLOYED nginx-0.1.1 2.0 default
- 查看该
Release
的历史记录,可以看到当前版本信息及版本的描述信息
$ helm history nginx REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Mar 27 16:06:20 2020 SUPERSEDED nginx-0.1.0 Install complete 2 Fri Mar 27 16:14:43 2020 DEPLOYED nginx-0.1.0 set image tag 1.8.0
- 如果在升级后发现当前版本有问题,需要马上回滚到上一个版本,此时可以通过命令
helm rollback
来回滚到指定的版本
$ helm rollback nginx 1 Rollback was a success! Happy Helming!
- 此时再次查看
Release
的历史记录,可以看到当前版本是回退到版本1
的位置
$ helm history nginx REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Mar 27 16:06:20 2020 SUPERSEDED nginx-0.1.0 Install complete 2 Fri Mar 27 16:14:43 2020 SUPERSEDED nginx-0.1.0 set image tag 1.8.0 3 Fri Mar 27 16:18:11 2020 DEPLOYED nginx-0.1.0 Rollback to 1
删除、恢复部署的 Release
- 当不再需要部署的
Release
时,可以通过helm delete
命令来删除部署的Release
。当Release
被删除后,Kubernetes
集群中部署的Pod
也会被清空
$ helm delete nginx release "nginx" deleted
- 虽然此时已经在
Kubernetes
集群中看不到部署的Pod
,但是Helm
中并没有真正删除该Release
。可以通过命令helm list -a
查看已经被删除的Release
$ helm list -a NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE nginx 8 Tue Mar 10 16:41:09 2020 DELETED nginx-0.1.1 2.0 default
- 即使删除了
Release
,其发布的历史信息还是会继续被保存
$ helm history nginx REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Mar 27 16:06:20 2020 SUPERSEDED nginx-0.1.0 Install complete 2 Fri Mar 27 16:14:43 2020 SUPERSEDED nginx-0.1.0 set image tag 1.8.0 3 Fri Mar 27 16:18:11 2020 DELETED nginx-0.1.0 Deletion complete
- 如果此时想恢复一个被删除的
Release
,可以通过helm rollback
命令来恢复
$ helm rollback nginx 2 Rollback was a success.
- 此时通过命令
helm list
查看部署的Release
时,发现被删除的Release已经恢复并且正常显示
helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE nginx 2 Tue Mar 10 17:06:00 2020 DEPLOYED nginx-0.1.0 1.0 default
- 如果想彻底删除一个
release
,可以添加参数--purge
来执行
$ helm delete nginx --purge release "nginx" deleted
依赖关系
在 Helm
中,一个 chart
可能依赖于任何数量的其他 chart
。这些依赖关系可以通过 requirements.yaml
文件动态链接或引入 charts/
目录并手动管理
用 requirements.yaml
来管理依赖关系
-
requirements.yaml
文件是列出chart
的依赖关系的简单文件
dependencies: - name: mysql version: 0.3.5 repository: https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
-
name
字段是chart
的名称 -
version
字段是chart
的版本 -
repository
字段是chart repo
的完整URL
。请注意,还必须使用helm repo add
添加该repo
到本地才能使用
- 有了依赖关系文件,你可以通过运行
helm dependency update
,它会使用你的依赖关系文件将所有指定的chart
下载到你的charts/
目录中
$ helm dependency update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "aliyun" chart repository ...Successfully got an update from the "binami" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. Saving 1 charts Downloading mysql from repo https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts Deleting outdated charts
- 当
helm dependency update
检索chart
时,它会将它们作为chart
存档存储在charts/
目录中。因此,对于上面的示例,可以在chart
目录中看到以下文件
$ ls charts/ mysql-0.3.5.tgz
通过 requirements.yaml
管理 chart
是一种轻松更新 chart
的好方法,还可以在整个团队中共享 requirements
信息。
除上述其他字段外,每个需求条目可能包含可选字段 tags
和 condition
。所有 charts
都会默认加载,如果存在 tags
或 condition
字段,将对它们进行评估并用于控制应用的 chart
的加载。
-
tags
和conditions
功能介绍 -
Conditions
(设置values
) 会覆盖tags
配置。第一个存在的condition
路径生效,后续该chart
的condition
路径将被忽略 - 如果
chart
的某tag
的任一tag
的值为true
,那么该tag
的值为true
,并启用这个chart
-
Tags
和conditions
值必须在顶级父级的值中进行设置 -
tags
:值中的关键字必须是顶级关键字。目前不支持全局和嵌套tags
:表格
-
Condition
:字段包含一个或多个YAML
路径(用逗号分隔)。如果此路径存在于顶级父级的值中并且解析为布尔值,则将根据该布尔值启用或禁用chart
。只有在列表中找到的第一个有效路径才被评估,如果没有路径存在,那么该条件不起作用. -
Tags
:标签字段是与此chart
关联的YAML
标签列表。在顶级父级的值中,可以通过指定标签和布尔值来启用或禁用所有带有标签的chart
# parentchart/requirements.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled, global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true
在上面的示例中,所有带有标签的 front-end
的 charts
都将被禁用,但由于 subchart1.enabled
的值在父项值中为“真”,因此条件将覆盖该 front-end标签,subchart1会启用。由于subchart2被标记back-end和标签的计算结果为true,subchart2将被启用。还要注意的是,虽然subchart2有一个在requirements.yaml中指定的条件,但父项的值中没有对应的路径和值,因此条件无效
使用命令行时带有 tag
和 conditions
, --set
参数可使用来更改 tag
和 conditions
值
$ helm install --set tags.front-end=true --set subchart2.enabled=false
通过 charts
目录手动管理依赖性
- 如果需要更多的控制依赖关系,可以通过将依赖的
charts
复制到charts
目录中来明确表达这些依赖关系 。依赖关系可以是chart
归档(.tgz
)或解压缩的chart
目录。但它的名字不能从_
或.
开始,这些文件被chart
加载器忽略 - 如果
WordPress chart
依赖于Apache chart
和MySQL chart
,则在WordPress chart
的charts
目录中提供Apache chart
和MySQL chart
,即表示相互的依赖关系。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Effective STL中文版
[美] Scott Meyers / 潘爱民、陈铭、邹开红 / 电子工业出版社 / 2013-5 / 59.00元
《Effective STL中文版:50条有效使用STL的经验》是EffectiveC++的第3卷,被评为“值得所有C++程序员阅读的C++书籍之一”。《Effective STL中文版:50条有效使用STL的经验》详细讲述了使用STL的50条指导原则,并提供了透彻的分析和深刻的实例,实用性极强,是C++程序员必备的基础书籍。C++的标准模板库(STL)是革命性的,要用好STL并不容易。《Effe......一起来看看 《Effective STL中文版》 这本书的介绍吧!