容器在国内的火热程度毫不亚于国外,这从基于容器的创业公司的数量上就能看出来。而大部分容器相关的创业公司都瞄准了同一个方向:CaaS(容器即服务)。时速云就是这样的一家公司,他们基于Docker、Kubernetes、Mesos 等开源技术实现了大规模容器集群的调度、部署和管理。目前他们的容器云平台上已经运行了上万个容器,并且非常稳定。为了了解时速云的创业背景以及他们的容器云平台的架构等细节,InfoQ 记者采访了时速云CEO 黄启功。另外,时速云CTO 王磊也将在8 月28 日举行的 CNUTCon 全球容器技术大会上分享题为《时速云基于 Kubernetes 打造容器云平台的实践》的演讲,敬请关注。
InfoQ:时速云的定位和愿景是什么?为什么当时会选择创业以及选择 Docker 创业?
黄启功:时速云 TenxCloud 是一家云计算领域的初创公司,我们的定位是轻量级的容器云平台(Container as a Service)。CaaS 很好的结合了 IaaS 和 PaaS 两者的优势,我们以 Docker 为代表的容器技术作为切入点,整个云平台都是以容器化应用作为交付的标准。TenxCloud 目前立足于公有云,为开发者和企业提供了一个快速构建、集成、部署、运行容器化应用的平台,帮助开发者和企业提高应用开发的迭代效率,简化运维环节,降低运维成本。 我们希望可以为容器技术在中国的发展贡献我们的力量,惠及更多的开发者和企业,与各界合作伙伴一起打造一个健康的、快速增长的容器云生态。
谈到创业的初衷,就要说起我在 IBM 期间的工作了。在 IBM 的几年,刚好经历 IBM 从传统的 IT 服务商拥抱云计算的战略转型,我有幸从事过各种类型的云计算产品。 IaaS 解决了资源的问题,但应用的构建、部署、运维等并没有得到很好的解决。Docker 的出现让我们看到了希望,Docker 的部署速度比虚拟机高出一个量级,占用资源极少,共享 HostOS,秒级部署,Namespace 隔离以及集装箱的理念很好的解决了环境构建的问题,加上我本身在做 IBM Bluemix PaaS 平台,我们当时研究过国内外主流的 PaaS 平台,以及分析他们为什么没有起来的原因,感觉到以 Docker 为代表的容器技术未来在云计算领域会有很大的机会,CaaS 很有可能会改变用户使用 IaaS 和 PaaS 的方式, 于是决定基于 Docker 创业做些事情。
InfoQ:时速云使用了哪些技术栈?目前的架构是怎么样的?
黄启功:目前时速云使用的技术栈比较多样化。基于 Docker 给我们带来的轻量级、自满足的打包特性,很好的消除了不同技术栈之间的差异,并以微服务形式进行封装,互相提供服务接口,可以简化一些开发技术上的问题。主要涉及 Node.js 和 Golang,以及一些 Python、 Ruby、Shell 脚本的使用,根据不同的使用场景使用不同的技术,满足快速开发、方便维护、容易扩展的需求。在设计和实现上,严格遵循了微服务的理念,比如每个模块尽量实现单一服务功能,服务之间的通信接口尽量简单轻量,每个服务可以比较轻松的实现横向伸缩等。
目前的架构可以分为 4 个大的区域:
- 容器集群管理主要由 Kubernetes 作为基础服务,并进行了很多优化,包括替换相关表现不佳的组件、对系统进行性能调优、系统的自动伸缩等;
- 镜像服务采用类似 Docker Hub 的架构,分布式的镜像存储后端,提供丰富和稳定的镜像服务;
- 对 CI/CD 的支持,实现从代码到部署上线的一站式服务;
- 对私有主机的集群管理。通过集群化管理用户的实体主机、虚拟机或者云主机上的资源,合理规划和充分利用现有的计算和存储资源,同时把我们平台的技术和优势传递给用户,为用户提供集群的部署、管理和监控的一整套解决方案。架构上既要考虑上面这些功能独立运作的能力,也要清晰定义彼此之间的交互接口,形成一个有机的整体。
InfoQ:你认为时速云产品中,最吸引人的特性有哪些?
黄启功: 1. 国内首个跨 IaaS 的容器云平台。时速云北京 2 区开放,率先支持跨集群、跨底层 IaaS 提供镜像和容器服务的能力。同时,2 区使用了更先进的底层技术,包括更大规模的集群支撑、分布式的数据存储等等,将提速整个平台的运行效率和稳定性。
2.TenxCloud 推出了国内首个 Docker 容器主机集群管理混合云服务。这是我们基于容器技术在混合云方面的探索和尝试,可以帮助企业轻松的搭建基于容器技术的私有主机集群,并提供和公有云平台一致的容器管理服务。
3. 更易于微服务和服务编排的实现。由于底层技术的差别,时速云在微服务架构和服务编排的实现上更有优势。用户之间的服务会有安全的隔离,平台内部通过自组网络进行安全通信,用户服务之间通过环境变量获取互相的信息,用户只需在一个服务中引用其他服务即可。
4. 本地代码直接构建镜像支持。如果用户的代码没有托管到 GitHub 或者 BitBucket 等代码托管平台上,只有本地的代码或者可部署的应用,时速云同样支持从代码到镜像的构建。并且具有以下优势:支持 Windows、Linux 和 Mac 三种平台;无需关联代码托管服务;如同使用本地 Docker 一样的体验;不需要打包源代码文件,保证用户的源代码安全。
5. 完整的开放 API,可以供开发者和 SaaS 厂商自由调度和连接。
InfoQ:在 Docker 的使用过程中,你们做了哪些重点优化?
黄启功:在 TenxCloud 时速云的平台构建中,我们对 Docker 本身并没有修改,而是对与之相关的技术进行了深入的研究和尝试,比如以下几个方面:
- 资源限制,尝试了 Docker 的各种存储 driver,为了做到存储空间限制和避免一些潜在问题;然后对内存、CPU、硬盘、可用进程数、磁盘读写等进行控制,避免多租户情况下产生资源冲突和相互干扰。
- 剔除 Docker 本身的网络,搭建自己的自组网络,做到 Docker 容器的跨机器通信。
- 实现自己的存储管理,做到跨机器挂载到相应 Docker 容器,随容器自由移动,保证数据和容器的一致性;对用户数据进行分布式存储,做到容器数据的高可用。
- 镜像存储同样采用分布式,保证用户镜像的安全高可用,并动态调整后端存储的容量。
上面几个问题只是冰山一角,在容器云平台的构建中会遇到各种各样的挑战,在以后我们的线下活动中再慢慢和大家分享。
InfoQ:如何解决容器的安全问题?
黄启功:容器部署运行上有轻量快速的特点,而它的内核共享的特性可能会给宿主机及网络环境带来安全问题。对于开发及运维人员,我们需要以容器特性为出发点,可以从以下几方面改善容器的安全问题:
- 权限及资源限制
限制用户运行特权及访问资源。对于多租户应用,不同的容器共享同一主机的资源和环境,普通用户权限的恶意提升将会使宿主主机完全处于被非法操控的险境,而对于用户的合法操作,大量的资源申请也会将主机推向崩溃的编译。因此,有必要对用户权限进行限定,避免根权限的赋予,进而减少主机暴露的攻击面和潜力。同时,在 CPU、内存及进程数等资源方面,限定用户在单一容器中的可用配额,来防止恶意的无限资源申请给整体系统带来的破坏。- 镜像及制作管理
对容器的镜像来源进行审核。容器镜像制作的简化让用户可以轻而易举的创建自定义的应用镜像,但制作的应用程序千差万别,功能完整性和测试完整性参差不齐。这让用户镜像的产生面临存在众多漏洞的风险,因此需要对镜像的制作过程尽量规范化,对放置的应用程序尽量做到测试完备并符合安全标准,从源头上减少漏洞镜像的生成。而在创建容器过程中,避免使用不受信任的镜像及应用程序,采用标准及合格厂商如时速云的镜像服务 mirror,从而保证容器运行时的正规及安全。- 日志安全审计及升级补丁
对容器及系统中宿主机进行定期安全检查及漏洞补丁升级。定期针对容器及所在宿主机的网络环境进行渗透安全测试,及时发现可疑容器或危险服务端口。对主机内核及原始镜像进行定时更新,及时修补公开漏洞。在应用层次,收集及检测容器的安全日志,统计监督应用的运行过程,及时发现服务异常。
InfoQ:Kubernetes 已经发布了 1.0 版本,你们有了很多的 Kubernetes 和 Mesos 的使用经验。它们目前是否已经成熟可用?相比于 Mesos,Kubernetes 有什么优势和缺点吗?使用场景有什么不同?
黄启功: Kubernetes 的快速发展得益于开源社区众多贡献者的努力,Kubernetes 1.0 的发布,意味着这个容器集群管理系统可以正式应用到生产环境。
Kubernetes 与 Mesos 同是集群管理系统,有着不同的应用场景和各自的优势。Kubernetes 作为专门的容器集群管理框架,其轻量级,易迁移,快捷部署的优点显而易见。Kubernetes 的灵感来源于 Google 的内部 Borg 系统,吸收了包括 Omega 在内的容器管理器的经验和教训,label、annotaion 等功能的加入让容器分类检索信息标记管理更加便捷。在网络方面,Kubernetes 可以和多种解决方案自然融合,插件化的构成方式让用户可以很方便的使用自定义的网络组件,进而解决了容器跨机通信的问题。在资源调度方面,Kubernetes 目前以预测规划的方式为容器分配集群资源,保证局部资源拥挤的发生,并提供调度接口,允许用户使用定制的调度算法。
Mesos 是 Apache 下的开源分布式资源管理框架,被称为是分布式系统的内核。其特点在于资源管理和调度,能够消除集群硬件的差异化。在使用场景上,Mesos 可以作为资源池提供分配给上层的框架,同时支持多种用途的数据应用框架比如 Hadoop、Kafka、Spark 等。而 Kubernetes 是专门的容器集群管理器。它本身的服务代理可以在集群范围内探知用户服务,同时提供多种方式的服务组合,再加上其模型本身允许多容器共享资源的特点,Kubernetes 从设计之初便提供了微服务实现的架构模型。
InfoQ:你怎么看 CaaS 的发展以及 CaaS 的未来?
黄启功:近几年云计算技术飞速发展,不断出现新的技术,从 IaaS 到 PasS,再到 SaaS,越来越多的厂商也意识到这些技术潜在的价值,而云计算作为一种全新的低成本、高效率的 IT 服务方式必将带来行业的变革和创新。CaaS 作为后起之秀,介于 IaaS 和 PaaS 之间,起到屏蔽底层系统(IaaS),支撑并丰富上层应用平台(PaaS)的作用,可以解决 IaaS 和 PaaS 的一些核心问题。比如 IaaS 很大程度上仍然是提供机器和系统,用户需要关心资源的管理、分配和监控,没有减少用户的使用成本,对各种各样的业务应用支持有限;PaaS 则重点提供对主流应用平台的支持,但是没有统一的服务接口标准,对用户各种各样的个性化需求不能很好的满足。以容器为中心的 CaaS 则可以很好的将底层的 IaaS 封装成一个大的资源池,用户只要把自己的应用部署到这个资源池中即可,不需要关心资源的申请、管理等与业务开发无关的事情;同时 CaaS 又有一套唯一标准的镜像格式,可以把各种应用打包成统一的格式,并在任意平台之间部署迁移,容器服务之间又可以通过地址、端口服务来互相通信,做到既有序又灵活,既支持对应用的无限定制,又可以规范服务的交互和编排。CaaS 必然会很大程度上替代 IaaS,并对 PaaS 提供更好的支持,未来云服务将会以应用为中心,并让开发和运维人员更加关注业务上的改革和创新,而不用去担心资源的事情。
InfoQ:目前技术上遇到的最大挑战是什么?准备如何解决?
黄启功:在平台搭建和优化过程中,确实碰到了很多棘手的问题,这里分享几个例子:
- Docker 的后端存储方式,我们曾经尝试过 aufs、devicemapper、overlayfs、brtfs 等方式,而且每种方式都碰到一些坑,在稳定性和可用性上也挣扎了一段时间。最后的解决方案是在不同场景下应用不同的存储方式,以达到功能和性能的平衡。
- 集群调度效率不高,资源分配不合理的问题。改进调度算法,结合资源预约和机器实际资源使用情况来共同决定容器的部署节点,考虑节点上非容器进程的资源占用情况,既要充分利用机器资源,又要避免节点过载而失效。并根据节点的资源情况动态迁移节点,最终实现节点资源的高利用和稳定性。
- 容器中数据的持久性和可操作性。对于容器中需要做持久化的数据,我们也尝试了不同的方式,包括共享网络磁盘、容器中自动挂载等等,最终确保数据跟随容器可以随意迁移到不同节点,以及数据的高可用。同样,也要考虑数据的备份、回滚,让用户轻松管理自己的数据。
评论