融合Kubernetes的Cloud Foundry 2.0: 鱼和熊掌兼得的一站式平台

Kubernetes的痛点和Pivotal、Google、VMWARE的方案
在一份针对Kubernetes用户的调查中,下列问题被认为是最具挑战的:存储、安全、网络、复杂性、难以选择编排方案、日志、可靠性、供应商技术支持等。这些问题涉及多个领域,Pivotal凭借多年深耕PaaS产品的丰富经验,在安全增强、管理和抽象复杂性、提供跨云的友好编排、日志聚合和展示、多层次跨可用域的高可用等方面持续创新,而VMAWRE结合EMC在存储、网络等领域引领技术方向,Google作为Kubernetes的创始公司对其优点和痛点自然理解更深,三家公司强强联合,推出PKS(Pivotal Container Service),为用户提供企业级的Kubernetes技术和支持。

Cloud Foundry 2.0的蓝图
PKS是整个Cloud Foundry 2.0蓝图中的重要一部分,提供容器级的服务。如果客户的应用是云原生的或者开发者不关心运行应用的容器环境,可以直接借助平台提供的应用运行时部署到PAS(Pivotal Application Service)中,部署维护更为简单。如果应用是无服务的响应式程序,可以使用PFS(Pivotal Function Service),类似于部署了一个扩展性极高的应用,平时没有需要实例数为0,如果有需要可以迅速扩展以满足业务需要。甚至有些更为复杂的需要在独立虚拟机中实现的应用或者服务,可以借助Bosh部署在虚拟机中,也纳入平台的管理中。

不论是Linux还是Windows的应用,不论是长期运行的、需要定期执行的应用,不论是Java还是其他语言的等等不同形式不同负载的应用,都可以在这样的一个平台中部署运行,并享受一致的网络、安全和服务模式。Cloud Foundry 2.0提供的市场类似于一个企业应用的app store, 允许企业下载安装第三方提供的经过认证的服务,这些服务都实现了一些标准的API,无缝集成到平台中,供平台中的应用和开发者使用。Pivotal实现的这些服务代理机制,已经成为了一个独立的开放服务代理API规范],也被Kubernetes社区拥抱,成为Kubernetes中应用和容器连接访问服务的方式。

在PKS推出之前,有一部分用户在Cloud Foundry与Kubernetes之间纠结,Cloud Foundry在PaaS平台的成熟度、应用开发的便捷性、运维管理的友好性、安全增强、高可用、企业案例和技术支持等方面极有优势,而Kubernetes在社区活跃度、容器定制和可操作性等方面也非常吸引用户。现在,兼具两者优点的Cloud Foundry 2.0让这部分用户欢呼雀跃,鱼与熊掌真的可以兼得。

平台的核心价值
为什么这么多世界500强的大企业都选择Pivotal Cloud Foundry这样的平台来支撑运行自己的开发产品环境,让一个产品在短短几年达到2.7亿美元的年度预定收入,实现130%的年增长率?在这些数字后面,是企业对产品带来的价值的认可,例如保险公司allianz开发者的生产率在平台部署后提高了2000%。如果说二十一世纪最珍贵的是人才,那么IT人才的时间其实就是企业的宝贵财富,当生产率提高了2000%,大量时间节省后,这些人才给企业所创造的新的价值肯定是不可估量的。

Pivotal着眼于平台的所有用户包括最终用户、开发者和运维人员的不同需求,通过大量的访谈、实践和反馈,不断优化操作流程和交互界面,打造用户友好的一站式平台。例如下面的健康状况视图中,最终用户所关心的延迟和错误度量、开发者所关心的部署和性能度量,以及运维人员所关心的资源和服务度量等,都被统一呈现出来,方便所有人随时查看:

一个开发运维友好的平台,可以借助自动化极大的节省人力。例如有用户提到,只需要两名工程师就可以管理超过两万个容器。类似这样的价值,与当前火热的机器学习和人工智能异曲同工,本质上都是借助机器和程序承担了更多的工作,将开发者解放出来,专注在与业务密切相关的创新上。

