以下内容全部摘抄自官方文档,只是选取以一部分自己认为有用的内容,方便后面回顾使用,建议查看官方文档.

相关命令

三大概念

Chart 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。你可以把它看作是 Homebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等价物。

Repository（仓库） 是用来存放和共享 charts 的地方。它就像 Perl 的 CPAN 档案库网络或是 Fedora 的软件包仓库，只不过它是供 Kubernetes 包所使用的。

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

在了解了上述这些概念以后，我们就可以这样来解释 Helm：

Helm 安装 charts 到 Kubernetes 集群中，每次安装都会创建一个新的 release。你可以在 Helm 的 chart repositories 中寻找新的 chart。

'helm search'：查找 Charts

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

$ 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 ...

$ 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 包

helm install 命令可以从多个来源进行安装：

chart 的仓库（如上所述）
本地 chart 压缩包（helm install foo foo-0.1.1.tgz）
解压后的 chart 目录（helm install foo path/to/foo）
完整的 URL（helm install foo https://example.com/charts/foo-1.2.3.tgz）

$ 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:

你可以使用 helm status 来追踪 release 的状态，或是重新读取配置信息：

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

安装前自定义 chart

使用 helm show values 可以查看 chart 中的可配置选项：

$ 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

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

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

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

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

当你想升级到 chart 的新版本，或是修改 release 的配置，你可以使用 helm upgrade 命令。

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

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

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

$ helm rollback happy-panda 1

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

安装、升级、回滚时的有用选项

你还可以指定一些其他有用的选项来自定义 Helm 在安装、升级、回滚期间的行为。请注意这并不是 cli 参数的完整列表。要查看所有参数的说明，请执行 helm <command> --help 命令。

--timeout：一个 Go duration 类型的值，用来表示等待 Kubernetes 命令完成的超时时间，默认值为 5m0s。
--wait：表示必须要等到所有的 Pods 都处于 ready 状态，PVC 都被绑定，Deployments 都至少拥有最小 ready 状态 Pods 个数（Desired减去 maxUnavailable），并且 Services 都具有 IP 地址（如果是LoadBalancer，则为 Ingress），才会标记该 release 为成功。最长等待时间由 --timeout 值指定。如果达到超时时间，release 将被标记为 FAILED。注意：当 Deployment 的 replicas 被设置为1，但其滚动升级策略中的 maxUnavailable 没有被设置为0时，--wait 将返回就绪，因为已经满足了最小 ready Pod 数。
--no-hooks：不运行当前命令的钩子。
--recreate-pods（仅适用于 upgrade 和 rollback）：这个参数会导致重建所有的 Pod（deployment中的Pod 除外）。（在 Helm 3 中已被废弃）

'helm uninstall'：卸载 release

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

$ helm uninstall happy-panda

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

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

在上一个 Helm 版本中，当一个 release 被删除，会保留一条删除记录。而在 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 list
NAME            URL
stable          https://charts.helm.sh/stable
mumoshu         https://mumoshu.github.io/charts

使用 helm repo add 来添加新的仓库：

$ helm repo add dev https://example.com/dev-charts

因为 chart 仓库经常在变化，在任何时候你都可以通过执行 helm repo update 命令来确保你的 Helm 客户端是最新的。

使用 helm repo remove 命令来移除仓库。

创建你自己的 charts (命令相关)

chart 开发指南介绍了如何开发你自己的chart。但是你也可以通过使用 helm create 命令来快速开始：

$ helm create deis-workflow
Creating deis-workflow

现在，./deis-workflow 目录下已经有一个 chart 了。你可以编辑它并创建你自己的模版。

在编辑 chart 时，可以通过 helm lint 验证格式是否正确。

当准备将 chart 打包分发时，你可以运行 helm package 命令

$ helm package deis-workflow
deis-workflow-0.1.0.tgz

然后这个 chart 就可以很轻松的通过 helm install 命令安装：

$ helm install deis-workflow ./deis-workflow-0.1.0.tgz
...

创建一个chart

创建chart

Chart 文件结构

chart是一个组织在文件目录中的集合。目录名称就是chart名称（没有版本信息）。因而描述WordPress的chart可以存储在wordpress/目录中。

在这个目录中，Helm 期望可以匹配以下结构：

