11.6.2　自动伸缩机制

图11-9说明了自动伸缩器的运行机制。

图11-9　自动伸缩器的运行机制

其中的相关定义如下：

·Knative Serving Revision：一个自定义资源，它是用户代码（在容器中）和配置的运行快照。

·Knative Serving Route：一种自定义资源，通过Istio ingress规则向客户公开修订。

·Kubernetes Deployment：一种Kubernetes资源，用于管理运行容器的各个pod的生命周期。每一个Deployment运行了某个版本的用户代码。

·Knative Serving Autoscaler：运行在Kubernetes中的单个pod，监视运行用户代码的pod上的请求负载。它可增加或者减少运行用户代码的部署大小，以便补偿更高或更低的流量负载。

·Knative Serving Activator：是指运行单个或多租户pod的Kubernetes部署（每个集群只有一个Activator，用于所有修订），它为没有pod的Revisions捕获请求。它通过Revision控制器调出运行用户代码的pod并转发捕获的请求。

·并发：在给定时刻提供的请求数。更多QPS或更高的延迟意味着更多并发请求。

自动伸缩的设计目标包括以下几个方面：

1）越快越好：修订版应该能够在30秒或更短的时间内支持从0到1000个并发请求。

2）更加轻量级：只要有可能，系统应该能够在没有用户干预或配置的情况下做出正确的扩缩容。

3）让一切变得更好：创建自定义组件是一种短期策略，可以支持现在的正常工作。长期策略是使底层组件更好，以便可以用配置替换自定义代码。例如，应使用Kubernetes Horizontal Pod Autoscaler和Custom Metrics替换Autoscaler。

其中，Knative Serving Autoscaler分为两部分：

·Fast Brain：每个pod保持所需的并发请求级别（满足设计目标1）。

·Slow Brain：根据CPU、内存和延迟统计信息提出所需级别（满足设计目标2）。