内置对象

同一个chart可以部署成为多套release：

image-20211217182614726

但如果一些对象的冲突没有解决，例如两个release有相同的deployment名称，则会报错。本节将讨论如何解决命名冲突

冲突测试

我们继续复用上一节的nginx-application代码，将此chart部署出两个release。

为简化实验，我们先将service.yaml删除：

kongpingfan:~/environment/helm/nginx-application $ ls
charts  Chart.yaml  new-values.yaml  templates  values.yaml
kongpingfan:~/environment/helm/nginx-application $ rm templates/service.yaml # 删除service.yaml

基于此chart创建两个release：

kongpingfan:~/environment/helm/nginx-application $ helm install nginx-app-1 .  # 部署第一个release
NAME: nginx-app-1
LAST DEPLOYED: Fri Dec 17 10:30:54 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
kongpingfan:~/environment/helm/nginx-application $ helm install nginx-app-2 .  # 部署第二个release
Error: rendered manifests contain a resource that already exists. Unable to continue with install: Service "my-service" in namespace "default" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "nginx-app-2": current value is "nginx-app-1"

在创建第二个release时会报错，因为两个release的deployment名称都为my-deployment:

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.deployment.name }}
  labels:
    app: nginx
    
---
values.yaml:

deployment:
  replicaCount: 3
  name: my-deployment

冲突解决

在同一个namespace下，每个deployment的名称都是唯一的。

在创建release时，每个release的名称也是唯一的，所以可以将release name成为deployment name的一部分：

更新deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.deployment.name }}-{{ .Release.Name }}
  labels:
    app: nginx

重新创建两个release：

kongpingfan:~/environment/helm/nginx-application $ helm uninstall nginx-app-1
release "nginx-app-1" uninstalled

kongpingfan:~/environment/helm/nginx-application $ helm install nginx-app-1 .
NAME: nginx-app-1
LAST DEPLOYED: Fri Dec 17 10:46:20 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

kongpingfan:~/environment/helm/nginx-application $ helm install nginx-app-2 .
NAME: nginx-app-2
LAST DEPLOYED: Fri Dec 17 10:47:11 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

kongpingfan:~/environment/helm/nginx-application $ kubectl get deploy # deployment名称根据ReleaseName进行区分
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment-nginx-app-1   3/3     3            3           58s
my-deployment-nginx-app-2   3/3     3            3           6s

内置对象（Built-in Objects）

Object的定义：

Objects are passed into a template from the template engine.

Objects can be simple, and have just one value. Or they can contain other objects or functions. For example. the Release object contains several objects (like Release.Name) . Release is one of the top-level objects that you can access in your templates.

前面提到过我们可以在模板中使用 {{ .Release.Name }} 获取 release 的名称，Release 是我们可以在模板中访问的几个顶级对象之一：

  • Release：该对象描述了 release 本身的相关信息，它内部有几个对象：
    • Release.Name：release 名称
    • Release.Namespace：release 安装到的命名空间
    • Release.IsUpgrade：如果当前操作是升级或回滚，则该值为 true
    • Release.IsInstall：如果当前操作是安装，则将其设置为 true
    • Release.Revision：release 的 revision 版本号，在安装的时候，值为1，每次升级或回滚都会增加
    • Reelase.Service：渲染当前模板的服务，在 Helm 上，实际上该值始终为 Helm
  • Values：从 values.yaml 文件和用户提供的 values 文件传递到模板的 Values 值，默认情况下，Values 是空的。
  • Chart：获取 Chart.yaml 文件的内容，该文件中的任何数据都可以访问，例如 {{ .Chart.Name }}-{{ .Chart.Version}} 可以渲染成 mychart-0.1.0。
  • Capabilities：提供了获取有关 Kubernetes 集群支持功能的信息的对象
    • Capabilities.APIVersions：支持的版本集合
    • Capabilities.APIVersions.Has $version：判断一个版本（比如 batch/v1）或资源（比如 apps/v1/Deployment）是否可用
    • Capabilities.Kube.Version：Kubernetes 的版本
    • Capabilities.Kube：是 Kubernetes 版本的缩写
    • Capabilities.Kube.Major：Kubernetes 主版本
    • Capabilities.Kube.Minor：Kubernetes 的次版本

image-20211216095241314

关于Object更详细的内容，可参考 https://helm.sh/docs/chart_template_guide/builtin_objects/