wordpress/
  Chart.yaml          # 包含了chart信息的YAML文件
  LICENSE             # 可选: 包含chart许可证的纯文本文件
  README.md           # 可选: 可读的README文件
  values.yaml         # chart 默认的配置值
  values.schema.json  # 可选: 一个使用JSON结构的values.yaml文件
  charts/             # 包含chart依赖的其他chart
  crds/               # 自定义资源的定义
  templates/          # 模板目录， 当和values 结合时，可生成有效的Kubernetes manifest文件
  templates/NOTES.txt # 可选: 包含简要使用说明的纯文本文件

Helm保留使用 charts/，crds/， templates/目录，以及列举出的文件名。其他文件保持原样

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: 按名称输入的批注列表 （可选）.

从 v3.3.2，不再允许额外的字段。推荐的方法是在 annotations 中添加自定义元数据。

Chart和版本控制

每个chart都必须有个版本号。版本必须遵循语义化版本 2 标准。不像经典Helm， Helm v2以及后续版本会使用版本号作为发布标记。仓库中的包通过名称加版本号标识。

比如 nginx chart的版本字段version: 1.2.3按照名称被设置为：

nginx-1.2.3.tgz

更多复杂的语义化版本2 都是支持的，比如 version: 1.2.3-alpha.1+ef365。但系统明确禁止非语义化版本名称。 Chart.yaml文件中的version字段被很多Helm工具使用，包括CLI。当生成一个包时， helm package命令可以用Chart.yaml文件中找到的版本号作为包名中的token。系统假设chart包名中的版本号可以与Chart.yaml文件中的版本号匹配。如果不满足这一假设会导致错误。

Chart Types

type字段定义了chart的类型。有两种类型： application 和 library。应用是默认类型，是可以完全操作的标准chart。库类型 chart 提供针对chart构建的实用程序和功能。库类型chart与应用类型chart不同，因为它不能安装，通常不包含任何资源对象。

注意： 应用类型chart 可以作为库类型chart使用。可以通过将类型设置为 library来实现。然后这个库就被渲染成了一个库类型chart，所有的实用程序和功能都可以使用。所有的资源对象不会被渲染。

使用 `dependencies` 字段管理依赖

当前chart依赖的其他chart会在dependencies字段定义为一个列表。

dependencies:
  - name: apache
    version: 1.2.3
    repository: https://example.com/charts
  - name: mysql
    version: 3.2.1
    repository: https://another.example.com/charts

name字段是你需要的chart的名称
version字段是你需要的chart的版本
repository字段是chart仓库的完整URL。注意你必须使用helm repo add在本地添加仓库
你可以使用仓库的名称代替URL

helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com

dependencies:
  - name: awesomeness
    version: 1.0.0
    repository: "@fantastic-charts"

一旦你定义好了依赖，运行 helm dependency update 就会使用你的依赖文件下载所有你指定的chart到你的charts/目录。

$ helm dep up foochart
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "local" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "example" chart repository
...Successfully got an update from the "another" chart repository
Update Complete. Happy Helming!
Saving 2 charts
Downloading apache from repo https://example.com/charts
Downloading mysql from repo https://another.example.com/charts

当 helm dependency update 拉取chart时，会在charts/目录中形成一个chart包。因此对于上面的示例，会在chart目录中期望看到以下文件：

charts/
  apache-1.2.3.tgz
  mysql-3.2.1.tgz

依赖中的tag和条件字段

除了上面的其他字段外，每个需求项可以包含可选字段 tags 和 condition。

所有的chart会默认加载。如果存在 tags 或者 condition 字段，它们将被评估并用于控制它们应用的chart的加载。

Condition - 条件字段field 包含一个或多个YAML路径（用逗号分隔）。如果这个路径在上层values中已存在并解析为布尔值，chart会基于布尔值启用或禁用chart。只会使用列表中找到的第一个有效路径，如果路径为未找到则条件无效。

Tags - tag字段是与chart关联的YAML格式的标签列表。在顶层value中，通过指定tag和布尔值，可以启用或禁用所有的带tag的chart。

# parentchart/Chart.yaml

