K8s原生Serverless实践：ASK与Knative
为什么需要Knative
K8s目前已成为云原生市场上主流操作系统，K8s对上通过数据抽象暴露基础设施能力，比如Service、Ingress、Pod、Deployment等，这些都是通过K8s原生API给用户暴露出来的能力；二对下K8s提供了基础设施接入的一些标准入口，比如CNI、CRI、CRD，让云资源一一个标准化的方式进入到K8s的体系中
K8s处在一个承上启下的位置，云原生用户使用K8s的目的是为了交付和管理应用，也包括灰度发布、扩缩容等情况。但是对用户来说，实现这些能力，通过直接操作K8sAPI难免有些复杂。另外节省资源成本弹性对于用户来说也越来越重要。
那么，如何才能简单地使用K8s的技术，并且实现按需使用，最终实现降本增效的目的呢？答案就是Knative
Knative简介
Knative是什么
Knative是一款基于Kubernetes的Serverless编排引擎，Knative一个很重要的目标是定制云原生跨平台的编排标准，它通过整合容器构建、工作负载以及事件驱动来实现这一目的。
Knative核心模块主要包括俩部分：事件驱动框架Eventing和提供工作负载的serving接下来本文主要介绍Serving相关的一些内容。
灰度发布
以一个简单的场景为例
在K8s中实现基于流量的灰度发布
如果要在K8s中实现基于流量的灰度发布，需要创建对应的Service与Deployment，弹性相关的需要HPA（水平容器自动缩放）来做，然后在灰度发布时，要创建新的版本。
以上图为例，初始版本是V1，我们需要创建一个新的版本V2。创建V2时，要创建对应的Service、Deployment、HPA。创建完之后Ingress设置对应流量的比例。，最终实现灰度发布的功能。
- Knative实习爱你基于流量的灰度发布
如上图所示，在Knative中需要实现基于流量的灰度发布，只需要创建一个KnativeService，然后基于不同的版本进行灰度流量，可以用Revision1和Revision2来表示。在不同版本里面，已经包含了自动弹性。
从上面简单的俩个图例，我们可以看到在Knative中实现流量灰度发布时，需要直接操作的资源明显较少。
knative Serving架构
Service
对应serverless编排的抽象，通过Service管理应用的生命周期。Service下又包含俩大部分：Route和Configuration
Route
Route对应路由策略。将请求路由到Revision，并可以向不同的Revision转发不同比例的流量。
Configuration
Configuration配置的是相应的资源信息。当前期望状态的配置。每次更新Service就会更新Configuration。
Revision
每次更新Configuration都会相应得到一个快照，这个快照就是Revision，通过Revision实现多版本管理以及灰度发布。
我们可以这样理解：Knative Service ≈ Ingress + Service + Deployment + 弹性（HPA）。
Knative应用
有了K8s为什么还要Knative？
通常Serverless=Faas+Bass，Faas无状态+Bass有状态（通用服务数据库，认证，消息队列）
资源利用率
讲资源利用率之前先看下下面两个应用，左边应用 A 这个是典型的中长尾应用，中长尾应用就是那些每天大部分时间都没有流量或者有很少流量的应用。
想一下，如果用pass（K8s）来实现的话，对于应用A，需要安装资源占用的资源最高点来申请规格，也就是4U10G，而且pass最低实例数>=1，长此以往 ，当中长尾应用足够多时，资源利用率科学系。有可能会出现大部分边缘资源被预占，但是利用率很低。
长尾应用（Long-tail applications）是指那些相对较少用户访问、需求相对较小，以及传统市场中往往被忽视的应用程序或服务。与之相对的是“头部应用”（Head applications），它们是市场上受欢迎、广泛使用的应用程序。
而Knative，恰恰可以解决应用A的资源占用问题，因为Knative可以将实例缩容为0，并根据请求自动扩缩容，缩容到0可以打打增加集群资源的利用率，因为中常委应用都是按需所取，不会过度占用资源。
比较合理的是对应用A用Knative对应用B用k8s（Pass）
弹性伸缩
大家可能会想到K9s也有hpa进行扩容，但是Knative的kpa和K8s的hpa有很大的不同：
- Knative支持缩容到0和从0启动，反应更迅速适合流量突发场景
- k8s HPA不支持缩容到0，反应比较保守
| Knative KPA | k8s HPA | |
|---|---|---|
| 指标类型 | 可以根据 请求量扩速容 | 只能根据 cpu memory 等指标扩缩容（或自定义指标） |
| 01启动 | 可以缩容到0和冷启动 | 只能缩容到1（如果缩容到0，就没有实例了，流量进不来，metrics数据永远为0，此时HPA也无能为力） |
| 指标获取方式 | Knative 指标获取有两种方式，Activator 和queue-proxy, activator的metrics 是通过websocket 主动push 给Autoscaler的，反应更迅速 | k8s 只能是通过prometheus 轮询获取。 |
| 反应速度 | Knative 默认会 计算 60 秒窗口内的平均并发数， 也会计算 6 秒的恐慌窗口，6s内达到目标并发的 2 倍，则会进入恐慌模式。在恐慌模式下，Autoscaler 在更短、更敏感的紧急窗口上工作 | 而且 HPA 本身设计比较保守，有一个稳定期（默认5min）默认在5min内没有重新扩缩容的情况下，才会触发扩缩容。当大流量突发过来时，如果正处在5min内的HPA稳定期，这个时候根据HPA的策略，会导致无法扩容。 |
按照比例灰度发布
设想一下，假如通过K8s来进行灰度发布怎么做，只能是通过俩个Deployment和俩个Service，如果灰度升级的话只能通过修改俩个Deployment的rs，一个逐渐增加一个逐渐减少，如果想要按照百分比灰度，只能在外部负载均衡做文章，所以想要Kubernetes原生实现，至少需要一个按流量分发的网关，俩个service，俩个Deployment，俩个ingress，hpa，Prometheus等，实现起来相当复杂。
使用knative就可以很简单的视线，只需一个ksvc即可
运维复杂性
使用 Knative 免运维，低成本：用户只关心业务逻辑，由工具和云去管理资源，复杂性由平台去做：容器镜像构建，Pod 的管控，服务的发布，相关的运维等。
k8s 本质上还是基础设施的抽象，对应pod的管控，服务的发布，镜像的构建等等需要上层的包装。
原文【Knative系列】看完这篇还不懂 Knative Serving，你来打我~(史上最详细) - 知乎 (zhihu.com)