1. リソースがetcdに書き込まれる前の最後の関門 — admission controlとは何か
Kubernetes v1.36でGAしたMutatingAdmissionPolicyは、この「受け入れる状態を決める層」の仕組みを変える機能だ。Kubernetesの中核には、望ましい状態と実際の状態を常に比較し続け、差分があれば自動的に修正するという単純な仕組みがある。デプロイメントに「10個のPodを動かしてほしい」と伝えれば、Kubernetesはそれを実現し続ける。しかし、この仕組みが機能する前提には、「そもそも何を望ましい状態として受け入れるか」を決める層が存在する。それが admission control だ。
Podがetcdに書き込まれる直前、APIサーバーは2段階のチェックを行う。まずMutating admissionでリソースを変更し、次にValidating admissionで内容を検証する。この順序と仕組みはKubernetes公式ドキュメントに明記されている。ラベルの自動付与、デフォルト値の設定、サイドカーコンテナの注入といった処理は、すべてこのMutating admissionの段階で行われる。
長らく、この段階をカスタマイズする唯一の方法はMutating Admission Webhookだった。そして2026年、この前提を変える機能がKubernetes本体に入った。MutatingAdmissionPolicyだ。
2. Mutating Webhookの運用コスト — 証明書・ネットワークホップ・可用性
Mutating Webhookを自前で運用したことがあるチームなら、その運用コストに心当たりがあるはずだ。Kubernetes公式ドキュメントによると、WebhookConfigurationにはPEM形式でBase64エンコードされたCA証明書（caBundle）が必須で、サーバー証明書は<svc_name>.<svc_namespace>.svc形式で有効でなければならない。証明書が期限切れになれば、Webhook自体が機能を失う。
さらに、Webhookサーバーをクラスタ内にDeploymentとして動かす場合、そのPod自体の可用性もチームが担保しなければならない。タイムアウト設定（デフォルト10秒）とfailurePolicy（FailかIgnoreか）の組み合わせ次第では、Webhookサーバーの障害がPodの作成そのものを止めてしまう。公式ドキュメントも「Admission webhookは本質的にクラスタコントロールプレーンの一部であり、本番環境では細心の注意を払って構築・デプロイする必要がある」と明記している。
要するに、Mutating Webhookは「証明書管理」「ネットワークホップ」「可用性確保」という3つの運用負債を常に抱え続ける仕組みだった。
3. MutatingAdmissionPolicyは何を変えるのか — CELでAPIサーバー内蔵のミューテーション
MutatingAdmissionPolicyは、KEP-3962として提案され、v1.32でalpha、v1.34でbetaを経て、**v1.36でGA（安定版）**に到達した。Kubernetes v1.36の公式リリース記事でも、ValidatingAdmissionPolicyとMutatingAdmissionPolicyがデフォルト有効になったことが明記されている。
仕組みはシンプルだ。Kubernetes公式ドキュメントによれば、MutatingAdmissionPolicyは3つのリソースで構成される。
- MutatingAdmissionPolicy: ミューテーションの抽象ロジックをCEL式で定義する
- パラメータリソース（任意）: ConfigMapやCRDなどで設定値を渡す
- MutatingAdmissionPolicyBinding: ポリシーとパラメータを紐づけ、適用スコープ（対象リソース種別など）を指定する
例えばサイドカー注入は、以下のようなCEL式で表現できる。
mutations:
- patchType: "ApplyConfiguration"
applyConfiguration:
expression: >
Object{
spec: Object.spec{
initContainers: [
Object.spec.initContainers{
name: "mesh-proxy",
image: "mesh/proxy:v1.0.0"
}
]
}
}
外部サービスも証明書も登場しない。CEL式はAPIサーバー内で直接評価され、ネットワークホップそのものが消える。CNCFブログも「外部ツールがネットワーク呼び出しに依存するのに対し、CELはAPIサーバーに直接埋め込まれているため遅延が削減され信頼性が向上する」と指摘している。CEL式はループや再帰を持たないため線形時間で実行され、v1.32以降はコスト推定器によってAPIサーバーの過負荷も防がれる。
既存のMutating Webhookから移行する場合も、ApplyConfiguration戦略に加えてJSON Patch戦略が用意されており、既存のWebhookロジックをそのまま移植しやすい設計になっている。
4. どこまでCELに置き換えられるか — 判断基準
ここで誤解してはいけないのは、MutatingAdmissionPolicyはWebhookの「全廃」ではなく「代替」だという点だ。判断基準は次の2軸で整理できる。
CELに置き換えるべきケース
- 固定ラベル・アノテーションの付与
- フィールドのデフォルト値設定
- 既存コンテナの有無をチェックしたうえでのサイドカー追加（
matchConditionsで重複注入を防げる）
これらは宣言的に表現でき、外部の状態を参照する必要がない。
Webhookのまま残すべきケース
- 外部データベースやAPIへの問い合わせが必要なミューテーション
- 複数の外部システムとの整合性チェックを伴う複雑なロジック
- CELの式では表現しきれない手続き的な処理
なお、こうした新機能は標準Kubernetes API上で動く機能であるため、K3sベースのKuboのような環境であれば、ディストリビューション側の対応を待つ必要がなく素のKubernetesとして利用できる。
実際、Kyverno自身もこの境界線を踏まえた移行を進めている。Nirmataのブログによると、Kyvernoは旧来のパターンベースのClusterPolicyを段階的に廃止し（v1.17で非推奨、v1.20での削除を予定）、MutatingPolicyを含む5つのCELベースの新しいAPIタイプへ移行している。記事は「CELはKubernetes自身がValidatingAdmissionPolicyで使っているのと同じ式言語であり、CELを学ぶことはKubernetesガバナンスツール全体に通用するスキルを身につけることだ」と述べている。
5. K3s運用での移行判断と実践ステップ
K3s公式サイトが謳う通り、K3sは「IoT & Edge computingのための認定Kubernetesディストリビューション」であり、70MB未満の単一バイナリに標準的なKubernetes APIをそのまま内包している。K3sのリリースノートが示す通り、K3s v1.36系はKubernetes v1.36をベースにしており、MutatingAdmissionPolicyはK3s上でも素のKubernetes機能としてそのまま利用できる。ベンダー独自の制限や追加設定は必要ない。
移行の進め方としては、まず既存のMutating Webhookを棚卸しし、「固定ラベル付与」「デフォルト値設定」「単純なサイドカー注入」といった宣言的に表現できるものと、「外部状態に依存する複雑なロジック」を分類する。前者から段階的にMutatingAdmissionPolicyへ移行し、matchConditionsで対象スコープを絞り込んだうえで、まずはfailurePolicy: Ignoreのdry-run的な設定で既存リソースへの影響を確認してから本番適用するのが安全だ。
K3sベースのKuboのように標準Kubernetes APIをそのまま使える環境であれば、こうした新機能も特別な対応なしに利用できる。EKSやAKSのような独自レイヤーを挟まないぶん、本体の進化をそのまま享受できるのはK3sベース基盤の利点のひとつだ。
Mutating Webhookの運用で証明書の期限切れやPodの可用性に悩まされてきたチームにとって、棚卸しと段階移行そのものが手間に感じられるかもしれない。Kubo CloudのCaptain UIを使えば、どのリソースにどのadmission policyが適用され、どんな変更が加えられているかを可視化しながら移行を進められる。ブラックボックスのまま本番にポリシーを適用するリスクを避けたい場合は、お問い合わせから相談してみてほしい。
6. まとめ
MutatingAdmissionPolicyは、Mutating Webhookが抱えてきた証明書管理・ネットワークホップ・可用性確保という3つの運用負債を、CELという宣言的な表現に置き換えることで解消する。ただしそれは全廃ではなく、単純な宣言的変更をCELへ、外部状態に依存する複雑なミューテーションはWebhookへ、という役割分担だ。
K3sは標準Kubernetesのディストリビューションであるため、v1.36以降であればこの機能をそのまま利用できる。MutatingAdmissionPolicyの詳細仕様は公式ドキュメントにまとまっているので、移行前に一読しておくとよい。まずは手元のMutating Webhookを棚卸しし、どこまでをCELに置き換えられるかを見極めることから始めてみてほしい。運用負荷を減らしながら本格的なKubernetesの機能を使い続けたいなら、K3sベースのKuboがその選択肢のひとつになる。EKS/AKSのパワーをそのままに、Vercelのような手軽さでクラスタを運用できる環境を目指すなら、Kuboを検討してみる価値がある。
関連する admission control の深掘りとしては、ValidatingAdmissionPolicyへの移行で何が起きたかや、KyvernoとOPA Gatekeeperの比較も合わせて読んでほしい。