按需開關更省錢，這樣的 Kubernetes 集群誰不想要?
為了盡可能降低基礎設施成本，我們可以在不使用某些資源時將其關閉。然而此時的挑戰之處在于，決定在必要時該如何將資源自動打開。本文將介紹如何使用 Linode Kubernetes Engine（LKE）部署一個 Kubernetes 集群，并使用 Kubernetes Events-Driven Autoscaler（KEDA）將其收縮到 “零”，然后恢復原狀。
慶祝 Linode 加入 Akamai 解決方案大家庭，現在注冊 Linode，就可免費獲得價值 100 美元的使用額度，可以隨意使用 Linode 云平臺提供的各種服務。立即點擊這里了解詳情并注冊吧↓↓↓
出海云服務，Akamai 是您的不二之選！
為何要收縮到零
假設我們在Kubernetes上運行了一個常見的資源密集型應用，但我們只需要在工作時間里運行該應用。我們可能會希望在大家都下班后將其關閉，并在上班時間自動重新打開。
我們可能希望關閉無人使用的開發環境
此時，雖然可以使用CronJob來縮放實例，但這只是權宜之計，只能按照預先設定的時間表照計劃運行。
周末會怎么辦？公共假期又如何處理？如果整個團隊都生病無法到崗呢？
與其編制一個不斷增長的規則列表，不如根據流量來擴展我們的工作負載。當流量增加時，可以擴展副本數量；當沒有流量時，可以將整個應用關閉。當應用關閉后又收到新的傳入請求后，Kubernetes 會啟動至少一個副本來處理這些流量。
將應用收縮至零有助于節約資源
下文我們將介紹該如何：
- 攔截去往應用程序的所有流量；
- 監控流量；并
- 設置 Autoscaler 調整副本數量或關閉應用。
為供大家參考，相關代碼均已發布至 LearnK8s GitHub。
創建集群
首先需要創建一個 Kubernetes 集群?？墒褂孟铝忻顒摻ㄒ粋€集群并保存 kubeconfig 文件。
bash
$ linode-cli lke cluster-create \
--label cluster-manager \
--region eu-west \
--k8s_version 1.23
$ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig我們可通過下列命令驗證安裝過程已成功完成：
bash
$ kubectl get pods -A --kubecnotallow=kubeconfig用環境變量導出 kubeconfig 文件通常是一種比較方便的做法。為此可以運行：
bash
$ export KUBECONFIG=${PWD}/kubeconfig
$ kubectl get pods接著需要部署應用程序。
部署應用程序
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: podinfo
spec:
selector:
matchLabels:
app: podinfo
template:
metadata:
labels:
app: podinfo
spec:
containers:
- name: podinfo
image: stefanprodan/podinfo
ports:
- containerPort: 9898
---
apiVersion: v1
kind: Service
metadata:
name: podinfo
spec:
ports:
- port: 80
targetPort: 9898
selector:
app: podinfo使用下列命令提交 YAML 文件：
terminal|command=1|title=bash
$ kubectl apply -f 1-deployment.yaml隨后即可訪問該應用，為此請打開瀏覽器并訪問 localhost:8080。
bash
$ kubectl port-forward svc/podinfo 8080:80接著應該就能看到這個應用了。
接下來需要安裝 KEDA，也就是本例中將會用到的 Autoscaler。
KEDA：Kubernetes 事件驅動的 Autoscaler
Kubernetes 提供的 Horizontal Pod Autoscaler（HPA）可以作為控制器動態增減副本數量。然而 HPA 有一些不足之處：
- 無法拆箱即用，需要安裝 Metrics Server 匯總和暴露指標。
- 無法縮放至零副本。
- 只能根據指標縮放副本，并且無法攔截 HTTP 流量。
好在并非只能使用官方提供的 Autoscaler，我們還可以使用 KEDA。KEDA 是一種為下列三個組件打造的 Autoscaler：
- Scaler
- Metrics Adapter
- Controller
KEDA架構
Scaler 類似于適配器，可以從數據庫、消息代理、遙測系統等處收集指標。例如，HTTP Scaler 這個適配器就可以攔截并收集 HTTP 流量。我們可以在這里看到一個使用 RabbitMQ 的 Scaler 范例。
Metrics Adapter 負責以 Kubernetes 指標管道可以使用的格式導出 Scaler 所收集的指標。
最后，Controller 可以將所有這些組件緊密結合在一起：
- 使用適配器收集指標，并將其暴露給指標 API。
- 注冊并管理 KEDA 指定的自定義資源定義（CRD），例如 ScaledObject、TriggerAuthentication 等。
- 代替我們創建并管理 Horizontal Pod Autoscaler。
理論上的介紹就是這些了，一起看看它們實際上是如何起效的。
我們可以使用 Helm 快速安裝 Controller，詳細的說明和介紹請參閱 Helm 官網。
bash
$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/kedaKEDA 默認并不包含 HTTP Scaler，因此需要單獨安裝：
bash
$ helm install http-add-on kedacore/keda-add-ons-http隨后就可以擴展我們的應用了。
定義 Autoscaling 策略
KEDA 的 HTTP 加載項會暴露出一個 CRD，借此我們可以描述應用程序的擴展方式。一起看一個例子：
yaml
kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
name: podinfo
spec:
host: example.com
targetPendingRequests: 100
scaleTargetRef:
deployment: podinfo
service: podinfo
port: 80
replicas:
min: 0
max: 10該文件會指示攔截器將有關 http://example.com 的請求轉發給 podinfo 服務。
KEDA和HTTP攔截器
其中還包含了需要擴展的部署的名稱，本例中為 podinfo。
使用下列命令將 YAML 提交至集群：
bash
$ kubectl apply -f scaled-object.yaml提交了上述定義后，Pod 被刪除了！為何會這樣？
在創建了 HTTPScaledObject 后，KEDA 會立即將該部署收縮到零，因為目前沒有流量。
為了進行擴展，我們必須向應用發出 HTTP 請求。試試看連接到該服務并發出一個請求。
bash
$ kubectl port-forward svc/podinfo 8080:80這個命令被掛起了！
這種現象是合理的，因為目前沒有可以為請求提供服務的 Pod。但 Kubernetes 為何沒有將該部署擴展為 1？
測試 KEDA 攔截器
在使用 Helm 安裝加載項時，會創建一個名為 keda-add-ons-http-interceptor-proxy 的 Kubernetes 服務。為了讓自動擴展能夠正常起效，HTTP 流量必須首先通過該服務進行路由。我們可以用 kubectl port-forward 進行測試：
shell
$ kubectl port-forward svc/keda-add-ons-http-interceptor-proxy 8080:8080這一次我們無法在瀏覽器中訪問該 URL。
將 KEDA HTTP 加載項與入口配合使用
我們可以使用 Helm 安裝 Nginx-ingress controller：
bash
$ helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx --create-namespace隨后寫一個入口清單，將流量路由給 podinfo：
yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: podinfo
spec:
ingressClassName: nginx
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: keda-add-ons-http-interceptor-proxy # <- this
port:
number: 8080通過下列命令可以獲取負載均衡器的 IP 地址：
bash
LB_IP=$(kubectl get services -l "app.kubernetes.io/compnotallow=controller" -o jsnotallow="{.items[0].status.loadBalancer.ingress
[0].ip}" -n ingress-nginx)最后使用下列命令向應用發出一個請求：
bash
curl $LB_IP -H "Host: example.com"起作用了！如果等待足夠長的時間，我們還將注意到，該部署最終被收縮到零。
這與 Serverless on Kubernetes 有什么區別？
這種配置與 Kubernetes 上的 Serverless 框架（如 OpenFaaS）有一些顯著區別：
- 如果使用 KEDA，將無需調整應用架構，也不需要使用 SDK 來部署應用。
- Serverless 框架負責路由和服務請求，我們只需要關注應用邏輯。
- 如果使用 KEDA，所部署的是常規容器；如果使用 Serverless 框架，則并不總是如此。
這篇文章的內容感覺還行吧？有沒有想要立即在 Linode 平臺上親自嘗試一下？別忘了，現在注冊可以免費獲得價值 100 美元的使用額度，快點自己動手體驗本文介紹的功能和服務吧↓↓↓
出海云服務，Akamai 是您的不二之選！
歡迎關注 Akamai ，第一時間了解高可用的 MySQL/MariaDB 參考架構，以及豐富的應用程序示例。
