DockOne技术分享(十九):畅谈PaaS

wulonghui · · 2346 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。


【编者的话】PaaS(平台即服务)是云计算中的一个火热的话题,本次分享跟大家聊聊PaaS,特别是PaaS的三个典型代表: Cloud Foundry、Docker和Kubernetes,包括一些技术性和非技术性话题,希望更加全面地帮助大家了解PaaS。

PaaS的前世今生

我们所熟悉的云计算分为3个层面:IaaS(基础架构即服务)、PaaS(平台即服务)、SaaS(软件即服务)。与SaaS相比,PaaS和IaaS的概念相对较新,也是最近几年云计算领域的集中发力点,像Amazon、微软、谷歌、阿里云等还有很多初创公司都推出了IaaS和PaaS产品。

下面一张图比较经典的比较传统IT、IaaS和PaaS:
QQ截图20150902093612.png

目前市面上有很多PaaS平台,我自己认为可以分为3个阶段:
  • 第一代PaaS,比如Google App Engine、SAE,这是最早期的PaaS,当时并没有PaaS这个概念,但是他们做的事情,现在看来是包含在PaaS范围内的。
  • 第二代PaaS,比如 Cloud Foundry、OpenShift。这是各大IaaS流行之后,顺势推出的PaaS, 并且迅速发展。
  • 第三代PaaS,比如Kubernetes。这是在Docker火爆之后,利用Docker的特性构建出许多PaaS,这些PaaS更加灵活,更加适应企业,逐渐成为PaaS的主力,我想也是很多人正在做的方向。


接下来给大家说明下刚才提到的几个典型的项目, Cloud Foundry、Docker和Kubernetes,从中就可以看到几代PaaS进化的技术驱动力。

Cloud Foundry

Cloud Foundry是VMware于2011年推出的业界第一个开源PaaS云平台,后来分拆出Pivotal公司进行接管,2014创立Cloud Foundry基金会,希望吸引更多的公司参与,而不是Pivotal一家独大。

现在说的Cloud Foundry是V2架构,它的结构图如下:
QQ截图20150902093738.png

  • Router:路由模块,所有的数据面和管理面请求都通过Router进行分发。
  • UAA/Login Server:鉴权模块。
  • NATS:消息总线, Cloud Foundry内部组件的通信主要通过NATS进行通信。
  • Cloud Controller(CC):管理中心,负责应用的生命周期管理等等。
  • Health Manager:应用的健康监控状态。
  • DEA:应用的运行时节点,应用都是运行在DEA上。
  • Warden:容器管理模块,类似Docker,提供给应用容器运行环境。
  • Service Brokers:用于适配对接各类的第三方服务,可以是各种关系数据库、中间件、缓存、云存储、内存数据库等各种服务。
  • Metrics Collector/App Log Aggregator:平台应用的日志和监控数据收集。


Cloud Foundry推出以后逐渐得到了各大厂商的支持, 华为云、IBM BlueMix、 HP Cloud和Dell云服务都采用了 Cloud Foundry作为基础,一时间成为PaaS的代表。那么 Cloud Foundry的优势有哪些呢?
  • 开源、开发的架构。 开源是趋势, Cloud Foundry顺应了趋势,自然可以吸引大批的开发者和公司参与其中。同时 Cloud Foundry是一个开发的架构,定义了一套标准,可以扩展多种框架、语言、运行时环境及应用服务,支持运行在云平台IaaS上。
  • 运维智能化。 运维能力是PaaS最最最最最重要的能力,这决定了PaaS的成功与否,如果PaaS无法提供强大的运维支持,为什么我要把应用托管在PaaS,我需要看日志和监控,我需要经常升级应用等等,IaaS可是提供了相当灵活的处理机制。 Cloud Foundry在这方面做出了很多努力,提供应用的容错容灾、弹性伸缩、负载均衡、安全控制、监控日志的收集汇总等等。
  • 容器。 这里不得不提容器技术,容器轻量、隔离的特性是非常适合PaaS的需求的, Cloud Foundry中开发了Warden组件来实现容器管理,实际上Warden和Docker类似,只不过 Cloud Foundry当时并没有专注于容器这一块,Warden在易用性和设计上都不如Docker,自然被Docker抢了风头。


Cloud Foundry最大的问题是它只能支持简单的Web类应用:应用只能暴露一个HTTP端口,应用之间通信也只能通过HTTP等等,这是因为 Cloud Foundry一开始的设计模型是比较简单的,很多复杂场景应该是没考虑的,目前V3架构Diego正在开发中,应该有这方面的考虑。

总之Cloud Foundry最为第二代PaaS的代表,它在运作、架构和技术上相比第一代PaaS都有一定的提高,在云计算大潮中引领了PaaS的发展,但是PaaS一直处在一个不温不火的尴尬程度,使用PaaS绝大多数是开发者个人的玩票性质,真正使用的企业用户其实很少。接下来Docker登场。

Docker

Docker是PaaS提供商dotCloud开源的高级容器引擎,Docker自2013年以来非常火热,2014年就已经火得没有朋友了。


这篇文章讲Docker的由来的,蛮有趣的,有点无心插柳柳成荫的意思。
关于Docker的好处,现在有许多文章都会说明,这里我讲讲个人的理解:


