Kubernetes（K8s）のinformerのEvent Handlerと、controller-runtimeのReconcileは、どちらもリソースの変更を検知して処理を行う仕組みですが、役割や動作の違いがあります。
1. InformerのEvent Handler
Kubernetesのinformerは、特定のリソース（Pod, Deployment, Custom Resourceなど）の変更を監視する仕組みです。
Informerには以下のようなEvent Handlerを登録できます：
• AddFunc（追加イベント）
• UpdateFunc（更新イベント）
• DeleteFunc（削除イベント）
動作
• informerはキャッシュ（Store）を持ち、APIサーバーの負荷を減らす
• informerはKubernetes APIサーバーと通信し、リソースの変更をキャッシュに保存する。
• クライアントはAPIサーバーに直接問い合わせるのではなく、キャッシュを参照することで効率的に動作する。
• イベント発生時にハンドラ関数が呼び出される
• 例えば、Podが作成されたらAddFuncが呼ばれる。
メリット
• リソースの追加・更新・削除のイベントごとに個別の処理ができる。
• キャッシュを活用し、APIサーバーへの負荷を減らせる。
デメリット
• イベントのロストや順序の保証がない
• UpdateFuncが連続して発生した場合、一部がスキップされる可能性がある。
• リトライ機能がない
• エラーが発生しても自動リトライはない。
2. Reconcile（controller-runtimeのReconciler）
Kubernetesのcontroller-runtimeを使うコントローラーは、Reconcileメソッドを持つReconcilerを実装する。
動作
• リソースの最終的な状態を保証する
• Reconcileは「あるべき状態」に修正するための関数であり、イベントベースではなく「状態ベース」。
• キュー（WorkQueue）を使用
• 変更があると、Reconcileがワークキューにエンキューされ、実行される。
• リトライ機能がある
• Reconcileがエラーを返すと、自動的にリトライされる。
• イベントではなくリソースの現在の状態を確認
• informerがキャッシュに持つリソース情報を取得し、必要な修正を加える。
メリット
• イベントのロストがない
• 変更のたびにリソースの「現在の状態」を取得して処理するので、個々のイベントを逃すことがない。
• リトライ機能がある
• 失敗しても再実行されるため、信頼性が高い。
• 最終的な整合性を保証
• 例えば、「Podが必ず3つ動いているべき」なら、その状態になるまで何度でも調整する。
デメリット
• 単純なイベント処理にはオーバーヘッドがある
• 状態を常に確認しながら処理するため、軽量な処理には向かない。
3. 使い分け
| 比較項目 |
InformerのEvent Handler |
Reconcile（controller-runtime） |
| 仕組み |
イベント駆動型 |
状態駆動型 |
| 主な目的 |
単純なイベント処理 |
あるべき状態の維持 |
| イベントのロスト |
あり（処理が間に合わない場合） |
なし（リソースの最終状態を保証） |
| リトライ機能 |
なし |
あり |
| キャッシュ利用 |
あり |
あり（controller-runtimeも利用） |
| 具体的な用途 |
ログ出力・メトリクス更新 |
カスタムコントローラーの実装 |
• イベントをトリガーに即時処理したい場合（ロギング、メトリクス更新）
→ informer のEvent Handlerを使う
• リソースの状態を維持する（例：Deploymentのレプリカ数管理、カスタムコントローラー）
→ Reconcile を使う
補足
controller-runtimeのReconcilerも内部的にinformerを利用してリソースの変更を検知するが、単なるイベント処理ではなく、最終的なリソースの状態を保証するように作られている。
Kubernetes（K8s）のinformerのEvent Handlerと、controller-runtimeのReconcileは、どちらもリソースの変更を検知して処理を行う仕組みですが、役割や動作の違いがあります。
1. InformerのEvent Handler
Kubernetesのinformerは、特定のリソース（Pod, Deployment, Custom Resourceなど）の変更を監視する仕組みです。
Informerには以下のようなEvent Handlerを登録できます：
• AddFunc（追加イベント）
• UpdateFunc（更新イベント）
• DeleteFunc（削除イベント）
動作
• informerはキャッシュ（Store）を持ち、APIサーバーの負荷を減らす
• informerはKubernetes APIサーバーと通信し、リソースの変更をキャッシュに保存する。
• クライアントはAPIサーバーに直接問い合わせるのではなく、キャッシュを参照することで効率的に動作する。
• イベント発生時にハンドラ関数が呼び出される
• 例えば、Podが作成されたらAddFuncが呼ばれる。
メリット
• リソースの追加・更新・削除のイベントごとに個別の処理ができる。
• キャッシュを活用し、APIサーバーへの負荷を減らせる。
デメリット
• イベントのロストや順序の保証がない
• UpdateFuncが連続して発生した場合、一部がスキップされる可能性がある。
• リトライ機能がない
• エラーが発生しても自動リトライはない。
2. Reconcile（controller-runtimeのReconciler）
Kubernetesのcontroller-runtimeを使うコントローラーは、Reconcileメソッドを持つReconcilerを実装する。
動作
• リソースの最終的な状態を保証する
• Reconcileは「あるべき状態」に修正するための関数であり、イベントベースではなく「状態ベース」。
• キュー（WorkQueue）を使用
• 変更があると、Reconcileがワークキューにエンキューされ、実行される。
• リトライ機能がある
• Reconcileがエラーを返すと、自動的にリトライされる。
• イベントではなくリソースの現在の状態を確認
• informerがキャッシュに持つリソース情報を取得し、必要な修正を加える。
メリット
• イベントのロストがない
• 変更のたびにリソースの「現在の状態」を取得して処理するので、個々のイベントを逃すことがない。
• リトライ機能がある
• 失敗しても再実行されるため、信頼性が高い。
• 最終的な整合性を保証
• 例えば、「Podが必ず3つ動いているべき」なら、その状態になるまで何度でも調整する。
デメリット
• 単純なイベント処理にはオーバーヘッドがある
• 状態を常に確認しながら処理するため、軽量な処理には向かない。
3. 使い分け
• イベントをトリガーに即時処理したい場合（ロギング、メトリクス更新）
→ informer のEvent Handlerを使う
• リソースの状態を維持する（例：Deploymentのレプリカ数管理、カスタムコントローラー）
→ Reconcile を使う
補足
controller-runtimeのReconcilerも内部的にinformerを利用してリソースの変更を検知するが、単なるイベント処理ではなく、最終的なリソースの状態を保証するように作られている。