Autoscale Sample App - Go

A demonstration of the autoscaling capabilities of a Knative Serving Revision.

Prerequisites

  1. A Kubernetes cluster with Knative Serving) installed.
  2. The hey load generator installed (go install github.com/rakyll/hey@latest).

  3. Clone this repository, and move into the sample directory:

    1. git clone -b "release-1.13" https://github.com/knative/docs knative-docs
    2. cd knative-docs

Deploy the Service

  1. Deploy the sample Knative Service:

    1. kubectl apply -f docs/serving/autoscaling/autoscale-go/service.yaml

  2. Obtain the URL of the service (once Ready):

    1. $ kubectl get ksvc autoscale-go
    2. NAME            URL                                                LATESTCREATED         LATESTREADY           READY   REASON
    3. autoscale-go    http://autoscale-go.default.1.2.3.4.sslip.io    autoscale-go-96dtk    autoscale-go-96dtk    True

Load the Service

  1. Make a request to the autoscale app to see it consume some resources.

    1. curl "http://autoscale-go.default.1.2.3.4.sslip.io?sleep=100&prime=10000&bloat=5"
    1. Allocated 5 Mb of memory.
    2. The largest prime less than 10000 is 9973.
    3. Slept for 100.13 milliseconds.

  2. Send 30 seconds of traffic maintaining 50 in-flight requests.

    1. hey -z 30s -c 50 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?sleep=100&prime=10000&bloat=5" \
    3.   && kubectl get pods
    1. Summary:
    2.   Total:        30.3379 secs
    3.   Slowest:      0.7433 secs
    4.   Fastest:      0.1672 secs
    5.   Average:      0.2778 secs
    6.   Requests/sec: 178.7861
    8.   Total data:   542038 bytes
    9.   Size/request: 99 bytes
    11. Response time histogram:
    12.   0.167 [1]     |
    13.   0.225 [1462]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    14.   0.282 [1303]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    15.   0.340 [1894]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    16.   0.398 [471]   |■■■■■■■■■■
    17.   0.455 [159]   |■■■
    18.   0.513 [68]    |■
    19.   0.570 [18]    |
    20.   0.628 [14]    |
    21.   0.686 [21]    |
    22.   0.743 [13]    |
    24. Latency distribution:
    25.   10% in 0.1805 secs
    26.   25% in 0.2197 secs
    27.   50% in 0.2801 secs
    28.   75% in 0.3129 secs
    29.   90% in 0.3596 secs
    30.   95% in 0.4020 secs
    31.   99% in 0.5457 secs
    33. Details (average, fastest, slowest):
    34.   DNS+dialup:   0.0007 secs, 0.1672 secs, 0.7433 secs
    35.   DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
    36.   req write:    0.0001 secs, 0.0000 secs, 0.0045 secs
    37.   resp wait:    0.2766 secs, 0.1669 secs, 0.6633 secs
    38.   resp read:    0.0002 secs, 0.0000 secs, 0.0065 secs
    40. Status code distribution:
    41.   [200] 5424 responses
    1. NAME                                             READY   STATUS    RESTARTS   AGE
    2. autoscale-go-00001-deployment-78cdc67bf4-2w4sk   3/3     Running   0          26s
    3. autoscale-go-00001-deployment-78cdc67bf4-dd2zb   3/3     Running   0          24s
    4. autoscale-go-00001-deployment-78cdc67bf4-pg55p   3/3     Running   0          18s
    5. autoscale-go-00001-deployment-78cdc67bf4-q8bf9   3/3     Running   0          1m
    6. autoscale-go-00001-deployment-78cdc67bf4-thjbq   3/3     Running   0          26s

Analysis

Algorithm

Knative Serving autoscaling is based on the average number of in-flight requests per pod (concurrency). The system has a default target concurrency of 100(Search for container-concurrency-target-default) but we used 10 for our service. We loaded the service with 50 concurrent requests so the autoscaler created 5 pods (50 concurrent requests / target of 10 = 5 pods)

Panic

The autoscaler calculates average concurrency over a 60 second window so it takes a minute for the system to stabilize at the desired level of concurrency. However the autoscaler also calculates a 6 second panic window and will enter panic mode if that window reached 2x the target concurrency. In panic mode the autoscaler operates on the shorter, more sensitive panic window. Once the panic conditions are no longer met for 60 seconds, the autoscaler will return to the initial 60 second stable window.

  1.                                                        |
  2.                                   Panic Target--->  +--| 20
  3.                                                     |  |
  4.                                                     | <------Panic Window
  5.                                                     |  |
  6.        Stable Target--->  +-------------------------|--| 10   CONCURRENCY
  7.                           |                         |  |
  8.                           |                      <-----------Stable Window
  9.                           |                         |  |
  10. --------------------------+-------------------------+--+ 0
  11. 120                       60                           0
  12.                      TIME

Customization

The autoscaler supports customization through annotations. There are two autoscaler classes built into Knative:

  1. kpa.autoscaling.knative.dev which is the concurrency-based autoscaler described earlier (the default), and
  2. hpa.autoscaling.knative.dev which delegates to the Kubernetes HPA which autoscales on CPU usage.

Example of a Service scaled on CPU:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: autoscale-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         # Standard Kubernetes CPU-based autoscaling.
  11.         autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
  12.         autoscaling.knative.dev/metric: cpu
  13.     spec:
  14.       containers:
  15.         - image: ghcr.io/knative/autoscale-go:latest

Additionally the autoscaler targets and scaling bounds can be specified in annotations. Example of a Service with custom targets and scale bounds:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: autoscale-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         # Knative concurrency-based autoscaling (default).
  11.         autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
  12.         autoscaling.knative.dev/metric: concurrency
  13.         # Target 10 requests in-flight per pod.
  14.         autoscaling.knative.dev/target: "10"
  15.         # Disable scale to zero with a min scale of 1.
  16.         autoscaling.knative.dev/min-scale: "1"
  17.         # Limit scaling to 100 pods.
  18.         autoscaling.knative.dev/max-scale: "100"
  19.     spec:
  20.       containers:
  21.         - image: ghcr.io/knative/autoscale-go:latest

Note

For an hpa.autoscaling.knative.dev class Service, the autoscaling.knative.dev/target specifies the CPU percentage target (default "80").

Demo

View the Kubecon Demo of Knative autoscaler customization (32 minutes).

Other Experiments

  1. Send 60 seconds of traffic maintaining 100 concurrent requests.

    1. hey -z 60s -c 100 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?sleep=100&prime=10000&bloat=5"

  2. Send 60 seconds of traffic maintaining 100 qps with short requests (10 ms).

    1. hey -z 60s -q 100 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?sleep=10"

  3. Send 60 seconds of traffic maintaining 100 qps with long requests (1 sec).

    1. hey -z 60s -q 100 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?sleep=1000"

  4. Send 60 seconds of traffic with heavy CPU usage (~1 cpu/sec/request, total 100 cpus).

    1. hey -z 60s -q 100 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?prime=40000000"

  5. Send 60 seconds of traffic with heavy memory usage (1 gb/request, total 5 gb).

    1. hey -z 60s -c 5 \
    2.   "http://autoscale-go.default.1.2.3.4.sslip.io?bloat=1000"

Cleanup

  1. kubectl delete -f docs/serving/autoscaling/autoscale-go/service.yaml

Further reading

Autoscaling Developer Documentation