写点什么

看 Kubernetes 1.5 之后如何称霸容器编排管理界

  • 2020 年 3 月 09 日
  • 本文字数:0 字

    阅读完需:约 1 分钟

看 Kubernetes 1.5 之后如何称霸容器编排管理界

2014 年,Google 公布开源项目 Kubernetes,它由 Joe Beda、Brendan Burns 以及 Craig McLuckie 带头创建,并于 2015 年 7 月 21 日正式发布 Kubernetes v1.0 版本。

微软 Azure 在 2014 年便引入 Kubernetes 以及 libswarm,开发者可以在 Azure 上使用 Kubernetes 管理 Docker 容器。然而,将 Windows 的应用运行在 Linux 上,或者将 Linux 应用运行在 Windows 上在当时无法实现。

2016 年 12 月, Kubernetes 1.5 的发布,上述 Linux 和 Windows 一起运行的梦想终于得以实现。


微软宣布支持 Kubernetes

Kubernetes 眼下已成为众多容器管理系统核心——比如 CoreOS 公司的商务平台 Tectonic。最近,微软也宣布已将 Kubernetes 整合到其公有云上。


“现在,我们支持 Kubernetes,它会比原来更加好用,并且宣布 Azure 容器服务的预发布版本,”Azure 的计算总监,Corey Sanders 在微软 Azure 发布的时候说道,“对 Kubernetes 本地有更高等级的支持,会为容器编排引擎提供了另外一个开源选择。”


微软也支持 Docker Swarm 和 Mesosphere 的 DC/OS,但是似乎 Kubernetes 更加有掌控容器编排界的趋势。随着事物的发展速度变快,Kubernetes 可能并非容器界的唯一一匹快马,但是它确实是很多厂商的选择。它的地位至此,值得深思。


开源软件公司 Red Hat 的高级产品经理,同时也是决定将 Red Hat 开源 OpenShift PaaS 进行标准化的小组成员之一的 Joe Fernandes 对容器管理系统非常了解。


2013 年,该公司想要创建一个本土的容器管理系统,那时,公司看到了 Mesos,并且跟 Google 讨论 Kubernetes 的开源计划,Joe Fernandes 说,“就功能上来说,Kubernetes 远远超过 Mesos 和 Marathon。”


Gartner 研究副总裁 Richard Watson 说,“这表明微软也希望成为 Kubernetes 生态系统内的重要贡献者。用户期望 Kubernetes 在 Windows 上正常工作,未来能够有 Windows 的集群功能,这对混合环境的 IT 部门很重要。”


Kubernetes 如何从众多容器编排工具中脱颖而出

但是对于 Fernandes 来说同样重要的就是 Google 在容器上的继承,他说,“就像他们之前说的那样,他们运行的所有东西都已容器化。Kubernetes 不是 Borg(Google 的资源编排软件),但是编写 Kubernetes 花费了他们过去使用 Borg 十几年的经验。


另外一个很重要的东西就是(或许对于像 Red Hat 这样的开源公司来说并不意外),Kubernetes 项目现在隶属于 CNCF 旗下,Google 则是开源项目的赞助商之一(在 Fernandes 看来,这绝对是一个加分项)。“我们在 Kubernetes 开源之前就跟 Google 聊过,但是现在 Kubernetes 项目发展很快,有很多厂商支持它,它增加新功能的速度非常快,能够运行很多不同类型的工作负载。”Fernandes 说道。


相比之下,他指出,虽然 Mesos 有 Apache 的支持,但是没有像 Kubernetes 那么多厂商支持。“只有 Mesosphere——虽然有几个厂商确实在云的选择(比如微软)上提供了几个选项。”


Fernandes 认为原因是 Mesos 的代码库不容易拓展,也不容易在它上面创建服务。他说,“我觉得他们的开源社区做得不太好。”


在他认为,Kubernetes 最大的竞争对手是 do-it-yourself 实现方法。但是现实就是,容器领域扩张速度非常快,这也使得实现方法不切实际。