参考资料
https://content.pivotal.io/blog/achieving-escape-velocity-with-pivotal-cloud-foundry-2-0
https://content.pivotal.io/announcements/introducing-pivotal-container-service-pks-the-simple-way-to-bring-kubernetes-to-enterprise-customers
http://fortune.com/2017/03/07/pivotal-cloud-foundry-growth/
http://www.computerworlduk.com/it-management/allianz-app-deployment-goes-from-days-minutes-with-paas-agile-practices-3646852/

BOSH与PKS(Pivotal版K8S)(《Cloud Foundry:从数字化战略到实现》第二版更新预览)

BOSH 与 PKS(Pivotal和谷歌发行的企业版Kubernetes)

在过去的一年中, Kubernetes 在容器领域可谓大放异彩,吸引了越来越多的来自企业用户的关注。Pivotal 和 VMWare 合作发布的 PKS(Pivotal Container Service)恰逢其时,将为用户带来真正企业级的 Kubernentes 集群,加速企业的数字化变革。 继续阅读“BOSH与PKS(Pivotal版K8S)(《Cloud Foundry:从数字化战略到实现》第二版更新预览)”

《Cloud Foundry:从数字化战略到实现》更新:Pivotal和谷歌的合作项目Kubo改名为CFCR (Cloud Foundry Container Runtime)

Cloud Foundry基金会在2017年底宣布把Pivotal和谷歌捐献的Kubo项目改名为CFCR (Cloud Foundry Container Runtime)。《Cloud Foundry:从数字化战略到实现》书稿或者其他书稿修订博文等文献中的Kubo应该被修改为CFCR。

Kubo = KUbernetes + BOsh
原Kubo在Pivotal的官网介绍

Kubo的名字取自于KUbernetes + BOsh的前两个首字母的组合。KUBO的创建逻辑在《Pivotal和谷歌共建Kubernetes(K8S)》博文有详细阐述。Pivotal公司在Cloud Foundry2.0发布中拥抱容器服务(Container Service),逻辑上并列于1.x版本的应用服务(Application Service)。原来的1.x的Elastic RunTime(ERT)在2.0版本下的含义得到了延伸,但是1.x用户的老印象认为ERT只管理应用服务,为此Pivotal把1.x的ERT在2.0改名为Application Runtime,按照这个平行的逻辑容器管理服务就自然叫做Container Runtime,全称就是Cloud Foundry Container Runtime (CFCR)。

总结来说,在Cloud Foundry2.0版本中,Cloud Foundry通过Application Runtime管理Application Service,通过Container Runtime管理Container Service。Cloud Foundry是Pivotal发起了的开源基金会,而Pivotal发行的Cloud Foundry叫做PCF。PCF 2.0的应用服务叫做PAS (Pivotal Application Service),容器服务叫做PKS (Pivotal Container Service)。Pivotal官网的介绍如下:

CFCR

source:https://pivotal.io/platform

Pivotal和谷歌共建Kubernetes(K8S)生态(中篇)

Pivotal和谷歌联合发布企业版K8S(Kubernetes)成为推特上前17个最热话题
Pivotal和谷歌联合发布企业版K8S(Kubernetes)成为推特上前17个最热话题

上篇谈到了Google云对于PaaS云的愿景下一步步走到GKS(=Kubernetes+Docker)的公有云版本并与Pivotal合作建立PKS(=Kubo+Kubernetes+Docker)进入企业级市场。中篇我们从Pivotal角度上看和Google合作“Kubernetes+Docker”的逻辑。

在书稿《Cloud Foundry: 从数字化战略到实现》中我阐述了Pivotal对于第三平台的判断和决心。Cloud Foundry的发展分两个阶段:2011年-2013年在兄弟公司VMWare孵化。2013年以后成立Pivotal全力以赴。(我打算写另外一篇文章《如何建立5年打造一个10亿美元的产品战略》介绍CF的发展史,但是本文主要讨论和Google合作K8S的逻辑。)Cloud Foundry是我们董事长(Windows之父)Paul Maritz的第三平台理论的产品。其实我们的产品团队更喜欢叫Cloud Foundry为Cloud Operating System,但是工业界喜欢把它划做PaaS云(P层云)。

