Helm安装与使用

背景

Kubernetes是一个基于容器的应用集群管理解决方案，Kubernetes为容器化应用提供了部署运行、资源调度、服务发现和动态扩容和缩容（即动态伸缩）等一系列完整功能。

Kubernetes的核心设计理念是，由用户定义部署应用程序的规则，而Kubernetes按照定义的规则并运行应用程序。如果应用程序出现问题导致偏离了定义的规则，Kubernetes负责对其进行自动修正。

用户通过使用Kubernetes API对象来描述应用程序规则，包括Pod、Service、Volume、Namespace、ReplicaSet、Depolyment以及Job等。通常情况下，系统管理员在定义这些资源对象的时候，需要编辑一系列的YAML配置文件，然后通过Kubernetes命令行工具kubectl调用Kubernetes API进行部署。

Helm介绍

Helm是Kubernetes生态系统中的一个软件包管理工具。在没使用Helm之前，向kubernetes部署应用，我们要依次部署deployment, service, configMap等，步骤较繁琐。而且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂。

Helm通过打包的方式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用的部署和管理。

Helm项目提供了两种获取和安装Helm的方式。这是官方提供的获取Helm发布版本的方法。

安装Helm

方法1： 用二进制版本安装
每个Helm 版本都提供了各种操作系统的二进制版本，这些版本可以手动下载和安装。

1. 下载 需要的版本
2. 解压(tar -zxvf helm-v3.0.0-linux-amd64.tar.gz)
3. 在解压目中找到helm程序，移动到需要的目录中(mv linux-amd64/helm /usr/local/bin/helm)

方法2：使用脚本安装
Helm现在有个安装脚本可以自动拉取最新的Helm版本并在本地安装：

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

如果想直接执行安装，运行curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash。

方法3：通过包管理器安装
这里由于是在Ubuntu20操作系统上，因此选择Apt包管理器：

curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

一旦你成功安装了Helm客户端，就可以继续使用Helm管理chart和添加稳定的仓库。

Helm解决了哪些问题？

在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的Kubernetes资源的共同协作。以安装一个 WordPress博客为例，需要用到了一些Kubernetes的一些资源对象，包括Deployment用于部署应用、Service提供服务发现、Secret配置WordPress的用户名和密码，可能还需要pv和pvc来提供持久化服务。并且WordPress的数据是存储在mariadb里面的，所以需要 mariadb启动就绪后才能启动WordPress。这些k8s资源过于分散，非常不方便进行管理，直接通过kubectl来管理一个应用，可能需要同时维护多个YAML文件。

因此，在使用k8s部署一个应用的时候，通常面临以下几个问题：

  • 如何统一管理、配置和更新这些分散的Kubernetes的应用配置文件。
  • 如何分发和重用Kubernetes的应用配置模板。
  • 如何将一套相关的资源配置文件作为一个应用进行管理。

Helm的出现解决了上面的这些问题。

Helm的优势

Helm是一个用于Kubernetes应用程序的软件包管理工具，主要用来管理Chart。类似于Ubuntu中的apt或者CentOS中的yum。Helm的优势从两个方面解释：

  1. 对于应用程度的发布者而言，可以通过Helm把应用程序打包、管理应用程序的依赖关系、管理应用程序的版本以及把应用程序发布到软件仓库；
  2. 对于使用者而言，使用Helm后就不用再编写复杂的YAML应用部署文件，可以用简单的方式在K8S上查找、安装、升级、回滚、卸载应用程序。

Helm相关组件及其概念

Helm的两个组件

Helm包含两个组件，分别是Helm客户端和Tiller服务器端：

1.Tiller

Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求，并根据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。

2. Helm

Helm是一个命令行的客户端工具，主要用于Kubernetes应用程序的创建、打包、发布以及创建和管理本地和远程的软件仓库。

Helm的三大概念

1. Chart

Chart 是Helm所管理的软件包，它采用TAR格式，类似于APT的DEB包或者YUM的RPM包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义，即一组定义K8S资源相关的YAML配置文件。可以在部署应用的时候自定义应用程序的一些元数据（Metadata），以便于应用程序的分发。

Config

Config指应用配置参数，在Chart中由 values.yaml 和命令行参数组成。Chart 采用 Go Template 的特性 + values.yaml 对部署的模板文件进行参数渲染，也可以通过 Helm Client 的命令 –set key=value 的方式进行参数赋值。