Fernandes 说,“Kubernetes 每年更新 4 次,Docker 每年更新 3-4 次,如果自己动手创建这些解决方法会非常耗时间,所以大多数企业都选择更有效率地创建应用以及让第三方公司来创建编排平台。”


现在有一些容器编排平台供你选择。按照道理来讲,Me sos 和 Docker Swarm 短时间内是不会被淘汰掉的。但是 Kubernetes 也有理由继续扩张式发展。


目前,类似于像 Tectonic 这样的平台,以及完全开源解决方案(比如 OpenShift)都是建立在 Kubernetes 的技术之上的,未来,会有更多的产品(不仅限于上述两种产品类型)选择 Kubernetes 作为底层技术。


Kubernetes 的优势

Kubernetes 并非市唯一的容器管理平台(其他还有 Docker Swarm 或 Mesos 等),但它是行业首选。这是为什么呢?


从一个高层次角度看,Kubernetes 吸引人的一点是它提供了一个平台,实现容器化应用程序的编写并在各类型云基础设施上运行。它将公有云与私有云之间的复杂基础设施差异抽象化。并且,Kubernetes 下一步可以让开发人员运行任何适合在 Kubernetes 运行的应用程序。Box 的合伙人 Sam Ghods 认为只要一个二进制文件可以运行,那它就能在 Kubernetes 上运行。


使用 Kubernetes,开发人员可以快速地部署应用程序,同时无须面对传统平台所具有的风险(想象一下跨多操作系统环境的横向扩展)、动态地扩展应用程序以及更佳的资源分配。


推动 Kubernetes 的另外一个原因,是企业硬件使用率的下降。有些公司报告说,由于容器的轻量特性以及(相比传统架构)更快速杀掉未使用的实体,对硬件的需求降低了 40-50%。eBay 是 Kubernetes 著名的支持者及用户,它声称在转换到该平台后服务器的开销支出急剧减少。


Kubernetes 的最大的优势之一是,它面向的是社区而不是一个技术规范,这让它的功能更加强大。Google 将其作为一个开源项目发布,获得超过 1 千个社区贡献者及 3 万 4 千个提交的支持。其社区比 Mesos(第二大的竞争社区)要大 5 倍,比所有竞争社区加起来还大。


Kubernetes 的弊端:

Kubernetes 在圈内广受赞誉,但是它自身也有缺点。当涉及到(大规模)初始部署的时候,设置起来步骤复杂、操作困难。而且它需要有特殊技能的工程师来操作,这样的人才在现目前的工程领域里还比较难找。


其次,Kubernetes 对于容器来说,是一个第三方管理系统。容器所历经的弊端和成长,对 Kubernetes 所提供的服务也会有影响。


调度器领域现在缺少 Kubernetes。默认设置下,Kubernetes 规划器依赖于由应用程序提出的资源分配需求,并不会考虑实时消耗情况。这样操作,每个节点上会产生资源碎片。


最后一点,能够在容器中运行的负载领域会限制 Kubernetes 被普及,但是这个问题 Kubernetes 眼下还无法解决。鉴于崩溃的倾向,很多工程师犹豫要不要在容器中运行“关键任务”负载,毕竟存储数据并不是容器的设计初衷。惯例是,大家会使用那些在崩溃时不会在容器内引起宕机的应用程序。


Kubernetes 的未来

即使有这样那样的缺点,也不阻挡不了像 Goldman Sachs、Box、SAP 和纽约时报等公司使用 Kubernetes 的步伐,他们将 Kubernetes 平台列入了他们下一个数据中心的计划。


应用程序是很多商务的血液。很多公司正在努力满足日益加快的部署时间和高质量应用程序的需求。这些需求就是开发人员为什么要涌向容器的原因。随着容器技术的爆发,Kubernetes 在市场中也找好了自己的定位。平台领域还有很多潜在性能可以挖掘,但是如果规模变大的还,它是很难管理的。在产品中,初始设置和大规模运行 Kubernetes 之间存在着巨大的鸿沟。在接下来这一年中,第三方管理平台之间的竞争将会很激烈。对于 Kubernetes 来说,不偏离它过去所做的成就显得尤为重要。如果社区能够合理地对平台进行扩容,那么 Kubernetes 的未来将无可限量。


