kustomizeでconfigMapを取り扱うときの注意

configMapGeneratorの動作を考える

現在、kustomizeでConfigMapを処理する方法は2つの方法があり
kustomizeのconfigMapGeneratorが若干クセのある動作をするので
軽くまとめておく

tl;dr

雑に

• 基本的にはconfigMapGeneratorを使おう

configMapの編集するたびに確実にconfigmapを違う名前にしたいのだったら configMapGeneratorを書く

configMapの更新で名前が変わったら困るなら configMapもresourcesに書く

前提

• kustomization.yaml
• deployment.yaml
• configmap

k8s manifestとしてはdeployment + configMapという最小構成を考える

2つの方法の違いを見ていく

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

ここからは2つの方法の違いを見ていく。
deploymentのmanifest deployment.yaml の内容はまったく同じものとする

deployment.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 を読み出すmanifestです

resourcesを使う

kustomization.yaml, deployment.yaml, config.yaml 3つのファイル

kustomization.yaml

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

config.yaml

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

kustomize build 結果

# (一部省略)
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は更新されないこと！！！

resourcesを使うとconfigMapの更新にかかわらず必ず同じ名前を参照する

configMapGeneratorを使う

kustomization.yaml

resources:
- ./deployment.yaml

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

kustomize build 結果

# (一部省略)
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がいいと思う

利用してるdeoloymentも確実に再起動してほしいのであれば
configMapGenerator を使おう

再起動したくないのであればvolume mountしてをconfigmapの変更を監視しようってことになりそう(prometheusは多分sidecar立ててそうしてる)