2. Repository

Repository（仓库） 是用来存放和共享 charts 的地方。Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。

3. Release

Release 是运行在 Kubernetes 集群中的 chart 的实例。即使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 release。以 MySQL chart为例，如果你想在你的集群中运行两个数据库，你可以安装该chart两次。每一个数据库都会拥有它自己的 release 和 release name。

Helm的工作原理

下面两张图描述了 Helm 的几个关键组件 Helm（客户端）、Tiller（服务器）、Repository（Chart 软件仓库）、Chart（软件包）之间的关系以及它们之间如何通信：
Helm组件通信
Helm架构

1. 创建Release

  • helm客户端从指定的目录或者本地TAR文件或远程repo仓库中解析出Chart的结构信息
  • helm客户端将指定的Chart结构和Values信息通过gRPC传递给Tiller
  • Tiller服务器端根据Chart和Values生成一个Release
  • Tiller服务器端将install release请求直接发送给kube-apiserver用于生成Release

2. 更新Release

  • helm客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息
  • helm客户端将要更新的Release的名称和Chart结构、Values信息通过gRPC传递给Tiller
  • Tiller服务器端生成Release并更新指定名称的Release的History
  • Tiller服务器端将Release发送给Kubernetes用于更新Release

3. 删除Release

  • helm客户端从指定的目录或本地TAR文件或远程repo仓库解析出chart的结构信息
  • helm客户端指定的chart结构和values信息通过 gRPC 传递给 Tiller
  • Tiller服务端根据 chart 和 values 生成一个 release
  • Tiller服务端将delete release请求直接传递给 kube-apiserver

4. 回退Release

  • helm客户端将要回滚的Release的名称传递给Tiller
  • Tiller服务器端根据Release的名称查找History
  • Tiller服务器端从History中获取上一个Release
  • Tiller服务器端将上一个Release发送给Kubernetes用于替换当前Release

Helm从v2到v3的变化

从2019年11月13日，Helm发布了Helm v3的第一个稳定版本以来，与v2相比发生了一些变化，如下图所示：
Helm v2到v3的变化
Helm V2 到 V3 经历了较大的变革，其中最大的改动就是移除了 Tiller 组件，所有功能都通过 Helm CLI 与 ApiServer 直接交互。Tiller 在 V2 的架构中扮演着重要的角色，但是它与 K8S 的设计理念是冲突的。主要有4个原因：

  1. 围绕 Tiller 管理应用的生命周期不利于扩展。
  2. 增加用户的使用壁垒，服务端需要部署 Tiller 组件才可以使用，侵入性强。
  3. K8S 的 RBAC 变得毫无用处，Tiller 拥有过大的 RBAC 权限存在安全风险。
  4. 造成多租户场景下架构设计与实现复杂。

因此：

  1. 移除了Tiller:
    • 用client/library结构（仅仅helm）替换了 client/server
    • 安全性现在是每个用户的基础（委托给了Kubernetes用户集群安全）
    • 发布版本现在作为集群内的密钥存储且改变了发布对象的元数据
    • 发布版本是在版本命名空间的基础上持久化的并且不再是Tiller的命名空间
    • Release名称可以在不同的命名空间中使用
  2. 升级了Chart仓库：
    • helm search 现在支持本地仓库搜索和Artifact Hub查询
    • 支持将Chart推送至Docker镜像仓库中
  3. 对于以下更新的规范，Chart的apiVersion升级到了"v2"：
    • 动态依赖的chart依赖移动到了Chart.yaml (删除了requirements.yaml 且 requirements --> dependencies)
    • 库chart (辅助/公共库) 现在可以添加为动态链接的chart依赖
    • Chart有个type元数据字段将chart定义为application或library的chart。默认是可渲染和安装的应用
    • Helm 2 的chart (apiVersion=v1) 依然可用
    • 使用JSONSchema验证chart values
  4. 添加了XDG目录规范：
    • Helm根目录针对存储配置文件删除和替换了XDG目录规范
    • 不再需要初始化Helm
    • 移除了helm init 和 helm home
  5. 其他更改：
    • 简化了Helm的安装和设置：
      • 仅针对Helm客户端 (二进制)
      • 按照已有范式运行
    • 不再默认设置local或stable仓库
    • 删除了crd-install钩子并用chart中的crds目录替换了，在渲染chart之前会安装所有的crd
    • 删除了test-failure钩子注释值，且弃用了test-success。使用test代替
    • 删除/替换/添加的命令：
      • delete --> uninstall : 默认删除所有的发布记录（之前需要–purge）
      • fetch --> pull
      • home (已删除)
      • init (已删除)
      • install: 需要发布名称或者–generate-name 参数
      • inspect --> show
      • reset (已删除)
      • serve (已删除)
      • template: -x/–execute 参数重命名为 -s/–show-only
      • upgrade: 添加了参数 --history-max，限制每个版本保存的最大记录数量（0表示不限制）
    • Helm 3 Go库经历了很多变化，不再兼容Helm 2库
    • 发行版二进制包现在托管在 get.helm.sh

