Knative ServerlessService 介绍

ServerlessService 简称： SKS，全称：Serverless Kubernetes-style Service 社区文档：

简单的解释

Knative 中 Autoscaler 是负责 KPA 伸缩的，并且在没有流量的时候可以缩容到零，而具体请求的流量是通过 Route 来实现的。那么 Route 和 Autoscaler 这两个看似独立的功能其实是需要紧密的配合的。否则 Autoscaler 都把 Pod 缩容到零了 Route 还在往老的 Revision 上面转发流量就会导致服务异常。所以 SKS（Serverless Kubernetes-style Service）就是解决这个问题的。

目前的路由切换机制以及问题

首先从上图可以看出来目前是通过 Route 切换后端的 service 名字实现当 revision 缩容到零的时候路由转发到 activator 上面，但是这个过程需要 istio 重新下发 virtualService 并且没有一个检查机制，不知道 istio 是否下发完成。

参见如下三个代码片段：

从上面的代码片段中可以发现，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 流量摘除的策略后续再单独介绍。