澳门新葡亰信誉平台游戏盘点:十二“发行版Kubernetes”,引领容器革命!

by admin on 2020年2月3日

开源推动者与 Android 专家 Jack
Wallen 近日发表了一篇文章,预测了未来的开源局势,他认为
2020
年的开源前途一片光明。

Kubernetes和容器正在改变应用的构建、部署和管理方式。以下这些发行版正在引领这一变革。
如果你需要大规模的容器编排,就可以借助Kubernetes这个项目。这个出自谷歌的开源容器编排系统备受好评,不仅得到了良好的支持,而且发展势头迅猛。

作者:木环、易立

澳门新葡亰信誉平台游戏 1

尽管如此,Kubernetes仍存在庞大、复杂,并且难以搭建和配置的问题。不仅如此,它还将许多繁重的工作留给了终端用户。因此,最好的方法是不要自己单独去尝试它们,而是寻找一个含有Kubernetes的完整的容器解决方案。在这个解决方案中,Kubernetes会被作为组件得到支持和维护。

编辑:小智

Image: Getty Images/iStockphoto

我在这里列出了12个最具知名度的Kubernetes解决方案,它们实际上是整合了Kubernetes和容器工具的发行版,也就是由众多厂商推出的带有Linux内核和用户层的发行版。

时至今日,IT 圈已经进化到开源与商业不再剑拔弩张的时代。

Jack 总结了以下几个方面:

需要注意的是,本文重点关注的是可在本地运行或可被云托管的软件发行版,不包括如亚马逊EKS或谷歌Kubernetes引擎等专用的云服务。

澳门新葡亰信誉平台游戏,1.时至今日,没有人质疑容器技术的未来

1、Deepin Linux 将改变开源格局

Deepin 15.11 计划发布一项功能——Deepin Cloud Sync,该功能可能会改变 Linux
发行版的版图。 

此功能会将选择的系统设置同步到云中,例如可以安装操作系统的另一个实例,将其连接到
Deepin Cloud Sync
帐户,然后让该操作系统的新实例自动同步设置。想象一下,部署多个桌面实例将节省多少时间。结合使用
Deepin 桌面的华丽程度,使用者体验将会很好。Deepin Linux
将会引起轰动,将成为许多使用者最喜欢的发行版。

CoreOS Tectonic

现在,没有人会否认容器技术的作用与地位。2013 年 Docker
问世,热度迅速蹿升并被大范围使用,如此势头在开源界当属少见。

2、预装 Linux 的机器会更多

这将有助于 Linux
提升其市场份额,甚至可能首次达到接近两位数的水平,相信会有更多的 OEM
厂商开始销售预装 Linux 的计算机。目前已经有
System76、Dell、Pine64、Lenovo、ThinkPenguin 与 Star LabTop 等,到 2020
年底,预计不仅预装 Linux 的小型 OEM 会增加,也有一些较大的 OEM。预计
Acer、HP 与 ASUS 都会加入竞争。

CoreOS提供了专注于容器的Linux发行版,并且可以与Docker兼容,不过它有着自己的镜像格式和运行环境。与此同时,还提供了一款企业级Kubernetes发行版。两者一起共同构成了CoreOS
Tectonic堆栈的基础。

DataDog 连续三年发布 Docker 问卷调查,2017 年报告显示 Docker
的采用率上升 40%。

3、开源将主导其企业

在企业业务中,开源无处不在,它在云、容器、大数据、物联网、边缘计算等领域中都是基础。目前 Linux
在企业领域中尚待征服的是台式机。

到 2020 年底会有改变,原因是安全。预计 Windows
勒索软件攻击将再次增加,这将导致一些企业寻找更可靠的替代方案,也就是
Linux。意识到多少工作流和工作能力依赖于开源的公司也可能会推动这一转变。

