博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
2019 年,容器技术生态会发生些什么?
阅读量:5862 次
发布时间:2019-06-19

本文共 2982 字,大约阅读时间需要 9 分钟。

Kubernetes 项目被采纳度将持续增长

作为“云原生”(Cloud Native)理念落地的核心,Kubernetes 项目已经成为了构建容器化平台体系的默认选择。但是,不同于一个只能生产资源的集群管理工具,Kubernetes 项目最大的价值,乃在于它从一开始就提倡的声明式 API 和以此为基础“控制器”模式。

在这个体系的指导下, Kubernetes 项目保证了在自身突飞猛进的的发展过程中 API 层的相对稳定的和一定的向后兼容能力,这是作为一个平台级项目被用户广泛接受和认可的重要前提。更重要的是,Kubernetes 项目为使用者提供了宝贵的 API 可扩展能力和良好的 API 编程范式,催生出了一个完全基于 Kubernetes API 构建出来的上层应用服务生态。可以说,正是这个生态的逐步完善与日趋成熟,才确立了 Kubernetes 项目如今在云平台领域牢不可破的领导地位,也间接宣告了其它竞品方案的边缘化。

与此同时,上述事实标准的确立,也使得“正确和合理的使用了 Kubernetes 的能力”,在某种意义上成为了评判上层应用服务框架(比如 PaaS 和 Serverless )的一个重要依据:这不仅包括了对框架本身复杂性和易用性的考量,也包括了对框架可扩展性和演进趋势的预期与判断。

不过,相比于国外公有云上以 Kubernetes 为基础的容器化作业的高占比,国内公有云市场对容器的采纳程度目前仍然处于比较初步的水平,直接贩卖虚拟机及其关联 IaaS 层能力依然是国内绝大多数公有云提供商的主要业务形态。所以,不同于国外市场容器技术增长逐步趋于稳定、Kubernetes 公有云服务已经开始支撑头部互联网客户的情况,Kubernetes 以及容器技术在国内云计算市场里的依然具有巨大的增长空间和强劲的发展势头。

不难预测,Kubernetes 项目在国内公有云上的逐渐铺开,会逐渐成为接下来几年国内公有云市场上的一个重要趋势。而无论是国内外,大量 Kubernetes 项目相关岗位的涌现,正是验证这个趋势与变化的一个最直接的征兆。

“Serverless 化”与“多样性”将成为上层应用服务生态的两大关键词

当云上的平台层被 Kubernetes 项目逐步统一之后,过去长期纠结在应用编排、调度与资源管理上裹足不前的 PaaS 项目得到了生产力的全面释放,进而在云平台层之上催生出了一个日趋多样化的应用服务生态。

事实上,这个生态的本质与 2014 年之前的 PaaS 生态没有太大不同。只不过,当原本 PaaS 项目的平台层功能(编排、调度、资源管理等)被剥离了出来之后,PaaS 终于可以专注于应用服务和发布流程管理这两个最核心的功能上,开始向更轻、更薄、更以应用为中心的方向进行演进。而在这个过程中, Serverless 自然开始成为了主流话题。

这里需要指出的是,Serverless 从 2014 年 AWS 发布 Lambda 时专门用来指代函数计算(或者说 FaaS)发展到今天,已经被扩展成了包括大多数 PaaS 功能在内的一个泛指术语,即:Serverless = FaaS + BaaS。而究其本质,“高可伸缩性”、“工作流驱动”和“按使用计费”,可以认为是 Serverless 最主要的三个特征。这也是为什么我们会说今天大家所谈论的 Serverless,其实是经典 PaaS 演进到今天的一种“极端”形态。

伴随着 Serverless 概念本身的“横向发展”,我们不难预料到,2019 年之后云端的应用服务生态,一定会趋于多样化,进而覆盖到更多场景下的应用服务管理需求。并且,无论是 Function,传统应用,容器,存储服务,网络服务,都会开始尝试以不同的方式和形态嵌入到“高可伸缩性”、“工作流驱动”和“按使用计费”这三个特征当中。当然,这种变化趋势的原因也不言而喻:Serverless 三个特征背后所体现的,乃是云端应用开发过程向“用户友好”和“低心智负担”方向演进的最直接途径。

