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

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

容器是个啥?它不是虚拟机这样单纯的底层虚拟化,也不是纯应用,它恰好位于两者之间,位置极其重要。简直就像是 IP 协议层一样,无论自顶向下还是自底向上都无法绕开。

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

在 IaaS 工程师们看来,做 PaaS 无非就是提供几个应用模板嘛,原来虚机不好做,现在有了 Docker,瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper,虚机号称要跟容器比性能,那原来熟悉虚机的工程师可是太喜欢了。

而在 PaaS 工程师们看来,IaaS 就该老老实实地做底层物理资源给抽象成虚拟资源的事。原来底层都是虚机的时候,感觉好复杂,什么 SR-IOV,Libvirt/KVM,SDN,Overlay,Ceph……搞 PaaS 的人一般看不懂。而现在有了一堆现成提供 Docker 的容器平台,再往上就是应用了,都是做软件的人可以做的事情了,所以以后其实 IaaS 就没那么关键了。

这些讨论就像当年的单内核和微内核之争一样,是不光涉及到技术,还涉及到模式的关键战役。

可以说,看起来现在已经到了一个很关键的节骨眼上,中间这一层的设计将决定未来至少十年内云计算产业的形态。

当前状况

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

目前有三种方案:

  • Nova-Docker:把容器作为虚机管起来。基本上其它组件都不需要动。唯一的问题就是容器毕竟不是虚机,比如需要提供一些额外的参数支持啦,需要引入组的概念啦,需要性能的优化啦。这导致玩 PaaS 的人很不喜欢。
  • 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 的大环境下,是一件太困难的事情了。

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

转载请注明:http://blog.csdn.net/yeasy/article/details/46545837

时间: 2024-10-12 20:41:12

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

云计算之路-阿里云上-容器难容:容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

阿里云宣布 Serverless 容器服务 弹性容器实例 ECI 正式商业化

摘要: 阿里云宣布弹性容器实例 ECI(Elastic Container Instance)正式商业化,ECI 是阿里云践行普惠的云计算理念,将 Serverless 和 Container 技术结合,提供的一款敏捷安全的Serverless容器运行服务. 1月2日,阿里云宣布弹性容器实例 ECI(Elastic Container Instance)正式商业化,ECI 是阿里云践行普惠的云计算理念,将 Serverless 和 Container 技术结合,提供的一款敏捷安全的Serverl

[Docker]公有云容器服务进入2.0时代

公有云容器服务进入2.0时代 近来Google.Amazon接连发布基于容器(其实主要是Docker)的新业务. 2014.11.05 Google发布Google Container engine 2014.11.13 Amazon发布AWS Container Service 估计很快我们也将看到Azure的新容器服务发布了. 如果我们把之前IaaS公有云提供商的产品看做容器服务1.0, 这轮新发布的产品相当于2.0升级版. 在1.0中,各厂商引入API.CLI方式向用户提供在虚拟机中创建容

阿里云容器服务与 ASP.NET Core 的 Docker 部署:用 docker secrets 保存 appsettings.Production.json

这是我们使用阿里云容器服务基于 docker 容器部署 asp.net core 应用遇到的另一个问题 —— 如果将包含敏感信息的应用配置文件 appsettings.Production.json 传递给运行在容器中的 asp.net core 应用. Docker 针对这样的应用场景已经提供了解决方案 —— Docker Secrets,对应的 docker 命令是 docker secret .我们就用 docker secrets 解决了这个问题,在这篇随笔中分享一下. 首先在阿里云容器

在阿里云容器服务上开发基于Docker的Spring Cloud微服务应用

本文为阿里云容器服务Spring Cloud应用开发系列文章的第一篇. 一.在阿里云容器服务上开发Spring Cloud微服务应用(本文) 二.部署Spring Cloud应用示例 三.服务发现 四.服务间通信与集成 五.服务智能路由 六.集中配置管理 七.高可用和容错 八.监控和日志 九.服务的部署和发布策略 微服务概述 单体应用通常指在一个程序中满足多个业务或技术领域的需求,不同的需求领域内化为模块.假定我们要开发一个Web应用,通常的MVC模式可以满足要求.针对不同领域有不少代码生成工具

品尝阿里云容器服务:初步尝试ASP.NET Core Web API站点的Docker自动化部署

部署场景是这样的,我们基于 ASP.NET Core 2.0 Preview 1 开发了一个用于管理缓存的 Web API ,想通过阿里云容器服务基于 Docker 部署为内网服务. 在这篇博文中分享一下经过实践验证的操作步骤: 一.创建与配置集群 1)首先创建一个 Swarm Mode 的集群(注意创建时不要选择“自动创建负载均衡”,因为我们部署的是内网服务,自动创建的是公网负载均衡,需要手动创建内网负载均衡并绑定到集群): 2)集群创建成功后,会在集群列表中显示下面的信息: 3)接着创建一个

品尝阿里云容器服务:用nginx镜像创建容器,体验基于域名的路由机制

在前一篇博文中我们了解了阿里云容器服务的路由机制: 请求 -> 负载均衡80端口 -> 容器主机9080端口 -> acsrouting路由容器80端口 --基于域名--> Web站点容器端口 在这篇博文中,我们用nginx镜像创建一个容器实际体验一下. 使用容器服务首先要创建一个集群(Cluster),比如这里我们创建一个名叫websites的集群(使用的是swarm mode): 创建好集群后,点击“管理”,进入集群管理页面 -> “负载均衡” -> “域名设置”,

腾讯云容器服务的滚动升级使用简介

版权声明:本文由腾讯云容器服务 原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/216046001482723263 来源:腾云阁 https://www.qcloud.com/community 作者介绍:于广游 腾讯云后台开发工程师 欢迎加入腾讯云容器服务QQ交流群434653499  1.什么是滚动升级 滚动升级是一种多副本服务的升级方式,其特点是能够保证升级过程中服务不中断,对外界无感知.其原理大致为循环的执行以

如何给容器服务的Docker增加数据盘

如何给容器服务的Docker增加数据盘 摘要: 我们知道Docker的数据是通过联合文件系统的方式存储到磁盘上,当需要在机器上运行的容器或者镜像的数量不断增加时,有可能磁盘的大小不再满足需求,这个时候就需要给Docker的数据目录通过增加数据盘的方式进行扩容. Docker 数据目录 Docker默认的容器和镜像数据存储的目录是在/var/lib/docker下面,可以通过du命令查看这个目录目前占用的磁盘的大小,例如: # du -h --max-depth=0 /var/lib/docker