1.2　Helm的目标

到目前为止，我们关注的是更广泛的云原生生态系统以及Kubernetes在该生态系统中的角色。在本节中，我们将把焦点转移到Helm。

在上一节中，我们看到了几个不同的Kubernetes资源：Pod、ConfigMap、Deployment和Service。每一个资源都扮演着一些独立的角色。但是一个应用程序通常需要不止一个资源。

例如，WordPress CMS系统可以在Kubernetes内部运行。但通常情况下，它至少需要一个Deployment（用于WordPress服务器）、一个ConfigMap（用于配置）、一个Secret（用于保存密码）、几个Service对象、一个StatefulSet（用于运行数据库）和几个基于角色的访问控制（RBAC）规则。Kubernetes对基本WordPress站点的描述已经超过了数千行YAML。Helm的核心思想是，所有这些对象都可以打包在一起进行安装、更新和删除。

编写Helm有三个主要目标：

1.轻松地实现从“从零到Kubernetes”；

2.提供与操作系统类似的软件包管理系统；

3.强调将应用程序部署到Kubernetes的安全性和可配置性。

接下来一一介绍，然后看看Helm用法的另一个方面：它如何参与生命周期管理。

1.2.1　从零到Kubernetes

Helm项目始于2015年，也就是KubeCon创始前几个月。Kubernetes过去很难设置，通常需要新用户编译Kubernetes源代码，然后使用一些shell脚本来运行Kubernetes。一旦集群启动，新用户就需要从头开始编写YAML。

我们希望颠倒学习周期：不要求用户从基本示例开始，尝试构建自己的应用程序，而是希望为用户提供现成的生产就绪示例。用户可以安装这些示例，查看它们的实际操作，然后了解Kubernetes是如何工作的。

这曾经是（至今仍然是）我们编写Helm的第一要务：让Kubernetes更易于使用。在我们看来，拥有现有Kubernetes集群的新Helm用户应该能够在5分钟甚至更短的时间内完成从下载到安装应用程序的步骤。

Helm不仅仅是一个学习工具，它还是一个软件包管理器。

1.2.2　软件包管理

Kubernetes就像一个操作系统。在它的基础上，操作系统提供了执行程序的环境。它提供了存储、执行和监视程序生命周期所需的工具。

它不执行程序，而是执行容器。但与操作系统类似，它提供了存储、执行和监视这些容器所需的工具。

大多数操作系统都由软件包管理器支持。软件包管理器的任务是使在操作系统上查找、安装、升级和删除程序变得容易。软件包管理器提供了将程序捆绑到可安装的应用程序中的语义，并提供了存储和检索软件包以及安装和管理软件包的方案。

当我们将Kubernetes设想为一个操作系统时，很快就看到了对Kubernetes软件包管理器的需求。从第一次提交到Helm源代码库，我们就一直将软件包管理比喻应用到Helm上：

·Helm提供软件包存储库和搜索功能，以查找可用的Kubernetes应用程序。

·Helm拥有我们熟悉的安装、升级和删除命令。

·Helm定义了在安装软件包之前配置软件包的方法。

·Helm提供了查看已安装内容和配置方式的工具。

我们最初借鉴Homebrew（macOS的软件包管理器）和Apt（Debian的软件包管理器）对Helm进行设计。但随着Helm的成熟，我们已经尽可能多地借鉴不同的软件包管理器。

典型的操作系统和Kubernetes之间有一些区别。其中之一是Kubernetes支持运行同一应用程序的多个实例。虽然我可能只在工作站上安装了一次数据库MariaDB，但是Kubernetes集群可能会运行数十、数百甚至数千个MariaDB安装，其中每个安装都有不同的配置，甚至是不同的版本。

另一个在典型操作系统中很少见的概念是命名空间（namespace），但它是Kubernetes的核心。在Kubernetes中，命名空间是一种任意的分组机制，它定义了命名空间内部和外部事物之间的边界。使用命名空间组织资源有许多不同的方法，但通常它们被用作附加安全性的固定装置。例如，可能只有特定用户才能访问命名空间内的资源。

这些只是Kubernetes与传统操作系统不同的几个方面。这些差异和其他差异对Helm的设计提出了挑战。我们不得不构建Helm来充分利用这些差异，但同时又不放弃关于我们的软件包管理比喻。

例如，Helm安装命令不仅需要软件包的名称，还需要用户提供的名称，通过用户提供的该名称可以引用该软件包的已安装版本。在下一章中，我们将看到这样的例子。