Helm的使用

配置helm仓库

  1. 查看helm的版本
[root@k8smaster ~]# helm version
version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}
  1. 配置Chart仓库
    首先导入一个国内的软件仓库，这里选择azure的源，导入过程如下：
[root@k8smaster ~]# helm repo add stable http://mirror.azure.cn/kubernetes/charts/
[root@k8smaster ~]# helm repo add artifact-hub https://artifacthub.github.io/hub/chart
  1. 查看配置的存储库：
[root@k8smaster ~]# helm repo list
NAME            URL
stable          http://mirror.azure.cn/kubernetes/charts/
artifact-hub    https://artifacthub.github.io/hub/chart
  1. 删除存储库：
$ helm repo remove stable
  1. helm的常用命令
命令描述
create创建一个chart并指定名字
dependency管理chart依赖
get下载一个release，可用子命令：all，hooks，manifest，notes，values
history获取release历史
install安装一个chart
list列出release
package将chart目录打包到chart存档文件中
pull从远程仓库中下载chart并解压到本地 # helm pull stable/mysql --untar
repo添加、列出、移除、更新和索引chart仓库。可用子命令：add、index、list、remove、update
rollback从之前版本回滚
search根据关键字搜索chart，可用子命令：hub、repo
show查看chart详细信息。可用子命令：all、chart、readme、values
status显示已命名版本的状态
template本地呈现模板
uninstall卸载一个release
upgrade更新一个release
version查看helm客户端版本

Chart文件结构

Helm使用称为Chart的软件包格式。chart就是一个描述Kubernetes相关资源的文件集合。单个chart可以用来部署一些简单的， 类似于memcache pod，或者某些复杂的HTTP服务器以及web全栈应用、数据库、缓存等等。

Chart是作为特定目录布局的文件被创建的。它们可以打包到要部署的版本存档中。

如果你想下载和查看一个发布的chart，但不安装它，你可以用这个命令： helm pull chartrepo/chartname。

该文档解释说明了chart格式，并提供了用Helm构建chart的基本指导。

从本质上将，Chart软件包实际上就是一个tar归档文件。使用helm fetch命令从软件仓库中下载一个打包好的Chart，例如：

[root@k8smaster ~]# helm fetch stable/wordpress
[root@k8smaster ~]# ll
total 48
-rw-r--r--  1 root root 41859 Jan 27 03:31 wordpress-9.0.3.tgz

.tgz表示该文件是经过tar和gzip压缩后的文件。
解压该文件：

[root@k8smaster ~]# tar -zxvf wordpress-9.0.3.tgz
[root@k8smaster wordpress]# ll
total 76
drwxr-xr-x 3 root root    21 Jan 27 03:36 charts				# 包含chart依赖的其他chart
-rwxr-xr-x 1 root root   421 Jan  1  1970 Chart.yaml			# 包含了chart信息的YAML文件
-rwxr-xr-x 1 root root 37484 Jan  1  1970 README.md				# 可选，可读的README文件
-rwxr-xr-x 1 root root   237 Jan  1  1970 requirements.lock
-rwxr-xr-x 1 root root   185 Jan  1  1970 requirements.yaml
drwxr-xr-x 3 root root   233 Jan 27 03:36 templates				# 目录模板，当和values结合时，可生成有效的Kubernetes manifest文件
-rwxr-xr-x 1 root root  4776 Jan  1  1970 values.schema.json	# 可选：一个使用JSON结构的values.yaml文件
-rwxr-xr-x 1 root root 14391 Jan  1  1970 values.yaml			# chart默认的配置值

文件的层级结构如下：

