为了尽可能降低基础设施成本，我们可以在不使用某些资源时将其关闭。然而此时的挑战之处在于，决定在必要时该如何将资源自动打开。本文将介绍如何使用 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 参考架构，以及丰富的应用程序示例。
