docker&kubernets篇(十五)

云平台的层次架构

IaaS平台接管了所有的资源虚拟化工作,通过软件定义的方式来为云租户提供虚拟的计算、网络和存储资源。

PaaS平台接管了所有的运行时环境和应用支撑工作,云平台的租户因此可以申请配额内的计算单元而不是虚拟机资源来运行自己的服务。当前不少经典PaaS平台已经采用容器作为计算单元,那些仍然依靠虚拟机提供应用运行时支持的PaaS平台在此处中将被称为IaaS+平台。
云平台调度这些计算单元用以部署和运行租户的代码制品。在这两层的基础上,用户部署的应用和服务通过API响应的方式组成一系列集合服务于最终用户,这就是所谓SaaS。上述过程其实描述了一个清晰可见的层次结构
在这里插入图片描述
在经典云平台层次体系里,应用实例运行在PaaS平台所提供的容器环境中,容器在虚拟机基础上完成了第二层次基础设施资源的划分;容器封装了应用正常运行所需的运行时环境和系统依赖;同时,容器也成为了租户调度应用、构建应用多实例集群的最直接手段。与IaaS层不同,通常在PaaS层可以采用更贴近应用的资源调度策略。可是,目前遵循这个体系结构构建的经典PaaS平台中存在一个有趣的现象:租户从始至终都无法感受到容器的存在!相比于基于虚拟机提供运行时支持的IaaS+平台(比如AWS),经典PaaS平台的租户甚至都不能进入自己的计算单元(容器)中,这类PaaS平台就如同一个黑盒,所有“扔”进去的应用就完全脱离了租户的控制,进入了完全被托管的状态。诚然,如果一切都有条不紊地运作,该模式可谓完美,因为“所有用户都是最懒的”这个假设总是成立,而残酷的现实却是:“错误总是会发生在任何意想不到角落里。”

举个简单的例子,一旦应用运行过程中有错误发生,一些经典PaaS平台首先会删除故障实例,然后立即在其他位置恢复这个实例和容器。这个过程中,甚至平台默认没有保存现场的过程。浙江大学SEL实验室云计算团队曾在Cloud Foundry中增加了从websocket日志组件收集容器中的应用日志到ElasticSearch的机制,通过该机制在一定程度上能给用户提供方便的日志信息诊断处理,但对于日志中无法体现的异常还是无能为力,更谈不上调试代码和保存环境上下文了。这样的先天缺陷,也是后来云计算领域会出现大量“云DevOps工具”,提供一个类似“白盒PaaS”解决方案的重要原因之一。

在一些经典PaaS平台中,出于安全、封装等各个方面的考虑,容器总是被故意隐藏在整个云平台的运行过程当中(如图5-1所示),因此开发和运维人员失去了往日对应用及其运行时环境的完全掌控能力,试图重新获得控制权所做的努力往往要求助于过分晦涩的交互方式和hack般的自定义过程。再加上经典PaaS平台通常在应用架构选择、支持的软件环境服务等方面有较强限制。因此在生产环境下,部分企业和个人开发者会倾向于放弃PaaS层,直接依靠运维力量来分配和调度虚拟机,靠大量自动化工具来维护和支撑所有运行时、应用环境配置、服务依赖、操作系统管理等。这时,传统云平台分层结构就会进化成如图5-2所示的状态,即IaaS+云平台。

在这里插入图片描述
这种“返璞归真”的做法是一种值得一试的云计算运维方法,尤其是在大部分IaaS都能够提供标准而丰富的API的今天。高效便捷的虚拟机DevOps工具在很大程度上弥补了IaaS平台脱离应用的缺陷;以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致;IaaS提供商还在不断推出关系型数据库、NoSQL、日志、搜索、对象存储等构建在虚拟机上的可对外提供服务的镜像。事实上,基于IaaS的云生态环境已经具有相当高的成熟度。

相比经典PaaS平台,Docker的出现使得构造一个对开发和运维人员更加开放的容器PaaS云成为可能,基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期,还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制,将更多控制力交还给开发和运维人员。这种“降维攻击”把曾经引起不少争论的话题再次摆在了开发者面前:PaaS应该以何种形态存在?此处无意给上述问题寻找一个完美答案,更希望能与读者一起研究和探索基于容器的云平台究竟以什么形态出现才更合理。因此,此处为读者介绍多种类型的容器云平台。它们中一类更偏向经典PaaS平台,提供各类“一键xx”服务,它们给予用户最大的方便和更高度的自动化,也因此附加了对应用架构和开发运维自由度限制;另一类则给用户最大的开发运维自由度,但自动化程度较低,使用相对复杂。也许到阅读完第二部分内容后,读者就能找到怎样的容器云平台才是最适合自己的。在本书中将不会再过分强调所谓IaaS、PaaS、SaaS三层云计算划分方式,更多的是将这些概念视为经典技术作为容器云的对照。

在这里插入图片描述
在Docker等容器技术很有成为未来应用发布事实标准的当下,必须指讨论的一个基本立足点:由于当前容器在内核完整性、安全性和隔离性上的固有缺陷,目前在大部分场景下我们必然需要虚拟机、虚拟网络、虚拟存储的支持。接下来讨论的所有以容器为核心的云平台都不会锁定在某种具体IaaS或者PaaS上面,将始终坚持容器云平台应无差别地工作在物理机上或者虚拟机上这样朴素的思想,并以此为基础剖析各类容器云的原理与本质。这或许不太容易,比如Kubernetes天生就是为GCE定制的,而其他大部分容器管理平台也都以AWS和DigitalOcean作为默认的下层资源依赖。在后续的论述中将尽可能屏蔽掉这类外部因素,以中立的技术态度贯穿始终

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yitian_hm

您的支持是我最大鼓励

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值