Helm-v3 application package manager
3.1 Why the need Helm?
K8S the application object, is described by a specific resource, including deployment, service and the like. Each file are saved or written to a centralized configuration file. Then kubectl apply -f deployment.
Why helm?
In k8s, when we went to deploy applications are generally used to manage file yaml our publishing applications, such as micro-services, including deployment, service, configmap, ingress, but if we have hundreds of micro-services then, that each modification will also involve more, feeling is not very flexible, management may feel powerless again, this is just a question, in fact, k8s lack of a more advanced application-level management, if we refer to these yaml files in one place, based on an application-level management, it might be better.
Using these files yaml faced with what kind of problem?
And due to the lack of application version management and control over the release of the application on the Kubernetes maintenance and updating face many challenges, mainly face the following problems:
how to manage these services as a whole, in fact, every time we deploy also for those yaml and then apply it, and how the lack of unified management of
the resource files how to efficiently reuse, in fact, when we deployed, many types of templates are the same, how we use a set of templates to publish to multiple applications then, when released simply modify
does not support application-level version management, so there are a lot of yaml, how to manage the application level may be able to do, in order to solve this problem, helm also came into being.
Introduction 3.2 Helm
Helm is a Kubernetes package management tools, like the package manager under Linux, such as yum / apt, etc., can easily be packaged yaml file deployed to kubernetes before.
Such as yum, it relies mainly to solve a problem, there may be a yum install yum to perform a lot of, this is equivalent to helm a yum package manager to install it directly on the application, the helm is the same.
There are three important concepts Helm:
Helm: a command-line client tool, mainly used to create the chart Kubernetes applications, packaging, distribution and management.
Chart: Application description used to describe a series of collection k8s resource-related documents.
Release: based deployment entity Chart, the chart is a run will generate a corresponding release Helm; creates a resource object in the real running k8s.
Helm v3 change 3.3
2019 Nian 11 Yue 13 Ri, Helm team released the first stable version of Helm v3.
This version of the main changes are as follows:
1, the architecture changes
the most obvious change is a lot simpler, first change is also the most obvious, it put it there as a server, it mainly receives a pod cluster deployed before the tiller as the helm client sent the request, issue to the API inside, then go forward api, tiller had to be deployed separately, and also authorization, which it can operate namespace cluster, which has the authority to delete.
kubeconfig connection to the cluster configuration file directly connected apiserver, before it is connected directly to the API, it is made by a forward, it is now used directly kubeconfig, kubectl kubeconfig are using to connect to the cluster, so the helm direct connection kubeconfig, then connect apiserver, then deploy chart package that simplifies a lot, and then deploy a version v2 Helm, but also need to work properly tiller, now v3 version is not required, just need to download a client helm of the tool can be, first of all this deployment has been simplified a lot, is more reasonable, prior rights management is very troublesome, but also need to do tiller rights management, so this authorization is too much trouble, feel this tiller also add extra things, was also the reason for the design, additional so a tiller, this is a non-essential things, with kubeconfig, you can directly through the native kubeconfig to complete, so there is no need to engage a component to do it alone, such as authorization API connection there may be another part of the helm of the client to realize, that this As a word with helm is very simple, which is the transformation of the community an understanding of the real let helm as a useful tool exists.
2, Release name can be reused in different namespaces, before this is a tiller to maintain, such as deploying a web produces a release, the release of this name, can not cross the namespace to use, with only a name, such as default use a web name can not be used in the namespace kube-system, mainly global management, store this information in a namespace, so that the maintenance of information under each namespace, this namespace inside Do not repeat.
3, the support push Chart Docker image repository, i.e. chart can be pushed onto the harbor warehouse, until there is a dedicated storage means, i.e. the support, only one repository to store a plurality of types, such as by harbor we can put a mirror image of our chart storage package management tool
4, JSONSchema verification chart values, mainly to verify the files you use the values of this variable format
5. other
1) in order to better coordinate with other package managers wording Helm CLI individual renamed
Helm the Delete 更名为Helm Uninstall
Helm the Inspect 更名为Helm Show
Helm FETCH 更名为Helm pull
but still more than the old command current use.
2) remove the helm serve for the local command of the makeshift Chart Repository.
3) automatically creates a name space
when you create a release that does not exist in the namespace in, Helm 2 creates a namespace. Helm 3 Kubernetes follow the behavior of other objects, if the namespace does not exist, an error is returned.
4) no longer required requirements.yaml, dependency is defined directly in the chart.yaml.
Basically v3 version of the helm is the code basically be reconstructed
3.4 Helm client
1, client deployment Helm
Helm Client Download: https://github.com/helm/helm/releases
unzip to move to the / usr / bin / directory.
wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
the tar-V3.0.0 zxvf Helm-Linux-amd64.tar.gz
Music Videos-Linux AMD64 / Helm / usr / bin /
2, Helm commonly used commands 
3, configuration Chart domestic warehouse
're ready client tools necessary to configure the look of the Chart warehouse, chart is an application package
Microsoft warehouse ( http://mirror.azure.cn/kubernetes/charts/ ) this warehouse is recommended, basically the official website has some chart here .
Ali cloud warehouse ( https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts )
official repository ( https://hub.kubeapps.com/charts/incubator) official chart warehouse, a little country to do so .
Add repository:
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会帮你列出来你仓库所有的
[root@k8s-master1 ~]# helm repo list
NAME URL
stable http://mirror.azure.cn/kubernetes/charts
[root@k8s-master1 ~]# 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指定包的名称（自定义）
[root@k8s-master1 ~]# 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
[root@k8s-master1 ~]# 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的部署状态
[root@k8s-master1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 0/1 Pending 0 3m47s查看事件，这里出现pending，检测pod无法运行的原因，查看原因这里的pvc无法绑定，说明没有pv
[root@k8s-master1 ~]# 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来绑定，只要帮它匹配上就能运行成功
[root@k8s-master1 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
db-1-mysql Pending 7m54s我们给它去创建一个pv，来让它自动去绑定，这里我还是用的nfs做的网络存储，创建好之后，查看pvc，会显示绑定成功，查看pod的状态
[root@k8s-master1 ~]# 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
[root@k8s-master1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
db-1-mysql-765759d7d8-n65x6 1/1 Running 0 24m通过helm list查看部署的应用
[root@k8s-master1 ~]# 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 [root@k8s-master1 ~]# 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先进入这个容器里面，然后将它告诉的我们去连接一下，测试并创建一个数据库
[root@k8s-master1 ~]# kubectl exec -it db-1-mysql-765759d7d8-n65x6 /bin/bash
root@db-1-mysql-765759d7d8-n65x6:/# 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下的文件重定向一个文件中
[root@k8s-master1 ~]# helm show values azure/mysql > volues.yaml
[root@k8s-master1 ~]# cat volues.yaml
mysqlRootPassword: testing
mysqlUser: k8s
mysqlPassword: k8s123
mysqlDatabase: k8s
persistence:
enabled: true
storageClass: "managed-nfs-storage"
accessMode: ReadWriteOnce
size: 8Gi这个存储类之前我是创建好的，这里不做演示，在values-yaml中去指定我们的存储类
[root@k8s-master1 ~]# kubectl get storageclass
NAME PROVISIONER AGE
managed-nfs-storage fuseim.pri/ifs 3d23h我们再创建一个数据库根据我们的values现在可以直接绑定我们的存储类，直接创建pod了
[root@k8s-master1 ~]# helm install db-2 -f volues.yaml azure/mysql
[root@k8s-master1 ~]# 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
[root@k8s-master1 ~]# 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
[root@k8s-master1 ~]# 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去中定义的，所以直接登录，并可以查看到我们创建的数据库
root@db-2-mysql-69dc64b75f-b2cxb:/# echo ${MYSQL_ROOT_PASSWORD}
testing
root@db-2-mysql-69dc64b75f-b2cxb:/# 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优先级高
[root@k8s-master1 ~]# helm install db-3 --set persistence.storageClass="managed-nfs-storage" azure/mysql
[root@k8s-master1 ~]# 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
[root@k8s-master1 ~]# 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下来，查看详细信息[root@k8s-master1 ~]# helm pull azure/mysql --untar
这个拉下来是一个压缩包，也可以拉的时候直接解压， --untar
这里面values.yaml，刚才我们重定向出来的就是这个yaml，其他的保持不变，在templates下就是部署mysql的所需的yaml,这样你会发现部署一个chart的简单了很多，而且我还可以快速的启动多套，部署多个这样的pod，来动态的传入参数，还能分生产环境，测试环境，只要你在values下面定义不同的命名空间，区分不同的生产环境和测试环境。
[root@k8s-master1 ~]# cd mysql
[root@k8s-master1 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 + 自定义名称（目录结构）
[root@k8s-master1 test-helm]# helm create chart
Creating chart
[root@k8s-master1 test-helm]# ls
chart
[root@k8s-master1 test-helm]# cd chart/
[root@k8s-master1 chart]# ls
charts Chart.yaml templates values.yaml启动刚才我们的chart,并且起一下pod自定义名称 helm install 名称 刚才的配置目录下
[root@k8s-master1 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
[root@k8s-master1 test-helm]# kubectl get pod -o wide
my-chart-94997cb67-c2zxx 1/1 Running 0 10m 10.244.0.43 k8s-node2 <none> <none>
[root@k8s-master1 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
[root@k8s-master1 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 看一下这个文件的目录结构
[root@k8s-master1 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的模版，发布简单的微服务类型的发布
[root@k8s-master1 chart]# tree .
.
├── charts
├── Chart.yaml
├── templates
└── values.yaml创建一个新的deployment类型的pod,镜像为nginx
[root@k8s-master1 templates]# kubectl create deployment app-1 --image=nginx -o yaml --dry-run > deployment.yaml
[root@k8s-master1 templates]# ls
deployment.yaml将yaml中一些不需要使用的字段空值进行删除
我们修改一下这个yaml，先简单的去使用values的变量赋值的渲染，然后发布两个微服务，使用nginx的镜像做一个小实例，后续将一个完整的微服务（dubbo,spring cloud的应用进行发布）
[root@k8s-master1 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也就应运而生了，主要就是解决这个问题，而且我们去发布多个任务直接通过这个模版将一些变动的值都写进去，发布任务也会很快，节省我们的时间。
[root@k8s-master1 chart]# cat .//values.yaml
name: base-user-devops
image: nginx
imageTag: 1.15
replicas: 2
[root@k8s-master1 ~]# 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
[root@k8s-master1 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启动起来
[root@k8s-master1 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, upgrade, rollback, and delete
when a new version of the chart, or when you want to change the configuration of the release, you can use the helm upgrade command
For example, the image of our base-user-common this service into a mirror image of the other, because in fact in the process of release, due to the development of the code changes will be re-building of our micro-services, by dockerfile, so in fact here the same is true when we go to publish a new service mirrors our need to replace the old code, where in fact the old can go to our designated as a new image. [root@k8s-master1 test-helm]# vim chart/values.yaml
Be mirrored revised to 1.15, and then update, upgrade using this name to specify the name of our services to micro defined in terms of projects, micro service itself is a molecule composed of a body of a split, this would by themselves to define and specify this chart template directory
[root@k8s-master1 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: NoneView mirror test has been successfully replaced with version 1.15
[root@k8s-master1 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: bytesFor example, the application is rolled back to the first version, now back to 1.16 this mirrored
[root@k8s-master1 ~]# helm rollback base-user-common
Rollback was a success! Happy Helming!
[root@k8s-master1 ~]# 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: bytesYou can also view the version history
[root@k8s-master1 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 The charts can also be packaged push others to use shared warehouse [root@k8s-master1 test-helm]# helm package chart
unloading distributions use helm uninstall or helm delete, so will the pod is also deleted
[root@k8s-master1 test-helm]# helm uninstall base-user-common
release "base-user-common" uninstalled