Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
OpenStack与Kubernetes 结缘:数据中心的最佳投资组合【zoues.com】 – zoues

LOADING

Follow me

OpenStack与Kubernetes 结缘:数据中心的最佳投资组合【zoues.com】
四月 27, 2017|DockerPaaS

OpenStack与Kubernetes 结缘:数据中心的最佳投资组合【zoues.com】

OpenStack与Kubernetes 结缘:数据中心的最佳投资组合【zoues.com】

有关OpenStack的“负面新闻”总能引起媒体和竞争者们的热吵,但对于OpenStack的行业参与者和技术贡献者们来说,即使这已经成为常态,大多数人还是难以适应——毕竟,他们自己、他们的同事、他们的合作伙伴和客户,都对OpenStack有着实质性的认可,而且OpenStack虽然不是毫无瑕疵,但它“可能是过去十年最成功的云计算基础框架”。

最新被热炒的一则“负面新闻”是《英特尔退出当初与Rackspace一起搞的OpenStack项目》,这一事件的概要是这样的:英特尔决定提前结束与Rackspace在“OpenStack创新中心(OpenStack Innovation Center)”上的合作,虽然两者的合作及资金规划是到2018年,但英特尔“决定结束参与该项目的工作“。

这一新闻更像是英特尔因为Rackspace的转型(实话说Rackspace确实在与OpenStack渐行渐远)而进行的正当商业决定,作为OpenStack基金会的8个白金会员之一,很难想象英特尔会像很多被转走了样的消息所说“英特尔退出OpenStack项目”甚至是“英特尔不再支持OpenStack”——不支持OpenStack,市场上会有什么相对成功的开源云计算基础框架能够吸引住英特尔的目光呢?

但不得不说,热潮OpenStack的“负面新闻”或是讨论“OpenStack不行了”阴谋论的市场大有人在,比如说,HPE和思科叫停自身OpenStack项目的新闻被解读为“OpenStack被大型厂商中断了他们的支持”;Mirantis针对OpenStack专项开发人员的裁员被认为是“OpenStack最知名的初创企业在走下坡路”;

即使是在技术层面,OpenStack的“黑材料”也是屡见不鲜,比如说OpenStack现阶段面临的复杂性和兼容性问题,或是落地失败的案例,被认为“证明了OpenStack无法被用于大型企业的复杂业务应用环境”;

此外,OpenStack在SDN、NFV领域的成功以及这一成功所起到的宣传效应,被认为“势头盖过了整个OpenStack的热度,所以OpenStack的应用范围很有限”——如果一直有人,比如说一些公有云公司,刻意的想要抹黑你,那你又有什么办法呢?

OpenStack与容器:曾经的招黑体质为何突然舆论“黑转粉”?

2015-2016年,“自带招黑体质”的OpenStack的一个热门“黑点”是日渐兴起的容器(Container)“对OpenStack的影响、冲击和威胁”,在一些文章中,容器技术被认为是OpenStack发展中遇到的新威胁,“是有可能在很多市场需求下彻底取代OpenStack”的一项技术——这其中自然有容器的追随者们在市场上宣传上的考虑,但这也不能完全归结于此:容器既可以运行在物理机上,也可以运行在VM上,所以容器的运行不需要OpenStack的支持——对后者来说OpenStack从技术角度来说不是一个必选项。

有趣的是,容器与OpenStack之间关系的问题,早在2013-2014年前后就已经有了,随着Docker、Kubernetes等容器技术的出现,类似的问题就已经出现在技术社区和讨论组中了,像是“Kubernetes和OpenStack到底是什么关系?”这样的问题,早在2014年就已经出现在了知乎;“为何现在流行OpenStack和Docker结合?”这样的问题2015年就已经有数千字的高票赞同回答,可以说在OpenStack与容器这件事情上,话题早已有之、招黑屡见不鲜。

但时间进入2017年,容器与OpenStack产生了剧烈的化学反应:社交媒体上被提及最多的OpenStack问题,绝对是“OpenStack怎么和容器结合?”同样有相当多的人在询问“为何现在流行OpenStack和Docker结合?”甚至于,“Kubernetes和OpenStack到底是什么关系?”这样的问题,都同样是屡见不鲜,偏偏有趣的是,诸多回答不仅不“黑”,而且在客观中立的技术分析之外,透着一股浓浓的“黑转粉”“路转粉”的劲头。

