Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
1 contributor

Users who have contributed to this file

289 lines (272 sloc) 9.85 KB
# Copyright 2018 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# ----------------------------------------------------
# Example kustomization.yaml content.
#
# This file declares the customization provided by
# the kustomize program.
#
# Since customization is, by definition, _custom_,
# there are no sensible default values for the fields
# in this file.
#
# The field values used below are merely examples, not
# to be copied literally. The values won't work if
# they happen to be references to external files that
# don't exist.
#
# In practice, fields with no value should simply be
# omitted from kustomization.yaml to reduce the content
# visible in configuration reviews.
# ----------------------------------------------------
# Kustomization 的 apiVersion 和 kind
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# 为所有 resources 添加 namespace
namespace: my-namespace
# 该字段的值将添加在所有资源的名称之前
# 例如 将资源名称 “wordpress” 变为 “alices-wordpress”
namePrefix: alices-
# 该字段的值将添加在所有资源的名称后面
# 例如 将资源名称 “wordpress” 变为 “wordpress-v2”
# 如果资源类型为 ConfigMap 或 Secret ,则在哈希值之前附加后缀
nameSuffix: -v2
# 为所有资源和 selectors 增加 Labels
commonLabels:
someName: someValue
owner: alice
app: bingo
# 和 Labels 一样, 增加 Annotations
# 为 key:value 键值对
commonAnnotations:
oncallPager: 800-555-1212
# 此列表中的每条记录都必须是一个存在的 YAML 资源描述文件
# 一个 YAML 资源描述文件可以含有多个由(“---”)分隔的资源。
# kustomize 将读取这些YAML文件中的资源,对其进行修改并
# 发布在 kustomize 的输出中。
resources:
- some-service.yaml
- sub-dir/some-deployment.yaml
# 列表中的每个条目都将创建一个 ConfigMap (它是n个 ConfigMap 的生成器)
# 下面的示例创建了两个 ConfigMaps
# 一个具有给定文件的名称和内容
# 另一个包含 key/value 键值对数据
# 每个 configMapGenerator 项都可以使用 [create | replace | merge] 参数
# 允许 overlay 从父级修改或替换现有的 configMap
configMapGenerator:
- name: myJavaServerProps
files:
- application.properties
- more.properties
- name: myJavaServerEnvVars
literals:
- JAVA_HOME=/opt/java/jdk
- JAVA_TOOL_OPTIONS=-agentlib:hprof
# 此列表中的每个条目都会导致创建一个Secret资源(n个 secrets 的生成器)
secretGenerator:
- name: app-tls
files:
- secret/tls.cert
- secret/tls.key
type: "kubernetes.io/tls"
- name: app-tls-namespaced
# 你可以给生成的 secret 定义一个 namespace ,默认为 ”default“
namespace: apps
files:
- tls.crt=catsecret/tls.cert
- tls.key=secret/tls.key
type: "kubernetes.io/tls"
- name: env_file_secret
# 文件路径以 k=v 键值对的形式,每行一个键值对
envs:
- env.txt
type: Opaque
# generatorOptions 修改所有 ConfigMapGenerator 和 SecretGenerator 的行为
generatorOptions:
# 为所有生成的资源添加 labels
labels:
kustomize.generated.resources: somevalue
# 为所有生成的资源添加 annotations
annotations:
kustomize.generated.resource: somevalue
# disableNameSuffixHash 为 true 时将禁止默认的在名称后添加哈希值后缀的行为
disableNameSuffixHash: true
# 此列表中的每个条目都应解析为包含 kustomization 文件的目录,否则定制将失败
#
# 该条目可以是指向本地目录的相对路径
# 也可以是指向远程仓库中的目录的 URL
# URL 应该遵循 hashicorp/go-getter 中的 URL 格式
# https://github.com/hashicorp/go-getter#url-format
#
# 此字段的存在意味着此文件(您正在阅读的文件)是 _overlay_
# 它将进一步定制这些来自 _bases_ 文件中的配置
#
# 典型用例:开发,演示和生产环境
# 这些环境大部分相同但有些关键方式存在差异(镜像标签,一些服务器参数等,与公共 base 不同的配置)
bases:
- ../../base
- github.com/kubernetes-sigs/kustomize/examples/multibases?ref=v1.0.6
- github.com/Liujingfang1/mysql
- github.com/Liujingfang1/kustomize/examples/helloWorld?ref=test-branch
# 此列表中的每个条目都应可以解析为部分或完整的资源定义文件
#
# 这些(也可能是部分的)资源文件中的 name 必须与已经通过 `resources` 加载的 name 字段匹配
# 或者通过 `bases` 中的 name 字段匹配
# 这些条目将用于 _patch_(修改)已知资源
#
# 推荐使用小的 patches
# 例如:修改内存的 request/limit,更改 ConfigMap 中的 env 变量等
# 小的 patches 易于维护和查看,并且易于在 overlays 中混合使用
patchesStrategicMerge:
- service_port_8888.yaml
- deployment_increase_replicas.yaml
- deployment_increase_memory.yaml
# patchesJson6902 列表中的每个条目都应可以解析为 kubernetes 对象和将应用于该对象的 JSON patch
# JSON patch 的文档地址:https://tools.ietf.org/html/rfc6902
#
# 目标字段指向的 kubernetes 对象的 group、 version、 kind、 name 和 namespace 在同一 kustomization 内
# path 字段内容是 JSON patch 文件的相对路径
# patch 文件中的内容可以如下这种 JSON 格式:
#
# [
# {"op": "add", "path": "/some/new/path", "value": "value"},
# {"op": "replace", "path": "/some/existing/path", "value": "new value"}
# ]
#
# 也可以使用 YAML 格式表示:
#
# - op: add
# path: /some/new/path
# value: value
# - op:replace
# path: /some/existing/path
# value: new value
#
patchesJson6902:
- target:
version: v1
kind: Deployment
name: my-deployment
path: add_init_container.yaml
- target:
version: v1
kind: Service
name: my-service
path: add_service_annotation.yaml
# 此列表中的每个条目都应该是 openAPI 定义中自定义资源定义(CRD)文件的相对路径
#
# 该字段的存在是为了让 kustomize 知道用户自定义的 CRD
# 并对这些类型中的对象应用适当的转换
#
# 典型用例:CRD 引用 ConfigMap 对象
# 在 kustomization 中,ConfigMap 对象名称可能会通过 namePrefix 、nameSuffix 或 hashing 来更改 CRD 对象中此 ConfigMap 对象的名称
# 引用时需要以相同的方式使用 namePrefix 、 nameSuffix 或 hashing 来进行更新
#
# Annotations 可以放入 openAPI 的定义中:
# "x-kubernetes-annotation": ""
# "x-kubernetes-label-selector": ""
# "x-kubernetes-identity": ""
# "x-kubernetes-object-ref-api-version": "v1",
# "x-kubernetes-object-ref-kind": "Secret",
# "x-kubernetes-object-ref-name-key": "name",
crds:
- crds/typeA.json
- crds/typeB.json
# Vars 用于从一个 resource 字段中获取文本
# 并将该文本插入指定位置
#
# 例如,假设需要在容器的 command 中指定了 Service 对象的名称
# 并在容器的 env 中指定了 Secret 对象的名称
# 来确保以下内容可以正常工作:
# ```
# containers:
# - image: myimage
# command: ["start", "--host", "$(MY_SERVICE_NAME)"]
# env:
# - name: SECRET_TOKEN
# value: $(SOME_SECRET_NAME)
# ```
#
# 则可以在 `vars:` 中添加如下内容:
#
vars:
- name: SOME_SECRET_NAME
objref:
kind: Secret
name: my-secret
apiVersion: v1
- name: MY_SERVICE_NAME
objref:
kind: Service
name: my-service
apiVersion: v1
fieldref:
fieldpath: metadata.name
- name: ANOTHER_DEPLOYMENTS_POD_RESTART_POLICY
objref:
kind: Deployment
name: my-deployment
apiVersion: apps/v1
fieldref:
fieldpath: spec.template.spec.restartPolicy
#
# var 是包含该对象的变量名、对象引用和字段引用的元组
#
# 字段引用是可选的,默认为 `metadata.name`
# 这是正常的默认值,因为 kustomize 用于生成或修改 resources 的名称
#
# 在撰写本文档时,仅支持字符串类型字段
# 不支持 ints,bools,arrays 等
#
# 变量引用,即字符串 '$(FOO)' ,只能放在 kustomize 配置指定的特定对象的特定字段中
#
# 关于 vars 的默认配置数据可以查看:
# https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/transformers/config/defaultconfig/varreference.go
# 默认目标是所有容器 command args 和 env 字段
#
# Vars _不应该_ 被用于 kustomize 已经处理过的配置中插入 names
# 例如, Deployment 可以通过 name 引用 ConfigMap
# 如果 kustomize 更改 ConfigMap 的名称,则知道更改 Deployment 中的引用的 name
# 修改镜像的名称、tag 或 image digest ,而无需使用 patches
# 例如,对于这种 kubernetes Deployment 片段:
# ```
# containers:
# - name: mypostgresdb
# image: postgres:8
# - name: nginxapp
# image: nginx:1.7.9
# - name: myapp
# image: my-demo-app:latest
# - name: alpine-app
# image: alpine:3.7
#```
# 想对 `image` 完成以下修改:
#
# - 将 `postgres:8` 修改为 `my-registry/my-postgres:v1`,
# - 将 nginx 的 tag 从 `1.7.9` 修改为 `1.8.0`,
# - 将 镜像名称从 `my-demo-app` 修改为 `my-app`,
# - 将 alpine 的 tag 从 `3.7` 修改为 digest 值
#
# 可以在 *kustomization* 中添加以下内容:
images:
- name: postgres
newName: my-registry/my-postgres
newTag: v1
- name: nginx
newTag: 1.8.0
- name: my-demo-app
newName: my-app
- name: alpine
digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
You can’t perform that action at this time.