在书稿《Cloud Foundry: 从数字化战略到实现》中剖析了CF的实现机制,其实CF内置了容器技术Warden和Garden。对于Pivotal这样世界级的软件研发团队写个容器当然不是什么难事,但是Cloud Foundry 1.0是相当有主见的平台,1.0版本认为工程师不需要关心容器机制,而只要专注在他们的应用逻辑上面,因为Cloud Foundry会帮助他们的应用自动成为一个满足12-factor的PaaS应用(也就是SaaS)。但是开发者(aka码农),这个部落有他们的极客思维方式,Docker容器技术出现后一下子得到开发者码农的极大相应(码农是开发者们对于自己的戏称,到那时上篇谈到了分析师和金融界朋友多留意码农的心情走向,因为他们是数字化世界的土著。)现在我们再打开PaaS层仔细聚焦一下,发现里面还可以存在几个技术:容器服务、应用服务和函数服务。

容器服务应用服务和函数服务
容器服务、应用服务和函数服务

现在的问题是我们应该将哪一层暴露给开发者?越往上效率越高,标准程度越高,所以公司老董们会喜欢,但是对于开发者的灵活性却降低。而且一些老的应用,如果需要放在应用服务层或者函数服务层,几乎需要重写。但是放在容器里面倒是可以直接打包分发到云(但是不一定能全满足12-factor应用)。

Pivotal也开始意识到和Google一样的发现:一步到应用平台或者函数平台步子太大了,既然他们同时在PaaS技术,我们应该让开发人员有选择权。而且这个时候Kubernetes+Docker已经成为主流的容器技术,站在产业的角度上,Pivotal可以选择在Warden和Garden技术上发力,或者拥抱Kubernetes+Docker技术生态。这个时候Pivotal留意到Kubernetes+Docker是Google在其公有云的一个安装部署,并不能达到CloudFoundry企业级水平。在成千上万个企业里面的防火墙里面安装维护和升级Kubernetes+Docker部署并没有完成。而Pivotal在Cloud Foundry里面的BOSH技术已经很好的解决了这个问题。所以Pivotal成立了一个项目叫做KUBO,用BOSH来安装维护和升级Kubernetes+Docker。这以举动让Google看到了他们的Kubernetes+Docker可以走向企业市场的可能。技术本身还不是解决商业问题的全部答案。大家没有忘记的话Pivotal还是一个有企业基因的进取富二代(堪比最近很火的 《最强大脑》富二代何猷君)。他的母公司EMC和兄弟公司VMWare有着强硬的500强企业生意往来关系,对于Pivotal来说,把KUBO+Kubernetes+Docker塞进500强企业比起Google做这个事情要容易很多。但是总是有一些500强帝国企业希望把部分负载放在公有云上,这个时候Google何乐不为把企业版Kubernetes给Pivotal发行,顺便建议把那些上公有云的企业介绍到Google云上。从Pivotal的角度上看,如果分支一路Google的Kubernetes+Docker或者发力建设Warden和Garden生态,势必和Google形成的K8S的生态分裂、竞争并降低势能,最糟糕的是在企业市场和二三线的容器企业去竞争。反过来强强联合下,双方都是人生赢家。最终的结果就是Pivotal和谷歌在同一个代码上开发K8S,谷歌分发GKS,Pivotal分发PKS,双方一起在开源Kubernetes和Kubo里面提交代码,Google获得公有云的KUBO+GKS,Pivotal获得企业版的KUBO+PKS。

至此,Pivotal把Cloud Foundry原有的1.0应用平台功能改名为PAS(Pivotal Applicaiton Serivce.) Cloud Foundry 2.0引入了PKS,在加上Pivotal已有的HAWQ技术和Greenplum技术与PKS的集成并有BOSH统一安装管理和升级,Cloud Foundry在PaaS的领导者地位更加巩固。在下篇中我想说说合作后面的学派关系,双方对于PaaS技术的认同并非偶然,因为他们同宗同源练的同门武功。