CoreOS操作系统Container
Linux与众不同,主要是因为它们被作为一套容器化组件交付。这样一来,操作系统的自动更新可以在不影响应用正常运行的情况下顺畅地进入到生产环境中。CoreOS还表示他们可以对Kubernetes进行一键更新。CoreOS
Tectonic可以在亚马逊网络服务、微软Azure和裸机上运行。

调查数据显示 2015 年起就有不少大型公司已经开始尝试使用 Docker,并且近
60% 的企业宣称使用 Docker 的机器规模超过 500 台,不过 100-499
台规模的使用比率也获得了显著上升。有分析认为 Docker
的出现在早期解决的是大公司痛点问题,而现在 Docker
正在寻求成为各类公司的通用平台技术。

4、Docker 将反弹

这里说的是 Docker 项目而不是 Docker 公司。2019 年对
Docker 来说并不好,Kubernetes 成为了首选的容器编排工具,但是相信 Docker
将会有一些发展,这些发展可能包括更强大、友好的
swarm 工具或新的客户端工具,以使编排容器集群变得容易。

能够使得 Docker 复出的原因是易于管理,随着 Kubernetes
变得越来越强大,它也变得越来越复杂,如果 Docker
可以在保持其功能和灵活性的同时恢复简单性,则它将重新获得一些市场份额。

Canonical 版的Kubernetes发行版

Sysdig 调查了 4.5 万个企业,统计显示平均每台机器上会运行 10
个容器实例,甚至有企业在一台机器上启用 95 个容器实例。当 Docker
逐渐生产环境中不可或缺的部分之后,势必要寻求工具更高效地管理和编排这些容器。目前市面上被广为熟知的编排方案是
Kubernetes、Mesos、Amazon ECS、Google Engine 等,而 Docker
也推出了自己的原生系统编排方案。

5、开源自动化将令人恐惧 

由于推动了更高效率的 CI/CD 管道的发展,我们见证了令人印象深刻的自动化技术的兴起。借助
Helm、Terraform 和其它以 Kubernetes
为中心的工具,可以创建可自我更新、测试代码并且在出现问题时不将其推向生产的系统。 

到 2020
年,开源自动化将接近科幻小说的程度,其系统会自行“思考”,并且我们将首次体验一种基于经验(来自
AI)和预测进行自我优化的系统。最大的问题是:这些系统将与任务隔离多远,一旦它们通过某个未知事件范围,我们是否能够将其关闭?

Ubuntu
Linux的开发商Canonical也推出了自己的Kubernetes发行版。Canonical版的Kubernetes发行版的一大卖点是它们立足于已得到广泛推崇并部署的Ubuntu
Linux发行版。Canonical称,其堆栈可以在任何云端或本地运行,并且支持由CPU和GPU驱动的工作负载。付费用户可以让Canonical工程师远程管理他们的Kubernetes集群。

2.Kubernetes vs Docker Swarm 两股流派

6、NVIDIA 将展示其 Linux 的巨大惊喜

NVIDIA 宣布在 2020 年将为 Linux 推出一个很大的惊喜,相信 NVIDIA
计划做这样的事:为 Nouveau 驱动程序做贡献,或者开源其官方 NVIDIA
驱动程序。NVIDIA 看到了很多东西,而加入 Linux 是前进的唯一途径。 

对于 Linux 来说,这将是一个巨大的胜利,其原因有两个:Nouveau
驱动从未如此出色地用于游戏;如果 NVIDIA 开始为 Nouveau
驱动做出贡献或将其官方驱动开源,那么这可能是 Linux
台式机游戏的福音,并且可以推动 Linux 普及率的上升。玩家会喜欢比 Windows
更可靠和安全的平台,我们将看到 Linux
不仅会以两位数的市场份额狂涨,而且可能会超越 macOS 成为第二名。

(文/开源中国)    

