helm 学习

在这里插入图片描述

文章目录

Helm 是什么？

Helm 是 Kubernetes 的包管理器。包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

Helm 解决了什么痛点？

咱就比方说，你现在在 k8s 上部署一个 redis 集群试试。

我们在 k8s 中部署一个应用，通常面临以下几个问题：

如何统一管理、配置和更新这些分散的 k8s 的应用资源文件
如何分发和复用一套应用模板
如何将应用的一系列资源当做一个软件包管理

版本映射

有关Helm 和 Kubernetes 之间支持的最大版本偏差，请参阅Helm 版本支持策略。

helm3 撤去了 tiller，所以如果用的是 helm2 需要自行安装 tiller。

安装

$ wget https://get.helm.sh/helm-v3.8.0-linux-amd64.tar.gz
$ tar -xzvf helm-v3.8.0-linux-amd64.tar.gz
$ cp linux-amd64/helm /usr/local/bin/
$ helm version
version.BuildInfo{
    
    Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}

具体版本自行替换：https://github.com/helm/helm/releases

基本概念

Chart（下文称为“图表”）是一个Helm 包。它包含在 Kubernetes 集群内运行应用程序、工具或服务所需的所有资源定义。可以把它想象成 Kubernetes 的 Homebrew 公式、Apt dpkg 或 Yum RPM 文件。
Repository 是可以收集和共享图表的地方。它类似于 Perl 的CPAN 存档或Fedora 包数据库，但用于 Kubernetes 包。
Release是在 Kubernetes 集群中运行的Chart的实例。一个Chart通常可以多次安装到同一个集群中。每次安装时，都会创建一个新Release。考虑一个 MySQL Chart。如果您希望在集群中运行两个数据库，则可以将该Chart安装两次。每个都有自己的发行版，而发行版又会有自己的发行版名称。

常用方法

helm repo：使用存储库

检查Artifact Hub以获取可用的 Helm 图表存储库。

$ helm repo list
NAME            URL
stable          https://charts.helm.sh/stable
mumoshu         https://mumoshu.github.io/charts

$ helm repo add stable https://charts.helm.sh/stable

由于图表存储库经常更改，因此您可以随时通过运行helm repo update.

可以使用删除存储库helm repo remove。

helm search: 查找图表

helm search hub搜索Artifact Hub，其中列出了来自数十个不同存储库的 helm 图表。
helm search repo搜索您添加到本地 helm 客户端的存储库（使用helm repo add）。此搜索是在本地数据上完成的，不需要公共网络连接。

$ helm search hub wordpress
URL                                                 CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...

以上搜索了wordpress Artifact Hub 上的所有图表。没有过滤器，helm search hub向您显示所有可用的图表。

使用helm search repo，您可以在已添加的存储库中找到图表的名称：

$ helm repo add brigade https://brigadecore.github.io/charts
"brigade" has been added to your repositories
$ helm search repo brigade
NAME                          CHART VERSION APP VERSION DESCRIPTION
brigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...
brigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...
brigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade
brigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes
brigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project
brigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes

Helm 搜索使用模糊字符串匹配算法，因此您可以键入部分单词或短语：

$ helm search repo kash
NAME            CHART VERSION APP VERSION DESCRIPTION
brigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes

helm install’：安装包

在最简单的情况下，它需要两个参数：您选择的版本名称和您要安装的图表的名称。

$ helm install happy-panda bitnami/wordpress
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
...

现在 wordpress 图表已安装。请注意，安装图表会创建一个新的发布对象。上面的版本名为 happy-panda. （如果您希望 Helm 为您生成名称，请省略发布名称并使用–generate-name.）

在安装过程中，helm客户端将打印有关创建了哪些资源、发布状态是什么以及您是否可以或应该采取其他配置步骤的有用信息。

Helm 按以下顺序安装资源：

命名空间
网络策略
资源配额
限制范围
PodSecurityPolicy
PodDisruptionBudget
服务帐户
秘密
秘密清单
配置映射
存储类
持久卷
PersistentVolumeClaim
自定义资源定义
集群角色
集群角色列表
集群角色绑定
ClusterRoleBindingList
角色
角色列表
角色绑定
角色绑定列表
服务
守护程序集
复制控制器
副本集
部署
HorizontalPodAutoscaler
有状态集
工作
定时任务
入口
API服务

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

要跟踪发布的状态，或重新读取配置信息，您可以使用helm status：

$ helm status happy-panda
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
...

自定义安装

比方说现在我们需要自定义安装一个 redis-ha。

1、拉取 redis-ha 安装包到本地：

helm pull stable/redis-ha

2、解压 redis-ha 包：

tar -xvf redis-ha-4.4.6.tgz

3、修改 value.yaml 文件

4、本地包安装

helm install redis ./redis-ha -n redis

自定义 chart

要查看图表上可配置的选项，请使用helm show values：

$ helm show values bitnami/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:
#   imageRegistry: myRegistryName
#   imagePullSecrets:
#     - myRegistryKeySecretName
#   storageClass: myStorageClass
## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
  registry: docker.io
  repository: bitnami/wordpress
  tag: 5.6.0-debian-10-r35
  [..]

