はじめに
Kubernetesのガバナンスやセキュリティは、API ServerのAdmission制御だけで完結するわけではありません。 実際には、kube-controller-managerがリソースの状態を監視し、クラスタの望ましい状態（Desired State）を維持することで、Admissionで許可された設定を実際のクラスタ状態に反映します。
つまりKubernetesの制御は以下の2段階で構成されています：
- Admission Layer：リソース作成時の検証・制御
- Controller Layer：作成されたリソースの実際の状態管理
本記事では、Admission PluginsとController Managerの連携モデルを詳しく解説します。
1. Kubernetes制御プレーンの役割分担
Kubernetesの制御プレーンは主に以下のコンポーネントで構成されています。
| コンポーネント | 役割 |
|---|---|
| API Server | リソース管理・Admission制御 |
| etcd | クラスタ状態保存 |
| Controller Manager | リソース状態の調整 |
| Scheduler | Pod配置決定 |
Admission制御はAPI Server、実際のリソース管理はController Managerが担当します。
2. Admission → Controller連携フロー
kubectl apply ↓ API Server ↓ Admission Plugins ↓ etcdへ保存 ↓ Controller ManagerがWatch ↓ 必要なリソース作成・調整 Controller ManagerはAPI Serverの変更をWatch APIで監視しています。
3. Controller Managerの主要コントローラー
kube-controller-managerは複数のコントローラーを内部に持っています。
代表例：
- Deployment Controller
- ReplicaSet Controller
- Node Controller
- ServiceAccount Controller
- ResourceQuota Controller
- Namespace Controller
これらはすべてイベント駆動型で動作します。
4. ResourceQuotaとAdmission Pluginの連携
ResourceQuotaはAdmissionとControllerの両方が関与する代表的な例です。
Admission側
ResourceQuota Admission Pluginが、リソース作成時にQuota超過をチェックします。
--enable-admission-plugins=ResourceQuota Controller側
ResourceQuota Controllerが使用量を定期的に更新します。
Quota Used CPU = Sum(Pods CPU Requests) つまり：
- Admission → リソース作成を制御
- Controller → 使用量を計算
5. ServiceAccount Controllerとの連携
ServiceAccount Controllerは、Namespace作成時に自動的に以下を作成します。
default ServiceAccount
Secret（Token）
Admission Pluginの動作：
ServiceAccount PluginがPodにSAを自動付与
フロー：
Namespace作成 ↓ ServiceAccount Controller ↓ default ServiceAccount生成 ↓ Pod作成 ↓ Admission PluginがSA付与 6. Namespace Lifecycle Controllerとの連携
Namespace削除時の処理もController Managerが担当します。
フロー：
kubectl delete namespace ↓ Namespace Controller ↓ リソース削除 ↓ finalizers処理 ↓ Namespace削除完了 Admission Pluginは削除中Namespaceへの作成を拒否します。
7. LimitRanger Controllerとの関係
LimitRangerは以下の2層構造です。
Admission Plugin
リソース作成時に default requests / limits を付与
Controller
NamespaceのLimitRangeオブジェクトを管理
例：
default: cpu: 100m memory: 128Mi Podがリソース指定なしで作成されても自動補完されます。
8. Controller Managerの内部構造
Controller Managerは以下のアーキテクチャを持ちます。
Controller Manager ↓ Shared Informer ↓ Work Queue ↓ Controller Worker Informer
API Serverの変更イベントをキャッシュ
WorkQueue
処理対象をキュー化
Controller Worker
状態調整（Reconcile）
この仕組みをReconciliation Loopと呼びます。
9. AdmissionとControllerの責務分離
| 層 | 責務 |
|---|---|
| Admission | リクエスト検証 |
| Controller | 状態維持 |
例：
- Admission → Pod specが安全か
- Controller → Pod数を維持
10. 実務設計モデル
推奨構成：
Admission Layer ├ PSA ├ Gatekeeper ├ Kyverno Controller Layer ├ ResourceQuota Controller ├ Deployment Controller ├ Namespace Controller この2層モデルにより、Kubernetesのセキュリティと運用安定性が実現されます。
まとめ
- AdmissionはAPI Serverで実行
- Controllerはクラスタ状態を調整
- ResourceQuotaやLimitRangerは両方が関与
- ControllerはInformer + WorkQueueでイベント処理
Kubernetesのガバナンスを理解するには、AdmissionとControllerの協調動作を把握することが重要です。
