云计算容器服务该何去何从

容器技术最近很火,各家项目纷纷提出自己的支持方案,比如 OpenStack、CF、Mesos,以及一堆本身就基于容器的平台方案,更是跟容器技术脱不开关系。

这也直接导致了暧昧已久的 IaaS 和 PaaS 开始正面的跨界冲突。

在 IaaS 看来,做 PaaS 无非就是提供几个应用模板嘛,原来虚机不好做,现在用 Docker,瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper,虚机要跟容器比性能。

而在 PaaS 看来,你 IaaS 就该老老实实地做底层物理资源给抽象出虚拟资源的事情。原来都是虚机的时候,感觉好复杂,我们搞软件的人确实不懂。现在有了一堆基于 Docker 的容器平台,往上就都是我做软件的人可以做的事情了,所以以后其实可以不再强调 IaaS 了。

这些讨论直接导致现在的云计算技术发展到了一个很关键的节骨眼上,将决定未来至少十年内云计算产业的形态。

当前状况

姑且放下这些争论,我们来看一下 IaaS 领域的 Top 开源项目 OpenStack 现在是怎么对待容器的。

目前有三种方案:

Nova-Docker:把容器作为虚机管起来。基本上其它组件都不需要动。唯一的问题就是容器毕竟不是虚机,比如需要提供一些额外的参数支持啦,需要引入组的概念啦,需要性能的优化啦。
Heat Docker Driver:用 Heat 来管容器。Heat 大家都知道,是个十分灵活且强大的解释引擎,理论上 Docker 需要的支持它都能有。唯一的问题是 Heat 毕竟是个解释引擎,它本质上还是要基于其它服务提供的 API。由于不是个运维引擎,导致运行时的管理没法保障,比如自动的资源调度啊,网络功能啊,等等。如果这些都做了,那就等于在更高一层上重复发明轮子了。
Magnum:玩容器的人看问题基本上都是从应用层往上开始考虑。一帮人跑去 Nova 项目谈,应该怎么支持基于容器的 DevOps 啊,应用模板啊,Nova 组一帮做系统的人就傻了,这事我们咋能干,这分明是 PaaS 该做的事情。但架不住大家都觉得 Docker 很火啊,我们肯定还是要玩点花样的,于是一个新的项目诞生了。但玩应用的人毕竟不懂系统,于是调研了下,现在能管理 Docker 的开源方案还真有几个,比如 Swarm 和 Kubernetes。太好了,那么,怎么把 Swarm 和 Kubernetes 这样的 PaaS 平台给集成到 OpenStack 这样的 IaaS 平台上呢?这个听起来好像也不懂唉,有人又想起 Heat 来了,一拍脑袋,可以先拿 Heat 来装一套啊。每次需要的时候就调个 Heat 命令,动态的装一套。所有问题看起来都解决了,皆大欢喜啊,真是皆大欢喜!

思考云计算

某位名人说过,之所以能看得远,是因为站在了前人的肩膀上。

让我们抛开系统和应用之争,姑且也胆大地站在前人的肩膀上来重新发明轮子。

还是要忍不住重复,信息技术的领域离不开分层和抽象。在不同的时代和位置进行分层和抽象,诞生了小型机,诞生了处理器,诞生了编程语言,诞生了 Web 服务,诞生了云计算……

抛开 IaaS,抛开 PaaS,云计算到底要提供啥?这个问题毫无疑问,是便捷服务。 于是,用户需要操作系统,可以直接给你一个;用户需要一个运行环境,可以直接给你一个;用户需要一套软件,也可以直接给你一个;用户需要一套方案,这个目前还没法直接给你一个,属于外包公司的业务。:)

那么,对于云平台的设计者来说,就是要提供这些不同层次的服务给用户,这才有了所谓的 IaaS 和 PaaS。所以,要记住,各种 XaaS 是呈献给用户的服务层次的不同,根本不是设计层次和技术方案的不同。

就好比你买了一个手机,可以玩游戏,也可以打电话。游戏和电话是手机提供给你的不同服务形态而已,并非说游戏是一种特殊的手机,电话是另外一种特殊的手机。

OK,那么,下面的问题就是讨论为了满足用户的这些需求,在设计上该如何分层。前人的智慧是毫无疑问的,总结出了计算、存储、网络这三个根本的基础业务。其中计算又是最核心和最直接的。

我们来看直接面向用户的计算业务。数据中心里面放着的都是物理机器,物理机器上可以装操作系统,操作系统上可以装各种软件,可以运行虚拟机,可以运行容器。无论物理机、虚拟机、容器,都是属于计算资源。统统都应该用云方案给实现供应出来。

如果说 IDC 是让用户可以拿物理机作为计算资源载体,那么现在的云计算是更进一步,让用户可以直接忽略计算资源的实际载体,无论是操作系统还是应用,直接提供给你即可,无需关心具体的载体。

总之一句话,云计算就是要方便提供计算资源!

问题与方向

Magnum 目前被认为 OpenStack 里面最有活力的容器项目,但是很可惜,一开始的路子就是偏的。

Magnum 的定位是提供一套 OpenStack API,底下可以兼容/依赖多种第三方的容器管理平台。OpenStack 本来就是要做一套资源管理平台,现在是用别人的,意味着这跟 OpenStack 其实关系不大。但是如果抛开 OpenStack,上面封装的一套 OpenStack API 又没有了意义。第三方的管理平台都有自己现成的 API。

