Serverless Kubernetes 落地实践

导读

Kubernetes 作为当今云原生业界标准，具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付标准，使得云资源交付变的越来越简单，与此同时用户期望更多的聚焦于业务自身，做到面向应用交付，Serverless 理念也因此而生。 那么如何通过原生 k8s 提供 Serverless 能力？ 如何借力丰富的云原生社区生态？这里给大家介绍一下我们在 Serverless Kubernetes 上的落地实践。本文将从以下 3 个方面展开介绍：

• 为什么要做Serverless Kubernetes
• 如何实现Serverless Kubernetes
• Serverless Kubernetes 落地实践

为什么要做Serverless Kubernetes

Kubernetes

众所周知，Kubernetes 是一款开源容器化编排系统，用户使用K8s 可以做到降低运维成本、提高运维效率，并且提供标准化API, 某种意义就是避免被云厂商绑定，进而形成了以K8s为核心的云原生生态。可以说K8s已然成为了云原生业界事实标准。

Serverless 与 Kubernetes

那么我们回到Serverless上面来，Serverless 的核心理念在于让开发者更聚焦业务逻辑，减少对基础设施的关注。那么我们如何在云原生业界标准之上做Serverless， k8s 是否也能做到更专注于应用业务逻辑。

Kubernetes 做 Serverless 有哪些优势

我们来看一下K8s做Serverless 有什么优势。

先看一下k8s特性包括哪些：

• 容器化
• 统一IaaS资源交付
• CI/CD持续集成部署
• 跨云厂商
• 丰富的生态
• 面向应用管理

而对应于Serverless来说

• 事件驱动：K8s 支持job类型、并围绕K8s提供丰富的事件源
• 按需使用：K8s  本身支持hpa 弹性能力
• 免运维、高可用：K8s可以通过容器化、统一资源交付很好的支持。

结合这些来看 k8s 实现serverless，天然具备优势。

如何实现Serverless Kubernetes

在Kubernetes上实现Serverless 主要做到一下两点：

第一：向下如何让用户减少对基础设施的关注

第二：线上如何更聚焦业务应用

这里我们通过Serverless Framework ，聚焦业务应用，进一步抽象K8s资源，提供按需使用自动弹性的能力。通过IaaS资源免运维，减少对基础设施的关注，做到节点免运维。

那么IaaS资源免运维，我们是如何做的呢？

减少对基础设置的关注：IaaS免运维

原生的K8s 节点资源需要用户自行维护，为了降低用户维护节点成本，我们提供了托管节点池，帮助用户维护节点的生命周期，但用户还是需要对托管节点池策略进行维护，更近一步在Serverless Kubernetes 中通过虚拟节点结合弹性容器实例ECI，让用户彻底摆脱对IaaS的运维。

Serverless Kubernetes IaaS 资源免运维包括：

• 基于容器，安全隔离、高移植
• 无服务器管理：无需容量规划，对服务器免运维
• 弹性扩容：秒级扩容，无限容器
• 按需付费，更高资源利用率

向下我们通过虚拟节点结合ECI实现了IaaS资源免运维，那么向上如何聚焦业务逻辑呢？其实就是以应用为核心。

聚焦业务逻辑：以应用为核心

围绕应用来看，无非我们要解这些问题：

• 应用部署
• 灰度发布
• 流量管理
• 自动弹性
• 可观测性以及应用的多版本管理。

那么有开箱即用的方案去解吗？答案是Knative

Knative 是什么

Knative是基于 Kubernetes 之上提供的一款开源 Serverless 应用框架，帮助用户部署和管理现代化的 Serverless 工作负载，打造企业级 Serverless 平台。

Knative具备如下优势：

• 在几秒钟内建立可扩展、安全、无状态的服务。
• 具有更高级别 Kubernetes应用抽象的API。
• 可插拔组件，让您可以使用自己的日志记录和监控、网络和服务网格。
• 在 Kubernetes 运行的任何地方都可以运行 Knative，无需担心供应商锁定。
• 开发者无缝体验，支持 GitOps、DockerOps、ManualOps等。
• 支持常用工具和框架，例如 Django、Ruby on Rails、Spring 等。

