k8s之helm入门
helm是k8s的另外一个项目,相当于linux的yum,在yum仓库中,yum不光要解决包之间的依赖关系,还要提供具体的程序包,helm仓库里面只有配置清单文件,而没有镜像,镜像还是由镜像仓库来提供,比如hub.docker.com、私有仓库.
helm提供了一个应用所需要的所有清单文件.比如对于一个nginx,我们需要一个deployment的清单文件、一个service的清单文件、一个hpa的清单文件,把这三个文件打包到一起,就是一个应用程序的程序包,称之为Chart.
Chart
Chart是一个helm程序包,其实质只是一个模板,我们可以对这个模板进行赋值(value),形成我们自定义的清单文件,也就实现我们生产个性化的需求,这样的仓库叫Chart仓库,一个https/http服务器.
Repos
Helm chart 可以被存储在专用的 HTTP 服务器上，称为 chart 仓库（repositories)，和 yum repository类似，chart 仓库提供了一个 index.yaml 来描述一批 chart，并且提供了每个 chart 的下载地址信息。
Helm 客户端可以指向多个 chart 仓库，默认情况下是没有配置仓库的，需要使用 helm repo add 来进行添加。helm3 中对于一些常用服务的下载安装，用 bitnami 仓库 取代了原来的stable 仓库，但是仍保留了 stable 仓库的使用。
Release
当 chart 被发布后，Helm 库会创建一个 release 来跟踪这个发布的对象，它的实质是在 Kubernetes 中运行的各种资源，service、deployment、configmap、secret 等，在 K8S 集群中的直接的表现就是一个或多个 pod。
在 Helm3 中，这种策略被升级成了三路策略合并，Helm 在生成一个补丁时，也会考虑之前老的 manifest 的活动状态。也就是说，在使用老的 chart manifest 生成新的补丁时，Helm 还会考虑当前的活动状态，并将其与之前老的 manifest 进行比对，并再比对新的 manifest 是否有改动，并进行自动补全，以此来生成最终的更新补丁
发布时必须指定 release 名称
在 Helm2 中，在发布时如果未提供 release 的名称，Helm 会自动生成一个，但是在 Helm3 中，如果未指定 release 名称，安装就会报错，如果仍然希望 Helm 能够自动生成 release 名称，可以使用 --generate-name 参数
二：官网介绍
https://helm.sh/docs/intro/quickstart/
三：Helm常用命令
[root@master ~]# helm version //查看helm版本信息
[root@master ~]# helm list /查看当前安装的Chart包
[root@master ~]# helm search mysql //查看与mysql相关的chart包
[root@master ~]# helm fetch stable/mysql //将mysql软件包下载到本地
[root@master ~]# helm inspect stable/mysql //查看该软件包的详细信息
[root@master ~]# helm install stable/mysql -n mysql //安装指定的mysql软件包，并命名为mysql
[root@master ~]# helm status mysql //查看mysql的状态信息
[root@master ~]# helm delete --purge mysql //删除mysql，并将本地的缓存也进行删除
[root@master ~]# helm repo add stable
https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts //添加阿里云的repo源
[root@master ~]# helm repo update //更新repo仓库资源
[root@master ~]# helm create helm_charts //创建一个chart，名称为helm_charts
[root@master ~]# cd helm_charts/ && helm lint //测试charts语法
[root@master ~]# helm package helm_charts //打包charts
[root@master helm_charts]# helm template helm_charts-0.1.0.tgz //查看该软件包生成的yaml文件
四：Helm 解决了什么痛点
在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。比如你安装一个 WordPress 博客，用到了一些 Kubernetes (下面全部简称k8s)的一些资源对象，包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码，可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在mariadb里面的，所以需要 mariadb 启动就绪后才能启动 WordPress。这些 k8s 资源过于分散，不方便进行管理，直接通过 kubectl 来管理一个应用，你会发现这十分蛋疼。
所以总结以上，我们在 k8s 中部署一个应用，通常面临以下几个问题：
- 如何统一管理、配置和更新这些分散的 k8s 的应用资源文件
- 如何分发和复用一套应用模板
- 如何将应用的一系列资源当做一个软件包管理
目录结构
- charts 目录存放依赖的chart
- Chart.yaml 包含Chart的基本信息，包括chart版本，名称等
- templates 目录下存放应用一系列 k8s 资源的 yaml 模板
- _helpers.tpl 此文件中定义一些可重用的模板片断，此文件中的定义在任何资源定义模板中可用
- NOTES.txt 介绍chart 部署后的帮助信息，如何使用chart等
- values.yaml 包含了必要的值定义（默认值）, 用于存储 templates 目录中模板文件中用到变量的值
基本命令
创建一个 Chart 模板
# helm create test
Creating test
helm package
打包一个 Chart 模板
# helm package test
Successfully packaged chart and saved it to: /root/test-0.1.0.tgz
helm search
查找可用的 Chart 模板
helm inspect
查看指定 Chart 的基本信息
# helm inspect test
apiVersion: v1
