Knative 作为最流行的应用 Severlesss 编排引擎，其中一个核心能力就是其简洁、高效的应用托管服务。Knative 提供的应用托管服务可以让您免去维护底层资源的烦恼，提升应用的迭代和服务交付效率。Knative 的弹性能力可以根据业务实时请求自动扩容或者缩容。您不需要长期保有冗余的 IaaS 资源，实时、灵活的弹性能力非常智能的帮助您节省成本。
在讨论云原生之前我们先来思考一下：为什么企业要上云、为什么技术人员要学习面向云的编程思维以及咱们应该怎么看待云这件事儿。咱们先来剖析一下发生这些事情的核心驱动力，然后通过这个核心驱动力出发看看整个云原生技术栈是什么样子。
我们先从一顿火锅谈起，一顿火锅虽然很简单，但会涉及到非常多的东西，比如各种蔬菜、牛羊肉等。细想一下，所有的这些东西我们都经常食用，但是其中有哪些东西是我们自己亲手种植或养殖的呢？事实上都没有，我们每天都是坐在办公室，下班的路上到市场或超市买到这些东西，不知道也并不关心这些东西的具体生产过程。
我小时候在内蒙的农村长大，大家都知道，内蒙很大。村里每户人家都有一个大园子，夏天的时候家家户户都会在园子里种植各种蔬菜，如西红柿、黄瓜、茄子、辣椒等；但到了冬天，由于天气很冷，根本见不到新鲜的蔬菜，大家吃的都是咸菜、酸菜，或者是秋天晾晒的一些干菜。我们可以发现：一个地域非常容易受到季节的影响，虽然夏天可以种植各种蔬菜，但是到了冬天就什么都没有了。但是现在就不同了，全国各地随处都能非常容易地买到新鲜蔬菜，这其实是社会分工的结果、是不同地域、不同角色之间通过市场相互协作的成果。
现在因为有专业的人在做这些事情，所以我们大多数人都无需劳心蔬菜是怎么种植的。而我们工程师所做的和计算机打交道的事情也能通过其他的渠道反过来帮助那些种菜的人。
分工提高效率，这是现代经济学之父亚当斯密 200 多年前在他的经典著作《国富论》中的开篇观点。其实现代社会的运行机制也印证了该理论；我认为它也是企业拥抱云计算的根本原因。因为大家需要把一些非业务核心的部分“承包”给专业的人士去完成，那些和自己的业务强相关的部分才是企业的核心竞争力。
应用要提供服务首先要有计算、存储和网络资源才能把进程跑起来。当然这些也仅仅是把进程跑起来，如果要承接具体的业务还需要依赖数据库等服务；如果要做分布式架构还需要做微服务拆分，这时候就需要缓存、注册中心、消息各种中间件的服务。
以上的情况都是程序已经存在，如何把程序跑起来承接业务的部分。还有一部分是如何把代码变成可启动的程序，这就是 CI/CD 部分了。从代码到应用启动再到应用依赖的周边系统支撑都说完了，还有一部分就是日常运维相关的：
虽然我们本来只是想要写一个应用，来为业务提供服务。但是应用周边的这些支撑系统比这个应用自身的消耗还要高上很多。这其实不是我们期望的结果，让业务团队更多的聚焦在业务逻辑本身，而不是周边的这些系统上，这才是我们希望看到的。
实际上有一定规模的公司，内部的组织架构基本也都是由一个基础平台团队和多个业务团队构成的，基础平台团队负责提供这些应用需要的公共能力支撑，业务团队更聚焦在业务上，直接使用基础平台团队的能力即可。这其实就是社会分工在 IT 组织中的体现，专业的人做专业的事儿，分工提升效率。
如果时间倒退 20 年，回到北方的冬天，我们想要吃一顿有肉、有蔬菜、还有金针菇的火锅，根本就不可能，但是现在，我们可以随时随地买到这些东西，而所有这些都是专业的人士生产的，我们无法自给自足这么丰富的资源。
那么对于一家企业而言，也是一样的。虽然每个企业都有自己的基础平台团队，但是由于规模或者资金投入等原因，不可能提供像云这么丰富的平台支撑。如果有，那一定也是一个云厂商。所以对于业务来说，把所有和应用相关的周边系统都使用云的初始设施搭建，把这些周边系统承包给云厂商才是高效率的做法。我理解为这就是云原生出现的背景。
分工提高效率这是大家使用云的根本动力。云原生理念是在各大企业上云的过程中逐渐形成和完善的。这套理念是协调所有参与方对服务上云逐渐形成的统一标准，这个统一的标准可以很好地帮助企业上云、帮助云厂商释放云的能力。从云的客户角度来讲，这个统一标准就是避免云厂商锁定。比如 Kubernetes 就是一个非常好的统一共识，因为所有云平台都支持 Kubernetes。
那么这个标准的价值是什么呢？为什么云厂商和上云的企业都积极参与这个标准的“制定”呢？这其实是一个互利互惠的结果。在具体谈论这个标准的作用之前，我们先来聊聊两种资源分配模式的差别。
去医院看病需要提前挂号，医生的号源这是一种先到先得的资源分配方式。特别是在北上广这些大城市，好医生的号源更是一号难求。如果想保证一定要拿到某个医生的就诊号，就要保证比别人都更早地到医院排队，提前排队可以优先拿到就诊号。我们现在来分析一下，提前排队的人所付出的努力都有什么价值。
对于排队的当事人：当事人付出的努力对于自己是有意义的，自己拿到了就诊号，得到了回报；
对于其他的排队者而言，是没有任何好处的。早来的人拿到了就诊号，这就给别的竞争号源的人发出了一个信号——来的越早就越有可能得到号源。这有可能引发更多人更早的前来排队，这是一个恶性循环；
对于医生来说，没有任何意义，谁来看病都是一样，谁得到这个号对医生来说差别不大。很多时候甚至患者要求加号，但医生其实是不愿意的，因为每增加一个号源就意味着医生要付出一点儿休息的时间。对于医生而言，多付出的休息时间是不能换来更多报酬的，因为这是一个先到先得的排队秩序规则，每一个号源的价格都是一样的。
有没有发现在排队的过程中所做出的付出只对排队的当事人是有意义的，对于医生以及其他排队者都没有任何意义，甚至会带来恶性竞争，造成社会资源的巨大浪费。在排队的过程中，大量的资源都白白地流失，没有给社会带来任何价值。
假设目前阿里云的 ECS 是性价比最高的，大家上云都优先选择使用阿里云的 ECS，那么如果出现供不应求的情况就可能会导致 ECS 价格上涨，而价格上涨就会导致更多的云厂商供应 ECS ，最终导致价格又回落下来。我们分析一下在这个过程中购买 ECS 的人和提供 ECS 的云厂商之间的关系：
我们发现大量客户选购 ECS 这件事情本身对于上云的客户是有益无害的，因为大量的需求会导致云厂商做更多的供应，价格不可能持续高攀。所以 ECS 需求的竞争者之间其实不是零和博弈，而是一个相互合作的关系。大家一起把饼做大，就让整个供应链更稳定、便宜。就好比我买苹果手机，你也买苹果手机，但是咱俩不是竞争关系，而且买的人越多，苹果手机的质量就会越来越好；
大量的 ECS 需求会促使 ECS 技术的成熟。对于 ECS 的提供者云厂商而言，越多的人购买自己的服务就越好，所有的客户和云厂商之间都是相互促进的关系。
市场经济这种基于价格的自由交易能够非常高效地促进大家的合作，任何一方的努力对于其他的参与者而言都是有价值的。和医院排队中先到的人付出的努力只对自己产生价值相比较，市场经济的自由交易方式中，每一方的付出都让整个系统得到了优化，这是社会资源合理利用、合理分配的一种非常好的方式。
是不是感觉扯远了，这和云计算有什么关系？我们继续来剖析一下市场经济，就可以看到和云计算的密切关系了。
我们先来看一下这个场景：如果云厂商 A 提供的服务性价比很高，但是有一天云厂商 B 提供了性价比更高的服务，客户会不会立即把服务迁移到云厂商 B 上去？答案是客户想要迁移，但是比较难迁移。因为每一个云厂商提供的服务标准都不太一样，服务迁移的过程需要适配大量差异化的底层基础设施，这给迁移带来了巨大的成本，甚至抵消了云厂商 B 提供的高性价比，所以平常比较少见到这种迁移。
前面咱们分析了市场经济的资源分配方式是非常有利于社会各方面资源进行最优配置的，可是如果云客户不能在云厂商之间低成本的流动，其实就很难选择性价比高的云厂商。所以从有效配置社会资源这个角度来分析，现在迫切需要一个能够让客户在不同云厂商之间低成本“流动”的体系，而这就是云原生的意义所在。
如果把客户要在云上托管的应用比喻成水的话，那么云服务的价格就是海拔的高度。哪里海拔低，水就很自然的流到哪里去。无限降低迁移的成本，对于客户和云厂商来说都是非常有价值的一件事情。云原生旨在以标准化云服务的提供方式衔接云厂商和客户。这种方式对于客户而言降低了上云和跨云迁移的成本，让客户始终保有和云厂商议价的能力；对云厂商而言，因为客户跨云迁移的成本低，所以只要能提供性价比更高的云服务，就能很容易的聚集大量用户。
云原生是在不断促进整个系统的良性循环：既能让客户始终保有选择的能力，又能让优秀的云厂商快速服务更多的客户。如果客户的业务服务能像水一样低成本在不同云厂商之间流通，那么云厂商提供的服务就能像货币一样在客户之间流通。这是一个多赢的局面。
说完云原生这个理念，我们来看一下云原生应用，以及在云原生的这个大背景下，如何看待传统的应用架构？
无论是云上的应用，还是云下的应用，其实依赖的核心要素都没有变，只是这些核心要素的提供形式发生了变化。
如上图所示，共有 7 个核心要素。这 7 个要素中日常运维这一块其实不是强依赖的，虽然它对业务的稳定性影响极大，但是这并不是业务跑起来的核心链路，没有这些业务也能跑，而其它的几块都是核心链路。那么我们就来看一下在云原生架构下，这些核心链路的要素都处于什么位置？然后剖析一下云原生应用的基本范式。
我们先来看看最右边的中间件这一块，里面有数据库、Redis 以及消息中间件组件。而这一块其实是应用代码里面直接调用的，并且这里包含的所有能力都有标准的协议，比如无论是使用 SQL Server 还是使用 MySQL，我们程序里都可以使用 SQL 规范进行操作。这部分其实早就被标准化了。
如图所示，计算、存储和网络这三个核心要素已经被 Kubernetes 层统一了。很多云服务已经实现了计算、存储和网络资源的无服务器化，比如阿里云的 ECI 和 ASK（Aliyun Serverless Kubernetes）。那么还有两块 CI/CD 和应用托管没有标准化，这就是应用编排这一层需要标准化的事情。Serverless 其实不单单是无服务器，还包括应用本身的编排，这也是应用编排这一层的价值所在。
Serverless Kubernetes 已经提供了 Pod 的无服务器支持，而应用层想要用好这个能力其实还有很多事情需要处理。
我们发现虽然基础资源可以动态申请，但是应用如果要做到实时弹性、按需分配和按量付费的能力还是需要有一层编排系统来完成应用和 Kubernetes 的适配。这个适配不单单要负责弹性，还要有能力同时管理流量和灰度发布。
上文中的内容就是 Knative 要解决的问题，这也是 Knative 出现的背景。接下来咱们来看看 Knative 。
我们先看看官方给出的定义：“基于 Kubernetes 平台，用于构建、部署和管理现代 Serverless 工作负载”。Knative 就是基于 Kubernetes 的应用 Serverless 编排系统。实际上 Knative 包含的不单单是 Workload，它还有 Kubernetes 原生的流程编排引擎和完备的事件系统。
前面提到 Kubernetes 实现了计算、存储和网络的标准化，而 Knative 目标基于 Kubernetes 提供了应用 Serverless 工作负载编排的标准化。
Knative 由三个核心模块构成：Tekton、Eventing 和 Serving：
Tekton 是 Kubernetes 原生的流程编排框架，主要用于构建 CICD 系统；
Eventing 主要负责事件处理功能，可以接入外部系统的事件，事件接入以后进行一系列的流程处理以及触发 Serving 消费事件；
Serving 是应用运行工作负载的核心管理模块，主要负责流量调度、弹性以及灰度发布等职责。
T
ekton 是一套 Kubernetes 原生的流程编排框架，主要用于构建 CICD 系统。比如从源码编译成镜像，以及对镜像里的服务进行测试、把镜像发布成应用等一系列的操作都可以基于 Tekton 完成。
Task 里面可以包含多个顺序执行的 Step。一个 Task 最终就是一个 Pod，里面的每一个 Step 最终执行的时候就是一个 Container 。每提交一个 TaskRun CRD 到 Kubernetes 就会触发一次 Task 的执行；
Pipeline 可以编排多个 Task，Pipeline 中的 Task 是可以设置依赖关系。Pipeline 会根据依赖关系生成一个有向无环图，然后生成的根据有向无环图并发或者串行执行一系列的 Task。每提交一个 PipelineRun CRD 就会触发 Pipeline 的一次执行；
PipelineResource 代表 Pipeline 使用或者生成的资源，比如：github 代码仓库、依赖或者使用的镜像等等；
Tekton 是 Kubernetes 原生的实现，所以资源鉴权的秘钥等信息都可以通过 Kubernetes 的 Secret 进行管理。
Eventing 模块基于 CloudEvent 标准实现了一系列的事件处理机制。Eventing 模块的核心能力分成四大块。
外部事件接入，Eventing 有很强的扩展机制，可以接入任何外部事件源的事件，比如 github 里面的 commit、pull request 等事件；Kubernetes 里面的事件；消息系统里面的消息；以及 OSS、表格存储、Redis 等系统的事件。
CloudEvent 标准，Eventing 接入外部事件以后会转换成 CloudEvent 格式，事件在内部的流转都是通过 CloudEvent 事件标准完成的。
事件在内部的处理，Eventing 模块引入的 Broker 、Trigger 模型，不仅将事件复杂的处理实现给用户屏蔽起来，更提供了丰富的事件订阅、过滤机制。
事件处理事务管理，Eventing 基于可靠的消息系统，可以对事件进行事务管理。如果事件消费失败可以进行重试或者重新分发等操作。
Serving 核心的 CRD 就是 Service，Knative Controller 通过 Service 的配置自动操作 Kubernetes 的 Ingress、K8s Service 和 Deployment 从而实现简化应用管理的目标。
Knative Service 对应一个叫做 Configuration 的资源，每次 Service 变化如果需要创建新的 Workload 就更新 Configuration，然后每次 Configuration 更新都会创建一个唯一的 Revision，Revision 可以认为是 Configuration 的版本管理机制。理论上 Revision 创建完以后是不会修改的，不同的 Revision 一般用于灰度发布。
Route 是 Knative 管理流量的核心逻辑，Knative 是建立在 Istio 之后的，Knative Route Controller 通过 Route 的配置自动生成 Istio 的 VirtualService 资源，从而实现了流量的管理。
Knative Serving 对应用 Workload 的 Serverless 编排是从流量开始的。
流量首先达到 Knative 的 Gateway，Gateway 根据 Route 的配置自动把流量根据百分比拆分到不同的 Revision 上，然后每一个 Revision 都有一个自己独立的弹性策略。当过来的流量请求变多的时候当前 Revision 就开始自动扩容。每一个 Revision 的扩容策略都是独立的，相互不影响。
基于流量百分比对不同的 Revision 进行灰度，每一个 Revision 都有一个自己独立的弹性策略。Knative Serving 通过对流量的控制实现了流量管理、弹性和灰度三者的完美结合。
Kubernetes 是业界公认的云原生操作系统，作为云原生的 Serverless 编排引擎 Knative 当然是兼容 Kubernetes API 的。
Knative 本身就是开源的，你可以在任何 Kubernetes 集群上面部署一套 Knative 。同样，你在任何 Knative 集群里面的服务都可以无缝迁移到另外一个 Knative 集群。如果你的服务是搭建在 Knative 之上，那么你的服务就可以像水一样在各个云厂商流通，任何一个云厂商的 Kubernetes 搭建好 Knative 就能轻松地把你的服务部署起来。咱们透过下面这个支持列表可以看到 Knative 已经被大量的厂商或平台支持：
Google 的 CloudRun 是基于 Knative 的[1]
IBM 公有云已经支持 Knative[2]
阿里云已经支持 Knative[3]
Pivotal 的 Riff 是建立在 Knative 之上的 FaaS 系统[4]
OpenShift 的 Knative 支持[5]
Rancher RIO 是基于 Knative 的[6]
KubeFlow 社区基于 Knative 的 KFServing，正在用 Knative 做 AI 相关的框架[7]
云原生的力量就在于此，开放的标准得到了广泛的支持。作为使用云的客户，基于这种开放的标准其实就是始终保有和服务商议价的权利，哪里的服务好就到哪里去，否则就有可能会被一家锁定。对于云厂商而言，通过开放的标准可以接入更多的客户，而这个标准之下的具体实现，每家都会根据自身特点进行支持，这也是云厂商的核心竞争力。
介绍了这么多，接下来咱们就捋一捋 Knative 都适合在哪些场景中使用。
Knative Serving 从流量入手对应用进行 Serverless 编排。
首先 Knative 基于 Istio Gateway 来接管服务的流量，可以做到按百分比对流量进行切分。切分的流量可以直接用于灰度发布，比如把按百分比切分的流量直接转给一个 Revision，精准地控制每一个 Revision 承接的流量百分比，从而达到精准控制灰度版本对线上服务应用的范围。
Knative 的弹性策略是作用在每一个 Revision 之上的，不同的 Revision 根据“自己的节奏”独自伸缩，实现了从流量到灰度灰度再到弹性这三者的完美结合，所有应用弹性托管诉求都可以通过 Knative 来实现。下面这些场景非常适合使用 Knative 来解决：
比如托管微服务应用
比如托管 Web 服务
比如托管 gRPC 服务
Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各个外部系统的事件。事件接入以后通过 CloudEvent 标准在内部流转，Broker/Trigger 机制给事件处理提供了非常好的方式。
这套完备的事件系统可以比较容易的实现事件驱动的服务，比如：
基于 Tekton 构建 CI/CD 系统等，比如：
基于 Knative Servering 部署服务，你就无需手动操作 Kubernetes 资源，这样可以大大降低使用 Kubernetes 的门槛。所以如果不是维护 Kubernetes 系统、或者要基于 Kubernetes 做复杂的开发，就可以使用 Knative 来管理自己的服务，非常便捷。
阿里云 Knative 现在都有哪些典型的客户案例？
Web 托管服务其实就是前面介绍的 MicroPaaS 类型的场景，客户使用 Knative 是为了简化使用 Kubernetes 的复杂度。即便不使用 Knative 的弹性也可以带来应用托管效率的提升。
微服务托管场景
Web 应用托管和弹性
电商服务后台
基于任务队列的弹性伸缩
使用 ECI 做弹性，有效降低长期保有资源的成本
把 Knative Service 的地址注册到注册中心，通过 Knative 的能力实现微服务的流量切分、灰度发布和弹性。这样 Knative 就给普通的微服务应用赋予了 Serverless 能力。
https://help.aliyun.com/document_detail/126413.html
https://github.com/knative-sample/cloud-native-go-weather
缩容到零的场景 http://weather-web.default.live.kuberun.com/#/
https://tracing-analysis.console.aliyun.com/#/appList/cn-shenzhen
registry.cn-hangzhou.aliyuncs.com/knative-sample/weather-detail:limit-v1
hey -z 60s -c 30 http://weather-web.default.live.kuberun.com/api/city/detail/010/2019-12-05
helm install ./chart --name live-weather --namespace live
helm delete live-weather --purge
Q：
开发怎么远程调试 Kubernetes 中的应用？
A：Kubernetes 底层首先是一个容器，那咱们就从容器谈起。容器相对于宿主机来说其实只是把业务进程限制在一个更合理的权限范围内，在调试容器里面的业务进程时可以直接 docker exec 到容器内。到了容器内部就和一个 VM 没有什么差别了。而 Kubernetes 的 Deployment 可以认为是编排很多容器，每一个容器都可以通过宿主机 docker exec 进去。当然也可以通过 Kubernetes 的方式 kubectl exec 到容器内进行调试。如果实在初期调试阶段建议使用比较完整的 CentOS 或者 Ubuntu 镜像，基础镜像内要有一些基本的调试工具。摸索熟悉了之后可以使用精简的基础镜像，这样更经济。
Q：
Knative 的 build 和开发流程管理可以代替 Jenkins 吗？
A：Knative 的 Build 现在是 Tekton 。Tekton 本身的定位不是替换 Jenkins，它的核心理念是建立在 Kubernetes 生态之上。比如 Pod 的执行力度，每一个 Pod 内可以包含很多容器，每一个容器是一个 step，这样我们就可以使用不同的镜像驱动容器，每一个容器内部的环境都是可以完全自定义的。并且容器之间以及 Pod 之间共享资源都是通过 Kubernetes 的模式提供的。另外我们知道 CI/CD 系统一般都会被运维系统集成，在被集成的的场景中 Tekton 的优势是比较大的。Tekton 是可以通过 Kubernetes API 进行操作的，而 Jenkins 的 API 以及设计理念都是需要单独学习的，这些都是成本。核心还是在于 Kubernetes 这个生态比较强大，而未来的趋势 Kubernetes 将是一个必备技能。在这个大环境下掌握 Tekton 的成本就更低，向前看 Tekton 正在成为主流。
Q：
Knative 编排和 Kubernetes 应用编排的区别及应用场景?
A：Kubernetes 的最大价值是把对 IaaS 资源的操作标准化了，比如无论是在 AWS 还是在阿里云上面使用计算、存储、网络等资源，都可以直接通过 Kubernetes 语义完成，不需要关系不同厂商底层差异化的实现。而 Knative 才是面向应用的编排。Knative 对应用的 Serverless 编排主要体现在：对流量、灰度策略以及弹性的管理，并且流量、灰度和弹性这三者是完美契合在一起的。从另一个角度来说 Knative 是建立在 Kubernetes 之上的，Knative 需要使用 Kubernetes 提供的对 IaaS 的标准化服务。这二者是上下层的依赖和被依赖的关系，不是竞争关系。
A：在阿里云上面已经有很多用户在使用了。另外 Google 的 CloudRun 产品完全是建立在 Knative 之上的。
A：Knative 现在已经被众多厂商开始支持了，Knative 的目标是标准化应用 Serverless 编排模型。比如：通过 Knative 对应用进行编排、通过 Knative 支撑上层 FaaS 系统实现。这里说的应用其实不限于在线服务，很多 AI 任务也是通过 Knative 驱动的，比如分享中提到的 KFServing。
Q：
感觉 Knative 就是另一种形式的配置即服务，和 Jenkins X发展的异同？
A：Knative 是一个应用 Serverless 编排引擎，可以快速给普通应用赋予 Serverless 能力。比如流量、灰度和弹性的完美结合。另外 Knative 的事件模型可以对接外部事件做基于事件驱动的 Serverless 模型。
Q：
Istio 层面的管控和维护成本比较高，如 Envoy 性能问题，网络问题等，这部分工作是由云平台负责的吗，Knative 这边有没有相应措施？
A：目前阿里云容器服务 Kubernetes 集群控制台可以通过 UI 管理 Istio 和 Knative，可以快速上手。控制台也提供了很多便捷操作降低运维成本。Knative 主要依赖了 Istio 的 Gateway，Gateway 本身是可以横向扩展的，不会有太大影响。
A：Knative 是建立在 Kubernetes 之上的，Knative 组件其实就是 CRD 的 Controller。在 Kubernetes 中 Controller 是可以部署多个实例，通过抢锁保证只有一个 Controller 可以执行写操作。
https://cloud.google.com/run/
https://cloud.ibm.com/docs/containers?topic=containers-serverless-apps-knative
https://help.aliyun.com/document_detail/121508.html
https://projectriff.io/
https://www.openshift.com/learn/topics/serverless
https://rio.io/
https://github.com/kubeflow/kfserving
基于Kubernetes的DevOps实战培训将于2019年12月27日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。
