地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【k8s】configMapGeneratorをconf書き換え時にdeploymentを再作成させる

kustomize.io

背景/概要

Configmapは通常書き換えただけだとその内容は既存のpodには反映されない。この仕組み自体は役立つケースもあるがミドルウェアの修正時に即座に反映させたいケースで人の手を介してkubectl の rollout restartを打つ必要が出てきてしまう。

そこで便利なのがkustomizeのconfigMapGeneratorです。これを使うことでconfigmapを修正したタイミングでdeploymentがいい感じにpodを再作成してくれます。

やり方は二通りあって

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

の二つをこの記事では取り上げてみます。(kustomizeの知識が前提となります。)

configMapGeneratorとは

github.com

ConfigMap のリソース名にハッシュを含めて,結果的にローリングデプロイのような挙動を実現できるようになる仕組みを提供してくれるkustomizeの機能の一つ。

使ってみる

ディレクトリ構成。overlays配下にdev/prodというステージを分けて置いておく。configmapGenaratorはoverlays配下のkustomizations.yamlへ記載する

.
├── base
│   ├── flask.yml
│   └── slbot.yml
├── overlays
│   ├── dev
│   │   ├── flask.yml
│   │   └── kustomization.yaml
│   └── prod
│       ├── flask.yml
│       └── kustomization.yaml

記載するイメージは以下。configMapGenerator.nameにpodのコンテナから使いたい名前を指定しておく。

bases:
- ../../base

resources:
- flask.yml

configMapGenerator:
- name: awesome-config-map
  literals:
    - foo=map2
    - bar=map2
    - baz=map3

使用したpodでenvFromを定義する。

        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: awesome-config-map
              key: foo

この状態でkustomize buildを実行すると出力されるmanifestのconfigMapKeyRefの値に冒頭でのべたハッシュ値が付与されていることがわかる。

        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              key: foo
              name: awesome-config-map-8h7925dg8

この時にconfigMapGeneratorの値を書き換えると以下のようにハッシュ値が変わっていることがわかる。この変更をdeploymentは検知してpodを再生成する。

        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              key: foo
              name: awesome-config-map-kbhtkh2mkf

ミドルウェアのconfigを管理させたい

confをyamlで宣言するとテストが大変だったりvimのsyntaxがいい感じに効かなかったりと良いことがあまりないかもしれません。

.
├── conf
│   └── nginx.conf
├── flask.yml
└── kustomization.yaml

と、いうような構成の時にkustomization.yamlへ以下のように記述することで上で書いたようなことがfileでもできます。

- name: nginx.conf
  files:
  - conf/nginx.conf

この状態でconf配下のファイルを修正しapplyすることでpodが再作成されconfを読み込むことができます。podは再作成になるのでこの辺のダウンタイムの考慮が必要となるので注意が必要です。readinessprobeを使って大体大丈夫そう。

感想

ConfigMapという機能自体はそれ単体でもとても便利な仕組みだなと感じていましたがkustomizeと組み合わせることでさらに便利になることを知りました。今回の例でいうとミドルウェアの設定を取り上げましたがカーネルパラメータの設定値や言語特有のランタイムの起動時のオプションなんかもconfigMapで用意して置いて使うと言ったケースもありかなと思いました。(マルチステージビルドしたコンテナのステージを選択すれば良いだけなのでここでやる話でもないかもです)