[容器] Helm的安装和使用

helm与EKS是无缝结合的，按照AWS教程即可

了解了下helm客户端和服务端tiller的区别

tiller是helm的服务端，helm客户端指令给到tiller部署EKS上的服务。AWS为了安全考虑建议tiller部署在本地，helm与本地的tiller交互，但缺点是每次helm指令都需要保证tiller服务在线。作为初学者，我直接将tiller部署到EKS上了。

helm init会将tiller服务部署好，同时测试helm repo update也成功了，但是helm ls遇到了如下错误：

原因是kubernetes对部署的服务有api权限控制，说白了就是tiller服务没有权限访问kubernetes的资源，需要赋予tiller一个role且绑定必要的权限，来做一下吧。

创建一个yaml描述文件，能看到该文件创建了一个ServiceAccount，同时做了一个ClusterRoleBinding。注意其中name、namespace取值要填写正确。

应用该yaml文件

表明使用上面的含有权限的账户，然后再运行不会报错了

EKS让参考helm官网的安装服务示例，helm上面的是mysql，但是验证mysql还需要client程序，blabla... 可以使用更简单的nginx来玩一下。

最后使用kubectl可以看到部署好的nignx服务，不过dns生效需要5分钟左右的时间，要耐心等一下。

Helm will figure out where to install Tiller by reading your Kubernetes configuration file (usually $HOME/.kube/config). This is the same file that kubectl uses.

各release版本:

helm指定特定的kubectl配置中特定的context dev描述的集群去部署:

tiller支持两种存储:

无论使用哪种部署方式,这两种存储都可以使用.memory存储在tiller重启后,release等数据会丢失.

执行helm init后,会

在k8s集群kube-system namespace下安装了deployment tiller-deploy和service tiller-deploy.

补充 :

https://github.com/kubernetes/helm/issues/2409

未解决.

尝试了几次,又成功了.

已解决:

在kubelet node上安装socat即可. https://github.com/kubernetes/helm/issues/966

2.5版本安装的tiller,在出现 context deadline exceeded 时,使用2.4版本的helm执行 heml reset --remove-helm-home --force 并不能移除tiller创建的pod和配置.这是2.4版本的问题.

https://docs.helm.sh/using_helm/#running-tiller-locally

When Tiller is running locally, it will attempt to connect to the Kubernetes cluster that is configured by kubectl. (Run kubectl config view to see which cluster that is.)

必须要执行 helm init --client-only 来初始化helm home下的目录结构.否则helm repo list会报以下的错误:

这种方法如果k8s集群,没有办法测试 helm install ./testChart --dry-run 类似的命令,

即使通过 ./tiller -storage=memory 配置存储为内存

在本地运行tiller,但指定后端运行的k8s集群

helm还是和之前的一样.

helm是k8s的包管理工具，类似于centos的yum，k8s将管理的资源都抽象成api，并且推荐使用声明方式创建，修改，删除这些对象，每个 API 对象都通过一个 yaml 格式或者 json 格式的文本来声明。这带来的一个问题就是这些 API 对象声明文本的管理成本，每当我需要创建一个应用，都需要去编写一堆这样的声明文件

helm就是管理这些api对象的工具，它把创建一个应用所需的所有 Kubernetes API 对象声明文件组合并打包在一起。并提供了仓库的机制便于分发共享，还支持模版变量替换，同时还有版本的概念，使之能够对一个应用进行版本的管理。

Helm chart 是用来封装 Kubernetes 原生应用程序的 YAML 文件，可以在你部署应用的时候自定义应用程序的一些 metadata，便与应用程序的分发。

Helm 和 chart 的主要作用是：

1.应用程序封装

2.版本管理

3.依赖检查

4.便于应用程序分发

Helm 可以安装本地或者远程的 chart，当 chart 安装到 Kubernetes 中后就会创建一个 release，每次更新该 chart 的配置并执行 helm upgrade， release 的版本数就会加 1。同一个 chart 可以部署多次

下面我们将一步步创建一个 chart 来说明其组织结构。

首先使用 helm create mychart 创建一个名为 mychart 的示例，我们再使用 tree mychart 命令看一下 chart 的目录结构。

以上仅为 helm 为我们自动创建的目录结构，我们还可以在 templates 目录加其他 Kubernetes 对象的配置，比如 ConfigMap、DaemonSet 等。

我们查看下使用 helm create 命令自动生成的 templates/service.yaml 文件。

可以看到其中有很多{{ }} 包围的字段，这是使用的 Go template 创建的自定义字段，其中 mychart 开头的都是在 _helpers.tpl 中生成的定义。

例如 _helpers.tpl 中对 chart.fullname 的定义：

我们再看下 values.yaml 文件中有这样的一段配置：

在使用 helm install 或 helm update 时，会渲染 templates/service.yaml 文件中的 {{ .Values.service.type }} 和 {{ .Values.service.port }} 的值。

使用 Helm

Helm 常用命令如下：

安装 chart 的命令格式为：

helm install [NAME] [CHART] [flags]

示例：

其中：

myvalues.yaml：自定义变量配置文件；

myredis：release 名称；

./redis：本地的 chart 目录；

Helm chart 安装后会转化成 Kubernetes 中的资源对象，生成一个 chart release，可以使用 helm list 命令查看。

关于 helm intsall 详细用法见： https://helm.sh/docs/helm/helm_install/ 。

要想升级 chart 可以修改本地的 chart 配置并执行：

使用 helm ls 的命令查看当前运行的 chart 的 release 版本，并使用下面的命令回滚到历史版本：

要想卸载 chart 可以使用下面的命令。

helm uninstall RELEASE_NAME [...] [flags]

---