• 安装Helm
    • 安装helm客户端
      • 用二进制发现版安装
      • 用 Homebrew (macOS)
  • 安装Tiller
    • 在集群内轻松安装
    • 安装tiller canary版本
  • 本地运行Tiller
  • 升级TILLER
  • 删除或重新安装TILLER
    • 高级用法
      • 使用--node-selectors
      • 使用--override
        • Override注解
      • override affinity
      • 使用--output
      • 后端存储
  • 结论

    安装Helm

    Helm有两个部分：Helm客户端（helm）和Helm服务器（Tiller）。 本指南介绍如何安装客户端，然后继续介绍安装服务器的两种方式。

    重要提示：如果您有责任确保您的群集是受控制的环境，尤其是在共享资源时，强烈建议使用安全配置安装Tiller。 有关指导，请参阅安装Helm安装。

    安装helm客户端

    Helm客户端可以从源代码安装，也可以从预先构建的二进制版本安装。

    用二进制发现版安装

    Helm的每个版本都为各种操作系统提供二进制版本。 这些二进制版本可以手动下载和安装。

    1. 下载你想要的版本
    2. 解压它 (tar -zxvf helm-v2.0.0-linux-amd64.tgz)
    3. 在解压后的目录中找到helm二进制文件，并将其移到它想要的目的地（mv linux-amd64/helm/usr/local/bin/helm）

    然后，你就可以运行客户端了：helm help。

    用 Homebrew (macOS)

    Kubernetes社区的成员为Homebrew贡献了Helm方案。 这个方案通常是最新的。

    1. brew install kubernetes-helm

    （注意：emacs-helm也有一个方案，这是一个不同的项目。）

    //TBD

    安装Tiller

    Helm的服务器部分Tiller通常运行在您的Kubernetes集群内部。 但是对于开发，它也可以在本地运行，并配置为与远程Kubernetes群集通信。

    在集群内轻松安装

    将tiller安装到集群中最简单的方法就是运行helm init。 这将验证helm的本地环境设置是否正确（并在必要时进行设置）。 然后它会连接到kubectl默认连接的任何集群（kubectl config view）。 一旦连接，它将把tiller安装到kube-system namespace中。

    在helm init之后，你应该可以运行kubectl get pods —namespace kube-system并且看到Tiller正在运行。

    你可以更精确的安装helm init …

    • 使用—canary-image标志安装canary版本
    • 使用—tiller-image安装特定镜像（版本）
    • 使用—kube-context安装到特定群集
    • 使用—tiller-namespace安装到特定的namespace中

    一旦安装了Tiller，运行helm version应该会显示客户端和服务器版本。 （如果只显示客户端版本，helm还不能连接到服务器，请使用kubectl来查看是否有任何tiller pod正在运行。）

    除非设置了—tiller-namespace或TILLER_NAMESPACE，否则Helm将在kube-system namespace中查找Tiller。

    安装tiller canary版本

    金丝雀图像是从主分支建立的。 他们可能不稳定，但他们为您提供测试最新功能的机会。

    安装Canary镜像最简单的方法是使用helm init和—canary-image标志：

    1. $ helm init --canary-image

    这将使用最近建立的容器镜像。 您可以使用kubectl从kube-system namespace中删除Tiller部署，随时卸载Tiller。

    本地运行Tiller

    对于开发而言，在本地处理Tiller有时更容易，并将其配置为连接到远程Kubernetes群集。

    上面介绍了建立Tiller的过程。

    一旦Tiller已经建成，只需启动它：

    1. $ bin/tiller
    2. Tiller running on :44134

    当Tiller在本地运行时，它将尝试连接到由kubectl配置的Kubernetes群集。 （运行kubectl config view查看是哪个群集。）

    您必须告诉helm连接到这个新的本地Tiller主机，而不是连接到一个群集中。 有两种方法可以做到这一点。 首先是在命令行中指定—host选项。 第二个是设置$HELM_HOST环境变量。

    1. $ export HELM_HOST=localhost:44134
    2. $ helm version # Should connect to localhost.
    3. Client: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"db...", GitTreeState:"dirty"}
    4. Server: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"a5...", GitTreeState:"dirty"}

    重要的是，即使在本地运行，Tiller也会将发布配置存储在Kubernetes内的ConfigMaps中。

    升级TILLER

    从Helm 2.2.0开始，可以使用helm init —upgrade升级Tiller。

    对于旧版本的Helm可以手动升级，或使用kubectl来修改Tiller镜像：

    1. $ export TILLER_TAG=v2.0.0-beta.1        # Or whatever version you want
    2. $ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG
    3. deployment "tiller-deploy" image updated

    设置TILLER_TAG = canary将获得master分支的最新快照。

    删除或重新安装TILLER

    由于Tiller将其数据存储在Kubernetes ConfigMaps中，因此您可以安全地删除并重新安装Tiller，而无需担心丢失任何数据。 推荐删除Tiller的方式是使用kubectl delete deploy tiller-deploy —namespace kube-system，或者更简洁的helm reset。

    然后可以从客户端重新安装Tiller：

    1. $ helm init

    高级用法

    helm init在安装之前为修改Tiller的deployment声明提供了额外的标志。

    使用--node-selectors

    —node-selectors标志允许我们指定调度Tiller pod所需的节点标签。

    下面的例子将在nodeSelector属性下创建指定的标签。

    1. helm init --node-selectors "beta.kubernetes.io/os"="linux"

    已安装的deloyment声明将包含我们的节点选择器标签。

    1. ...
    2. spec:
    3.   template:
    4.     spec:
    5.       nodeSelector:
    6.         beta.kubernetes.io/os: linux
    7. ...

    使用--override

    —override允许您指定Tiller的deployment声明的属性。 与helm中其他地方使用的—set命令不同，helm init —override操作最终声明的指定属性（没有“values”文件）。 因此，您可以为deployment声明中的任何有效属性指定任何有效值。

    Override注解

    在下面的示例中，我们使用—override来添加修订版本属性并将其值设置为1:

    1. helm init --override metadata.annotations."deployment\.kubernetes\.io/revision"="1"

    输出:

    1. apiVersion: extensions/v1beta1
    2. kind: Deployment
    3. metadata:
    4.   annotations:
    5.     deployment.kubernetes.io/revision: "1"
    6. ...

    override affinity

    在下面的例子中，我们为affinity节点设置了属性。 可以组合多个—override命令来修改同一列表项的不同属性。

    1. helm init --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].weight"="1" --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].preference.matchExpressions[0].key"="e2e-az-name"

    指定的属性组合到“preferredDuringSchedulingIgnoredDuringExecution”属性的第一个列表项中。

    1. ...
    2. spec:
    3.   strategy: {}
    4.   template:
    5.     ...
    6.     spec:
    7.       affinity:
    8.         nodeAffinity:
    9.           preferredDuringSchedulingIgnoredDuringExecution:
    10.           - preference:
    11.               matchExpressions:
    12.               - key: e2e-az-name
    13.                 operator: ""
    14.             weight: 1
    15. ...

    使用--output

    —output标志允许我们跳过安装Tiller的deployment声明，只需将deployment声明以JSON或YAML格式输出到stdout。 然后可以使用jq等工具修改输出，并使用kubectl手动安装。

    在下面的例子中，我们用—output json标志执行helm init。

    1. helm init --output json

    Tiller安装被跳过，声明以JSON格式输出到stdout。

    1. "apiVersion": "extensions/v1beta1",
    2. "kind": "Deployment",
    3. "metadata": {
    4.     "creationTimestamp": null,
    5.     "labels": {
    6.         "app": "helm",
    7.         "name": "tiller"
    8.     },
    9.     "name": "tiller-deploy",
    10.     "namespace": "kube-system"
    11. },
    12. ...

    后端存储

    默认情况下，Tiller会将release信息存储在ConfigMaps的运行的namespace中。 从Helm 2.7.0开始，现在有一个测试版存储后端使用Secrets来存储发布信息。 添加了此功能，以便在Kubernetes中发布Secret加密时保护chart的安全。

    要启用后端加密，您需要使用以下选项启动Tiller：

    1. helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'

    目前，如果您想从默认后端切换到加密后端，您必须自行为此进行迁移。 当这个后端从测试版本毕业时，将会有更正式的移徙路径

    结论

    在大多数情况下，安装和获得预先构建的helm二进制文件和运行helm init一样简单。 本文档涵盖了那些想要使用Helm做更复杂事情的人的其他案例。

    一旦成功安装了Helm Client和Tiller，您可以继续使用Helm来管理chart。