订阅
纠错
加入自媒体

哥本哈根的KubeCon巨浪,要把云计算带向何处

2018-06-06 10:56
来源: CSDN


Service Mesh持续走俏,Istio 引领大潮

企业上云,容器和微服务是两大利器。容器屏蔽了应用对环境的感知,简化了软件包分发的一致性问题,避免重复劳动。而转向微服务的架构,屏蔽了应用对服务的感知,可以使业务团队更专注于自身专业领域。关于如何做负载均衡、熔断和遥测等等问题,都可以通过Service Mesh卸掉。高度的聚焦可以大幅度提高生产力。

Istio作为最有希望成为Service Mesh事实标准的项目,自去年5月份发布以来,凭借与K8S的深度集成、零侵入性、易扩展等优势,加以Google、IBM等大厂商支持,迅速走红。在不到一年的时间里获得了8000+的star,吸引到近200个贡献者参与代码开发,成为去年以来K8S生态中最火热的项目。

而在技术上,早期版本的性能问题也得到了一定程度的改善,p99和p99.9时延有10倍左右的提升,2 vCPU下的最大吞吐量也达到了1700 QPS。大部分场景只有10%左右消耗,已经能够为人们接受。

本次大会中Istio的一大话题是多云和多集群。K8S在多云之间提供了一致的平台环境,但是如何实现跨云、跨集群的服务发现和流量控制却一直悬而未决。在K8S Federation项目中,有一个简单版的实现——本集群优先路由。而Istio在最新发布的0.8版本中提供了多集群支持的特性,补齐K8S在多集群场景下的服务管理能力。

当然,Istio作为一个刚满一年的年轻项目,离生产可用还有一定的距离,但这并不削减人们对其使用的兴趣。有调查显示,已有相当一部分K8S的用户开始在生产中部署使用Istio。相信经过2018年市场的打磨和沉淀,Istio的成熟度会有一个质的飞越。

Serverless领域发布事件标准CloudEvents 0.1

随着云技术的发展和越来越广泛的采用,应用程序变得越来越分散,集成的数量也在不断增长。人们越来越多地发布事件,在各种环境之间传递事件,利用事件驱动的设计模式构建应用。而另一方面,Serverless概念兴起,各大云平台开始提供函数服务(事件驱动计算服务),支持的事件类型也在不断增加。然而,各个平台对于事件的描述却各不相同。开发人员不得不学习、适配各个平台特定的术语和语义。由于逻辑和基础设施缺少一致的信息,开发者难以实现对事件的智能决策处理,事件的传递也因此颇受阻碍。

为了解决Serverless的互操作性问题,CNCF Serverless工作组自去年年底完成白皮书之后,便致力于Serverless事件标准规范—— CloudEvents 的制定。开源玩家包括华为,谷歌,微软,IBM,红帽等,都积极投入其中,为该项目做出了巨大的贡献。

本次大会上发布的CloudEvents 0.1的范围很简单:提供一组一致的元数据,可以将其包含在事件数据中,使事件更容易适用于发布者、中间件、订阅者和应用程序。简而言之,就是一个标准的事件信封。

CloudEvents的通用元数据使得事件更易于路由,扇出,追踪,重放,并且基本保持“在线”。它们更便携,更流畅,更易于跨环境传输。项目同时还在制定适用于每种协议的CloudEvents元数据映射到现有协议的规范。目前,网络带宽,成本和延迟仍然是主要挑战。但CloudEvents简单的元数据定义已经可以在诸多场景中为数据带来不错的可移植性。

聚焦K8S加速创新,Cloud Native编程框架应运而生

众所周知,Kubernetes早在设计之初就做到了架构上的松耦合,在而后的演进中又进行了多处插件化框架和可扩展性的改进和增强。Operator概念的引入,更是标准化了一大部分对K8S有定制扩展需求的场景。

然而,Operator本身的开发、测试、运维等,仍然有一定的门槛。开发者往往是寻找一个现有的Operator实现,刨除原有的业务代码,填入自己应用相关的管理逻辑。完成这个过程往往需要对K8S的API有比较深入的了解,并且具备相当的经验和技术知识。而想要完整地实现Operator的测试和运维,所需的额外工作就更多了。

Operator开发框架旨在归纳已有实现中优秀的实践经验,形成一套标准,来帮助降低K8S上应用程序的开发、测试和运维的门槛。开发框架包含3部分—— SDK、生命周期管理以及监控度量。

Operator SDK提供了开发者构建、测试和封装Operators的工具。生命管理组件提供监督跨Kubernetes集群运行的所有Operator(及其关联服务)的生命周期的安装,更新和管理。而未来几个月内将会实现的监控度量组件,则会提供CPU、内存等基础指标以及自定义指标的监控采集。

Operator开发运维门槛的降低,对那些苦于业务改造上云后运维难、对K8S有定制需求的企业用户来说,是一大福音。

本次KubeCon还带来了一个十分新颖的项目——Ballerina。这是一门用于集成的Cloud Native编程语言。

Ballerina的开发者认为,未来人们编写的应用程序会越来越依赖于API,而集成则是打通各端点间弹性通信的重要规范。因此,他们将分布式系统集成的基本概念融合到语言中,设计了这门编译型、事务性、静态强类型编程语言,并提供了类型安全的并发环境。

Ballerina支持文本和图形语法,除常规的文本编写代码外,开发者还可以通过在设计器中编辑图表来组织代码。这更进一步降低了云原生应用的开发门槛,开发者可以轻松地实现具有分布式事务、可靠消息传递、流处理和工作流的微服务。

大幕拉开,真正的好戏才刚刚开始

过去,面向分布式应用开发,我们看到的是Erlang、容错编程和开发框架等,更多的是绑定于不同的编程社区和软件栈。

现在,我们可以欣喜地看到,Kubernetes凭借着它许多惊艳的特性和庞大的生态力量,已经进入与诸多分布式系统走向商业化相似的发展历程——日渐变得适合日常的开发者,适合日常的企业,最终成为被业界普遍采用的横向技术。

而在以K8S为核心的基座之上,良好的开发监控和运维体验使得创新越来越快。眼下,诸如在微服务治理、机器学习等领域生态中,我们已经可以见到K8S被用作标配的底座和强力的助推器。

在接下来的几年里,市面上各类应用定义工具与服务将呈现爆发式增长,大大简化云上部署运维应用的门槛。毫无疑问,将来如果一个软件不能以某种形式直接或者插件化运行在K8S上,将没有人为它们买单。

未来,K8S的使用门槛将从白盒转向黑盒,开发者甚至不用掌握太多K8S的知识,只需基于一套标准化原语,便可实现分布式系统风格的编程。人们不必在纠结代码如何编译,镜像如何构建,测试与生产环境的配置有何不同,甚至连“kubernetes just run my code”这样的命令都不用执行,寻常的一个代码提交动作便可以触发从编译构建测试到生产运维全流程的交付流水线。而出现问题时的回滚也会是如此的简单,因为代码提交的操作都是原子的。

<上一页  1  2  
声明: 本文系OFweek根据授权转载自其它媒体或授权刊载,目的在于信息传递,并不代表本站赞同其观点和对其真实性负责,如有新闻稿件和图片作品的内容、版权以及其它问题的,请联系我们。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

云计算 猎头职位 更多
文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号