Kubernetes 2017 发展趋势

2016 是 Kubernetes 作为开源容器编排工具在技术圈疯狂圈地的一年。世界范围内成千上万的代码贡献者都在争相为 Kubernetes 贡献功能。越来越多的公司选择 Kubernetes 作为最佳工具,实现在生产环境中容器化微服务的高可用。


版本发布记录:2016 年 3 月 16 日发布 1.2 版,7 月 1 日发布 1.3 版,9 月 27 日发布 1.4 版,12 月 14 日发布 1.5 版:



据上图数据来看,2016 年 Kubernetes 稳定版发布 34 次,发布次数相比 2015 年增加了 112.5%,平均发布间隔为 11 天。2016 年度,K8S 连同 alpha 版和 beta 版共计发布 111 次。



(Kubernetes 2017 版本发布时间线)


2017 年,Kubernetes 预计发布 4 个版本:1.6、1.7、1.8 和 1.9。Github 上显示,1.6 版本将在三月发布,发布频率基本上保持 3 个月一更的状态。据悉,很多应用使用 GPU 可以提升效率,所以 Kubernetes 上游计划在其 1.6 发行版本中加入 GPU 功能,提升应用程序运行效率。(了解详情请点击链接:GPU 在 Docker/K8S/TensorFlow 的应用以及实操经验)


本文转载自才云 Caicloud 公众号。


原文链接:https://mp.weixin.qq.com/s/Eb4S8VTEggZeFbpyM65hMQ


2020 年 3 月 09 日 20:58257

评论

发布
暂无评论
发现更多内容

2021年第4季度记账理财应用监测,头部集聚加强,领跑者转型发展

易观分析

理财 记账

反射解析与使用

Puciu

两行代码助你搞定SAST(静态应用程序安全测试)

极狐GitLab

gitlab security

大数据培训:Spark性能调优与参数配置

@零度

大数据 spark

FabEdge 成为 CNCF 沙箱级项目

BoCloud博云

边缘计算 cncf 开源技术

Flink CDC 项目 GitHub star 破 2000,新增 Maintainer 成员

Apache Flink

大数据 flink 开源 编程 实时计算

如何解决海量数据更新场景下的Mysql死锁问题

领创集团Advance Intelligence Group

MySQL

开源,从一个轮子说起|趣说开源

腾源会

开源 腾源会

业务系统安全工程在阿里的实践|阿里巴巴DevOps实践指南

阿里云云效

云计算 阿里云 云原生 系统安全 研发

1688 复杂业务场景下的 Serverless 提效实践

Serverless Devs

阿里云 电商 1688

围观报名中-2022北京物联网博览会

InfoQ_caf7dbb9aa8a

物联网

2022-03微软漏洞通告

火绒安全

漏洞 漏洞修复 远程代码执行

JavaScript 基础(三):数组和对象

devpoint

JavaScript 数组 对象 3月月更

阿里巴巴监管控一体化运维|阿里巴巴DevOps实践指南

阿里云云效

云计算 阿里云 运维 云原生 研发

低代码和无代码的注意事项

禅道项目管理

低代码 开发 无代码

Docker原理——启动时的icc标志的原理

kof11321

Docker docker网络

为什么要学习togaf的不完全分析

spark

企业架构 架构师 TOGAF 软件架构师

WMS仓储管理系统解决方案

源字节1号

开源 前端开发 后端开发 WMS仓库管理

Redis实现排名

向往自由的太阳花

后端开发

软件商店上新:石墨文档、Shotcut 等 5 款便捷办公类软件上线!

优麒麟

Linux 生态 优麒麟 石墨文档 办公软件

帮助企业实现客户服务自动化的方式

小炮

java培训:22道springboot高频面试题

@零度

JAVA开发 springboot

Go语言使用gorm对MySQL进行性能测试

FunTester

Go MySQL 性能测试 gorm FunTester

看 Kubernetes 1.5 之后如何称霸容器编排管理界_文化 & 方法_才云科技_InfoQ精选文章