You can scale most services running in Kubernetes from the command line or in a configuration override. You can set scaling parameters for Apigee hybrid runtime services in theoverrides.yaml file.

mart:replicaCountMax:2replicaCountMin:1watcher:replicaCountMax:2replicaCountMin:1connectAgent:replicaCountMax:2replicaCountMin:1

synchronizer:replicaCountMax:10replicaCountMin:1runtime:replicaCountMax:10replicaCountMin:1udca:replicaCountMax:10replicaCountMin:1

Advanced configurations

In some scenarios, you may need to use advanced scaling options. Example scenarios include:

• Setting different scaling options for each environment. For example, where env1 has aminReplica of 5 and env2 has aminReplica of 2.
• Setting different scaling options for each component within an environment. For example, where theudca component has amaxReplica of 5 and thesynchronizer component has amaxReplica of 2.

The following example shows how to use thekubernetes patch command to change themaxReplicas property for theruntime component:

1. Create environment variables to use with the command:

   exportENV=my-environment-nameexportNAMESPACE=apigee#the namespace where apigee is deployedexportCOMPONENT=runtime#can be udca or synchronizerexportMAX_REPLICAS=2exportMIN_REPLICAS=1

2. Apply the patch. Note that this example assumes thatkubectl is in yourPATH:

   kubectlpatchapigeeenvironment-n$NAMESPACE\$(kubectlgetapigeeenvironments-n$NAMESPACE-ojsonpath='{.items[?(@.spec.name=="'$ENV'")]..metadata.name}')\--patch"$(echo -e "spec:\ncomponents:\n$COMPONENT:\nautoScaler:\nmaxReplicas:$MAX_REPLICAS\nminReplicas:$MIN_REPLICAS")"\--typemerge

3. Verify the change:

   kubectl get hpa -n $NAMESPACE

Environment-based scaling

By default, scaling is described at the organization level. You can override the default settings by specifying environment-specific scaling in theoverrides.yaml file as shown in the following example:

envs:# Apigee environment name- name: test  components:  # Environment-specific scaling override  # Otherwise, uses scaling defined at the respective root component   runtime:    replicaCountMin: 2    replicaCountMax: 20

Metrics-based scaling

With metrics-based scaling, the runtime can use CPU and application metrics to scale theapigee-runtime pods. The KubernetesHorizontal Pod Autoscaler (HPA) API, uses thehpaBehavior field to configure the scale-up and scale-down behaviors of the target service. Metrics-based scaling is not available for any other components in a hybrid deployment.

Scaling can be adjusted based on the following metrics:

The following example from theruntime stanza in theoverrides.yaml illustrates the standard parameters (and permitted ranges) for scalingapigee-runtime pods in a hybrid implementation:

hpaMetrics:serverMainTaskWaitTime:400M(300Mto450M)serverNioTaskWaitTime:400M(300Mto450M)targetCPUUtilizationPercentage:75hpaBehavior:scaleDown:percent:periodSeconds:60(30-180)value:20(5-50)pods:periodSeconds:60(30-180)value:2(1-15)selectPolicy:MinstabilizationWindowSeconds:120(60-300)scaleUp:percent:periodSeconds:60(30-120)value:20(5-100)pods:periodSeconds:60(30-120)value:4(2-15)selectPolicy:MaxstabilizationWindowSeconds:30(30-120)

Configure more aggressive scaling

Increasing thepercent andpods values of the scale-up policy will result in a more aggressive scale-up policy. Similarly, increasing thepercent andpods values inscaleDown will result in an aggressive scale-down policy. For example:

hpaMetrics:serverMainTaskWaitTime:400MserverNioTaskWaitTime:400MtargetCPUUtilizationPercentage:75hpaBehavior:scaleDown:percent:periodSeconds:60value:20pods:periodSeconds:60value:4selectPolicy:MinstabilizationWindowSeconds:120scaleUp:percent:periodSeconds:60value:30pods:periodSeconds:60value:5selectPolicy:MaxstabilizationWindowSeconds:30

In the above example, thescaleDown.pods.value is increased to5, thescaleUp.percent.value is increased to30, and thescaleUp.pods.value is increased to5.

hpaMetrics:serverMainTaskWaitTime:400MserverNioTaskWaitTime:400MtargetCPUUtilizationPercentage:75hpaBehavior:scaleDown:percent:periodSeconds:60value:10pods:periodSeconds:60value:1selectPolicy:MinstabilizationWindowSeconds:180scaleUp:percent:periodSeconds:60value:20pods:periodSeconds:60value:4selectPolicy:MaxstabilizationWindowSeconds:30

For more information about metrics-based scaling using thehpaBehavior field, see Scaling policies.

Disable metrics-based scaling

While metrics-based scaling is enabled by default and cannot be completely disabled, you can configure the metrics thresholds at a level that metrics-based scaling will not be triggered. The resulting scaling behavior will be the same as CPU-based scaling. For example, you can use the following configuration to prevent triggering metrics-based scaling:

hpaMetrics:serverMainTaskWaitTime:4000MserverNioTaskWaitTime:4000MtargetCPUUtilizationPercentage:75hpaBehavior:scaleDown:percent:periodSeconds:60value:10pods:periodSeconds:60value:1selectPolicy:MinstabilizationWindowSeconds:180scaleUp:percent:periodSeconds:60value:20pods:periodSeconds:60value:4selectPolicy:MaxstabilizationWindowSeconds:30

Troubleshooting

This section describes troubleshooting methods for common errors you may encounter while configuring scaling and auto-scaling.

HPA showsunknown for metrics values

If metrics-based scaling does not work and the HPA showsunknown for metrics values, use the following command to check the HPA output:

kubectl describe hpaHPA_NAME

When running the command, replaceHPA_NAME with the name of the HPA you wish to view.

The output will show the CPU target and utilization of the service, indicating that CPU scaling will work in the absence of metrics-based scaling. For HPA behavior using multiple parameters, seeScaling on multiple metrics.