作者:Pivotal中国Head冯雷  [如需转载请注明本文
URL:http://digitx.cn/2018/01/16/pivotal-google-k8s/]

 

Pivotal和谷歌共建Kubernetes(K8S)生态(上篇)

谷歌和Pivotal合作共建Kubernetes生态,Google发行云版Kubernetes(GKS),Pivotal发行企业版Kubernetes(PKS)
谷歌通过和Pivotal合作把企业版Kubernetes带给用户(来源:https://www.blog.google/topics/google-cloud/vmware-and-pivotal-launch-new-hybrid-kubernetes-solution-optimized-gcp/)

歌Kubernetes和Pivotal Cloud Foundry的关系可能搞得业界有点混淆。最近还是有不少分析师问我Pivotal的Cloud Foundry如何和谷歌的Kubernetes竞争。我本来以为Pivotal、VMWare和Google三者的公关把这个事情说清楚了。因为聪明的分析师们都看不明白这个事情,所以我百度了一下。我发现所有的中文报道都没有能够深刻剖析我们三方的合作逻辑,所以我觉得有必要写这篇blog。《Cloud Foundry: 从数字化战略到实现》的书稿发布前,Pivotal和VMWare和谷歌三方就Kubernetes的合作关系紧锣密鼓通信中,公司要求高管保密到SpringOne大会召开的时候正式发布,所以我在书稿中不能探讨Kubernetes进入Cloud Foundry 2.0版本的逻辑。当媒体和分析师们问及Kubernetes竞争Cloud Foundry的时候,我只能引导他们站在PaaS产业上去推理这里的商业逻辑。如果站在产业高度上看,一些看似竞争关系实质上作为合作关系更加合理。目前你进入Google云主页google.com/Pivotal可以一览合作关系。

Google云上提供Pivotal发行的的企业版Kubernetes
Google云上提供Pivotal发行的企业版Kubernetes。

首先,我们先站在Google云的角度上看。公有云厂商中谷歌是最早把战略定位在PaaS云上的。谷歌当时推出的产品叫做Google Compute Engine(GCE)。这里可能是因为Google在IaaS层云和AWS竞争差异化造成的,也有可能是Google和我们的目光一样,认为PaaS云是云计算的新浪潮(具体逻辑参考书第一章第三节《1.3P层云计算和数字化变革》)。Google Compute Engine(GCE)的首次公开发行是在2012年 ,而Cloud Foundry(CF)的第一版是在2011年亮相。当其他的云厂商都在卖虚拟服务器的时候,GCE和CF站出来说开发人员不需要关心虚拟服务器而只需要关心自己的应用。双方在那个时候在举起一个上万亿美元的市场信念可谓是形影相吊。两个寂寞的视野家虽然彼此惺惺相惜,但生意归生意,各自照顾各自的投资人和客户利益,还不构成充分的合作逻辑。在谷歌推进PaaS战略的过程中,以Docker为主容器技术在码农中火了起来(我建议分析师们在这个年代一定要关心码农的心情走向)。容器技术对于Google和VMWare当然不是什么难的技术,但是难点在于容器的编排和调度(分布式计算机的问题)。所以Google做了一个Kubernetes(缩写为K8S,意思是K后面跳过8个字母到S。这里扯远一下下聊聊硅谷的缩写坏习惯。硅谷的聪明人有一个坏习惯就是喜欢把一个长单词用首字母+跳过的字母数来进行缩写,目的是让爷爷奶奶们读不懂。例如亚马逊的Algorithms被写成A9,如下面动画所示。)

www.a9.com

回到正题上。因为K8S的先进性和容器技术的火爆,Google云的“K8S+Docker”在公有云市场取得了巨大的反响。 但是Google的基因是公有云和消费者市场,如何把“K8S+Docker”推向500强帝国企业不是Google的特长。另外企业软件和互联网软件的还有一个重大差别,就是如何安装、管理、维护和升级上千个“K8S+Docker“在帝国企业防火墙里面的部署?Google云只要维护自己的一个部署,Google云是去组建一个企业软件团队触及帝国企业群还是物色一个门当户对的合作伙伴?读者去Google网站查找的话答案就在第一幅插图。

中篇我们再切换到故事的另外一个主角Pivotal上看心路历程。(….to be continued)

作者:Pivotal中国Head冯雷  [如需转载,请注明本文URL
Pivotal和谷歌共建Kubernetes(K8S)生态(上篇)