Serverless的应用场景
Serverless部不是一个新的概念，Knative也不是第一种Serverless平台。以往的Serverless平台，有的不支持K8S，有的虽然支持，但与K8S配合并不紧密。
我们知道K8S已经成了事实上的容器云标准，而从K8S到FaaS，需要一个“长”在K8S上的Severless，即K8S原生Serverless平台。
Knative是谷歌牵头发起的Serverless项目，希望通过提供一套简单易用的Serverless开源方案，把Serverless标准化。Knative的定位是：基于Kubernetes平台，用于构建，部署和管理现代serverless工作负载。
那么，Serverless有什么应用场景呢?
无现金支付系统
交易处理审核
欺诈识别
信用检查
通过OCR检查签名验证
产品缩略图生成
聊天机器人和CRM功能
营销活动通知
销售审核
内容PushImage结果验证（X射线，MRI）
快速医疗保健互操作性资源查询
结果通知
计划服务
测试结果要求（PDF，报告）
网络异常检测（VNF）
受害者识别
网络功能启用
交通操纵
媒体处理（5G和VNF）
OpenShift Serverless架构
Serverless应用程序本质上是事件驱动的。它们遵循一种非常简单的模式：发生某些事件，并触发您的应用程序。在Kubernetes上运行时，这意味着启动一个容器来处理该事件。您的应用程序可能会从该计算或处理中产生一些结果，并且一旦空闲了足够的时间，该容器将被缩小为零。简单，但功能强大。
按照这种简单的模式，您可以构建可接收HTTP请求并自动扩展以处理请求数量的Web应用程序，静态API或微服务。这些容器将自动缩小（到零）以在不发生请求时节省资源。
同样的模式也适用于事件驱动的应用程序，这些应用程序从消息传递系统（例如Kafka）中消费。这使得可以使用高效的分布式处理模式来实现许多业务案例。
我们通过OpenShift Serverless将无服务器功能纳入了平台，使几乎所有容器化应用程序都可以运行Serverless。这意味着您可以选择任何一种编程语言，并启用自动缩放行为，可以进行缩放以满足需求，甚至可以降低到零。
除了自动缩放HTTP请求之外，您还可以触发来自各种事件源的那些无服务器容器，并接收诸如Kafka消息，将文件上传到存储，用于重复作业的计时器以及100多个事件源（如Salesforce，Service Now，E-邮件等…由Camel-K提供支持。
OpenShift Serverless基于开源项目Knative，它是市场上增长最快的无服务器项目之一。这样可以确保您不会遇到锁定问题，并且仍然可以从不断增长的开源社区中获得创新。
从上图我们可以看出，OpenShift Serverless的两大核心模块是Serving和Eventing（Function是workload）。
OpenShift Serverless的两个核心架构
我们首先介绍Serving开始。
Serving使应用程序的部署和功能成为无服务器的容器。它提供了一种在Kubernetes上部署应用程序的简便方法。在Knative中创建应用程序时，您的应用程序由Knative Service表示。
Knative服务包含3个主要组成部分：
configuration-配置文件，描述从Service到Revision对应关系（如流量百分比）
Route-Knative Service对外暴露的路由。
revisions-应用程序的快照或版本，该快照或版本是不可变的，
如下图所示：
那么，问题来了：
1.knative service与K8S service是否是一个层级的概念？
不是。
在OCP中，我们怎么实现的蓝绿发布？给两个版本的应用创建两个K8S Service，然后给两个Service创建一个路由。然后在路由上调整流向两个Service的流量百分比。
而knative service就代表一个应用。如果想做蓝绿发布，那调整从knative service到revisions之间的流量百分比即可。调整的方式是应用configuration（yaml文件）。
2.Knative的路由和OCP的路由是一个层级的概念么？
不同
OCP的路由，准确意义上说，是Ingress Controller管理下的容器化HAProxy，是OCP集群的最外端入口。
Knative的路由是容器化的envoy（Istio的Ingressgateway就是envoy）。
Knative路由或者说ingress是个名为Kourier的开源项目。Kourier是Knative服务的Ingress。Kourier是Istio入口的轻量级替代方案，因为其部署仅由Envoy代理和控制平面组成。
3.Knative还需要Istio不？
早期的Knative依赖于Istio，OCP上GA的Knative已经不需要Istio了。
现在让我们看一下Eventing。
Eventing最基本的组件是事件源。它们为事件提供程序提供了一种机制来连接到您的应用程序并发送事件。在原始事件中，事件基于Cloud Events Specification（云事件规范），这是一种以与云无关的方式描述事件数据的机制。
在这种拓扑中，事件源将您的应用程序用作事件的“接收器”或目标。
Eventing提供了更多的构建块，例如Broker，Trigger和Subscription。broker 组件代表事件网格，其中事件可以发送给对该事件感兴趣的多个订户，并且可以调整持久性，持久性，性能和其他语义。这种模型的好处在于，将基础结构部分的管理委托给平台，从而抽象化了管理这些部分的复杂性，从开发人员的角度提供了无服务器方面。
因此，让我们介绍用于执行微服务编排的所有这些构造。假设您正在尝试建立一个事件驱动的客户创建过程。每当您填写新客户表格时，都会触发一个新客户事件。我们将必须连接一个事件源-一个将产生事件的来源系统-新客户。并将其发送给Knative Broker。
然后，我们将部署我们的微服务：
-在这种情况下，Log服务只会打印事件的内容
-Email服务，将发送欢迎消息
-Loyalty points service，它将为我们的客户在该系统上创建新记录
OpenShift Serverless的部署
我们将使用Kubernetes Operators在OpenShift上安装Knative。安装方法非常简单。
首先在OCP上创建两个项目：
[root@lb.weixinyucluster ~]# oc new-project knative-serving
[root@lb.weixinyucluster ~]# oc new-project knative-eventing
通过OperatorHub选择红帽提供的OpenShift Serverless Operator
我们注意到OpenShift Serverless Operator包含两个API：Serving和Eventing，即Knative的两个核心组件：
接下来，根据API创建pod，主要选择对应的项目：
创建完毕后，查看OCP上和kvative相关的项目：
到目前为止，OpenShift Serverless就安装完成了。