dependencies:
  - name: subchart1
    repository: http://localhost:10191
    version: 0.1.0
    condition: subchart1.enabled, global.subchart1.enabled
    tags:
      - front-end
      - subchart1
  - name: subchart2
    repository: http://localhost:10191
    version: 0.1.0
    condition: subchart2.enabled,global.subchart2.enabled
    tags:
      - back-end
      - subchart2

# parentchart/values.yaml

subchart1:
  enabled: true
tags:
  front-end: false
  back-end: true

在上面的例子中，所有带 front-endtag的chart都会被禁用，但只要上层的value中 subchart1.enabled 路径被设置为 'true'，该条件会覆盖 front-end标签且 subchart1 会被启用。

一旦 subchart2使用了back-end标签并被设置为了 true，subchart2就会被启用。也要注意尽管subchart2 指定了一个条件字段，但是上层value没有相应的路径和value，因此这个条件不会生效。

使用带有标签和条件的CLI

--set 参数一如既往可以用来设置标签和条件值。

helm install --set tags.front-end=true --set subchart2.enabled=false

标签和条件的解析

条件（当设置在value中时）总是会覆盖标签 第一个chart条件路径存在时会忽略后面的路径。
标签被定义为 '如果任意的chart标签是true，chart就可以启用'。
标签和条件值必须被设置在顶层value中。
value中的tags:键必须是顶层键。全局和嵌套的tags:表现在不支持了。

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。

模板文件

模板文件遵守书写Go模板的标准惯例（查看文本/模板 Go 包文档了解更多）。模板文件的例子看起来像这样：

apiVersion: v1
kind: ReplicationController
metadata:
  name: deis-database
  namespace: deis
  labels:
    app.kubernetes.io/managed-by: deis
spec:
  replicas: 1
  selector:
    app.kubernetes.io/name: deis-database
  template:
    metadata:
      labels:
        app.kubernetes.io/name: deis-database
    spec:
      serviceAccount: deis-database
      containers:
        - name: deis-database
          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}
          imagePullPolicy: {{ .Values.pullPolicy }}
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_STORAGE
              value: {{ default "minio" .Values.storage }}

上面的例子，松散地基于 github.com/deis/charts，是一个Kubernetes副本控制器的模板。可以使用下面四种模板值（一般被定义在values.yaml文件）：

imageRegistry: Docker镜像的源注册表
dockerTag: Docker镜像的tag
pullPolicy: Kubernetes的拉取策略
storage: 后台存储，默认设置为"minio"

预定义的Values

Values通过模板中.Values对象可访问的values.yaml文件（或者通过 --set 参数)提供，但可以模板中访问其他预定义的数据片段。

以下值是预定义的，对每个模板都有效，并且可以被覆盖。和所有值一样，名称 区分大小写。

Release.Name: 版本名称(非chart的)
Release.Namespace: 发布的chart版本的命名空间
Release.Service: 组织版本的服务
Release.IsUpgrade: 如果当前操作是升级或回滚，设置为true
Release.IsInstall: 如果当前操作是安装，设置为true
Chart: Chart.yaml的内容。因此，chart的版本可以从 Chart.Version 获得，并且维护者在Chart.Maintainers里。
Files: chart中的包含了非特殊文件的类图对象。这将不允许您访问模板，但是可以访问现有的其他文件（除非被.helmignore排除在外）。使用{{ index .Files "file.name" }}可以访问文件或者使用{{.Files.Get name }}功能。您也可以使用{{ .Files.GetBytes }}作为[]byte访问文件内容。
Capabilities: 包含了Kubernetes版本信息的类图对象。({{ .Capabilities.KubeVersion }}) 和支持的Kubernetes API 版本({{ .Capabilities.APIVersions.Has "batch/v1" }})

注意： 任何未知的Chart.yaml字段会被抛弃。在Chart对象中无法访问。因此， Chart.yaml不能用于将任意结构的数据传递到模板中。不过values文件可用于此。

Values文件

imageRegistry: "quay.io/deis"
dockerTag: "latest"
pullPolicy: "Always"
storage: "s3"

values文件被定义为YAML格式。chart会包含一个默认的values.yaml文件。 Helm安装命令允许用户使用附加的YAML values覆盖这个values：

$ helm install --generate-name --values=myvals.yaml wordpress

