Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

23 App-AutoScaler

The App-AutoScaler service is used for automatically managing an application's instance count when deployed on SUSE Cloud Foundry. The scaling behavior is determined by a set of criteria defined in a policy (See Section 23.5, “Policies”).

23.1 Prerequisites

Using the App-AutoScaler service requires:

  • A running deployment of scf

  • cf, the Cloud Foundry command line interface. For more information, see https://docs.cloudfoundry.org/cf-cli/.

    For SUSE Linux Enterprise and openSUSE systems, install using zypper.

    tux > sudo zypper install cf-cli

    For SLE, ensure the SUSE Cloud Application Platform Tools Module has been added. Add the module using YaST or SUSEConnect.

    tux > SUSEConnect --product sle-module-cap-tools/15.1/x86_64

    For other systems, follow the instructions at https://docs.cloudfoundry.org/cf-cli/install-go-cli.html.

  • The Cloud Foundry CLI AutoScaler Plug-in, see https://github.com/cloudfoundry/app-autoscaler-cli-plugin

    The plugin can be installed by running the following command:

    tux > cf install-plugin -r CF-Community app-autoscaler-plugin

    If the plugin repo is not found, add it first:

    tux > cf add-plugin-repo "CF-Community" "https://plugins.cloudfoundry.org"

23.2 Enabling and Disabling the App-AutoScaler Service

By default, the App-AutoScaler service is not enabled as part of a SUSE Cloud Foundry deployment. To enable it, run helm upgrade with the --set "enable.autoscaler=true" flag on an existing scf deployment. Be sure to pass your uaa secret and certificate to scf first:

