> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Installing Kyverno on Your Cluster
> Instructions for installing Kyverno on Kubernetes with Helm, explaining standalone versus high availability modes, installation commands, verification steps, and RBAC and resource setup.
Now that we understand Kyverno's architecture, let's install it.
The recommended method is to use Helm — the Kubernetes package manager. The Kyverno Helm chart packages all required Kubernetes resources, sensible production defaults, and simplifies upgrades and configuration. Using the chart avoids manually creating many YAML manifests for deployments, services, and RBAC.
Installation modes
* Standalone — single replica of each Kyverno controller. Best for learning, development, or small test clusters because it consumes fewer resources.
* High availability (HA) — multiple replicas of each controller. Required for production to ensure policy enforcement continues if a controller instance fails.
For production use, deploy Kyverno in high availability mode so multiple controller replicas can handle failures and maintain continuous policy enforcement.
Quick install (standalone)
We'll perform a simple standalone install using Helm. These three commands add the Kyverno chart repo, refresh your local index, and install Kyverno into the `kyverno` namespace:
```bash theme={null}
# 1. Add the Kyverno Helm repository (do this once)
helm repo add kyverno https://kyverno.github.io/kyverno/
# 2. Update your local Helm repositories
helm repo update
# 3. Install Kyverno into the 'kyverno' namespace (creates the namespace if needed)
helm install kyverno kyverno/kyverno -n kyverno --create-namespace
```
What the commands do
* `helm repo add kyverno https://kyverno.github.io/kyverno/` adds the official Kyverno Helm repository to your local Helm configuration.
* `helm repo update` refreshes Helm's local chart index so you get the latest chart versions.
* `helm install kyverno kyverno/kyverno -n kyverno --create-namespace` installs the chart with the release name `kyverno` into namespace `kyverno`, creating the namespace if required.
Installation modes comparison
| Mode | Use case | Characteristics |
| ---------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------- |
| Standalone | Learning, development, small test clusters | Single replica per controller, lower resource consumption |
| High availability (HA) | Production clusters | Multiple replicas per controller, resilient to failures, recommended for critical workloads |
Verify the installation
After Helm finishes, Kubernetes resources are created by the chart. Check that Kyverno's controllers are deployed and ready:
```bash theme={null}
kubectl get deployments -n kyverno
```
Example output:
```bash theme={null}
NAME READY UP-TO-DATE AVAILABLE AGE
kyverno-admission-controller 1/1 1 1 60s
kyverno-background-controller 1/1 1 1 60s
kyverno-cleanup-controller 1/1 1 1 60s
kyverno-reports-controller 1/1 1 1 60s
```
When the deployments report READY and AVAILABLE replicas, Kyverno controllers are running.
Service accounts and RBAC
The Helm chart creates a dedicated service account per controller so each controller can be granted least-privilege access. List the service accounts:
```bash theme={null}
kubectl get serviceaccounts -n kyverno
```
Example output:
```bash theme={null}
NAME SECRETS AGE
default 1 44s
kyverno-admission-controller 0 44s
kyverno-background-controller 0 44s
kyverno-cleanup-controller 0 44s
kyverno-reports-controller 0 44s
```
Kyverno requires cluster-level visibility and permissions to validate, mutate, and generate resources. The Helm chart creates ClusterRoles and ClusterRoleBindings for admission, background processing, cleanup, reporting, and other controller responsibilities. To inspect Kyverno-related cluster roles:
```bash theme={null}
kubectl get clusterroles | grep -i kyverno
```
Common resources created by the Helm chart
| Resource type | Purpose | Example / command | |
| ---------------------------------- | -------------------------------------------------------------------- | ------------------------------------------- | ----------------- |
| Deployments | Runs controller components (admission, background, cleanup, reports) | `kubectl get deployments -n kyverno` | |
| ServiceAccounts | Per-controller identity for RBAC | `kubectl get serviceaccounts -n kyverno` | |
| ClusterRoles / ClusterRoleBindings | Provide cluster-scoped permissions used by controllers | \`kubectl get clusterroles | grep -i kyverno\` |
| ConfigMaps / Secrets | Configuration and TLS secrets for admission webhook | `kubectl get configmaps,secrets -n kyverno` | |
At this point, Kyverno is installed, running, and has the permissions required to enforce and manage policies.
To switch to high availability later, update the Helm values to increase replica counts (or use the HA values provided by the chart) and perform a Helm upgrade.
Next steps
We'll cover how to author and apply Kyverno policies to enforce guardrails across your cluster, including examples for validation, mutation, and generation policies.
Links and references
* [Helm — Kubernetes package manager](https://helm.sh/)
* [Kyverno documentation](https://kyverno.io/docs/)
* [Kubernetes RBAC documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)