然后，您可以覆盖 YAML 格式文件中的任何这些设置，然后在安装期间传递该文件。

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

以上将创建一个名为的默认 MariaDB 用户user0，并授予该用户对新创建的user0db数据库的访问权限，但将接受该图表的所有其余默认值。

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

--values（或-f）：指定具有覆盖的 YAML 文件。这可以指定多次，最右边的文件将优先
--set：在命令行上指定覆盖

如果两者都使用，则以更高的优先级–set合并值。–values用指定的覆盖–set将持久保存在 ConfigMap 中。–set可以使用 . 查看给定版本的值helm get values 。可以通过使用指定–set的运行来清除已被清除的值。helm upgrade–reset-values

格式和限制–set

该–set选项采用零个或多个名称/值对。最简单的用法是这样的：–set name=value. 等效的 YAML 是：

name: value

多个值由,字符分隔。于是–set a=b,c=d变成：

a: b
c: d

支持更复杂的表达式。例如，–set outer.inner=value翻译成这样：

outer:
  inner: value

列表可以通过将值括在{和中来表示}。例如，–set name={a, b, c}转换为：

name:
  - a
  - b
  - c

从 Helm 2.5.0 开始，可以使用数组索引语法访问列表项。例如，–set servers[0].port=80变为：

servers:
  - port: 80

可以通过这种方式设置多个值。该行–set servers[0].port=80,servers[0].host=example变为：

servers:
  - port: 80
    host: example

有时您需要在行中使用特殊字符–set。您可以使用反斜杠来转义字符；–set name=value1,value2会变成：

name: "value1,value2"

toYaml同样，您也可以转义点序列，当图表使用该函数解析注释、标签和节点选择器时，这可能会派上用场。的语法–set nodeSelector.“kubernetes.io/role”=master变为：

nodeSelector:
  kubernetes.io/role: master

helm upgrade、helm rollback：升级版本，并在失败时恢复

当发布新版本的图表时，或者当您想要更改发布的配置时，可以使用该helm upgrade命令。

升级采用现有版本并根据您提供的信息对其进行升级。由于 Kubernetes 图表可能很大且很复杂，Helm 尝试执行侵入性最小的升级。它只会更新自上次发布以来已更改的内容。

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

在上述情况下，happy-panda使用相同的图表升级版本，但使用新的 YAML 文件：

mariadb.auth.username: user1

我们可以helm get values用来查看新设置是否生效。

$ helm get values happy-panda
mariadb:
  auth:
    username: user1

该helm get命令是查看集群中发布的有用工具。正如我们在上面看到的，它表明我们的新值panda.yaml已部署到集群中。

现在，如果在发布期间某些事情没有按计划进行，很容易使用helm rollback [RELEASE] [REVISION].

$ helm rollback happy-panda 1

以上将我们的happy-panda 回滚到它的第一个发布版本。发布版本是增量修订。每次安装、升级或回滚时，修订号都会增加 1。第一个修订号始终为 1。我们可以使用它helm history [RELEASE]来查看某个版本的修订号。

在安装/升级/回滚期间，您可以指定其他几个有用的选项来自定义 Helm 的行为。请注意，这不是 cli 标志的完整列表。要查看所有标志的描述，只需运行helm <command> --help

--timeout：等待 Kubernetes 命令完成的Go 持续时间值。这默认为5m0s.

--wait：等到所有 Pod 都处于就绪状态，PVC 被绑定，部署有最少（Desired减号maxUnavailable）的 Pod 处于就绪状态并且服务有一个 IP 地址（如果是 a 则为 Ingress LoadBalancer），然后才将发布标记为成功。
只要--timeout值，它将等待。如果达到超时，释放将被标记为FAILED。
注意：在Deploymentreplicas设置为 1 并且maxUnavailable作为滚动更新策略的一部分未设置为 0的情况下，–wait将返回就绪状态，因为它满足了处于就绪状态的最小 Pod。

--no-hooks：这会跳过命令的运行钩子

helm uninstall：卸载版本

$ helm uninstall happy-panda
$ helm list
NAME            VERSION UPDATED                         STATUS          CHART
inky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0

在以前的 Helm 版本中，当一个版本被删除时，它的删除记录将保留。在 Helm 3 中，删除也会删除发布记录。如果您希望保留删除版本记录，请使用helm uninstall --keep-history.

请注意，由于现在默认删除版本，因此无法再回滚已卸载的资源。

有时，当 Helm 运行helm uninstall. chart开发人员可以为资源添加注释以防止其被卸载。

kind: Secret
metadata:
  annotations:
    "helm.sh/resource-policy": keep
[...]

“helm.sh/resource-policy”: keep指示 Helm 在 helm 操作（例如helm uninstall、helm upgrade或helm rollback）导致其删除时跳过删除此资源。但是，此资源成为孤立资源。Helm 将不再以任何方式管理它。helm install --replace如果在已卸载但保留资源的版本上使用，这可能会导致问题。

创建自己的chart