Canonical 和 Rancher 实验室共同推出了 一款名为云原生平台的产品,该产品将
Canonical的Kubernetes发行版与Rancher的容器管理平台整合到了一起。其理念是使用Kubernetes来管理每个集群中运行的容器,同时使用Rancher来管理多个Kubernetes集群。Cloud
Native Platform 将随 Rancher 2.0 一起推出,目前仅提供了测试预览版。

Kubernetes
出身于谷歌,是其多年大规模容器管理技术的开源版本,在容器浪潮中完成了短时间内的迅速发展,是目前容器生态中最受欢迎的开源项目。项目于
2014 年 6 月首次亮相 GitHub,即 Docker
项目开源的一年多之后;项目已经被捐赠给
CNCF组织,其目标是成为“跨集群的应用级别容器部署、扩展和运维自动化平台”,它会支持包括
Docker 在内的一系列容器工具。

Docker 社区版/Docker 企业版

而 Docker Swarm 则是 Docker 主推的原生的集群工具,意图让用户像使用单机
Docker API 一样来驱动整个集群。2016 年 7 月发布的 Docker1.12 把 Swarm
内置到 Docker 中,这种内置的做法引来了一些争议,有人认为这对 Kubernetes
和 Mesos 造成了一定的威胁。

对于我们当中的大多数人来说,Docker就是容器。自2014 年以来,Docker
拥有了自己的集群和编排系统Docker Swarm,直到近期它们还是 Kubernetes
的竞争对手。然而在2017 年 10
月,Docker宣布将不做任何修改处于原本状态的Kubernetes作为Docker社区版和
Docker Enterprise 2.0 的标准插入式组件。

在很多人眼里,Kubernetes 更开源、汇聚了更多的力量,而 Docker Swarm 则是
Docker 处于商业化的本心。这里,先抛开 Kubernetes 和 Docker
的历史背景,也不提两者社区背后曾经有过的争论;我们单纯从技术设计的角度来看看两者技术层面的差异。

简而言之,Docker公司已经认识到自己将会遇到大麻烦,并承认Kubernetes比Swarm更适合管理大型复杂的容器环境。尽管如此,Docker仍然为低强度工作保留了其初始的集群系统,比如位于防火墙后面的本地应用,这些应用在数量上不会有大的增长。

遵循的两种网络标准

Heptio Kubernetes付费版

在不同的用户环境中,如公共云、专有云、混合云中,容器的网络模型都有不同之处,为此容器平台提供了插件机制,来支持不同的网络实现。目前关于容器网络接口的配置主要有两种标准:容器网络模型和容器网络接口

为了提供基于 Kubernetes 的服务和产品,Kubernetes 的两位发明者Craig
McLuckie 和Joe Beda 共同创立了Heptio。他们的第一个主要产品是Heptio
Kubernetes 付费版,这是一项需要付费的 Kubernetes
部署服务,由Heptio提供24/7 全天候支持。起步价为每月 2000 美元。

CNM 由 Docker 主导,吸引了 Cisco、VMware 等公司的应用;而 CNI
更归属社区,被运用于 Mesos、Cloud Foundry、K8S 之中。

Heptio的主要卖点是提供没有厂商锁定的企业级Kubernetes。该产品可以运行在公有云或私有硬件上。由Heptio提供的所有Kubernetes配置管理工具都是开源的,补丁可以直接推送到受支持的集群。

CNM 是 Docker 主导的网络方案,而且 libnetwork 和 Docker
原生编排等能力紧密集成在一起,内置的服务发现和负载均衡等能力对于开发者而言非常友好。但是正因如此,也对网络驱动的实现带来了一定挑战,在
Docker 17.06 中 Swarmkit 开始支持 node scope
网络,会简化一部分网络模型支持的复杂性。

Mesosphere DC/OS

CNI 是社区主导的网络方案,整个方案很简洁,只提供基本的网络管理和 IPAM
管理接口,同时和其他网络能力保持正交。好处是网络驱动容易实现,三方编排可以方便地控制网络接口和容器对象的生命周期。不足之处则是,编排系统需要集成多个方案才能完整解决用户的诉求,比如在
Kubernetes 中,DNS 和 Ingress 都是通过 addon
的方式实现的,这也为部署和维护引入和复杂性。

