Knative 介绍
knative 是谷歌开源的 serverless 架构方案，旨在提供一套简单易用的 serverless 方案，把 serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018年7月24日才刚刚对外发布，当前还处于快速发展的阶段。最近刚发布了0.14版本。
我们本次以 0.11 版本为例，讲解 knative 中的 serving 和 eventing。Knative 之前还有的镜像构建模块 build 来实现 CI/CD，目前已经依赖于 tekton 项目：https://github.com/tektoncd/pipeline
Knative 的整体架构如下所示
由上图可知，knative 是在 kubernetes 之上的，istio 是 service mesh,但是knative 只使用到了 knative 的网关功能，所以在这里可以简单理解为等同于 kubernetes 上的 ingress controller。
Istio-gateway 的组件如下所示：在这里我们不会详细讲解 istio-gateway 的内容，只需要知道，两个组件，istio-ingressgateway 就是网关组件，这个是对外的网关，cluster-local-gateway 是内部的 istio-gateway。
在正确部署了 kubernetes 和 istio 之后，就可以根据官网的部署 knative yaml 文件直接部署。knative 是在 k8s 之上的应用，它的所有组件都是以 deployment 的形式部署的，部署成功之后，所有组件如下所示：
各个组件的大体意思如下：
1、Controller 是 Knative 对应资源的控制器，其本身的功能跟 k8s 中其他的组件的实现类似，根据资源的当前状态和期望状态来进行一致性调整，从而实现最终一致性
2、Autoscaler 是 Knative 中实现自动扩容的关键，其通过 Activator 和 Queue 两个组件传递过来的监控数据并根据配置来计算，实时动态的调整业务容器的副本数量，从而实现自动伸缩
3、Activator 容器是缩容至零的关键，当业务容器没有访问的时候，Knative就会将对应的 ingress 流量指向 Activator 组件，当缩容至零的时候，如果此时有业务请求，Activator 会立即通知 autoscaler 立刻拉起业务容器，并将流量转发真正的业务容器，这样既可以完成流量的无损转发，又可以实现按需付费，再也不用为没有访问量的业务，一直启动着 Pod 了, Activator 并不负责实际的伸缩决策，伸缩组件主要是通过Autoscaler 来实现
4、Knative 是基于 k8s 的 CRD 实现的，其 webhook 主要包含对应资源数据的验证和修改等 admission 相关
环境部署好之后，接下来我们就开始部署一个 knative 服务，它的名字也是 Service,但是它跟 k8s 里原生的 Service 不是一个意思，所以一般会称之为 ksvc。
Knative 服务部署
创建一个最简单的 hello-world 服务：
如上图所示：它的apiVersion和kind是关键，其他的内容跟我们部署一个deployment 类似，下面的配置就是 meta 和 pod 的信息。
创建之后，我们来看一下效果：
我们使用命令 kubectl get ksvc 就可以查看创建的 ksvc 资源的内容，从左到右分别展示了 ksvc 的名字，访问服务的地址，服务状态是否 Ready。
默认状态是没有 pod 启动的，pod 会在有请求的时候，才会去创建并接收请求。
Kubectl get po 发现是不会有相应的 po 正在运行。
如何访问服务呢？要以网关作为入口进行访问。也就是访问 istio,访问的时候，将域名指向 istio gateway 就可以了。
我们要访问 istio-ingressgateway,它就是我们访问服务的入口。
Istio 已经以 nodeport 启动，
第一次访问有，pod 的过程，会慢一些，第二次访问，就会快了。因为第一次访问的时候，会先启动 pod,然后再去响应。
time curl -H "Host: helloworld-go.default.example.com" http://10.254.156.233
Knative ksvc 创建过程
到目前为止，我们创建了一个 knative 服务，并正确请求了这个服务。我们知道，在 k8s 上创建一个 deployment 资源，会自动的去启动 pod。那在创建 ksvc 之后，后台会有什么操作的？如下图所示：
当我们创建 ksvc 之后，后台会创建另外两种资源：route 和 configuration.
像 ingress 为 ingress controller 提供路由信息一样，route 是提供路由信息给istio-gateway.
Configuration 是服务的配置，如果修改 ksvc 的内容，就产生不同的 revision,每一个 revision 都对应着一个 deployment,当然 deployment 的 replicas 的数量是0。Deployment 的内容是无法通过 kubectl edit 来修改的，knative 会自动的根据请求来调节 replicas 的数量。
如果我们更新 ksvc 的内容，cofiguration 就会生成第二个 revision。
有多个 revision 就可以进行灰度发布等。
我们一起看一下它们各自的内容：
Kubectl get route
Kubectl get configuration
Kubectl get revision
Kubectl get deployment
我们可以看到 route 和 configuration 的名字是一样的，revision 的名字开始有不同。
Configuration,revision 和 deployment 的 spec 是一样的。
那么在 kubernetes 底层，请求是如何转发到 pod 里的呢？当有请求的时候，是如何启动 pod 并接受请求的呢？
我们知道，如果是 k8s 的 ingress controller,是转发到 svc 的，knative 也是，但是会有不同：如下所示，在创建一个 ksvc 后，会创建三个 svc,其中 ExternalName 类型的 svc 会在 eventing 模块用到，主要是下面两个 svc 在起作用：
我们看一下其他两个 svc 的区别：名字不一样，端口不一样
我们看一下 svc 的 endpoint
其中有一个 svc 有 ep,另外一个没有，因为这个时候还没有 pod 创建所以，这个 ep 地址，是哪个 pod 的呢？
那我们来看一下它的 endpoint:
由此图可知，172.30.168.2这个地址，是 activator 的 pod 的地址，所以，当我们请求，服务的时候，请求会到达 activator。
curl -H "Host: helloworld-go.default.example.com" 10.254.156.233:31380
当我们执行完上述命令后，再来看一下 ep 的变化。
Ep变成了别的地址，而这个地址，就是刚启动的 hello-world 的地址：
所以初次请求的流程如下所示：
持续请求过程：
我们看到实际启动的 pod 里是有两个容器的，容器里的内容是什么样子的呢？
在启动后，pod 里会有两个容器，一个是 queue-proxy,一个是我们真正启动的容器。
通过上图，我们也可以看到，我们启动的容器，必须以 8080 端口启动，否则请求无法真正的传入容器中。
在了解了 knative 的一些基本知识之后，我们来介绍一下 knative 的一些特性：
1、 扩缩容
虽然上面我们讲了在第一次请求服务的时候，autoscaler 扩容 pod 数量，但是当有请求书不断变化的时候，autoscaler 是如何调整 pod 的数量的呢？
它是由几个参数共同作用的：
根据上述几个数值的设定，和真实的服务请求数量，流量会有不同的路径：
扩容的频率也会有两种模式：
当然，如果当某个服务不再有请求的时候，pod 的数量就会变成 0
2、 版本管理
我们编辑 ksvc,会自动生成一个 revison,
我们把返回的内容改成另外一个名字。
再次请求服务的时候，返回了如下：
我们把 ksvc 的 tracffic 部分改成如下所示：
再次调用服务的时候，就会发现，服务的输出内容会有变化。
这也是 knative 进行服务版本管理和流量管理的方式。
3、 控制 pod 的最大和最小数量
4.29细说
