背景/概要
Configmapは通常書き換えただけだとその内容は既存のpodには反映されない。この仕組み自体は役立つケースもあるがミドルウェアの修正時に即座に反映させたいケースで人の手を介してkubectl の rollout restartを打つ必要が出てきてしまう。
そこで便利なのがkustomizeのconfigMapGeneratorです。これを使うことでconfigmapを修正したタイミングでdeploymentがいい感じにpodを再作成してくれます。
やり方は二通りあって
- resources の中に書いてresourceとして処理する
- kustomization.yaml にconfigMapGeneratorとして書く
の二つをこの記事では取り上げてみます。(kustomizeの知識が前提となります。)
configMapGeneratorとは
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で用意して置いて使うと言ったケースもありかなと思いました。(マルチステージビルドしたコンテナのステージを選択すれば良いだけなのでここでやる話でもないかもです)