同样，Helm中的操作也是区分命名空间的。可以将同一个应用程序安装到两个不同的命名空间中，Helm提供了管理这些不同应用程序的实例的工具。

不过，最终，Helm仍然稳居软件包管理类工具之列。

1.2.3　安全性、可重用性和可配置性

我们设计Helm的第三个目标是关注管理集群中应用程序的三个“必备条件”：

1.安全性

2.可重用性

3.可配置性

简而言之，我们想让Helm充分了解这些原则，以便Helm用户对他们使用的软件包有信心。用户应该验证（verify）一个软件包是否有可靠的来源（并且没有被篡改），多次重用（reuse）同一个软件包，并配置（configure）该软件包以满足他们的需求。

尽管Helm的开发人员可以直接控制前两个设计目标（易用和软件包管理），但第三个目标不一样：Helm只能为软件包作者提供正确的工具，以供这些创建者选择来实现这三个“必备条件”。

安全性

安全性是一个广泛的范畴。不过此处我们指的是这样一种想法，当用户检查某个软件包时，用户有能力验证软件包的某些内容：

·软件包来源可靠。

·拉取软件包的网络连接是安全的。

·软件包未被篡改。

·软件包易于检查，因此用户可以看到它的功能。

·用户可以看到软件包的配置，以及不同的输入如何影响软件包的输出。

在本书中，特别是在第6章中，我们将更详细地介绍安全性。但我们相信Helm已经提供了这5种能力。

Helm提供了一个provenance特性来验证软件包的来源、作者和完整性。Helm支持安全套接字层/传输层安全性（SSL/TLS），用于通过网络安全地发送数据。Helm提供了dry-run、template和linting（试运行、模板和代码校验）命令来检查包及其可能的排列。

可重用性

软件包管理的一个优点是它能够重复和可预测地安装相同的东西。在Helm中，这个想法得到了扩展：我们甚至可能希望将相同的东西（重复地和可预测地）安装到同一个集群中，甚至是集群中的同一个命名空间中。

Helm chart是可重用性的关键。chart提供了一种模式来生成相同的Kubernetes清单。但是chart也允许用户提供额外的配置（见第2章）。所以Helm提供了存储配置的模式，使得chart加上它的配置的组合甚至可以重复进行。

通过这种方式，Helm鼓励Kubernetes用户将他们的YAML打包成chart，以便这些描述可以重用。

在Linux世界中，每个Linux发行版都有自己的软件包管理器和存储库。Kubernetes的世界并非如此。Helm的构造使得所有Kubernetes发行版都可以共享相同的软件包管理器，并且（除了极少数例外）也可以共享相同的软件包。当两个不同的Kubernetes发行版之间存在差异时，chart可以使用模板（见第5章）和配置来适应这种情况。

可配置性

Helm提供了一个Helm chart模式，并提供了一些额外的配置。例如，我可能安装了一个带有Helm的网站，但希望（在安装时）设置该网站的名称。Helm提供了在安装时配置软件包的工具，以及在升级期间重新配置安装的工具。但要注意的一点是按照顺序。

Helm是一个软件包管理器。另一类软件处理配置管理。这类软件以Puppet、Ansible和Chef为代表，主要关注给定的软件（通常已打包）是如何针对其宿主环境进行特定配置的。它的职责是随时间的变化管理配置更改。

Helm并未被设计成配置管理工具，尽管软件包管理和配置管理之间有一些重叠。

软件包管理通常局限于实现三个动词：安装、升级和删除。配置管理是一个更高层次的概念，旨在随着时间的推移管理一个或多个应用程序。这有时被称为“第二天行动”（day-two ops）。

虽然Helm并不是一个配置管理工具，但有时会被用作配置管理工具。组织不仅依赖Helm来安装、升级和删除应用程序，还依赖Helm来跟踪随时间的变化、跟踪配置以及确定整个应用程序是否正在运行。Helm可以这样扩展，但是如果你想要一个强大的配置管理解决方案，可能需要利用Helm生态系统中的其他工具。许多工具（如Helmfile、Flux和Reckoner）都在更大的配置管理事项中填补了细节。

Helm社区创建了大量与Helm互操作或增强Helm的工具。Helm项目在官方文档（https://oreil.ly/hOqca）中保留了这些工具的清单。

在Helm chart中你会注意到的一个常见主题是，配置选项通常是设置好的，这样你就可以将同一个chart的最小版本发布到你的开发环境中，或者使用不同的配置选项将一个复杂的版本发布到你的生产环境中。