Kubernetes HelmHelm 概述Helm 的主要概念Helm 的安装Helm 使用Helm search 搜索可用的 ChartHelm install 安装 Chart自定义 Chart 的配置set 的格式和限制更多的安装方法helm upgrade 和 helm rollback 应用的更新或回滚helm install/upgrade/rollback 命令的常用参数helm delete 删除一个 Releasehelm repo 仓库的使用自定义 ChartChart 目录结构和配置文件的说明Chart.yaml 文件说明快速制作自定义的 Chart搭建私有 Repository删除 Helm Kubernetes Helm随着容器技术逐渐被企业接受，简单的应用在 Kubernetes 上已经能够便捷部署。但对于复杂的应用中间件，在 Kubernetes 上进行容器化部署并非易事，通常需要先研究 Docker 镜像的运行要求、环境变量等内容，并能为这些容器定制存储、网络等设置，最后设计和编写 Deployment、Configmap、Service 及 Ingress 等相关 yaml 配置文件，在提交给 Kubernetes 进行部署。这些复杂的过程将逐步被 Helm 应用包管理工具实现。Helm 概述Helm 是一个由 CNCF 孵化和管理的项目，用于对需要在 Kubernetes 上部署的复杂应用进行定义，安装和更新。Helm 以 Chart 的方式对应用软件进行描述，可以方便的创建、版本化、共享和发布复杂的应用软件。Helm 的主要概念Chart 是一个 Helm 包，其中包含了运行一个应用所需要的工具和资源定义，还可能包含 Kubernetes 集群中的服务定义，类似于 Homebrew 中的 formula、APT 中的 dpkg 或者 Yum 中的 RPM 文件。Release 在 Kubernetes 集群上运行一个 Chart 示例。在同一个集群上，一个 Chart 可以安装多次。例如有一个 MySQL Chart，如果想在服务器上运行两个 MySQL 数据库，就可以基于这个 Chart 安装两次。每次安装都会生成新的 Release，会有独立的 Release 名称。Repository 用于存放和共享 Chart 的仓库。简单来说，Helm 整个系统的主要任务就是，在仓库中查找需要的 Chart，然后将 Chart 以 Release 的形式安装到 Kubernetes 集群中。Helm 的安装Helm 由以下两个组件组成。HelmClient：客户端，拥有对 Repository、Chart、Release 等对象的管理能力。TillerServer：负责客户端指令和 Kubernetes 集群之间的交互，根据 Chart 定义，生成和管理各种 Kubernetes 的资源对象。1）HelmClient 客户端：可以通过二进制文件或脚本方式安装。通过二进制文件方式安装，需要从 https://github.com/kubernetes/helm/releases 下载二进制文件，解压并复制到执行目录即可。通过脚本方式安装，执行下方脚本即可：2）TilerServer 的安装对 TillerServer 的安装可以使用 helm init 命令进行（官方推荐），这一命令会在 kubectl 当前 context 指定集群内的 kube-system 命名空间创建一个 Deployment 和 一个 Service，运行 TillerService 服务。Deployment 中使用的景象是 gcr.io/kubernetes-helm/tiller:v[helm-version]，Helm 版本可以使用 helm version 命令获得。如果环境无法连接互联网获取该镜像，则可以先通过一台能够联网的服务器下载这个镜像保存到镜像仓库，利用 helm init 子命令的 --tiller-image 参数来指定镜像仓库中的镜像来执行初始化过程。安装结束之后，用 helm version 命令来验证安装情况，一切正常的话，会分别显示 Tiler 和 Helm 的版本信息。一个常见的问题是，Tiler 部分显示一个错误信息：“uid：unable to do port forwarding：socat not found”，这是因为所在节点没有 socat，无法进行端口转发造成的，在主机上安装 socat 软件即可。对 TilerServer 的安装还可以在本地进行，在服务器本地直接运行 Tiller，这种安装方式需要让 Helm 指定要连接的服务地址，有以下两种方式。使用 --host 指定 Tiller 运行的监听地址。设置 HELM_HOST 环境变量。需要注意的是，Tiller 仍会使用 kubectl 配置中的 context 连接 Kubernetes 集群。MacOS 执行结果如下：或者指定服务器名称使用其他镜像可以执行此命令：正常状态：Helm 使用下面介绍 Helm 的常见用法，包括搜索 Chart、安装 Chart、自定义 Chart 配置、更新或回滚 Release、删除 Release、创建自定义 Chart、搭建私有仓库等。Helm search 搜索可用的 ChartHelm 初始化完成之后，默认配置为使用官方的 Kubernetes Chart 仓库。官方仓库包含大量的警告组织和持续维护的 Chart，这个仓库通常命名为 stable。在没有进行过滤的情况下，helm search 会显示所有可用 chart，可以使用参数进行过滤：为什么列表会有 MariaDB？因为 MariaDB 的描述信息中包含了 mysql 关键字。可以使用命令查看 Chart 的详细信息：找到需要安装的 Chart 之后，就可以进行安装了。Helm install 安装 Chart使用 helm install 命令进行应用的安装，最简单的参数就是 Chart 的名称。下面以 MariaDB 为例：至此，MariaDB 就安装完成了。可以看到系统创建了一个新的名为 womping-bobcat 的 Release 对象，这个名称可以在 helm install 命令中使用 --name 参数进行修改。在安装过程中，Helm 客户端输出一些有用的信息，例如 Release 的状态，以及额外的配置步骤等。Helm 不会等待所有创建过程的完成。这是因为有些 Chart 的 Docker 镜像较大，会消耗很长的实际进行下载和创建。如果有 RBAC 的等问题，请到 Github issus 查看：https://github.com/kubernetes/helm/issues/2224，或执行：在 helm install 过程中，可以使用 helm status 命令来跟踪 release 的状态:删除服务：在成功安装 Chart 后，系统会在 kube-system 命名空间内创建一个 configmap 用于保存 Release 对象的数据：自定义 Chart 的配置前面介绍的安装过程使用的是 Chart 的默认设置。然而在很多情况下，会希望使用自定义的配置进行应用的部署。首先，用 helm inspect 命令查看 Chart 的可配置内容：用户可以编写一个 yaml 配置文件来覆盖上面这些设置，然后利用一个文件来给安装过程提供设置。例如，可以自定义配置额外的两个配置文件 config.yaml 和 config2.yaml，用于 helm install 安装 MariaDB 之后，在 MariaDB 启动时自动创建名为 firstdb 和 seconddb 的数据库，并且设置 root 用户的密码：安装完成之后，可以登入到 MariaDB Pod 中查看数据库是否已经创建成功。自定义 Chart 的配置有两种方法。--values 或者 -f：使用 yaml 配置文件进行参数配置，可以设置多个文件，最后一个优先生效。多个文件中重复的 value 会进行覆盖操作，不同的 value 会叠加生效。上面的例子使用的就是这种方式。--set：在命令行直接设置参数。如果同时使用两个参数，则 --set 会以高优先级合并到 --values 中。set 的格式和限制--set 参数可以使用零或者多个名称/值的组合。最简单的方式是 --set name=value，yaml 中的等效描述是：多个值可以使用逗号进行分割，例如 --set a=b,c=d 的 yaml 等效为下面的描述：还可以用来表达多层结构的变量 --set outer.inner=value：大括号 ( {} ) 可以用来表达列表数据，例如 --set name={a,b,c} 会翻译成：有需要在 --set 时使用一些特殊字符，这里可以使用斜线进行转义，比如 --set name=value1\, value2。类似的，可以对点符号 ". " 进行转义，这样 Chart 使用 toYaml 函数解析注解、标签或者 node selector 时就很方便了，例如: --set nodeSelector."kubernetes\.io/role"=master。尽管如此，–set 语法的表达能力依然无法和 yaml 相提并论，尤其是在处理集合时。目前没有方法能够完成注入 “把列表中第 3 个元素设置为 xxx” 这样的描述。更多的安装方法helm install 能通过多种安装源进行安装。上面提到的 Chart 仓库。本地的 Chart 压缩包（helm install foo-0.1.1.tgz）一个 Chart 目录（helm install path/to/foo）一个完整的 URL（helm install https://example.com/charts/foo-1.3.4.tgz）helm upgrade 和 helm rollback 应用的更新或回滚当一个 Chart 发布新版本或者需要修改一个 Release 的配置时，就需要使用 helm upgrade 命令了。helm upgrade 会利用用户提供的信息来对 Release 进行更新。因为 Kubernetes Chart 可能会有很大的规模或者复杂的管理，Helm 会尝试进行最小影响范围的更新，只更新相对于上一个 Release 来说发生变化的内容。例如要更新一个 Release 的资源限制，创建 config3.yaml 配置文件，内容如下：使用 upgrade 命令进行更新：看到更新提示之后，可以用 Helm 的 list 指令查看 Release 的信息，会发现 revision 一列发生了变化。接下来使用 kubectl 的 get pods，deploy 指令，可以看到 pod 已经被更新；如果使用 kubectl describe deploy 指令，则还会看到 deployment 的更新过程和一系列的 ScalingReplicaSet 事件。如果对更新后的 Release 不满意，则可以使用 helm rollback 命令对 Release 进行回滚，例如：这个命令可以将名为 elder-lightningbug 的 Release 回滚到版本 2.命令执行之后，同样可以使用之前提到的几个查询指令，会看到类似结果。最后，可以使用 helm history命令来查看一个 Release 的变更历史。helm install/upgrade/rollback 命令的常用参数Helm 有很多参数可以帮助用户来指导命令的行为，可以通过 helm --help 来进行查看。--timeout：等待 Kubernetes 命令完成的时间，单位是 s，默认值是 300，也就是 5min。--wait：等待 Pod，指导其状态变为 ready，PVC 完成绑定，Deployment 完成其最低就绪要求的 Pod 创建，并且服务有了 IP 地址，才认为 Release 创建成功。这一等待过程会一直持续到超过 --timeout，超过后这一 Release 被编辑为 FAILED（注意：当 Deployment 的 replicas 被设置为 1，同时滚动更新策略的 maxUnavailable 不为 0 时，–wait 会因为最小就绪 Pod 数量达成而返回 ready 状态）。no-hooks：该命令会跳过 Hook 执行。--recreate-pods：会引用所有 pod 的重建（Deployment 所属的 Pod 除外）。helm delete 删除一个 Release执行 helm delete 命令可以删除一个 Release，例如使用 helm delete happy-panda 会从集群中删除名为 “happy-panda” 的 Release。可以使用 helm list 命令列出集群中部署的 Release。如果给 list 加上了 --deleted 参数，则会列出所有删除的 Release；–all 参数会列出所有的 Release，包含删除的、现存的以及失败的 Release。正因为 Helm 会保存所有被删除 Release 信息，所以 Release 的名字是不可复用的（如果坚持服用，则可以使用 --replace 参数，这一操作不建议在生产环境中使用），这样被删除的 Release 也可以被回滚，甚至重新激活。helm repo 仓库的使用前面使用的 Chart 都来自于 stable 仓库。可以对 helm 进行设置，让其使用其他仓库。Helm 在 helm repo 命令中提供了很多仓库相关的工具。helm repo list：列出所有仓库。helm repo add：添加仓库，例如从 repo_url 添加名为 dev 的仓库 helm repo add dev http:///dev-charts。 helm repo update：更新仓库中的 Chart 信息。 自定义 Chart 用户可以将自己的应用定义为 Chart 并进行打包部署，详细的开发指南参见：https://docs.helm.sh/developing_charts/#charts Chart 目录结构和配置文件的说明 Chart 是一个包含一系列文件的目录。目录的名字就是 Chart 的名字（不包含版本信息），例如一个 WordPress 的 Chart 就会存储在 wordpress 目录中。 目录中的文件结构如下： chrts 子目录和 requirements.yaml 的区别在于，前置需要提供整个 Chart 的文件，后者仅需要注明依赖 Chart 的仓库信息，例如一个 requirements.yaml 可以定义为： Chart.yaml 文件说明 Chart.yaml 文件（注意手写字母大写）这个需要文件，包含如下内容。 name：Chart 名，必选。 version：SemVer2 规范的版本号，必选。 description：项目的描述，可选。 keywords：一个用于描述项目的关键字列表，可选。 home：项目的主页，可选。 sources：一个 URL 列表，说明项目的源代码位置，可选。 maintainers：维护者列表，可选。 name：管理员名字，必选。 email：管理员邮件地址，必须。 engine：模板引擎命令，默认值是 gotpl，可选。 icon：一个指向 svg 或 png 图像的 URL，作为 Chart 的图标，可选。 appVersion：Chart 中包含的应用的版本，无须遵循 SemVer 规范，可选。 deprecated：布尔值，该 Chart 是否标注为 “启用”，可选。 tillerVersion：可选，该 Chart 所需的 Tiller 版本。取值应该是一个 SemVer 的范围，例如 “>2.0.0”。 快速制作自定义的 Chart 同其他软件开发过程一样，快速制作一个简单 Chart 的方法，就是从其他项目中复制并修改。比如要简单地改写前面 MariaDB 的 Chart，令其使用本地的私有镜像仓库，可以按照如下步骤进行。 下载 Chart：使用 helm fetch stable/mariadb 命令下载这一 Chart 的压缩包。 编辑 Chart。 利用 tar 压缩之后，将目录重新命名为 mymartiadb。 修改 templatest 中的 deployment.yaml，简单地将其中的 image 字段硬编码为需要的镜像（当然不推荐这种用法，可以继续以便利的方式在 values 中进行设置）。 将 Chart.yaml 中的版本号修改为 0.1.1，name 为 mymariadb。 使用 helm package mymariadb 打包 Chart，会生成一个名为 mymariadb-0.1.1.tgz 的压缩包。 安装 Chart：通过 helm install mymariadb-0.1.1.tgz 命令可将新生成的 Chart 安装到集群中。 搭建私有 Repository 自建 Chart 之后，自然需要搭建私有仓库。下面使用 Apache 来搭建一个简单的 Chart 私有仓库，并将刚才新建的 mymariadb Chart 保存到私有仓库中。相关文档：https://docs.helm.sh/developing_charts/#the-chart-repository-guide Chart 仓库主要由前面提到的 Chart 压缩包和索引文件构成，通过 HTTP/HTTPS 对外提供服务。这里使用一个 Apache 应用来提供仓库服务。Apache 的设置如下。 Apache 使用 /var/web/repo 目录进行仓库的存储。 使用 http://127.0.0.1/repo 网址提供访问服务。 将前面生成的 mymariadb-0.1.1.tgz 文件复制到仓库的 /var/web/repo 目录中。 接下来使用 helm repo index /var/web/repo --url http://127.0.0.1/repo 命令，Helm 将自动根据目录中的内容创建索引。命令执行完成后，可以看到目录下多出来了一个 index.yaml 文件。 最后启动 Web Server。 为了能够使用这个私有仓库，需要将这个新的仓库地址加入到 Helm 配置中： 再次运行 helm search mysql 命令，就会看到 Chart 列表中多出来的 localhost/mymariadb 项目了，也就是新仓库中的 Chart。 可以使用 install 命令进行安装。 删除 Helm 如果需要删除 Helm 可执行，但是会删除所有相关的应用：