Mesosphere DC/OS通过Apache
Mesos将一组机器转变成可动态分配给多个应用的单个资源。Kubernetes被支持作为DC/OS
上众多应用程序包中的一个,允许用户跨 DC/OS
群集安装、运行和更新Kubernetes。

两种设计的对比

DC/OS 本质上是否是一个Kubernetes发行版值得商榷。这主要是考虑到Kubernetes
并不完全是 DC/OS
的一部分,但可以像其他被支持的应用一样通过DC/OS来部署,就像Linux应用可通过Linux发行版的软件包管理系统进行管理一样。尽管如此,Mesosphere使用Kubernetes的方式严格遵循Kubernetes
的工作方式。例如,他们使用Kubernetes
的主流社区发行版以确保与现有工具集有着高度的兼容性。

CNM 是 Docker 提出的规范。Docker 引擎中的 libnetwork 是 CNM
的缺省实现,现在 CNM 已经被 Cisco Contiv, Project Calico,Weave
等项目所采纳。阿里云也提供了基于 CNM 的 VPC,MacVLAN 等网络驱动。CNM
提供了 Docker daemon 与网络驱动实现之间的控制接口。Docker
提供了原生网络驱动包括 none, bridge, overlay 以及 Macvlan/Ipvlan
等。除了 Linux 容器支持,Libnetwork 也推出了对 Windows 的支持。通过
CNM,Docker 也可以由第三方插件获得更多的网络驱动支持。

Mirantis云平台

CNI 最早是由 CoreOS 提出的一个容器网络规范。已采纳该规范的包括 Apache
Mesos, Cloud Foundry, Kubernetes 等。Flannel, Project Calico 和 Weave
等项目为 CNI 提供插件实现,阿里云也为 Flannel 项目贡献了支持阿里云 VPC
的实现。CNI 最近加入 CNCF 的官方项目。Docker/Moby 社区也会在
Containerd/Swarmkit 中提供 CNI 支持。

正如 Mirantis 所言,Mirantis云平台将OpenStack、Kubernetes
或两者的组合作为敏捷基础设施平台的基础。简而言之,Mirantis Cloud
Platform
是一个用于编排虚拟机、容器和裸机服务器的单一集成解决方案。该平台以DevOps
方式管理部署在该平台上的应用程序,使用 Salt 作为配置管理工具,并集成
CI/CD 支持以确保应用程序被正确部署。

CNM 和 CNI
都提供了插件化的机制来提供网络支持的扩展性,也都支持多个网络驱动被同时使用,这些大大扩展了容器的灵活性和适用范围

Mirantis云平台能够直接在裸机、OpenStack集群或公有云上运行Kubernetes。据Mirantis称,Mirantis云平台可以更容易地与Kubernetes协同工作,原因在于配置Kubernetes底层基础设施的工作不会落在终端用户身上。

然而在设计细节上还是有很多不同,比如 CNI 目前只提供了基本网络管理和 IP
地址管理接口。

Platform9 托管的Kubernetes

Docker libnetwork 是一套完整的容器网络方案实现,不仅提供 CNM 支持
network 驱动和 IPAM plugin,还包含了 DNS、负载均衡、IP Masq
等功能
。下面会深入谈到其中的一些实现差异。libnetwork 和 CNM
可以让容器方便地支持多个网络接口,实现更加灵活和安全的网络拓扑。比如,在部署一个典型的三层应用架构时。web
层容器和数据库容器可以分属于两个隔离的网络,应用服务层容器则可以同时加入这两个网络。这样的网络模型会比把所有容器放置到一个网络更加安全,可以防止由于
Web 层漏洞导致数据库遭到直接攻击。libnetwork 代理了网络 plugin
的部分行为,避免 plugin 直接操作容器的 network
namespace,其优点是可以仲裁解决不同驱动可能引起的配置冲突,如路由规则等。