陈喜伦,EasyStack创始人兼CEO,在谈到这一问题时认为:“2014年、2015年,国内的开发人员就已经在接触容器了,但问题是,IaaS层的解决方案还没有竖立起来,容器处于‘上不着天下不着地’的架空位置,容器发展很难,容器和IaaS层之间的结合也很难。”他认为,IaaS层的准备就绪本身就是一个很大的挑战,OpenStack逐渐成为了IaaS层的首要选择,处于比较稳定的、占据主要市场的位置,容器也就随之与OpenStack开始呈现更为成熟的融合、互补的发展道路。

OpenStack与容器技术之间曾经产生的“分歧”,在陈喜伦看来,更像是不同业务团队从不同的出发点对技术产生的自我理解:“CIO负责两部分团队,一部分是管数据中心的,一部分是管开发应用的,数据中心的团队考虑的是长期的战略,要云化、要节省成本,也要管理简单,负责应用的团队主要面向应用开发人员,他们的想法就是先用起来再说,所以他们接触的很早。”换句话说:在早期OpenStack和容器的发展都处于初期,更不用提两者的融合,而且OpenStack考虑的是统一管理、融合架构和经济性,容器更多的考虑的是怎么样快速的上线支持应用,对成本和延续性等方面考虑较少,“两者产生一定的‘矛盾’在所难免,不足为怪”。

但现在,业界越来越多的认识到,同样作为企业云化解决方案,OpenStack和容器是有很多可以融合的地方的:前者启动虚拟机略嫌臃肿,耗时较长,但从IaaS层的角度来说,是目前最好的云计算资源管理平台;后者速度更快,存储密度更高、镜像文件更小、更方面管理集群,除此以外,虚拟机之间、虚拟机和宿主机之间隔离性很好,而容器之间公用宿主机的内核,共享系统调用和一些底层的库,隔离性相对较差。

显而易见,对于那些觉得虚拟机(VM)较重的人来说,容器(Container)是一个更好的选择,但容器在IaaS层资源管理上,与OpenStack相对成熟、完整的生态环境又无法比拟,更何况,OpenStack解决的是基础架构的问题,容器解决的是应用的问题,两者本来就不是一个层面上的事情,早先的论战实际上颇有“关公战秦琼”的意味,所以,解决方案也很简单:在OpenStack上运行容器就好了!

但接下来要面对的问题却并不简单:

容器技术严格说来分为两个层面:1、镜像(或映像),或者说是容器环境运行的“虚拟机文件”;2、容器的部署、扩展和容器操作的编排工具——IaaS层通过OpenStack来管理虚拟机(比如KVM虚拟机),然后用户可以在OpenStack环境(比如说在虚拟机上)运行Docker(映像),通过容器编排工具进行管理。怎样解决容器的管理、编排、组织工具(编排系统),与OpenStack相结合的问题?比如说,(Swarm、Kubernetes和Mesos)+OpenStack的解决方案如何实现?对于这个问题,陈喜伦和刘国辉(EasyStack CTO,联合创始人之一)现在有了一个“八九不离十的答案”。

EasyStack选定Kubernetes?这事儿远没那么简单

很显然,即使EasyStack的胃口再大,信心再足;即使EasyStack对OpenStack+容器技术的未来投入再雄厚,想要同时支持容器编排的三大平台Swarm、Kubernetes和Mesos也是一个不太现实的选择,所以,EasyStack必须要做出一个选择,陈喜伦、刘国辉和EasyStack团队的选择,是Kubernetes。

Kubernetes,一个在集群主机间进行自动化部署、扩展和容器操作的提供以容器为中心基础设施的开源平台,来自于2014年Google的一个项目,被称为“基于Google十多年运行大规模负载产品的经验,同时也吸取了社区中最好的意见和经验”,需要注意的是,Kubernetes是“通过部署基于操作系统级别虚拟化的容器进行虚拟化而非通过硬件来进行虚拟化”,也就是在OpenStack上的虚拟机(VM)上运行容器映像,而不是直接通过物理机。