[root@k8smaster wordpress]# tree
.
├── charts
│   └── mariadb
│       ├── Chart.yaml
│       ├── files
│       │   └── docker-entrypoint-initdb.d
│       │       └── README.md
│       ├── OWNERS
│       ├── README.md
│       ├── templates
│       │   ├── _helpers.tpl
│       │   ├── initialization-configmap.yaml
│       │   ├── master-configmap.yaml
│       │   ├── master-pdb.yaml
│       │   ├── master-statefulset.yaml
│       │   ├── master-svc.yaml
│       │   ├── NOTES.txt
│       │   ├── rolebinding.yaml
│       │   ├── role.yaml
│       │   ├── secrets.yaml
│       │   ├── serviceaccount.yaml
│       │   ├── servicemonitor.yaml
│       │   ├── slave-configmap.yaml
│       │   ├── slave-pdb.yaml
│       │   ├── slave-statefulset.yaml
│       │   ├── slave-svc.yaml
│       │   ├── test-runner.yaml
│       │   └── tests.yaml
│       ├── values-production.yaml
│       ├── values.schema.json
│       └── values.yaml
├── Chart.yaml
├── README.md
├── requirements.lock
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── externaldb-secrets.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── pvc.yaml
│   ├── secrets.yaml
│   ├── servicemonitor.yaml
│   ├── svc.yaml
│   ├── tests
│   │   └── test-mariadb-connection.yaml
│   └── tls-secrets.yaml
├── values.schema.json
└── values.yaml

Chart.yaml文件

Chart.yaml文件是chart必需的。包含了以下字段：

apiVersion: chart API 版本 （必需）
name: chart名称 （必需）
version: 语义化2 版本（必需）
kubeVersion: 兼容Kubernetes版本的语义化版本（可选）
description: 一句话对这个项目的描述（可选）
type: chart类型 （可选）
keywords:
  - 关于项目的一组关键字（可选）
home: 项目home页面的URL （可选）
sources:
  - 项目源码的URL列表（可选）
dependencies: # chart 必要条件列表 （可选）
  - name: chart名称 (nginx)
    version: chart版本 ("1.2.3")
    repository: 仓库URL ("https://example.com/charts") 或别名 ("@repo-name")
    condition: （可选） 解析为布尔值的yaml路径，用于启用/禁用chart (e.g. subchart1.enabled )
    tags: # （可选）
      - 用于一次启用/禁用 一组chart的tag
    import-values: # （可选）
      - ImportValue 保存源值到导入父键的映射。每项可以是字符串或者一对子/父列表项
    alias: （可选） chart中使用的别名。当你要多次添加相同的chart时会很有用
maintainers: # （可选）
  - name: 维护者名字 （每个维护者都需要）
    email: 维护者邮箱 （每个维护者可选）
    url: 维护者URL （每个维护者可选）
icon: 用做icon的SVG或PNG图片URL （可选）
appVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号
deprecated: 不被推荐的chart （可选，布尔值）
annotations:
  example: 按名称输入的批注列表 （可选）.

Chart许可证、自述和注释

Chart也可以包含描述安装，配置和使用文件，以及chart许可证。

许可证（LICENSE）是一个包含了chart license的纯文本文件。 chart可以包含一个许可证，因为在模板里不只是配置，还可能有编码逻辑。如果需要，还可以为chart安装的应用程序提供单独的许可证。

chart的自述文件README文件应该使用Markdown格式(README.md)，一般应包含：

  • chart提供的应用或服务的描述
  • 运行chart的先决条件或要求
  • values.yaml的可选项和默认值的描述
  • 与chart的安装或配置相关的其他任何信息

README.md 文件会包含hub和用户接口显示的chart的详细信息。

chart也会包含一个简短的纯文本 templates/NOTES.txt 文件，这会在安装后及查看版本状态时打印出来。 这个文件会作为一个 模板来评估，并用来显示使用说明，后续步骤，或者其他chart版本的相关信息。 比如，可以提供连接数据库的说明，web UI的访问。由于此文件是在运行helm install或helm status时打印到STDOUT的， 因此建议保持内容简短，并指向自述文件以获取更多详细信息。

Chart dependency

