Skip to content

Scaling DX 9.5 container deployments using Helm

This topic provides information to apply container scaling capabilities, and how scaling resources are handled within the HCL DX 9.5 deployment using Helm. In terms of scaling the pods, the recommended way is to update the replicas in the values.yaml and apply these changes issuing a helm upgrade. It is not supported to manually scale using kubectl scale commands.

Known limitations:

  • Core
    The HCL Digital Experience 9.5 Core can only be scaled to more than one Pod if you have performed a database transfer from the default packaged Derby database. Prior to that, any other additional Pod except for Pod-0 fails to start, since the default packaged Derby database does not allow for multiple Pods connecting to it.

  • Persistence
    During scale down of persistence nodes, DAM will be unavailable for few seconds (This happens as PgPool was not able to determine whether primary or secondary has been scaled down).

Use of HorizontalPodAutoscalers in DX 9.5 Deployments using Helm

The following DX 9.5 applications can be configured to leverage HorizontalPodAutoscalers for Kubernetes based automated scaling:

  • Core
  • Content Composer
  • Digital Asset Management
  • Image Processor
  • Ring API

HorizontalPodAutoscalers monitor Pod resources such as CPU and Memory usage, and automatically scales up/down applications based on specific thresholds defined and scaling limits.

For the above mentioned DX applications, the maximum and minimum count of Replicas can be configured via the values.yaml. The thresholds for CPU and Memory usage are also configurable allowing for load-based automated scaling of these applications.

Refer to HorizontalPodAutoscaler details in Kubernetes for more information on these services.

Per default, the automated scaling is not active and needs to be enabled before taking effect.