大多数Kubernetes发行版将重点放在了让 Kubernetes
从内到外和从上到下都易管理上。Platform9托管的Kubernetes可以在本地的裸机或远程的公有云等任意环境中运行,并可由
Platform9的工程师作为服务进行远程管理。

Kubernetes 中的网络模型相对简单,并不需要 libnetwork
类似的冲突解决能力
。比如,Pod 中容器共享相同的网络名空间,Pod
只支持一个网络接口等等。

在客户的监督下,Platform9大约每六周就会对托管的Kubernetes进行一次更新。
Platform9还提供了一些正常情况下必须手动添加至Kubernetes集群中的功能,比如针对多租户场景的用户配额。此外,Platform9还提供了与无服务器计算服务的Platform9
Fission 项目的集成功能,其可在容器化环境下与大多数编程语言协同工作。

同时这两种方案也在不断相互影响和互相融合,不少开源的网络方案同时支持
CNM/CNI 接口。

Rancher 2.0

3.阿里云的容器服务打开方式

Rancher 实验室已经将Kubernetes集成到了他们2.0
版本的Rancher容器管理平台中,不过目前Rancher
2.0还处于测试阶段。相比其他的Kubernetes发行版,Rancher 2.0
在更高的层级上工作,其位于Linux主机、Docker容器和 Kubernetes
节点之上,可以在不考虑位置和基础设施的情况下独立管理所有这些节点。它们甚至可以管理位于亚马逊EKS、谷歌Kubernetes引擎、微软Azure容器服务和其他Kubernetes即服务云上的Kubernetes集群。

容器技术使用概况

Rancher 也有自己的Kubernetes发行版。Rancher的目的是消除搭建Kubernetes
集群和为特定环境定制的Kubernetes时所遇到的繁琐工作,同时防止一些自定义功能妨碍Kubernetes进行顺畅的升级,这对于那些快速发展和经常性更新的项目来说是一个非常重要的考虑。

去年阿里已经实现了电商平台核心业务全部容器化;今年则会实现全部业务应用的容器化,除了一些核心的数据库系统之外,主要应用和部分数据库将都完成容器化。由于买家链路交易流量大,需要具备弹性,这也是电商最痛的业务部分,所以容器化的改造是先从买家链路开始的。

红帽OpenShift

选择 Docker 是因为它具备开源技术标准化、高效率、工具链丰富等优势。在拥抱
Docker 之前,阿里已经使用了五年多自研容器技术 T4,去年开始基于 Docker
容器技术来进行应用的交付和运维,为了适配阿里内部 IT
系统架构和运维方式做了大量的优化和定制。

作为红帽的平台即服务 产品,红帽OpenShift最初使用的是类似于Heroku
buildpack的cartridges来打包应用,然后把它们部署到名为gears的容器中。在Docker出现后,OpenShift被进行了重写,以便利用新的容器镜像和运行时标准。红帽也不可避免地将Kubernetes作为OpenShift内的编排技术。

时下 AI
的发展备受关注,阿里云展示了其容器服务对机器学习的支持,该解决方案可以持续观测用户机器学习的过程,在发生故障时进行快速修复。

OpenShift创建的目的是为了向
PaaS中的所有组件提供抽象和自动化。这种抽象和自动化也扩展到了Kubernetes,这也带来了相当大的管理负担,而OpenShift
可以用来在PaaS大型部署任务中缓解这些负担。有兴趣的读者可以查阅InfoWorld网站关于红帽OpenShift
3的测评,以了解更多信息。

除了对外提供容器服务支撑,阿里云容器服务团队还支撑阿里集团容器内部镜像仓库服务,提供集团内部的
Docker 镜像分发的基础设施。利用 Docker 容器技术,可以实现 IT
架构快速水平扩展和灾备恢复。比如双 11
时,即使有一个数据中心发生故障,要确保有能力在一两个小时内在创建一个的虚拟数据中心,这意味着需要迅速在云上创建数千台虚拟机,并部署完成对应的电商全部业务。

