Kyverno vs OPA Gatekeeper: In 2026, It's No Longer About Features
When teams try to add compliance-ready policies to a K3s cluster, the first fork in the road is almost always "Kyverno or OPA Gatekeeper?" A few years ago, this comparison had a fairly clear answer. In 2026, that's no longer the case.
In March 2026, at KubeCon + CloudNativeCon North Europe, the CNCF announced that Kyverno had reached its highest maturity level, Graduated. Since joining the CNCF in November 2020 with 574 GitHub stars, the project has grown to over 9,000 stars, with production adopters including Bloomberg, Coinbase, LinkedIn, and Spotify. Its latest release fully adopts CEL (Common Expression Language), aligning with the direction Kubernetes itself is taking for admission control.
OPA Gatekeeper, meanwhile, continues to strengthen its two-tier CRD model built around ConstraintTemplate and Constraint, along with parameterized policy libraries and external data integration. As of real-world comparisons in April 2026, the two projects' core admission-control capabilities have largely converged. In other words, "which one has more features" is no longer a meaningful question. The real question has shifted to something more practical: "which one can we actually run safely on our own cluster?"
This article examines the real operational differences between Kyverno and OPA Gatekeeper with concrete data, assuming a lightweight, resource-constrained cluster like K3s. Policy design decisions like these look mundane but directly cause production incidents, so we'll also touch on how far a managed K3s environment like Kubo can take standardization and visibility.
YAML or Rego — The Fork That Decides Whether Your Whole Team Can Write Policy
The most fundamental difference between Kyverno and OPA Gatekeeper is the policy language itself.
Kyverno writes policies in plain Kubernetes YAML, the same format as the resources it validates. Because it slots directly into existing tooling like kubectl, Git, and Kustomize, anyone who already knows Kubernetes can start writing policies with almost no extra learning curve.
OPA Gatekeeper, on the other hand, uses Rego, a dedicated query language from the Open Policy Agent project. Rego is expressive and can encode complex conditional logic, but for Kubernetes engineers it effectively means learning an entirely new programming language.
One real-world case shows exactly how this difference plays out inside an organization. Adevinta, the European marketplace company, originally ran Gatekeeper on its runtime platform, but hit a wall as requirements grew for rewriting existing resources — adding metadata, changing nodeSelectors and affinity rules. Gatekeeper's mutation capability (Assign) couldn't even meet these basic requirements.
Adevinta ultimately moved to Kyverno for three reasons:
- Easier to learn: YAML-based policies have a lower learning curve than Rego, letting the whole team participate in writing them
- Feature completeness: Native support for both ValidatingWebhook and MutatingWebhook
- Resource efficiency: Better memory efficiency even as policies grew more complex
In fact, Kyverno is designed to handle not just validation but also mutation (rewriting existing resources) and generation (automatically creating related resources) as a unified whole, split across an admission controller, a background controller, and a reports controller. Gatekeeper, by contrast, is built primarily around validation.
The Biggest Trap in K3s Production — The Wildcard Policy Time Bomb
Beyond the feature-level differences, what becomes truly dangerous on a lightweight, resource-constrained cluster like K3s is how the policy itself is written.
Kyverno's official scaling guide warns that matching a policy's target resources with a wildcard (*) forces Kyverno to process every operation — CREATE, UPDATE, DELETE, and CONNECT — against every resource in the cluster. This happens regardless of cluster size, and even a single, simple policy written this way can cause a sharp spike in computational load.
The official Kubernetes guidance on admission webhook best practices raises the same warning, noting that "badly-designed webhooks often result in workload disruptions because of how much control the webhooks have over objects in the cluster." The recommended fix is to scope target resources as narrowly as possible and use match conditions to eliminate unnecessary webhook calls.
On a typical managed Kubernetes service, some of this overhead can be absorbed simply by scaling out nodes. But K3s is a lightweight distribution designed from the ground up around resource constraints. In an environment with little CPU or memory headroom, a single wildcard policy can translate directly into API server latency — a risk that K3s operators, more than anyone, need to keep front of mind.
One Replica and p99 Latency — What the Measured Data Actually Shows
Kyverno's own maintainers are well aware of this load problem and have invested continuously in performance work. According to a performance optimization report published on the CNCF blog, the following improvements were measured between v1.10 and v1.12:
- 25 virtual users, 250 iterations: average latency dropped from 127.95ms to 15.52ms
- 100 virtual users, 1,000 iterations: average latency dropped from 430.43ms to 64.34ms
That's roughly an 8x improvement. Technically, the gains came from replacing JSON-based context storage with in-memory Golang maps, restructuring policy matching to reject incompatible requests earlier, and fixing memory spikes and OOMKills caused by the EventBroadcaster spawning excessive goroutines, via a custom Watcher implementation.
Even so, replica configuration remains a bottleneck. Load tests in Kyverno's official scaling guide show that under extreme load — 500 concurrent operations — a single-replica deployment sees p99 latency exceed one second, while a three-replica configuration keeps p99 under 650ms for the same workload.
In many K3s deployments, both the control plane and add-ons end up running as a single replica, simply because K3s is "lightweight." But for a policy engine, that assumption breaks down quickly as policy count grows. Designing for horizontal scaling (adding replicas) from the start matters even more in K3s environments than elsewhere. This kind of replica and resource-allocation design is easier to stay on top of with a platform like Kubo Cloud, where built-in monitoring and scaling make p99 latency degradation visible directly in the Captain UI.
So Which Should You Actually Choose? A Decision Framework for K3s Production
Given everything above, here's how the decision breaks down for K3s production environments.
Choose Kyverno if:
- You want policies managed inside a Kubernetes-native workflow (kubectl / Git / Kustomize)
- You need to mutate or generate resources — adding metadata, changing nodeSelectors, etc.
- You want the whole team, including people with no Rego experience, to maintain policies
- You run GitOps and want policy to live as code alongside everything else
Choose OPA Gatekeeper if:
- You've already invested in Rego/OPA and want governance that spans beyond Kubernetes — Terraform, HTTP APIs, and so on
- You need to express very complex logic within a single policy
- You value the reusable policy library pattern that ConstraintTemplate provides
A real-world comparison from April 2026 confirms this is still the practical dividing line: Kyverno's mutation feature is GA and lives inside the same ClusterPolicy resource, while Gatekeeper's mutation support remains alpha and requires a separate CRD. Whether you need mutation/generation is still the question that matters most.
Whichever you choose, on a lightweight cluster like K3s, policy scope design matters more than the choice of policy language. Avoid wildcard matches, scope target resources and operations as narrowly as possible, and size your replica count based on actual load testing. These unglamorous design decisions, repeated consistently, are what actually keep production incidents at bay.
Summary
By 2026, Kyverno and OPA Gatekeeper have become nearly comparable in raw functionality. But the real gap that shows up in K3s production clusters isn't YAML versus Rego — it's wildcard policy design mistakes and under-provisioned replica configurations. Whichever tool you pick, skipping load-aware design for a lightweight cluster leads to the same wall.
Designing and monitoring policy operations like this entirely from scratch is far from trivial. Kubo, a managed Kubernetes service built on K3s, provides visibility through its Captain UI and a standardized operational foundation, helping teams avoid overlooking the kind of unglamorous design decisions that directly cause incidents.
For organizations with strict governance requirements — finance, healthcare — there's often a need to keep full control over the policy enforcement mechanism itself. Kubo On-Premise lets you standardize policy operations on a fully self-managed K3s cluster, even in an air-gapped environment.
If you want to move away from the high cost and complexity of EKS/AKS while still guaranteeing production-grade quality — including policy operations — on top of K3s's lightweight footprint, starting from Kubo Cloud's pre-built standard configuration is one option worth considering. Get in touch to talk through where your cluster's policy operations stand today.