Helm简介 Helm是一个可简化Kubernetes应用程序安装和管理的工具。Helm可以理解为Kubernetes的apt/yum/homebrew。
此文档使用的是Helm 的v3版本。如果我们使用的是Helm v2，请转到helm-v2 分支。请参阅“Helm状态 ”以获取有关不同Helm版本的更多详细信息。
Helm状态 Helm v3于2019年11月发布。新老版本的接口非常相似，但是Helm的体系结构和内部架构发生了重大变化。有关更多详细信息，请查看Helm 3 中的内容。
Helm v2计划支持1年“维护模式”。它指出以下内容：
6个月的bug修复，直到2020年5月13日
6个月的安全修复，直到2020年11月13日
2020年11月13日开始，对Helm v2的支持将终止
为什么使用Helm Helm通常被称为Kubernetes应用程序包管理器。那么，使用Helm而不直接使用kubectl有什么好处呢？
目标 这些实验提供了关于使用Helm优于直接通过Kubectl使用Kubernetes的优势的见解。后续的几个实验都分为两种情况：第一种情况提供了如何使用kubectl执行任务的示例；第二种情况提供了使用Helm的示例。完成所有实验后，我们可以：
了解Helm的核心概念
了解使用Helm而非直接使用Kubernetes进行部署的优势：
应用管理
更新
配置
修订管理
储存库和Chart图表共享
前提
Helm概览 Helm是可简化Kubernetes应用程序安装和管理的工具。它使用一种称为“Chart”的打包格式，该格式是描述Kubernetes资源的文件的集合。它可以在任何地方（笔记本电脑，CI/CD等）运行，并且可用于各种操作系统，例如OSX，Linux和Windows。
Helm 3从Helm 2客户端-服务器架构 转向了客户端架构。客户端仍称为helm，并且有一个改进的Go库，该库封装了Helm逻辑，以便可以由不同的客户端使用。客户端是一个CLI，用户可以与它进行交互以执行不同的操作，例如安装/升级/删除等。客户端与Kubernetes API服务器和Chart存储库进行交互。它将Helm模板文件渲染为Kubernetes清单文件，用于通过Kubernetes API在Kubernetes集群上执行操作。有关更多详细信息，请参见Helm架构 。
Chart 被组织为目录内文件的集合，其中目录名是Chart的名称。它包含模板YAML文件，这些模板有助于在运行时提供配置值，并且无需修改YAML文件。这些模板基于Go模板语 言，Sprig lib 中的功能和其他专用功能 提供了编程逻辑。
Chart存储库是可以存储和共享打包的Chart的位置。这类似于Docker中的镜像存储库。有关更多详细信息，请参考《Chart存储库指南 》。
Helm概念 Helm术语：
Chart - 包含在Kubernetes集群中运行的应用程序，工具或服务所需的所有资源定义。Chart基本上是预先配置的Kubernetes资源的软件包。
Config - 包含可合并到Chart中以创建可发布对象的配置信息。
helm - helm客户端。它将Chart呈现为清单文件。它直接与Kubernetes API服务器交互以安装，升级，查询和删除Kubernetes资源。
Release - 在Kubernetes集群中运行的Chart实例。
Repository - 存储Chart的仓库，可以与他人共享。
Lab0 安装Helm 可以从源代码或预构建的二进制发行版中安装Helm客户端（helm）。在本实验中，我们将使用Helm社区的预构建二进制发行版（Linux amd64）。有关更多详细信息，请参阅Helm安装文档 。
前提依赖
安装Helm客户端
下载适用于环境的最新版本的Helm v3，以下步骤适用于Linux amd64，请根据环境调整示例。
解压：$ tar -zxvf helm-v3.<x>.<y>-linux-amd64.tgz。
在解压后的目录中找到helm二进制文件，并将其移至所需位置：mv linux-amd64/helm /usr/local/bin/helm。最好是将复制到的位置设置到path环境变量，因为它避免了必须对helm命令进行路径设置。
现在已安装了Helm客户端，可以使用helm help命令对其进行测试。
结论 现在可以开始使用Helm了。
Lab1 使用Helm部署应用 让我们研究一下Helm如何使用Chart来简化部署。我们首先使用kubectl将应用程序部署到Kubernetes集群，然后展示如何通过使用Helm部署同一应用程序。
该应用程序是Guestbook App ，它是一个多层级的Web应用程序。
场景1: 使用kubectl部署应用 在本部分的实验中，我们将使用Kubernetes客户端kubectl部署应用程序。使用该应用程序的版本1 进行部署。
如果已经从kube101 安装了guestbook应用程序，请跳过本节，转到场景2中的helm示例。
克隆Guestbook App存储库以获取文件：
1 git clone https://github.com/IBM/guestbook.git
使用克隆的Git库中的配置文件来部署容器，并使用以下命令为它们创建服务：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ cd guestbook/v1$ kubectl create -f redis-master-deployment.yaml deployment.apps/redis-master created $ kubectl create -f redis-master-service.yaml service/redis-master created $ kubectl create -f redis-slave-deployment.yaml deployment.apps/redis-slave created $ kubectl create -f redis-slave-service.yaml service/redis-slave created $ kubectl create -f guestbook-deployment.yaml deployment.apps/guestbook-v1 created $ kubectl create -f guestbook-service.yaml service/guestbook created
有关更多详细信息，请参阅README 。
查看guestbook：
现在，我们可以通过在浏览器中打开刚创建的留言簿来玩（可能需要一些时间才能显示出来）。
场景2: 使用Helm部署应用 在实验的这一部分，我们将使用Helm部署应用程序。我们将设置guestbook-demo的发行版名称，以使其与之前的部署区分开。可在此处 获得Helm chart。克隆Helm 101存储库以获取文件：
1 git clone https://github.com/IBM/helm101
Chart被定义为描述一组相关的Kubernetes资源的文件的集合。我们先查看文件，然后再安装。guestbook 的chart文件如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 . ├──Chart.yaml \\包含有关信息的YAML文件 ├──LICENSE \\许可证 ├──README.md \\帮助文档，提供有关chart用法，配置，安装等信息 ├──template \\模板目录，当与values.yaml结合使用时将生成有效的Kubernetes清单文件 │ ├──_helpers.tpl \\在整个chart中重复使用的模板帮助程序/定义 │ ├──guestbook-deployment.yaml \\ Guestbook应用程序容器资源 │ ├──guestbook-service.yaml \\ Guestbook应用服务资源 │ ├──NOTES.txt \\一个纯文本文件，包含有关如何在安装后访问应用程序的简短使用说明 │ ├──redis-master-deployment.yaml \\ Redis主容器资源 │ ├──redis-master-service.yaml \\ Redis主服务资源 │ ├──redis-slave-deployment.yaml \\ Redis从属容器资源 │ └──redis-slave-service.yaml \\ Redis从属服务资源 └──values.yaml \\chart的默认配置值
注意：上面显示的模板文件将被传递到Kubernetes清单文件中，然后再传递给Kubernetes API服务器。因此，它们映射到我们在使用kubectl时部署的清单文件（不包含README和NOTES）。
让我们继续并立即安装chart。如果helm-demo命名空间不存在，则需要使用以下命令创建它：
1 kubectl create namespace helm-demo
将应用程序作为Helm chart安装：
1 2 3 4 5 $ cd helm101/charts$ helm install guestbook-demo ./guestbook/ --namespace helm-demo NAME: guestbook-demo ...
我们应该看到类似于以下内容的输出：
1 2 3 4 5 6 7 8 9 10 11 12 NAME: guestbook-demo LAST DEPLOYED: Mon Feb 24 18:08:02 2020 NAMESPACE: helm-demo STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. You can watch the status of by running 'kubectl get svc -w guestbook-demo --namespace helm-demo' export SERVICE_IP=$(kubectl get svc --namespace helm-demo guestbook-demo -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo http://$SERVICE_IP:3000
该chart的安装将执行Redis主服务器和从服务器以及guestbook应用的Kubernetes部署和服务创建。这是因为该chart是描述一组相关的Kubernetes资源的文件的集合，并且Helm通过Kubernetes API管理这些资源的创建。
查看部署状态：
1 2 3 $ kubectl get deployment guestbook-demo --namespace helm-dem NAME READY UP-TO-DATE AVAILABLE AGE guestbook-demo 2/2 2 2 51m
查看pod状态：
1 2 3 4 5 6 7 $ kubectl get pods --namespace helm-demo NAME READY STATUS RESTARTS AGE guestbook-demo-6c9cf8b9-jwbs9 1/1 Running 0 52m guestbook-demo-6c9cf8b9-qk4fb 1/1 Running 0 52m redis-master-5d8b66464f-j72jf 1/1 Running 0 52m redis-slave-586b4c847c-2xt99 1/1 Running 0 52m redis-slave-586b4c847c-q7rq5 1/1 Running 0 52m
查看service状态：
1 2 3 4 5 $ kubectl get services --namespace helm-demo NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE guestbook-demo LoadBalancer 172.21.43.244 <pending> 3000:31367/TCP 52m redis-master ClusterIP 172.21.12.43 <none> 6379/TCP 52m redis-slave ClusterIP 172.21.176.148 <none> 6379/TCP 52m
查看留言簿：
现在，我们可以通过在浏览器中打开刚创建的留言簿来玩（可能需要一些时间才能显示出来）。
在这种情况下，URL为http://50.23.5.136:31367。
注意：如果未分配外部IP，则可以使用以下命令获取外部IP：
1 2 3 $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME 10.47.122.98 Ready <none> 1h v1.10.11+IKS 173.193.92.112 Ubuntu 16.04.5 LTS 4.4.0-141-generic docker://18.6.1
- 在这种情况下，URL为`http://173.193.92.112:31367`。在浏览器中导航到给定的输出（例如`http://50.23.5.136:31367`）。应该看到浏览器显示如下：
结论 恭喜，我们现在已经通过两种不同的方法将应用程序部署到Kubernetes。从本实验中，我们可以看到，与使用kubectl相比，使用Helm所需的命令更少，思考的时间也更少（通过提供chart路径而不是单个文件）。 Helm的应用程序管理为用户提供了这种简单性。
Lab2 使用Helm更新应用 在Lab1中，我们使用Helm安装了guestbook示例应用程序，并看到了相较于kubectl的优势。我们可能认为自己已经足够了解使用Helm。但是chart的更新或修改呢？我们如何更新和修改正在运行的应用？
在本实验中，我们将研究chart更改后如何更新正在运行的应用程序。为了说明这一点，我们将通过以下方式对原始留言簿的chart进行更改：
删除Redis从节点并改为仅使用内存数据库
将类型从LoadBalancer更改为NodePort
虽然是修改，但是本实验的目的是展示如何使用Kubernetes和Helm更新应用。那么，这样做有多容易呢？让我们继续看看。
场景1: 使用kubectl更新应用 在本部分的实验中，我们将直接使用Kubernetes更新以前部署的应用程序Guestbook 。
这是一个可选步骤，从技术上讲，更新正在运行的应用程序不是必需的。进行此步骤的原因是“整理”-我们要为已部署的当前配置获取正确的文件。这样可以避免在以后进行更新甚至回滚时犯错误。在此更新的配置中，我们删除了Redis从节点。要使目录与配置匹配，请移动/存档或仅从来文件夹中删除Redis从属文件：
1 2 3 cd guestbook/v1 rm redis-slave-service.yaml rm redis-slave-deployment.yaml
注意：如果需要，可以稍后使用git checkout-命令来还原这些文件。
删除Redis从节点的Service和Pod：
1 2 3 4 $ kubectl delete svc redis-slave --namespace default service "redis-slave" deleted $ kubectl delete deployment redis-slave --namespace default deployment.extensions "redis-slave" deleted
将Guestbook服务的yaml从LoadBalancer更新为NodePort类型：
1 sed -i.bak 's/LoadBalancer/NodePort/g' guestbook-service.yaml
删除Guestbook运行时服务
1 kubectl delete svc guestbook --namespace default
重新创建具有NodePort类型的服务：
1 kubectl create -f guestbook-service.yaml
使用以下命令检查更新：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ kubectl get all --namespace default NAME READY STATUS RESTARTS AGE pod/guestbook-v1-7fc76dc46-9r4s7 1/1 Running 0 1h pod/guestbook-v1-7fc76dc46-hspnk 1/1 Running 0 1h pod/guestbook-v1-7fc76dc46-sxzkt 1/1 Running 0 1h pod/redis-master-5d8b66464f-pvbl9 1/1 Running 0 1h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/guestbook NodePort 172.21.45.29 <none> 3000:31989/TCP 31s service/kubernetes ClusterIP 172.21.0.1 <none> 443/TCP 9d service/redis-master ClusterIP 172.21.232.61 <none> 6379/TCP 1h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/guestbook-demo 3/3 3 3 1h deployment.apps/redis-master 1/1 1 1 1h NAME DESIRED CURRENT READY AGE replicaset.apps/guestbook-v1-7fc76dc46 3 3 3 1h replicaset.apps/redis-master-5d8b66464f 1 1 1 1h
注意：服务类型已更改（更改为NodePor），并且已为留言簿服务分配了新端口（在此输出情况下为31989）。所有redis-slave资源均已删除。
获取节点的公共IP，并重新访问应用提供的服务：
1 kubectl get nodes -o wide
场景2: 使用Helm更新应用 在本节中，我们将使用Helm更新以前部署的guestbook-demo应用程序。
在开始之前，让我们花几分钟看一下Helm与直接使用Kubernetes相比如何简化流程。 Helm使用模板语言为chart提供了极大的灵活性和强大的功能，从而为chart用户消除了复杂性。在留言簿示例中，我们将使用以下模板功能：
Values：提供访问传递到chart中的值的对象。例如在guestbook-service中，它包含以下类型：.Values.service.type。此行提供了在升级或安装期间设置服务类型的功能。
控制结构：在模板中也称为“动作”，控制结构使模板能够控制生成的流程。一个例子是在redis-slave-service中，它包含行-if .Values.redis.slaveEnabled-。该行允许我们在升级或安装期间启用/禁用REDIS主/从。
如下所示，完整的redis-slave-service.yaml演示了在禁用slaveEnabled标志时文件如何变得冗余以及如何设置端口值。其他chart文件中还有更多的模板功能示例。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 {{- if .Values.redis.slaveEnabled -}} apiVersion: v1 kind: Service metadata: name: redis-slave labels: app: redis role: slave spec: ports: - port: {{ .Values.redis.port }} targetPort: redis-server selector: app: redis role: slave {{- end }}
1.
请注意，我们指定了名称空间。如果未指定，它将使用当前的名称空间上下文。我们应该看到类似于以下内容的输出：
1 2 3 $ helm list -n helm-demo NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION guestbook-demo helm-demo 1 2020-02-24 18:08:02.017401264 +0000 UTC deployed guestbook-0.2.0
list命令提供已部署chart（发行版）的列表，其中提供了chart版本，名称空间，更新（修订）数量等信息。
我们更新应用程序：
1 2 3 4 5 $ cd helm101/charts$ helm upgrade guestbook-demo ./guestbook --set redis.slaveEnabled=false ,service.type=NodePort --namespace helm-demo Release "guestbook-demo" has been upgraded. Happy Helming! ...
Helm升级将采用现有版本，并根据提供的信息对其进行升级。我们应该看到类似于以下内容的输出：
1 2 3 4 5 6 7 8 9 10 11 12 13 $ helm upgrade guestbook-demo ./guestbook --set redis.slaveEnabled=false ,service.type=NodePort --namespace helm-demo Release "guestbook-demo" has been upgraded. Happy Helming! NAME: guestbook-demo LAST DEPLOYED: Tue Feb 25 14:23:27 2020 NAMESPACE: helm-demo STATUS: deployed REVISION: 2 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: export NODE_PORT=$(kubectl get --namespace helm-demo -o jsonpath="{.spec.ports[0].nodePort}" services guestbook-demo) export NODE_IP=$(kubectl get nodes --namespace helm-demo -o jsonpath="{.items[0].status.addresses[0].address}") echo http://$NODE_IP:$NODE_PORT
upgrade命令将应用程序升级到chart的指定版本，删除redis-slave资源，并将应用程序service.type更新为NodePort。
使用kubectl get all --namespace helm-demo获取更新内容：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $ kubectl get all --namespace helm-demo NAME READY STATUS RESTARTS AGE pod/guestbook-demo-6c9cf8b9-dhqk9 1/1 Running 0 20h pod/guestbook-demo-6c9cf8b9-zddn2 1/1 Running 0 20h pod/redis-master-5d8b66464f-g7sh6 1/1 Running 0 20h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/guestbook-demo NodePort 172.21.43.244 <none> 3000:31202/TCP 20h service/redis-master ClusterIP 172.21.12.43 <none> 6379/TCP 20h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/guestbook-demo 2/2 2 2 20h deployment.apps/redis-master 1/1 1 1 20h NAME DESIRED CURRENT READY AGE replicaset.apps/guestbook-demo-6c9cf8b9 2 2 2 20h replicaset.apps/redis-master-5d8b66464f 1 1 1 20h
注意：服务类型已更改（更改为NodePort），并且已为留言簿服务分配了新端口（在此输出情况下为31202）。所有redis-slave资源均已删除。
当我们使用helm list -n helm-demo命令检查Helm版本时，可以看到revision和日期已更新：
1 2 3 $ helm list -n helm-demo NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION guestbook-demo helm-demo 2 2020-02-25 14:23:27.06732381 +0000 UTC deployed guestbook-0.2.0
获取节点的公共IP，并重新访问应用提供的服务：
1 kubectl get nodes -o wide
结论 恭喜，现在已经更新了应用程序！ Helm不需要任何手动更改资源，因此非常容易升级！所有配置都可以在命令行上即时设置，也可以使用替代文件设置。从将逻辑添加到模板文件后就可以实现这一点，这取决于flag标识，启用或禁用此功能。
Lab 3. 跟踪已部署的应用程序 假设我们部署了应用程序的不同发行版（即升级了正在运行的应用程序）。如何跟踪版本以及如何回滚？
场景1: 使用Kubernetes进行修订管理 在本部分的实验中，我们应该直接使用Kubernetes来说明留言簿的修订管理，但是我们不能。这是因为Kubernetes不为修订管理提供任何支持。我们有责任管理系统以及所做的任何更新或更改。但是，我们可以使用Helm进行修订管理。
场景2: 使用Helm进行修订管理 在本部分的实验中，我们将使用Helm来说明对已部署的应用程序guestbook-demo的修订管理。
使用Helm，每次进行安装，升级或回滚时，修订版本号都会增加1。第一个修订版本号始终为1。Helm将发布元数据保留在Kubernetes集群中存储的Secrets（默认）或ConfigMap中。每当发行版更改时，都会将其附加到现有数据中。这为Helm提供了回滚到先前版本的功能。
让我们看看这在实践中如何工作。
检查部署的数量：
应该看到类似于以下的输出，因为在Lab 1中进行初始安装后，我们在Lab 2中进行了升级。
1 2 3 4 $ helm history guestbook-demo -n helm-demo REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Feb 24 18:08:02 2020 superseded guestbook-0.2.0 Install complete 2 Tue Feb 25 14:23:27 2020 deployed guestbook-0.2.0 Upgrade complete
回滚到以前的版本：
在此回滚中，Helm将检查从修订版1升级到修订版2时发生的更改。此信息使它能够调用Kubernetes API服务，以根据初始部署更新已部署的应用程序-换句话说，使用Redis slave并使用负载平衡器。
1 2 $ helm rollback guestbook-demo 1 -n helm-demo Rollback was a success! Happy Helming!
再次检查历史记录：
应该看到类似于以下的输出：
1 2 3 4 5 $ helm history guestbook-demo -n helm-demo REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Feb 24 18:08:02 2020 superseded guestbook-0.2.0 Install complete 2 Tue Feb 25 14:23:27 2020 superseded guestbook-0.2.0 Upgrade complete 3 Tue Feb 25 14:53:45 2020 deployed guestbook-0.2.0 Rollback to 1
检查回滚结果：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 $ kubectl get all --namespace helm-demo NAME READY STATUS RESTARTS AGE pod/guestbook-demo-6c9cf8b9-dhqk9 1/1 Running 0 20h pod/guestbook-demo-6c9cf8b9-zddn 1/1 Running 0 20h pod/redis-master-5d8b66464f-g7sh6 1/1 Running 0 20h pod/redis-slave-586b4c847c-tkfj5 1/1 Running 0 5m15s pod/redis-slave-586b4c847c-xxrdn 1/1 Running 0 5m15s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/guestbook-demo LoadBalancer 172.21.43.244 <pending> 3000:31367/TCP 20h service/redis-master ClusterIP 172.21.12.43 <none> 6379/TCP 20h service/redis-slave ClusterIP 172.21.232.16 <none> 6379/TCP 5m15s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/guestbook-demo 2/2 2 2 20h deployment.apps/redis-master 1/1 1 1 20h deployment.apps/redis-slave 2/2 2 2 5m15s NAME DESIRED CURRENT READY AGE replicaset.apps/guestbook-demo-26c9cf8b9 2 2 2 20h replicaset.apps/redis-master-5d8b66464f 1 1 1 20h replicaset.apps/redis-slave-586b4c847c 2 2 2 5m15s
从输出中可以再次看到，应用程序服务是LoadBalancer的服务类型，并且Redis主/从部署已返回。这显示了实验2中升级的完整回滚。
结论 从这个实验中，我们可以说Helm很好地进行了修订管理，而Kubernetes没有内置的功能！我们可能想知道为什么需要helm rollback，因为重新执行helm upgrade也可以回到老版本。这是一个很好的问题。从技术上讲，我们应该最终部署相同的资源（具有相同的参数）。但是，使用helm rollback的好处是，Helm可以管理（即记住）以前的helm install\upgrade的所有变体/参数。通过helm upgrade进行回滚需要我们手动跟踪先前执行命令的方式。这不仅繁琐，而且容易出错。让Helm管理所有这些工作更加容易，安全和可靠，并且我们需要做的所有事情都告诉它可以使用哪个以前的版本，其余的都可以完成。
Lab 4. 共享Helm Charts 提供应用程序的一个关键方面意味着与他人共享。共享可以是直接的（由用户或在CI/CD管道中），也可以作为其他chart的依赖项。如果人们找不到你的应用程序，那么他们就无法使用它。
共享的一种方法是使用chart库，该仓库可以存储和共享打包的chart。由于chart库仅适用于Helm，因此我们将仅查看Helm chart的用法和存储。
从公共仓库中获取Chart Helm charts可以在远程存储库或本地环境/存储库中使用。远程存储库可以是公共的，例如Bitnami Charts 或IBM Helm Charts ，也可以是托管存储库，例如在Google Cloud Storage或GitHub上。有关更多详细信息，请参阅《 Helm Chart存储库指南》 。我们可以通过在本实验中检查chart索引文件 来了解有关chart存储库结构的更多信息。
在本部分的实验中，我们将展示如何从Helm101存储库 中安装留言簿chart。
检查系统上配置的存储库：
1 2 $ helm repo list Error: no repositories to show
注意：默认情况下，Helm v3未安装chart存储库，而是期望我们自己为要使用的chart添加存储库。 Helm Hub可以集中搜索公共可用的分布式chart。使用Helm Hub ，我们可以找到所需chart，然后将其添加到本地存储库列表中。 Helm chart存储库（如Helm v2）处于“维护模式”，将于2020年11月13日弃用。有关更多详细信息，请参见项目状态 。
添加helm101仓库：
1 2 $ helm repo add helm101 https://ibm.github.io/helm101/ "helm101" has been added to your repositories
还可以通过运行以下命令在存储库中搜索chart：
1 2 3 $ helm search repo helm101 NAME CHART VERSION APP VERSION DESCRIPTION helm101/guestbook 0.2.1 A Helm chart to deploy Guestbook three tier web...
安装chart：
如前所述，我们将安装Helm101存储库中的留言簿chart。当将仓库添加到我们的本地仓库清单中时，我们可以使用repo name/chart name（即helm101/guestbook）来引用chart。要查看实际效果，将应用程序安装到名为repo-demo的新命名空间中。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ kubectl create namespace repo-demo $ helm install guestbook-demo helm101/guestbook --namespace repo-demo $ helm install guestbook-demo helm101/guestbook --namespace repo-demo NAME: guestbook-demo LAST DEPLOYED: Tue Feb 25 15:40:17 2020 NAMESPACE: repo-demo STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. You can watch the status of by running 'kubectl get svc -w guestbook-demo --namespace repo-demo' export SERVICE_IP=$(kubectl get svc --namespace repo-demo guestbook-demo -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo http://$SERVICE_IP:3000
检查是否按预期部署了该版本，如下所示：
1 2 3 $ helm list -n repo-demo NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION guestbook-demo repo-demo 1 2020-02-25 15:40:17.627745329 +0000 UTC deployed guestbook-0.2.1
结论 本实验简要介绍了Helm存储库，以显示如何安装chart。共享chart的能力意味着更易于使用。
