Edited at

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立ててそうしてる)