背景

如今各大云厂商都开始提供 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/v1kind: Servicemetadata:name: helloworld-gonamespace: defaultspec: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/v1kind: Servicemetadata:name: testspec:template:metadata:annotations:initial-scale: "1"allow-zero-initial-scale: "false"enable-scale-to-zero: "false"spec:containers:- image: wentevill/demo:latestEOF

查看 pod 状态，在一段时间没有流量的情况下，scale 到 0。

 kubectl get podsNAME                                   READY   STATUS    RESTARTS   AGEtest-00001-deployment-c4546964-mjwqm   2/2     Running   0          15s

查看 ksvc 状态。

 kubectl get ksvcNAME   URL                                           LATESTCREATED          LATESTREADY            READY   REASONtest   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.io
```
a. 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/tasks/run-application/horizontal-pod-autoscale

[3] Kubernete Autoscaler：https://v1-17.docs.kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

作者

唐磊青云科技全象平台部

本文由博客一文多发平台 OpenWrite 发布！

Knative Autoscaler 自定义弹性伸缩相关推荐

Fluid 给数据弹性一双隐形的翅膀 -- 自定义弹性伸缩
作者 | 车漾 Fluid 社区 Commiter 谢远东 Fluid 社区 Commiter 来源 | 阿里巴巴云原生公众号 **导读:**弹性伸缩作为 Kubernetes 的核心能力之一,但它 ...
Fluid给数据弹性一双隐形的翅膀（1） -- 自定义弹性伸缩
简介: 弹性伸缩作为Kubernetes的核心能力之一,但它一直是围绕这无状态的应用负载展开.而Fluid提供了分布式缓存的弹性伸缩能力,可以灵活扩充和收缩数据缓存. 它基于Runtime提供了缓存空 ...
HPA（Horizontal Pod Autoscaler）弹性伸缩
在生产环境中总会遇到高并发的场景,故在kubernetes中有一种Pod 水平自动扩缩策略,故整理相关文件汇总此博文! 简述 Horizontal Pod Autoscaler(HPA,Pod水平自动 ...
Fluid 给数据弹性一双隐形的翅膀 -- 自定义弹性伸缩，mysql基础教程
否则手动执行以下命令: kubectl create -f integration/custom-metrics-api/namespace.yaml kubectl create -f integr ...
Kubernetes大集群怎么管?基于监控的弹性伸缩方法
导语: 我们通常使用Prometheus来对Kubernetes运行情况进行监控.并根据监控数据来扩容或者缩容.通常的扩/缩容都是根据内存或者CPU的使用,但是很多时候我们扩/缩容的依据通常是业务监控 ...
在阿里云上进行Docker应用的自动弹性伸缩
简介上次介绍了通过监控集成实现容器的自定义弹性伸缩.最近阿里云Docker容器服务发布了自动弹性伸缩的支持,可以非常方便的支持容器的自动弹性伸缩,从而更好的支持应用的弹性管理.能够自动的监控容器应用 ...
达达集团智能弹性伸缩架构的设计与落地实践
文章来源:架构头条,嘉宾 | 杨森,编辑 | 李忠良面对节假日常规促销.618/ 双 11 购物节等配送业务订单量的暴增,达达集团通过智能弹性伸缩架构和精细化的容量管理,有效地做到了业务系统对配送全 ...
Kubernetes 弹性伸缩全场景解读（二）- HPA 的原理与演进
前言在上一篇文章 Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家 ...
K8S实战集训第一课 Ansible自动化部署k8s、弹性伸缩、Helm包管理、k8s网络模型介绍
Ansible自动化部署K8S集群一.Ansible自动化部署K8S集群 1.1 Ansible介绍 Ansible是一种IT自动化工具.它可以配置系统,部署软件以及协调更高级的IT任务,例如持续部 ...

Knative Autoscaler 自定义弹性伸缩

背景