Knative 主要包括 2 大核心模块：Serving 和 Eventing

Serving提供了Service应用模型，支持基于流量的灰度发布、版本管理、缩容到0以及自动弹性。

Eventing 提供事件驱动能力。支持丰富的事件源，以及用于事件流转、过滤的Broker/Trigger模型。

为什么是Knative

那么我们为什么选择Knative呢？

根据 CNCF 2020 中国云原生调查报告，Knative 已经成为 Kubernetes 上最广泛安装的无服务器.

另外 Knative 社区近期也发起了一项统计：当前哪些云厂商或企业在提供或者使用 Knative。我们可以看到，几乎所有的大厂都支持或者集成 Knative, 如阿里云、谷歌云、IBM、Red Hat等，并且大部分都提供了生产级别能力（Production），这些迹象表明越来越多的用户拥抱 Knative。

此外近期 Knative 已申请成为 CNCF 孵化项目，这无疑让 Knative 开发者为之兴奋。

Knative 落地挑战、应对与效果

从开源到产品化落地，必然会面对一些挑战。Knative 产品化落地主要面对如下挑战：

• 管控组件多，运维复杂
• 0到1冷启动问题
• 流量请求1对1分发

那么我们如何来应对呢？

我们提供组件托管，帮助用户节省资源及运维成本；当请求为0时，缩容到低规格保留实例，实现请求 0 到 1 免冷启动，做到成本可控；提供自研事件网关，做到流量的精准控制。

Serverless Kubernetes 落地实践

落地方案

结合上述介绍，向上通过Serverless Framewok Knative更聚焦业务应用，向下通过虚拟节点减少对基础设施的关注。这就是我们Serverless K8s 落地方案：围绕K8s api, 下线集成云产品的能力，包括消息事件、弹性容器实例以及日志监控等。向上通过 Knative 围绕应用为核心，提供事件驱动、自动弹性等能力

典型应用场景

最后看一下我们有哪些落地场景，典型的应用场景及行业领域如图：

落地实践：异构资源，按需使用

• 客户痛点

用户希望通过 Serverless 技术按需使用资源，节省资源使用成本，简化运维部署 。另外有 GPU 的业务诉求。希望使用容器化的 Serverless ，支持使用 GPU 资源，同时简化应用运维部署（尽可能少的操作 k8s deployment/svc/ingress/hpa等资源），IaaS资源免运维。

• 解决方案

使用 Knative + ASK 作为 Serverless 架构。数据采集之后，通过服务网关访问数据处理服务，数据处理服务根据请求量按需自动扩缩容

落地实践：事件驱动，精准分发

某客户直播系统支持用户在线互动。消息数据的处理主要有以下技术挑战：

•业务弹性波动，消息并发高。

•互动实时响应，低延迟。

客户选择阿里云的Knative服务进行数据的弹性处理。应用实例数随着业务波峰波谷实时扩容和缩容，真正做到了按需使用，实时弹性的云计算能力。整个过程完全自动化，极大的减少了业务开发人员在基础设施上的心智负担

小结

我们回顾一下本文介绍的主要内容：

首先介绍了为什么在 Kubernetes 提供 Serverless：

• K8s 已成为云原生业界标准
• 面向标准 K8s API 进行 Serverless 编程

然后我们如何实现 Serverless  Kubernetes：

• IaaS 节点免运维
• Serverless Framework (Knative)

最后介绍了2个落地实践场景：

• 异构资源，按需使用
• 事件驱动，精准分发

一句话：Serverless Kubernetes 基于 Kubernetes 之上，提供按需使用、节点免运维的 Serverless 能力，让开发者真正实现通过 Kubernetes 标准化 API 进行 Serverless 应用编程，值得关注。

欢迎有兴趣的加入以下钉钉交流群：

     

参考

【CNCF 2020中国云原生调查报告】https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020/

【Knative社区使用情况统计】https://github.com/knative/community/blob/main/ADOPTERS.MD