Helm-v3应用包管理器
3.1 为什么需要Helm？
K8S上的应用对象，都是由特定的资源描述组成，包括deployment、service等。都保存各自文件中或者集中写到一个配置文件。然后kubectl apply –f 部署。
为什么使用helm？
在k8s中，当我们去部署应用的时候，一般都是使用yaml文件去管理我们的应用的发布，比如像微服务，其中包括deployment,service,configmap,ingress，但是如果我们有上百个微服务的话，每次的修改涉及也都会比较多，感觉就是不太灵活了，再去管理可能就觉得力不从心了，这只是一个问题，其实k8s缺少一个更高级的应用级别的管理，如果我们将这些yaml文件放在一个地方，基于一个应用层面的管理，那可能会更好了。
使用这些yaml文件面临着一个什么样的问题？
且由于缺少对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，主要面临以下问题：
如何将这些服务作为一个整体管理，其实我们每次部署也针对这些yaml,然后apply 一下，然后也缺乏了怎么统一的管理
这些资源文件如何高效复用，其实我们在部署的时候，模版的很多的类型都是一样的，我们怎么去使用一套模版来发布多个应用呢，发布的时候只需要简单修改一下
不支持应用级别的版本管理，那么这里有很多的yaml，怎么可能可以去管理应用级别的呢，为了解决这个问题,helm也就应运而生了。
3.2 Helm 介绍
Helm是一个Kubernetes的包管理工具，就像Linux下的包管理器，如yum/apt等，可以很方便的将之前打包好的yaml文件部署到kubernetes上。
比如像yum ,它主要解决一个依赖的问题，安装yum的可能会有很多的yum去执行，这个helm就相当于一个yum的包管理器，它将直接按应用去安装，这个helm也一样。
Helm有三个重要概念：
helm：一个命令行客户端工具，主要用于Kubernetes应用chart的创建、打包、发布和管理。
Chart：应用描述，一系列用于描述 k8s 资源相关文件的集合。
Release：基于Chart的部署实体，一个 chart 被 Helm 运行后将会生成对应的一个 release；将在k8s中创建出真实运行的资源对象。
3.3 Helm v3 变化
2019年11月13日， Helm团队发布 Helm v3的第一个稳定版本。
该版本主要变化如下：
1、 架构变化
最明显的变化是，简单了很多，第一个变化就是，也是最明显的，它把tiller之前作为一个pod集群中部署的它作为一个服务端存在的，它主要接收helm客户端发来的请求，发给API里面,然后api去转发，tiller还得需要单独部署，并且还要授权，它能操作集群的哪些命名空间，拥有哪些权限给删除了。
kubeconfig连接集群的配置文件直接连接apiserver,之前呢是直接连接的API，由它做一个转发，现在呢直接使用kubeconfig,kubectl都是使用kubeconfig来连接集群的，所以helm直接连接kubeconfig,再连接apiserver,然后部署chart的包，那简化了很多，然后v2版本部署一个Helm，还需要tiller还能正常的工作，现在v3版本就不需要了，只需要下载一个helm的客户端工具就可以了，首先这个部署已经简化了很多，是更合理的，之前的权限管理也是很麻烦的，也是需要tiller去做权限管理，所以这个授权也是比较麻烦，感觉加这个tiller也是多余的东西，也是当时设计的原因，附加了这么一个tiller,这个也是一个可有可无的东西，有了kubeconfig,就可以直接通过原生的kubeconfig去完成了，所以也没必要搞一个组件单独去做这件事，比如授权，连接API，有一部分可以再helm的客户端去实现了，那这么一来的话用helm就很简单了，这也就是社区一个认识的转变，真正的让helm作为一个好用的工具存在。
2、Release名称可以在不同命名空间重用，之前这个都是tiller去维护的，比如部署一个web产生一个发行版，这个发行版这个名称，不能跨命名空间去使用，只能用一个名字，比如default使用了一个web的名称，在kube-system的命名空间下就不能用，主要是全局管理，在一个命名空间下存储这个信息的，所以说是每个命名空间下维护的信息，这个命名空间里面不要重复。
3、支持将 Chart 推送至 Docker 镜像仓库中 ，也就是chart可以推送到harbor仓库上了，之前是有专门的存储工具，也就是这个支持，可以只用一个仓库来存储多个类型，比如通过harbor放我们的镜像还能存放我们的chart的包管理工具
4、使用JSONSchema验证chart values ，主要去验证你使用values这个格式的变量的文件
5、其他
1）为了更好地协调其他包管理者的措辞 Helm CLI个别更名
helm delete更名为helm uninstall
helm inspect更名为helm show
helm fetch更名为helm pull
但以上旧的命令当前仍能使用。
2）移除了用于本地临时搭建 Chart Repository的 helm serve 命令。
3）自动创建名称空间
在不存在的命名空间中创建发行版时，Helm 2创建了命名空间。Helm 3遵循其他Kubernetes对象的行为，如果命名空间不存在则返回错误。
4） 不再需要requirements.yaml, 依赖关系是直接在chart.yaml中定义。
基本上就是v3版本的helm就是代码基本上算是重构了
3.4 Helm客户端
1、部署Helm客户端
Helm客户端下载地址：https://github.com/helm/helm/releases
解压移动到/usr/bin/目录即可。
wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
tar zxvf helm-v3.0.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/bin/
2、Helm常用命令
3、配置国内Chart仓库
准备好客户端工具之后，就要配置一下这个Chart的仓库,chart就是一个应用的包
微软仓库（http://mirror.azure.cn/kubernetes/charts/）这个仓库推荐使用，基本上官网有的chart这里都有。
阿里云仓库（https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts ）
官方仓库（https://hub.kubeapps.com/charts/incubator）官方chart仓库，国内有点不好使。
添加存储库：
helm repo add azure http://mirror.azure.cn/kubernetes/charts
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo update 更新查看配置的存储库：
这里也可以添加多个仓库，比如阿里云，微软的，都可以通过search会帮你列出来你仓库所有的
[[email protected] ~]# helm repo list
NAME URL
stable http://mirror.azure.cn/kubernetes/charts
[[email protected] ~]# helm search repo mysql删除存储库：helm repo remove aliyun
3.5 Helm基本使用
主要介绍三个命令：
chart install 安装
chart update 升级
chart rollback 回滚1、使用chart部署一个应用
查找chart：
helm search repo
helm search repo mysql为什么mariadb也在列表中？因为他和mysql有关。
查看chart信息：helm show chart azure/mysql
安装包：db-1指定包的名称（自定义）
[[email protected] ~]# helm install db-1 azure/mysql
NAME: db-1
LAST DEPLOYED: Tue Dec 17 10:24:07 2019
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:查看发布状态：
helm status db-1
列出release
[[email protected] ~]# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
db-1 default 1 2019-12-17 10:24:07.593783822 +0800 CST deployed mysql-1.6.2 5.7.28 查看pod的部署状态
[[email protected] ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 0/1 Pending 0 3m47s查看事件，这里出现pending，检测pod无法运行的原因，查看原因这里的pvc无法绑定，说明没有pv
[[email protected] ~]# kubectl describe pod db-1-mysql-765759d7d8-n65x6
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling <unknown> default-scheduler pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
Warning FailedScheduling <unknown> default-scheduler pod has unbound immediate PersistentVolumeClaims (repeated 3 times)查看pvc,这里是没有绑定成功，说明一直没有找到合适的pv来绑定，只要帮它匹配上就能运行成功
[[email protected] ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
db-1-mysql Pending 7m54s我们给它去创建一个pv，来让它自动去绑定，这里我还是用的nfs做的网络存储，创建好之后，查看pvc，会显示绑定成功，查看pod的状态
[[email protected] ~]# cat pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 8Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt/k8s/db
server: 10.4.7.200
[[email protected] ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 1/1 Running 0 24m通过helm list查看部署的应用
[[email protected] ~]# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
db-1 default 1 2019-12-17 10:24:07.593783822 +0800 CST deployemysql-1.6.2 5.7.28 查看详细信息，这里面会告诉你怎么连接mysql [[email protected] ~]# helm status db-1
这里说生成一个随机的密码，将里面的值拿出来进行生成
To get your root password run:
MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default db-1-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)这里说通过这个命令去连接数据库
Connect using the mysql cli, then provide your password:
$ mysql -h db-1-mysql -p先进入这个容器里面，然后将它告诉的我们去连接一下，测试并创建一个数据库
[[email protected] ~]# kubectl exec -it db-1-mysql-765759d7d8-n65x6 /bin/bash
[email protected]:/# mysql -h db-1-mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 73
Server version: 5.7.28 MySQL Community Server (GPL)
mysql> create database db;
Query OK, 1 row affected (0.07 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| db |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.02 sec)现在还有个问题，本身就有这个NFS自动供给，现在我想用自己的pv自动供给怎么去实现？
所以就要去修改chart的配置选项了，因为有的需要一些依赖，比如刚才的mysql有个pv的依赖，因为它不知道我们使用的存储类是哪个，说白了就是安装chart之前自定义配置选项，有两种方法，第一种就是直接使用--values这个yaml去覆盖它，刚才我们使用的helm show values azure/mysql,这个chart的中的values的yaml
我们先将刚才那个values下的文件重定向一个文件中
[[email protected] ~]# helm show values azure/mysql > volues.yaml
[[email protected] ~]# cat volues.yaml
mysqlRootPassword: testing
mysqlUser: k8s
mysqlPassword: k8s123
mysqlDatabase: k8s
persistence:
enabled: true
storageClass: "managed-nfs-storage"
accessMode: ReadWriteOnce
size: 8Gi这个存储类之前我是创建好的，这里不做演示，在values-yaml中去指定我们的存储类
[[email protected] ~]# kubectl get storageclass
NAME PROVISIONER AGE
managed-nfs-storage fuseim.pri/ifs 3d23h我们再创建一个数据库根据我们的values现在可以直接绑定我们的存储类，直接创建pod了
[[email protected] ~]# helm install db-2 -f volues.yaml azure/mysql
[[email protected] ~]# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
db-1 default 1 2019-12-17 10:24:07.593783822 +0800 CST deployed mysql-1.6.2 5.7.28
db-2 default 1 2019-12-17 11:37:31.852808375 +0800 CST deployed mysql-1.6.2 5.7.28
[[email protected] ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv0003 8Gi RWO Retain Bound default/db-1-mysql 52m
pvc-0baaf69a-0a3b-4d05-adb5-515057bda753 8Gi RWO Delete Bound default/db-2-mysql managed-nfs-storage 18s
pvc-16725fa9-3fe5-4e87-a2f8-f3f1e7df56b3 16Gi RWO Delete Bound kube-system/prometheus-data-prometheus-0 managed-nfs-storage 3d23h
pvc-30244364-8bcd-43af-b1a9-d36e044c83c4 1Gi RWO Delete Bound kube-system/grafana-data-grafana-0 managed-nfs-storage 3d23h
[[email protected] ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 1/1 Running 0 74m
db-2-mysql-69dc64b75f-b2cxb 1/1 Running 0 59s现在测试一下我们的数据库，我们的密码也是在values去中定义的，所以直接登录，并可以查看到我们创建的数据库
[email protected]:/# echo ${MYSQL_ROOT_PASSWORD}
testing
[email protected]:/# mysql -uroot -p${MYSQL_ROOT_PASSWORD}
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 52
Server version: 5.7.28 MySQL Community Server (GPL)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| k8s |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.06 sec)查看用户，已经创建k8s用户
mysql> select user from mysql.user;
+---------------+
| user |
+---------------+
| k8s |
| root |
| mysql.session |
| mysql.sys |
| root |
+---------------+
5 rows in set (0.04 sec)2、安装前自定义chart配置选项
如果想对官方的chart进行使用就直接使用install了，有些必须依赖的也是提前去准备的，比如刚才的pv
有两种方式，保留一些修改的文件，然后引用这些配置文件，或者使用--set，在命令行进行替换变量
配置文件写的也都可以在命令行去使用，然后也都运行了。
--values（或-f）：指定带有覆盖的YAML文件。这可以多次指定，最右边的文件优先
--set：在命令行上指定替代。如果两者都用，--set优先级高
[[email protected] ~]# helm install db-3 --set persistence.storageClass="managed-nfs-storage" azure/mysql
[[email protected] ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
db-1-mysql Bound pv0003 8Gi RWO 4h13m
db-2-mysql Bound pvc-0baaf69a-0a3b-4d05-adb5-515057bda753 8Gi RWO managed-nfs-storage 3h
db-3-mysql Bound pvc-2bf895a8-075b-43d9-ade9-fe9b7ae67b1b 8Gi RWO managed-nfs-storage
[[email protected] ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 1/1 Running 0 4h13m
db-2-mysql-69dc64b75f-b2cxb 1/1 Running 0 179m
db-3-mysql-679888dd7b-9m5cm 1/1 Running 0 85s或者你想关心这个官方的chart是怎么写的，你可以直接pull下来，查看详细信息[[email protected] ~]# helm pull azure/mysql --untar
这个拉下来是一个压缩包，也可以拉的时候直接解压， --untar
这里面values.yaml，刚才我们重定向出来的就是这个yaml，其他的保持不变，在templates下就是部署mysql的所需的yaml,这样你会发现部署一个chart的简单了很多，而且我还可以快速的启动多套，部署多个这样的pod，来动态的传入参数，还能分生产环境，测试环境，只要你在values下面定义不同的命名空间，区分不同的生产环境和测试环境。
[[email protected] ~]# cd mysql
[[email protected] mysql]# ls
Chart.yaml README.md templates values.yaml而且该helm install命令可以从多个来源安装：
chart存储库
本地chart存档（helm install foo-0.1.1.tgz）或者在它官方刚才我们拉的mysql那个包，直接用helm install mysql-1.5.0.gz
chart目录（helm install path/to/foo）
完整的URL（helm install https://example.com/charts/foo-1.2.3.tgz）或者你一个url的地址3、构建一个Helm Chart
一个chart是怎么组成的 create + 自定义名称（目录结构）
[[email protected] test-helm]# helm create chart
Creating chart
[[email protected] test-helm]# ls
chart
[[email protected] test-helm]# cd chart/
[[email protected] chart]# ls
charts Chart.yaml templates values.yaml启动刚才我们的chart,并且起一下pod自定义名称 helm install 名称 刚才的配置目录下
[[email protected] test-helm]# helm install my-chart chart/
NAME: my-chart
LAST DEPLOYED: Tue Dec 17 15:09:10 2019
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=chart,app.kubernetes.io/instance=my-chart" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl --namespace default port-forward $POD_NAME 8080:80来看一下我们这个启动的pod是一个什么服务，这个默认的就是官方的一个模版，在values下面可以看出它获取的image是nginx
[[email protected] test-helm]# kubectl get pod -o wide
my-chart-94997cb67-c2zxx 1/1 Running 0 10m 10.244.0.43 k8s-node2 <none> <none>
[[email protected] chart]# curl -I 10.244.0.43
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Tue, 17 Dec 2019 07:22:57 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Apr 2019 10:18:21 GMT
Connection: keep-alive
ETag: "5cbee66d-264"
Accept-Ranges: bytes
[[email protected] chart]# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
db-1 default 1 2019-12-17 10:24:07.593783822 +0800 CST deployed mysql-1.6.2 5.7.28
db-2 default 1 2019-12-17 11:37:31.852808375 +0800 CST deployed mysql-1.6.2 5.7.28
db-3 default 1 2019-12-17 14:36:00.445305589 +0800 CST deployed mysql-1.6.2 5.7.28
my-chart default 1 2019-12-17 15:09:10.164272986 +0800 CST deployed chart-0.1.0 1.16.0 看一下这个文件的目录结构
[[email protected] test-helm]# tree .
.
└── chart
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
4 directories, 9 filesChart.yaml：用于描述这个 Chart的基本信息，包括名字、描述信息以及版本等。
values.yaml ：用于存储 templates 目录中模板文件中用到变量的值。
Templates： 目录里面存放所有yaml模板文件。
charts：目录里存放这个chart依赖的所有子chart。
NOTES.txt ：用于介绍Chart帮助信息， helm install 部署后展示给用户。例如：如何使用这个 Chart、列出缺省的设置等。
_helpers.tpl：放置模板助手的地方，可以在整个 chart 中重复使用
现在我们自己制作一个chart的模版，发布简单的微服务类型的发布
[[email protected] chart]# tree .
.
├── charts
├── Chart.yaml
├── templates
└── values.yaml创建一个新的deployment类型的pod,镜像为nginx
[[email protected] templates]# kubectl create deployment app-1 --image=nginx -o yaml --dry-run > deployment.yaml
[[email protected] templates]# ls
deployment.yaml将yaml中一些不需要使用的字段空值进行删除
我们修改一下这个yaml，先简单的去使用values的变量赋值的渲染，然后发布两个微服务，使用nginx的镜像做一个小实例，后续将一个完整的微服务（dubbo,spring cloud的应用进行发布）
[[email protected] chart]# cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: {{ .Values.name }}
name: {{ .Values.name }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.name }}
template:
metadata:
labels:
app: {{ .Values.name }}
spec:
containers:
- image: {{ .Values.image }}:{{ .Values.imageTag }}
name: {{ .Values.image }}当我们去发布一个微服务的时候，它会去调用我们上层values的模版的变量进行对我们发布应用的yaml进行渲染，helm的好处就在这里，在k8s原生的yaml中去发布一个服务,yaml本身的格式不支持变量的注入，所以helm也就应运而生了，主要就是解决这个问题，而且我们去发布多个任务直接通过这个模版将一些变动的值都写进去，发布任务也会很快，节省我们的时间。
[[email protected] chart]# cat .//values.yaml
name: base-user-devops
image: nginx
imageTag: 1.15
replicas: 2
[[email protected] ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
base-user-common-58b7bc9c56-2nmcb 1/1 Running 0 12m
base-user-common-58b7bc9c56-2tgpg 1/1 Running 0 12m
base-user-devops-7cf5c99485-rr295 1/1 Running 0 10m
base-user-devops-7cf5c99485-s2jbb 1/1 Running 0 10m
[[email protected] test-helm]# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
base-user-common default 1 2019-12-17 16:29:01.587768045 +0800 CST deployed chart-0.1.0 1.16.0
base-user-devops default 1 2019-12-17 16:27:11.757082258 +0800 CST deployed chart-0.1.0 1
查看我们渲染之后的效果是什么样的，我们的变量已经赋值到我们的yaml中，然后帮我们将pod启动起来
[[email protected] test-helm]# helm get manifest base-user-common
---
Source: chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: base-user-common
name: base-user-common
spec:
replicas: 2
selector:
matchLabels:
app: base-user-common
template:
metadata:
labels:
app: base-user-common
spec:
containers:
- image: nginx:1.16
name: nginx4、升级、回滚和删除
发布新版本的chart时，或者当您要更改发布的配置时，可以使用该helm upgrade 命令
比如将我们的base-user-common这个服务的镜像换成其他的镜像，因为我们的微服务其实在发布的过程中，由于开发的代码的修改都会进行重新的构建，通过dockerfile，那么其实这里的道理也是一样的，当我们去发布一个新的服务就需要去替换我们旧代码的镜像，这里其实旧可以去指定为我们新的镜像。[[email protected] test-helm]# vim chart/values.yaml
进行对镜像修改为1.15,然后进行更新，使用upgrade指定我们微服务的名称这个名称根据项目去定义，微服务本身就是一个拆分的一个机构的组成的分子，这个就按自己去定义，然后指定这个chart模版目录
[[email protected] test-helm]# helm upgrade base-user-common chart/
Release "base-user-common" has been upgraded. Happy Helming!
NAME: base-user-common
LAST DEPLOYED: Tue Dec 17 16:47:55 2019
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None测试查看已经将镜像成功替换为1.15版本
[[email protected] test-helm]# curl -I 10.244.2.24
HTTP/1.1 200 OK
Server: nginx/1.15.12
Date: Tue, 17 Dec 2019 08:48:34 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Apr 2019 13:08:19 GMT
Connection: keep-alive
ETag: "5cb5d3c3-264"
Accept-Ranges: bytes例如将应用回滚到第一个版本，现在又回到1.16这个镜像了
[[email protected] ~]# helm rollback base-user-common
Rollback was a success! Happy Helming!
[[email protected] ~]# curl -I 10.244.1.20
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Tue, 17 Dec 2019 09:44:44 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 13 Aug 2019 10:05:00 GMT
Connection: keep-alive
ETag: "5d528b4c-264"
Accept-Ranges: bytes也可以查看历史的版本
[[email protected] chart]# helm history base-user-common
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Tue Dec 17 16:29:01 2019 superseded chart-0.1.0 1.16.0 Install complete
2 Tue Dec 17 16:47:55 2019 superseded chart-0.1.0 1.16.0 Upgrade complete
3 Tue Dec 17 17:43:23 2019 deployed chart-0.1.0 1.16.0 Rollback to 1 也可以打包推送的charts仓库共享别人使用[[email protected] test-helm]# helm package chart
卸载发行版使用helm uninstall或者helm delete,这样的话也会将pod也会删除
[[email protected] test-helm]# helm uninstall base-user-common
release "base-user-common" uninstalled原文地址：https://blog.51cto.com/14143894/2459403