KEDA
首先，KEDA 強調的是事件驅動的擴展，這意味著它不僅僅關注內部資源 (CPU/MEM) 的使用情況，還能夠根據外部事件源的情況進行擴展。
其次，KEDA 支援多種外部事件源， 例如Azure Queue、AWS SQS、Kafka等，這使開發者能夠更好地整合各種系統和服務，也意味著我們可以更靈活地應對不同的業務需求，而不僅僅依賴於內部指標。
此外，KEDA 提供更靈活的擴縮展條件，允許我們根據應用程序的實際需求定義擴展條件，例如支援 Scale down 到 0 的設置讓閒置的資源不浪費，確保滿足業務需求的同時最大限度地節省成本。
為什麼要選擇使用 KEDA ?
Kubernetes官方有 Horizontal Pod Autoscaler（HPA），目前已經有了三個版本的演進 ，從原本僅支援 CPU 指標到能夠使用外部指標來進行自動擴展了，已經能支援多種指標，但為什麼我們還需要使用 KEDA？
因為 K8s 的 HPA 接取外部指標不夠簡易方便以及能夠使用事件源不夠廣泛。
為什麼會這樣說呢？這裡就要稍微介紹一下 K8s 官方 HPA 如何接通其他外部事件的指標來進行擴展，它是使用 K8s HPA 的 v2beta2 版本提供的 ExternalMetrics 來實現的。
通常會使用 Prometheus Metrics Adapter 將 Prometheus 收到的的指標轉為HPA 能夠識別的格式，而本身指標來源的應用程式需要實作 Metrics API 或是有對應的 Exporter 來提供指標讓 Prometheus 能夠對接。
以上，官方 HPA 還是能夠做到使用外部資源來實現自動擴展，而 KEDA 則內建多種 Scaler 可直接做使用，相當於簡化了上述自定義的流程。
KEDA 工作原理
首先當你安裝 KEDA 後會發現他啟用了三個 container：
- Controller (
keda-operator) ：負責 Deployment 是否啟動，控制 Pod 數量擴展為 1 或是減縮為 0。 - Metrics Adapter (
keda-operator-metrics-apiserver)：負責將指標的訊息傳遞給 K8s 的 HPA 做自動化擴展。 - Admission Webhooks (
keda-admission-webhooks)：用於自動驗證 Kubernetes 資源的變更，以防止配置錯誤。
其次，你會看見 KEDA 建立了四份 Custom Resources ( CRD )：
- ScaledObjects ：定義了事件源和 Kubernetes 的 Deployment、StatefulSet 或自定義資源之間的映射，通過這個 CRD，可以指定 KEDA 如何根據外部指標來調整應用程式的擴展規模。
- ScaledJobs ：定義了事件源和 Kubernetes Job 之間的映射，用途於上述的 ScaledObjects 一致。
- TriggerAuthentication：提供對特定 namespace 內的事件源的身份驗證配置，以確保 KEDA 能夠安全地監聽和處理事件。
- ClusterTriggerAuthentication ：與 TriggerAuthentication 用途一致，用於全局性也就是跨多個 namespace 或整個集群的事件源。
以上就是 KEDA 基本介紹，下一篇會在記錄如何實作。