Stackube

一方面,是 Docker 战略伙伴

作为专门用于运行容器的Hyper.sh云服务的开发商,HyperHQ开发出了一个以
Kubernetes为中心的OpenStack发行版,即Stackube。通常情况下,OpenStack
使用一个名为Nova的组件来配置和管理计算节点,Stackube则使用的是
Kubernetes替代了Nova。除此之外,它们使用的是不做任何修改的原OpenStack 和
Kubernetes,所有其他额外细节都由OpenStack插件进行处理。

2015 年 12 月开始阿里云在公共云上推出了容器服务:支持 Docker
原生编排技术,用户可以在云端复用已有的 Docker
镜像和编排模板;将容器技术和阿里云的存储、网络、日志、监控等能力整合;预置了容器化
DevOps 解决方案,简化持续集成和持续交付等。

HyperHQ称,Stackube的主要优势是它们可以根据使用哪个容器运行环境提供多种不同类型的多租户。对于软多租户来说,他们可以使用Docker,如果想实现企业级的资源分离,那么他们可以使用HyperContainer,因为后者使用了管理程序级的隔离。

去年容器技术公司 Docker
与阿里云宣布达成战略合作,当时宣布的合作包括三方面内容:阿里云平台提供
Docker Hub 在中国运营的基础服务;阿里云获得 Docker
企业版的销售权,为客户提供企业级支持和咨询服务;阿里云 成为 Docker
官方支持的云服务提供商。

SUSE云即服务平台

其中 Docker Hub
国内服务已经在阿里云上海云栖大会发布
。基于阿里云的数据存储和 CDN
能力, 加速从国内下载 Docker Hub
容器镜像的速度,并且会基于此陆续推出本地化服务,可以访问
www.docker-cn.comDocker 中国网站了解更多详情。

以在欧洲广泛使用的Linux发行版而闻名的SUSE也推出了SUSE
CaaS平台。在概念上,它们会让人联想到CoreOS
Tectonic,后者为一套裸机微操作系统,能够运行容器和作为容器编排系统的Kubernetes、内置的镜像注册表和集群配置工具。

Docker 近来面向企业市场推出的 Docker Enterprise Edition有几个不同版本
;Docker EE Basic 对应原来的 Docker Engine CS, Docker EE Advanced
则对应为之前的 Docker Datacenter。其中 Docker
企业版也已经在阿里云市场发布。目前阿里云与 Docker
的合作可以总结为下面三方面:Docker
云服务对于国内开发者开服;对企业化产品的整合,包括技术和业务流程上的协同;对
Docker 技术在阿里云能力的集成。

SUSE
CaaS平台能够在公有云和本地裸机上运行,不过需要注意的是SUSE目前并不支持与底层云基础设施的任何集成。这意味着SUSE
CaaS平台的设计不是作为亚马逊EKS或谷歌Kubernetes引擎的补充而设计的,而是为了战胜这些产品,让用户可以跨多个云和数据中心运行容器。

在谈及前一段时间在圈内引起轩然大波的 Moby
项目事件时,阿里云容器负责人易立和阿里云容器服务产品经理汤志敏均此表达了赞同的观点。Docker
和 Moby 主要是为了区分产品服务和开源项目的名字。Docker 公司的逻辑是把
Moby
项目交给社区,模块化拆分则提供更多的灵活性,方便应用于不同的特定领域。其实容器领域适用范围很广,但是
Docker Engine 并不适合所有场景,对于嵌入式设备上、网络设备上等所谓的 IoT
等场景,现有 Docker Engine 会比较重,而基于 Moby
可以剪裁和定制自己的容器引擎。然而此次的改变没有与社区沟通好,引起了一些误解,但是未来应该带给容器生态带来更多的活力。

