[Kyverno]πŸ› οΈ Why should we install it with Helm?

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.

  1. CRD Check: Verify that the policy resources used by Kyverno are well created. (kubectl get crd | grep kyverno)
  2. Webhook Check: Verify that the Kyverno webhook is properly registered with the API server. (kubectl get mutatingwebhookconfigurations)
  3. 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! πŸ™‹β€β™‚οΈ



Comments

Leave a Reply

Your email address will not be published. Required fields are marked *