那就有必要看一下一个 chart 里面都有些啥了：

wordpress
├── charts
├── Chart.yaml
├── README.md
├── requirements.lock
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── externaldb-secrets.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── pvc.yaml
│   ├── secrets.yaml
│   ├── svc.yaml
│   └── tls-secrets.yaml
└── values.yaml

一个 wordpress chart 如上（去除部分 test 和 charts 依赖），基本结构由以下几个部分组成：

charts 存放子Chart (Subchart) 的定义，Subchart 指的是当前 Chart 依赖的 Chart ，在 requirements.yaml 中定义
Chart.yaml 包含 Chart 信息的 YAML 文件，包括 Chart 的版本、名称等，在 DCE Helm 插件中还包含 Chart 的团队授权信息和是否公开的信息
README.md 可选：Chart 的介绍信息等（该文件对于一个大型 Chart 来说十分重要）
Requirements.yaml 可选：列举当前 Chart 的需要依赖的 Chart
templates
该目录下存放 Chart 所有的 K8s 资源定义模板，通常不同的资源放在不同的文件中，DCE Helm 插件中自定义模板的 K8s 资源统一放在 all_sources.yaml 文件中
_helpers.tpl ，通常这个文件存放可重用的模板片段，该文件中的定义可以在 Chart 其它资源定义模板中使用
NOTES.txt，可选：一段简短使用说明的文本文件，用于安装 Release 后提示用户使用
values.yaml 当前 Chart 的默认配置的值

本节以构建一个名称为 nginx-test Chart 为示例，来描述一个 chart 必要条件。

# helm create nginx-test
Creating nginx-test

1、Chart.yaml 文件是一个 chart 必要文件，该文件可以简单包括以下字段（具体字段请参考Helm官网)
复制代码

# cat nginx-test/Chart.yaml 
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: nginx-test
version: 0.1.0

2、values.yaml 文件是 chart 的必要文件，以 nginx 为示例：

# cat nginx-test/values.yaml 
# Default values for nginx-test.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1
...

从示例中可以看出，values.yaml 中定义了一些当前chart 的一些默认值，用于 templates 下的 K8s 资源 yaml 渲染时填充默认值。
不过需要注意的是，如果使用 helm install 来部署一个 Release , 可以通过下面命令指定一份yaml 文件作为填充值：

helm install --values=myvals.yaml nginx

注意：上面命令不要复制执行，执行会报错的。请根据实际情况执行！！！

3、创建 templates 下的模板文件，用于生成 Kubernetes 资源清单(manifests) 如下所示:

# cat nginx-test/templates/deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {
    
    {
    
     include "nginx-test.fullname" . }}
  labels:
...

上面定义了一个 deployments.yaml 和 service.yaml 资源文件，里面使用 { { }} 符号的是 Go 模板语言的标准。其中可以通过：

.Values 对象访问 values.yaml 文件的内容， 前面的dot(.) 表示从顶层命名空间开始，找到 Values 对象(下同)
.Release、.Chart 开头的预定义值可用于任何的模板中
.Chart 对象用来访问 Chart.yaml 文件的内容
.Release 对象是 Helm的内置对象之一， 使用 Helm 安装一个 release 时，由 Tiller 分配 release 的名称

4、命名模板(_helper.tpl) ：可以从上面看到有 { { template “nginx-test.fullname” . }} 定义。该定义由 _helper.tpl 文件定义的字段来实现，比如下面一个 _helper.tpl :

# cat nginx-test/templates/_helpers.tpl 
{
    
    {
    
    /* vim: set filetype=mustache: */}}
{
    
    {
    
    /*
Expand the name of the chart.
*/}}
...

该模板定义了 “nginx-test.name”、“nginx-test.fullname”、“nginx-test.chart” 等可重用模板部分，当模板引擎读取该文件时，它存储对 nginx-test.name等的引用，直到调用 template “nginx-test.name” 为止。然后把值渲染到模板中。

注意 { { template “nginx-test.chart” . }} 后面有个dot(.)，这是因为一个已命名的模板（用于创建 define) 被渲染时，它将接收由该 template 调用传入的范围（scope)。没有范围传入，在模板中无法访问任何内容，因此在：

{ {- define “nginx-test.chart” -}}
这里面的 .Chart 将无法访问，导致在模板中无法看到内容，因为这里值为空
{ {- end -}}

因此在模板中将范围(scope) 传入即可正常使用：

# cat nginx-test/templates/service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: {
    
    {
    
     include "nginx-test.fullname" . }}

在末尾传递了 . 这样就可以使用 .Values 或者 .Chart 或其它范围(scope)

5、Chart 依赖（requirements.yaml)：比如 WordPress Chart 依赖于 mariadb Chart，下面是 WordPress 的依赖(requirements.yaml)：

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - wordpress-database

该文件列举当前 Chart 所有的依赖（subchart)。有几个字段是必要的：

name: 依赖 Chart 的名称（必要）
version: 依赖 Chart 的版本号（必要）
repository: 依赖 Chart 的存储库完整URL，必须通过 helm repo add 添加 repository（存储库）到本地