Helm 最小图表示例解剖从helm create alpine到可安装的 Pod 图表【免费下载链接】helmThe Kubernetes Package Manager项目地址: https://gitcode.com/GitHub_Trending/hel/helm这篇技术指南以 helm 仓库测试数据中的 alpine 子图表示例README.md为线索逐层拆解一个最小 Helm 图表的完整组成Chart.yaml元数据、templates/模板目录、values.yaml默认值以及helm install的安装方式。读完本文你将理解helm create生成的图表骨架中各文件与模板指令的真实作用并掌握如何参照该示例快速搭建自己的第一个 Helm 图表。示例的由来helm create alpine该 alpine 子图表位于测试数据目录internal/chart/v3/util/testdata/frobnitz/charts/alpine/其 README 明确说明这个示例是使用helm create alpine命令生成的。在 helm 源码中helm create的底层实现位于 internal/chart/v3/util/create.go其中的Create(name, dir string)函数见 create.go会完成以下工作使用正则^[a-zA-Z0-9._-]$与 250 字符长度上限校验图表名validateChartName见 create.go在目标目录下创建以图表名命名的子目录写入 12 类默认文件Chart.yaml、values.yaml、.helmignore、templates/ 下的 deployment.yaml、service.yaml、ingress.yaml、httproute.yaml、serviceaccount.yaml、hpa.yaml、NOTES.txt、_helpers.tpl、test-connection.yaml显式创建charts/依赖目录os.MkdirAll(filepath.Join(cdir, ChartsDir), 0o755)。值得注意现代helm create默认生成的模板要丰富得多Deployment、Service、Ingress 等而本文的 alpine 示例刻意保持极简——它只包含一个非常简单的 Pod 模板和极少的参数非常适合作为理解 Helm 图表渲染机制的入门标本。图表目录结构总览alpine 子图表的完整结构如下相对仓库根目录internal/chart/v3/util/testdata/frobnitz/charts/alpine/ ├── Chart.yaml # 图表元数据apiVersion: v3 ├── README.md # 本文所依据的示例说明 ├── values.yaml # 默认值文件README 中误写为 values.toml ├── templates/ │ └── alpine-pod.yaml # 唯一的模板文件一个极简 Pod └── charts/ # 子图表目录含 mast1/ 子图表与 mast2-0.1.0.tgz 打包文件这里有一个细节值得注意示例 README 提到 Thevalues.tomlfile contains the default values但仓库中实际的文件名是 values.yaml。Helm 约定俗成的默认值文件名就是values.yaml这一点可以从源码常量确认ValuesfileName values.yaml见 create.go。这属于测试数据中 README 的笔误实际行为以代码为准。Chart.yaml图表元数据alpine/Chart.yaml 内容如下apiVersion: v3 name: alpine description: Deploy a basic Alpine Linux pod version: 0.1.0 home: https://helm.sh/helm关键字段说明字段值作用apiVersionv3声明使用 Helm 3 图表格式chart.APIVersionV3区别于 Helm 2 的v1/v2namealpine图表名称须匹配^[a-zA-Z0-9._-]$并作为资源命名的一部分description单行描述人类可读的图表用途说明version0.1.0图表语义化版本每次修改模板或 appVersion 都需递增homeURL项目主页对比仓库中更完整的 frobnitz 主图表 Chart.yaml可以看到可选字段还包括keywords、maintainers、sources、icon、annotations和dependencies。在create.go的defaultChartfile模板中见 create.go还会默认生成type: application与appVersion: 1.16.0字段并附带注释说明应用图表application与库图表library的区别。模板文件templates/alpine-pod.yaml逐行解析核心模板文件 alpine-pod.yaml 是整个示例的精华apiVersion: v1 kind: Pod metadata: name: {{.Release.Name}}-{{.Chart.Name}} labels: app.kubernetes.io/managed-by: {{.Release.Service}} chartName: {{.Chart.Name}} chartVersion: {{.Chart.Version | quote}} spec: restartPolicy: {{default Never .restart_policy}} containers: - name: waiter image: alpine:3.3 command: [/bin/sleep,9000]这段模板展示了 Helm 模板引擎的四个核心机制内置对象访问{{.Release.Name}}、{{.Chart.Name}}、{{.Release.Service}}、{{.Chart.Version}}分别引用 Release 对象本次发布的名称与服务类型和 Chart 对象元数据。这些对象由模板引擎在渲染时注入其渲染入口可在 internal/chart/v3/loader/load.go 的图表加载链路中找到对应上下文构造逻辑。管道与函数{{.Chart.Version | quote}}将版本号通过quote函数转为带引号的字符串{{default Never .restart_policy}}则是在.restart_policy未定义时回退到默认值Never。这正是 Helm 模板中安全取值的常见写法——default函数可以避免空值直接渲染到 YAML 中导致格式错误。渲染结果以helm install my-alpine ./alpine为例上述模板会被渲染为名为my-alpine-alpine的 PodRelease.Name 拼接 Chart.Name标签中携带托管者Helm{{.Release.Service}}与图表版本0.1.0。镜像与命令image: alpine:3.3配合command: [/bin/sleep,9000]让 Pod 启动后挂起 9000 秒方便观察部署状态——这是一个典型的占位容器教学用法。values.yaml模板参数的默认值来源alpine/values.yaml 内容极简只有一行有效配置# The pod name name: my-alpineREADME 声称 values 文件包含alpine-pod.yaml模板的默认值但对照上面的模板可以发现实际模板引用的外部参数只有.restart_policy且已用default兜底Pod 名称则通过.Release.Name与.Chart.Name计算得出values.yaml中的name字段在渲染时并不会被模板直接消费。这说明该示例的 values 文件更偏向演示默认值文件的存在形式而非严格与模板一一对应——这正是入门示例常见的简化处理。作为对照helm create生成的完整默认 values 文件defaultValues常量见 create.go会包含replicaCount、image.repository/pullPolicy/tag、imagePullSecrets、serviceAccount、ingress、httpRoute、resources、livenessProbe、autoscaling等几十个带注释的参数并针对每个参数附上 Kubernetes 官方文档链接——这是编写生产级图表 values 文件的最佳参考模板。安装示例helm install ./alpineREADME 给出了唯一的实战命令helm install ./alpine这里省略了 release 名称Helm 会为本次发布自动生成一个随机名称。更完整的用法是显式指定名称并覆盖 valueshelm install my-alpine ./alpine helm install my-alpine ./alpine --set restart_policyOnFailure helm install my-alpine ./alpine -f my-values.yaml其中--set与-f分别对应命令行内联赋值与外部 values 文件覆盖二者合并后的最终值会参与模板渲染。安装后可通过helm list、helm status my-alpine、kubectl get pods观察结果用helm uninstall my-alpine清理。需要说明的适用前提执行安装要求集群上下文可用kubectl已配置而模板渲染本身不触达集群可通过helm template ./alpine或helm install --dry-run验证。测试数据中的验证依据该 alpine 子图表并非孤立存在而是嵌在 frobnitz 这个用于测试的复合图表中父级 Chart.yaml 声明了 alpine 与 mariner 两个依赖。仓库中的测试用例从多个角度验证了这类图表的行为load_test.go 通过Loader(testdata/frobnitz)加载整棵依赖树断言图表名称、模板文件与依赖子图表是否正确解析frobnitz-1.2.3.tgz的打包/解包也在 expand_test.go 中覆盖create_test.go 的TestCreate会真实调用Create(foo, tdir)生成新图表随后用loader.LoadDir重新加载并逐一断言 Chart.yaml、templates 目录、values.yaml 等 12 个文件全部存在create_test.go 的TestCreateFrom则以testdata/frobnitz/charts/mariner为源执行CreateFrom脚手架复制并验证模板内容中CHARTNAME占位符已被全部替换。这些测试共同印证了本文描述的图表结构约定templates/目录下的.yaml会被当作模板渲染values.yaml提供默认值charts/存放依赖子图表。理解 alpine 这个最小示例后再对照 create.go 中完整的默认模板与 values 常量即可从零编写结构规范、参数完备的 Helm 图表。【免费下载链接】helmThe Kubernetes Package Manager项目地址: https://gitcode.com/GitHub_Trending/hel/helm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Helm 最小图表示例解剖：从 `helm create alpine` 到可安装的 Pod 图表
Helm 最小图表示例解剖从helm create alpine到可安装的 Pod 图表【免费下载链接】helmThe Kubernetes Package Manager项目地址: https://gitcode.com/GitHub_Trending/hel/helm这篇技术指南以 helm 仓库测试数据中的 alpine 子图表示例README.md为线索逐层拆解一个最小 Helm 图表的完整组成Chart.yaml元数据、templates/模板目录、values.yaml默认值以及helm install的安装方式。读完本文你将理解helm create生成的图表骨架中各文件与模板指令的真实作用并掌握如何参照该示例快速搭建自己的第一个 Helm 图表。示例的由来helm create alpine该 alpine 子图表位于测试数据目录internal/chart/v3/util/testdata/frobnitz/charts/alpine/其 README 明确说明这个示例是使用helm create alpine命令生成的。在 helm 源码中helm create的底层实现位于 internal/chart/v3/util/create.go其中的Create(name, dir string)函数见 create.go会完成以下工作使用正则^[a-zA-Z0-9._-]$与 250 字符长度上限校验图表名validateChartName见 create.go在目标目录下创建以图表名命名的子目录写入 12 类默认文件Chart.yaml、values.yaml、.helmignore、templates/ 下的 deployment.yaml、service.yaml、ingress.yaml、httproute.yaml、serviceaccount.yaml、hpa.yaml、NOTES.txt、_helpers.tpl、test-connection.yaml显式创建charts/依赖目录os.MkdirAll(filepath.Join(cdir, ChartsDir), 0o755)。值得注意现代helm create默认生成的模板要丰富得多Deployment、Service、Ingress 等而本文的 alpine 示例刻意保持极简——它只包含一个非常简单的 Pod 模板和极少的参数非常适合作为理解 Helm 图表渲染机制的入门标本。图表目录结构总览alpine 子图表的完整结构如下相对仓库根目录internal/chart/v3/util/testdata/frobnitz/charts/alpine/ ├── Chart.yaml # 图表元数据apiVersion: v3 ├── README.md # 本文所依据的示例说明 ├── values.yaml # 默认值文件README 中误写为 values.toml ├── templates/ │ └── alpine-pod.yaml # 唯一的模板文件一个极简 Pod └── charts/ # 子图表目录含 mast1/ 子图表与 mast2-0.1.0.tgz 打包文件这里有一个细节值得注意示例 README 提到 Thevalues.tomlfile contains the default values但仓库中实际的文件名是 values.yaml。Helm 约定俗成的默认值文件名就是values.yaml这一点可以从源码常量确认ValuesfileName values.yaml见 create.go。这属于测试数据中 README 的笔误实际行为以代码为准。Chart.yaml图表元数据alpine/Chart.yaml 内容如下apiVersion: v3 name: alpine description: Deploy a basic Alpine Linux pod version: 0.1.0 home: https://helm.sh/helm关键字段说明字段值作用apiVersionv3声明使用 Helm 3 图表格式chart.APIVersionV3区别于 Helm 2 的v1/v2namealpine图表名称须匹配^[a-zA-Z0-9._-]$并作为资源命名的一部分description单行描述人类可读的图表用途说明version0.1.0图表语义化版本每次修改模板或 appVersion 都需递增homeURL项目主页对比仓库中更完整的 frobnitz 主图表 Chart.yaml可以看到可选字段还包括keywords、maintainers、sources、icon、annotations和dependencies。在create.go的defaultChartfile模板中见 create.go还会默认生成type: application与appVersion: 1.16.0字段并附带注释说明应用图表application与库图表library的区别。模板文件templates/alpine-pod.yaml逐行解析核心模板文件 alpine-pod.yaml 是整个示例的精华apiVersion: v1 kind: Pod metadata: name: {{.Release.Name}}-{{.Chart.Name}} labels: app.kubernetes.io/managed-by: {{.Release.Service}} chartName: {{.Chart.Name}} chartVersion: {{.Chart.Version | quote}} spec: restartPolicy: {{default Never .restart_policy}} containers: - name: waiter image: alpine:3.3 command: [/bin/sleep,9000]这段模板展示了 Helm 模板引擎的四个核心机制内置对象访问{{.Release.Name}}、{{.Chart.Name}}、{{.Release.Service}}、{{.Chart.Version}}分别引用 Release 对象本次发布的名称与服务类型和 Chart 对象元数据。这些对象由模板引擎在渲染时注入其渲染入口可在 internal/chart/v3/loader/load.go 的图表加载链路中找到对应上下文构造逻辑。管道与函数{{.Chart.Version | quote}}将版本号通过quote函数转为带引号的字符串{{default Never .restart_policy}}则是在.restart_policy未定义时回退到默认值Never。这正是 Helm 模板中安全取值的常见写法——default函数可以避免空值直接渲染到 YAML 中导致格式错误。渲染结果以helm install my-alpine ./alpine为例上述模板会被渲染为名为my-alpine-alpine的 PodRelease.Name 拼接 Chart.Name标签中携带托管者Helm{{.Release.Service}}与图表版本0.1.0。镜像与命令image: alpine:3.3配合command: [/bin/sleep,9000]让 Pod 启动后挂起 9000 秒方便观察部署状态——这是一个典型的占位容器教学用法。values.yaml模板参数的默认值来源alpine/values.yaml 内容极简只有一行有效配置# The pod name name: my-alpineREADME 声称 values 文件包含alpine-pod.yaml模板的默认值但对照上面的模板可以发现实际模板引用的外部参数只有.restart_policy且已用default兜底Pod 名称则通过.Release.Name与.Chart.Name计算得出values.yaml中的name字段在渲染时并不会被模板直接消费。这说明该示例的 values 文件更偏向演示默认值文件的存在形式而非严格与模板一一对应——这正是入门示例常见的简化处理。作为对照helm create生成的完整默认 values 文件defaultValues常量见 create.go会包含replicaCount、image.repository/pullPolicy/tag、imagePullSecrets、serviceAccount、ingress、httpRoute、resources、livenessProbe、autoscaling等几十个带注释的参数并针对每个参数附上 Kubernetes 官方文档链接——这是编写生产级图表 values 文件的最佳参考模板。安装示例helm install ./alpineREADME 给出了唯一的实战命令helm install ./alpine这里省略了 release 名称Helm 会为本次发布自动生成一个随机名称。更完整的用法是显式指定名称并覆盖 valueshelm install my-alpine ./alpine helm install my-alpine ./alpine --set restart_policyOnFailure helm install my-alpine ./alpine -f my-values.yaml其中--set与-f分别对应命令行内联赋值与外部 values 文件覆盖二者合并后的最终值会参与模板渲染。安装后可通过helm list、helm status my-alpine、kubectl get pods观察结果用helm uninstall my-alpine清理。需要说明的适用前提执行安装要求集群上下文可用kubectl已配置而模板渲染本身不触达集群可通过helm template ./alpine或helm install --dry-run验证。测试数据中的验证依据该 alpine 子图表并非孤立存在而是嵌在 frobnitz 这个用于测试的复合图表中父级 Chart.yaml 声明了 alpine 与 mariner 两个依赖。仓库中的测试用例从多个角度验证了这类图表的行为load_test.go 通过Loader(testdata/frobnitz)加载整棵依赖树断言图表名称、模板文件与依赖子图表是否正确解析frobnitz-1.2.3.tgz的打包/解包也在 expand_test.go 中覆盖create_test.go 的TestCreate会真实调用Create(foo, tdir)生成新图表随后用loader.LoadDir重新加载并逐一断言 Chart.yaml、templates 目录、values.yaml 等 12 个文件全部存在create_test.go 的TestCreateFrom则以testdata/frobnitz/charts/mariner为源执行CreateFrom脚手架复制并验证模板内容中CHARTNAME占位符已被全部替换。这些测试共同印证了本文描述的图表结构约定templates/目录下的.yaml会被当作模板渲染values.yaml提供默认值charts/存放依赖子图表。理解 alpine 这个最小示例后再对照 create.go 中完整的默认模板与 values 常量即可从零编写结构规范、参数完备的 Helm 图表。【免费下载链接】helmThe Kubernetes Package Manager项目地址: https://gitcode.com/GitHub_Trending/hel/helm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考