tux > SECRET=$(kubectl get pods --namespace uaa \
--output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')

tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
--output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"

tux > helm upgrade susecf-scf suse/cf \
--values scf-config-values.yaml \
--set "secrets.UAA_CA_CERT=${CA_CERT}" \
--set "enable.autoscaler=true" \
--version 2.20.3

To disable the App-AutoScaler service, run helm upgrade with the --set "enable.autoscaler=false" flag. Be sure to pass your uaa secret and certificate to scf first:

tux > SECRET=$(kubectl get pods --namespace uaa \
--output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')

tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
--output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"

tux > helm upgrade susecf-scf suse/cf \
--values scf-config-values.yaml \
--set "secrets.UAA_CA_CERT=${CA_CERT}" \
--set "enable.autoscaler=false" \
--version 2.20.3

23.3 Upgrade Considerations

In order to upgrade from a SUSE Cloud Application Platform 1.3.1 deployment with the App-AutoScaler enabled to SUSE Cloud Application Platform 1.4, perform one of the two methods listed below. Both methods require that uaa is first upgraded.

  1. Enabling App-AutoScaler no longer requires sizing values set to have a count of 1, which is the new minimum setting. The following values in your scf-config-values.yaml file can be removed:

    sizing:
      autoscaler_api:
        count: 1
      autoscaler_eventgenerator:
        count: 1
      autoscaler_metrics:
        count: 1
      autoscaler_operator:
        count: 1
      autoscaler_postgres:
        count: 1
      autoscaler_scalingengine:
        count: 1
      autoscaler_scheduler:
        count: 1
      autoscaler_servicebroker:
        count: 1
  2. Get the most recent Helm charts:

    tux > helm repo update
  3. Upgrade uaa:

    tux > helm upgrade susecf-uaa suse/uaa \
    --values scf-config-values.yaml \
    --version 2.20.3
  4. Extract the uaa secret for scf to use:

    tux > SECRET=$(kubectl get pods --namespace uaa \
    --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
    
    tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
    --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"

You are now ready to upgrade scf using one of the two following methods:

The first method is to disable the App-AutoScaler during the initial SUSE Cloud Application Platform upgrade, then when the upgrade completes, enable the App-AutoScaler again.

  1. Upgrade scf with the App-AutoScaler disabled:

    tux > helm upgrade susecf-scf suse/cf \
    --values scf-config-values.yaml \
    --set "secrets.UAA_CA_CERT=${CA_CERT}" \
    --set "enable.autoscaler=false"
  2. Monitor the deployment progress. Wait until all pods are in a ready state before proceeding:

    tux > watch --color 'kubectl get pods --namespace scf'
  3. Enable the App-AutoScaler again:

    tux > helm upgrade susecf-scf suse/cf \
    --values scf-config-values.yaml \
    --set "secrets.UAA_CA_CERT=${CA_CERT}" \
    --set "enable.autoscaler=true"
  4. Monitor the deployment progress and until all pods are in a ready state:

    tux > watch --color 'kubectl get pods --namespace scf'

The second method is to pass the --set sizing.autoscaler_postgres.disk_sizes.postgres_data=100 option as part of the upgrade.

tux > helm upgrade susecf-scf suse/cf \
--values scf-config-values.yaml \
--set "secrets.UAA_CA_CERT=${CA_CERT}" \
--set "enable.autoscaler=true" \
--set sizing.autoscaler_postgres.disk_sizes.postgres_data=100

23.4 Using the App-AutoScaler Service

Push the application without starting it first:

tux > cf push my_application --no-start

Attach autoscaling policy to the application:

tux > cf attach-autoscaling-policy my_application my-policy.json

Policy has to be defined as a JSON file (See Section 23.5, “Policies”) in a proper format (See https://github.com/cloudfoundry/app-autoscaler/blob/develop/docs/policy.md).

Start the application:

tux > cf start my_application

Autoscaling policies can be managed using cf CLI with the App-AutoScaler plugin as above (See Section 23.4.1, “The App-AutoScaler cf CLI Plugin”) or using the App-AutoScaler API (See Section 23.4.2, “App-AutoScaler API”).

23.4.1 The App-AutoScaler cf CLI Plugin

The App-AutoScaler plugin is used for managing the service with your applications and provides the following commands (with shortcuts in brackets). Refer to https://github.com/cloudfoundry/app-autoscaler-cli-plugin#command-list for details about each command:

autoscaling-api (asa)

Set or view AutoScaler service API endpoint. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-autoscaling-api for more information.

autoscaling-policy (asp)

Retrieve the scaling policy of an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-autoscaling-policy for more information.

attach-autoscaling-policy (aasp)

Attach a scaling policy to an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-attach-autoscaling-policy for more information.

detach-autoscaling-policy (dasp)

Detach the scaling policy from an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-detach-autoscaling-policy for more information.

create-autoscaling-credential (casc)

Create custom metric credential for an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-create-autoscaling-credential for more information.

delete-autoscaling-credential (dasc)

Delete the custom metric credential of an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-delete-autoscaling-credential for more information.

autoscaling-metrics (asm)

Retrieve the metrics of an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-autoscaling-metrics for more information.

autoscaling-history (ash)

Retrieve the scaling history of an application. See https://github.com/cloudfoundry/app-autoscaler-cli-plugin#cf-autoscaling-history for more information.

23.5 Policies

A policy identifies characteristics including minimum instance count, maximum instance count, and the rules used to determine when the number of application instances is scaled up or down. These rules are categorized into two types, scheduled scaling and dynamic scaling. (See Section 23.5.1, “Scaling Types”). Multiple scaling rules can be specified in a policy, but App-AutoScaler does not detect or handle conflicts that may occur. Ensure there are no conflicting rules to avoid unintended scaling behavior.

Policies are defined using the JSON format and can be attached to an application either by passing the path to the policy file or directly as a parameter.

The following is an example of a policy file, called my-policy.json.

{
    "instance_min_count": 1,
    "instance_max_count": 4,
    "scaling_rules": [{
        "metric_type": "memoryused",
        "stat_window_secs": 60,
        "breach_duration_secs": 60,
        "threshold": 10,
        "operator": ">=",
        "cool_down_secs": 300,
        "adjustment": "+1"
    }]
}

For an example that demonstrates defining multiple scaling rules in a single policy, refer to the sample of a policy file at https://github.com/cloudfoundry/app-autoscaler/blob/develop/src/integration/fakePolicyWithSchedule.json. The complete list of configurable policy values can be found at https://github.com/cloudfoundry/app-autoscaler/blob/master/docs/policy.md.

23.5.1 Scaling Types

Scheduled Scaling

Modifies an application's instance count at a predetermined time. This option is suitable for workloads with predictable resource usage.

Dynamic Scaling

Modifies an application's instance count based on metrics criteria. This option is suitable for workloads with dynamic resource usage. The following metrics are available:

  • memoryused

  • memoryutil

  • cpu

  • responsetime

  • throughput

  • custom metric

See https://github.com/cloudfoundry/app-autoscaler/tree/develop/docs#scaling-type for additional details.

Print this page