Telekube

而另一方面,支持 Kubernetes,成为 CNCF 金牌会员

Teleport
SSH服务器的开发商Gravitational推出了可在在本地或远程集群上运行的生产强化型Kubernetes
发行版,即Telekube。Telekube
定位为私有软件即服务平台解决方案,可跨多个地区或托管服务提供商将Kubernetes
作为一项服务予以运行。

上个月, CNCF(Cloud Native Computing Foundation)
基金会宣布阿里云正式成为金牌会员,当前 CNCF 最具人气的项目非 Kubernetes
莫属;阿里云同时宣布除了 Docker 最新版 Swarm mode,其容器云服务亦将支持
Kubernetes。

Telekube
上的应用必须具备能够在Kubernetes上的容器中运行的能力。此外,它们必须被打包至Bundls中,随后Bundls将被发布到Kubernetes集群中。在部署基于容器的应用之前,虽然还需要为捆绑做一些额外的工作,不过Bundle
清单是用户唯一需要维护的Telekube额外工作。

阿里云支持 Kubernetes 的研发工作从 2016
年就已经开始,主要是从与阿里云能力的整合和简化 Kubernetes
部署等方面入手,先后陆续支持了若干个国内外的客户,帮助将其 Kubernetes
环境迁移到阿里云上。

作者:Serdar Yegulalp
为InfoWorld网站资深撰稿人,长期关注机器学习、容器、开发运营和Python生态系统,并定期对上述内容进行总结。

CNCF是 Linux
基金会下属定义云计算模型未来的重要标准化组织,从最早的容器集群调度技术
Kubernetes,到现在覆盖了从容器引擎、容器编排、微服务应用编程和运维模型等众多内容。2017
年 2 月,阿里云加入 Linux 基金会,并开始与 CNCF
讨论合适的加入时机。由于双方在技术方向,社区发展等方面都有合作基础,并且阿里云也一直致力于开源社区和
Cloud Native 的标准推动,比如阿里云是 containerd
项目的初始成员;所以双方的合作是水到渠成的事情。

编译:陈琳华

4.一山二虎,容器编排的未来何去何从?

原文网址:-kubernetes-distributions-leading-the-container-revolution.html

那么,阿里云怎样看待 Docker 和 Kubernetes
背后的两种编排体系的未来?两者是会更加有特色的分化?还是更加趋同的直面竞争?

责任编辑:周星如

一方面,Docker 和 Kubernetes
将在容器编排领域有更多直接的竞争,因为对于多数应用,Docker 和 Kubernetes
的编排方案都能够提供类似的能力,社区将在易用性、稳定性、规模、能力等多方面展开竞争,而厂商们也会努力差异化自己的产品,比如阿里云和
Docker
合作在推动容器在企业混合云场景的应用。良性竞争终将让用户收益,就像
iOS/Andriod 的竞争让移动互联网变得如此富有创造力一样

但在更高的层面,Docker 和 Kubernetes
并不是竞争对手。容器领域有足够的想象空间可以发展;商业的成功也不仅决定于技术,生态的建设更加重要:
只有更多的厂商围绕容器技术进行的创新,更多的应用开发商支持容器化应用交付,更多企业开始拥抱容器技术,才能让容器商业蓬勃发展。除了编排技术本身,Docker
也在不断完善生态建设,比如 Docker
企业版提供的认证的基础设施、插件和企业应用,可以为企业客户提供安全可信的容器环境;其推出的传统应用现代化项目,将帮助企业用户改造遗留系统,更好地利用容器技术。在去年底
Docker 推出 containerd 项目时得到了 Google、阿里云、AWS
等厂商支持,因为它不但提供了一个标准化、稳定的容器运行时,也将更加便于
Kubernetes 这样的编排方案来进行集成。在这一方面上,Docker 和
Kubernetes 更像是合作伙伴

