超级会员免费看
Helm 插件、启动器与图表 API 版本详解
1. Helm 动态补全功能
Helm 提供了动态补全功能，通过以下代码可以实现：
if [[ "${flag}" == "${INPUT}"* ]]; then
echo "${flag}"
fi
done
fi
当运行插件并输入
animals list
后按下 Tab 键，会显示所有可用的动物类别列表：
$ helm zoo animals list # (press Tab key)
birds cats reptiles
若要确保其动态性，可以向
animals.txt
文件中添加额外的类别，例如添加 “monkeys”：
$ echo "monkeys" >> "${HOME}/animals.txt"
$ helm zoo animals list # (press Tab key)
birds cats monkeys reptiles
需要注意的是，如果已经使用
completion.yaml
文件进行静态补全，即使插件根目录中存在
plugin.complete
可执行文件，也不会使用动态补全。
2. Helm 启动器（Starters）
启动器类似于 Helm 图表，但它们是作为新图表的模板使用的。
-
使用内置启动器创建新图表
：使用
helm create
命令创建新图表时，会使用 Helm 的内置启动器生成一个新图表，这是一个遵循最佳实践的通用图表。
-
使用自定义启动器
：可以在创建新图表时使用
--starter
选项指定自定义启动器，例如：
$ helm create --starter basic-webapp superapp
使用启动器可以利用之前为类似应用程序构建的图表，有助于快速启动具有相似需求的新项目，并立即部署到 Kubernetes 环境中。
3. 将图表转换为启动器
任何 Helm 图表都可以转换为启动器，启动器与标准图表的唯一区别在于启动器的模板中存在对图表名称的动态引用。
将标准图表转换为启动器的步骤如下：
1. 把模板中对图表名称的硬编码引用替换为
<CHARTNAME>
。
例如，有一个名为
mychart
的图表，其简单的 ConfigMap 模板如下：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "mychart.fullname" . }}
labels:
{{- include "mychart.labels" . | nindent 4 }}
data:
hello: {{ .Values.hello | quote }}
转换为启动器后的模板为：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "<CHARTNAME>.fullname" . }}
labels:
{{- include "<CHARTNAME>.labels" . | nindent 4 }}
data:
hello: {{ .Values.hello | quote }}
-
该图表仍需包含
Chart.yaml文件才能正常工作，但它会被生成器覆盖。
4. 使启动器对 Helm 可用
在使用启动器之前，需要为其指定一个唯一的名称，例如 “basic - webapp”。要使这个启动器在命令行中使用
--starter
标志时成为有效选项，它必须作为一个目录存在于
$(helm env HELM_DATA_HOME)/starters
路径下。
具体操作步骤如下：
1. 确保顶级
starters
目录存在：
$ export HELM_STARTERS="$(helm env HELM_DATA_HOME)/starters"
$ mkdir -p "${HELM_STARTERS}"
-
将整个
basic - webapp目录复制到顶级目录中：
cp -r basic-webapp "${HELM_STARTERS}"
5. 使用启动器
启动器可用后，可以在命令行中引用其名称来生成基于它的新图表：
$ helm create --starter basic-webapp superapp
Creating superapp
新生成的图表结构将与启动器相同，启动器模板中所有对
<CHARTNAME>
的引用将被新图表的名称（如
superapp
）替换。例如，基于一个仅定义了
deployment.yaml
和
service.yaml
两个模板的启动器生成的图表目录结构如下：
$ tree superapp/
superapp/
├── Chart.yaml
├── templates
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
从这里开始，可以将新图表纳入版本控制，并进行定制以适应特定应用程序。
6. 进一步扩展 Helm
除了使用插件和启动器扩展 Helm 外，还可以通过开源贡献来扩展它。Helm 项目的发展离不开全球众多开发者的开源贡献，包括对 Go 源代码的修改、测试和文档更新等。如果想为 Helm 项目做出贡献，可以访问 Helm 社区主页了解更多信息。
7. 图表 API 版本
图表 API 版本在每个图表的
Chart.yaml
文件中指定，Helm 使用它来确定如何解析图表以及提供哪些功能集。
7.1 API 版本 2
Chart API 版本 2 是在 Helm 3 中引入的当前 API 版本，使用
helm create
创建新图表时默认使用此版本。使用 API 版本 2 的图表保证能被 Helm 3 支持，但不一定能被 Helm 2 支持。如果只计划支持 Helm 3 及以上版本，建议使用此 API 版本。
Chart.yaml
文件示例：
apiVersion: v2
name: lemon
version: 1.2.3
type: application
description: When life gives you lemons, do the DevOps
appVersion: 2.0.0
home: https://example.com
icon: https://example.com/img/lemon.png
sources:
- https://github.com/myorg/mychart
keywords:
- fruit
- citrus
maintainers:
- name: Carly Jenkins
email: carly@mail.cj.example.com
url: https://cj.example.com
- name: William James Spode
email: william.j@mail.wjs.example.com
url: https://wjs.example.com
deprecated: false
annotations:
sour: 1
kubeVersion: ">=1.14.0"
dependencies:
- name: redis
version: ~10.5.7
repository: https://kubernetes-charts.storage.example.com/
condition: useCache,redis.enabled
- name: postgresql
version: 8.6.4
repository: @myrepo
tags:
- database
- backend
各字段说明如下：
| 字段 | 说明 |
| ---- | ---- |
|
apiVersion
| 图表的 API 版本，必须设置为
v2
|
|
name
| 图表的名称，通常与应用程序名称一致，由小写字母、数字和连字符组成 |
|
version
| 图表的当前版本，严格遵循语义化版本 2 格式 |
|
type
| 图表类型，可为
application
或
library
|
|
description
| 图表的简单描述 |
|
appVersion
| 图表所代表的应用程序的版本 |
|
home
| 图表和/或应用程序的主页绝对 URL |
|
icon
| 图表的图标绝对 URL |
|
sources
| 图表源代码的绝对 URL |
|
keywords
| 图表代表的关键词列表 |
|
maintainers
| 维护图表的人员信息列表 |
|
deprecated
| 图表是否已弃用 |
|
annotations
| 图表的额外映射，供其他应用程序检查 |
|
kubeVersion
| 图表正确安装所需的最小 Kubernetes 版本的 SemVer 约束 |
|
dependencies
| 图表的依赖列表 |
当图表的
Chart.yaml
文件中列出依赖项时，每次运行
helm dependency update
命令都会生成并更新一个名为
Chart.lock
的特殊文件。例如：
dependencies:
- name: redis
repository: https://kubernetes-charts.storage.example.com/
version: 10.5.7
- name: postgresql
repository: https://charts.example.com/
version: 8.6.4
digest: sha256:529608876e9f959460d0521eee3f3d7be67a298a4c9385049914f44bd75ac9a9
generated: "2020-07-17T11:10:34.023896-05:00"
7.2 API 版本 1（遗留版本）
Chart API 版本 1 是原始 API 版本，也是 Helm 2 唯一识别的版本。在 Helm 2 中，所有图表都假定遵循 API 版本 1；在 Helm 3 中，
apiVersion
字段是严格必需的。使用 API 版本 1 的图表保证能被 Helm 2 和 Helm 3 支持，但可能无法支持未来仅为 Helm 3 提供的某些功能。
Chart.yaml
文件示例：
apiVersion: v1
name: lemon
version: 1.2.3
description: When life gives you lemons, do the DevOps
appVersion: 2.0.0
home: https://example.com
icon: https://example.com/img/lemon.png
sources:
- https://github.com/myorg/mychart
keywords:
- fruit
- citrus
maintainers:
- name: Carly Jenkins
email: carly@mail.cj.example.com
url: https://cj.example.com
- name: William James Spode
email: william.j@mail.wjs.example.com
url: https://wjs.example.com
deprecated: false
annotations:
sour: 1
kubeVersion: ">=1.14.0"
tillerVersion: ">=2.12.0"
engine: gotpl
与 API 版本 2 的差异如下：
-
apiVersion
字段设置为
v1
，在 Helm 2 中该字段不是严格必需的。
- 缺少
type
字段，API 版本 1 中没有库图表的概念。
- 缺少
dependencies
字段，API 版本 1 中图表依赖项在
requirements.yaml
文件中指定。
- 存在两个额外字段：
tillerVersion
和
engine
。
requirements.yaml
文件示例：
dependencies:
- name: redis
version: ~10.5.7
repository: https://kubernetes-charts.storage.example.com/
condition: redis.enabled
- name: postgresql
version: 8.6.4
repository: "@myrepo"
tags:
- database
- backend
在 API 版本 1 中，图表依赖项锁定文件名为
requirements.lock
，其格式和用途与 API 版本 2 中的
Chart.lock
文件相同。
8. 图表仓库 API
图表仓库 API 很轻量级，只需要实现一个必需的 HTTP 端点：
GET /index.yaml
。
在 99% 的情况下，图表仓库还会提供图表包 tarball 文件（
.tgz
）和相关的证明文件（
.prov
），但也可以将这些文件托管在单独的域上。
index.yaml
文件代表仓库索引，包含仓库中所有可用图表版本的完整列表，其格式特定于 Helm，目前只有一个 API 版本（1）。
当实现图表仓库 API 时，服务必须提供相对于所提供的仓库 URL 的
HTTP GET /index.yaml
路由，该请求的响应必须返回状态码
200 OK
，并且响应体必须是有效的
index.yaml
文件。例如，给定仓库 URL 为
https://example.com/charts
，则
GET /index.yaml
路由必须在
https://example.com/charts/index.yaml
可访问。
综上所述，Helm 的插件、启动器和图表 API 版本等功能为 Kubernetes 应用程序的部署和管理提供了强大而灵活的工具，通过合理使用这些功能，可以提高开发和运维效率。
Helm 插件、启动器与图表 API 版本详解
9. 总结与对比
为了更清晰地对比 Chart API 版本 1 和版本 2 的差异，我们可以通过以下表格进行总结：
| 对比项 | API 版本 1（遗留版本） | API 版本 2 |
| ---- | ---- | ---- |
|
apiVersion
| 设置为
v1
，Helm 2 中非严格必需 | 必须设置为
v2
|
|
type
| 无此概念，所有图表为应用图表 | 分为
application
和
library
两种类型 |
|
dependencies
| 在
requirements.yaml
文件中指定 | 在
Chart.yaml
文件中直接定义 |
|
tillerVersion
| 有此字段，指定 Tiller 版本要求 | 无此字段，Helm 3 不使用 Tiller |
|
engine
| 有此字段，默认
gotpl
| 无此字段 |
| 依赖锁定文件 |
requirements.lock
|
Chart.lock
|
下面是一个 mermaid 格式的流程图，展示了根据不同 Helm 版本和需求选择 Chart API 版本的过程：
graph TD;
A[选择 Chart API 版本] --> B{是否仅支持 Helm 3 及以上};
B -- 是 --> C[选择 API 版本 2];
B -- 否 --> D{是否需要库图表功能};
D -- 是 --> C;
D -- 否 --> E[选择 API 版本 1];
10. 操作步骤回顾
为了方便大家回顾和操作，这里将前面提到的关键操作步骤进行整理：
10.1 动态补全功能操作
- 实现动态补全代码：
if [[ "${flag}" == "${INPUT}"* ]]; then
echo "${flag}"
fi
done
fi
- 测试动态补全：
$ helm zoo animals list # (press Tab key)
- 添加额外类别并再次测试：
$ echo "monkeys" >> "${HOME}/animals.txt"
$ helm zoo animals list # (press Tab key)
10.2 启动器使用操作
-
将标准图表转换为启动器：
-
替换模板中硬编码的图表名称为
<CHARTNAME>。 -
确保图表包含
Chart.yaml文件。
-
替换模板中硬编码的图表名称为
-
使启动器对 Helm 可用：
-
确保顶级
starters目录存在：
-
确保顶级
$ export HELM_STARTERS="$(helm env HELM_DATA_HOME)/starters"
$ mkdir -p "${HELM_STARTERS}"
- 复制启动器目录到顶级目录：
cp -r basic-webapp "${HELM_STARTERS}"
- 使用启动器创建新图表：
$ helm create --starter basic-webapp superapp
10.3 图表依赖操作
-
API 版本 2：
-
在
Chart.yaml文件中定义依赖项。 -
运行
helm dependency update生成并更新Chart.lock文件。
-
在
-
API 版本 1：
-
在
requirements.yaml文件中定义依赖项。 -
运行相关命令生成并更新
requirements.lock文件。
-
在
11. 注意事项
在使用 Helm 的这些功能时，还需要注意以下几点：
-
动态补全
：如果已经使用
completion.yaml
文件进行静态补全，即使插件根目录中存在
plugin.complete
可执行文件，也不会使用动态补全。
-
启动器
：启动器模板中的
<CHARTNAME>
会在创建新图表时被替换为新图表的名称。
-
Chart API 版本
：选择合适的 API 版本取决于你的 Helm 版本支持和功能需求。如果仅支持 Helm 3 及以上，建议使用 API 版本 2；如果需要兼容 Helm 2 且不需要库图表功能，可以选择 API 版本 1。
12. 拓展思考
Helm 的这些功能为 Kubernetes 应用的部署和管理带来了很大的便利，但在实际使用中，我们还可以进一步拓展和优化：
-
动态补全
：可以结合远程查询功能，如查询 Kubernetes 集群中的资源，使动态补全更加智能和实用。
-
启动器
：可以创建更多类型的启动器，满足不同项目的需求，提高项目的启动效率。
-
Chart API 版本
：随着 Helm 的不断发展，未来可能会有新的 API 版本出现，我们需要关注其变化并及时调整使用。
通过对 Helm 插件、启动器、图表 API 版本和图表仓库 API 的深入了解和合理使用，我们可以更好地管理和部署 Kubernetes 应用程序，提高开发和运维的效率和质量。希望本文能对大家有所帮助，让大家在使用 Helm 的过程中更加得心应手。
扫一扫
19
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
