為了盡可能降低基礎(chǔ)設(shè)施成本，我們可以在不使用某些資源時將其關(guān)閉。然而此時的挑戰(zhàn)之處在于，決定在必要時該如何將資源自動打開。本文將介紹如何使用 Linode Kubernetes Engine（LKE）部署一個 Kubernetes 集群，并使用 Kubernetes Events-Driven Autoscaler（KEDA）將其收縮到 “零”，然后恢復(fù)原狀。

慶祝 Linode 加入 Akamai 解決方案大家庭，現(xiàn)在注冊 Linode，就可免費獲得價值 100 美元的使用額度，可以隨意使用 Linode 云平臺提供的各種服務(wù)。立即點擊這里了解詳情并注冊吧↓↓↓

出海云服務(wù)，Akamai 是您的不二之選！

為何要收縮到零

假設(shè)我們在Kubernetes上運行了一個常見的資源密集型應(yīng)用，但我們只需要在工作時間里運行該應(yīng)用。我們可能會希望在大家都下班后將其關(guān)閉，并在上班時間自動重新打開。

我們可能希望關(guān)閉無人使用的開發(fā)環(huán)境

此時，雖然可以使用CronJob來縮放實例，但這只是權(quán)宜之計，只能按照預(yù)先設(shè)定的時間表照計劃運行。

周末會怎么辦？公共假期又如何處理？如果整個團隊都生病無法到崗呢？

與其編制一個不斷增長的規(guī)則列表，不如根據(jù)流量來擴展我們的工作負載。當流量增加時，可以擴展副本數(shù)量；當沒有流量時，可以將整個應(yīng)用關(guān)閉。當應(yīng)用關(guān)閉后又收到新的傳入請求后，Kubernetes 會啟動至少一個副本來處理這些流量。

將應(yīng)用收縮至零有助于節(jié)約資源

下文我們將介紹該如何：

1. 攔截去往應(yīng)用程序的所有流量；
2. 監(jiān)控流量；并
3. 設(shè)置 Autoscaler 調(diào)整副本數(shù)量或關(guān)閉應(yīng)用。

為供大家參考，相關(guān)代碼均已發(fā)布至 LearnK8s GitHub。

創(chuàng)建集群

首先需要創(chuàng)建一個 Kubernetes 集群?？墒褂孟铝忻顒?chuàng)建一個集群并保存 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

用環(huán)境變量導(dǎo)出 kubeconfig 文件通常是一種比較方便的做法。為此可以運行：

bash
$ export KUBECONFIG=${PWD}/kubeconfig
$ kubectl get pods

接著需要部署應(yīng)用程序。

部署應(yīng)用程序

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

隨后即可訪問該應(yīng)用，為此請打開瀏覽器并訪問 localhost:8080。

bash
$ kubectl port-forward svc/podinfo 8080:80

接著應(yīng)該就能看到這個應(yīng)用了。

接下來需要安裝 KEDA，也就是本例中將會用到的 Autoscaler。

KEDA：Kubernetes 事件驅(qū)動的 Autoscaler

Kubernetes 提供的 Horizontal Pod Autoscaler（HPA）可以作為控制器動態(tài)增減副本數(shù)量。然而 HPA 有一些不足之處：

1. 無法拆箱即用，需要安裝 Metrics Server 匯總和暴露指標。
2. 無法縮放至零副本。
3. 只能根據(jù)指標縮放副本，并且無法攔截 HTTP 流量。

好在并非只能使用官方提供的 Autoscaler，我們還可以使用 KEDA。KEDA 是一種為下列三個組件打造的 Autoscaler：

1. Scaler
2. Metrics Adapter
3. Controller

KEDA架構(gòu)

Scaler 類似于適配器，可以從數(shù)據(jù)庫、消息代理、遙測系統(tǒng)等處收集指標。例如，HTTP Scaler 這個適配器就可以攔截并收集 HTTP 流量。我們可以在這里看到一個使用 RabbitMQ 的 Scaler 范例。

Metrics Adapter 負責(zé)以 Kubernetes 指標管道可以使用的格式導(dǎo)出 Scaler 所收集的指標。

最后，Controller 可以將所有這些組件緊密結(jié)合在一起：

1. 使用適配器收集指標，并將其暴露給指標 API。
2. 注冊并管理 KEDA 指定的自定義資源定義（CRD），例如 ScaledObject、TriggerAuthentication 等。
3. 代替我們創(chuàng)建并管理 Horizontal Pod Autoscaler。

理論上的介紹就是這些了，一起看看它們實際上是如何起效的。

我們可以使用 Helm 快速安裝 Controller，詳細的說明和介紹請參閱 Helm 官網(wǎng)。

bash
$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda

KEDA 默認并不包含 HTTP Scaler，因此需要單獨安裝：

bash
$ helm install http-add-on kedacore/keda-add-ons-http

隨后就可以擴展我們的應(yīng)用了。

定義 Autoscaling 策略

KEDA 的 HTTP 加載項會暴露出一個 CRD，借此我們可以描述應(yīng)用程序的擴展方式。一起看一個例子：

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

該文件會指示攔截器將有關(guān) http://example.com 的請求轉(zhuǎn)發(fā)給 podinfo 服務(wù)。

KEDA和HTTP攔截器

其中還包含了需要擴展的部署的名稱，本例中為 podinfo。

使用下列命令將 YAML 提交至集群：

bash
$ kubectl apply -f scaled-object.yaml

提交了上述定義后，Pod 被刪除了！為何會這樣？

在創(chuàng)建了 HTTPScaledObject 后，KEDA 會立即將該部署收縮到零，因為目前沒有流量。

為了進行擴展，我們必須向應(yīng)用發(fā)出 HTTP 請求。試試看連接到該服務(wù)并發(fā)出一個請求。

bash
$ kubectl port-forward svc/podinfo 8080:80

這個命令被掛起了！

這種現(xiàn)象是合理的，因為目前沒有可以為請求提供服務(wù)的 Pod。但 Kubernetes 為何沒有將該部署擴展為 1？

測試 KEDA 攔截器

在使用 Helm 安裝加載項時，會創(chuàng)建一個名為 keda-add-ons-http-interceptor-proxy 的 Kubernetes 服務(wù)。為了讓自動擴展能夠正常起效，HTTP 流量必須首先通過該服務(wù)進行路由。我們可以用 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)

最后使用下列命令向應(yīng)用發(fā)出一個請求：

bash
curl $LB_IP -H "Host: example.com"

起作用了！如果等待足夠長的時間，我們還將注意到，該部署最終被收縮到零。

這與 Serverless on Kubernetes 有什么區(qū)別？

這種配置與 Kubernetes 上的 Serverless 框架（如 OpenFaaS）有一些顯著區(qū)別：

1. 如果使用 KEDA，將無需調(diào)整應(yīng)用架構(gòu)，也不需要使用 SDK 來部署應(yīng)用。
2. Serverless 框架負責(zé)路由和服務(wù)請求，我們只需要關(guān)注應(yīng)用邏輯。
3. 如果使用 KEDA，所部署的是常規(guī)容器；如果使用 Serverless 框架，則并不總是如此。

這篇文章的內(nèi)容感覺還行吧？有沒有想要立即在 Linode 平臺上親自嘗試一下？別忘了，現(xiàn)在注冊可以免費獲得價值 100 美元的使用額度，快點自己動手體驗本文介紹的功能和服務(wù)吧↓↓↓

出海云服務(wù)，Akamai 是您的不二之選！

歡迎關(guān)注 Akamai ，第一時間了解高可用的 MySQL/MariaDB 參考架構(gòu)，以及豐富的應(yīng)用程序示例。