Configure Horizontal Pod Autoscaling (HPA)

This page details the configuration of the autoscaling system for pods. Autoscaling allows you to dynamically adjust the number of pods based on load (CPU and RAM).

Technical Prerequisites

For the HPA to work, the following conditions must be met:

  1. Metrics-server: Must be installed on the cluster (to expose cpu and memory metrics).

  2. Resource Requests: Your pods must have CPU/RAM requests and limits defined. The percentage calculation is based on these values. Default values are defined for Cyberwatch pods, but they can be adjusted in the values.yml file.

Implementation example

Copy this configuration into your values.yml file to enable autoscaling:

autoscaling:
  # Enables or disables resource autoscaling for the cluster
  enabled: true
  
  targets:
    - name: sidekiq-node
      minReplicas: 1      # Number of pods kept alive even with no activity
      maxReplicas: 5      # Maximum number of pods that autoscaling can create
      targetCPUUsage: 70  # Triggers a new pod if average CPU usage exceeds 70%
      targetRAMUsage: 80  # Triggers a new pod if average RAM usage exceeds 80%

    - name: container-scanner
      minReplicas: 1
      maxReplicas: 10
      targetCPUUsage: 70
      targetRAMUsage: 80

Working volume of the container-scanner pod

The container-scanner pod downloads the images to analyze into a working volume, whose size is defined by the containerScanner.cacheStorageSize field (40Gi by default).

With version 0.6.10 of the Helm chart, each container-scanner pod has its own volume, created and deleted with the pod, when the following two conditions are met:

  • container-scanner is one of the autoscaling targets, or containerScanner.replicaCount is greater than 1;
  • the global.storageClass field is defined.

The required storage space is multiplied by the number of pods. If the reclaimPolicy of the StorageClass is Retain, the volumes of deleted pods are kept and must be deleted manually.

Use a shared volume

It is also possible to share the same volume between all container-scanner pods, by specifying an existing PersistentVolumeClaim in the values.yml file:

containerScanner:
  existingClaim: pvc-name

For the pods to run on several nodes, this volume must be ReadWriteMany.

Image scans rely on Buildah in rootless mode, whose support for network file systems (NFS, CephFS, SMB) is limited. Most ReadWriteMany volumes rely on these file systems. Depending on the storage used, the pods can start while image scans fail. Check that an image scan succeeds before generalizing this configuration.