共计 3409 个字符，预计需要花费 9 分钟才能阅读完成。
背景
现在各大云厂商都开始提供 Serverless Kubernetes 服务，简化集群治理，升高运维管理负担，让 Kubernetes 更加简略。那么问题来了，一个零碎到底须要具备怎么的能力能力更好地撑持 Serverless 利用呢？
Serverless 利用须要的是面向利用的治理性能，比方：降级、回滚、灰度公布、流量治理以及弹性伸缩等性能。
Knative 就是建设在 Kubernetes 之上的 Serverless 利用编排框架。Knative 的次要性能之一是主动缩放应用程序的正本，包含在没有收到流量时将应用程序缩放为 0。默认 Autoscaler 组件监督流向应用程序的流量，并依据配置的指标向上或向下扩大正本。本期次要解说 Knative Autoscaler 的原理和应用。
阐明：
如需实际 Knative Autoscaler 的应用，您能够先理解以下内容。
Kubernetes：须要筹备一个 Kubernetes 的集群，并学习相干的命令。
Knative Serving：您能够依照入门指南装置 Knative。
Autoscaler 原理
Autoscaler 依据监控到的指标（concurrency、rps、cpu 等），并依据配置的指标来放大或放大正本，从而实现主动扩缩容。
(起源：Kubernetes Autoscaler)
KPA VS HPA
Knative Serving 反对 Knative Pod Autoscaler（KPA）和 Kubernetes 的 Horizontal Pod Autoscaler（HPA）。以下是不同 scaler 的性能和局限性。
KPA
- Knative Serving 外围的一部分，并且在装置 Knative Serving 后默认启用；
- 反对从 0 扩大性能；
- 不反对基于 CPU 的主动缩放。
HPA
- 不是 Knative Serving 外围的一部分，装置 Kubernetes 后默认启动；
- 不反对从 0 扩大性能；
- 反对基于 CPU 的主动缩放。
scaling 配置
通过以上介绍，咱们初步理解了 Autoscaler 执行原理，接下来介绍如何配置 KPA 或 HPA。
scaling 配置用于指定放大和放大的行为，能够为两个方向指定一个稳固窗口，以避免缩放指标中的正本数量稳定。相似地，指定扩大策略能够管制扩大时正本的变化率。
能够应用 annotations 配置 Autoscaler 实现的类型（KPA 或 HPA）；
- Global settings key：pod-autoscaler-class；
- Per-revision annotation key：autoscaling.knative.dev/class；
- Possible values：”kpa.autoscaling.knative.dev” or “hpa.autoscaling.knative.dev”；
- Default：”kpa.autoscaling.knative.dev”；
配置示例：
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
配置指标阐明
度量标准配置定义主动定标器监督哪种度量规范类型，配置参数阐明如下：
-
Setting metrics per revision: 对于 per-revision 配置，这是应用 autoscaling.knative.dev/metric 注解确定的。能够 per-revision 配置的可能的度量规范类型取决于应用的 Autoscaler 实现的类型：
- 默认的 KPA Autoscaler 反对并发和 rps 指标；
- HPA Autoscaler 反对 cpu 指标。
- Targets：配置 Targets 会为 Autoscaler 提供一个值，它会尝试为 revision 的配置指标保护该值。
- Configuring scale to zero：只有在应用 Knative Pod Autoscaler(KPA) 时能力启用缩放为零，并且只能全局配置。
- Enable scale to zero：scale to zero 值管制 Knative 是否容许正本放大到零（如果设置为 true），或者如果设置为 false 则进行在 1 个正本。
- Scale to zero grace period：指定一个下限工夫限度，零碎将在外部期待从零开始缩放的机器在删除最初一个正本之前就位。
- Configuring concurrency：并发性决定了应用程序的每个正本在任何给定工夫能够解决的并发申请数。
- Soft versus hard concurrency limits：能够设置软或硬并发限度。如果同时指定了软限度和硬限度，则将应用两个值中较小的一个。这能够避免 Autoscaler 具备硬限度值不容许的目标值。
- Target utilization：指定 Autoscaler 理论应针对的先前指定指标的百分比。这也称为指定正本运行的热度，这会导致 Autoscaler 在达到定义的硬限度之前扩大。
- Configuring scale bounds：配置下限和上限以管制主动缩放行为。还能够指定在创立后立刻将 revision 缩放到的初始比例。
- Lower bound：每个修订版应具备的最小正本数。
- Upper bound：每个修订版应具备的最大正本数。
- Initial scale：revision 在创立后必须立刻达到的初始指标比例，而后再将其标记为就绪。
- Scale Down Delay：缩减提早指定了一个工夫窗口，在利用缩减决策之前，该工夫窗口必须以升高的并发性通过。
配置示例
在应用默认配置状况下的 Knative Serving (KPA)。
-
创立一个 demo 服务。
cat <<-EOF | kubectl apply -f - apiVersion: serving.knative.dev/v1 kind: Service metadata: name: test spec: template: metadata: annotations: initial-scale: "1" allow-zero-initial-scale: "false" enable-scale-to-zero: "false" spec: containers: - image: wentevill/demo:latest EOF -
查看 pod 状态，在一段时间没有流量的状况下，scale 到 0。
kubectl get pods NAME READY STATUS RESTARTS AGE test-00001-deployment-c4546964-mjwqm 2/2 Running 0 15s -
查看 ksvc 状态。
kubectl get ksvc NAME URL LATESTCREATED LATESTREADY READY REASON test http://test.default.172.31.162.220.sslip.io test-00001 test-00001 True
阐明：
这里应用的是 magicDNS，应用其余的地址可能会不一样，请以理论应用为准。
-
拜访 service。
curl http://test.default.172.31.162.220.sslip.ioa. pod 存在：执行并返回后果。
b. pod 不存在：autoscaler 扩容 (冷启动) 到 1，而后执行并返回后果。
阐明：
冷启动时长从毫秒到分钟级别，第一批流量可能会超时。
总结
以上就是 Knative Autoscale 的内容，通过 KPA 技术实现真正意义上的 Severless。
下期将为大家带来 API 编排的利用及痛点，请大家继续关注。
援用链接
[1] Knavtive Serving：https://knative.dev/docs/serving
[2] Horizontal Pod Autoscaler：https://kubernetes.io/docs/ta…
[3] Kubernete Autoscaler：https://v1-17.docs.kubernetes…
作者
唐磊 青云科技全象平台部
本文由博客一文多发平台 OpenWrite 公布！