Hello! This is the second part of the Kyverno series, the core of Kubernetes security. π‘οΈ
Last time, we looked at the overall architecture of Kyverno. Today, we’ll dive into practice and discuss “How to perfectly install and optimize Kyverno in a cluster?” In particular, we will thoroughly explore the installation using Helm, which is most commonly used in the field, and the key configuration values in the values.yaml file. π

Managing Kubernetes resources with individual YAMLs is a very painful task. This is even more true for solutions like Kyverno, which have many CRDs (Custom Resource Definitions) and complex Webhook configurations.
- Version Management: Easily deploy and roll back specific versions of Kyverno.
- Configuration Automation: Centralize management of High Availability (HA) settings or resource limits using a single values.yaml file.
- Maintenance: Apply the latest security patches with a single helm upgrade command.
ποΈ Step 1: Register Kyverno Official Helm Repository
The first thing to do is to add the official Kyverno chart repository.
Bash
# Add repository
helm repo add kyverno https://kyverno.github.io/kyverno/
# Update latest chart information
helm repo update
# Check chart version before installation
helm search repo kyverno
βοΈ Step 2: Delving into the Core of values.yaml Key Settings
Rather than simply typing helm install, it’s crucial to customize the settings to fit our service environment. We’ve compiled the key parameters of values.yaml that are most heavily covered in KCA exams and practical work.
β High Availability and Replicas (Replica & HA) π
In a production environment, having only one Kyverno Pod is risky. If the API server cannot receive a response from Kyverno, resource creation may be blocked.
- replicaCount: A minimum of 3 is recommended.
- topologySpreadConstraints: Distributes Pods evenly across multiple nodes or zones to increase availability.
YAML
replicaCount: 3
podDisruptionBudget:
minAvailable: 1
β‘ Resource Management (Resources & Webhook) π
Kyverno inspects all requests in the cluster, so resource allocation and timeout settings are very important.
- resources: Set requests and limits to prevent OOM (Out Of Memory).
- webhook.timeoutSeconds: Sets the Webhook response waiting time. (Default 10 seconds; too long degrades API response speed.)
YAML
resources:
limits:
memory: 512Mi
requests:
cpu: 100m
memory: 256Mi
β’ Service and Communication Security (Service & RBAC) π
Determines how Kyverno communicates with the API server and what permissions it will have.
- admissionController.container.image.tag: Explicitly specify the Kyverno version to use.
- rbac.create: Determines whether Kyverno should automatically create necessary permissions. (Default true)
- certManager.enabled: Whether to use an external cert-manager to manage certificates.
β£ Policy Reporting and Background Scans (Background & Reports) π
- backgroundController.enabled: Determines whether to perform periodic policy compliance scans on existing resources.
- cleanupController.enabled: Activates the function to delete expired resources.
π Kyverno Optimized my-values.yaml Example
# ---------------------------------------------------------
# 1. Replica and High Availability (HA) settings
# ---------------------------------------------------------
replicaCount: 3
# Pod distribution policy: Distribute evenly across multiple nodes to ensure availability
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/instance: kyverno
# During upgrade, at least 1 Pod must always remain available
podDisruptionBudget:
minAvailable: 1
# ---------------------------------------------------------
# 2. Resource allocation and timeout (performance optimization)
# ---------------------------------------------------------
admissionController:
container:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
# Webhook timeout: Too short causes request failure, too long slows down API response
webhook:
timeoutSeconds: 15
# ---------------------------------------------------------
# 3. Certificate management (when integrating with cert-manager)
# ---------------------------------------------------------
# Set to true to use external cert-manager instead of internal self-signed certificates
certManager:
enabled: false
# ---------------------------------------------------------
# 4. Monitoring and metrics activation
# ---------------------------------------------------------
# Enable metrics service for Prometheus and Grafana integration
metricsService:
enabled: true
serviceMonitor:
enabled: false # Change to true if Prometheus Operator is installed
# ---------------------------------------------------------
# 5. Background scan and resource cleanup (Controller settings)
# ---------------------------------------------------------
backgroundController:
enabled: true
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
cleanupController:
enabled: true # Enable automatic deletion of expired resources
resources:
requests:
cpu: 50m
memory: 64Mi
# ---------------------------------------------------------
# 6. Security and Filtering (RBAC & Filters)
# ---------------------------------------------------------
# Exclude specific namespaces or resources from inspection (prevent failures)
config:
resourceFilters:
- "[Event,*,*]"
- "[*,kube-system,*]"
- "[*,kube-public,*]"
- "[*,kube-node-lease,*]"
- "[Node,*,*]"
- "[APIService,*,*]"
- "[TokenReview,*,*]"
- "[SubjectAccessReview,*,*]"
- "[SelfSubjectAccessReview,*,*]"
π Step 3: Execute Actual Installation Command
Once you have prepared the optimized my-values.yaml file, proceed with the installation using the command below.
# Create namespace
kubectl create namespace kyverno
# Install with optimized settings
helm install kyverno kyverno/kyverno -n kyverno -f my-values.yaml
After installation, be sure to check that all components are in a Running state with the following command! kubectl get pods -n kyverno
π Step 4: Verify Custom Settings After Installation
Installation is not the end. We need to verify that our settings have been correctly applied.
- CRD Check: Verify that the policy resources used by Kyverno are well created. (kubectl get crd | grep kyverno)
- Webhook Check: Verify that the Kyverno webhook is properly registered with the API server. (kubectl get mutatingwebhookconfigurations)
- ConfigMap Check: Verify the ConfigMap reflecting filtering settings, etc.
π‘ Practical Tips for Operators
- Utilize Dry-run: Use helm install –dry-run –debug to review the YAML that will be generated before actual installation.
- Resource Filters: It is safer to exclude core system resources such as the kube-system namespace from policy checks to prevent fault propagation.
- Prometheus Integration: Monitor Kyverno’s status in real-time on Grafana by setting metricsService.enabled: true.
π Conclusion
Today, we learned how to smartly install Kyverno using Helm and how to optimize the key settings in values.yaml. “Anyone can do basic setup, but precise tuning is the first step to creating a stable cluster.” We hope you utilize the settings learned today to build a robust security environment.
Next time, we will finally delve into
Chapter 3. Writing Policies (Policy Writing Methods)
, which many of you have been waiting for, to cover how to code actual rules. Stay tuned! πββοΈ
Leave a Reply