因此,严格意义上来说,Kubernetes更像是PaaS层:根据chinmaynaik在文章《Google Kubernetes – Analytical Evaluation》中所写的:利用Kubernetes的一种方法是在OpenStack(IaaS层)提供的虚拟机智商部署应用程序,一旦VM(以及所需的网络和存储设置)已经为其各自的项目分配,应用程序部署工程师可以将这些VM视为分配给其业务部门的实际物理机,并选择运行容器友好的应用程序。Kubernetes试图在框架顶部构建一个协调层,试图决定融合将PODS部署到物理机器上,通过这种方式,Kubernetes可以被视为PaaS层的应用程序部署工具。

“Kubernetes是一个‘Born for Cloud Native Application’的平台,它有一个开放的基金会,它有着更正确的技术路线图。”陈喜伦认为,相比Kubernetes,Docker的Swarm,他认为“Docker的野心太大,如果Swarm有一个独立的开源基金会,事情可能会好办的多,但是Docker既要做容器,又要做容器的管理,有要做很多其他的东西,大家就会比较担心。”而对于Mesos,刘国辉认为,它主要是输在了社会的活跃度上,而且技术路线的发展方向也与EasyStack略有出入,此外,“Mesos更像是一个分布式集群管理软件,它能解决容器的编排问题”——言外之意,Mesos对于容器的“忠诚度”还是偏低了些。

此外,从技术角度,Kubernetes是一个“保留用户选择权”的平台,在知乎答主Aitian Ma的眼中,它拥有诸多优势,比如说“不限制支持应用的种类”“不提供中间键(如message buses)”“允许用户选择自己的日志、监控和报警系统”,而且还“不提供或者任何综合的机器配置,维护,管理或者自愈系统”,此外,大量的Paas系统都可以运行在Kubernetes上,比如Openshift, Deis, 和Gondor。

甚至于Aitian Ma认为,Kubernetes不仅仅是一个“编排系统”:它消弥了编排的需要。“编排”的定义是指执行一个预定的工作流:先做A,之后B,然后C。相反地,Kubernetes是由一系列独立的、可组合的驱使当前状态走向预想状态的控制进程组成的。怎么样从A到C并不重要:达到目的就好。当然也是需要中心控制的;方法更像排舞的过程。这让这个系统更加好用更加强大、健壮、有弹性且可扩展。

当然,陈喜伦表示EasyStack并不抗拒Swarm和Mesos方面的合作,毕竟从目前的情况来看,这三者并未100%确认谁会是未来的标准,或是谁最终实质性的胜出,但他强调“从几年前EasyStack就已经在学习和实践容器技术,Kubernetes在技术上与团队的契合度是最高的,能够达到最佳的效果、解决关键的问题,而且Kubernetes与OpenStack上的共识现在是最多的。”

因此,在3月底,EasyStack在德国柏林举行的CloudNativeCon+KubeCon容器大会上,正式发布基于Kubernetes技术的容器集群产品ESContainer,并宣布已经相继加入了全球两大容器开放标准组织——CNCF基金会(Cloud Native Computing Foundation)和OCI开放容器项目联盟(Open Container Initiative)此举使得EasyStack同红帽、Mirantis一道成为全球三大同时具备OpenStack和Kubernetes(K8S)产品的专业开源企业,也是中国首个OpenStack+Kubernetes专业开源企业。

“2017年将是中国企业的容器实践元年。”针对容器市场,刘国辉表示,“容器由于轻量化、快速、可移植的特色颠覆了PaaS,成为部署云原生应用至关重要的技术。而容器的能力能否得到全面体现,取决于是否有一个强大的容器集群管理平台,目前大多数企业级的容器应用都部署在OpenStack之上,OpenStack + Kubernetes将能更好地满足企业的开源云计算需求。”

但EasyStack推出ESContainer仅仅是为了“时髦”,赶上容器的这班车么?ESContainer与EasyStack的两大核心产品ESCloud和ESCore之间是否有什么关系?对于自称要“赶上中国基础软件春天”的EasyStack来说,容器是否仅仅就意味着一个新的产品?

OpenStack和Kubernetes的兴起 与基础软件有什么关系?

