思考configMapGenerator的运作方式

现在，在kustomize中处理ConfigMap有两种方法，
由于kustomize的configMapGenerator行为有些特殊，
我将简要总结一下。

太长不看

随便地

基本的にはconfigMapGeneratorを使おう

如果每次编辑configMap时确保将configMap更改为不同的名称，可以编写configMapGenerator。

如果在对configMap进行更新时，如果名字发生变化会造成困扰，那么同样将configMap写入resources中。

前提 tí)

• kustomization.yaml

• deployment.yaml

configmap

在Kubernetes中，将deployment和configMap作为最小配置来考虑。

观察两种方法的差异

resources の中に書いてresourceとして処理する
kustomization.yaml にconfigMapGeneratorとして書く

我们将从这里开始看两种方法的区别。
假设 deployment 的清单 deployment.yaml 的内容完全相同。

部署.yaml

# 余計なものを省いています
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  template:
    spec:
      containers:
      - name: api
        envFrom:
        - configMapRef:
            name: awesome-config

这是读取基本的 awesome-config 的清单。

使用资源

kustomization.yaml、deployment.yaml、config.yaml 这三个文件

自定义化配置.yaml

resources:
- ./deployment.yaml
- ./config.yaml

配置文件.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: awesome-config
data:
  foo: a
  bar: b
  baz: c

自定義生成的結果

# (一部省略)
apiVersion: v1
data:
  bar: b
  baz: c
  foo: a
kind: ConfigMap
metadata:
  name: awesome-config
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: awesome-config # !!!ここに注目!!!

值得关注的是

config.yamlを更新してを再び
$ kustomization build

configMapRefで参照しているconfigmap nameは更新されないこと！！！

不管configMap的更新如何，使用resources时总是引用相同的名称。

使用configMapGenerator

自定义化.yaml

resources:
- ./deployment.yaml

# resourcesにconfig.yamlを書かない
configMapGenerator:
- name: awesome-config
  literals:
    - foo=a
    - bar=b
    - baz=c

自定义生成结果

# (一部省略)
apiVersion: v1
data:
  bar: b
  baz: c
  foo: a
kind: ConfigMap
metadata:
  creationTimestamp: null # できてる
  name: awesome-config-cf7cgck6mg
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: api
  name: api
spec:
  template:
    spec:
      containers:                       
      - envFrom:
        - configMapRef:
            name: awesome-config-cf7cgck6mg # !!!ここに注目!!!

值得关注的是

Deploymentが参照している configMapRef.nameが更新されたこと！！！
その後、configMapの内容を書き換えて kustomize buikdを行うとhashが更新された！！！！

> name: awesome-config-tm49dhk965

总结

在kustomize环境下，有两种处理configMap的方法，根据目的选择合适的方法似乎是一个好主意。

但是，在大多数情况下，我认为configMapGenerator是最好的选择。

如果希望确保利用的deployment能够可靠地重新启动，请使用configMapGenerator方法。

如果不想重新启动，可以通过挂载卷并监视configmap的更改来实现（可能会使用prometheus作为sidecar）。