# 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