Serverless Kubernetes 落地实践
作者:元毅
导读
Kubernetes 作为当今云原生业界标准,具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付标准,使得云资源交付变的越来越简单,与此同时用户期望更多的聚焦于业务自身,做到面向应用交付,Serverless 理念也因此而生。那么如何通过原生 Kubernetes 提供 Serverless 能力?如何借力丰富的云原生社区生态?这里给大家介绍一下我们在 Serverless Kubernetes 上的落地实践。本文将从以下 3 个方面展开介绍:
- 为什么要做Serverless Kubernetes
- 如何实现Serverless Kubernetes
- Serverless Kubernetes 落地实践
为什么要做 Serverless Kubernetes
Kubernetes
众所周知,Kubernetes 是一款开源容器化编排系统,用户使用 Kubernetes 可以做到降低运维成本、提高运维效率,并且提供标准化 API,某种意义就是避免被云厂商绑定,进而形成了以 Kubernetes 为核心的云原生生态。可以说 Kubernetes 已然成为了云原生业界事实标准。
Serverless 与 Kubernetes
那么我们回到 Serverless 上面来,Serverless 的核心理念在于让开发者更聚焦业务逻辑,减少对基础设施的关注。那么我们如何在云原生业界标准之上做 Serverless,Kubernetes 是否也能做到更专注于应用业务逻辑。
Kubernetes 做 Serverless 有哪些优势
我们来看一下 Kubernetes 做 Serverless 有什么优势。先看一下 Kubernetes 特性包括哪些:
- 容器化
- 统一 IaaS 资源交付
- CI/CD 持续集成部署
- 跨云厂商
- 丰富的生态
- 面向应用管理
而对应于 Serverless 来说
- 事件驱动:Kubernetes 支持 job 类型、并围绕 Kubernetes 提供丰富的事件源
- 按需使用:Kubernetes 本身支持 hpa 弹性能力
- 免运维、高可用:Kubernetes 可以通过容器化、统一资源交付很好的支持。
结合这些来看 Kubernetes 实现 serverless,天然具备优势。
如何实现 Serverless Kubernetes
在 Kubernetes 上实现 Serverless 主要做到一下两点:
第一:向下如何让用户减少对基础设施的关注;
第二:线上如何更聚焦业务应用。
这里我们通过 Serverless Framework ,聚焦业务应用,进一步抽象 Kubernetes 资源,提供按需使用自动弹性的能力。通过 IaaS 资源免运维,减少对基础设施的关注,做到节点免运维。
那么 IaaS 资源免运维,我们是如何做的呢?
减少对基础设置的关注:IaaS 免运维
原生的 Kubernetes 节点资源需要用户自行维护,为了降低用户维护节点成本,我们提供了托管节点池,帮助用户维护节点的生命周期,但用户还是需要对托管节点池策略进行维护,更近一步在 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 Kubernetes 落地方案:围绕 Kubernetes api, 下线集成云产品的能力,包括消息事件、弹性容器实例以及日志监控等。向上通过 Knative 围绕应用为核心,提供事件驱动、自动弹性等能力。
典型应用场景
最后看一下我们有哪些落地场景,典型的应用场景及行业领域如图:
落地实践:异构资源,按需使用
- 客户痛点
用户希望通过 Serverless 技术按需使用资源,节省资源使用成本,简化运维部署 。另外有 GPU 的业务诉求。希望使用容器化的 Serverless ,支持使用 GPU 资源,同时简化应用运维部署(尽可能少的操作 Kubernetes deployment/svc/ingress/hpa等资源),IaaS 资源免运维。
- 解决方案
使用 Knative + ASK 作为 Serverless 架构。数据采集之后,通过服务网关访问数据处理服务,数据处理服务根据请求量按需自动扩缩容。
落地实践:事件驱动,精准分发
某客户直播系统支持用户在线互动。消息数据的处理主要有以下技术挑战:
- 业务弹性波动,消息并发高。
- 互动实时响应,低延迟。
客户选择阿里云的 Knative 服务进行数据的弹性处理。应用实例数随着业务波峰波谷实时扩容和缩容,真正做到了按需使用,实时弹性的云计算能力。整个过程完全自动化,极大的减少了业务开发人员在基础设施上的心智负担。
小结
我们回顾一下本文介绍的主要内容:首先介绍了为什么在 Kubernetes 提供 Serverless:
- Kubernetes 已成为云原生业界标准
- 面向标准 Kubernetes API 进行 Serverless 编程
然后我们如何实现 Serverless Kubernetes:
- IaaS 节点免运维
- Serverless Framework (Knative)
最后介绍了 2 个落地实践场景:
- 异构资源,按需使用
- 事件驱动,精准分发
一句话:Serverless Kubernetes 基于 Kubernetes 之上,提供按需使用、节点免运维的 Serverless 能力,让开发者真正实现通过 Kubernetes 标准化 API 进行 Serverless 应用编程,值得关注。
点击此处,即可查看 1204 Serverless Developer Meetup 详情!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
云原生 Serverless Database 使用体验
作者:李欣 近十年来互联网技术得到了飞速的发展,越来越多的行业加入到了互联网的矩阵,由此带来了更为丰富且复杂的业务场景需求,这对于数据应用系统的性能无疑是巨大的挑战。 关系型数据库 MySQL 是应用系统中最广泛使用的数据库产品,拥有强大的数据查询和强事务处理能力。在如今的云时代,应用系统逐渐演进到基于云原生 Serverless 架构去进行搭建,因为它具有低成本、高弹性的优势。但基于 MySQL 的数据存储在 Serverless 架构体系下仍存在一些明显的不足: 弹性扩展能力差。Serverless 场景中一个重要特点是应用负载具有显著的波峰波谷。当面临流量洪峰时,DBA 又需要手动对集群进行扩容以避免集群被打爆;而适逢流量低谷时,则需要对集群进行缩容以节省成本。 运维复杂度高。MySQL 搭建需要进行购置集群、安装服务、管理连接。业务上线后还要关注数据安全、服务可用性、响应时间等等,用于集群运维的时间占比会变高,无法把更多的精力专注于业务研发上。 成本高。通常 DBA 需要预估业务规模来事先设定数据库初始容量,当业务请求量未达到预估值时,集群中的资源会一直处于闲置状态,造成资源浪...
-
下一篇
运维的线上系统故障总结
线上故障是一件让人很“紧张”的事情,之所以用紧张这个词,是因为暂时找不到更好的词汇描述遇到时的心态。 对于运维人员来说,出现故障,可能意味着: 失职、麻烦、质疑、加班、绩效、无尽的报告等负面词汇,但也意味着: 机会与挑战。前者大家都好理解,后者也是很重要的,为什么呢? 故障的机会与挑战 一、有一部分故障是大家都没有预料到的。 个人对故障的发生是不用担责的,只需要善后就可以这种。 比如机房突然断电了这种大故障,来电后各种毛病就出现了,开不了机、服务启不起来、启动顺序又不对、配置丢了、网络不通、数据异常等等。 这种情况就非常锻炼人啦,只要出现过一次,一般你之后就会对此项目的全局掌握比较清晰了,并且一般遇到这种大场面,也正是展示你台下十年功露脸的最好时机,但可遇不可求。 小故障当然也有学习的价值,遇到得越多,对经验的提升和以后对问题的全面分析能力都有帮助。 二、有一部分故障是个人操作失误导致的。 我们经常说,人总是会犯错的嘛,但这样自言自语说多了后就会让人产生懈怠、疏忽,经历或个人导致故障后,成长更快。 说一个小故事,我在之前一个项目组时,几乎每个人都有造成过线上故障,于是一旦新人来后,我都...
相关文章
文章评论
共有0条评论来说两句吧...