Helm的升级是指升级一个安装，而不是一个chart。
安装是集群中某个chart的特定实例。
运行helm install时，它将创建这个安装。要修改该安装，需使用helm upgrade。
升级安装可能包括两种不同的更改：
·升级chart的版本 ·升级此安装的配置
这两者不是相互排斥的，可以同时进行。
所以版本是安装的配置和chart版本的特定组合。
当我们第一次安装chart时，我们会创建安装的初始版本，称之为版本1。
当我们执行升级时，正在创建同一安装的新版本：版本2。
当再次升级时，我们将创建版本3。
在升级过程中，我们可以创建一个具有新配置、新chart版本或两者兼有的版本。
例如，假设我们在ingress（入口）关闭的情况下安装Drupal chart（这将有效地防止流量从集群外部路由到Drupal实例）。
注意，我们使用--set标志来演示，但在常规场景中建议使用values.yaml文件：
$ helm install mysite bitnami/drupal --set ingress.enabled=false
在ingress关闭的情况下，可以根据自己的喜好设置网站。准备好之后，就可以创建一个新的版本来启用ingress特性：
$ helm upgrade mysite bitnami/drupal --set ingress.enabled=true
在这种情况下，我们正在运行的upgrade只会更改配置。
在后台，Helm将加载chart，生成该chart中的所有Kubernetes对象，然后查看这些对象与已安装的chart的版本有何不同。它只会给Kubernetes发送需要更改的东西。换言之，Helm只会试图改变最少量的东西。
前面的示例只会更改ingress配置。数据库没有任何变化，甚至运行Drupal的Web服务器也没有任何变化。
因此，不会重新启动或删除并重新创建任何内容。
这有时会让Helm的新用户感到困惑，但这是特意设计的。
Kubernetes的哲学是以最精简的方式进行更改，Helm也是一样。
有时，你可能需要强制某个服务重新启动。
你不需要用Helm去实现，可以简单地使用kubectl本身来重启它。
对于操作系统的软件包管理器，你不能使用软件包管理器重新启动程序。
同样，你不需要使用Helm来重新启动Web服务器或数据库。
当chart的新版本出现时，你可能需要升级现有安装以使用新的chart版本。在很大程度上，Helm试图让这变得简单：
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repositoryUpdate Complete. Happy Helming!
$ helm upgrade mysite bitnami/drupal
helm repo update 从chart存储库获取最新的软件包。
helm upgrade mysite bitnami/drupal 升级mysite版本以使用最新版本的bitnami/drupal。
如你所见，Helm的默认策略是尝试使用最新版本的chart。如果你希望保留chart的特定版本，可以显式声明：
$ helm upgrade mysite bitnami/drupal --version 6.2.22
在这种情况下，即使发布了更新的版本，也只会安装bitnaim/drupal版本6.2.22。
配置值和升级
关于Helm的安装和升级，需要了解的最重要的一点是，在每个版本中都会应用新的配置。下面是一个简单的例子：
# 使用配置文件安装
$ helm install mysite bitnami/drupal --values values.yaml
# 不带配置文件的升级
$ helm upgrade mysite bitnami/drupal
这一对操作的结果是什么？
安装将使用values.yaml中提供的所有配置数据，但升级不会。
因此，某些设置可能会更改回其默认值。这通常不是你想要的。
可以使用helm get values mysite查看上次helm install或helm upgrade操作中使用的值。
Helm核心维护人员建议在每次安装和升级时提供一致的配置。要对两个发布版本应用相同的配置，可在每个操作上都提供值：
# 使用配置文件安装。
$ helm install mysite bitnami/drupal --values values.yaml
# 使用相同的配置文件升级。
$ helm upgrade mysite bitnami/drupal --values values.yaml
建议将配置存储在一个values.yaml文件中，以便很容易复制这个模式。
想象一下，如果使用--set来设置三个或四个配置参数，对于每个版本，都必须准确地记住要设置哪些内容，会有多麻烦！
虽然强烈建议使用这里讨论的模式，并每次指定--values，但是有一个升级快捷方式可以重用你发送的最后一组值：
$ helm upgrade mysite bitnami/drupal --reuse-values
--reuse values标志 (re use values)将告诉Helm重新加载最后一组值的服务器端副本，然后使用这些值生成升级。
如果总是重复使用相同的值，那么这个方法是可以的。
但是，Helm维护人员强烈建议不要尝试将--reuse-values与其他--set或--values选项混合使用。
因为没有人知道这个安装的某些配置参数是如何设置的，这样做会使故障排除变得复杂，并很快导致无法维护的安装，
虽然Helm确实保留了一些状态信息，但它不是一个配置管理工具。建议用户使用自己的工具管理配置，并在每次调用中显式地将配置传递给Helm。
卸载安装
要删除某个Helm安装，可使用helm uninstall命令：
helm uninstall mysite
注意，这个命令不需要chart名（bitnami/drupal）或任何配置文件。
它只需要安装的名称。
我们将了解删除是如何工作的，并简要介绍一下Helm 2和Helm 3之间的重大变化。
与install、list和upgrade类似，可以提供--namespace标志来指定要从特定命名空间中删除安装
helm uninstall mysite --namgespace first
前面的命令将删除之前first命名空间中创建的站点。
注意，没有命名可以删除多个应用程序，要想删除多个应用程序，必须卸载特定安装。
删除需要时间。大型应用程序可能需要几分钟甚至更长时间，因为Kubernetes会清理所有资源。在此期间，将无法使用相同的名称重新安装。
Helm如何存储发布信息
Helm 3的一个重大变化是删除Helm自己关于安装的数据的方式。
当第一次用Helm安装chart时（比如用helm install mysite bitnami/drupal），创建了Drupal应用程序实例，并且还创建了一个包含发布版本信息的特殊记录。
默认情况下，Helm将这些记录存储为Kubernetes Secret（尽管还有其他受支持的存储后端）。
可以用kubectl get secret看到这些记录：
kubectl get secret
可以在列表底部看到多个版本记录，每个版本一个。
如图通过运行install和upgrade操作创建了mysite的4个修订版本。
可以使用这些扩展记录回滚到以前的安装版本
运行helm uninstall mysite命令将加载mysite安装的最新版本记录。
从该记录中，它将汇集一个应该从Kubernetes中移除的对象列表。然后Helm将删除所有这些内容，最后返回并删除4个版本的记录：
$ helm uninstall mysite
release "mysite" uninstalled
helm list命令将不再显示mysite：
现在没有安装了。如果重新运行kubectl get secrets命令，还会看到mysite的所有记录都被清除了：
可以看到，不仅Drupal chart创建的两个Secret被删除了，而且4个发布记录也被删除了。
可以删除应用程序，但会保留发布记录：
$ helm uninstall --keep-history
在Helm 2中，历史记录被默认保留。在Helm 3中，默认值更改为删除历史记录。
不同的组织喜欢不同的策略，但是核心维护人员发现，大多数人在执行卸载时希望所有安装痕迹都被销毁。