Helm 中，chart可能会依赖其他任意个chart。 这些依赖可以使用Chart.yaml文件中的dependencies 字段动态链接，或者被带入到charts/ 目录并手动配置。

  1. 使用dependencies字段管理依赖
    当前chart依赖的其他chart会在dependencies字段定义为一个列表。
    在某些情况下，允许子chart的值作为公共默认传递到父chart中是值得的。使用 exports格式的额外好处是它可是将来的工具可以自检用户可设置的值。
  2. 通过charts/目录手动管理依赖
    如果对依赖进行更多控制，通过将有依赖关系的chart复制到charts/目录中来显式表达这些依赖关系。

Templates and Values

Helm Chart 模板是按照 Go模板语言书写， 增加了50个左右的附加模板函数 来自 Sprig库 和一些其他 指定的函数。

所有模板文件存储在chart的 templates/ 文件夹。 当Helm渲染chart时，它会通过模板引擎遍历目录中的每个文件。

模板的Value通过两种方式提供：

  • Chart开发者可以在chart中提供一个命名为 values.yaml 的文件。这个文件包含了默认值。
  • Chart用户可以提供一个包含了value的YAML文件。可以在命令行使用 helm install命令时提供。

当用户提供自定义value时，这些value会覆盖chart的values.yaml文件中value。

用户自定义资源（CBD）

Kubernetes提供了一种声明Kubernetes新类型对象的机制。使用CustomResourceDefinition（CRD）， Kubernetes开发者可以声明自定义资源类型。

Helm 3中,CRD被视为一种特殊的对象。它们被安装在chart的其他部分之前，并受到一些限制。

CRD YAML文件应被放置在chart的crds/目录中。 多个CRD(用YAML的开始和结束符分隔)可以被放置在同一个文件中。Helm会尝试加载CRD目录中 所有的文件到Kubernetes。

CRD 文件无法模板化，必须是普通的YAML文档。

当Helm安装新chart时，会上传CRD，暂停安装直到CRD可以被API服务使用，然后启动模板引擎， 渲染chart其他部分，并上传到Kubernetes。因为这个顺序，CRD信息会在Helm模板中的 .Capabilities对象中生效，并且Helm模板会创建在CRD中声明的新的实例对象。

使用Helm管理Chart

helm工具有一些命令用来处理chart。
创建一个新的chart:

[root@k8smaster ~]# helm create mychart
Creating mychart
[root@k8smaster mychart]# ls
charts  Chart.yaml  templates  values.yaml

打包成一个chart存档：

[root@k8smaster ~]# helm package mychart
Successfully packaged chart and saved it to: /root/mychart-0.1.0.tgz

使用helm帮助找到chart的格式或信息的问题：

[root@k8smaster ~]# helm lint mychart
==> Linting mychart
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

Chart仓库

**chart仓库 是一个HTTP服务器，包含了一个或多个打包的chart。**当helm用来管理本地chart目录时， 共享chart时，首选的机制就是使用chart仓库。

任何可以服务于YAML文件和tar文件并可以响应GET请求的HTTP服务器都可以用做仓库服务器。 Helm 团队已经测试了一些服务器，包括激活websit模组的Google Cloud 存储，以及使用website的S3。

仓库的主要特征存在一个名为 index.yaml 的特殊文件，文件中包含仓库提供的包的完整列表， 以及允许检索和验证这些包的元数据。

在客户端，仓库使用helm repo命令管理。然而，Helm不提供上传chart到远程仓库的工具。 这是因为这样做会给执行服务器增加大量的必要条件，也就增加了设置仓库的障碍。

Chart Starter包

helm create命令可以附带一个可选的 --starter 选项让您指定一个 “starter chart”。

Starter就只是普通chart，但是被放置在$XDG_DATA_HOME/helm/starters。作为一个chart开发者， 可以编写被特别设计用来作为启动的chart。设计此类chart应注意以下考虑因素：

  • Chart.yaml会被生成器覆盖。
  • 用户将希望修改此类chart的内容，所以文档应该说明用户如果做到这一点。
  • 所有出现的<CHARTNAME>都会被替换为指定为chart名称，以便chart可以作为模板使用。

当前增加一个chart的唯一方式就是拷贝chart到$XDG_DATA_HOME/helm/starters。在您的chart文档中，您可能需要解释这个过程。

具体每个项目的详细信息可参考官方网站：https://helm.sh/zh/docs/topics/charts/

Chart Hook

