Helm 入门学习
概念：helm是什么？Helm 是Kubernetes的包管理器。包管理器类似于在Ubuntu中使用的apt，能快速查找、下载和安装软件包。Helm由客户端组件helm和服务端组件Tiller组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。因为在Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。而这些k8s资源过于分散，不方便进行管理，直接通过 kubectl 来管理一个应用，十分麻烦。所以使用helm就可以解决1）如何统一管理、配置和更新这些分散的 k8s 的应用资源文件，2）如何分发和复用一套应用模板。3）如何将应用的一系列资源当做一个软件包管理。
原理：Helm的几个关键组件 Helm（客户端）、Tiller（服务器）、Repository（Chart 软件仓库）、Chart（软件包）。helm之间的通信时helm client通过grpc协议消息传到helm的服务器端Tiller，Tiller与k8s API交互。而helm的整体架构如下图：
组件：1）helm 是一个命令行工具，用于本地开发及管理chart，chart仓库管理等；2）Tiller 是 Helm 的服务端。Tiller 负责接收 Helm 的请求，与 k8s 的 apiserver 交互，根据chart 来生成一个 release 并管理 release；3）chart Helm的打包格式叫做chart，所谓chart就是一系列文件, 它描述了一组相关的 k8s 集群资源；4）release 使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release；5）Repoistory Helm chart 的仓库，Helm 客户端通过 HTTP 协议来访问存储库中 chart 的索引文件和压缩包。具体的工作流程如下：
创建release：1）helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息； 2）helm客户端指定的chart 结构和values信息通过 gRPC 传递给Tiller；3）Tiller 服务端根据 chart 和 values 生成一个 release； 4）Tiller 将install release请求直接传递给 kube-apiserver。同理删除release：1）helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息；2）helm 客户端指定的 chart 结构和 values 信息通过 gRPC 传递给 Tiller； 3）Tiller 服务端根据 chart 和 values 生成一个 release；4）Tiller 将delete release请求直接传递给 kube-apiserver。更新release：1）helm 客户端将需要更新的 chart 的 release 名称 chart 结构和 value 信息传给 Tiller；2）Tiller 将收到的信息生成新的 release，并同时更新这个 release 的 history；3）Tiller 将新的 release 传递给 kube-apiserver 进行更新。
安装前提：以下是成功和安全使用Helm的前提条件。1）一个Kubernetes集群或有一个可访问的集群；2）决定将哪些安全配置应用于安装（如果有的话）3）安装和配置Helm和Tiller（集群端服务）。你必须安装Kubernetes。对于Helm的最新版本推荐Kubernetes的最新稳定版本，它在大多数情况下是第二个最新的次要版本，还应该有一个本地配置的kubectl。注：Kubernetes v1.6之前的版本对基于角色的访问控制（RBAC）支持有限或不支持。Helm将通过读取Kubernetes配置文件（通常为 $HOME/ .kube/config）找到安装Tiller的位置。这与kubectl使用的同一个文件。要找到Tiller要安装到哪个集群，可以运行kubectl config current-context或kubectl cluster-info。
安装：Helm客户端可以从源代码安装，也可以从预先构建的二进制版本安装。1）使用二进制版本：Helm的每个版本都为各种操作系统提供了相应的二进制版本。这些二进制版本可以手动下载和安装。1）下载你需要的版本；2）解压（tar -zxvf helm-v2.0.0-linux-amd64.tgz）；3）在解压的目录中找到helm二进制文件，将其移至合适的地方（mv linux-amd64/helm /usr/local/bin/helm）在那里，你应该能够运行客户端：helm help。Helm现在有一个安装脚本，可以自动获取最新版本的Helm客户端并在本地安装。你可以获取该脚本，然后在本地执行它。它有很好的文档记录，因此你可以在运行它之前通读它并了解它在做什么。$ curl -LO https://git.io/get_helm.sh $ chmod 700 get_helm.sh $ ./get_helm.sh 你还可以curl -L https://git.io/get_helm.sh | bash ，Tiller是Helm的服务端部分，通常运行在Kubernetes集群内部。但对于开发，它也可以在本地运行，并配置为与远程Kubernetes集群通信。
大多数云提供商都支持一个称为基于角色的访问控制的特性——简称RBAC。如果你的云提供商启用了此功能，你将需要为Tiller创建一个服务账户，该帐户具有访问资源的正确角色和权限。在集群中安装tiller的最简单方法是运行helm init。这将验证Helm的本地环境是否正确设置（并在必要时进行设置）。然后它将默认连接到kubectl连接的集群（kubectl config view）。一旦连接，它将把tiller安装到kube-system命名空间中。helm init之后，你应该可以运行 kubectl get pods --namespace kube-system，并可以看到Tiller正在运行。一旦安装了Tiller，运行helm version应该同时显示客户端和服务端版本。如果它只显示客户端版本，则helm还没有连接到服务端。使用kubectl查看是否有tiller pod正在运行。Helm将在kube-system命名空间中查找Tiller，除非设置了--tiller-namespace 选项或 TILLER_NAMESPACE环境变量。对于开发，有时本地运行Tiller更加方便，并将其配置为连接到远程Kubernetes集群。一但 tiller构建好了，只需要简单地启动它：$ bin/tiller Tiller running on :44134 当Tiller在本地运行时，它将尝试连接到由kubectl配置的Kubernetes集群。（运行kubectl config view，查看连接的是哪个集群。）你必须告诉helm连接到这个本地Tiller主机，而不是连接到集群中的一个Tiller主机。有两种方法可以做到这一点。第一种方法是在命令行上指定--host选项。第二个是设置$HELM_HOST环境变量。$ export HELM_HOST=localhost:44134 $ helm version # Should connect to localhost。重要的是，即使在本地运行时，Tiller也会将发布配置存储在Kubernetes内部的ConfigMap中。
升级Tiller从Helm v2.2.0开始，Tiller可以使用 helm init --upgrade进行升级。对于旧版本的Helm，需要手动升级，你可以使用k8s修改Tiller的镜像：$ export TILLER_TAG=v2.0.0-beta.1 # Or whatever version you want $ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG 设置TILLER_TAG=canary将获得master分支的最新快照。删除或重新安装Tiller：因为Tiller将其数据存储在Kubernetes ConfigMap中，所以你可以安全地删除和重新安装Tiller，而不必担心丢失任何数据。推荐的删除Tiller的方式是使用kubectl delete deployment tiller-deploy --namespace kube-system，或者更简洁一些：helm reset。然后可以使用以下命令从客户端重新安装Tiller：$ helm init helm init提供了额外的选项，用于在安装Tiller的部署清单之前修改它。使用--node-selectors选项允许我们指定调度Tiller pod所需的节点标签。下面的示例将在nodeSelector属性下创建指定的标签。helm init --node-selectors "bata.kubernetes.io /os" = "linux"; 使用--override 它允许你指定Tiller的部署清单的属性。
与Helm中的--set选项不同helm init override操作最终清单的指定属性（没有“values”文件）。因此，你可以为部署清单中的任何有效属性指定任何有效值。使用--output output选项允许我们跳过Tiller的部署清单的安装，直接以JSON或YAML格式将部署清单输出到标准输出。然后可以使用jq等工具修改输出，并使用kubectl手动安装。执行helm init时指定--output json选项。helm init --output json跳过了Tiller安装，清单以JSON格式输出到标准输出。默认情况下，tiller将ConfigMap中的发布信息存储在它运行的名称空间中。secret的存储后端，在Helm v2.7.0中，现在有一个beta存储后端，它使用Secret来存储发布（release）信息。这是为了在Kubernetes发布Secret加密的同时保护chart而增加的额外安全措施。要启用secret存储后端，你需要使用以下选项初始化Tiller：helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'；SQL存储后端，在Helm v2.14.0中，现在有一个beta SQL存储后端，它在SQL数据库中存储发布信息（到目前为止只测试了postgres）。如果你的发布（release）信息超过1MB（在这种情况下，它不能存储在ConfigMap或Secret中，因为Kubernetes的底层etcd键值存储存在内部限制），那么使用这样的存储后端尤其有用。
三个重要的概念及使用：chart是一个Helm包。它包含了在Kubernetes集群中运行应用程序、工具或服务所需的所有资源定义。可以把它看作Kubernetes的Homebrew formula、一个Apt dpkg或一个Yum RPM文件。仓库（repository）是可以收集和共享chart的地方。它类似于Perl的CAPN归档或Fedora包数据库，但仓库针对的是Kubernetes包，是一个存放了index.yaml文件和一些的chart（可选）的HTTP服务器。当你准备共享chart时，最好的方法是将它们上传到chart仓库。由于chart仓库可以是任何能够提供YAML和tar文件并能够响应GET请求的HTTP服务器，所以当涉及到托管自己的chart仓库时，你有很多的选择。例如，你可以使用谷歌云存储（GCS）桶、Amazon S3桶、Github页面，甚至创建自己的web服务器。chart仓库由打包的chart和称为index.yaml（包含仓库中所有chart的索引）的特殊文件组成。通常情况下，index.yaml描述的chart和来源文件托管在同一服务器上。如仓库 https://example.com/charts的布局可能如下所示：
charts/
|
|- index.yaml
|
|- alpine-0.1.2.tgz
|
|- alpine-0.1.2.tgz.prov索引文件是一个名为index.yaml的yaml文件。它包含关于包的一些元数据，包括chart的Chart.yaml文件的内容。一个有效的chart仓库必须有一个索引文件。索引文件包含关于chart仓库中每个chart的信息。helm repo index命令将根据包含打包chart的给定本地目录生成索引文件。
发布（release）是在Kubernetes集群中运行的chart的实例。一个chart通常可以多次安装到同一个集群中。每次安装它时，都会创建一个新的发布。考虑一个MySQL chart。如果希望在集群中运行两个数据库，可以安装该chart两次。每个都有自己的发布，而每个发布又有自己的发布名称。Helm将chart安装到Kubernetes中，为每个安装创建一个新的发布。要找到新的chart，你可以搜索Helm chart仓库。helm search：查找chart：当第一次安装Helm时，它被预先配置为与官方的Kubernetes chart仓库进行交互。这个仓库包含许多精心策划和维护的chart。默认情况下，这个chart仓库的名称为stable。可以运行helm search查看哪些图表可用：如果不使用过滤器，helm search向你显示所有可用的chart。你可以使用过滤器来缩小你的搜索结果：$ helm search mysql,可以使用helm inspect char查看helm 包的详细信息。
使用helm install来安装搜索得到的包，它只需要一个参数：chart的名称。如$ helm install stable/mariadb；注：安装chart会创建一个新的发布对象。（如果你想使用自己的发布名称，只需在helm install上使用--name选项即可）在安装期间，helm客户端将打印关于创建了哪些资源、发布的状态如何以及是否可以或应该执行其他配置步骤的有用信息。Helm不会等到所有资源都运行之后才退出。许多chart需要大小超过600M的Docker镜像，并且可能需要很长时间才能安装到集群中。在安装过程中有两种传递配置数据的方法: 1) --values 或者 -f：指定YAML文件覆盖配置项。可以指定多次，最右边的文件将优先；2) --set 与其变种 --set-string 和--set-file：在命令行中指定要覆盖的配置项。如果两者都使用，--set值将合并到具有更高优先级的 --values 值中。用--set指定的覆盖将持久化在ConfigMap中。可以通过 helm get values <release-name>查看通过--set已设置的值。通过 --set 设置的值可以执行 helm upgrade时指定 --reset-values来清除。从Helm 2.5.0开始，可以使用数组索引语法访问列表项。有时需要在--set行中使用特殊字符。你可以使用反斜杠来转义字符；
helm upgrade和helm rollback，升级发布并在失败时进行恢复,当一个chart的新版本发布时，或者当你想要改变发布的配置时，你可以使用helm upgrade命令。升级采用现有版本并根据你提供的信息进行升级。因为Kubernetes chart可能很大也很复杂，Helm试图执行侵入性最小的升级。它将只更新自上一个版本以来更改的内容。$ helm upgrade -f panda.yaml happy-panda stable/mariadb在上面的例子中，happy-panda 发布使用相同的chart进行了升级，但是使用了一个新的YAML文件：可以使用helm get values来查看新设置是否生效。helm get命令是查看集群中某个发布的有用工具。它显示了我们从panda.yaml得到的、被部署到集群中的新值。使用 helm rollback [RELEASE] [REVISION]很容易回滚到以前的发布。可以使用helm history [RELEASE]来查看某个发布的修订号。在安装、升级、回滚期间，还可以指定几个其他有用的选项来自定义Helm的行为。请注意，这不是一个完整的命令行选项。要查看所有选项的描述，只需运行 helm <command> --help。(1)--timeout：等待Kubernetes命令完成的秒数值，默认为300（5分钟）(2) --wait：等待，直到所有的pod都处于就绪状态，PVC被绑定，部署在就绪状态中有最少的pod（Desired 减去maxUnavailable），服务有一个IP地址（如果是LoadBalancer类型，则为Ingress），然后才将发布标记为成功。它将等待与--timeout值一样长的时间。如果超时，则发布将被标记为FAILED。注意：在部署将 replicas设置为1而maxUnavailable不设置为0作为滚动更新策略的一部分的场景中，--wait将返回Ready，因为它满足了Ready条件下的最少Pod。(3) --no-hooks：跳过钩子执行 (4) --recreate-pods（只对 upgrade 和rollback可用） ：此选项将导致重新创建所有pod（属于部署的pod除外）.helm delete：删除发布,可以使用helm list命令查看你目前部署的所有发布：helm repo：操作仓库,可以使用helm repo list查看配置了哪些仓库：使用helm repo add添加一个新仓库：$ helm repo add dev https://example.com/dev-charts由于chart仓库经常更改，在任何时候都可以通过运行helm repo update来确保helm客户端是最新的。
