stakater/Reloader
通常 kubernetesにおいてはConfigMapやSecretが更新された際、それに紐付いたリソース(deployment/daemonset/statefulset等)はそれを検知して再起動するという機能はない。
これを提供するのが、 stakater/Reloader である。
Install
マニフェストをそのままapplyすることで導入できる。
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml
この他にもHelm ChartやKustomizeでのインストールも可能らしい、詳しくはリポジトリのREADMEを参照してほしい。
Usage
指定したConfigMap/Secretの変更を検知してローリングアップデートを実行する
<configmap|secret>.realoader.stakater.com/reload: "<comma-separated-names>" という形式のannotationをDeployment等に追加するだけで良い。
関連するConfigMap/Secretの変更を検知してローリングアップデートを実行する
また、 reloader.stakater.com/auto: "true" を設定しておけば、そのリソースに紐付いたConfigMap/Secretの更新時に自動で関係するpodをローリングアップデートしてくれるらしい。
この時の対象となるConfigMap/Secretの探索をannotationで指定したものに限定したい場合は、 reloader.stakater.com/search: "true" を設定することで実現できる。
この際ローリングアップデートを発火するConfigMap/Secretには reloader.stakater.com/match: "true" のannotationを指定しておく必要がある。
自宅内運用
自宅では、基本的にはローリングアップデートをトリガーしたいConfigMap/Secretを指定する形でannotationを設定する形で採用した。
これは、意図しないタイミングでのローリングアップデートの実行が怖いのと、ConfigMap/Secretの手動更新時には既に手オペが発生しているので自動更新する必要もないだろうという算段がある。
特に、今回必要となった要因は、OAuthの古いtokenがexpireした際にSecretを更新する方法としてOAuthの砲台からAccess TokenをSecretに保存するpodがいるので、こいつのSecret保存時に手オペするのが面倒という理由だけなので、必要以上に影響範囲を増やさないで運用しようという結論である。
所感
kubernetes内に自身(k8s)内部のConfigMap/Secretを変更しうるサービスが存在しうる場合には非常に助かるツールだとは感じた。
一方でとりあえず入れておいたら便利！という形で導入するにはオーバーパワーな感じもする。
kubernetes内でConfigMap/Secretを変更するようなシステムを運用していて、かつその変更に追従して更新したいリソースがある各位は試してみてはいかがだろうか。(いるのか？)