Helm 提供了一个 hook 机制允许chart开发者在发布生命周期的某些点进行干预。比如可以使用hook用于：

  • 安装时在加载其他chart之前加载配置映射或密钥
  • 安装新chart之前执行备份数据库的任务，然后在升级之后执行第二个任务用于存储数据。
  • 在删除发布之前执行一个任务以便在删除服务之前退出滚动。

钩子的工作方式与常规模板类似，但因为Helm对其不同的使用方式，会有一些特殊的注释。具体参考https://helm.sh/zh/docs/topics/charts_hooks/

‘helm search’：查找 Charts

Helm 自带一个强大的搜索命令，可以用来从两种来源中进行搜索：

  • helm search hub 从 Artifact Hub 中查找并列出 helm charts。 Artifact Hub中存放了大量不同的仓库。
  • helm search repo 从你添加（使用 helm repo add）到本地 helm 客户端中的仓库中进行查找。该命令基于本地数据进行搜索，无需连接互联网。

通过运行 helm search hub 命令找到公开可用的charts：

[root@k8smaster ~]# helm search hub wordpress
URL                                                     CHART VERSION   APP VERSION     DESCRIPTION                       
https://artifacthub.io/packages/helm/groundhog2...      0.2.9           5.6.2-apache    A Helm chart for Wordpress on Kubernetes
https://artifacthub.io/packages/helm/bitnami/wo...      10.6.10         5.6.2           Web publishing platform for building blogs and ...
https://artifacthub.io/packages/helm/seccurecod...      2.5.2           4.0             Insecure & Outdated Wordpress Instance: Never e...
https://artifacthub.io/packages/helm/presslabs/...      0.11.0-alpha.0  0.11.0-alpha.0  Presslabs WordPress Operator Helm Chart
https://artifacthub.io/packages/helm/presslabs/...      0.10.4          v0.10.4         A Helm chart for deploying a WordPress site on ...
https://artifacthub.io/packages/helm/gh-shessel...      1.0.6           5.6.2           Web publishing platform for building blogs and ...
https://artifacthub.io/packages/helm/seccurecod...      2.5.2           latest          A Helm chart for the WordPress security scanner...
https://artifacthub.io/packages/helm/presslabs/...      0.10.4          v0.10.4         Open-Source WordPress Infrastructure on Kubernetes

使用 helm search repo 命令，你可以从你所添加的仓库中查找chart的名字。

[root@k8smaster ~]# helm search repo wordpress
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
stable/wordpress        9.0.3           5.3.2           DEPRECATED Web publishing platform for building...

Helm 搜索使用模糊字符串匹配算法，所以你可以只输入名字的一部分：

[root@k8smaster ~]# helm search repo word
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
stable/wordpress        9.0.3           5.3.2           DEPRECATED Web publishing platform for building...

一旦你找到你想安装的 helm 包，你便可以通过使用 helm install 命令来安装它。

‘helm install’：安装一个 helm 包

使用 helm install 命令来安装一个新的 helm 包。最简单的使用方法只需要传入两个参数：你命名的release名字和你想安装的chart的名称。
helm install的用法如下：

helm install [NAME] [CHART] [flags]

其中NAME为你命令的Release的名称，CHART表示要安装的Chart的名称，flag为一系列的选项，常用的有：

  • --name： 指定Chart的名称
  • --set : 该选项为一组“键值对”，用来覆盖Chart的配置文件中默认的配置选项
  • -f：通过YAML配置文件覆盖默认选项

安装示例：

[root@k8smaster ~]# helm install happy-panda stable/wordpress
WARNING: This chart is deprecated
NAME: happy-panda
LAST DEPLOYED: Wed Jan 27 06:09:20 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
This Helm chart is deprecated