像很多文章提到的Docker快速敏捷(启动、停止都是以秒或毫秒为单位的),隔离轻量级(不添加额外的操作系统),这些实际上是Linux内核提供的能力,Docker是沿用了这些特性,像Cloud Foundry的Warden也有这些能力,Docker最大的创新点在于Docker镜像的设计,下面是张Docker镜像的层次图,分层的文件系统,一层层地搭建出一个完整的容器运行环境:
QQ截图20150902093917.png

这样一来,我们可以像乐高玩具一样搭建各式各样的镜像,同时Docker提供了一整套镜像存储方案(Docker Registry),可以非常方便地获取想要的镜像,然后快速地启动运行,而不必像以前那样安装各种麻烦的依赖软件。
Docker更像个微创新者,但是解决了最大痛点,像Warden只解决了应用运行的问题,而Docker解决了应用的发布、构建和运行,创建了很多想象空间,所以基于Docker衍生出了很多新的解决方案,特别是PaaS,即第三代的PaaS,Kubernetes是其中最具代表性的一员,最后讲一下Kubernetes。

Kubernetes

Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上,为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能,本质上可看作是基于容器技术的micro-PaaS平台。


关于Kubernetes的技术分析可以参考我的系列文章,这里不做展开。
因为Docker解决了应用编译构建的问题,所以Kubernetes架构上就可以专注在容器编排,服务发现等等运维相关特性上,像Cloud Foundry就是花了很大精力在应用编译构建上,集成了BuildPack,各种文件传输,效果其实不是特别好。

PaaS的价值不是在帮你编译打包上,而是在于节省运维成本。

Kubernetes的设计模型我认为有几个好的地方:
  1. Label的设计: Pod、Service、Replication Controller之间的是通过Label进行关联,这是一种轻绑定的方式,可以方便地组合业务,做灰度升级等等。
  2. 网络模型: Kubernetes采用扁平化的网络模型,每个Pod都有一个全局唯一的IP(IP-per-pod),Pod之间可以跨主机通信,相比于Docker原生的NAT方式来说,这样使得容器在网络层面更像虚拟机或者物理机,复杂度整体降低,更加容易实现服务发现、迁移、负载均衡等功能。


Q&A

问:开源势必引入安全问题。Cloud Foundry的安全保护机制?
答:Cloud Foundry对于应用有个安全组的特性,可以控制应用容器的访问。但是实际上能力不强,容器安全这块一直是被担心的地方。

问:Cloud Foundry的DEA,即应用的运行时节点,是虚拟的操作系统么?Warden对底层的操作系统有和要求?Warden如何实现的隔离性?
答:DEA是个服务,其实还是Linux系统Warden对内核有要求,实现原理和Docker类似。

问:va/spring/web 应用很容易在Docker/Kubernetes环境运行,如果要迁移到CF,工作量大吗?
答:CF V2工作量应该挺大,V3的话因为支持Docker,所以还好。

问:关于k8s中Flannel和Weave两者哪个更适合生产环境?
答:这个我最近正在分析,感觉Flannel和Weave都还不成熟,推荐OVS。

问:Docker既然是namespace隔离的,就算不安全应该也影响不是很大吧?
答:其实如果你清楚原理,很容易进入到容器环境中的,没办法,安全是个大问题。

问:k8s可以实现应用的自主迁移吗?
答:目前没有Pod迁移的API。

问:CloudFoundary中监控部分有插件机制么?
答:支持导入到各种第三方监控系统。

问:Pod直接通信需要开通隧道么?换句话说他们之间是如何实现通信的?
答:容器跨主机的通信,是对Docker的增强,像Flannel、ovs等。

问:PaaS的三个典型代表: Cloud Foundry、Docker和Kubernetes,最近的DaoCloud、灵雀云、时速云等以Docker为核心提出了新的CaaS概念。CaaS和PaaS都使用了Docker,Kubernetes等技术,您是怎么理解PaaS和CaaS的?
答:CaaS容器即服务,我的理解就是PaaS,只不过主打这Docker容器,所以叫CaaS。

问:Docker在CentOS上使用devicemapper,据说容易使系统crash,对于其他的文件系统有没有推荐,brtfs和aufs哪个更好?
答:aufs是内核不接受的,听说是因为代码太乱。

问:对于管理Docker这件事情,除了Kubernetes, OpenStack(IaaS阵营), YARN(Hadoop阵营)也开始发力,怎么看待这几者间的竞争?
答:没有任何技术是银弹,不同需求不同设计。当然大家都想占据制高点了,这就是运作了。

问:k8s现在具备auto scaling能力吗,比如应用响应时间变长,k8s可以自动扩容?
答:没有。

问:如果将Flannel替换成ovs是不是也可以替换掉kube-proxy,如果是那会不会影响集群中SVC的使用?
答:flannel/ovs和kube-proxy的作用是不一样的,可以看下http://dockone.io/article/545

===========================
以上内容根据2015年9月1日晚微信群分享内容整理。分享人吴龙辉,现任网宿科技高级运营工程师,致力于云计算PaaS的研究和实践,活跃于 Cloud Foundry、Docker、Kubernetes等开源社区,贡献代码和撰写技术文档。邮箱:wulh@chinanetcenter.com/wlh6666@qq.comDockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

有疑问加站长微信联系(非本文作者)

本文来自:DockOne.io

感谢作者:wulonghui

查看原文:DockOne技术分享(十九):畅谈PaaS

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

2346 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传