按需开关更省钱，这样的 Kubernetes 集群谁不想要​

2023-07-21 13:32:30

云计算 本文将介绍如何使用 Linode Kubernetes Engine（LKE）部署一个 Kubernetes 集群，并使用 Kubernetes Events-Driven Autoscaler（KEDA）将其收缩到 “零”，然后恢复原状。

为了尽可能降低基础设施成本，我们可以在不使用某些资源时将其关闭。然而此时的挑战之处在于，决定在必要时该如何将资源自动打开。本文将介绍如何使用 Linode Kubernetes Engine（LKE）部署一个 Kubernetes 集群，并使用 Kubernetes Events-Driven Autoscaler（KEDA）将其收缩到 “零”，然后恢复原状。

庆祝 Linode 加入 Akamai 解决方案大家庭，现在注册 Linode，就可免费获得价值 100 美元的使用额度，可以随意使用 Linode 云平台提供的各种服务。立即点击这里了解详情并注册吧↓↓↓

出海云服务，Akamai 是您的不二之选！

为何要收缩到零

假设我们在Kubernetes上运行了一个常见的资源密集型应用，但我们只需要在工作时间里运行该应用。我们可能会希望在大家都下班后将其关闭，并在上班时间自动重新打开。

我们可能希望关闭无人使用的开发环境

此时，虽然可以使用CronJob来缩放实例，但这只是权宜之计，只能按照预先设定的时间表照计划运行。

周末会怎么办？公共假期又如何处理？如果整个团队都生病无法到岗呢？

与其编制一个不断增长的规则列表，不如根据流量来扩展我们的工作负载。当流量增加时，可以扩展副本数量；当没有流量时，可以将整个应用关闭。当应用关闭后又收到新的传入请求后，Kubernetes 会启动至少一个副本来处理这些流量。

将应用收缩至零有助于节约资源

下文我们将介绍该如何：

1. 拦截去往应用程序的所有流量；
2. 监控流量；并
3. 设置 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 有一些不足之处：

1. 无法拆箱即用，需要安装 Metrics Server 汇总和暴露指标。
2. 无法缩放至零副本。
3. 只能根据指标缩放副本，并且无法拦截 HTTP 流量。

好在并非只能使用官方提供的 Autoscaler，我们还可以使用 KEDA。KEDA是一种为下列三个组件打造的 Autoscaler：

1. Scaler
2. Metrics Adapter
3. Controller

KEDA架构

Scaler 类似于适配器，可以从数据库、消息代理、遥测系统等处收集指标。例如，HTTP Scaler这个适配器就可以拦截并收集 HTTP 流量。我们可以在这里看到一个使用 RabbitMQ 的 Scaler 范例。

Metrics Adapter 负责以 Kubernetes 指标管道可以使用的格式导出 Scaler 所收集的指标。

最后，Controller 可以将所有这些组件紧密结合在一起：

1. 使用适配器收集指标，并将其暴露给指标 API。
2. 注册并管理 KEDA 指定的自定义资源定义（CRD），例如 ScaledObject、TriggerAuthentication 等。
3. 代替我们创建并管理 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 服务。

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）有一些显著区别：

1. 如果使用 KEDA，将无需调整应用架构，也不需要使用 SDK 来部署应用。
2. Serverless 框架负责路由和服务请求，我们只需要关注应用逻辑。
3. 如果使用 KEDA，所部署的是常规容器；如果使用 Serverless 框架，则并不总是如此。

这篇文章的内容感觉还行吧？有没有想要立即在 Linode 平台上亲自尝试一下？别忘了，现在注册可以免费获得价值 100 美元的使用额度，快点自己动手体验本文介绍的功能和服务吧↓↓↓

出海云服务，Akamai 是您的不二之选！

欢迎关注Akamai，第一时间了解高可用的 MySQL/MariaDB 参考架构，以及丰富的应用程序示例。