KyvernoとOPA Gatekeeper、2026年はもう「機能」では決まらない
K3sクラスタに監査対応のポリシーを入れようとしたとき、多くのチームが最初に迷うのが「Kyvernoにするか、OPA Gatekeeperにするか」という選択です。数年前まではこの比較には明確な答えがありました。しかし2026年の今、状況は変わっています。
Kyvernoは2026年3月、KubeCon + CloudNativeCon North EuropeにてCNCFの最高成熟度「Graduated」に到達したことが発表されました。2020年11月のCNCF参加時に574個だったGitHubスターは9,000個を超え、Bloomberg・Coinbase・LinkedIn・Spotifyといった企業が本番採用しています。最新リリースではCEL（Common Expression Language）を完全採用し、Kubernetes標準のアドミッション制御の方向性にも足並みを揃えました。
一方のOPA Gatekeeperも、ConstraintTemplateとConstraintという2段構成のCRDモデルを軸に、パラメータ化可能なポリシーライブラリと外部データ連携を強化し続けています。2026年4月時点の実測比較では、主要なアドミッション制御機能において両者はほぼ収斂しつつあります。つまり「どちらが高機能か」という問いにはもう意味がなく、選定は**「自分たちのクラスタでどちらが安全に運用できるか」**という、より実務的な問いに変わっています。
本記事では、K3sのような軽量・リソース制約クラスタを前提に、Kyverno と OPA Gatekeeper の実運用上の差を具体的なデータで検証します。こうしたポリシー運用の設計判断は地味に見えて事故に直結するため、KuboのようなマネージドK3s環境でどこまで標準化・可視化できるかも併せて考えていきます。
YAMLかRegoか — チーム全員が書けるかという分かれ道
KyvernoとOPA Gatekeeperの最も本質的な違いは、ポリシー言語そのものです。
KyvernoはポリシーをKubernetesリソースと同じYAMLで記述します。kubectl、Git、Kustomizeといった既存ツールチェーンにそのまま乗せられるため、Kubernetesの知識があればほぼ学習コストなしでポリシーを書き始められます。
対してOPA Gatekeeperは、Open Policy Agent由来のRegoという専用のクエリ言語を使います。Regoは表現力が高く複雑な条件分岐も書けますが、Kubernetesエンジニアにとっては新しいプログラミング言語を1つ学ぶのに等しいコストがかかります。
この差が実際の組織でどう効いてくるかを示す事例があります。欧州の大手マーケットプレイス企業Adevintaのランタイムチームは、もともとGatekeeperを使っていましたが、メタデータ追加やnodeSelector/affinityの変更といった「リソースを書き換える」要件が増えたタイミングで壁にぶつかりました。Gatekeeperの変更機能（Assign）は基本的な要件すら満たせなかったのです。
最終的にAdevintaがKyvernoへの移行を決めた理由は3つでした。
- 習熟しやすさ: YAMLベースでRegoより学習コストが低く、チーム全体がポリシー作成に参加できる
- 機能の完全性: ValidatingWebhookとMutatingWebhookの両方をネイティブにサポートしている
- リソース効率: ポリシーが複雑化してもメモリ効率で優位だった
実際、Kyvernoはvalidate（検証）だけでなくmutate（既存リソースの書き換え）とgenerate（関連リソースの自動生成）までをアドミッションコントローラ・バックグラウンドコントローラ・レポートコントローラという3つのコントローラで一体的に扱えるよう設計されています。Gatekeeperがvalidationを主軸に据えているのとは対照的です。
K3sの本番で起きる最大の落とし穴 — ワイルドカードポリシーという爆弾
機能面の違い以上に、K3sのような軽量・リソース制約クラスタで致命的になるのがポリシーの書き方そのものです。
Kyverno公式のスケーリングガイドは次のように警告しています。ポリシーの対象リソースをワイルドカード（*）でマッチさせると、Kyvernoはクラスタ内のあらゆるオペレーション（CREATE / UPDATE / DELETE / CONNECT）をすべてのリソースに対して処理することになります。これはクラスタの規模とは無関係に発生し、たった1つの単純なポリシーでも計算負荷を急増させる原因になります。
同様の注意はKubernetes公式のAdmission Webhookベストプラクティスにも明記されており、「設計の悪いWebhookは、オブジェクトに対して持つ制御の強さゆえにワークロード障害を引き起こしやすい」と警鐘を鳴らしています。公式ドキュメントが推奨するのは、対象リソースを必要最小限に絞り込み、マッチ条件で不要な呼び出しを削減することです。
通常のマネージドKubernetesであれば、多少のオーバーヘッドはノードのスケールアウトで吸収できます。しかしK3sは最初からリソース制約を前提に設計された軽量ディストリビューションです。CPU・メモリに余裕のない環境でワイルドカードポリシーを1つ入れてしまうと、API Server全体のレイテンシに直結するリスクがあることは、K3s運用者ほど強く意識すべきポイントです。
レプリカ1台とp99レイテンシ — 実測データで見る限界点
Kyverno自身もこの負荷問題を認識しており、継続的にパフォーマンス改善に取り組んできました。CNCFブログで公開されたパフォーマンス最適化レポートによると、v1.10からv1.12にかけて次のような改善が実測されています。
- 25仮想ユーザー・250イテレーション条件: 平均レイテンシ127.95ms → 15.52ms
- 100仮想ユーザー・1000イテレーション条件: 平均レイテンシ430.43ms → 64.34ms
約8倍の改善です。技術的には、JSONベースのコンテキストストレージをGolangのin-memoryマップに置き換え、ポリシーマッチングを早期リジェクト方式に再構成したことが効いています。あわせて、EventBroadcasterが過剰にgoroutineを生成することで発生していたメモリスパイクとOOMKillも、カスタムWatcher実装によって解消されました。
それでもなお、レプリカ構成がボトルネックになることは変わりません。Kyverno公式のスケーリングガイドが示す負荷テストでは、シングルレプリカで500同時オペレーションという高負荷下では、p99レイテンシが1秒を超えます。一方、3レプリカ構成にすると同じ条件下でもp99は650ms未満に収まります。
K3sの導入現場では「軽量だから」という理由でコントロールプレーン・アドオンの両方をシングルレプリカで運用するケースが少なくありません。しかしポリシーエンジンに関しては、ポリシー数が増えるほどこの前提が崩れやすく、水平スケーリング（レプリカ追加)を前提にリソース設計することが、K3s環境でこそ重要になります。こうしたレプリカ構成やリソース配分の設計は、Kubo Cloudのように監視・スケーリングが標準で組み込まれた基盤であれば、Captain UI上でp99レイテンシの悪化に気づきやすくなります。
結局どちらを選ぶべきか — K3s本番運用の判断基準
ここまでの技術的な違いを踏まえると、K3sの本番運用における判断基準は次のように整理できます。
Kyvernoを選ぶべきケース
- Kubernetesネイティブなワークフロー（kubectl / Git / Kustomize）でポリシーも一元管理したい
- メタデータ付与・nodeSelector変更など、リソースのmutation/generationが必要
- チーム全体（Rego未経験者を含む）でポリシーをメンテナンスしたい
- GitOpsを中心にポリシーもコードとして運用したい
OPA Gatekeeperを選ぶべきケース
- 既にRego・OPAに投資済みで、Kubernetes以外（Terraform、HTTP API等）も含めた横断ガバナンスをしたい
- 非常に複雑なロジックを1つのポリシーに凝縮する必要がある
- ConstraintTemplateによる再利用可能なポリシーライブラリの仕組みを重視したい
2026年4月時点の実機比較でも、Kyvernoのmutation機能はGA済みで同一のClusterPolicyリソース内で完結する一方、Gatekeeperのmutationは依然alpha扱いで別のCRDが必要とされており、mutation/generation要件の有無が今なお両者を分ける実質的な分岐点であることが裏付けられています。
どちらを選ぶにせよ、K3sのような軽量クラスタでは**「ポリシー言語の選択」よりも「ポリシーのスコープ設計」が本番運用の成否を分ける**という点は共通して意識すべきです。ワイルドカードマッチを避け、対象リソース・オペレーションを絞り込み、レプリカ数を負荷テストに基づいて設計する。この地道な設計判断の積み重ねが、本番障害を防ぐ最後の砦になります。
まとめ
KyvernoとOPA Gatekeeperは2026年時点で機能的にはかなり近づきました。しかし実際にK3sの本番クラスタで差が出るのは、YAMLかRegoかという言語選択以上に、ワイルドカードポリシーの設計ミスとレプリカ構成の設計不足です。どちらのツールを選んでも、軽量クラスタ前提の負荷設計を怠れば同じ壁にぶつかります。
こうしたポリシー運用の複雑さを、自前で一から設計・監視していくのは決して簡単ではありません。改めて、KuboはK3sベースのマネージドKubernetesとして、Captain UIによる可視化と標準化された運用基盤を提供し、ポリシー運用のような「地味だが事故に直結する」設計判断をチームが見落としにくい形で支援します。
特に金融・医療のように厳格なガバナンス要件がある組織では、ポリシー強制の仕組みそのものを自社で完全にコントロールしたいというニーズもあるはずです。そうした場合は、Kubo On-Premiseであれば、Air-Gapped環境でも完全自社管理のK3sクラスタ上でポリシー運用を標準化できます。
EKS/AKSのような高コスト・複雑な管理から離れ、K3sの軽量性を活かしながらポリシー運用まで含めて本番品質を担保したいなら、Kubo Cloudの構築済み標準構成から始めるのも一つの選択肢です。まずはお問い合わせから、自社クラスタのポリシー運用の現状を相談してみてください。