Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

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

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away