Given the `stable` deprecation timeline (https://github.com/helm/charts#deprecation-timeline), the Bitnami maintained Helm chart is now located at bitnami/charts (https://github.com/bitnami/charts/).

The Bitnami repository is already included in the Hubs and we will continue providing the same cadence of updates, support, etc that we've been keeping here these years. Installation instructions are very similar, just adding the _bitnami_ repo and using it during the installation (`bitnami/<chart>` instead of `stable/<chart>`)

'''bash
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/<chart>           # Helm 3
$ helm install --name my-release bitnami/<chart>    # Helm 2
'''

To update an exisiting _stable_ deployment with a chart hosted in the bitnami repository you can execute

'''bash
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm upgrade my-release bitnami/<chart>
'''

Issues and PRs related to the chart itself will be redirected to `bitnami/charts` GitHub repository. In the same way, we'll be happy to answer questions related to this migration process in this issue (https://github.com/helm/charts/issues/20969) created as a common place for discussion.

** Please be patient while the chart is being deployed **

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

在安装过程中，helm 客户端会打印一些有用的信息，其中包括：哪些资源已经被创建，release当前的状态，以及你是否还需要执行额外的配置步骤。

Helm 客户端不会等到所有资源都运行才退出。许多 charts 需要大小超过 600M 的 Docker 镜像，可能需要很长时间才能安装到群集中。

使用helm status来追踪 release 的状态，或是重新读取配置信息。
使用 helm show values 可以查看 chart 中的可配置选项：

[root@k8smaster ~]# helm show values stable/wordpress
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
	...

然后，你可以使用 YAML 格式的文件覆盖上述任意配置项，并在安装过程中使用该文件。例如

$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml
$ helm install -f values.yaml bitnami/wordpress --generate-name

上述命令将为 MariaDB 创建一个名称为 user0 的默认用户，并且授予该用户访问新建的 user0db 数据库的权限。chart 中的其他默认配置保持不变。

安装过程中有两种方式传递配置数据：

  • --values (或 -f)：使用 YAML 文件覆盖配置。可以指定多次，优先使用最右边的文件。
  • --set：通过命令行的方式对指定项进行覆盖。

如果同时使用两种方式，则 --set 中的值会被合并到 --values 中，但是 --set 中的值优先级更高。在--set 中覆盖的内容会被被保存在 ConfigMap 中。可以通过 helm get values <release-name> 来查看指定 release 中 --set 设置的值。也可以通过运行 helm upgrade 并指定 --reset-values 字段来清除 --set 中设置的值。

最简单的用法类似于：--set name=value

‘helm upgrade’ 和 ‘helm rollback’：升级 release 和失败时恢复

一次升级操作会使用已有的 release 并根据你提供的信息对其进行升级。由于 Kubernetes 的 chart 可能会很大而且很复杂，Helm 会尝试执行最小侵入式升级。即它只会更新自上次发布以来发生了更改的内容。例如：

$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress

可以使用 helm get values命令来看看配置值是否真的生效了。

假如在一次发布过程中，发生了不符合预期的事情，也很容易通过 helm rollback [RELEASE] [REVISION]命令回滚到之前的发布版本。例如：

$ helm rollback happy-panda 1

release 版本其实是一个增量修订（revision）。 每当发生了一次安装、升级或回滚操作，revision 的值就会加1。第一次 revision 的值永远是1。我们可以使用 helm history [RELEASE]命令来查看一个特定 release 的修订版本号。

‘helm uninstall’：卸载 release

使用 helm uninstall 命令从集群中卸载一个 release：

[root@k8smaster ~]# helm uninstall happy-panda
release "happy-panda" uninstalled

该命令将从集群中移除指定 release。你可以通过 helm list 命令看到当前部署的所有 release：

[root@k8smaster ~]# helm list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

在 Helm 3 中，删除也会移除 release 的记录。 如果想保留删除记录，使用 helm uninstall --keep-history。使用 helm list --uninstalled只会展示使用了 --keep-history 删除的 release。
helm list --all 会展示 Helm 保留的所有 release 记录，包括失败或删除的条目（指定了 --keep-history）

$  helm list --all
NAME            VERSION UPDATED                         STATUS          CHART
happy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0
inky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0
kindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0

注意，因为现在默认会删除 release，所以不再能够回滚一个已经被卸载的资源了。

‘helm repo’：使用仓库

Helm 3 不再附带一个默认的 chart 仓库。helm repo 提供了一组命令用于添加、列出和移除仓库。
使用 helm repo list 来查看配置的仓库
使用 helm repo add 来添加新的仓库
使用 helm repo remove 命令来移除仓库。

总结

本文介绍了 helm 客户端的基本使用方式，包括搜索，安装，升级，和卸载。也涵盖了一些有用的工具类命令，如helm status， helm get，和 helm repo。 有关这些命令的更多信息，使用 Helm 的内置帮助命令：helm help。

参考资料

  1. Helm官方文档：https://helm.sh/zh/docs/intro/quickstart/
  2. https://helm.sh/zh/docs/topics/
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes