💠

文章封面来自Garuku-capriccioso

以前一直没有系统学习过helm，只是会操作一些简单的命令，五一假期来卷一下

想找一些资料视频看看吧，发现b站上就是一些没多长时间的，或者包含在K8S大培训里面的一小节视频，没什么水平，看着没啥意思

百度到的一些关于helm的文档，大部分还是对官方英文文档的机翻

PS: 其实已经有官方的中文文档了，我在写HELM的另外一篇文章的时候才发现…，就在英文文档的右上角，可以切换语言 😦，是没必要去啃英文的，写这篇文章的时候我阅读的是英文，有些表述可能不如官方翻译，章节都是一一对应的，我表述不清的地方可以查看官方中文文档

求人不如求己，还是自己啃一下官方文档吧

下面的章节，照着官方文档，算是按顺序做了一个简单的笔记吧（可能也只有我能看懂 😅，大部分属于helm基础的部分，高级的部分打算另开一篇，继续读官方文档写一写

一些链接：

官方中文文档

国内访问文档

前提

  • 准备 Kubernetes 集群

  • helm安装版本需要和K8版本匹配，否侧可能出现不兼容风险，详细查看官方文档 匹配表

    下面的版本匹配 2022/05/03 copy 自官方文档

Helm Version Supported Kubernetes Versions
3.8.x 1.23.x - 1.20.x
3.7.x 1.22.x - 1.19.x
3.6.x 1.21.x - 1.18.x
3.5.x 1.20.x - 1.17.x
3.4.x 1.19.x - 1.16.x
3.3.x 1.18.x - 1.15.x
3.2.x 1.18.x - 1.15.x
3.1.x 1.17.x - 1.14.x
3.0.x 1.16.x - 1.13.x
2.16.x 1.16.x - 1.15.x
2.15.x 1.15.x - 1.14.x
2.14.x 1.14.x - 1.13.x
2.13.x 1.13.x - 1.12.x
2.12.x 1.12.x - 1.11.x
2.11.x 1.11.x - 1.10.x
2.10.x 1.10.x - 1.9.x
2.9.x 1.10.x - 1.9.x
2.8.x 1.9.x - 1.8.x
2.7.x 1.8.x - 1.7.x
2.6.x 1.7.x - 1.6.x
2.5.x 1.6.x - 1.5.x
2.4.x 1.6.x - 1.5.x
2.3.x 1.5.x - 1.4.x
2.2.x 1.5.x - 1.4.x
2.1.x 1.5.x - 1.4.x
2.0.x 1.4.x - 1.3.x

安装

helm 推荐二进制安装

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

更多安装方法参考官方安装指南

概念

摘自官方提到的三大概念 分别解释了 helm chart ，repo ，release

其实这些概念还是蛮重要的，多读读还是有用的

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。

Using

按照官方的文档，一点点操作学习，官方使用指南

'helm search': Finding Charts

这里主要说了两个命令

  • helm search hub 联网搜索数十个仓库

  • helm search repo 离线搜索仓库，这里的仓库是使用 helm repo add 命令添加的，依据的本地离线的仓库数据

# 联网查找所有可用的关键字包含 wordpress 的项目(charts)
helm search hub wordpress

# 添加一个仓库
helm repo add brigade https://brigadecore.github.io/charts

# 搜索本地仓库关键字包含 brigade 的项目(charts)
helm search repo brigade

helm repo

'helm repo': Working with Repositories

在helm 3 中已经没有默认的 charts仓库了 需要使用 helm repo 命令添加、查看、删除仓库

# 查看
helm repo list

# 添加 helm repo add reponame repoaddress
helm repo add dev https://example.com/dev-charts

# charts仓库更新（远端改动拉取到本地类似 git fetch & git pull）
helm repo update

# 删除添加的仓库
helm repo remove

helm install

'helm install': Installing a Package

# helm install 需要两个参数，分别是 release name 和 chart名字
# 如果你想让系统自动生成 release name 不要填你自己的发布名称 并 加上参数 --generate-name
helm install happy-panda bitnami/wordpress

Helm在安装这些项目的时候，是根据一定顺序来的，而且不会等到完全安装结束才退出（比如拉大镜像之类的时候）

Helm安装时候遵循的顺序由上到下以此为：

  • Namespace
  • NetworkPolicy
  • ResourceQuota
  • LimitRange
  • PodSecurityPolicy
  • PodDisruptionBudget
  • ServiceAccount
  • Secret
  • SecretList
  • ConfigMap
  • StorageClass
  • PersistentVolume
  • PersistentVolumeClaim
  • CustomResourceDefinition
  • ClusterRole
  • ClusterRoleList
  • ClusterRoleBinding
  • ClusterRoleBindingList
  • Role
  • RoleList
  • RoleBinding
  • RoleBindingList
  • Service
  • DaemonSet
  • Pod
  • ReplicationController
  • ReplicaSet
  • Deployment
  • HorizontalPodAutoscaler
  • StatefulSet
  • Job
  • CronJob
  • Ingress
  • APIService
# 查看发布的状态 helm status 
helm ls -n cattle-system
helm status rancher -n cattle-system

# 在install 之前查看可以配置的相关选项（可修改参数）
helm show values bitnami/wordpress

Helm install时候 两种传参的方法

  • –values（或-f）：指定具有覆盖配置的YAML文件 可以指定多次最右边的文件优先

    # 可以通过覆盖相关的配置 在安装的时候传递该文件

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

  • –set：install时候用set参数覆盖

    # --set的与yaml的匹配格式，样例如下
 
# --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"

# 选择器中的注释、标签 --set nodeSelector."kubernetes\.io/role"=master：
nodeSelector:
  kubernetes.io/role: master

Helm install 命令可以从多个来源安装：

  • 一个charts存储库（ helm install happy-panda bitnami/wordpress ）
  • 本地charts ( helm install foo foo-0.1.1.tgz)
  • 解压后的charts目录 ( helm install foo path/to/foo)
  • 完整网址 ( helm install foo https://example.com/charts/foo-1.2.3.tgz)

helm upgrade and helm rollback

'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure

# panda.yaml 
mariadb.auth.username: user1
# 使用新的 yaml 配置升级
helm upgrade -f panda.yaml happy-panda bitnami/wordpress
# 查看配置是否生效
helm get values happy-panda
helm get values rancher -n cattle-system

# 回滚版本
# helm rollback [RELEASE] [REVISION]
# REVISION 可以通过 helm status 命令查看 每次升级 REVISION +1
# 第一个版本  REVISION 始终为1
helm rollback happy-panda 1

# helm install / upgrade / rollback 的其他参数
# --timeout
# --wait ： 等到所有 Pod 都处于就绪状态

helm uninstall

'helm uninstall': Uninstalling a Release

helm uninstall happy-panda
helm list
# 在helm 3 中 发布删除了发布记录也会被删除，旧的helm版本不会
# 如果需要保留历史 helm uninstall --keep-history
# 查看 keep history 标志卸载的发布
helm list --uninstalled

# 查看所有Release （包括失败或已删除项目的记录 前提是使用 --keep-history 参数做的删除）
helm list --all

Note that because releases are now deleted by default, it is no longer possible to rollback an uninstalled resource.

已经删除的发布无法回滚或者卸载，慎用uninstall

create your charts

官方在使用的最后简单介绍了，创建charts的相关命令，charts更详细的在后续章节记录

# 创建一个自己的 charts
# 当前目录下生成 ./deis-workflow 
helm create deis-workflow

# 验证是否正确
helm lint

# 打包
# 生成 deis-workflow-0.1.0.tgz 文件
helm package deis-workflow

# 离线安装 charts包
helm install deis-workflow ./deis-workflow-0.1.0.tgz

# 拉取线上charts
helm pull chartreponame/chartname

如何将charts维护进仓库，参考官方文档

Charts

本节主要介绍Charts ，安装官方文档的介绍顺序，笔记笔记

The Chart File Structure

官方对helm charts包含的文件结构解释如下

  Chart.yaml          # chart的相关信息
  LICENSE             # 证书（可缺省文件）
  README.md           # Readme（可缺省文件）
  values.yaml         # chart的一些默认值设置
  values.schema.json  # values.yaml JSON格式的约束文件（约束值的类型之类）（可缺省文件）
  charts/             # 依赖chart
  crds/               # 自定义资源文件目录（如果需要使用crd）
  templates/          # 模板目录 和values.yaml内的默认值组合后形成可以kubectl apply的yaml文件
  templates/NOTES.txt # 用法说明文件（可缺省文件）
  
  # 其中 charts/ crds/ templates/ 文件名不可随便使用和修改

自己实际创建一个看看有哪些

[root@lkarrie helm-study]# helm create deis-workflow
Creating deis-workflow
[root@lkarrie helm-study]# cd deis-workflow/
[root@lkarrie deis-workflow]# tree .
.
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 10 files
[root@lkarrie deis-workflow]# cd templates/
[root@lkarrie templates]# ls
deployment.yaml  _helpers.tpl  hpa.yaml  ingress.yaml  NOTES.txt  serviceaccount.yaml  service.yaml  tests
[root@lkarrie templates]# cd tests/
[root@lkarrie tests]# ls
test-connection.yaml
[root@lkarrie tests]# cat test-connection.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "deis-workflow.fullname" . }}-test-connection"
  labels:
    {{- include "deis-workflow.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['{{ include "deis-workflow.fullname" . }}:{{ .Values.service.port }}']
  restartPolicy: Never

看起来简单使用的话 只需要 Charts.yaml values.yaml templates/ charts/ 就可以，自动创建的时候还给你生成一个test-connection.yaml，就是简单创建一个busybox的pod 执行wget命令检查一下你的charts部署结果端口有没有问题

The Chart.yaml File

先看看Chart.yaml吧，官方对其详细配置解释如下

apiVersion: The chart API version (required)
name: The name of the chart (required)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
description: A single-sentence description of this project (optional)
type: The type of the chart (optional)
keywords:
  - A list of keywords about this project (optional)
home: The URL of this projects home page (optional)
sources:
  - A list of URLs to source code for this project (optional)
dependencies: # A list of the chart requirements (optional)
  - name: The name of the chart (nginx)
    version: The version of the chart ("1.2.3")
    repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name")
    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )
    tags: # (optional)
      - Tags can be used to group charts for enabling/disabling together
    import-values: # (optional)
      - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
maintainers: # (optional)
  - name: The maintainers name (required for each maintainer)
    email: The maintainers email (optional for each maintainer)
    url: A URL for the maintainer (optional for each maintainer)
icon: A URL to an SVG or PNG image to be used as an icon (optional).
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
deprecated: Whether this chart is deprecated (optional, boolean)
annotations:
  example: A list of annotations keyed by name (optional).

自动生成的Charts，只会简单生成其中的部分项目

[root@lkarrie deis-workflow]# cat Chart.yaml 
apiVersion: v2
name: deis-workflow
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
appVersion: 1.16.0
[root@lkarrie deis-workflow]#

官方在解释这些配置之前，强调了一下 Chart.yaml 中 version 的命名规范，它必须满足SemVer2的命名规范（遵循一定的规则命名，想了解可以点链接看一下，这个规范我也是第一次见…），而且这个 version 会和 package 后的压缩包命名一致，例如version: 1.2.3 再打包之后会生成的压缩包名为 nginx-1.2.3.tgz

The apiVersion Field

Chart.yaml中 apiVersion 字段 helm3 填v2即可，向下兼容v1

The appVersion Field

Chart.yaml中 appVersion 字段 定义的是你的应用的版本，比如我用当前的Charts部署我的应用是 1.1.1 版本，这里就维护1.1.1即可，官方建议这个字段使用双引号括起来，例如 appVersion: “8.2.1”，这样避免在出现不同平台下yaml的解析问题（数字用科学计数法表示的情况）

The kubeVersion Field

Chart.yaml中 kubeVersion 字段表示的是支持的Kubernetes版本，有这个约束的话不满足的版本将不能被安装

他的一些书写格式如下

# 大于 xx 小于 xx
>= 1.13.0 < 1.15.0
# 大于 xx 小于 xx 或者 xxx
>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0

# 下面支持的简略写法和nodejs相同
# 区间可以简单用 - 代替, >= 1.1 <= 2.3.4 可以如下表示
1.1 - 2.3.4 
# 通配符x, >= 1.2.0 < 1.3.0 可以如下表示
1.2.x
# 波浪号 不大于小版本号, >= 1.2.3 < 1.3.0 可以如下表示
~1.2.3
# 插入符号 不大于大版本号,  >= 1.2.3 < 2.0.0 可以如下表示
^1.2.3

Deprecating Charts

deprecated 字段表示是否弃用（true or false），弃用之后，charts项目的名字可以被重用，即等待被最新生效的charts覆盖

Chart Types

type 字段的值只有两种 application 和 library ，一般默认的类型就是 application 指定这种类型的charts可以直接被安装并运行，library 类型的charts一般里面没有任何资源对象

A library chart differs from an application chart because it is not installable and usually doesn’t contain any resource objects.

官方这里有对 library chart做详细的 说明

Chart LICENSE, README and NOTES

这里就不详细说了，证书、Readme和git中类似

notes这里指的是templates/NOTES.txt文件，其中的内容会在 helm install 或者 helm status命令执行之后在屏幕上输出的一些提示

默认生成的NOTES.txt如下

1. Get the application URL by running these commands:
{{- if .Values.ingress.enabled }}
{{- range $host := .Values.ingress.hosts }}
  {{- range .paths }}
  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ $host.host }}{{ .path }}
  {{- end }}
{{- end }}
{{- else if contains "NodePort" .Values.service.type }}
  export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ include "deis-workflow.fullname" . }})
  export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT
{{- else if contains "LoadBalancer" .Values.service.type }}
     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
           You can watch the status of by running 'kubectl get --namespace {{ .Release.Namespace }} svc -w {{ include "deis-workflow.fullname" . }}'
  export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ include "deis-workflow.fullname" . }} --template "{{"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}"}}")
  echo http://$SERVICE_IP:{{ .Values.service.port }}
{{- else if contains "ClusterIP" .Values.service.type }}
  export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "app.kubernetes.io/name={{ include "deis-workflow.name" . }},app.kubernetes.io/instance={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace {{ .Release.Namespace }} $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace {{ .Release.Namespace }} port-forward $POD_NAME 8080:$CONTAINER_PORT
{{- end }}

Chart Dependencies

当你的charts项目依赖别的charts的时候，依赖字段就可能会被使用到，依赖维护到Charts.yaml中，或者手动维护拖到charts/目录下面去（不建议）

在维护Chart.yaml中依赖形如：

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

如果已经把依赖的一些仓库add到你本地了，dependencies 中 repository字段也可以直接用reponame替换

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

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

一旦在Chart.yaml中定义了依赖charts，就可以执行 helm dependency update yourchartsname 命令拉取这些依赖，拉取的依赖会在charts/目录下

helm dep up foochart

官方文档还提到，依赖还可以定义一个别名（alias），让同一个依赖可以多次拉取到charts/下，我没太理解这个功能的使用场景，就不多写了，遇到了再补充，形如：

dependencies:
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0
    alias: new-subchart-1
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0
    alias: new-subchart-2
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0

关于父子依赖这一块官方的介绍还是比较详细的，还有一些关于父子values的传递，手动管理依赖，和kubenets在安装父子时资源的创建顺序等等，这些我实际遇工作中遇到再补充补充，有兴趣了解参阅官方文档依赖的部分

Templates and Values

charts的模板文件存储在templates/目录下，默认值存储在values.yaml中，渲染模板的时候，如果用户没提供包含值得yaml或者set参数指定，会以values.yaml中的默认值，渲染成kube中可以执行得yaml文件资源

Template Files

模板文件是Go模板语言写的，详细可以参考 the text/template Go package documentation

官方给示例模板如下，可以很简单的理解，镜像仓库地址，镜像标签，镜像拉取策略，容器的环境变量取values.yaml中，其中环境变量 设置了默认值 minio

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 }}

Predefined Values

除了values里面定义值可以在渲染的时候访问外，还有一些预定义的值可以被访问

  • Release.Name: 你的发布名称（install 时候自定义的名字）
  • Release.Namespace: ns
  • Release.Service: sc
  • Release.IsUpgrade: 升级或者回滚 这个值就是true
  • Release.IsInstall: 安装 这个值就是true
  • Chart: Chart.yaml里面定义的内容可以用Chart对象访问比如 Chart.Version，Chart.Maintainers
  • Files: A map-like object containing all non-special files in the chart. This will not give you access to templates, but will give you access to additional files that are present (unless they are excluded using .helmignore). Files can be accessed using {{ index .Files "file.name" }} or using the {{.Files.Get name }} function. You can also access the contents of the file as []byte using {{ .Files.GetBytes }}（charts的一些文件信息）
  • Capabilities: A map-like object that contains information about the versions of Kubernetes ({{ .Capabilities.KubeVersion }}) and the supported Kubernetes API versions ({{ .Capabilities.APIVersions.Has "batch/v1" }})（当前kube版本的一些信息）

官方文档在这里还提到，不要把Chart.yaml当作 values.yaml来使，虽然可以用Chart.来访问里面的内容，但是Charts内部字段是约定好的，自己加一些乱七八糟的字段用Chart.来访问是访问不到的，只有规定好的约束字段才能被Chart.访问到，这种情况定义在 values.yaml 里就行

Values files

values.yaml没啥好说的，看过的都知道里面存的默认值，values.yaml 名字必须为values，但是在 helm install 时候 values 参数后面跟的覆盖默认值的yaml名字可以随意，访问的时候就是 {{ .Values.xxx }}

Scope, Dependencies, and Values

这里官方文档主要介绍了，values在有依赖的charts里面的作用域

