kubernetes-kustomization.yaml内容解析(kustomize)
kustomization.yaml内容解析：
＃该字段的值前置于所有资源的名称，例如一个部署的名称：
＃"wordpress"变成了"alices-wordpress"。
namePrefix：alices-＃该字段的值后置于所有资源的名称，例如一个部署的名称：
＃"wordpress"变成"wordpress-v2"。
＃如果资源类型是ConfigMap或Secret，在哈希内容之前附加后缀,
nameSuffix：-v2# Annotations 增加到所有资源中,
commonAnnotations:
oncallPager: 800-555-1212
#资源中每一条目列表，必须是一个已经存在的YAML资源描述文件
resources:
- some-service.yaml
- sub-dir/some-deployment.yaml＃此列表中的每个条目都会导致创建一个ConfigMap资源（它是n个映射的生成器）。
＃下面的示例创建了两个ConfigMaps。一个与给定文件的名称和内容，另一个用键/值作为数据。
＃每个configMapGenerator项都接受一个参数行为：创建|替换|合并。这允许叠加层修改或从父级替换现有的configMap。
configMapGenerator:
- name: myJavaServerProps
files:
- application.properties
- more.properties
- name: myJavaServerEnvVars
literals:
- JAVA_HOME=/opt/java/jdk
- JAVA_TOOL_OPTIONS=-agentlib:hprof＃此列表中的每个条目都会导致创建一个secret的资源。
secretGenerator:
- name: app-tls
files:
- secret/tls.cert
- secret/tls.key
type: "kubernetes.io/tls"
- name: app-tls-namespaced
# you can define a namespace to generate secret in, defaults to: "default"
namespace: apps
files:
- tls.crt=catsecret/tls.cert
- tls.key=secret/tls.key
type: "kubernetes.io/tls"
- name: env_file_secret
# env is a path to a file to read lines of key=val
# you can only specify one env file per secret.
env: env.txt
type: Opaque
# generatorOptions修改所有ConfigMap和secret的行为
generatorOptions:
# labels 添加到所有产生的资源中
labels:
kustomize.generated.resources: somevalue
# annotations 添加到所有产生的资源中
annotations:
kustomize.generated.resource: somevalue
＃disableNameSuffixHash是真的禁止添加的默认行为后缀来生成资源的名称是的散列资源内容。
disableNameSuffixHash: true
＃此列表中的每个条目都应解析为目录，包含kustomization文件，否则定制失败。
＃该条目可以是指向本地目录的相对路径或指向远程仓库中目录的URL。
＃该网址应遵循hashicorp/go-getter网址格式，如：https ://github.com/hashicorp/go-getter#url-format
＃此字段的存在表示此文件（文件你阅读）是一个_overlay_进一步自定义来自这些_bases_的信息。
＃典型用例：开发，升级和生产环境大多相同但不同重要方式（image tags, a few server arguments, etc. that differ from the common 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＃此列表中的每个条目都应解析为部分或完整的资源定义文件。
＃这些（可能是部分）资源文件中的名称必须匹配已经通过`resources`加载的名称字段或通过`resources`经由传递地加载`base`条目。这些条目用于_patch_（修改）已知资源。
＃做一件事的小补丁是最好的，例如修改内存请求/限制、更改一个 ConfigMap的env var等小补丁。
patchesStrategicMerge:
- service_port_8888.yaml
- deployment_increase_replicas.yaml
- deployment_increase_memory.yaml＃image修改名称，tag或image digest，而无需使用patches。
＃例如，鉴于这种kubernetes部署片段：
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# Vars are used to capture text from one resource's field
# and insert that text elsewhere.
#
# For example, suppose someone specifies the name of a k8s Service
# object in a container's command line, and the name of a
# k8s Secret object in a container's environment variable,
# so that the following would work:
# ```
# containers:
# - image: myimage
# command: ["start", "--host", "$(MY_SERVICE_NAME)"]
# env:
# - name: SECRET_TOKEN
# value: $(SOME_SECRET_NAME)
# ```
#
# To do so, add an entry to `vars:` as follows:
#
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
更多详细说明，参考：
https://github.com/kubernetes-sigs/kustomize/blob/master/docs/kustomization.yaml
https://kubectl.docs.kubernetes.io/pages/examples/kustomize.html