[{"data":1,"prerenderedAt":426},["ShallowReactive",2],{"blog-ja-kyverno-opa-gatekeeper-k3s-wildcard-policy-overhead":3,"blog-related-ja-kyverno-opa-gatekeeper-k3s-wildcard-policy-overhead":368,"blog-ja-kyverno-opa-gatekeeper-k3s-wildcard-policy-overhead-alt":356},{"id":4,"title":5,"author":6,"body":7,"date":350,"description":351,"extension":352,"image":353,"locale":354,"meta":355,"navigation":356,"path":357,"seo":358,"stem":359,"tags":360,"__hash__":367},"blog\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead.md","KyvernoとOPA Gatekeeper、K3sの本番で本当に差が出たのはワイルドカードポリシーだった","Kubo Team",{"type":8,"value":9,"toc":340},"minimark",[10,15,23,26,37,46,55,59,65,68,81,94,107,110,132,135,139,145,152,168,177,184,188,194,203,211,214,225,237,241,247,250,255,269,274,285,294,297,300,311,318,327],[11,12,14],"h2",{"id":13},"kyvernoとopa-gatekeeper2026年はもう機能では決まらない","KyvernoとOPA Gatekeeper、2026年はもう「機能」では決まらない",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Fsection01.webp",[16,24,25],{},"K3sクラスタに監査対応のポリシーを入れようとしたとき、多くのチームが最初に迷うのが「Kyvernoにするか、OPA Gatekeeperにするか」という選択です。数年前まではこの比較には明確な答えがありました。しかし2026年の今、状況は変わっています。",[16,27,28,29,36],{},"Kyvernoは2026年3月、KubeCon + CloudNativeCon North Europeにて",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2026\u002F03\u002F24\u002Fcloud-native-computing-foundation-announces-kyvernos-graduation\u002F",[34],"nofollow","CNCFの最高成熟度「Graduated」に到達したことが発表されました","。2020年11月のCNCF参加時に574個だったGitHubスターは9,000個を超え、Bloomberg・Coinbase・LinkedIn・Spotifyといった企業が本番採用しています。最新リリースではCEL（Common Expression Language）を完全採用し、Kubernetes標準のアドミッション制御の方向性にも足並みを揃えました。",[16,38,39,40,45],{},"一方のOPA Gatekeeperも、",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Fopen-policy-agent.github.io\u002Fgatekeeper\u002Fwebsite\u002Fdocs\u002F",[34],"ConstraintTemplateとConstraintという2段構成のCRDモデル","を軸に、パラメータ化可能なポリシーライブラリと外部データ連携を強化し続けています。2026年4月時点の実測比較では、主要なアドミッション制御機能において両者はほぼ収斂しつつあります。つまり「どちらが高機能か」という問いにはもう意味がなく、選定は**「自分たちのクラスタでどちらが安全に運用できるか」**という、より実務的な問いに変わっています。",[16,47,48,49,54],{},"本記事では、K3sのような軽量・リソース制約クラスタを前提に、Kyverno と OPA Gatekeeper の実運用上の差を具体的なデータで検証します。こうしたポリシー運用の設計判断は地味に見えて事故に直結するため、",[30,50,53],{"href":51,"rel":52},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようなマネージドK3s環境でどこまで標準化・可視化できるかも併せて考えていきます。",[11,56,58],{"id":57},"yamlかregoか-チーム全員が書けるかという分かれ道","YAMLかRegoか — チーム全員が書けるかという分かれ道",[16,60,61],{},[19,62],{"alt":63,"src":64},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Fsection02.webp",[16,66,67],{},"KyvernoとOPA Gatekeeperの最も本質的な違いは、ポリシー言語そのものです。",[16,69,70,71,75,76,80],{},"Kyvernoはポリシーを",[72,73,74],"strong",{},"Kubernetesリソースと同じYAML","で記述します。",[77,78,79],"code",{},"kubectl","、Git、Kustomizeといった既存ツールチェーンにそのまま乗せられるため、Kubernetesの知識があればほぼ学習コストなしでポリシーを書き始められます。",[16,82,83,84,87,88,93],{},"対してOPA Gatekeeperは、Open Policy Agent由来の",[72,85,86],{},"Rego","という専用のクエリ言語を使います。Regoは表現力が高く複雑な条件分岐も書けますが、",[30,89,92],{"href":90,"rel":91},"https:\u002F\u002Fnirmata.com\u002F2026\u002F01\u002F28\u002Fwhats-the-difference-between-kyverno-and-opa-gatekeeper\u002F",[34],"Kubernetesエンジニアにとっては新しいプログラミング言語を1つ学ぶのに等しいコスト","がかかります。",[16,95,96,97,100,101,106],{},"この差が実際の組織でどう効いてくるかを示す事例があります。欧州の大手マーケットプレイス企業Adevintaのランタイムチームは、もともとGatekeeperを使っていましたが、",[72,98,99],{},"メタデータ追加やnodeSelector\u002Faffinityの変更といった「リソースを書き換える」要件が増えたタイミングで壁にぶつかりました","。",[30,102,105],{"href":103,"rel":104},"https:\u002F\u002Fadevinta.com\u002Ftechblog\u002Fwhy-did-we-transition-from-gatekeeper-to-kyverno-for-kubernetes-policy-management\u002F",[34],"Gatekeeperの変更機能（Assign）は基本的な要件すら満たせなかった","のです。",[16,108,109],{},"最終的にAdevintaがKyvernoへの移行を決めた理由は3つでした。",[111,112,113,120,126],"ul",{},[114,115,116,119],"li",{},[72,117,118],{},"習熟しやすさ",": YAMLベースでRegoより学習コストが低く、チーム全体がポリシー作成に参加できる",[114,121,122,125],{},[72,123,124],{},"機能の完全性",": ValidatingWebhookとMutatingWebhookの両方をネイティブにサポートしている",[114,127,128,131],{},[72,129,130],{},"リソース効率",": ポリシーが複雑化してもメモリ効率で優位だった",[16,133,134],{},"実際、Kyvernoはvalidate（検証）だけでなくmutate（既存リソースの書き換え）とgenerate（関連リソースの自動生成）までをアドミッションコントローラ・バックグラウンドコントローラ・レポートコントローラという3つのコントローラで一体的に扱えるよう設計されています。Gatekeeperがvalidationを主軸に据えているのとは対照的です。",[11,136,138],{"id":137},"k3sの本番で起きる最大の落とし穴-ワイルドカードポリシーという爆弾","K3sの本番で起きる最大の落とし穴 — ワイルドカードポリシーという爆弾",[16,140,141],{},[19,142],{"alt":143,"src":144},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Fsection03.webp",[16,146,147,148,151],{},"機能面の違い以上に、K3sのような軽量・リソース制約クラスタで致命的になるのが",[72,149,150],{},"ポリシーの書き方そのもの","です。",[16,153,154,159,160,163,164,167],{},[30,155,158],{"href":156,"rel":157},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Finstallation\u002Fscaling\u002F",[34],"Kyverno公式のスケーリングガイド","は次のように警告しています。ポリシーの対象リソースをワイルドカード（",[77,161,162],{},"*","）でマッチさせると、Kyvernoはクラスタ内の",[72,165,166],{},"あらゆるオペレーション（CREATE \u002F UPDATE \u002F DELETE \u002F CONNECT）をすべてのリソースに対して処理","することになります。これはクラスタの規模とは無関係に発生し、たった1つの単純なポリシーでも計算負荷を急増させる原因になります。",[16,169,170,171,176],{},"同様の注意は",[30,172,175],{"href":173,"rel":174},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fcluster-administration\u002Fadmission-webhooks-good-practices\u002F",[34],"Kubernetes公式のAdmission Webhookベストプラクティス","にも明記されており、「設計の悪いWebhookは、オブジェクトに対して持つ制御の強さゆえにワークロード障害を引き起こしやすい」と警鐘を鳴らしています。公式ドキュメントが推奨するのは、対象リソースを必要最小限に絞り込み、マッチ条件で不要な呼び出しを削減することです。",[16,178,179,180,183],{},"通常のマネージドKubernetesであれば、多少のオーバーヘッドはノードのスケールアウトで吸収できます。しかしK3sは",[72,181,182],{},"最初からリソース制約を前提に設計された軽量ディストリビューション","です。CPU・メモリに余裕のない環境でワイルドカードポリシーを1つ入れてしまうと、API Server全体のレイテンシに直結するリスクがあることは、K3s運用者ほど強く意識すべきポイントです。",[11,185,187],{"id":186},"レプリカ1台とp99レイテンシ-実測データで見る限界点","レプリカ1台とp99レイテンシ — 実測データで見る限界点",[16,189,190],{},[19,191],{"alt":192,"src":193},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Fsection04.webp",[16,195,196,197,202],{},"Kyverno自身もこの負荷問題を認識しており、継続的にパフォーマンス改善に取り組んできました。",[30,198,201],{"href":199,"rel":200},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2024\u002F02\u002F09\u002Fthe-need-for-speed-optimizing-kyvernos-performance\u002F",[34],"CNCFブログで公開されたパフォーマンス最適化レポート","によると、v1.10からv1.12にかけて次のような改善が実測されています。",[111,204,205,208],{},[114,206,207],{},"25仮想ユーザー・250イテレーション条件: 平均レイテンシ127.95ms → 15.52ms",[114,209,210],{},"100仮想ユーザー・1000イテレーション条件: 平均レイテンシ430.43ms → 64.34ms",[16,212,213],{},"約8倍の改善です。技術的には、JSONベースのコンテキストストレージをGolangのin-memoryマップに置き換え、ポリシーマッチングを早期リジェクト方式に再構成したことが効いています。あわせて、EventBroadcasterが過剰にgoroutineを生成することで発生していたメモリスパイクとOOMKillも、カスタムWatcher実装によって解消されました。",[16,215,216,217,220,221,224],{},"それでもなお、",[72,218,219],{},"レプリカ構成がボトルネックになる","ことは変わりません。",[30,222,158],{"href":156,"rel":223},[34],"が示す負荷テストでは、シングルレプリカで500同時オペレーションという高負荷下では、p99レイテンシが1秒を超えます。一方、3レプリカ構成にすると同じ条件下でもp99は650ms未満に収まります。",[16,226,227,228,231,232,236],{},"K3sの導入現場では「軽量だから」という理由でコントロールプレーン・アドオンの両方をシングルレプリカで運用するケースが少なくありません。しかしポリシーエンジンに関しては、ポリシー数が増えるほどこの前提が崩れやすく、",[72,229,230],{},"水平スケーリング（レプリカ追加)を前提にリソース設計すること","が、K3s環境でこそ重要になります。こうしたレプリカ構成やリソース配分の設計は、",[30,233,235],{"href":51,"rel":234},[34],"Kubo Cloud","のように監視・スケーリングが標準で組み込まれた基盤であれば、Captain UI上でp99レイテンシの悪化に気づきやすくなります。",[11,238,240],{"id":239},"結局どちらを選ぶべきか-k3s本番運用の判断基準","結局どちらを選ぶべきか — K3s本番運用の判断基準",[16,242,243],{},[19,244],{"alt":245,"src":246},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Fsection05.webp",[16,248,249],{},"ここまでの技術的な違いを踏まえると、K3sの本番運用における判断基準は次のように整理できます。",[16,251,252],{},[72,253,254],{},"Kyvernoを選ぶべきケース",[111,256,257,260,263,266],{},[114,258,259],{},"Kubernetesネイティブなワークフロー（kubectl \u002F Git \u002F Kustomize）でポリシーも一元管理したい",[114,261,262],{},"メタデータ付与・nodeSelector変更など、リソースのmutation\u002Fgenerationが必要",[114,264,265],{},"チーム全体（Rego未経験者を含む）でポリシーをメンテナンスしたい",[114,267,268],{},"GitOpsを中心にポリシーもコードとして運用したい",[16,270,271],{},[72,272,273],{},"OPA Gatekeeperを選ぶべきケース",[111,275,276,279,282],{},[114,277,278],{},"既にRego・OPAに投資済みで、Kubernetes以外（Terraform、HTTP API等）も含めた横断ガバナンスをしたい",[114,280,281],{},"非常に複雑なロジックを1つのポリシーに凝縮する必要がある",[114,283,284],{},"ConstraintTemplateによる再利用可能なポリシーライブラリの仕組みを重視したい",[16,286,287,288,293],{},"2026年4月時点の実機比較でも、",[30,289,292],{"href":290,"rel":291},"https:\u002F\u002Fcomputingforgeeks.com\u002Fopa-gatekeeper-vs-kyverno-policy\u002F",[34],"Kyvernoのmutation機能はGA済みで同一のClusterPolicyリソース内で完結する一方、Gatekeeperのmutationは依然alpha扱いで別のCRDが必要","とされており、mutation\u002Fgeneration要件の有無が今なお両者を分ける実質的な分岐点であることが裏付けられています。",[16,295,296],{},"どちらを選ぶにせよ、K3sのような軽量クラスタでは**「ポリシー言語の選択」よりも「ポリシーのスコープ設計」が本番運用の成否を分ける**という点は共通して意識すべきです。ワイルドカードマッチを避け、対象リソース・オペレーションを絞り込み、レプリカ数を負荷テストに基づいて設計する。この地道な設計判断の積み重ねが、本番障害を防ぐ最後の砦になります。",[11,298,299],{"id":299},"まとめ",[16,301,302,303,306,307,310],{},"KyvernoとOPA Gatekeeperは2026年時点で機能的にはかなり近づきました。しかし実際にK3sの本番クラスタで差が出るのは、YAMLかRegoかという言語選択以上に、",[72,304,305],{},"ワイルドカードポリシーの設計ミス","と",[72,308,309],{},"レプリカ構成の設計不足","です。どちらのツールを選んでも、軽量クラスタ前提の負荷設計を怠れば同じ壁にぶつかります。",[16,312,313,314,317],{},"こうしたポリシー運用の複雑さを、自前で一から設計・監視していくのは決して簡単ではありません。改めて、",[30,315,53],{"href":51,"rel":316},[34],"はK3sベースのマネージドKubernetesとして、Captain UIによる可視化と標準化された運用基盤を提供し、ポリシー運用のような「地味だが事故に直結する」設計判断をチームが見落としにくい形で支援します。",[16,319,320,321,326],{},"特に金融・医療のように厳格なガバナンス要件がある組織では、ポリシー強制の仕組みそのものを自社で完全にコントロールしたいというニーズもあるはずです。そうした場合は、",[30,322,325],{"href":323,"rel":324},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise","であれば、Air-Gapped環境でも完全自社管理のK3sクラスタ上でポリシー運用を標準化できます。",[16,328,329,330,333,334,339],{},"EKS\u002FAKSのような高コスト・複雑な管理から離れ、K3sの軽量性を活かしながらポリシー運用まで含めて本番品質を担保したいなら、",[30,331,235],{"href":51,"rel":332},[34],"の構築済み標準構成から始めるのも一つの選択肢です。まずは",[30,335,338],{"href":336,"rel":337},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から、自社クラスタのポリシー運用の現状を相談してみてください。",{"title":341,"searchDepth":342,"depth":342,"links":343},"",2,[344,345,346,347,348,349],{"id":13,"depth":342,"text":14},{"id":57,"depth":342,"text":58},{"id":137,"depth":342,"text":138},{"id":186,"depth":342,"text":187},{"id":239,"depth":342,"text":240},{"id":299,"depth":342,"text":299},"2026-10-11","KyvernoとOPA GatekeeperはK3sの本番運用でどちらを選ぶべきか。ワイルドカードポリシーが招く負荷急増とレプリカ構成別のp99レイテンシ実測データから、K3s特有の判断基準を整理する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead",{"title":5,"description":351},"blog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead",[361,362,363,364,365,366],"k3s","kubernetes","kyverno","opa-gatekeeper","admission-control","policy-as-code","6RVC4vf0XDwVsf0aKQPJI8QCvPVVNNaJqrOW3H-V6RE",[369,377,385,394,404,416],{"path":370,"title":371,"description":372,"date":373,"tags":374},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[361,362,375,363,376,365],"validatingadmissionpolicy","cel",{"path":378,"title":379,"description":380,"date":381,"tags":382},"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","2026-07-17",[362,361,383,365,363,384],"shadow-ai","security",{"path":386,"title":387,"description":388,"date":389,"tags":390},"\u002Fblog\u002Fja\u002Fcicd-pipeline-devsecops-gate-design-four-layers","そのCI\u002FCDパイプライン、セキュリティチェックをどこに置くか決めずに継ぎ足していないか。DevSecOpsゲート設計の4層モデル","SASTもDASTもコンテナスキャンも導入した。それでも本番で事故は起きる。CI\u002FCDパイプラインのセキュリティを『4つの層』で設計し直すDevSecOpsゲート設計の考え方を、K3s\u002FKubernetes運用の観点から解説する。","2026-08-28",[361,362,391,392,365,393],"ci-cd","devsecops","gitops",{"path":395,"title":396,"description":397,"date":398,"tags":399},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[361,362,400,401,402,403],"hpa","containerresource","autoscaling","service-mesh",{"path":405,"title":406,"description":407,"date":408,"tags":409},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[361,362,410,411,412,413,414,415],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":417,"title":418,"description":419,"date":420,"tags":421},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[361,362,422,423,424,425],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",1792592621124]