1. 什么是 Serverless ? 什么是 Knative ?

什么是 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 配置文件如下：

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 的过程，这里就不介绍了，可以自行了解。

2. Knative 实践

在上面大致了解 Knative 后，本节将详细介绍如何完成 Knative 的部署。为方便大家能按指引同样完成 Knative 的部署，因此选择滴滴云提供的基本的云服务器完成，大家可在滴滴云上申请云服务器然后按下面的步骤，完成 Knative 的基本部署。若未注册滴滴云账号的，可以通过此【链接】完成注册，有券^_^。

2.1 云服务器申请

注册好滴滴云账号后，申请一个 16核32G内存，带80G本地盘及500G EBS数据盘 的云服务器，然后申请一按流量计费的 公网 IP。之所以申请这样的配置，是为后续完成整个部署的过程更为顺畅。

首先登录服务器，滴滴云出于安全考虑默认的登录账户是 dc2-user，并且禁止了 root 用户的直接登录，登录命令如下：

服务器登录成功，使用 sudo su 命令完成到 root 账户的切换，购买云服务器时，我们购买了一块 500G 的数据盘，由于从未挂载过，需要先 格式化云盘，才能开始使用该云盘。初始化的过程如下：

vdb 即为那块新买的 EBS 盘。详细的挂载流程可见挂载云盘。通过教程的指引完成了数据盘的挂载，如下：

到目前为此，云服务器的准备好了，下面开始 Knative 的部署。

2.2 Knative 部署

我们买的是一台裸的云服务器，因此需要完成整个 Knative 的部署，大致需要下面的几个步骤：
* Go 安装
* Docker 安装
* Kubectl 安装
* Minikube 安装
* Istio 部署
* Knative Serving/Knative Build 部署

依次完成上面几个相关组件的安装。

2.2.1 Go 安装

安装 Go 环境,先使用 yum 安装一个低版本的 Golang，如下：

但因为 Kubectl 必须要大于 Go.1.11 版本的 Golang，需要升级 Golang,如下：

也可以在此地址下载对应的 Go 版本进行安装。
至此基本完成了 Go 的安装。

2.2.2 Docker 安装

Docker 的安装是为后面的集群搭建做准备的，如下：

通过上面的步骤，即完成了 Docker 的安装。下面继续安装其它组件。

2.2.3 Kubectl 安装

因为 Knative 依赖 Kubernates，刚刚在滴滴云只买了一个 DC2 云服务器，在开始之前还需要一个 Kubernates 集群，由于只有一台云服务器，直接选择安装 Minikube。安装 Minikube 前可以先安装 Kubectl 及相关驱动，这里选择通过源代码编译安装，编译源码需要有 Git、Golang 环境的支撑。安装过程如下：

至此完成了 Kubectl 工具的安装。也可以不通过此方式安装，但需要注意版本是否正确，否则下面启动 minikube 时会报错。

2.2.4 Minikube 安装

下一步即开始安装 Minikube，Minikube 的安装如下：

因为 Minikube 的启动其实也需要依赖一些墙外的镜像，为了顺利安装需要将相应的镜像提前准备好，然后以 Docker tag 方式进行标记，相关的命令，已经准备好，放在了 github 中，准备过程如下：

执行完上面的命令后，在无报错的情况，通过下面的命令即可完成 Minikube 的启动, 如下：

经历上面的过程，Minikube 基本是准备好了，下面开始安装Knative相关组件

2.2.5 Istio 部署

使用下面的命令开始安装

几分钟后，各 pods 的状态均会变为 running 或者 completed，如下：

至此 Istio 基本部署完成。

2.2.6 Knative Serving/Knative Build 部署

下面开始部署 Knative 相关的组件

官方提供了上面的部署命令，但是因为科学上网的问题，最后是不可能装成功的，下载上面的 release-lite.yaml 其实部分依赖的 image 文件是在 gcr.io 等地方，如下：

除去上面的几个外，还有一部分这里不一一给出了，上面的镜像地址是带 digest 引用的，直接用 Docker tag 其实是解决不了问题的，如下会报refusing to create a tag with a digest reference的错误：

因此得想其它办法，一个比较简单的办法是利用 Docker Hub ，可在国内 pull，但它同时能拉取国外镜像的特点，选择在 Docker Hub 上构建一个以目标镜像为 base 镜像的方式，然后将上面 release-lite.yaml 上的目标镜像替换为在 Docker HUb 上建立的镜像地址即可。如下为一个 Dockerfile 的示例：

Docker Hub 的构建示例如图示：

这里我已经完成了对 release-lite.yaml 不可使用镜像的替换，也放在 github 上了，但只替换了这里需要用到的部分，下面安装 Knative 相关组件的过程如下：

同样几分钟后，所有的 pod 均会变为 Running 状态，如下：

到这一步 Knative 的部署基本完成，我们能看到在整个集群中有那些 pod 及 svc，及他们对应的状态，首先是 Service，如下：

再来看一下 pod，如下：

从上可以看出 pod 的状态基本处于 Running 及 completed，至此 Knative 基本搭建完成，下面开始在 Knative 上跑一下官方的示例。

3. Knative 示例演示

3.1 应用访问演示

按官方提供的示例, 简单修改了 Service.yaml，如下：

下面是此应用的启动过程，如下：

几分钟后，应该会被正常拉起，如下：

下面开始访问此应用，首先找到此服务的IP地址，如下：

可以看到 EXTERNAL-IP 为 状态，大概是因为无外部的 LoadBalancer，因此采用示例中的第二种方式，获取 IP， 如下：

下一步获取服务的访问地址，如下：

访问服务如下：

成功返回了 Hello World: hello, didiyun! 符合预期。

3.2 auto-scaling 演示

上面介绍 Knative 时，提到了其非常重要的一个机制 auto-scaling。这里看一下，上面访问应用一段时间后，hellodidiyun-go 应用的 pod 会慢慢被 Terminate，如下示：

我们重新发起一次请求，然后看一下 pod 的状态，如下：

服务重新启动，符合预期。

4. 结语

以前 Serverless 架构更多只能在公有云上才可运行及使用， Knative 出现后，相信会有更多服务独立维护小的 Serverless 服务，当然 Knative 发布时间不长，问题肯定不少，我们一起来发现它们吧。

本文作者：doop-ymc