# Helm使用手册
本文档基于的helm版本为：
? ~ helm version
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.17.2"}
本文档面向OPS角色，用来说明，基于这个仓库的内容，helm是如何启动一整套云端环境的，但并非step by step启动某个区域云端的SOP文档。
## 什么是helm，与kubectl有哪些不同
helm相对于原生kubectl有如下区别：
helm需要安装helm和kubectl
kubectl只需要安装kubectl
除了上面的这个区别之外，还有如下的思维观念上的区别：
### 编排维度
Helm是以应用为单位进行管理，一个应用是能够完整的提供一套服务的，它包含的内容是应用本身需要的配置描述、应用所占用的容器资源、内部暴露的端口、向其他服务提供end-point的方式等等，
所以在这个高层应用的维度上，helm引入了Chart和Release两个概念。
Chart用来表达一个应用需要的所有信息，它表现为一个具有特定目录结构的一系列文件，这一系列文件，可以由一个helm仓库(Helm Repository)来管理，也可以直接存储这一系列文件来管理。chart之于helm仓库，类似于jar包之于maven repo、package之于npm repo、go module source之于git repo
Release用来表达一个使用Chart启动的应用实例，Chart之于Release，就像一个Docker image之于Docker container. docker image启动时可以增加参数，Chart启动时也可以增加参数，但Chart管理的是应用，启动的配置往往比docker容器所需要的配置多很多，所以更常用的方式是，参数放在values文件中。
所以我们可以理解为:
public Release install(Chart chart,Values values)
kubectl管理的仅仅只是k8s集群中的资源，粒度更细，维度更低：configmap是资源，pod是资源，ingress是资源，service也是资源，kubectl一次只能对一个资源进行操作，所以用它来操作应用时，就会需要多条命令，当应用本身包含了多个服务时，操作应用时命令之间的先后顺序、服务的启动顺序、命令本身的数量，都会大大增加操作的复杂程度。
### 资源文件的表达方式
helm关注应用，应用的Chart中，细节中的k8s资源文件仍然需要存在，但，是模版化的，使用{{ .Values.xxx }}作为模版变量，应用到Release时，将会取Values中的xxx替换到资源文件，再启动应用。
所以对于A、B区域的应用，helm需要两个值文件：A-values.yaml、B-values.yaml，他们共用一个相同的Chart。
而kubectl关注k8s中的资源，比如configmap，在A区域中，需要一个A-configmap，在B区域中，需要B-configmap，即使只有几个字段不同，也需要有不同的资源文件来表达。所以最终它 会有A区域的一套资源文件，B区域的一套资源文件，这在比对和管理上会较为复杂。
### 部署方式
helm是面向应用的部署，将复杂的逻辑托管给了helm，比如比对配置文件有哪些更新，需要更新pod/ingress吗，等等。
在细节操作和记录的层次上，helm会自动的进行configmap、pod、service、ingress的删除、创建、更新；记录应用的更新版本号、更新时间、记录应用名称等。
在应用的层次上，它还具有回滚、滚动更新等特性。
而kubectl是k8s资源层次的功能，它操作细节，暴露细节，所以应用的信息需要操作者记录。它的回滚和滚动更新，都也只是k8s资源层次的。
? ~ helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
cn-a default 1 2021-12-02 22:54:43.105032 +0800 CST deployed a-0.1.0 1.16.0
cn-b default 1 2021-12-02 23:13:59.329862 +0800 CST deployed b-0.1.0 0.1.0
c default 2 2021-12-01 22:50:23.145235 +0800 CST deployed c-agent-0.1.0 1.0.0.10261
特殊地，面向应用的部署中我们再回来提到Helm概念中的两个版本号：Chart的版本号和应用的版本号。
我们刚才已经明白，Chart是模版，对于同一个应用，不同时间，需要的模版关注点也不一样，对模版的抽象可能也不一样。
比如应用没有到达功能稳定阶段，变化较大，我们可能对chart模版的抽象程度就低，暴露的内容更多，也许需要在values.yaml中写大量重复的信息；
当应用较为稳定时，我们可能对chart模版的抽象程度变高，模版变化较大，values也需要有相应的变化。
当产生了变动时，就是Chart的版本号变动逻辑。它表达的仅仅只是模版抽象的变化版本。
应用的版本号则跟随了服务的版本号，它表达的就是Chart所表达的应用本身，比如configmap有变化、pod有变化、资源有变化等情况，这属于应用本身的升级，这个版本号应跟随应用。
## 如何使用Chart和Values.yaml
在具体的操作上，这里提供了一些示例，用来表达具体的helm操作逻辑。
我们知道，当重启了priest的service之后，需要重新启动最前方的nginx代理(如果有且它的proxy_pass到了一个service上，这种情景下，service重启后，nginx无法转发到新的service了，需要重启nginx才可以)，比如flagship_api，
当flagship_api是helm启动时，如何重启pod呢？这种可以有两种方式：
-- https://github.com/helm/helm/issues/9041
kubectl rollout restart deployment <deploymentname>
kubectl delete pod <podname>
# Install Release
helm install xxxName chartOrChartSource -f value-which-renamed.yml
# Upgrade
helm upgrade xxxName chartOrChartSource -f value-which-renamed.yml
# Debug
helm install xxxName chartOrChartSource --dry-run -f value-which-renamed.yml --debug
# list All Release
helm list
|