Helm
参考:
- docs: https://docs.helm.sh/
- github: https://github.com/helm
环境:
- el7x86_64
- helm v3.3
概述
Helm是Kubernetes生态系统中的一个软件包管理工具,主要用来管理Charts,有点类似于Ubuntu中的apt或CentOS中的yum。由go编写,是Deis公司发起的一个开源工具,有助于简化部署和管理Kubernetes应用。
在Kubernetes中,应用管理是需求最多、挑战最大的领域。Helm项目提供了一个统一软件打包方式,支持版本控制,可以大大简化Kubernetes应用分发与部署中的复杂性。
Helm Chart是用来封装 Kubernetes原生应用程序的一系列YAML文件。可以在你部署应用的时候自定义应用程序的一些 Metadata,以便于应用程序的分发。
对于应用发布者而言,可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言,使用 Helm 后不用需要编写复杂的应用部署文件,可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
The package manager for Kubernetes.
Helm is the best way to find, share, and use software built for Kubernetes.
术语
Glossary: https://helm.sh/docs/glossary/
Chart
Helm包涵盖了将k8s资源安装到k8s集群所需的足够多的信息。
Charts包含了Chart.yaml
文件核模板,默认值(values.yaml
),以及相关依赖。
Charts开发设计了良好定义的目录结构,并打包为chart archive。
Chart Archive
Chart包是被tar
和gzip
压缩(可选签名)的chart。
Chart Dependency(Subcharts)
Chart可以依赖于其它chart。依赖有两种方式:
- 软依赖(soft): 如果另一个chart没有在集群中安装,chart可能会无法使用
- 硬依赖(hard): chart包含它所依赖的chart。(在
charts/
目录中)
当一个chart打包(helm package
)时,所有的依赖都会和它绑定。
Chart Version
每个chart都需要版本号。
Chart.yaml
chart的信息说明被存储在一个特定文件(Chart.yaml
)。每个chart都必须有这个文件。
helm
Helm是k8s包管理器。作为一个操作系统包管理器,使其很容易在操作系统中安装工具。Helm使得k8s集群中安装应用和资源变得异常简单。
Helm Configuration Files
Helm将配置文件存储在XDG目录中。helm
第一次运行,会自动生成。
Kube Config(KUBECONFIG)
helm客户端通过Kube config配置文件来理解k8s集群。默认$HOME/.kube/config
。
Lint
Helm代码规范,规范一个chart是去验证其遵照Helm chart的标准规范和要求。Helm提供了helm lint
命令。
Provenance
Helm chart可以由来源文件(provenance file)提供chart的出处以及它所包含的内容。
来源文件(.prov
)是Helm安全的一部分。一个来源包含chart包文件的加密哈希值,Chart.yaml
数据,一个签名块。当再加上一个钥匙链(keychain)时,可为chart用户提供以下能力:
- 验证chart被可信第三方签名
- 验证chart文件没有被篡改
- 验证chart的元数据内容(
Chart.yaml
) - 快速匹配chart的数据来源
Release
发行版本。chart安装之后,Helm库会创建一个release来跟踪这个安装。
单个chart可以在同一个集群中安装多次,并能创建多个不同的版本。
Release Number/Version
单个版本号可以被升级多次。通过连续技术来跟踪升级发布版本。
Rollback
每一次发布会更新chart或者配置。当生成发布历史后,一次发布也可以被 rolled back 之前的发布版本号。回滚使用helm rollback
命令。
重要的是, 每一次回滚版本会生成一个新的发布版本号。
|
|
Helm Library(SDK)
Helm库(或SDK)涉及到go代码,可以直接与k8s API服务交互进行安装、升级、查询 以及移除k8s资源。
Repository
Helm chart可以被存储到专用的HTTP服务器上,称之为chart仓库。
Helm客户端可以指向零个或多个chart仓库。默认没有配置仓库,可使用helm repo add
添加。
Values
Values 提供了一种使用您自己的信息覆盖模板默认值的方式。
Helm Chart是参数化的, 这意味着chart开发者可以在安装时显式配置。比如说,chart可以暴露username
字段, 允许为服务设置一个用户名。这些可暴露的变量在Helm用语中称为values
。
Values可在helm install
, helm upgrage
时设置。也可以在values.yaml
文件中设置。
介绍
Introduction: https://helm.sh/docs/intro/
快速入门
Quickstart: https://helm.sh/docs/intro/quickstart/
如何快速安装核使用Helm。
先决条件
Prerequisites
使用Helm的前置条件:
- k8s集群
- 建议最新k8s稳定版
kubectl
- 安装的安全配置(如果有的话)
- 安装和配置Helm
注意Helm版本对应支持的k8s版本。
安装
Install: https://helm.sh/docs/intro/install/
从源码、或二进制安装Helm CLI。
从Helm项目
From The Helm Project
从二进制包:
- 下载特定版本包: https://github.com/helm/helm/releases
- 解压
- 添加到PATH
|
|
从脚本:
|
|
从源码
|
|
初始化Helm chart
Initialize a Helm Chart Repository
Helm安装好之后,你可以添加一个chart仓库。
|
|
安装Chart
Install an Example Chart
可以通过helm install
命令安装chart。
|
|
Releases
|
|
卸载Release
使用helm uninstall
命令卸载realease。
|
|
它会删除和该release相关的所有资源。使用--keep-history
选项,Helm将保存release history。所以你可以审计集群历史甚至使用helm rollback
回滚release。
主题
Topic Guides: https://helm.sh/docs/topics/
Charts
Charts: https://helm.sh/docs/topics/charts/
Helm使用的包格式称为charts。chart就是一个描述k8s相关资源的文件集合。单个chart可以用来部署简单或复杂的服务。
Chart是作为特定目录布局的文件被创建,它们可以打包到要部署的版本存档中。
|
|
文件结构
chart是一个组织在文件目录中的集合。目录名称就是chart名称(没有版本信息)。
示例:
|
|
Chart.yaml
Chart.yaml
文件是chart必须的。包含以下字段。
|
|
Chart和版本控制
每个chart都必须有版本号。版本必须遵循SemVer2标准。
|
|
Chart.yaml
文件中的version
字段被很多Helm工具使用。当生成一个包时,helm package
命令可以用Chart.yaml
文件中找到的版本号作为包名的token。系统假设chart包名中的版本号可以与Chart.yaml
文件中的版本号匹配。如果不满足这一假设会导致错误。
apiVersion字段
对于至少需要Helm3的chart,apiVersion
字段应该是v2
。
kubeVersion字段
可选的kubeVersion
字段可以在支持的k8s版本上定义语义约束,Helm 在安装chart时会验证这个版本约束, 并在集群运行不支持的k8s版本时显示失败。
版本约束可以包含空格、比较操作符、逻辑操作符。
|
|
deprecated字段
在Chart仓库管理chart时,有时需要废弃一个chart。deprecated
字段可用来标记已弃用的chart。如果latest版本被标记为已弃用,则所有的chart都会被认为是已弃用的。以后可以通过发布未标记为已弃用的新版本来重新使用chart名称。
kubernetes/charts
项目遵循的弃用charts的流程为:
- 升级chart的
Chart.yaml
文件,将这个文件标记为已弃用,并更改版本 - 在chart仓库中发布新版的chart
- 从源仓库中移除这个chart
type字段
type
字段定义了chart的类型。有两种类型:
application
:默认类型,是可以完全操作的标准chart。library
:不能安装,提供针对chart构建的实用程序和功能。通常不包含任何资源对象。
应用类型chart 可以作为库类型chart使用。可以通过将类型设置为library
来实现。 然后这个库就被渲染成了一个库类型chart,所有的实用程序和功能都可以使用。所有的资源对象不会被渲染。
许可证和描述
Chart LICENSE, README and NOTES
Chart也可以包含描述安装、配置和使用的文件,以及chart许可证。
LICENSE是一个包含了chart license的纯文本文件。chart可以包含一个许可证,因为在模板里不只是配置,还可能有编码逻辑。如果需要,还可以为chart安装的应用程序提供单独的许可证。
README自述文件,一般包含:
- chart提供的应用或服务的描述
- 运行chart的先决条件或要求
values.yaml
的可选项和默认值的描述- 与chart的安装或配置相关的其它信息
chart也会包含一个简短的纯文本templates/NOTES.txt
文件,这会在安装后及查看版本状态时打印出来。由于此文件是在运行helm install
或helm status
时打印到STDOUT的,因此建议保持内容简短,并指向自述文件以获取更多详细信息。
依赖
Chart Dependencies
Helm中,chart可能会依赖其它任意个chart。这些依赖可使用dependencies
字段(Chart.yaml
)动态链接,或写入charts/
目录。
dependencies字段
当前chart依赖的其它chart会在dependencies
字段定义为一个列表。
|
|
必须使用helm repo add
在本地添加仓库。
一旦你定义好了依赖,运行helm dependency update
就会使用你的依赖文件下载所有你指定的chart到你的charts/
目录。
alias字段
为依赖chart添加一个别名,会使用别名作为新依赖chart的名称。 需要使用其他名称访问chart时可以使用alias
。
|
|
tags和condition字段
|
|
|
|
|
|
通过依赖导入sub values
在某些情况下,允许子chart的值作为公共默认传递到父chart中是值得的。
|
|
|
|
通过charts目录手动管理依赖
如果对依赖进行更多控制,通过将有依赖关系的chart复制到charts/
目录中来显式表达这些依赖关系。
要将依赖放入charts/
目录,使用helm pull
命令。
Templates and Values
Helm Chart模板是按照Go模板语言书写。让我想起了Django模板语言,Jinja2模板语言。
所有模板语言存放在chart的templates/
目录下。当Helm渲染chart时,它会通过模板引擎遍历目录中的每个文件。
模板的Value通过两种方式提供:
- 通过
values.yaml
文件提供,此文件包含了默认值。 - 用户可以提供一个包含value的yaml文件,在
helm install
时使用它。
当用户提供自定义的value时,会覆盖values.yaml
中的值。
模板文件示例
|
|
预定义的Values
以下值是预定义的,对每个模板都有效,并且可以被覆盖。和所有值一样,名称 区分大小写:
Release.Name
: 版本名称(非chart的)Release.Namespace
: 发布的chart版本的命名空间Release.Service
: 组织版本的服务Release.IsUpgrade
: 如果当前操作是升级或回滚,设置为trueRelease.IsInstall
: 如果当前操作是安装,设置为trueChart
:Chart.yaml
的内容。因此,chart的版本可以从Chart.Version
获得, 并且维护者在Chart.Maintainers
里Files
:chart中的包含了非特殊文件的类图对象Capabilities
: 包含了Kubernetes版本信息的类图对象
范围
Scope, Dependencies, and Values
Values文件可以声明顶级chart的值,以及charts/
目录中包含的其他任意chart。
全局Values
Helm支持特殊的global
值。
|
|
这个值以.Values.global.app
在所有chart中有效。
架构文件
有时候,chart容器可能想基于它们的values值定义一个结构,这可以在values.schema.json
文件中定义一个架构实现。
示例:
|
|
这个架构会应用values值并验证它。当执行以下任意命令时会进行验证: helm install, helm upgrage, helm lint, helm template
。
用户自定义资源
Custom Resource Definitions
k8s提供了一种声明k8s新类型对象的机制。使用CustomResourceDefinition(CRD),k8s开发者可以声明自定义资源类型。
Helm3中,CRD被视为一种特殊的对象。它们被安装在chart的其他部分之前,并受到一些限制。
CRD YAML文件应被放置在chart的crds/
目录中。 多个CRD(用YAML的开始---
和结束符...
分隔)可以被放置在同一个文件中。Helm会尝试加载CRD目录中所有的文件到k8s。
当Helm安装新chart时,会上传CRD,暂停安装直到CRD可以被API服务使用,然后启动模板引擎, 渲染chart其他部分,并上传k8s。
CRD的限制
不像大部分k8s对象,CRD是全局安装的。因此Helm管理CRD时会采取非常谨慎的方式。 CRD受到以下限制:
- CRD从不重新安装。 如果Helm确定
crds/
目录中的CRD已经存在(忽略版本),Helm不会安装或升级。 - CRD从不会在升级或回滚时安装。Helm只会在安装时创建CRD。
- CRD从不会被删除。自动删除CRD会删除集群中所有命名空间中的所有CRD内容。因此Helm不会删除CRD。
希望升级或删除CRD的操作员应该谨慎地手动执行此操作。
管理chart
Using Helm to Manage Charts
helm
工具有一些命令用来处理chart。
|
|
仓库
Chart Repositories
当helm
用来管理本地chart目录时, 共享chart时,首选的机制就是使用chart仓库。
仓库的主要特征存在一个名为index.yaml
的特殊文件,文件中包含仓库提供的包的完整列表, 以及允许检索和验证这些包的元数据。
在客户端,仓库使用helm repo
命令管理。然而,Helm不提供上传chart到远程仓库的工具。 这是因为这样做会给执行服务器增加大量的必要条件,也就增加了设置仓库的障碍。
Starter Packs
helm create
命令可以附带一个可选的--starter
选项指定一个starter chart。Starter就只是普通chart,但是被放置在$XDG_DATA_HOME/helm/starters
。
Hooks
Chart Hooks: https://helm.sh/docs/topics/charts_hooks/
Helm提供了一个hook机制,使chart开发者在发行版(release)生命周期的特定点进行干预。你可以使用hooks做以下事情:
- 安装过程中,在chart载入之前载入configmap或secret。
- 在安装一个新chart之前,执行一个作业(job)来备份数据库,然后执行第二个作业还原数据库。
- 在删除一个release之气,运行一个作业,在移除之前,来优雅地取出服务轮询。
hooks工作像常规模板,但它们有特殊的注释(写在annotations下),因此helm可以不同地使用它们。本章节,我们将介绍hooks的基本使用模式。
|
|
可用的hooks
Annotation | Value | Description |
---|---|---|
pre-install |
- | 模板渲染之后执行,但在k8s创建任何资源之前 |
post-install |
- | 所有资源载入k8s后执行 |
pre-delete |
- | 在从k8s删除任意资源前,执行一个删除请求 |
post-delete |
- | 在所有release的资源被删除后,执行一个删除请求 |
pre-upgrade |
- | 在模板渲染后,执行一个升级请求,但在任意资源升级之前 |
post-upgrade |
- | 在所有资源都升级后,执行一个升级 |
pre-rollback |
- | 在模板渲染后,执行一个回滚请求,但在任意资源回滚前 |
post-rollback |
- | 在所有资源都被修改后,执行一个回滚请求 |
test |
- | 当heml test子命令调用时执行 |
测试
Chart Tests: https://helm.sh/docs/topics/chart_tests/
chart包含许多k8s资源和协同工作的组件。作为包作者,你可能想编写一个测试,来验证包安装时是否如预期那样工作。
helm chart中的测试位于templates/
目录下,是一个作业(job)定义,指定一个容器运行特定的命令。容器成功退出(exit 0),被认为测试成功。作业定义必须包含helm.sh/hook: test
的注释。
示例测试:
- 验证
values.yaml
文件被正确配置 - 验证服务、负载均衡正常
- 等等
可在helm中运行预定义测试,在release上使用helm test <RELEASE_NAME>
命令。对于包的使用者,这是一个检测release of chart工作正常的方式。
示例
Example Test
|
|
templates/tests/test-mariadb-connection.yaml
的内容:
|
|
运行测试:
|
|
注意:
- 你可以在
templates/
目录下定义许多测试 - 你可以嵌套你的测试
<chart-name>/templates/tests/
- 一个测试就是一个helm hook
Library
Library Charts: https://helm.sh/docs/topics/library_charts/
A library chart is a type of Helm chart,定义chart可通过helm模板在其它charts中共享。
完整性校验
Helm Provenance and Integrity: https://helm.sh/docs/topics/provenance/
helm有来源工具,帮助chart user验证包的来源和完整性。使用基于行业标准的PIK, GnuPG等备受推崇的包管理器,Helm 可以生成和验证签名文件。
|
|
仓库
Chart Repository: https://helm.sh/docs/topics/chart_repository/
官方的chart repo由Kubernetes Charts项目维护。欢迎各位参与。Helm也使得创建和运行自己的chart repo变得很容易。
创建仓库
Create a chart repository: https://helm.sh/docs/topics/chart_repository/
一个chart repo是一个HTTP服务器,它容纳了一个index.yaml
文件和一些包。当你准备好分享你的charts,方法是将它们上传到一个chart repository。你可以使用GCS, S3, GitHub Pages等来创建你自己的web服务器。
注册中心
Registries: https://helm.sh/docs/topics/registries/
Helm 3 支持OCI用于包分发。 Chart包可以通过基于OCI的注册中心存储和分发。
|
|
使用上述命令存储的chart会被缓存到文件系统中。OCI 镜像设计规范 严格遵守文件系统布局的。如:
|
|
架构
Helm Architecture: https://helm.sh/docs/topics/architecture/
介绍Helm在高级别的架构。
目的
The Purpose of Helm
Helm是管理称为chart的k8s包的工具。Helm可以做以下事情:
- 从头开始创建一个新的charts
- packages charts为归档(tgz) chart文件
- 与chart repo交互,并存储在那
- 安装和卸载charts到k8s集群
- 管理已安装的charts的发行版
对于Helm,有三个重要的概念:
- chart是创建一个k8s应用实例所需的信息束
- config包含配置信息,可以合并到package chart来创建一个可发行的对象
- release是一个运行的chart实例,包含特定的配置
组件
Components
Helm被实现为两个不同部分来执行:
Helm CLI客户端,负责以下事情:
- 本地chart开发
- 管理repo
- 管理release
- 与Helm Library接口
- 发送chart安装
- 请求升级或卸载releases
Helm Library提供了执行所有helm操作的逻辑。与k8s API接口交互,并提供以下功能:
- 组合chart和配置来构建一个release
- 安装chart到k8s,并提供release对象
- 通过与k8s交互,升级和卸载chart
实现
Implementation
Helm client和library由go编写。library使用k8s client与k8s集群通信。目前,library使用REST+JSON
。它存储信息在k8s内的secrets里,不需要自己的数据库。配置文件以YAML编写。
高级技术
Advanced Helm Techniques: https://helm.sh/docs/topics/advanced/
后置渲染
Post Rendering
GO SDK
后端存储
Storage backends
RBAC
Role-based Access Control: https://helm.sh/docs/topics/rbac/
k8s rbac: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
介绍Helm如何与k8s RBAC进行交互。
在k8s中,授权角色给特定用户或应用的服务账号(service account),以确保应用程序的操作在特定范围内。从k8s v1.6开始,RBAC默认启用。
使用RBAC,你可以:
- 授权特权操作给管理员
- 限制用户在特定命名空间/集群范围创建资源的能力
- 限制用户在特定命名空间/集群范围内查看资源的能力
管理用户账户
Managing user accounts
所有的k8s集群有两种类型的用户:
- service accounts managed by Kubernetes
- normal users
普通用户假定由外部进行管理,独立的服务。管理员分发私钥,用户存储密码,甚至是用户名密码列表这样的文件。在这方面,k8s不具有代表普通用户账户的对象。普通用户无法通过API调用被添加到集群。
相比之下,服务账号是由k8s API管理的用户。它们被绑定到特定的命名空间,通过API server自动创建,或通过API调用手动创建。服务账号绑定在一组凭据里,存储为secret,它被挂载到pod,允许集群内进程与k8s API进行交谈。
API请求被绑定到任何一个用户(普通用户、服务账号),或者被视为匿名请求。这意味着集群内或集群外的每一个进程,从工作站上输入kubectl
的人类用户,到节点上的kubelets,到控制面板的成员,在进行请求API server时必须进行认证,或被视为匿名用户。
角色、集群角色、角色绑定、集群角色绑定
Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings
在k8s中,用户账户和服务账户只能够根据授权访问来查看和修改资源。这种授权是通过使用角色(Roles)和角色绑定(RoleBindings)。角色和角色绑定被绑定到特定的命名空间,它通过角色提供授权,授予用户在此命名空间内查看或修改资源的能力。
在集群范围内,这些被称为集群角色(ClusterRoles)和集群角色绑定(ClusterRoleBindings)。授权用户集群角色,允许它们访问和修改整个集群的资源。这也需要查看和修改集群范围(命名空间,资源配额,节点)的资源。
集群角色可通过角色绑定的引用来绑定到特定的命名空间。admin
, edit
, view
是最常使用的默认集群角色。
k8s有一些默认的集群角色可用,它们的本意是面向用户的角色。它们包含超级角色(cluster-admin
),和细粒度访问的角色(admin
, edit
, view
)。
Default ClusterRole | Default ClusterRoleBinding | 描述 |
---|---|---|
cluster-admin | system:masters group | 允许超级用户访问对任意资源执行任意动作。 |
admin | None | 允许管理员访问,在命名空间内使用角色绑定来授权。如读写命名空间内的大部分资源,包括在命名空间内创建角色和角色绑定的能力。但不允许对资源配额或命名空间进行写操作。 |
edit | None | 允许在命名空间内读取大多数对象的权限,不允许查看或修改角色和角色绑定 |
view | None | 允许在命名空间内查看大多数对象的权限。不允许查看角色和角色绑定。不允许查看secrets。 |
限制用户账户使用RBAC访问
Restricting a user account access using RBAC
现在让我们了解基于角色的访问控制的基础知识,让我们讨论管理员如何限制用户的访问范围。
示例:授予用户命名空间范围的读写权限
Grant a user read/write access to a particular namespace
要限制用户对特定命名空间的读写权限,可以使用edit
或admin
角色。
此外,你还可以使用cluster-admin
来创建一个角色绑定。授予在命名空间范围内的cluster-admin
来提供在此命名空间内完整控制资源的权限,包含命名空间自身。
|
|
示例:授予用户集群范围的读写权限
Example: Grant a user read/write access at the cluster scope
如果用户希望安装chart,在集群范围内安装集群资源(ns, roles, crd…),它们将需要集群范围的写权限。要这样做,授予用户admin
或cluster-admin
角色权限。
|
|
示例:授予用户命名空间范围的只读权限
Example: Grant a user read-only access to a particular namespace
你可能注意到了,没有查看secret的集群角色。view
集群角色没有授予用户访问secret的权限。然而,Helm默认将release metadata存储为secret。
为了使用户运行helm list
,它需要读取这些secrets。为此,我们将创建一个特殊的secret-reader
集群角色。
|
|
|
|
示例:授予用户集群范围的只读权限
Example: Grant a user read-only access at the cluster scope
如果用户想运行helm l ist --all-namespaces
命令,API需要用户拥有集群范围内的读权限。
|
|
插件
The Helm Plugins Guide: https://helm.sh/docs/topics/plugins/
Helm plugin是一个可通过helm CLI访问的工具,但不是内置的helm基础代码的一部分。
V2迁移到V3
Migrating Helm v2 to v3: https://helm.sh/docs/topics/v2_v3_migration/
弃用的k8s api
Deprecated Kubernetes APIs: https://helm.sh/docs/topics/kubernetes_apis/
版本支持
Helm Version Support Policy: https://helm.sh/docs/topics/version_skew/
SQL存储后端的权限管理
Permissions management for SQL storage backend: https://helm.sh/docs/topics/permissions_sql_storage_backend/
最佳实践
The Chart Best Practices Guide: https://helm.sh/docs/chart_best_practices/
涵盖了Helm团队对创建chart的最佳做法。它侧重于chart应该如何构造。主要关注那些可能会公开部署的charts的最佳实践。
一般约定
General Conventions: https://helm.sh/docs/chart_best_practices/conventions/
chart名称
Chart Names
chart名称必须是小写字母和数字,可用-
隔开。
chart目录必须与chart名称相同。
|
|
版本号
Version Numbers
只要有可能,Helm使用SemVer2来表示版本号。请注意,Docker image tag并不一定遵循SemVer,注意。
格式化YAML
Formatting YAML
YAML应该使用两个空格(别使用tab)。
词
Usage of the Words Helm and Chart
Helm词的一些约定:
- Helm指作为一个整体的项目
helm
客户端CLIchart
不需要大写,它不是专有名词Chart.yaml
需要大写,因为该文件名是大小写敏感的
值
Values: https://helm.sh/docs/chart_best_practices/values/
提供给你如何组织和设计chart的values.yaml
文件,并使用你的值。
命名约定
Naming Conventions
变量名必须小写字母开头,使用驼峰分开:
|
|
请注意,所有Helm内置变量以大写字母开头,用户可以轻松区分开:
|
|
嵌套值
YAML是一种灵活的格式,值可以被深度嵌套。
|
|
|
|
使类型清晰
Make Types Clear
|
|
考虑用户如何使用你的值
Consider How Users Will Use Your Values
值有三个来源:
values.yaml
文件helm install -f
或helm upgrade -f
时指定的文件里--set
或--set-string
选项指定
当设计值的组织结构时,用户是希望可通过-f
或--set
选项来覆盖它们。YAML建议写成映射(mapping),便于替换--set servers.foo.port=80
。
|
|
values.yaml
每个在values.yaml
中定义的属性应该被记录(documented)。文档字符串应该用它描述的属性的名称开始,然后给出至少一个单句描述。
|
|
模板
Templates: https://helm.sh/docs/chart_best_practices/templates/
templates目录架构
Structure of templates/
templates/
目录应该是如下结构:
- 模板文件是
.yaml
扩展的YAML输出。.tpl
扩展可用于未经格式化的模板文件 - 模板文件名应使用虚线(example-configmap.yaml),而不是驼峰
- 每个资源定义应该有自己的模板文件
- 模板文件应放映资源类型(如
foo-pod.yaml
,bar-svc.yaml
)
定义的模板的名称
Names of Defined Templates
定义的模板(模板文件内的{{ define }}
)是全局访问的。这意味着,chart和它的subchart可以访问所有{{ define }}
创建的模板。这样我想起了Pythond的模板语言(Django模板语言,Jinja2等等)。
出于此原因,所有定义的模板名称都应该命名空间。
|
|
It is highly recommended that new charts are created via helm create command as the template names are automatically defined as per this best practice.
格式化模板
Formatting Templates
模板应该使用两个空格,而不是tab。花括号前后应该有空格。有适当的空格和缩进。
|
|
生成模板中的空格
Whitespace in Generated Templates
优选的是,保持在生成的模板中的空格数量降到最低。特别是,许多空行不应出现彼此相邻。但偶尔空行还是可以的。
|
|
注释
Comments (YAML Comments vs Template Comments)
YAML文件注释和模板注释。当一个模板记录功能时,应该使用模板注释。当Helm用户通过查看注释调试时,在模板内应该使用YANML注释。
|
|
在模板和模板输出中使用JSON
Use of JSON in Templates and Template Output
YAML是JSON的超集(superset)。在一些情况下,使用JSON语法可比其它YAML表示更具有可读性。
|
|
依赖
Dependencies: https://helm.sh/docs/chart_best_practices/dependencies/
介绍Chart.yaml
内声明的dependencies
的最佳实践。
版本
Versions
如果可能的化,使用版本范围,而不是某个确切的版本。建议使用补丁级别(patch-level)版本匹配:
|
|
repo ruls,如果可能,使用HTTPS。文件URL(file://...
)被认为是一个特殊,对由一个固定部署的流水线charts。
条件和标记
Conditions and Tags
条件或标记应被添加到任何依赖(可选的)。
|
|
标签和注释
Labels and Annotations: https://helm.sh/docs/chart_best_practices/labels/
讨论chart中使用标签和注释的最佳实践。
标签还是注释
Is it a Label or an Annotation?
以下条件的元数据项应该为标签(label):
- 它利用k8s来标识此资源
- 暴露给查询系统的目的是有用的
如果元数据的条目不用于查询,它应该设置为注释。Helm hooks总是注释。
标准的标签
Standard Labels
下表定义了Helm chart常用的标签。Helm自身从未要求特定的标签存在。REC的标签是建议的,并应该放置到全局一致性的chart。OPT的标签是可选的。
|
|
可在k8s 文档中,带有app.kubernetes.io
前缀的文档中查看更多信息。
Pods和PodTemplates
Pods and PodTemplates: https://helm.sh/docs/chart_best_practices/pods/
以下资源列表使用PodTemplate:
- Deployment
- ReplicationController
- ReplicaSet
- DaemonSet
- StatefulSet
镜像
Images
容器镜像应该使用确定的标记或镜像的SHA。但不应该使用latest
, head
, canary
这样的标记。
镜像可以在values.yaml
文件中定义,使其很容易替换镜像。
|
|
镜像和标记可在values.yaml
中被定义为分开的两个字段:
|
|
镜像拉取策略
ImagePullPolicy
helm create
默认在deployment.yaml
中设置imagePullPolicy
为IfNotPresent
。
|
|
|
|
同样,如果未设置impagePullPolicy
,k8s默认会将其设置为IfNotPresent
。如果想要修改此值,只需在values.yaml
文件中更新此值。
PodTemplate应该声明选择器
PodTemplates Should Declare Selectors
所有的PodTemplate部分应该指定一个选择器。示例:
|
|
这是一个很好的做法,因为它使set和pod相关联。
但是,这对于像Deployment这样的集更为重要。没有这一点,整个标签集(set of labels)用于选择匹配pod,如果你使用的标签发生改变(如版本或日期),这将打破匹配。
自定义资源的定义
Custom Resource Definitions
当使用自定义资源定义(CRDs),区分两种不同的片是很重要的:
- 声明一个CRD(
kind: CustomResourceDefinition
) - 然后资源使用CRD
使用资源前安装CRD声明
Install a CRD Declaration Before Using the Resource
Helm是尽可能优化地载入更多的资源到k8s中。按照设计,k8s可以采取一整套清单(manifests),并带它们所有上线(这就是所谓的和解循环(reconciliation loop)))。
但是,CRDs有一些不同。对于CRD,在任意CRDs类型资源被使用之前,必须先注册声明。注册过程有时需要几秒。
方法1:让helm为你做此事
Method 1: Let helm Do It For You
随着Helm3的到来,出于更简单的方法,Helm移除了旧的crd-install
hooks。这在是一个称为crds
的新目录,在你创建的chart的此目录下保存你的CRDs。这些CRDs没有模板,但会在chart运行helm install
时默认安装。如果CRD已存在,它会被跳过。你也可以通过传递--skip-crds
选项来跳过CRD的安装。
一些注意事项:
目前不支持使用Helm更新或删除CRDs。这是一个经过反复讨论的明确的决定,由于存在非故意丢失数据的危险。此外,目前社区如何处理CRDs和它的生命周期没有共识,由于这种演变,Helm将添加对这些用例的支持。
helm install
和helm upgrade
的--dry-run
选项暂不支持CRDs。Dry Run的目的是去验证chart的输出将实际地工作,如果发送到服务器。但CRDs可通过服务器行为的修改。Helm无法在dry run上安装CRD,因此发现客户端将不知道自定义资源(CR),并验证将失败。你可以可选地移动CRDs到它们自己的chart,或使用helm template
来代替。
围绕CRD支持的另一个重要的考虑点是如何处理模板的渲染(rendering of templates)。一个在Helm2中使用crd-install
方法的明显的缺点是不能正确验证chart,由于改变API可用性(一个CRD被实际添加到另一个可用API到k8s集群)。如果一个chart安装了CRD,helm
不再有一组API版本的有效集。这也是在移除从CRDs的模板支持的原因。随着安装CRD的新的crds
方法,我们现在确保helm
有关于当前集群状态的完整信息。
方法2:独立chart
Separate Charts
另一种方法是,把CRD定义在一个chart中,然后把所有资源使用的该CRD放在另一个chart。
在此方法中,每个char都必须单独安装。然而,这个工作流程可能是集群操作器(cluster operators)(对集群拥有admin权限)使用。
RBAC
Role-Based Access Control: https://helm.sh/docs/chart_best_practices/rbac/
RBAC资源有:
- ServiceAccount (namespaced)
- Role (namespaced)
- ClusterRole
- RoleBinding (namespaced)
- ClusterRoleBinding
YAML配置
RBAC和ServiceAccount配置因该在单独的密钥里。它们是不同的东西。拆分这两个概念在YAML歧义消除它们,使之更清楚。
|
|
多个服务账号可以扩展为更复杂的charts。
|
|
RBAC资源应该被默认创建
RBAC Resources Should be Created by Default
rbac.create
应该是一个布尔值,由RBAC资源来控制创建。默认应该为true。希望管理RBAC访问控制的用户可以将此设置为false。
使用RBAC资源
Using RBAC Resources
serviceAccount.name
应该被设置为由chart创建的访问控制资源使用的服务账号名称。如果serviceAccount.create
为true,那么此名称的服务名称应该被创建。如果此名称未设置,则使用模板fullname
来生成。如果为false,则它不应该被创建,但它应该与同样的资源相关联,以便创建后引用该手动创建RBAC资源正常工作。如果为false且没有指定名称,则使用默认的服务账号。
下面的助手模板应该用于服务账号:
|
|
模板
Chart Template: https://helm.sh/docs/chart_template_guide/
Helm‘s chart templates,重点介绍模板语言。让我想起的Django模板语言、Jinja2模板语言。
模板生成清单文件,这是k8s可理解的YAML格式的资源描述。本章重点介绍以下概念:
- Helm模板语言
- Values使用
- 使用模板的技术
入门
Getting Started: https://helm.sh/docs/chart_template_guide/getting_started/
创建一个chart并添加一个模板。
Charts
|
|
templates/
目录存放模板文件。当Helm评估一个chart,它会发送所有模板目录中的文件到模板渲染引擎。然后,它收集模板的结果,并将它们发送到k8s。
values.yaml
文件对模板也很重要。此文件包含了一个chart的默认值。默认值可通过命令行选项进行覆盖。
Chart.yaml
文件包含对chart包的描述信息。你可在模板中访问它。charts/
目录可能包含其它chats(称为subcharts)。
示例
A Starter Chart
|
|
当编写生产环境的chart包时,有这些charts包的基础版本可能很有用。
第一个模板
A First Template
创建一个ConfigMap
资源的模板。由于它是一个基本的资源,因此它为我们提供了一个很好的起点。
|
|
小技巧:模板名称不遵循严格的命名模式。然而,我们建议为YAML文件使用.yaml
后缀,为模板助手使用.tpl
后缀。
上述YAML文件是一个最基本的ConfigMap,最有最小的必要的字段。它会通过模板引擎进行发送。
一个普通的平YAML文件是蛮好的。当Helm读取此模板,它会简单地将文件原样发送给k8s。
在这个简单的例子中,我们现在有了一个可安装的chart包。安装一下:
|
|
添加一个简单的模板调用
Adding a Simple Template Call
硬编码的name
,通常被认为是不好的做法。每个发行版的名称应该是唯一的。因此,我们可能将生成一个名称字段来写入发行版名称。
注意,由于DNS系统的限制,name
字段被限制为63字符。出于这个原因,发行版名称被限制为53字符。
|
|
|
|
使用--dry-run
将更容易对代码进行测试,但它不会保证k8s会接受你生成的模板。
内置对象
Built-in Objects: https://helm.sh/docs/chart_template_guide/builtin_objects/
对象动模板引擎传递到模板。你的代码可以传递对象范围(如with
和range
)。有一些方法可在模板中创建新的对象,如tuple
函数。
对象可以很简单,它只有一个值。它们也可以包含其它对象或函数。如,Realease
对象可包含几个对象(如Release.Name
),Files
对象有一些函数。
|
|
内置的值总以大写字母开头。这与go命名方式保持一致。
值文件
Values Files: https://helm.sh/docs/chart_template_guide/values_files/
Values
是一个内置的对象。它提供了访问值并传递到chart包。值文件是平YAML文件。其内容来源于多个源:
- chart包中的
values.yaml
文件 - 如果是一个subchart包,则为parent chart包的
values.yaml
文件 - 通过
helm install/upgrade
的-f myvals.yaml
传递值 - 通过
helm install/upgrade
的--set foo=bar
选项传递值
|
|
|
|
值文件也可以包含更多结构化的内容。
|
|
虽然结构化数据这种方式是可行的,但建议你保持值的浅度(shallow),有利于平整。当看到subcharts包的值时,我们将看到值是如何使用树状结构命名的。
删除一个默认键
Deleting a default key
如果你需要从默认值删除一个键,你可以覆盖这个键的值为null
,在这种情况下,Helm将从覆盖值得合并中移除这个键。
模板函数和管道
Template Functions and Pipelines: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/
到目前为止,我们以将看到如何将信息转换为模板。但这些信息放入未修改的模板。有时候,我们希望以一种更可用的方式来转换提供的数据。
在模板指令中调用quote
函数:
|
|
模板函数使用funcationName arg1 arg2...
语法。上面的quote .Values.favorite.drink
调用quote
函数并传递一个参数。
Helm有超过60个可用的函数。一些通过go模板语言定义。大多数是Sprig template library的一部分。
管道
pipelines(|
)
模板语言的一个强大功能就是它的管道(|
)。管道是让几件事情依序进行的有效方式。让我们使用管道重写上面的示例:
|
|
使用管道,我们可以将多个函数链接在一起:
|
|
default函数
default
函数经常在模板中使用(default DEFAULT_VALUE GIVEN_VALUE
)。此函数允许你指定一个默认值。有则替换它,无则使用默认值。
|
|
在实际的chart包中,所有静态默认值都应该位于values.yaml
中,而不应该使用default
重复。然而,default
命令对于不能在values.yaml
中声明的值,是完美的计算值的方法。例如:
|
|
lookup函数
lookup
函数可用于在正在运行的集群中查找资源。它查找apiVersion
, kind
, namespace
, name
到resource或resource list。
|
|
当没有找到对象时,则返回一个空值。这可以用于检查对象是否存在。
lookup
函数使用Helm现有的k8s连接配置来查询k8s。如果调用API server进行交互时返回错误,则Helm的模板处理将失败。
请记住,Helm是不应该在helm template
或helm install|update|delete|rollback --dry-run
期间连接到k8s API server,因此,lookup
在此情况下将会获得一个空列表。
操作符
Operators are functions
对于模板,操作符(eq
, ne
, lt
, gt
, and
, or
等)都被实现为函数。在管道中,操作符可使用括号()
进行分组。
函数列表
Template Function List: https://helm.sh/docs/chart_template_guide/function_list/
Helm包含很多模板函数,你可以在模板中使用它们。下面按照功能列出:
- Cryptographic and Security
- Date
- Dictionaries
- Encoding
- File Path
- Kubernetes and Chart
- Logic and Flow Control
- Lists
- Math
- Network
- Reflection
- Regular Expressions
- Semantic Versions
- String
- Type Conversion
- URL
- UUID
流程控制
Flow Control: https://helm.sh/docs/chart_template_guide/control_structures/
控制结构(在模板原语中称为行动)提供给模板作者,模板生成的控制流程的能力。Helm的模板语言提供了如下控制结构:
if
,else
:创建条件块with
:指定一个范围range
: 提供一个类似的for循环
除此之外,它为声明和使用命名模板段提供了一些动作:
define
:在模板内声明一个新的命名模板template
:导入一个命名的模板block
:声明一个特殊的可填写的模板区域
这些都让我想起之前用Django模板语言写前端的时候,基本上一样的原理。
if和else
if
, else
块示例:
|
|
|
|
控制空格
Controlling Whitespace
虽然我们看到了条件语句,我们也应该了解模板中的空格的控制方式。这主要是确保对于生成的YAML文件的缩进的正确性。
|
|
生成的不正确的YAML格式:
|
|
mug被不正确地缩进。让我们修改模板:
|
|
这样生成的YAML是有效的,但显得很滑稽:
|
|
请注意,在YAML文件中生成了几个空行。为什么?当模板引擎运行时,它将删除花括号里的内容,但它留下的剩余空格完全一样。
YAML对空白很在意,所以管理空白变得非常重要。幸运的是,Helm有一些工具来帮助我们。
|
|
|
|
|
|
小心使用排列修改器(chomping modifier)。很容易不小心做了下面的事情:
|
|
这会生成food: "PIZZA"mug:true
这样,因为它消耗了两侧的换行。
|
|
使用with修改范围
Modifying scope using with
另一个控制结构是with
动作。这可以控制变量的范围,.
是指的当前范围。因此,.Values
告诉模板到当前范围下去寻找Values
对象。
|
|
范围可以被更改。with
可以允许你将当前范围(.
)设置为特定对象。例如,我们使用.Values.favorite
工作。让我们在.Values.favorite
范围来重写ConfigMap:
|
|
|
|
但这里有一个值得注意的问题!在限制的范围内,你将无法从父对象范围(.
)访问其它对象。以下示例会失败:
|
|
由于Release.Name
没有在限制的范围(.
)内,会报错。但在限制的之外就没有问题。
或者,我们可以使用$
符号从父范围访问Release.Name
对象。$
符号在开始执行时会映射到根范围内,在模板执行时也不会改变。示例如下:
|
|
在了解range
后,我们会看到模板变量,它提供了一个解决上述作用域问题的方法。
range循环
Looping with the range action
许多编程语言都是用for
循环,在Helm模板语言中,它使用range
操作符来实现迭代。
首先,让我们在values.yaml
文件里添加一个列表。
|
|
在我们的ConfigMap中获取值里面的列表:
|
|
我们可以使用$
来访问父范围内的Values.pizzaToppings
。$
符号映射到根目录下,并在函数执行时不会改变。示例如下:
|
|
渲染示例:
|
|
符号|-
声明一个多行字符串。因此,实际上我们的toppings不是一个YAML list,而是一个big string。我们为什么要这样做?因为在ConfigMaps data
里的数据是由键值对(k/v)组成,其中键和值都是简单的字符串。要理解为什么这样的化,请查看k8s configmap文档。
YAML里的|-
符号表示一个多行字符串(multi-line string)。这可以在文件中嵌入一大块数据。
Helm模板具有一个tuple
函数,来使得操作更简单。让我想起了Python中的tuple数据类型。示例如下:
|
|
结果如下:
|
|
除了list和tuple,range
还可以迭代具有有键值对的map和dict。我们将在后面的章节中了解它们。
变量
Variables: https://helm.sh/docs/chart_template_guide/variables/
我们可以在模板中使用变量。在Helm模板中,变量是其它对象的命名引用。
|
|
在with
块之前,我们赋值了一个变量。在with
块内,$relname
变量仍然指向版本名称。
在range
循环中使用变量:
|
|
渲染效果:
|
|
有一个变量($
)它永远是全局的,此变量将永远指向根上下文(root context)。放你使用range
循环,并且需要知道chart的版本名称时,这非常有用。示例如下:
|
|
到目前为止,我们已看到了只在一个文件中声明的模板。但是Helm模板语言的一个强大功能是声明多个模板和使用它们。我们将在后面的章节了解到。
命名模板
Named Templates: https://helm.sh/docs/chart_template_guide/named_templates/
是时候使用多个模板了。本章中,我们将在一个文件中命名模板,然后在其它地方使用它们。这让我想起了Python写Web是的模板。命名模板(有时称为子模板)是在文件中定义的一个简单的模板。有两种方法来创建它,有几种不同的方法来使用它。
在流程控制(flow control)章节,我们介绍了define
, template
, block
这三个声明和管理模板的动作。在本章中,我们将讨论这三种动作,并引入一种特殊目的的include
函数。
命名模板的一个重要细节:模板名称是全局的。如果声明了两个相同名称的模板,whichever one is loaded last will be the one used. 由于subcharts中的模板与顶级模板一起编译,你应该小心命名。
|
|
下划线文件
Partials and _
files
目前为止,我们使用的一个文件中包含一个模板。但是Helm模板语言允许你创建命名嵌套模板,可通过名称在其它任何地方进行访问。
在我们开始编写这些模板之前,我们需要注意一下命名规范:
templates/
下的大多数文件被视为包含k8s manifestsNOTES.txt
是一个例外- 以下划线(
_
)开头的文件被假定为不包含k8s manifests。这些文件不会被渲染为k8s对象定义,但可在任意chart templates中使用。
这些文件用来存储特定(partials)和助手(helpers)。实际上,当我们第一次创建mychart
,我们会看到_helpers.tpl
文件,此文件是默认的template partials。
声明和使用模板
Declaring and using templates with define
and template
。
define
动作允许我们在一个模板文件中创建命名模板(named template)。语法如下:
|
|
栗子:
|
|
渲染之后的效果:
|
|
define
仅定义,只有在模板中调用时才会产生输出。
按照惯例,Helm charts将这些模板放在partials文件中(通常是_helpers.tpl
),如:
|
|
|
|
设置模板范围
Setting the scope of a template
在上面定义的模板中,我们没有使用任何对象。让我们做些修改:
|
|
上面定义的名称和版本是动态的,会根据不同的模板生成不同的值。
之前的引用并没有床底范围,因此在模板内我们不能使用.
来访问任何事物。现在我们对模板加上范围:
|
|
注意上面在模板调用处使用的点(.
)。我们可以非常容易地传递.Values
或.Values.favorite
或任何我们需要的范围。但是,我们需要的是顶级范围。
现在运行渲染(helm install --dry-run --debug plinking-anaco ./mychart
)来预览下:
|
|
include
The include
function
假设我们定义了如下一个简单模板:
|
|
一个错误的栗子:
|
|
渲染的结果并不正确:
|
|
Because the template that is substituted in has the text aligned to the right. Because template is an action, and not a function, there is no way to pass the output of a template call to other functions; the data is simply inserted inline.
To work around this case, Helm provides an alternative to template that will import the contents of a template into the present pipeline where it can be passed along to other functions in the pipeline.
因为模板是靠右对齐的文本,因为template
是一个动作,不是一个函数,因此无法传递调用其它函数的template
的输出,数据被简单的插入内联。
现在我们需要使用ident
来告诉模板正确的缩进,栗子:
|
|
正确的渲染结果:
|
|
在Helm template中使用include
对template
被认为更好,这使得输出格式可以为YAML文档更好地处理。
有时候,我们想要导入内容,但不作为模板。也就是逐字导入文件。我们可以通过.Files
对象访问文件来实现这一目标。
在模板内访问文件
Accessing Files Inside Templates: https://helm.sh/docs/chart_template_guide/accessing_files/
Helm提供了.Files
对象来访问文件。在开始模板示例之前,有些事需要注意下:
- 可以添加额外的文件到Helm chart。这些文件将被捆绑。要注意,charts必须小于1MB,因为k8s对象的存储限制。
- 某些文件无法通过
.Files
对象访问,通常出于安全原因templates/
目录内的文件无法访问.helmignore
中包含的文件无法访问
- Charts不保留UNIX mode信息,当设计到
.Files
对象时,文件级别的权限对一个文件的可用性没有影响。
示例
Basic example
添加三个位于mychart/
目录下的文件。
|
|
在模板中访问文件:
|
|
|
|
渲染效果示例:
|
|
路径助手
Path helpers
使用文件时,对文件路径执行一些标准的操作是有用的。为了帮助处理,Helm从go path包中引入了许多函数供你使用:
Base
Dir
Ext
IsAbs
Clean
Glob模式
Glob patterns
随着你的chart包的增长,你会发现你有一个更大的需来组织你的文件,因此我们提供了Files.Glob(pattern string)
方法,以帮助提取某些文件与glob patterns的所有灵活性。
.Glob
返回一个Files
类型,因此你可以在返回的对象上调用任意Files
方法。
|
|
使用Globs的多种选项:
|
|
或者:
|
|
ConfigMap和Secrets的实用功能
ConfigMap and Secrets utility functions
将文件内容放置到K8s ConfigMap或Secrets中非常常见,然后在运行的时候挂载到容器。为了帮助实现此功能,我们在Files
类型上提供了几种实用的方法:
AsCoinfig
AsSecrets
栗子:
|
|
编码
Encoding
你可以导入一个文件,并实用base64编码来确保成功传输:
|
|
渲染后的效果:
|
|
行
Lines
有时候需要在模板中访问一个文件中的每行内容。我们为此提供了Lines
方法。
示例:
|
|
NOTES.txt
Creating a NOTES.txt File: https://helm.sh/docs/chart_template_guide/notes_files/
在helm install
或helm upgrade
结束,Helm可以为用户打印一块有用的信息。此信息使用模板且高度可定制。
要为你的chart包添加安装说明,简单地创建一个templates/NOTES.txt
文件。此文件是纯文本文件,但它像作为模板一样处理,并可访问所有正常模板函数和对象。
NOTES.txt
文件示例:
|
|
接下来运行:
|
|
强烈建议创建NOTES.txt
文件,以帮助用户获得chart包的有用信息。
Subcharts
Subcharts and Global Values: https://helm.sh/docs/chart_template_guide/subcharts_and_globals/
之前我们只有一个chart,但charts可能会有依赖(dependencies),称为subcharts。subcharts也有自己的值和模板。本章我们将会创建subchart,并看看我们可以从模板访问值的不同的方式。
subcharts的一些重要详情:
- 一个subchart被认为是独立的(stand-alone),这意味着一个subchart不能明确依赖它的parent chart
- 出于此原因,subchart不能访问parent chart的值
- parent chart可以覆盖subcharts的值
- Helm有一个全局值(global values)的概念,这些全局值可被所有charts访问
创建一个subchart
Creating a Subchart
|
|
对subchart添加值和模板
Adding Values and a Template to the Subchart
为subchart添加一个简单的值和模板:
|
|
|
|
因为每个subchart都是独立的chart,我们可以测试mysubchart:
|
|
从parent chart覆盖值
现在,mychart是mysubchart的parent chart。因为mychart是parent chart,我们可以在mychart中指定配置,并将配置推送到mysubchart中。
|
|
我们在parent chart(mychart)的值文件里添加了mysubchart的值,mysubchart这部分值会发送到mysubchart包,这回覆盖mysubchart的值。
|
|
全局值
Global Chart Values
有时候你需要将值提供给所有模板,这可以使用全局值(global chart values)。全局值可被任意chart或subchart通过相同的名称来访问。全局需要明确地声明。
值数据类型保留在称为Values.global
的区域,此区域可以设置全局值。
|
|
|
|
|
|
渲染输出效果:
|
|
共享模板
Sharing Templates with Subcharts
parent charts和subcharts可以共享模板。任意在chart中定义的block(块)都可以被其它charts所使用。
定义一个简单的模板栗子:
|
|
尽管chart开发者可以在include
和template
之间选择,但使用include
的优点是它可以动态引用模板:
|
|
上面间接引用$mytemplate
。template
函数,相反它只接受一个字符串。
避免使用块
Avoid Using Blocks
go模板语言提供了一个block
关键字,来允许开发者提供一个覆盖的默认实现。在Helm chart中,块(block)并不是覆盖的最佳工具,因为如果提供了相同块的多个实现,选择的那个是不可预测的。
建议使用include
来代替。
.helmignore
The .helmignore file: https://helm.sh/docs/chart_template_guide/helm_ignore_file/
.helmignore
也就类似于.gitignore
, .dockerignore
,指定不需要包含在chart包中的文件。
如果此文件存在,helm package
命令将忽略.helmignore
里面匹配到的文件打包到应用的包里。
一个.helmignore
文件的栗子:
|
|
模板调试
Debugging Templates: https://helm.sh/docs/chart_template_guide/debugging/
有几个命令可帮助调试模板:
helm lint
: 验证chart最佳实践的工具helm install --dry-run --debug
或helm template --debug
:渲染模板并返回k8s manifest文件helm get manifest
:查看安装了哪些模板
YAML技巧
YAML Techniques: https://helm.sh/docs/chart_template_guide/yaml_techniques/
Helm命令
Helm Commands: https://helm.sh/docs/helm/
社区指南
Community Guides: https://helm.sh/docs/community/
FAQ
Frequently Asked Questions: https://helm.sh/docs/faq/