2.6　升级安装

当我们在Helm中谈论升级时，谈论的是升级一个安装，而不是一个chart。安装是集群中某个chart的特定实例。运行helm install时，它将创建这个安装。要修改该安装，需使用helm upgrade。

目前，这是一个重要的区别，因为升级安装可能包括两种不同的更改：

·升级chart的版本

·升级此安装的配置

这两者不是相互排斥的，可以同时进行。但这确实引入了Helm用户在谈论他们的系统时提到的一个新术语：版本是安装的配置和chart版本的特定组合。

当我们第一次安装chart时，我们会创建安装的初始版本，称之为版本1。当我们执行升级时，正在创建同一安装的新版本：版本2。当再次升级时，我们将创建版本3（在下一章中，我们将看到回滚如何创建版本）。

在升级过程中，我们可以创建一个具有新配置、新chart版本或两者兼有的版本。

例如，假设我们在ingress（入口）关闭的情况下安装Drupal chart（这将有效地防止流量从集群外部路由到Drupal实例）。

注意，我们使用--set标志来保持示例的紧凑性，但在常规场景中建议使用values.yaml文件：

在ingress关闭的情况下，我们可以根据自己的喜好设置网站。准备好之后，我们可以创建一个新的版本来启用ingress特性：

在这种情况下，我们正在运行的upgrade只会更改配置。

在后台，Helm将加载chart，生成该chart中的所有Kubernetes对象，然后查看这些对象与已安装的chart的版本有何不同。它只会给Kubernetes发送需要更改的东西。换言之，Helm只会试图改变最少量的东西。

前面的示例只会更改ingress配置。数据库没有任何变化，甚至运行Drupal的Web服务器也没有任何变化。因此，不会重新启动或删除并重新创建任何内容。这有时会让Helm的新用户感到困惑，但这是特意设计的。Kubernetes的哲学是以最精简的方式进行更改，Helm试图遵循这一哲学。

有时，你可能需要强制某个服务重新启动。你不需要用Helm去实现，可以简单地使用kubectl本身来重启它。对于操作系统的软件包管理器，你不能使用软件包管理器重新启动程序。同样，你不需要使用Helm来重新启动Web服务器或数据库。

当chart的新版本出现时，你可能需要升级现有安装以使用新的chart版本。在很大程度上，Helm试图让这变得简单：

❶　从chart存储库获取最新的软件包。

❷　升级mysite版本以使用最新版本的bitnami/drupal。

如你所见，Helm的默认策略是尝试使用最新版本的chart。如果你希望保留chart的特定版本，可以显式声明：

在这种情况下，即使发布了更新的版本，也只会安装bitnaim/drupal版本6.2.22。

2.6.1　配置值和升级

关于Helm的安装和升级，需要了解的最重要的一点是，在每个版本中都会应用新的配置。下面是一个简单的例子：

❶　使用配置文件安装。

❷　不带配置文件的升级。

这一对操作的结果是什么？安装将使用values.yaml中提供的所有配置数据，但升级不会。因此，某些设置可能会更改回其默认值。这通常不是你想要的。

检查值

在下一章中，我们将研究helm get命令。你可以使用helm get values mysite查看上次helm install或helm upgrade操作中使用的值。

Helm核心维护人员建议你在每次安装和升级时提供一致的配置。要对两个发布版本应用相同的配置，可在每个操作上都提供值：

❶　使用配置文件安装。

❷　使用相同的配置文件升级。

我们建议将配置存储在一个values.yaml文件中，以便很容易复制这个模式。想象一下，如果你使用--set来设置三个或四个配置参数，这些命令会有多麻烦！对于每个版本，你必须准确地记住要设置哪些内容。

虽然我们强烈建议使用这里讨论的模式，并每次指定--values，但是有一个升级快捷方式可以重用你发送的最后一组值：

--reuse values标志将告诉Helm重新加载最后一组值的服务器端副本，然后使用这些值生成升级。如果你总是重复使用相同的值，那么这个方法是可以的。但是，Helm维护人员强烈建议不要尝试将--reuse-values与其他--set或--values选项混合使用。这样做会使故障排除变得复杂，并很快导致无法维护的安装，因为没有人知道这个安装的某些配置参数是如何设置的。虽然Helm确实保留了一些状态信息，但它不是一个配置管理工具。建议用户使用自己的工具管理配置，并在每次调用中显式地将配置传递给Helm。

现在，我们已经学习了如何安装、列出和升级安装。在本章的最后一节中，我们将删除一个安装。