TAP 基于 Knative 的 云原生运行时

当前 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:

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 的核心功能和组件

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 的商业化和产品化实现

o VMware 是 Knative 的主要创始成员之一，VMware 一直是主要的贡献者

o VMware 研发团队有专门的全职员工支持 Knative

o Knative 社区的领导力

o Knative steering committee 的 5 名成员中的 2 位来自 VMware

o Brenda Chan and Ville Aikas

o Knative technical oversight committee 的 5 名成员中的 2 位来自 VMware

o Evan Anderson and Dave Protasowski

CNR 核心价值主要从开发者和运维管理角度体现便捷与高效

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

运维和管理角度：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 支持；