スケーラビリティ問題を克服：Kubernetes Operatorを再構築した理由
当初作成したKubernetes Operatorが大規模環境でスケールしないという問題に直面。そこで、Architectureを根本から見直し、完全に再構築した。新Operatorはリソース消費を最適化し、大規模クラスターでも安定したパフォーマンスを発揮する。
背景メモ
- Infisicalは、シークレット（APIキーやDBパスワードなど）を一元管理するためのオープンソースツール。開発チームが機密情報をコードに埋め込まずに安全に共有・管理できるようにする。
- Kubernetes Operatorは、Kubernetes（コンテナ管理プラットフォーム）上で複雑なアプリケーション運用を自動化するための仕組み。Infisicalはこれを使い、Kubernetes内のPod（コンテナの実行単位）がシークレット情報を安全に取得できるようにしていた。
- しかし、初期のOperatorアーキテクチャでは、数百〜数千のPodが同時に起動する本番規模のクラスタでパフォーマンスのボトルネック（Operator内のコントローラースレッドが情報取得や更新処理に追いつかない問題）が発生。再設計に至った。
- 本稿では、その再設計の判断理由、アーキテクチャの変更点（コントローラーの分割やキャッシュ戦略の見直しなど）、および得られた教訓を技術的に詳述している。