在Helm中安装chart至少需要两条信息：安装的名称和要安装的chart。
之前我们区分了安装（installation）和chart。
这是安装和升级期间的一个重要区别。
在操作系统软件包管理器中，我们可以请求它安装一个软件。
但在一个操作系统上，我们需要多次安装同一个软件包的情况极为罕见。
Kubernetes集群是不同的。在Kubernetes中说“我想为应用程序A安装一个MySQL数据库，为应用程序B安装第二个MySQL数据库”是完全有意义的。即使这两个数据库的版本完全相同，配置也完全相同，为了适当地管理应用程序，我们可能希望有两个实例运行。
因此，Helm需要一种方法来区分同一chart的不同实例。
因此，chart的installation是chart的一个特定实例。
一个chart可能有许多installation。
当我们运行helm install命令时，我们需要给它指定一个installation名和chart名。
所以最基本的installation命令如下：
前面的代码将创建bitnami/drupal chart的一个实例，并将这个实例命名为mysite。
在install命令运行时，它将返回大量信息，包括有关开始使用Drupal的面向用户的说明。
此时，集群中现在有一个名为mysite的实例。如果我们尝试重新运行前面的命令，就不会得到第二个实例。相反，我们会得到一个错误，因为名称mysite已经被使用：
$ helm install mysite bitnami/drupal
Error: cannot re-use a name that is still in use
在Helm 2中，实例名是集群范围的。每个集群只能有一个名为mysite的实例。
在Helm 3中，命名规则已经改变。现在实例名称的作用域是Kubernetes命名空间。
可以安装两个名为mysite的实例，只要它们各自位于不同的命名空间中即可。
例如，以下内容在Helm 3中是完全合法的，尽管它会在Helm 2中引发致命错误：
$ kubectl create ns first
$ kubectl create ns second
$ helm install --namespace first mysite bitnami/drupal
$ helm install --namespace second mysite bitnami/drupal
这将在第一个命名空间中安装一个名为mysite的Drupal站点，在第二个命名空间中安装一个相同配置的名为mysite的实例。
这一点一开始可能会让人困惑，但当我们将命名空间看作名称的前缀（prefix on a name）时，情况就更清楚了。
从这个意义上说，我们有一个名为“first mysite”的网站和另一个名为“second mysite”的网站。
安装时的配置
在前面的示例中，我们以几种不同的方式安装了相同的chart。
在所有情况下，它们的配置都是相同的。虽然使用默认配置有时是不错的，但更多的时候我们希望将自己的配置传递给chart。
许多chart允许提供配置值。
如果我们看看Drupal的Artifact Hub页面（oreil.ly/baxxf），就会看到一长串可配置参数。
例如，我们可以通过设置drupalUsername值来配置Drupal管理员账户的用户名。
有几种方法可以告诉Helm要配置哪些值。最好的方法是创建一个包含所有配置覆盖值的YAML文件。例如，我们可以创建一个文件来设置drupalUsername和drupalEmail的值：
drupalusername: admin
drupalEmail: admin@example.com
现在我们有一个文件（按惯例命名为values.yaml），它拥有我们所有的配置。
因为它在一个文件中，所以很容易复制相同的安装。
还可以将此文件签入版本控制系统，以跟踪随时间变化的值。
Helm核心维护人员认为将配置值保存在YAML文件中是一种很好的做法。
但是，请务必记住，如果配置文件中包含敏感信息（如口令或身份验证令牌），则应采取措施确保这些信息不会泄漏。
helm install和helm upgrade都提供了一个--values标志，它指向具有覆盖值的YAML文件：
注意，在前面的输出中，Username（用户名）现在是admin而不是user。
Helm甚至可以使用你提供的值来更新帮助文本。
可以多次指定--values标志。
有些人使用此功能以便在一个文件中具有“公共”覆盖，而在另一个文件中具有特定覆盖。
第二个标志可用于向安装或升级添加单个参数。
--set标志直接接受一个或多个值。它们不需要存储在YAML文件中：
$ helm install mysite bitnami/drupal --set drupalusername=admin
这只设置了drupalUsername这一个参数。此标志使用简单的key=value格式。
配置参数可以结构化。也就是说，一个配置文件可以有多个部分。
例如，Drupal chart具有特定于MariaDB数据库的配置。这些参数都分组到mariadb部分中。在前面的示例的基础上，我们可以覆盖MariaDB数据库名称，如下所示：
drupalusername: admin
drupalEmail: admin@example.com
mariadb:
db:
name: "my-database"
当使用--set标志时，子部分要复杂一些。你将需要使用虚线表示法：--set mariadb.db.name=my-database。当设置多个值时，这可能会变得冗长。
一般来说，Helm核心维护人员建议将配置存储在values.yaml文件中（注意，文件名不一定是“values”），仅在绝对必要时才使用--set。
通过这种方式，你可以很容易地访问在操作期间使用的值（并且可以随着时间的推移跟踪这些值），同时还可以缩短Helm命令。使用文件还意味着不必像在命令行上设置内容时那样转义那么多字符。
在继续介绍升级之前，我们先快速了解一条最有用的Helm命令。
列出你的安装
Helm可以在同一个集群中安装很多东西，甚至可以在同一个chart中安装多个实例。
对于集群上的多个用户，不同的人可能会在集群上的同一命名空间中安装所需内容。
helm list命令是一个简单的工具，可以帮助你查看安装并了解这些安装：
$helm list
此命令将提供许多有用的信息，包括版本的名称和命名空间、当前版本号、上次更新的时间、安装状态以及chart和应用程序的版本。
与其他命令一样，helm list是区分命名空间的。
默认情况下，Helm将Kubernetes配置文件设置的命名空间作为默认命名空间（通常名为default）。
前面，我们在命名空间first中安装了一个Drupal实例。可以在helm list -n first中看到这一点。
列出所有发行版时，一个有用的标志是--all namespaces，它将查询你有权访问的所有Kubernetes命名空间，并返回找到的所有发行版：
$ helm list --all-namespaces
