一.简略介绍

二.文字介绍

1.Serverless

1.1 Serverless介绍：

字面理解即无服务架构，指由第三方云计算供应商以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。它的核心思想是让开发者专注构建和运行应用，而无需管理服务器。

1.2 Serverless优点：

Serverless 最大的优点就是自动扩展伸缩、无需自己管理。
在以往部署一个应用时，需要经历购买服务器、安装操作系统、购买域名等等一系列步骤，应用才能真正的上线。后来有了云服务器，我们就省去了购买服务器、安装操作系统这些操作步骤。只需要在云服务器上搭建环境、安装数据库就可以部署应用了。但是这仍然有个问题，当网站访问量过大时，你需要增加服务器；访问量过小时，需要减少服务器。如果使用 Serverless，你就不需要考虑这些，云服务商会帮你管理这一切。云服务商会根据你的访问量自动调整所需的资源。

2.knative 引入

2.1 knative介绍：

Knative 开源于 2018 年 7 月 24 日，由 Pivotal、Google、IBM 等公司共同发起，从以 K 打头的名字上就可以看出来 Knative 是用来扩展 Kubernetes 的。官方给 Knative 的定位是：基于 Kubernetes 的平台用来构建、部署和管理现代 Serverless 的工作负载。通过 Knative 可将云原生应用开发在三个领域的最佳实践结合起来——服务构建部署的自动化、服务编排的弹性化以及事件驱动基础设施的标准化。

2.2 为什么选择knative？

业务代码部署到 Serverless 平台上就离不开源码的编译、部署和事件的管理。然而无论是开源的解决方案还是各公有云的 FAAS 产品大家的实现方式大家都各不相同，缺乏统一的标准导致市场呈现碎片化。因此无论选择哪一个方案都面临供应商绑定的风险。这对云厂商来说用户 Serverless 上云就比较困难，对于 PAAS 提供商来说很难做一个通用的 PAAS 平台给用户使用。基于这样的背景 Google 牵头联合 IBM、Red Hat 等发起了 Knative 项目。

3.knative的几个核心组件

3.1 serving 服务

Knative Serving 中定义了以下 CRD 资源：

Service: 自动管理工作负载整个生命周期。负责创建 Route、Configuration 以及 Revision 资源。通过 Service 可以指定路由流量使用最新的 Revision 还是固定的 Revision
Route：负责映射网络端点到一个或多个 Revision。可以通过多种方式管理流量。也允许以百分⽐的⽅式跨 Revision 进⾏流量分配。⽀持诸如增量发布、蓝绿部署或者其他复杂的路由场景。
Configuration: 负责保持 Deployment 的期望状态，提供了代码和配置之间清晰的分离。修改一次 Configuration 产生一个 Revision。
Revision：Revision 资源是对工作负载进行的每个修改的代码和配置的时间点快照。Revision 是不可变对象，可以长期保留。

3.2 event服务

事件源：

⾕歌云、微软云、阿里云等服务中的主题并监听消息。
Kubernetes Event （kubernetes 事件） Kubernetes 集群中发⽣的所有事件的反馈。
GitHub 监视 GitHub 存储库中的事件，诸如版本的 pull 请求，推送和创建发布。
Container Source（容器源）

通道（Channel）：

通道处理缓冲和持久性，有助于确保将事件传递到其预期的服务，即使该服务已被关闭。也支持外部接入常用的MNS、RocketMQ、kafka等消息中间件 ,自己订阅事件处理。内部通过Broker/Trigger模型实现事件的订阅、过滤和路由机制。内部几种常见的事件订阅处理. 1.ACR镜像更新自动发布服务。2.代码提交自动构建镜像。3.AI音视频处理、定时任务等。

3.3 Tekon

tekton三个阶段：

资源、参数输入：包括git代码库等
执行逻辑：mvn clean package、docker build等
自定义资源输出：docker push等

tekton的几个概念：

步骤（Step）：具体操作，比如golang的单元测试、比如编译Java程序。
任务（Task） ：作为命令、二进制文件或脚本的步骤序列，也就是按顺序排列的Step集合。
频道（Pipeline）：一组串行或并行的任务。具体点就是tekton收集所有任务，将它们连接在一个有向无环图中，然后按顺序执行该图形的任务。换句话说，它创建了多个Pod对象，并确保每个Pod按成功的按照预期运行。
管道运行（PipelineRun）：执行包含一个或多个任务的管道。例如，我们可以要求Tekton每天固定时间运行某个工作流。
任务运行（TaskRun）：通过一个或多个步骤执行任务。

为什么需要Pineline：

既然Tekton是一个CI/CD工具，我们除了用它来编译和构建镜像，还可以做更多，例如，加入一些自动化测试的流程，对接其他kubernetes集群实现容器镜像的更新部署。当然，这一切都放到task里的steps也未尝不可，但是这样无法抽象出各种task进行组织和复用，所以Tekton提供了更高一级的CRD描述，Pipeline和PipelineRun，Pipeline中可以引用很多task，而PipelineRun可用来运行Pipeline

4.knative的流量治理

简单说下弹性伸缩，弹性伸缩分为hpa和kpa:

hpa：基于一些监控指标，比如CPU、内存等情况来决定是否需要扩缩容pod的数量，另外hpa不支持将实例数降到0个。
kpa：基于监控到的并发请求数来自动弹性伸缩实例数，当并发高的时候就扩容，当持续一段时间没有请求的时候，就让pod处于闲置状态，将流量转给看门人activator来中转。一旦有新请求，立马召回pod，并对外服务。

Knative Serving 流量管理模块的核心原理如下图所示。下图中的 Route 可以理解成是 Istio Gateway 的角色。

当缩容到零时进来的流量就会指到 Activator 上面。
当 Pod 数不为零时流量就会指到对应的 Pod 上面，此时流量不经过 Activator。
其中 Autoscaler 模块根据请求的 Metrics 信息实时动态的扩缩容

Knative Serving为每个Pod注入代理容器（queue-proxy），该容器负责向Autoscaler报告业务容器的并发指标。Autoscaler接收到这些指标之后，会根据并发请求数及相应的算法，调整Deployment的Pod数量，从而实现自动扩缩容。这里其实也可以使用istio的mixer，我们可以将 Knative 原有的参考架构的冷启动（cold-start）时间与新的 Istio Mixer 适配器参考架构进行了比较。结果显示它们的冷启动时间很接近。使用 Mixer 适配器的实现更加简单。无需处理基于底层网络的机制，因为这些机制是由 Envoy 处理的。