系列文章:
总目录索引：九析带你轻松完爆 Knative 系列教程
目录
1 前言
2 邀约
3 Knative 简介
4 Knative Serving 架构
4.1 Configuration 对象
4.2 Route 对象
4.3 Service 对象
4.4 Revision 对象
4.5 Knative serving 各组件之间关系
1 前言
如果你对博客有任何疑问，请告诉我。
2 邀约
你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料：
3 Knative 简介
上小节中介绍 Knative 0.17.0 版本中主要组件有 Serving 和 Event。这节简要介绍一下 Serving 组件。
Serving 组件是让应用运行起来并提供服务，其中包括：
自动启动和销毁容器
自动生成网络访问的 service、ingress 对象（这些原来需要运维编写相关 Yaml 文件）
监控应用的请求，根据请求自动进行扩缩容（这些原来需要运维指定 K8S HPA）
使用 k8s 管理应用是一件比较辛苦的事情，尽管 k8s 针对容器编排已经非常方便，但是仍然会有很多手工、重复性工作。比如，需要根据源码创建镜像（无论是手动编写 Dockerfile 还是通过工具创建流水线）、创建 deployment 对象、创建 service 对象、创建 ingress 对象。经过上述操作才可以最终将服务暴露给外部用户使用，而且有时还需要手动创建 HPA 对象来响应容器的扩缩容策略。
Knative 提供了更简单的操作接口，使得只通过一个 Knative service 对象就可以轻松完爆上述整个流程。
下图展示了一个 Knative service 用例：
执行如下命令创建 Knative service 对象。如果要让整个 Knative 起作用，前提是已经安装好 Knative，安装过程可以参考本人上节内容。
kubectl apply -f knative-svc.yaml
执行结果如下所示，注意是 ksvc，而不是 svc，前者是 Knative 对象，后者是 K8s 对象：
部署好 Knative service 对象之后，就可以直接通过 curl 进行访问了，而不像以前 k8s 管理一样，需要手动创建 deployment、service、ingress 对象后才可以访问。访问结果如下所示：
是不是更方便了？惊不惊喜？开不开心？意不意外？
Knative Serving 组件是如何做到这一步的？这里需要介绍一下 Knative Serving 架构。
4 Knative Serving 架构
下图是 Knative Serving 架构图：
执行 kubectl apply -f knative-svc.yaml 后，会同时生成 Knative Service、Configuration、Route 和 Revision 对象。下面分别介绍这些对象。
4.1 Configuration 对象
Configuration：应用的配置对象，也就是应用目前期望的状态，你可以对标 k8s 的 deployment 对象。每次应用升级都会更新 configuration，而 Knative 同时也会保留历史版本记录（revision），结合流量管理，Knative 可以让多个不同版本共同提供服务，方便蓝绿发布和滚动升级
你可以执行如下语句来查看 Knative configuration 对象：
kubectl get configurations.serving.knative.dev -n helloworld
命令执行结果如下图所示：
4.2 Route 对象
应用的路由规则，也就是进来的流量如何访问应用，对应了 Istio 的流量管理（Virtual Service）
你可以执行如下语句来查看 Knative Route 对象：
kubectl get routes.serving.knative.dev -n helloworld
命令执行结果如下图所示：
4.3 Service 对象
注意，这里的 Service 对象不是 k8s 提供服务发现的那个 Service，而是 Knative 自定义的的 CRD，它的全称目前是 serving.knative.dev/v1。单独控制 route 和 configuration 就能实现 serving 的所有功能，但 Knative 更推荐使用 Service 来管理，因为它会自动帮你管理 route 和 configuration
Knative Serving 和 k8s 的 pod 定义非常类似，但是它会帮你管理 deployment、ingress、service discovery、auto scaling... 等资源，从这个角度来看，Knative Serving 自动帮你封装了 k8s 和网络层（Istio、Kourier等）的实现细节。
执行如下结果查看 Knative service 对象：
kubectl get ksvc -n helloworld
命令执行结果如下图所示：
4.4 Revision 对象
可以通过执行如下指令查看 Revision 对象：
kubectl get revisions.serving.knative.dev -n helloworld
命令执行结果如下：
4.5 Knative serving 各组件之间关系
由上图可知：
每个 Revision 对应一组 deployment 管理的 pod
pod 自动汇报 metrics 给 Autoscaler 组件，Autoscaler 会根据请求量和资源使用情况修改 deployment 的 replicas 数量，从而实现自动扩缩容。serverless 一个重要的特性是它可以缩容到 0，也就是当没有流量访问时，它会自动销毁所有的 pod
Activator 组件作用是当 revision 的 pod 缩容到 0 时，route 流量就会指向 Activator，Activator 接收到请求之后会自动拉起 pod，然后把流量转发过去
route 对象决定访问应用的流量如何路由
来源：oschina
链接：https://my.oschina.net/u/4365856/blog/4545419