首先是 K8S 的复杂性。开发和运维部署应用时，使用者至少深入学习和掌握下面几个部分，而每个部分又会关联引出更多的 K8S 知识点。

此外，还包括以下生产环境中实际相关的问题：

·K8S 应用部署后怎么访问？找谁配 DNS 和负载均衡？

·怎么实现灵活的部署模式，比如蓝绿、灰度、A/B 测试、按微服务版本，进行比例限流等？

·容量规划总是估不准，只好估高点，多留点 buffer，资源利用率过低会不会有问题？但如果估算的过低，到时不够的话，扩容快不快？

因为以上的诸多问题，企业用户通常在自行构建基于开源 Kubernetes 实现的容器平台上碰到诸多繁琐的配置和运维工作，并时常会因为手动操作带来很多潜在的问题。

图中红色标注部分就是 Cloud Native Runtimes。

作为 TAP 平台运行时基础层,当前版本是 version1.2。其中 Knative Runtime 和 K8S Jobs 作为核心基础已经生产就绪，Batch Runtime 和 Stream Runtime 是路线图中的规划。CNR 本身独立发布，并且内置包含在 TAP 的发布包。Knative 是 CNR 的核心之一，下面首先介绍一下无服务器运算 Serverless 和 Knative，以及 Cloud Native Runtimes 在此基础上的集成和增强。

在大型软件系统设计和规划中，增加抽象层是其中一种经典方法。如下所示,虚拟化->容器-> K8S -> Serverless 的抽象层的引入对业务、开发和运维提供积极的促进。

Serverless 是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩。目前业界公认的无服务器架构主要包含两个方面， FaaS 和 BaaS-Backend as a Service:

1)  函数即服务（Function as a Service）

函数即服务，是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施。开发交付更加敏捷，资源利用更加高效。

2)  后端即服务（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（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 是开源方案 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 核心价值主要从开发者和运维管理角度体现便捷与高效。

开发角度：大幅提升开发和部署业务逻辑代码的效率。

运维和管理角度：CNR 优化运维和 Admin 的体验。

·通过请求驱动的自动扩缩容来管理和控制基础设施成本；

·按照软件程序的代码版本来划分流量的测试部署；

·通过 Carvel 简化部署；

·集成 Ingress(Contour/Avi/Tanzu service mesh)和 Eventing(RabbitMQ,kafka 或 AWS Events,vSphere Events)；

·提供企业级的 7x24 技术支持保证。

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 产品的核心云原生应用运行时基础。特点总结如下几个方面：