EKS環境におけるReloader運用改善の取り組み

こんにちは、スタンバイでインフラを担当している勝俣です。

今回はEKSを日々運用していく中で直面した技術的な課題のうち、スタンバイのEKSクラスタに導入している「Reloader」というアプリケーションについて紹介します。

Reloaderとは

KubernetesのConfigMapやSecretの変更を検知し、該当するPodを自動的に再起動してくれる便利なツールです。

スタンバイでは、AWS Parameter Store に機密情報を保存しており、Secret に反映してます。 Parameter Store に保存している機密情報を変更すると Secret も変更されるので、そのために Reloader を使用してます。

https://github.com/stakater/Reloader?tab=readme-ov-file#-what-is-reloader

課題

これまでは、アプリケーションは1つのネームスペース内で稼働させていました。

Reloaderはこのアプリケーションのネームスペースに配置され、このネームスペースのみ監視している状態でした。

スタンバイでは、規模拡大に合わせ新規アプリケーションの構築やリアーキテクチャが行われており、アプリケーションのワークロードや特性ごとに複数のネームスペースに分けたいという要望があがってきました。

そのため、今後構築される新規のネームスペースも同様にReloaderに監視させる必要があり、稼働中のEKSクラスタに対して設定変更が必要でした。

設定変更概要

現状のReloaderは以下のような設定になっていました。

既存アプリケーションと同じネームスペースに配置され、そのネームスペースのみを監視している
- その中で annotation が設定されている pod が監視対象

対して、新規追加したネームスペースも監視できるよう以下のような方針で設定変更する事を決めました。

Reloader専用のネームスペースに配置し、全ネームスペースを監視する
- その中でannotationが設定されている pod が監視対象

結果的に、以下のようなステップで設定変更を実施しました。

Reloader専用ネームスペースを作成
Reloaderの設定を変更し、全てのネームスペースを監視するように変更
Reloader専用ネームスペースにReloaderを再配置

それぞれ解説していきます。

1.Reloader専用ネームスペースを作成

Reloaderを他のアプリケーションリソースと分離することで、他のアプリケーションリソースとの混在を防ぎ、クラスタに対するオペレーション時のメンテナンス性を向上させる為、新しくReloader専用のネームスペースを作成します。

前提として、スタンバイはEKSクラスタと内部のコンポーネントをterraform+helm、アプリケーションをArgoCDで構成しています。

ネームスペースに関してはterraformを使用して構築しており、以下が実際のコードです。

resource "kubernetes_namespace" "reloader" {
  metadata {
    name = "reloader"
  }
}

2.Reloaderの設定を変更し、全てのネームスペースを監視するように変更

Reloader自体はterraform+helmで実装されています。

ここでは、reloader.watchGloballyの値をfalseからtrueに変更します。

これにより、Reloaderが配置されているネームスペースのみを監視している状態から、配置されているネームスペースを問わず全ネームスペースを監視する状態になります。

values.yaml の中の以下の設定を変更します。

reloader:
  reloadStrategy: annotations
  watchGlobally: true   # ここを変更

3.Reloader専用ネームスペースにReloaderを再配置

以下が実際のコードで、1.で構築した専用のネームスペースを指定しています。

配置ネームスペースの変更により、helmチャートのreplaceが走り、deploymentの削除→作成が行われます。

locals {
  helm_reloader = {
    repository = "https://stakater.github.io/stakater-charts"
    version    = "1.X.X"
  }
}

resource "helm_release" "reloader" {
  name       = "reloader"
  chart      = "reloader"
  repository = local.helm_reloader.repository
  version    = local.helm_reloader.version
  namespace  = kubernetes_namespace.reloader.id     # ここを変更

  values = [
    templatefile("_files/reloader/values.yaml", {
      env     = var.env
      version = local.helm_reloader.version
    })
  ]

}

テストや検証について

設定自体は至ってシンプルですが、既に稼働している環境への設定変更となるので、検証・調査に多くの時間を割きました。

起こり得るシナリオを列挙したラフを作成し、チーム内でブラッシュアップを重ね、テストケースに落とし込みました。
正常系の動作確認方法の一部ですが、以下のような方法を実施しました。
- Reloaderのログレベルreloader.loglevelをdebugに変更
```
reloader:
  logLevel: debug
```
- 適当なアプリケーションのConfigMap/Secretを以下のように手動で変更
```
### ConfigMap
$ kubectl patch configmap hoge-staging --type merge -p '{"data":{"HOGE":null}}'

### Secret
$ kubectl label secret hoge-staging hoge/hoge=hoge --overwrite
```
- 対象のpodsが再起動されている事を確認
  
  $ kubectl get pods | grep hoge
- Reloaderのログからも変更が検知されている事を確認
```
  $ kubectl logs reloader-6fc54b7755-b2stv | tail -n1
  time="2025-06-11T09:09:12Z" level=info msg="Changes detected in 'hoge-staging' of type 'SECRET' in namespace 'A'; updated 'hoge-staging' of type 'Deployment' in namespace 'A'"
```
- Reloaderの監視対象に変更があった際に付与している※¹hash値が変更前後に変わっていない事も確認。

上記に加え、異常系等の様々なパターンのテストを実施し、既存のpodに影響が無いことを確認できたので、特に不安要素は無く安心してリリースできました。

※¹ reloader.reloadStrategyで、どこにhashを記録しそれをトリガーにするかを選択が可能。スタンバイにおいてはannotationsを使用しており、以下のようなhash値が付与されていました。

$ kubectl describe deployment reader-api-staging | grep -iA1 reloaded
                    reloader.stakater.com/last-reloaded-from:
                      {"type":"CONFIGMAP","name":"reader-api-staging","namespace":"A","hash":"stanbytechblognisanjoucbeb27969f21cd937800632c8602f737d","conta...