官方用WordPress的charts举例，WordPress charts的values.yaml文件如下，mysql下面的参数传到了依赖mysql的charts中，这里WordPress 的模板文件可以用.Values.mysql.password 访问到密码配置，又因.Values.mysql.password 传递到父依赖mysql的charts中，mysql的charts中values.yaml是直接配置的password，所以在mysql的模板中依然是用 .Values.password 访问密码，但这是时候使用的值实际上是 WordPress的values.yaml传递过来的（这里有点绕…）

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

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

apache:
  port: 8080 # Passed to Apache

在父依赖mysql charts 中我们是无法访问WordPress values中定义的 title 和 apache的配置值，这里官方描述的比较难懂，个人认为就可以简单理解成，如果父依赖的values.yaml没有与子charts的values对应的配置，就是访问不到

为了解决作用域的问题，可以将相关的配置抽出来，作为全局配置来定义，如下，现在mysql 和 apache的模板文件中都可以使用 .Values.global.app 来访问到 WordPress values.yaml所定义的global.app

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
  
##### 实际上 上面的配置 就是等价与下面的配置 对比一下就很好理解了 为什么这样配置 父依赖可以访问子charts所定义的 公共配置

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

Schema Files

schema file主要定义的values中值的类型约束，必输或非必输等等，无法满足schema定义的约束charts是无法被安装或者升级的

在运行下面的命令的时候，会去校验渲染时候的参数是否满足现成定义的约束

  • helm install
  • helm upgrade
  • helm lint
  • helm template

下面是官方提供一个schema样例

{
  "$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"
}

References

关于参考部分，官方提供了几个相关有用的标准，有兴趣可以点点

Custom Resource Definitions (CRDs)

Kubernetes 的自定义对象，在helm 3中被视为特殊的对象，和正常渲染的yaml文件不同，在使用上有一些限制，具体如下：

  • crd必须放到 crds/ 目录内部
  • crd文件不能被渲染，就必须是纯yaml文件，不能和template目录下面go模板一样写一堆渲染代码
  • 在有crd的charts中，helm首先会安装crd，并且等到其在api server中可用之后才会进行模板的渲染
  • 在有crd的charts中，helm永远不会重新安装crd
  • 在helm upgrade 或者 rollback时helm不会安装crd，只有在install的时候安装一遍
  • crd永远不会被删除，helm uninstall无法删除crd资源

由于helm对crd资源谨慎的管理方法，建议在操作CRD的时候一定要小心

引用官方的一句话

Operators who want to upgrade or delete CRDs are encouraged to do this manually and with great care.

Using Helm to Manage Charts

下面就是简单说一下 使用helm管理charts的一些基础命令，可能和上一大章节 using 中有重复的部分

# 创建
helm create mychart
# Created mychart/

# 打包
helm package mychart
# Archived mychart-0.1.-.tgz

# 校验
helm lint mychart
# No issues found

Chart Repositories

关于charts项目的仓库，只要能wget到tgz包的地址就行，有空实际做一个再补充补充，官方这里还提到，helm没有以供推送到远端仓库的功能（类似docker push的功能）

Chart Starter Packs

可以使用 --starter来指定默认helm create出来的charts模板，我不太会用到的功能，也比较简单，有兴趣参考官方文档-初始包这一部分的内容吧

Others

差不多基础使用就到这里了，官方的helm文档远不止这么多内容，还有很多高级的用法，有时间继续啃形成文档

留个坑：HELM 高级（写完补上超链接）

官方基础的读完了，最后简单看看 helm create 自动生成的默认模板和 values.yaml

deployment.yaml 中，除了go模板的一些语法外，还有一些，官方基础的文档里没有提到，比如自动生成的模板中deis-workflow.fullname 这项配置，并没有定义在Chart.yaml和values.yaml中，而是定义在了 templates/_helpers.tpl 中

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "deis-workflow.fullname" . }}
  labels:
    {{- include "deis-workflow.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "deis-workflow.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        {{- include "deis-workflow.selectorLabels" . | nindent 8 }}
    spec:
      {{- with .Values.imagePullSecrets }}
      imagePullSecrets:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      serviceAccountName: {{ include "deis-workflow.serviceAccountName" . }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

values.yaml，其中的一些注释我删掉了看着比较清晰，比较常规没啥看不懂的

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: ""

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  create: true
  annotations: {}
  name: ""

podAnnotations: {}

podSecurityContext: {}

securityContext: {}

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  annotations: {}
  hosts:
    - host: chart-example.local
      paths: []
  tls: []

resources: {}

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

Q.E.D.

Go to the dock and order some French fries!