|
1 | 1 | --- |
2 | | -title: Integration |
| 2 | +title: Integrations |
3 | 3 | --- |
4 | 4 |
|
5 | | -<!-- START doctoc generated TOC please keep comment here to allow auto update --> |
6 | | -<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
7 | | -**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* |
8 | | - |
9 | | -- [Integration with HPA](#integration-with-hpa) |
10 | | -- [Integration with KEDA](#integration-with-keda) |
11 | | - - [Prerequisites](#prerequisites) |
12 | | - - [Starting setup](#starting-setup) |
13 | | - - [Add Elasti to the service](#add-elasti-to-the-service) |
14 | | - |
15 | | -<!-- END doctoc generated TOC please keep comment here to allow auto update --> |
16 | 5 |
|
17 | 6 | # Integration with HPA |
18 | 7 | Elasti works seamlessly with Horizontal Pod Autoscaler (HPA) and handles scaling to zero on its own. Since Elasti manages the scale-to-zero functionality, you can configure HPA to handle scaling based on metrics for any number of replicas **greater than zero**, while Elasti takes care of scaling to/from zero. |
19 | 8 |
|
| 9 | +A setup is explained in the [getting started](getting-started.md) guide. |
| 10 | + |
20 | 11 | # Integration with KEDA |
21 | | -Elasti takes care of scaling up a service when there is some traffic. We need another component to scale down the service when there is no traffic. KEDA is a good candidate for this. |
22 | | -Here we will see how to integrate Elasti with KEDA to perform a complete scaling solution. |
| 12 | +Elasti takes care of scaling up and down a service when there is some traffic. KEDA is a good candidate for performing the scaling logic for the service from minReplicas to maxReplicas based on it's triggers. |
| 13 | + |
| 14 | +Here we will see how to integrate Elasti with KEDA to build a complete scaling solution. |
23 | 15 |
|
24 | 16 | ## Prerequisites |
25 | | -- Istio installed in the cluster - [Istio Installation](https://istio.io/latest/docs/setup/getting-started/) |
| 17 | +- Make sure you have gone through the [getting started](getting-started.md) guide. We will extend the same setup for this integration. |
26 | 18 | - KEDA installed in the cluster - [KEDA Installation](https://keda.sh/docs/latest/deploy/) |
27 | | -- Elasti installed in the cluster - [Elasti Installation](https://github.com/truefoundry/elasti) |
28 | | -- Prometheus installed in the cluster - [Prometheus Installation](https://prometheus.io/docs/prometheus/latest/installation/) |
29 | | -- A service to scale |
30 | | - |
31 | | -## Starting setup |
32 | | -Let's start with a setup where scaling down to zero is performed by KEDA for a service deployed behind istio. |
33 | 19 |
|
34 | | - |
| 20 | +## Steps |
| 21 | +### 1. Create a keda scaler for the service |
35 | 22 |
|
36 | | -- traffic is being routed to the service via istio |
37 | | -- keda handles the autoscaling logic for the service from minReplicas to maxReplicas based on it's triggers |
| 23 | +Let's create a keda scaler for the httpbin service. |
38 | 24 |
|
39 | | -The keda scaler yaml for such a setup is as follows: |
40 | | - |
41 | | -```yaml |
42 | | -apiVersion: keda.sh/v1alpha1 |
43 | | -kind: ScaledObject |
44 | | -metadata: |
45 | | - name: <service-name>-scaled-object |
46 | | -spec: |
47 | | - maxReplicaCount: 1 |
48 | | - minReplicaCount: 1 |
49 | | - pollingInterval: 30 |
50 | | - scaleTargetRef: |
51 | | - apiVersion: apps/v1 |
52 | | - kind: Deployment |
53 | | - name: <service-name> |
54 | | - triggers: |
55 | | - - type: <trigger-type> |
56 | | - metadata: |
57 | | - <trigger-metadata> |
| 25 | +```bash |
| 26 | +kubectl apply -f ./playground/config/ demo-application-keda.yaml |
58 | 27 | ``` |
| 28 | +Note that the same prometheus query is used as in the [getting started](getting-started.md) guide for ElastiService and the namespace is the same as the namespace that the ElastiService is created in. |
59 | 29 |
|
60 | 30 | Refer to the [keda documentation](https://keda.sh/docs/2.16/reference/scaledobject-spec/) for more details on configuring the ScaledObject. |
61 | 31 |
|
62 | | -## Add Elasti to the service |
63 | | -We will create an [ElastiService](../README.md#1-define-an-elastiservice) object for this service, update the keda scaler to query the Elasti metrics and add a scrapeconfig to the prometheus instance to scrape the Elasti metrics. The final setup will look like this: |
64 | | -
|
65 | | - |
66 | | -
|
67 | | -Here is the flow of requests: |
68 | | -- first request on istio will go to resolver |
69 | | -- controller will scale up the service to 1 replica |
70 | | -- resolver will forward the request to the pods for further processing |
71 | | -
|
72 | | -When elasti scales down the service, it will pause the keda ScaledObject to prevent it from scaling up the service again, and when elasti scales up the service, it will resume the ScaledObject. |
73 | | -
|
74 | | -To achieve this, we will have to add the ScaledObject details to the ElastiService. |
75 | | -
|
76 | | -Note that the namespace that the ElastiService is created in **must** be the same as the namespace that the keda ScaledObject is deployed in. |
77 | | -
|
78 | | -An example of the ElastiService object is as follows: |
| 32 | +### 2. Update ElastiService to work with the keda scaler |
79 | 33 |
|
| 34 | +We will update the ElastiService to specify the keda scaler to work with. We will add the following fields to the ElastiService object: |
80 | 35 | ```yaml |
81 | | -apiVersion: elasti.truefoundry.com/v1alpha1 |
82 | | -kind: ElastiService |
83 | | -metadata: |
84 | | - name: <service-name>-elasti-service |
85 | 36 | spec: |
86 | 37 | autoscaler: |
87 | | - name: <service-name>-scaled-object # Must be the same as the keda ScaledObject name |
| 38 | + name: httpbin-scaled-object |
88 | 39 | type: keda |
89 | | - cooldownPeriod: 300 # Elasti will not scale down a service for at least cooldownPeriod seconds from lastScaledUpTime |
90 | | - minTargetReplicas: 1 |
91 | | - scaleTargetRef: |
92 | | - apiVersion: apps/v1 |
93 | | - kind: Deployment |
94 | | - name: <service-name> |
95 | | - service: <service-name> |
96 | | - triggers: |
97 | | - - metadata: |
98 | | - query: sum(rate(istio_requests_total{destination_service="<service-name>.demo.svc.cluster.local"}[1m])) or vector(0) |
99 | | - serverAddress: http://<prometheus-instance-url>:9090 |
100 | | - threshold: "0.01" |
101 | | - type: prometheus |
102 | | - ``` |
103 | | -
|
104 | | -With these changes, elasti can reliably scale up the service when there is traffic and scale down the service to zero when there is no traffic. |
| 40 | +``` |
| 41 | +
|
| 42 | +Patch the ElastiService object with the above changes. |
| 43 | +
|
| 44 | +```bash |
| 45 | +kubectl patch elastiservice httpbin -n elasti-demo -p '{"spec":{"autoscaler":{"name": "httpbin-scaled-object", "type": "keda"}}}' --type=merge |
| 46 | +``` |
| 47 | +
|
| 48 | +Now when elasti scales down the service, it will pause the keda ScaledObject to prevent it from scaling up the service again, and when elasti scales up the service, it will resume the ScaledObject. |
| 49 | +
|
| 50 | +With these changes, elasti can reliably scale up the service when there is traffic and scale down the service to zero when there is no traffic while keda can handle the scaling logic for the service from minReplicas to maxReplicas based on it's triggers. |
0 commit comments