以这种方式传递值时，它们会合并到默认的values文件中。比如，myvals.yaml文件如下：

storage: "gcs"

当在chart中这个值被合并到values.yaml文件中时，生成的内容是这样：

imageRegistry: "quay.io/deis"
dockerTag: "latest"
pullPolicy: "Always"
storage: "gcs"

注意只有最后一个字段会覆盖。

注意： chart包含的默认values文件必须被命名为values.yaml。不过在命令行指定的文件可以是其他名称。

注意： 如果helm install或helm upgrade使用了--set参数，这些值在客户端会被简单地转换为YAML。

注意： 如果values 文件存在任何必需的条目，它们会在chart模板中使用 'required' 函数声明为必需的。

然后使用模板中的.Values对象就可以任意访问这些值了：

apiVersion: v1
kind: ReplicationController
metadata:
  name: deis-database
  namespace: deis
  labels:
    app.kubernetes.io/managed-by: deis
spec:
  replicas: 1
  selector:
    app.kubernetes.io/name: deis-database
  template:
    metadata:
      labels:
        app.kubernetes.io/name: deis-database
    spec:
      serviceAccount: deis-database
      containers:
        - name: deis-database
          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}
          imagePullPolicy: {{ .Values.pullPolicy }}
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_STORAGE
              value: {{ default "minio" .Values.storage }}

范围，依赖和值

Values文件可以声明顶级chart的值，以及charts/目录中包含的其他任意chart。或者换个说法，values文件可以为chart及其任何依赖项提供值。比如，上面示范的WordPress chart同时有 mysql 和 apache 作为依赖。values文件可以为以下所有这些组件提供依赖：

title: "My WordPress Site" # Sent to the WordPress template

mysql:
  max_connections: 100 # Sent to MySQL
  password: "secret"

apache:
  port: 8080 # Passed to Apache

更高阶的chart可以访问下面定义的所有变量。因此WordPress chart可以用.Values.mysql.password访问MySQL密码。但是低阶的chart不能访问父级chart，所以MySQL无法访问title属性。同样也无法访问apache.port。

Values 被限制在命名空间中，但是命名空间被删减了。因此对于WordPress chart，它可以用.Values.mysql.password访问MySQL的密码字段。但是对于MySQL chart，值的范围被缩减了且命名空间前缀被移除了，因此它把密码字段简单地看作.Values.password。

全局Values

从2.0.0-Alpha.2开始，Helm 支持特殊的"global"值。设想一下前面的示例中的修改版本：

title: "My WordPress Site" # Sent to the WordPress template

global:
  app: MyWordPress

mysql:
  max_connections: 100 # Sent to MySQL
  password: "secret"

apache:
  port: 8080 # Passed to Apache

上面添加了global部分和一个值app: MyWordPress。这个值以.Values.global.app在所有 chart中有效。

比如，mysql模板可以以{{.Values.global.app}}访问app，同样apachechart也可以访问。实际上，上面的values文件会重新生成为这样：

title: "My WordPress Site" # Sent to the WordPress template

global:
  app: MyWordPress

mysql:
  global:
    app: MyWordPress
  max_connections: 100 # Sent to MySQL
  password: "secret"

apache:
  global:
    app: MyWordPress
  port: 8080 # Passed to Apache

架构文件

有时候，chart容器可能想基于它们的values值定义一个结构，这可以在values.schema.json文件中定义一个架构实现。架构使用 JSON 架构表示。看起来像这样：

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        }
      },
      "type": "object"
    },
    "name": {
      "description": "Service name",
      "type": "string"
    },
    "port": {
      "description": "Port",
      "minimum": 0,
      "type": "integer"
    },
    "protocol": {
      "type": "string"
    }
  },
  "required": [
    "protocol",
    "port"
  ],
  "title": "Values",
  "type": "object"
}

这个架构会应用values值并验证它。当执行以下任意命令时会进行验证：

helm install
helm upgrade
helm lint
helm template

一个符合此架构要求的values.yaml文件示例如下所示：

name: frontend
protocol: https
port: 443

注意这个架构被应用到了最终的 .Values 对象，而不仅仅是values.yaml文件。这意味着下面的yaml文件是有效的，给定的chart是用下面显示的适当的--set选项安装的：

name: frontend
protocol: https

Helm