国内在Minikube上搭建Knative及示例演示

1. 什么是Serverless?什么是Mnative?
什么是 Severless, 下面是 CNCF 对 Serverless 架构给出的定义：

“Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment”

从定义中能够看出 Serverless 架构应该下面的几个特色：

构建及运行应用的基础设施环境
无需进行服务的状态管理
足够细粒度的部署模式
可扩展且按使用量付费
上面的几个特色，除去足够细粒度的部署模式外，Kubernetes 都可以提供很是好的支持。幸运的是，无论是为了让 Kubernetes 完整支持 Serverless 架构,仍是 Google 在 cloud 上更加吸引开发者，Google 在Google Cloud Next 2018 上，发布了 Knative，并将其称为 : “ 基于 Kubernetes 的平台，用来构建、部署和管理现代 Serverless 架构 ”。Knative的主要角色以下图中所描述：

Knative 致力于提供可重用的“通用模式和最佳实践组合”的实现，目前可用的组件包括：

Build: Cloud-native source to container orchestration
Eventing: Management and delivery of events
Serving：Request-driven compute that can scale to zero
1.1 Build 构建系统
Knative 的构建工做都是被设计于在 Kubernetes 中进行，和整个 Kubernetes 生态结合更紧密；另外，它旨在提供一个通用的标准化构建组件，使其能够在普遍的场景内得以使用。正如官方文档中的说 Build 构建系统，更可能是为了定义标准化、可移植、可重用、性能高效的构建方法。Knative 提供了 Build CRD 对象，让用户能够经过 yaml 文件定义构建过程。一个典型的 Build 配置文件以下：

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: kaniko-build
spec:
  serviceAccountName: build-bot
  source:
    git:
      url: https://github.com/my-user/my-repo
      revision: master
  template:
    name: kaniko
    arguments:
    - name: IMAGE
      value: us.gcr.io/my-project/my-app
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1.2 Serving：服务系统
Serving 的核心功能是让应用运行起来以提供服务。其提供的基本功能包括：

自动化启动和销毁容器
根据名字生成网络访问相关的 Service、ingress 等对象
监控应用的请求，并自动扩缩容
支持蓝绿发布、回滚功能，方便应用方法流程
Knative Serving 功能是基于 Kubernetes 和 Istio 开发的，它使用 Kubernetes 来管理容器（deployment、pod），Istio 来管理网络路由（VirtualService、DestinationRule）。
下面这张图介绍了 Knative Serving 各组件之间的关系。

1.3. Eventing：事件系统
Knative 定义了不少事件相关的概念。介绍一下：

EventSource：事件源，可以产生事件的外部系统。
Feed：把某种类型的 EventType 和 EventSource 和对应的 Channel 绑定到一块儿。
Channel：对消息实现的一层抽象，后端可使用 kafka、RabbitMQ、Google PubSub 做为具体的实现。channel name 相似于消息集群中的topic，能够用来解耦事件源和函数。事件发生后 sink 到某个 channel 中，而后 channel 中的数据会被后端的函数消费。
Subscription：把 channel 和后端的函数绑定的一块儿，一个 channel 能够绑定到多个 Knative Service。
目前支持的事件源有三个：github（好比 merge 事件，push 事件等），Kubernetes（events），Google PubSub（消息系统），后面还会不断接入更多的事件源。

1.4 Auto-scaling
Auto-scaling 其实本质上是用于提升云上使用资源的弹性、提供按照使用量计费的能力，以提供给用户高性价比的云服务，其有如下两个特色：

Request-driving：根据请求量动态伸缩，目前经过统计系统当前并发请求量、和配置中的基准值比较，作出伸缩决策。
Scale to zero：无流量时彻底释放资源，有请求时从新唤醒。
Knative Serving 中抽象了一系列用于定义和控制应用行为的资源对象，称为Kubernetes Custom Resource Definitions (CRDs)。

Service：app/function生命周期管理
Route：路由管理
Configuration：定义了指望的运行状态
Revision: 某一时刻 code + configuration ，Revision 是不可变对象，修改代码或配置生成新的 Revision
4者间的交互以下图示：

Revision 生命周期有三种运行状态： Active：Revision 启动，能够处理请求 Reserve：一段时间未请求为 0 后，Revision 被标记为 Reserve 状态，并释放占用的资源、伸缩至零 Retired: Revision 废弃，再也不收到请求 其具体的 auto-scaling 的过程，这里就不介绍了，能够自行了解。 ---------------------