真正的 Container as a Service,其实应该是在 OpenStack 中实现一套容器平台,而不是在 OpenStack 中安装了别人的一套平台,然后进行了 API 的封装。

或许有人会猜测,之所以不做底下的实现,可能跟 Nova-Docker 有关。

如果我们只谈技术,其实很容易在 Nova 中实现真正的 Container as a Service。在 Nova 看来,都是计算节点,但计算节点可以带上各自的类型,比如有的计算节点是物理机、有的是虚拟机、有的是容器甚至容器组。不同的类型意味着底层不同的驱动。用一套抽象的资源调度的框架(参考 Mesos 的二层调度机制),带上不同的底层 framework,问题很容易得到解决。

但偏偏是现在已经有了 Nova-Docker,已经有了 Magnum,不知道要经过多少波折才可能走到这个方向上来。或许在 OpenStack 的大环境下,是一件太困难的事情了。

或许,这就是开源的魅力,分分合合,曲折中前行。

本文作者:yeasy

来源:51CTO

时间: 2024-08-02 05:28:22

云计算容器服务该何去何从的相关文章

Docker监控:基于阿里云容器服务构建自己的Docker监控框架

微服务架构通过将一个复杂系统分解成一系列独立开发.部署和运维的服务,提升了整个系统的敏捷性,可以灵活的响应业务和规模的变化.而Docker技术则将服务的部署和环境完全解耦,利用Docker的可移植性和敏捷性,快速交付分布式应用,从而大大提升了部署运维效率.然而大规模分布式微服务应用,也会给系统监控带来新的挑战. 除去分布式应用自身的复杂性,微服务倡导的快速迭代和动态部署都会加剧管控的复杂性.从技术角度来看,传统的监控系统大多是针对物理机或虚拟机设计的,通常使用静态的配置项来建立应用.环境与监控指

阿里巴巴高级技术专家张智宇:阿里聚石塔电商云容器服务应用和实践

大流量高并发互联网应用实践在线峰会官网:https://yq.aliyun.com/activity/112 峰会统一报名链接:http://yq.aliyun.com/webinar/join/49 议题名称:<阿里聚石塔电商云容器服务应用和实践> 议题简介:聚石塔是阿里电商云,承载着品牌商.ISV等阿里生态各角色的电商IT系统云化的任务,这些ISV和品牌商的系统很多都运行在淘系电商的主链路上,三方系统的稳定性就成为了这个淘系电商稳定性保障的重要组成部分.为了让ISV更好的支持双11.实现三

网易云基于Kubernetes+Docker的容器服务研发实践

网易从2012年春开始云计算研发,陆续上线私有云IaaS.PaaS服务,并实现网易95%以上的互联网业务迁移上云.在近日的网易云技术布道系列活动中,张晓龙分享了网易云基础服务团队在研发容器服务过程中的实战经验.   一.网易云技术架构   首先看到网易云的研发历程和整体架构,如下:   下图是网易云的简单架构:     技术架构从底到上可分为三层:   基础设施层主要采用虚拟化技术将服务器.交换机/路由器以及硬盘等物理设备虚拟成为可以按需分配的计算/存储/网络资源.基础设施层主要包括:云主机.云

阿里云容器服务简介

容器服务是阿里云在2015年12月推出的一项新产品,目前正处于公测阶段.   容器服务是一项高性能可扩展的容器管理服务,支持在一组阿里云云服务器上通过 Docker容器来部署或编排应用.用户不再需要安装.运维.扩展自己的集群管理基础设施,而是可以直接通过阿里云控制台图形化界面或API进行容器操作和生命周期管理.容器服务整合了阿里云负载均衡SLB.专有网络 VPC等云产品,为云应用部署与运维场景提供丰富的一站式功能支持.   和业内同类容器服务产品AWS EC2 Container Service

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完

阿里云容器服务测评

背景 为了集中精力在上层逻辑,我们计划将自己搭建的容器调度框架mesos+marathon逐步迁移至阿里云容器服务.经过一个月的测试.迁移和开发,我们已将测试环境所有服务迁移到容器服务,并针对容器服务的问题,做了很多workaround,最终在容器服务上搭建了一个高可用零宕机的容器环境.下面我们从<云计算十字真言及其在小博无线的实践>中提到的五个维度来谈一谈容器服务的亮点和它的不足,以及如何让其变得高可用. 冗余 服务无论是被内部还是外部请求调用,都需要通过冗余来避免单点,防止单点故障时造成的

基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

换个角度看持续交付 在<基于容器服务的持续集成与云端交付>系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付. 不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么.回到本系列第一篇文章中的容器持续交付的流程图: 这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段.持续集成阶段.持续交付阶段等等,规定了在每个阶段中该做什么

基于容器服务的持续集成与云端交付(四)- 多种发布方式

前言 哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死.而云端交付过程中也只有三个问题是严肃的. 如何重建你的系统 How to recreate your system? 如何安全地部署你的系统 How to safely change your system? 部署后的问题监控与解决 When something has gone wrong? 在前面的文章中,我们讲述了什么是云端交付,如何搭建从零搭建一个持续交付系统,而今天我们要谈的是如何安全的部署你的系统,部署

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持