# 結合KEDA和事件驅動(Event-Driven)於Kubernetes進行自動擴展 - 林彥勳 (Kerrigan Lin)

{%hackmd @DevOpsDay/BymyqYaeo %}
> 各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
> [name=DevOpsDays Taipei 2022]

> 從這開始

###### tags: `DevOpsDays Taipei 2022`

[KEDA](https://keda.sh)

## 起源
- 目前最常聽到的auto scaling是指CPU, memory，但是這個夠用嗎？
--> 通常遇到CPU, memory不足的時候已經來不及了
- 能不能根據metrics的資料？
- Writing custom scalers and operators takes time and reduces productivity
- 許多不同的scalers，都不太一樣，整合起來也是個挑戰

## KEDA (Kubernetes Event-driven Autoscaling)
* Event-Driven
* intelligently scale your event-driven app
* Autoscaling Made Simple
* rich scaling to container in your EKS
* Built-In Scalers
* out-of-box scalers for various vendors, dbs, msg system..
* Multiple Workload Types
* Vendor-Agnostic
* Support for triggers across multiple vendors
* AWS Fargate Support
* Run and scale you fargates on AWS EKS in production workloads

CNCF - Cloud Native Computing Foundation

- HPA Horizaontal Pod Autoscaler
***即使已經喊了那麼久
真正敢在production上用auto scaling的還是非常非常少***

Scalers for AWS(自訂AutoScaling Metrics)
Amazon Opensearch
Amazon SQS
Amazon CloudWatch
Amazon Managed Service for Prometheus
...

如果已經有1000個客戶執行同樣的動作 就auto scaling (不是基於CPU跟Memory)

可以整合非常多的scalers ([KEDA 官網 - scalers](https://keda.sh/docs/2.8/scalers/))

KEDA scaled object example - yaml file
SQS
* pollingInterval: 10 //每十秒拉一次 - default 30 sec
* cooldownPeriod: 10 //default 300 sec
* ... - queueLength: 2 //每超過兩個message就新增一個pod

### Long Runnning Execution
如果用CPU做為scaling依據，很容易遇到問題
- 做到一半的jobs，因為CPU暫時下來，就可能被HPA砍掉

- Option 1: Leverage K8S pod Lifecycle
- 偏土炮，因為不知道要做多久，就是一直延長
- Option 2: Use the Scaled Jobs functionality of KEDA to create K8S Job per event

### Demo Architecture
1. Producer send mseaage to Amazon SQS
2. KEDA check Amazon SQS length
3. KEDA告訴Scaled Oject
4. Scaled Object告訴HPA 你該長大了
5. Scales Up/Down
6. Consume Message to Amazon SQS

Prometheus query result to trigger KEDA

### Core Principles
... (watch speaker's ppt)