EasyStack是这样描述自家的容器新产品的:

“ESContainer 面向应用角度设计,自身提供应用管理服务,方便用户在平台中集中管理发布容器化应用;对于有状态应用场景进行优化,方便用户构建多层微服务化应用;支持无 Overlay 纯二层网络等多种网络方案,容器应用与虚拟化应用网络直通;增强监控与日志,面对庞大的容器集群,ESContainer还提供了增强的多级的监控、日志管理。

ESContainer 面向企业级容器化应用的管理和编排场景,产品提供包括自动化部署、强化的管理界面、应用商店,多级监控、支持虚拟机、可视化编排、物理机资源池的混合部署,并且与EasyStack的企业级OpenStack平台ESCloud 深度融合,无缝的使用 ESCloud 提供的计算、网络和存储资源以及丰富的软件基础设施,为云计算从以资源为中心到以应用为中心打通了最后一公里。”

而且EasyStack特别指出:

“ESContainer和ESCloud融合,Kubernetes 使用 OpenStack Keystone 作为用户管理系统,用 Keystone 作为统一用户管理平台,打通两个平台的认证体系。”而且“EasyStack云计算内核ESCore 还专门为ESContainer进行裁剪与优化、提供适合容器运行的定制化操作系统,能够为容器集群带来更高密度的运行能力,同时提供了更加稳定高效的底层环境。”(EasyStack的产品包括:ESCore、ESCloud、ESCloud+、ESCaaS、ESRoller、ESConnect等,均是以ES开头)

ESContainer与ESCloud,ESCore之间紧密的关系,甚至是“ESCore专门为容器技术进行了裁剪和优化”的做法,是否意味着ESContainer对EasyStack来说,有着更重要的作用?作为EasyStack所有产品、服务的核心底层ESCore,是否又可能会吸收部分ESContainer的技术,形成“以OpenStack+Container为核心”的EasyStack基础软件(底层)平台?

首先,OpenStack已经成为事实上的IaaS层标准,纵使它有大量的问题,但是在规模庞大的社区和诸多专业OpenStack公司的支持下,它的前景是非常被看好的,而且短时间内不可能有取代OpenStack的产品(包括社区和生态环境)出现;

与此同时,容器作为一种轻量级的Linux虚拟客户环境,对目前新应用迭出、新业务上线时间紧凑的客户需求环境来说,是相当好的(恐怕也是唯一的)解决方案,两者的结合,能够实现“IaaS层对下层资源的优化编排,PaaS对上层应用的快速响应”,是当前合情合理的解决方案,可以说,两者结合才是更好的基础软件平台;

其次, “OpenStack+Container”方案需要的不只是Docker创建和管理容器(也就是Docker本身与单个容器的配合使用),否则面对的是一个庞大的OpenStack平台加上无法管理的、孤立的许许多多Docker容器,企业用户更需要的是一个支持更为常见的集群级容器使用模式的平台,在这一领域,Kubernetes同样是当前最切实可行也是最有希望的容器调度、部署和编排平台,在ESCore中加入对Kubernetes的支持,甚至是干脆将后者纳入其中,对EasyStack的“中国基础软件战略”都是技术的加强和适应度的扩展。

第三,既然EasyStack的目标是基础软件市场,ESCore是EasyStack“基础中的基础”,那ESCore加入IaaS、PaaS层的平台就不是一件“违和”的事,还可以让EasyStack更进一步的向上渗透。

略显可惜的是,这个问题现在还没有确切的答案,陈喜伦谈到,ESCore“会融合一些场景做更多的适配和优化,这也是EasyStack正在做的,但作为一个战略性产品,它的发展空间还很大。未来也会有一些新的发布。”他强调“从EasyStack核心想法的角度来看,这样的想法是读懂了EasyStack的战略的”。

刘国辉从技术角度表示:“在容器层面我们现在支持OCI、Docker,这些都是原生支持的,对于容器,包括容器编排平台与ESCore的紧密结合,完全具备这种可能性。”但他补充表示:“平台的强化、裁剪,性能的优化,技术的密度,都是会体现在一个技术平台上的,而且还要具备可升级的能力”——对ESCore或是ESCloud而言,或许还不到时候。

no comments
Share