当前CNCF主导的云原生以及相应生态发展如火如荼，企业IT和研发部门都在花大力气尝试通过K8S进行微服务应用的部署、编排和生命周期的管理，进而解放开发和运维，使开发者真正聚焦在业务代码的设计开发和创新上。但是实际具体落地的过程中都受到了巨大挑战。
首先是K8S的复杂性。开发和运维部署应用时，使用者至少深入学习和掌握下面几个部分，而每个部分又会关联引出更多的K8S知识点。
此外，还包括以下生产环境中实际相关的问题：
- K8S应用部署后怎么访问？找谁配DNS和负载均衡？
- 怎么实现灵活的部署模式，比如蓝绿、灰度、A/B测试、按微服务版本，进行比例限流等？
- 容量规划总是估不准，只好估高点，多留点buffer，资源利用率过低会不会有问题？但如果估算的过低，到时不够的话，扩容快不快？
因为以上的诸多问题，企业用户通常在自行构建基于开源Kubernetes实现的容器平台上碰到诸多繁琐的配置和运维工作，并时常会因为手动操作带来很多潜在的问题。
VMware推出第三代云原生平台Tanzu Application Platform – TAP，是面向企业级的PaaS平台解决方案；而TAP的云原生应用运行时抽象层 - Cloud Native Runtimes（CNR），能够帮助提升应用开发者和应用运维者效率，有效地解决在本文中刚开始时提到的诸多环境配置和运维相关联难题，通过自动化的平台方式，能够大大降低用户的使用复杂度：
图中红色标注部分就是Cloud Native Runtimes。
作为TAP平台运行时基础层,当前版本是version1.2。其中Knative Runtime和K8S Jobs作为核心基础已经生产就绪，Batch Runtime和Stream Runtime是路线图中的规划。CNR本身独立发布，并且内置包含在TAP的发布包。Knative是CNR的核心之一，下面首先介绍一下无服务器运算Serverless和Knative，以及Cloud Native Runtimes在此基础上的集成和增强。
Serverless无服务运算和Knative
在大型软件系统设计和规划中，增加抽象层是其中一种经典方法。如下所示,虚拟化->容器->K8S->Serverless的抽象层的引入对业务、开发和运维提供积极的促进。
Serverless是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以API接口的方式供给用户按需调用，真正做到按需伸缩。目前业界公认的无服务器架构主要包含两个方面， FaaS和BaaS-Backend as a Service:
- 函数即服务（Function as a Service）
函数即服务，是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施。开发交付更加敏捷，资源利用更加高效。
- 后端即服务（Backend as a Service）
BaaS的概念涵盖范围较广，覆盖了应用有可能依赖的所有第三方服务，如云数据库、对象存储等服务。开发人员通过API集成所需的后端功能，不必管理虚拟机或容器等基础设施。BaaS服务大多有云服务商提供，目前常见的BaaS服务包括：数据库管理,云存储,用户认证,推送通知,远程更新,消息队列等。
传统的 Serverless 方案优点很明显，但平台和服务均由云厂商负责维护，使无服务器架构的厂商绑定现象非常严重。目前存在以下问题：
- 缺乏统一标准。呈现碎片化，各家都有各自的实现。
- 厂商锁定。比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品。
- 应用迁移或多云成本极高。
此时伴随K8S的广泛应用和探索,Knative受到国内外大厂关注，其定位是基于 K8S的 Serverless 解决方案，旨在标准化 Serverless，简化学习成本。Knative目前已成为CNCF孵化项目，后续生态和前景必将更加广阔。
Knative两个关键组件：Serving（服务）和Eventing（事件）。
Serving（服务）：基于负载自动伸缩，包括在没有负载时缩减到零。允许你为多个修订版本（revision）应用创建流量策略，从而能够通过 URL 轻松路由到目标应用程序。
Eventing（事件）：使得生产和消费事件变得容易。抽象出事件源，并允许操作人员使用自己选择的消息传递层。是事件驱动开发的一种实现。
Cloud Native Runtimes的核心功能和组件
Cloud Native Runtimes（CNR）的核心是Knative，并提供工具集成和能力扩展。它提供了一个Runtime运行时层，即支持用户使用K8S Deployment和Service,也可以使用Knative Serving, Scale From/To Zero,Eventing和Streaming等。
如图所示，
1) CNR包括核心Knative Serving、Eventing，并且继续提供Streaming和Batch多种类型Runtime支持；
2）CNR与Contour，Avi和Tanzu Service Mesh有很多好的集成，提供高级Ingress的能力（默认安装使用Contour作为Ingress Controller）；
3）CNR提供Eventing集成支持vSphere Events,AWS Events，RabbitMQ，Kafka。默认使用IMC(InMemoryChannel);
4）TAP中的CNR提供通过Carvel和TanzuBuildService集成做打包、部署；
5）最后，我们可以看到CNR底层是基于VMware TKG或者其它云服务厂商的K8S发行版本。
我们一起回顾下Knative Serving和Eventing的主要能力：
1.Serving：目标是为 Kubernetes 提供扩展功能，用于部署和运行 Serverless 工作负载。Knative Servic管理Routes和Configuration,Route负责将流量根据需要指向Revision的实例。可缩放至零、请求驱动的计算运行环境。
Knative Serving 与Activator和Knative Pod Autoscaler共同完成自动扩缩、从零扩展和缩减到零等能力和控制。对于预热、Graceful shutdown， window-size都有考虑和设计。
2.Eventing：提供用来使用和生成符合 CloudEvents 规范的事件的构建块。它包括对来自事件源的信息流的抽象，以及通过由可插拔发布/订阅代理服务提供支持的消息传递通道实现交付解耦
Cloud Native Runtimes社区影响力和核心价值
Cloud Native Runtimes 是开源方案Knative的商业化和产品化实现
- VMware是Knative的主要创始成员之一，VMware 一直是主要的贡献者
- VMware 研发团队有专门的全职员工支持Knative
- Knative 社区的领导力
-
Knative steering committee 的5名成员中的2位来自VMware
- Brenda Chan and Ville Aikas
-
Knative technical oversight committee 的5名成员中的2位来自VMware
- Evan Anderson and Dave Protasowski
CNR核心价值主要从开发者和运维管理角度体现便捷与高效
开发角度：大幅提升开发和部署业务逻辑代码的效率
| 通过K8S进行应用开发者需要学习掌握并管理： |
通过CNR/Knative进行应用开发者需要学习掌握并管理: |
| Pods Deployment Process Rollout Progress Labels and selectors Service (networking model) Ingress |
Pods CNR/Knative Service |
运维和管理角度：CNR优化运维和Admin的体验
- 通过请求驱动的自动扩缩容来管理和控制基础设施成本；
- 按照软件程序的代码版本来划分流量的测试部署；
- 通过Carvel简化部署；
- 集成Ingress(Contour/Avi/Tanzu service mesh)和 Eventing(RabbitMQ,kafka或AWS Events,vSphere Events)
- 提供企业级的7x24技术支持保证
Cloud Native Runtimes的关键场景
1.自动发布URL，CNR自动完成DNS和负载均衡的配置
TAP平台的云原生运行时CNR通过Knative Runtime自动生成Route，直接通过域名访问，可以在界面监控应用负载的运行时资源对象的状态信息。自动完成Source2URL，开发者无需管理K8S中Ingress/Service/Deployment/Label等资源对象。
通过TAP GUI查看资源使用和资源对象状态,可以从应用层面理解从应用->Knative资源对象->K8S资源对象，各个层面看到关联关系。
2.实现灵活的容器应用部署模式，并且方便的提供流量分配和控制
TAP平台CNR包括K8S Runtime和Knative Runtime等支持，无论是微服务还是函数应用，或事件驱动架构的应用，都能部署。您可以:
- 通过K8S的deployment yaml直接定义和部署应用；
- 也可以通过Knative service创建应用服务；
- 亦或是TAP的workload去创建应用
而且利用Knative高层抽象比如service和revision就能实现零停机部署；多版本部署；按比例分配流量等部署和流量相关场景。下图中可见设置流量比例和执行结果。
3.基于资源和实际请求负载算法的自动扩缩容
CNR除了简单的通过资源使用情况CPU/MEM等进行扩缩容，更多是通过请求的负载压力算法进行自动扩缩容。包括：从零扩容（Scale From Zero）；缩容到零（Scale To Zero）；设置服务扩缩容的上限和下限参数（比如配置Pod数量最少为1个,min=1，max=5）；Auto-Scaling等。并可以通过CNR命令行或者TAP界面应用运行详细页面进行观测。
下图示左侧用siege或hey工具持续以200个并发来连续发送请求，图示右侧窗口可以看到在tap-tanzu-java-web-app-0006这个应用的Deployment中的Pod数量会根据流量压力增加到1,2,3个Pods。整个过程完全根据流量和Pod状态通过算法，进行自动调度扩缩容；当流量发送停止，Pod数量会从3，2，1逐渐降低直至为零。
结论
VMware Cloud Native Runtimes是Tanzu产品组合中的重要基础软件，是TAP产品的核心云原生应用运行时基础。特点总结如下几个方面：
展望与发展
Cloud Native Runtimes将伴随着K8S、Knative和TAP演进和发展,不断满足企业环境下云原生应用的构建、运行和管理需求。
- 不断完善对于TAP的支持和集成，更好的融合buildservice能力；
- 提供和完善Streaming,Batch等Runtime；
- 更多类型Event Sources支持，比如Azure，GCP Event Sources；
- 结合TAP平台支持Streaming Supply Chain,Batch Supply Chain；
- 基于Tanzu Service Mesh的CNR Routes支持；
敬请期待和试用最新版本CNR！
参考
1: Knative community, https://knative.dev/docs/
2:Knative in Action, JACQUES CHESTER
3: Gartner,Innovation Insight for Internal Developer Portals https://tanzu.vmware.com/content/analyst-reports/innovation-insight-for-internal-developer-portals
4: Cloud Native Runtime Document
5: 13 challenges creating an open, scalable, and secure serverless platform
6: Proposal for Autoscaling of Knative Eventing
7: https://tanzu.vmware.com/content/blog/join-cloud-native-runtimes-vmware-tanzu-serverless-public-beta
作者：刘鹏
VMware资深云原生应用架构师，20年软件开发设计和产品管理经验。在VMware/Pivotal之前曾就职于IBM中国实验室、Oracle、大唐电信和Ericsson等国内外IT企业，从事企业级平台和云计算相关软件的系统架构、产品管理和研发等工作。具有丰富的电信和银行、交通等行业经验。拥有Spring Core professional, Kubernetes CKA, AWS Solution Architect, CloudFoundry和软件架构师认证，目前主要专注企业级PaaS和容器云平台产品及云原生微服务应用架构设计。
来源｜公众号：VMwareTanzu云原生