而这种“简单、经济、可信赖”的朴实诉求,正是云计算诞生的最初期许和永恒的发展方向。而在这种上层应用服务能力向 Serverless 迁移的演进过程中,不断被优化的 Auto-scaling 能力和细粒度的资源隔离技术,将会成为确保 Serverless 能为用户带来价值的最有力保障。

看得见、摸得着、能落地的“云原生”

自从 CNCF 社区迅速崛起以来,“云原生”三个字就成了各大云厂商竞相角逐的一个关键词。不过,相比于 Kubernetes 项目和容器技术实实在在的发展和落地过程,云原生(Cloud Native)的概念却长期以来“曲高和寡”,让人很难说出个所以然来。

其实,“云原生”的本质,不是简单对 Kubernetes 生态体系的一个指代。“云原生” 刻画出的,是一个使用户能低心智负担的、敏捷的,以可扩展、可复制的方式,最大化利用”云“的能力、发挥”云“的价值的一条最佳路径。而这其中,”不可变基础设施“是“云原生”的实践基础(这也是容器技术的核心价值);而 Kubernetes、Prometheus、Envoy 等 CNCF 核心项目,则可以认为是这个路径落地的最佳实践。这套理论体系的发展过程,与 CNCF 基金会创立的初衷和云原生生态的发展历程是完全一致的。

也正是伴随着这样的发展过程,云原生对于它的使用者的意义,在2019年之后已经变得非常清晰:是否采用云原生技术体系,实际上已经成为了一个关系到是不是要最大化”云“的价值、是不是要在”云“上赢取最广泛用户群体的一个关键取舍。这涉及到的,关系到整个组织的发展、招聘、产品形态等一系列核心问题,而绝非一个单纯的技术决定。

明白了这一层道理,在 2019 年,我们已经不难看到,国内最顶尖的技术公司们,都已经开始在云原生技术框架下发起了实实在在的技术体系升级与落地的“战役”。显然,大家都已经注意到,相比于纠结于“云原生到底是什么”这样意识形态话题,抓紧时间和机遇将 Kubernetes 及其周边核心技术生态在组织中生长起来,并借此机会完成自身基础技术体系的转型与升级,才是这些体量庞大的技术巨人赶上这次云计算浪潮的不二法宝。在这个背景下,所谓“云原生”体系在这些公司的落地,只是这个激动人心的技术革命背后的一个附加值而已。

而在”云原生”这个关键词的含义不断清晰的过程中,我们一定要再次强调:”云原生不等于 CNCF,更不等于 Kubernetes“。云原生固然源自于 Kubernetes 技术生态和理念,但也必然是一个超越 CNCF 和 Kubernetes 存在的一个全集。它被创立的目的和始终在坚持探索的方向,是使用户能够最大化利用”云“的能力、发挥”云“的价值,而不是在此过程中构建一个又一个不可复制、不可扩展的“巨型烟囱”。

所以说,云原生这个词语的准确定义,是围绕着 Kubernetes 技术生态为核心的,但也一定是一个伴随着 CNCF 社区和 Kubernetes 项目不断演进而日趋完善的一个动态过程。而更为重要的是,在这次以”云“为关键词的技术革命当中,阿里巴巴很可能成为”云原生“的一个重要的定义者。

转载地址:http://wygjx.baihongyu.com/

你可能感兴趣的文章
淘宝Refrash_token签名错误的解决办法
查看>>
[NHibernate]Nhibernate如何映射sqlserver中image字段
查看>>
PV、TPS、QPS是怎么计算出来的?
查看>>
用命令创建MySQL数据库
查看>>
vue methods 方法中 方法 调用 另一个方法。
查看>>
[转载] 燃情岁月
查看>>
20155332 第六周课堂实践作业
查看>>
Maya插件开发的几种方式归纳
查看>>
jar包和war包的介绍和区别
查看>>
获取两个经纬度之间的距离,返回值是米
查看>>
Quartz.NET 实现定时任务调度
查看>>
C++ 强制类型转换(转载)
查看>>
LeetCode 947. Most Stones Removed with Same Row or Column
查看>>
【总结整理】2018.03面试
查看>>
stark组件(4):列表定义列,展示数据库数据
查看>>
LA 3902 网络
查看>>
Uva 11294 婚姻
查看>>
ORACLE中判断数据库中的表存不存在
查看>>
Tp3.2 mysql where条件做复合查询
查看>>
2017年12月6日高级软件测试技术例会记录
查看>>