Autoscaling of Planned Events

The Event Agent helps in scaling for planned events. This topic describes how the autoscaling of planned events occur.

During the event, anticipating more load requires more pods. This scaling of pods can be pre-configured using the Event Agent and it can be reset to its pre-event configuration after the event ends.

Required Setup

This guide explains how to create an Autoscaler Event for the Online Boutique sample application to demonstrate scaling for multiple microservices. To begin, the first step involves creating an application configuration. This step is a one-time process that ensures the application is registered with the Event Agent.

Configure an Application

In the application configuration, you can provide the Argo CD reference or manually add all the application details. If you provide the Argo CD reference, then the application details are automatically retrieved from the GitHub repository. In the absence of Argo CD reference, you must manually enter the application details.

Configure the boutique application referring to the Argo CD application name and namespace.

apiVersion: agent.smart-scaler.io/v1alpha1
kind: ApplicationConfig
metadata:
  name: boutique-appconfig
spec:
  argocdApplicationRef: # user defined
    name: boutique
    namespace: argocd

Apply the configuration using the following command:

kubectl  apply -f applicationconfig.yaml -n smart-scaler

The next steps involves creating the scaling ratio configuration. This is also a one-time process to set the scaling configurations for an event for a specific application.

Configure the Scaling Ratio

This configuration precisely defines how scaling is distributed across different components of the application. In this following example, we will use configuration for the Boutique Application which consists of multiple microservices. The Frontend microservice serves as the entry point for this application. Hence, it is the source or the root node for the rest of the microservices which are the targets.

# ScalingRatioConfig
apiVersion: agent.smart-scaler.io/v1alpha1
kind: ScalingRatioConfig
metadata:
  name: boutique-sr
spec:
  scaling_ratios: # can either be queried from SmartScaler or user configurable.
    - source: frontend
      target: adservice
      weight: "0.116"
    - source: frontend
      target: cartservice
      weight: "0.512"
    - source: frontend
      target: checkoutservice
      weight: "0.916"
    - source: frontend
      target: currencyservice
      weight: "1.841"
    - source: frontend
      target: emailservice
      weight: "0.188"
    - source: frontend
      target: paymentservice
      weight: "0.095"
    - source: frontend
      target: productcatalogservice
      weight: "1.749"
    - source: frontend
      target: recommendationservice
      weight: "1.595"
    - source: frontend
      target: shippingservice
      weight: "0.275"

kubectl  apply -f scalingratio.yaml -n smart-scaler

Now consider a significant upcoming event, like the Black Friday sale and in preparation for this event, we need to create an event configuration. This involves referencing both the application configuration and the scaling ratio configuration.

Configure the Event

The scaling ratio that you had configured in the previous step is used in this event configuration. The pods are scaled as per the configuration during the event. Configure the event as illustrated in the following example.

apiVersion: example.com/v1alpha1
kind: EventConfig
metadata:
  name: black-friday-sale
spec:
  eventName: black-friday-sale
  eventStartTimestamp: "2023-08-11T08:00:00Z"
  eventEndTimestamp: "2023-08-11T10:00:00Z"
  applicationConfigName: boutique-appconfig   # references applicationConfig CR
  scalingRatioConfigName: boutique-sr   # references scalingRatioConfig CR
  scalingConfiguration:
    minScalingFactor: "10"
    maxScalingFactor: "100"
  cooldownConfiguration:
    cooldownDuration: 180h # eg. 120s, 1h, 1d

Apply the configuration using the following command:

kubectl  apply -f eventconfig.yaml -n smart-scaler

Operations After EventConfig is Created for an ApplicationConfig

1. An hour prior to the event start time (configurable in Autoscaler settings), a pull request (PR) is raised. This PR contains updated minimum/maximum replica counts based on the specified scaling factors and ratios.
2. Five minutes before the event start time (configurable in Autoscaler settings), the PR is automatically merged. This ensures that we are thoroughly prepared for the upcoming event.
3. Argo CD then synchronizes these changes with the Kubernetes cluster from the base GitHub branch.
4. Finally, the pods are appropriately scaled up in preparation for the event.

Configure Recurring Events

Configure the recurring events as illustrated in the following example.

apiVersion: agent.smart-scaler.io/v1alpha1
kind: EventConfigSet
metadata:
  name: weekend-sale
spec:
  template:
    metadata:
      name: weekend-sale # need a way to generate a event specific name
      # other metadata fields
    spec:
      displayName: ThursdaySale
      eventDuration: 24h
      cooldownDuration: 30s
      applicationConfigName: applicationconfig-sample    ## references applicationConfig CR
      scalingRatioConfigName: scalingratioconfig-sample       ## references scalingConfig CR
      scalingConfiguration:
        minScalingFactor: "10.2"  
        maxScalingFactor: "20.4"
      destinationContexts:
        - ca-central-1
        - us-south-east-2
        - us-west-2
  recurrenceConfig:
    schedule: "0 0 * * 0,6" # support only recurring type schedule
    startDate: "2023-12-12" # Date from which the schedule would start
    endDate: "2024-12-12" # Date at which the schedule would end
    concurrentFutureEvents: 2 # no. of concurrent future eventConfigs that would be generated
    cleanupCompletedEvents: false # Cleanup completed events

In the above example, recurring events for the weekend-sale event is scheduled for every weekend using cron expressions. The event will start on every weekend and end after 24 hours.

Apply the configuration using the following command:

kubectl  apply -f recurring-eventconfig.yaml -n smart-scaler

Cooldown to Reset Values

After the event is over, the cooldown setting provides a gradual downscaling of the pods. Based on the cooldown configuration, the maximum and minimum values fall back to the old values (stored in the status of the EventConfig object).

The minimum value of HPA/KEDA configuration is modified.

A new PR in the Git repository is created to apply the changes. If automatic merging is disabled, then the PR should be approved by the relevant stakeholders. After the PR is approved, it is merged to restore the original minimum and maximum values.