业界更希望看到的是各派系编排系统在良性竞争中逐渐成熟,如此整个容器生态、包括企业级用户将会更加方便轻松受益于此。根据
451 Research 调查显示,以 Docker 为首的容器技术在 2016 年创收 7.62
亿美元,预计该数字将于 2020 年上升至 27 亿美元。

5.写在最后

编排系统各自着力布局发展, Kubernetes 得到了不同厂商的支持,发行版包含
Openshift、Tectonic 等,其最新 1.6
版本在集群规模、调度能力上都有提升;而 Docker Swarm
作为原生编排机制,提供了简化用户体验,Docker 亦在 DockerCon2017
上为大家展示了其内置安全特性;Mesos 内含 Mesosphere DC/OS,最新版 Mesos
1.1 添加了如嵌套容器、任务组等关键性功能
。在众多提供容器服务的厂商中,阿里云、Azure、灵雀云等提供了对 Kubernetes
和 Docker Swarm
的双支持。当然,目前还有一些容器云服务坚定地选择只支持一种编排系统。

在 Kubernetes 和 Docker Swarm 之争成为焦点之前,其实 Mesos
在早期是被广泛使用。有些遗憾的是,目前 Mesos
的社区热度似乎在递减,而另一方面,业界明显感受到 Kubernetes
的崛起;Sysdig 调查显示 43% 的用户使用 Kubernetes,而只有 9% 的用户使用
Mesos。那为什么比 Mesos 晚五年亮相的 Kubernetes
会实现这样的逆转呢?不过,两者的 star 数量相差 7.5
倍,不能否认的是社区贡献的力量,这是对于技术生态的发展至关重要。

同样,各个 IT
企业也不再偏居一偶地“闭门造车”,在提供或者使用商业软件同时,大家越来越多地关注开源项目甚至深度参与源代码的贡献。Docker
虽为商业公司,也是如此:Docker 已经向 Linux 基金会的 Open Container
Initiative 项目捐献了容器镜像和运行时相关规范,和参考实现;并在今年 3
月份,将其容器引擎核心 containerd 捐献给了
CNCF;并且还会继续开展其他标准化工作。而阿里云则提供容器生态多方面技术的支持,同时也参与开源项目贡献和社区建设;阿里云称其会努力成为连接技术生态、企业和高校学术的桥梁,促进越来越多的技术合作。

不论是 CNCF 还是 OCI 都归属于 Linux 基金会,两个基金会成员中有很多 IT
商业公司。OCI 开放容器项目于 2015 年 6 月 22 日由 Docker 与 Linux
联合推出,加入的公司有 AWS、Cisco、CoreOS、IBM、Intel、Oracle、微软等 43
名成员。CNCF 是 Google 于 2015 年 7 月 20
日联合数家公司成立的开源组织,旗下有 Kubernetes 项目,CNCF
基金会中,除了有 eBay、ticketmaster、Twitter 等技术使用公司,还有
Cisco、Dell、Docker、Google、Huawei、IBM、阿里云、腾讯云等著名商业公司,也不乏才云科技、超算云、DaoCloud、EasyStack、谐云科技等创业公司,共计
76 名成员。

众人拾柴火焰高,IT
作为智慧密集型行业,流行的开源项目更容易进入快速发展的良性循环模式;而企业级的应用则更需要专注更专业
IT
服务,并预留特定的人力和精力。那么,基于开源项目提供的商业服务,则可以成为完美结合;比如
RedHat Linux 和 Oracle MySQL 就是很棒的成功先例。

IT 圈已经进化到开源与商业不再剑拔弩张的时代。

作者介绍

木环,InfoQ 运维主编、高效开发运维负责人,前程序媛。

易立,阿里资深专家,目前负责阿里云容器服务、开发者服务的研发。之前曾在
IBM
中国开发中心工作,担任资深技术专员;作为架构师和主要开发人员负责了一系列在云计算、中间件领域的产品研发和创新。

文章来自微信公众号:InfoQ

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图