ServerlessService 简称： SKS， 全称：Serverless Kubernetes-style Service 社区文档：
- https://docs.google.com/document/d/1byHQL6kePDZq6Qt4MqB-g4BDfiaJsfDPGb5oJEK1Ldo/edit?ts=5c81373b#
- https://docs.google.com/document/d/1byHQL6kePDZq6Qt4MqB-g4BDfiaJsfDPGb5oJEK1Ldo/preview#
- https://docs.google.com/presentation/d/1JJ7OlzBlpWwk1q0zdoRS_T3e84wi5Fr7G9wMbL8VhEc/preview?slide=id.g58b9a24884_0_24
简单的解释
Knative 中 Autoscaler 是负责 KPA 伸缩的，并且在没有流量的时候可以缩容到零，而具体请求的流量是通过 Route 来实现的。那么 Route 和 Autoscaler 这两个看似独立的功能其实是需要紧密的配合的。否则 Autoscaler 都把 Pod 缩容到零了 Route 还在往老的 Revision 上面转发流量就会导致服务异常。所以 SKS（Serverless Kubernetes-style Service） 就是解决这个问题的。
目前的路由切换机制以及问题
首先从上图可以看出来目前是通过 Route 切换后端的 service 名字实现当 revision 缩容到零的时候路由转发到 activator 上面，但是这个过程需要 istio 重新下发 virtualService 并且没有一个检查机制，不知道 istio 是否下发完成。
参见如下三个代码片段：
- https://github.com/kubedemo/serving/blob/master/pkg/reconciler/v1alpha1/autoscaling/kpa/scaler.go#L160
- https://github.com/kubedemo/serving/blob/master/pkg/autoscaler/config.go#L148
- https://github.com/kubedemo/serving/blob/master/pkg/autoscaler/config.go#L35
从上面的代码片段中可以发现，activator 想要把一个 revision 缩容到零需要先标记为 inactive 状态，然后强制等待至少 30s，这 30s 其实就是在等待 istio virtualService 生效。这里有两个问题：
istio virtualService 如果在 30s 内已经生效了那多余的等待就是浪费的
如果负载很高的时候 30s 也不一定能够生效，所以也可能会失败
根本原因是两边的信息没有确认机制，目前仅仅是通过 30s 大概同步一下。#2949 这个 issue 有人提出了这个问题。
SKS(Serverless Kubernetes-style Service) 解决思路
State #1: Steady State
State #2: Scaled-to-Zero
State #3 (Prospective): Overload / Underprovisioned
Scale to Zero 时序图 : 最关键的就是这张时序图
为了解决这个问题所以提出了 SKS 的想法。SKS 有两个核心点：
- 加上了强制确认机制，SKS controller 会主动向发起请求确保 activator 路由生效之后再进行缩容到零的操作
- 从始至终 Route 后端对应的 service 的名字是不会变化。所以 virtualService 本身不需要重新下发
不过也有一个问题：因为 istio 路由转发的原理也是通过监听 endpoints 然后直接向EndPoint 转发，而不是向 ClusterIP，所以即便 SKS controller 探测到 activator 成功了也不代表 istio 能够探测成功。不过这个生效时间差就很小了。
把问题降维到这个程度基本上就解决了，目前社区认为这个时间还是可以接受的。因为在 Kubernetes 体系中 cloud-controller-manager 本身的实现机制和这个过程是一样的。Kubernetes 中当有 pod 需要删除时 controller-manager 会在 EndPoint 中摘除相关的 pod 信息但也不会等待 cloud-controller-manager 完成 slb 的摘除。这里面还有一个 pod 优雅下线的逻辑一起配合生效，关于 Kubernetes pod 流量摘除的策略后续再单独介绍。
