2 使用Helm
Helm 提供了一个名为 helm 的命令行工具，它提供了使用 Helm chart 所需的所有特性。在本章中，我们将探索helm客户端的主要特性，并了解 Helm 如何与Kubernetes 交互。
我们将从了解如何安装和配置 Helm 开始，并通过 Helm 中的主要命令组进行工作。然后我们将介绍如何查找和学习软件包，以及如何安装、升级和删除它们。
2.1 安装和配置Helm客户端
Helm 提供了一个能够执行所有 Helm 任务的命令行客户端：helm。虽然还有许多其他工具可以使用 Helm chart ，但这是由 Helm 核心维护人员维护的官方通用工具，也是本章和下一章的主题。
helm 客户端是用 Go 语言编写的。与 Python、JavaScript 和 Ruby 不同，Go 是一种编译语言。一旦编译了 Go 程序，就不需要任何 Go 工具来运行或以其他方式处理二进制文件。
因此，我们将首先介绍下载和安装静态二进制文件，然后简要介绍获取和编译 Go 源代码的过程。
2.1.1 安装预构建的二进制文件
每次 Helm 维护人员发布新版本的 helm 时，项目都会为许多常见的操作系统和架构提供新的 helm 签名二进制版本。在撰写本书时，可以在64位Intel/AMD、ARM、s390 和 PPC 等架构上为 Linux、Windows 和 macOS 操作系统提供预构建版本的 Helm。这意味着你可以在从树莓派到超级计算机的任何机器上运行Helm。
Helm 发布的最终列表在 Helm 发布页面（https://github.com/helm/helm/releases）。发布页面将显示按时间顺序排列的发布列表，最新版本位于顶部。
2.1.1.1 关于Helm版本号
直到 2020 年 11 月，两个不同的主要版本的 Helm 都被积极维护。目前稳定的是 Helm 3 。当你访问 Helm 下载页面时，可能会看到两个版本都可以下载。因为版本是按时间顺序列出的，所以一个 Helm 2 版本甚至有可能比最新的 Helm 3 版本还新。但你应该使用 Helm 3。
Helm 遵循一种称为语义版本管理（SemVer）
（https://semver.org）的版本管理约定。在语义版本管理中，版本号表示你能期望在发行版中获得的内容。因为 Helm 遵循该规范，所以用户只需仔细阅读版本号就可以从发行版中获得特定的东西。
语义版本的核心是三个数字部分和一个可选的稳定性标记（stability marker）（用于alpha、beta和候选版本）。
以下是一些示例：
- v1.0.0
- v3.3.2
- v2.4.22-alpha.2
我们先来讨论数字部分。
- 我们经常将这种格式概括为 X.Y.Z，其中 X 是主版本（majorversion），Y是次要版本（minor version），Z是补丁版本（patchrelease）：
- 主版本号往往很少增加。它表明对 Helm 进行了重大更改，其中一些更改可能会破坏与以前版本的兼容性。Helm 2 和 Helm 3 之间的差别很大，需要在两个版本之间进行迁移。
- 次要版本号表示新增功能。3.2.0 和 3.3.0之间的区别可能是添加了一些小的新特性。但是，版本之间没有突破性的修改（breakingchange）。有一个警告：一个安全修复可能需要一个突破性的修改，但在这种情况下，我们会强调指出。
- 补丁版本号表示在这个版本和上一个版本之间只进行了向后兼容的 bug 修复。建议始终保持最新的补丁版本。当你看到一个版本在版本号后面附加了一个稳定性标记（如 alpha.1、beta.4 或 rc.2 ）时，这意味着该版本被认为是一个预发布版本，还没有准备好用于主流生产。特别是，Helm 经常在主要或次要更新之前发布候选版本。在发布最终版本之前，社区有机会就稳定性、兼容性和新特性向我们提供一些反馈。记住这一点，我们准备继续实际的安装。
2.1.1.2 安装二进制版本
从存储库安装Helm最简单的方法就是进入发布页面（https://github.com/helm/helm/releases）并下载最新的Helm 3版本。
- 在 Windows 上，下载文件是包含 README.md 文本文件、LICENSE 文本和helm.exe的ZIP压缩包。
- 在 macOS 和 Linux 上，下载的是一个 gzip tar 压缩包（.tar.gz)，它可以用 tar-zxf 命令提取。与 Windows 版本一样，它将包含 README.md 文本文件、LICENSE 文本文件和 helm 二进制文件。
- 如果你使用的是 Windows Subsystem for Linux（WSL），那么应该将 Linux AMD64版本安装到 WSL 实例中。
无论你使用哪种操作系统，二进制文件都是运行 Helm 所需的唯一文件，你可以将其放置在系统中你喜欢的任何位置。它应该被预先标记为可执行文件，但是在类似 UNIX 的环境中，在很少的情况下，你可能还需要运行 chmod helm+x 命令来将 Helm 设置为可执行文件。
1 下载安装包，由于我这里是 Linux amd64 架构所以下载对应的 helm 3.5.0 amd64 版本
root@master:~# wget https://get.helm.sh/helm-v3.5.0-linux-amd64.tar.gz
2 解压
root@master:~# tar xf helm-v3.5.0-linux-amd64.tar.gz
# 解压之后的目录结构
root@master:~# ll linux-amd64/
total 38836
drwxr-xr-x 2 3434 3434 4096 Jan 14 2021 ./
drwx------ 9 root root 4096 Apr 19 22:13 ../
-rwxr-xr-x 1 3434 3434 39743488 Jan 14 2021 helm* # 可以看到这个是一个二进制程序
-rw-r--r-- 1 3434 3434 11373 Jan 14 2021 LICENSE
-rw-r--r-- 1 3434 3434 3367 Jan 14 2021 README.md
3 移动 helm 至 bin 目录
root@master:~# cp linux-amd64/helm /usr/local/bin/
# 查看 helm 命令，是先安装
root@master:~# helm version
version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}
如果能够通过 helm version 命令查看到当前 helm 版本信息，并无报错就说明当前 helm 可以提供对外使用，当然在使用 helm 之前我们还需要对接 K8S 集群。
2.1.2 使用Kubernetes集群
Helm 直接与 kubernetes API 服务器交互。
因此，Helm 需要能够连接到 Kubernetes 集群。Helm 试图通过读取 kubectl（主Kubernetes命令行客户端）使用的相同配置文件来自动完成这一任务。
Helm 将尝试通过读取环境变量 $KUBECONFIG 来查找此信息。如果没有设置此环境变量，它将在与 kubectl 相同的默认位置中查找（例如，在 UNIX、Linux 和 macOS上，$HOM 你还可以使用环境变量（HELM_KUBECONTEXT）和命令行标志（--kube-context）覆盖这些设置。运行 helm help 可以看到环境变量和标志的列表。
Helm 维护人员建议使用 kubectl 来管理 Kubernetes 凭据，让 Helm 只自动检测这些设置。如果你还没有安装 kubectl ，最好从 Kubernetes 的官方安装文档（https://kubernetes.io/docs/tasks/tools/）开始
现在我们已经部署好了 helm 所以在下面的内容中，我们将了解从 Helm 开始的最常见的工作流程：
- 添加 chart 存储库。
-
查找要安装的 chart 。
-
安装 Helm chart 。
-
查看安装内容列表。
-
升级安装。
-
删除安装。
在下一章中，我们将深入了解 Helm 的一些附加功能，并在此过程中进一步了解 Helm 的工作原理。
2.2 添加chart存储库
chart 存储库本身就是一个宏大的主题。但是任何使用 Helm 的人都必须知道一些关于 chart 存储库的基本知识。
Helm chart 是一个单独的软件包，可以安装到 Kubernetes 集群中。在 chart 开发过程中，通常只使用存储在本地文件系统中的chart。
但当谈到共享 chart 时，Helm 描述了一种标准格式，用于索引和共享有关 Helm chart 的信息。Helm chart 存储库只是一组可通过网络访问、符合 Helm 规范的文件。
Helm 3 引入了一个实验特性，用于将 Helm chart 存储在不同类型的存储库中：Open Container Initiative（OCI）注册中心（有时称为 Docker 注册中心）。在这个后端，一个 Helm chart 可以存储在 Docker 镜像旁边。
虽然这个功能还没有得到广泛的支持，但它可能会成为 Helm 软件包存储的未来。
在因特网上有许多（可能数千个）chart 存储库。找到流行存储库的最简单方法是使用Web浏览器导航到ArtifactHub（https://artifacthub.io）。在那里你会发现数以千计的 Helm chart ，每一个都托管在一个适当的存储库中。
首先，我们将安装流行的 Drupal 内容管理系统（https://www.drupal.org）。这是一个很好的示例 chart ，因为它使用了 Kubernetes 的许多类型，包括Deployment、Service、Ingress 和 ConfigMap（部署、服务、入口和配置映射）。Helm 2 默认安装了一个 Helm 存储库。stable chart 存储库曾一度是生产就绪的 Helm chart 的官方来源。但我们意识到，将 chart 集中到一个存储库对一小群维护人员来说任务过于繁重，而对 chart 贡献者来说则令人沮丧。
因此在 Helm 3 中没有默认的存储库。鼓励用户使用 Artifact Hub 来查找他们要查找的内容，然后添加他们首选的存储库。
Drupal 的 Helm chart 位于一个最完善的 chart 库中：Bitnami 的官方 Helm chart 。你可以查看 Artifact Hub 的 Drupal chart（https://artifacthub.io/packages/helm/bitnami/drupal）条目以获取更多信息。
1 使用 1helm repo add 命令添加 Helm chart 。几个 Helm 存储库命令被划分在 helm repo 命令组下：
# helm repo add 命令将添加一个名为 bitnami 的存储库，该存储库指向URL https://charts.bitnami.com/bitnami
root@master:~# helm repo add bitnami https://charts.bitnami.com/bitnami
2 现在，我们可以通过运行第二个 repo 命令来验证 Bitnami 存储库是否存在：
# 这个命令显示了为Helm安装的所有存储库。现在，我们只看到刚才添加的 Bitnami 存储库。
root@master:~# helm repo list
NAME URL
bitnami https://charts.bitnami.com/bitnami
一旦我们添加了一个存储库，它的索引就将被本地缓存，直到下次更新它。我们现在可以做的一件重要的事情就是搜索存储库。
2.3 搜索chart存储库
尽管我们已经了解了 Artifact Hub，知道 Drupal chart 存在于这个存储库中，但是从命令行搜索它仍然很有用。通常，搜索是一种有用的方法，不仅可以找到可以安装的 chart ，而且可以找到可用的版本
1 首先，搜索Drupal chart
root@master:~# helm search repo drupal
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/drupal 11.0.31 9.3.11 Drupal is one of the most versatile open source...
2 我们对 drupal 这个词做了一个简单的搜索。
# Helm 不仅会搜索包名，还会搜索标签和描述等其他字段。因此，我们可以搜索 content（内容） 并在那里看到 Drupal ，因为它是一个内容管理系统：
root@master:~# helm search repo content
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/drupal 11.0.31 9.3.11 Drupal is one of the most versatile open source...
bitnami/harbor 12.3.3 2.5.0 Harbor is an open source trusted cloud-native r...
bitnami/joomla 12.0.2 4.0.5 PHP content management system (CMS) for publish...
bitnami/mongodb 10.31.5 4.4.11 NoSQL document-oriented database that stores JS...
bitnami/mongodb-sharded 3.12.0 4.4.11 NoSQL document-oriented database that stores JS...
bitnami/nginx 10.1.1 1.21.6 NGINX Open Source is a web server that can be a...
bitnami/owncloud 11.0.25 10.9.1 ownCloud is an open source content collaboratio...
bitnami/wordpress 13.3.0 5.9.3 WordPress is the world's most popular blogging ...
虽然 Drupal 是第一个结果，但请注意，还有许多其他 chart，它们在描述性文本中的某个地方，包含单词 content。
3 指定查看 chart 版本
# 默认情况下，Helm 尝试安装 chart 的最新稳定版本，但是你可以覆盖此行为并安装 chart 的特定版本。如此，我们不仅可以查看 chart 的摘要信息，还可以查看chart 的确切版本：
root@master:~# helm search repo drupal --versions
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/drupal 11.0.31 9.3.11 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.30 9.3.11 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.29 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.28 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.27 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.26 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.25 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.24 9.3.9 Drupal is one of the most versatile open source...
bitnami/drupal 11.0.23 9.3.9 Drupal is one of the most versatile open source...
.......省略......
Drupal chart 有几十个版本。前面的示例已被截断，仅显示前几个版本。
注意：chart 版本和应用程序版本
chart 版本是 Helm chart 的版本。应用程序版本是打包在 chart 中的应用程序的版本。Helm 使用 chart 版本来进行版本控制决策，比如哪个软件包是最新的。正如我们在前面的示例中看到的，多个 chart 版本可能包含相同的应用程序版本。
2.4 安装程序包
在这个章节中，我们将深入探讨如何在 Helm 中安装软件包的细节。不过，在本节中，我们将了解安装 Helm chart 的基本机制。
在 Helm 中安装 chart 至少需要两条信息：安装的名称和要安装的 chart。
回想一下，在上一章中，我们区分了安装（installation）和 chart 。这是安装和升级期间的一个重要区别。在操作系统软件包管理器中，我们可以请求它安装一个软件。
但在一个操作系统上，我们需要多次安装同一个软件包的情况极为罕见。Kubernetes 集群是不同的。在 Kubernetes 中说“我想为应用程序 A 安装一个 MySQL 数据库，为应用程序 B 安装第二个 MySQL 数据库”是完全有意义的。即使这两个数据库的版本完全相同，配置也完全相同，为了适当地管理应用程序，我们可能希望有两个实例运行。因此，Helm 需要一种方法来区分同一 chart 的不同实例。
因此，chart 的 installation 是 chart 的一个特定实例。一个 chart 可能有许多 installation 。当我们运行 helm install 命令时，我们需要给它指定一个installation 名和 chart 名。所以最基本的 installation 命令如下：
1 安装 drupal 应用
# helm install mysite bitnami/drupal 该命令将创建bitnami/drupal chart的一个实例，并将这个实例命名为 mysite
root@master:~# helm install mysite bitnami/drupal
NAME: mysite
LAST DEPLOYED: Tue Apr 19 22:49:13 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: drupal
CHART VERSION: 11.0.31
APP VERSION: 9.3.11** Please be patient while the chart is being deployed **
1. Get the Drupal URL:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w mysite-drupal'
export SERVICE_IP=$(kubectl get svc --namespace default mysite-drupal --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
echo "Drupal URL: http://$SERVICE_IP/"
2. Get your Drupal login credentials by running:
echo Username: user
echo Password: $(kubectl get secret --namespace default mysite-drupal -o jsonpath="{.data.drupal-password}" | base64 --decode)
在 install 命令运行时，它将返回大量信息，包括有关开始使用 Drupal 的面向用户的说明。
在以后的 helm install 示例中，为了简洁起见，我们将省略返回的输出。但是，当使用 Helm 时，你将看到每个安装的输出。在下一章中，我们还将看到如何使用helm get 命令再次查看该输出。
此时，集群中现在有一个名为 mysite 的实例。如果我们尝试重新运行前面的命令，就不会得到第二个实例。相反，我们会得到一个错误，提示因为名称 mysite 已经被使用：
2 再次安装 drupal 应用，并取名为 mysite ，验证报错
root@master:~# helm install mysite bitnami/drupal
Error: cannot re-use a name that is still in use # 提示 name 已经被使用
需要进一步澄清。在 Helm 2 中，实例名是集群范围的。每个集群只能有一个名为 mysite 的实例。在Helm 3中，命名规则已经改变。现在实例名称的作用域是Kubernetes 命名空间。我们可以安装两个名或多个为 mysite 的实例，只要它们各自位于不同的命名空间中即可。
例如，以下内容在 Helm 3 中是完全合法的，尽管它会在 Helm 2 中引发致命错误：
3 创建两个不同 NS ，并安装同名的 helm 实例
# 创建 first ns
root@master:~# kubectl create ns first
# 创建 second ns
root@master:~# kubectl create ns second
# 安装 mysite 实例到 first NS 下
root@master:~# helm install --namespace first mysite bitnami/drupal
# 安装 mysite 实例到 second NS 下
root@master:~# helm install --namespace second mysite bitnami/drupal
# 这将在第一个命名空间中安装一个名为 mysite 的 Drupal 站点，在第二个命名空间中安装一个相同配置的名为 mysite 的实例。这一点开始可能会让人困惑，但当我们将命名空间看作名称的前缀（prefixon a name）时，情况就更清楚了。从这个意义上说，我们有一个名为 “first mysite” 的网站和另一个名为 “second mysite” 的网站。
4 查看部署好的两个 mysite 实例
root@master:~# helm list -n first
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite first 1 2022-04-19 22:55:03.525279588 +0800 CST deployed drupal-11.0.31 9.3.11
root@master:~# helm list -n second
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite second 1 2022-04-19 22:57:05.950712583 +0800 CST deployed drupal-11.0.31 9.3.11
# 由此发现我们可以在不同的 NS 中部署 name 相同的 helm 实例
注意：在整个 Helm 中使用命名空间标志
使用命名空间和 Helm 时，可以使用 --namespace 或 -n 标志指定所需的命名空间。
2.4.1 安装时的配置
在前面的示例中，我们以几种不同的方式安装了相同的 chart 。在所有情况下，它们的配置都是相同的。虽然使用默认配置有时是不错的，但更多的时候我们希望将自己的配置传递给 chart。
许多 chart 允许你提供配置值。如果我们看看 Drupal 的 Artifact Hub 页面（https://artifacthub.io/packages/helm/bitnami/drupal），就会看到一长串可配置参数。
例如，我们可以通过设置 drupalUsername 值来配置 Drupal 管理员账户的用户名。
在下一章中，我们将学习如何使用 helm 命令获取这些信息。
有几种方法可以告诉 Helm 要配置哪些值。最好的方法是创建一个包含所有配置覆盖值的 YAML 文件。例如，我们可以创建一个文件来设置 drupalUsername 和drupalEmail 的值：
1 编写 values.yaml文件
# 现在我们有一个文件（按惯例命名为 `values.yaml` ），它拥有我们所有的配置。因为它在一个文件中，所以很容易复制相同的安装。你还可以将此文件签入版本控制系统，以跟踪随时间变化的值。Helm 核心维护人员认为将配置值保存在 YAML 文件中是一种很好的做法。但是，请务必记住，如果配置文件中包含敏感信息（如口令或身份验证令牌），则应采取措施确保这些信息不会泄漏。
root@master:~# vim values.yaml
drupalUsername: admin
drupalEmaill: admin@example.com
2 指定创建 mysite 实例，并通过 values.yaml 文件赋值给该实例
# helm install 和 helm upgrade 都提供了一个 --values 标志，它指向具有覆盖值的 YAML 文件
# 查看当前用邮件 mysite 实例
root@master:~# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite default 1 2022-04-19 22:49:13.274549143 +0800 CST deployed drupal-11.0.31 9.3.11
# 因为在上面的示例中我创建了一个 mysite 的实例，所以这里需要将其删除
root@master:~# helm delete mysite
release "mysite" uninstalled
# 创建 mystie 实例并指定 values.yaml 文件生成对应的配置值
root@master:~# helm install mysite bitnami/drupal --values values.yaml
注意：在前面的输出中，Username（用户名）现在是 admin 而不是 user 。Helm 的一个很好的特性是甚至可以使用你提供的值来更新帮助文本。
3 指定 --set 参数对 helm 实例创建时赋值，而非使用 yaml 文件
# --set 标志直接接受一个或多个值。它们不需要存储在YAML文件中：
# 这只设置了 drupalUsername 这一个参数。此标志使用简单的 key=value 格式。
root@master:~# helm install mysite-v2 bitnami/drupal --set drupalUsername=admin
NAME: mysite-v2
LAST DEPLOYED: Tue Apr 19 23:13:23 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: drupal
CHART VERSION: 11.0.31
APP VERSION: 9.3.11** Please be patient while the chart is being deployed **
1. Get the Drupal URL:
NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w mysite-v2-drupal'
export SERVICE_IP=$(kubectl get svc --namespace default mysite-v2-drupal --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
echo "Drupal URL: http://$SERVICE_IP/"
2. Get your Drupal login credentials by running:
echo Username: admin
echo Password: $(kubectl get secret --namespace default mysite-v2-drupal -o jsonpath="{.data.drupal-password}" | base64 --decode)
注意：通过上面两种方式不管是使用 yaml 文件还是使用 --set 参数，我们都可以对需要创建的 helm 实例指定对应的赋值
配置参数可以结构化。也就是说，一个配置文件可以有多个部分。例如，Drupal chart 具有特定于 MariaDB 数据库的配置。这些参数都分组到 mariadb 部分中。在前面的示例的基础上，我们可以覆盖 MariaDB 数据库名称，如下所示：
root@master:~/helm/values# vim values.yaml
drupalUsername: admin
drupalEmaill: admin@example.com
mariadb:
db:
name: "my-datebase"
# 我们可以在一个 yaml 文件中定义多个不同的值，来实现对 helm 实例的多个字段配置
如果使用 --set 参数就需要注意：
子部分要复杂一些。你将需要使用虚线表示法：--set mariadb.db.name=my-database。当设置多个值时，这可能会变得冗长
总结：
一般来说，Helm 核心维护人员建议将配置存储在 values.yaml 文件中（注意，文件名不一定是“values”），仅在绝对必要时才使用 --set 。通过这种方式，你可以很容易地访问在操作期间使用的值（并且可以随着时间的推移跟踪这些值），同时还可以缩短 Helm 命令。使用文件还意味着不必像在命令行上设置内容时那样转义那么多字符。在继续介绍升级之前，我们先快速了解一条最有用的Helm命令。
2.5 列出安装实例
到目前为止，我们已经看到，Helm 可以在同一个集群中安装很多东西，甚至可以在同一个 chart 中安装多个实例。对于集群上的多个用户，不同的人可能会在集群上的同一命名空间中安装所需内容。
helm list 命令是一个简单的工具，可以帮助你查看安装并了解这些安装：
1 查看当前实例
# 此命令将为你提供许多有用的信息，包括版本的名称和命名空间、当前版本号（在第1章中讨论过，在下一节中将进行更深入的讨论）、上次更新的时间、安装状态以及chart和应用程序的版本。
root@master:~# helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite default 1 2022-04-19 23:08:03.036116391 +0800 CST deployed drupal-11.0.31 9.3.11
mysite-v2 default 1 2022-04-19 23:13:23.813982116 +0800 CST deployed drupal-11.0.31 9.3.11
2 查看 first NS 下的实例
# 与其他命令一样，helm list 是区分命名空间的。默认情况下，Helm 将 Kubernetes 配置文件设置的命名空间作为默认命名空间（通常名为 default ）。前面，我们在命名空间 first 中安装了一个 Drupal 实例。可以在 helm list__namespace first 中看到这一点。
root@master:~# helm list -n first
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite first 1 2022-04-19 22:55:03.525279588 +0800 CST deployed drupal-11.0.31 9.3.11
# 这里通过 -n 参数指定需要查看 NS
3 查看所有 NS 下的 helm 实例
root@master:~# helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mysite first 1 2022-04-19 22:55:03.525279588 +0800 CST deployed drupal-11.0.31 9.3.11
mysite second 1 2022-04-19 22:57:05.950712583 +0800 CST deployed drupal-11.0.31 9.3.11
mysite default 1 2022-04-19 23:08:03.036116391 +0800 CST deployed drupal-11.0.31 9.3.11
mysite-v2 default 1 2022-04-19 23:13:23.813982116 +0800 CST deployed drupal-11.0.31 9.3.11
# --all namespaces，它将查询你有权访问的所有 Kubernetes 命名空间，并返回找到的所有实例
2.6 升级安装
当我们在 Helm 中谈论升级时，谈论的是升级一个安装，而不是一个 chart 。安装是集群中某个 chart 的特定实例。运行 helm install 时，它将创建这个安装。要修改该安装，需使用 helm upgrade 。
目前，这是一个重要的区别，因为升级安装可能包括两种不同的更改：
- 升级chart的版本
- 升级此安装的配置
这两者不是相互排斥的，可以同时进行。但这确实引入了 Helm 用户在谈论他们的系统时提到的一个新术语：版本是安装的配置和 chart 版本的特定组合。
当我们第一次安装 chart 时，我们会创建安装的初始版本，称之为版本 1 。当我们执行升级时，正在创建同一安装的新版本：版本 2。当再次升级时，我们将创建版本3（在下一章中，我们将看到回滚如何创建版本）。
在升级过程中，我们可以创建一个具有新配置、新 chart 版本或两者兼有的版本。
例如，假设我们在 ingress（入口）网关，关闭的情况下安装 Drupalchart（这将有效地防止流量从集群外部路由到 Drupal 实例）。
注意，我们使用 –set 标志来保持示例的紧凑性，但在生产场景中建议使用values.yaml文件：
1 防止流量路由至部署的 Drupal 实例中：
root@master:~# helm install mysite bitnami/drupal --set ingress.enabled=false
# --set ingress.enabled=false 这是流量入口为 false
2 当我们对改应用初识话完成之后，需要暴露至外部访问
# 在 ingress 关闭的情况下，我们可以根据自己的喜好设置网站。准备好之后，我们可以创建一个新的版本来启用 ingress 特性：并提供给外部用户访问
root@master:~# 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 试图让这变得简单
2.6.1 升级 chart 仓库
1 从 chart 存储库获取最新的软件包。
root@master:~# helm repo update
2 指定 helm 实例升级至最新版本的 bitnami/drupal。
root@master:~# helm upgrade mysite bitnami/drupal
3 指定升级 helm 实例版本
# 这里是指定升级为 6.2.22 版本
# 在这种情况下，即使发布了更新的版本，也只会安装 bitnaim/drupal 版本6.2.22。
root@master:~# helm upgrade mysite bitnami/drupal --version 6.2.22