为了尽可能降低基础设施成本，我们可以在不使用某些资源时将其关闭。然而此时的挑战之处在于，决定在必要时该如何将资源自动打开。本文将介绍如何使用Linode Kubernetes Engine（LKE）部署一个Kubernetes集群，并使用Kubernetes Events-Driven Autoscaler（KEDA）将其收缩到“零”，然后恢复原状。
为庆祝Linode加入 Akamai解决方案大家庭，现在注册Linode，就可免费获得价值100美元的使用额度，可以随意使用Linode云平台提供的各种服务。立即点击这里了解详情并注册吧↓↓↓
为何要收缩到零
假设我们在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 --kubeconfig=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
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/keda
KEDA默认并不包含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服务。
其中还包含了需要扩展的部署的名称，本例中为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/component=controller" -o jsonpath="{.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 ，第一时间了解高可用的MySQL/MariaDB参考架构，以及丰富的应用程序示例。
