当提到 Helm 时，我们常常会做这样的类比：Helm 之于 Kubernetes，就像 apt 之基于 debian 的系统，yum 或 rpm 之于基于 Red Hat 的系统一样。除了包管理之外，Helm 还内置了配置管理的许多内容。

Helm 是针对 Kubernetes 的一款包管理工具，最初是由一家名为 Deis 的公司开发的，后来被微软收购。微软全力支持 Helm，加快了它的开发速度，现在它是云本地计算基金会 (CNCF) 的一部分。

为什么 Kubernetes 需要一个包管理器？

大多数技术都是以“Hello World”的示例来引入关键概念，Kubernetes 也不例外。除最简单的组件以外，将任何组件部署到 Kubernetes 集群都需要跨多个组件进行协调。

比如，管理 Kubernetes 集群外的应用程序部署的过程并不复杂，然而由于存在依赖关系和依赖版本、配置工件、部署前和部署后的步骤、验证等，这就变成一项繁琐的工作了。正如 apt 和 yum 是为 Linux 管理该过程一样，Helm 为 Kubernetes 处理这个过程。

总的说来，Helm 特性具有以下特性：

• Kubernetes 管理组件和应用程序的部署生命周期
• 基于模板的定义，支持跨部署环境 (例如，开发、质保、生产) 的可移植性
• 钩子机制可以在部署生命周期的不同阶段注入特定于用例的代码
• 部署测试框架

Helm 的结构

使用 Helm 只需要安装一个可执行文件。helm 命令提供了 20 多个参数，用于构建、部署、删除、回滚等，将应用程序部署到 Kubernetes 集群中。

Helm 部署构件是 Helm Chart。Helm Chart 由用于将组件或应用程序部署到 Kubernetes 集群的资源组成。Chart 中最常见的资源是 YAML 文件，它遵循标准的 Kubernetes 资源描述。如果你能够很熟练地使用 kubectl create 或者 kubectl apply 命令部署到 Kubernetes 集群，那么就会觉得 Helm Chart 中的 YAML 文件看起来很熟悉。Helm Chart 通常包含额外的资源，如 README 文件、默认参数文件和部署所需的额外文件 (如证书)。

开发 Helm Chart 需要使用预定义的目录结构组织文件。可以用 Helm 命令 helm create。

Helm 部署过程的一个关键特性是 Chart Hooks。在 Helm Chart 的部署生命周期中，Chart hook 是一种执行额外任务的机制。

例如，一个应用程序可能包含对一组微服务的依赖，其中的微服务由他自己的 Helm Chart 定义。当应用程序部署时，Helm 会管理这些依赖项。为了与微服务模式保持一致，每个组件都可以独立于其他组件进行更新，因此它仍然是内聚的应用程序的集合的定义。

规划 Helm 部署

Helm 在应用程序开发和部署的各个方面都能够发挥作用，这需要工程和运营团队紧密合作，以设计解决方案并回答部署问题。通过团队协调，可以迭代地做出部署决策，以使用单个部署包来支持每个环境的目标以适应每个部署环境中的差异。

除了前面描述的钩子概念之外，Helm 还提供了一种健壮的模板机制，使团队能够解决单一部署包的挑战。通常，Helm Chart 中的 YAML 文件看起来不像手写的 YAML Kubernetes 资源描述。

相反，Helm Chart 中的 YAML 文件是使用 Helm 的模板语言开发的：

{{- if .Values.ingress.enabled -}}
{{- $fullName := include "helm-demo.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}
kind: Ingress
metadata:
  name: {{ $fullName }}
  labels:
    {{- include "helm-demo.labels" . | nindent 4 }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  {{- if .Values.ingress.tls }}
  tls:
    {{- range .Values.ingress.tls }}
    - hosts:
        {{- range .hosts }}
        - {{ . | quote }}
        {{- end }}
      secretName: {{ .secretName }}
    {{- end }}
  {{- end }}
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          {{- range .paths }}
          - path: {{ .path }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: {{ $svcPort }}
          {{- end }}
    {{- end }}
  {{- end }}

这个由 helm create 生成的被模板化的 ingress 描述示例，提供了几个变量，用来定义和配置 ingress 资源，包括是否应该创建 ingress 资源。通过模板，Helm 提供了对 Kubernetes 资源如何部署的大量控制。规划良好的模板模式可以生成单个部署包，使 Helm Chart 能够成功部署，范围从开发人员工作站上的单节点 Kubernetes 集群到生产 Kubernetes 集群。

Helm Chart 和 CI/CD

作为组织持续集成 / 持续交付管道的一部分，Helm 扮演着促成者和组件的角色。作为一个推动者，它通过成为跨环境 (工程、质保、交付、认证、生产等) 部署应用程序或组件的机制来增强管道。在 CI/CD 管道中，自动化的 Helm Chart 部署非常简单。

Helm Chart 作为一个应用程序组件，也像应用程序代码一样是迭代开发和部署的。这意味着 CI/CD 管道在验证 Helm Chart 本身时是不可或缺的。事实上，Helm Chart 应该被视为应用程序代码的一部分，而不是应用程序开发过程的外围部分——甚至应该将 Helm Chart 作为应用程序源代码的一部分纳入管理。与应用程序构建生成版本化的容器映像并将其推送到镜像注册表的方式类似，helm package 将 chart 绑定到版本化的归档文件中。生成的归档文件被提交到 Helm Chart 存储库，可以从该存储库访问它以进行部署。

结束语

Helm 一直是 Kubernetes 生态系统炒作曲线的一部分，随着 Kubernetes 炒作曲线开始变平，Helm 也已经成熟。Helm 的方法是革命性的吗？不完全是。Helm 利用多年积累了大量的软件包和配置管理工具的知识，现在将这些经验带给 Kubernetes。同时，Helm 通过 Helm Chart 定义部署包的观点对组织 CI/CD 管道的效率产生了直接影响，最显著的是配置模式和部署灵活性。设计良好的 Helm Chart 是有效交付的重要组成部分。