CN109062655A - 一种容器化云平台及服务器 - Google Patents

Abstract

本发明提供了一种容器化云平台及服务器，所述云平台以基于容器技术的分布式架构构建而得，在所述分布式架构中，包括至少一个服务用容器，所述服务用容器用于运行一个目标服务，所述服务用容器与所述目标服务一一对应。本发明提供的容器化云平台具备容器管理的功能，而不只是单纯的容器部署方案，并且所述云平台能够减少部署时间，降低维护难度，具有自愈功能。所述云平台进一步提供了容器应用管理功能，无须维护kubernetes复杂的yaml配置文件。平台服务之间采用容器方式隔离，便于维护，同时可以对每个容器进行cpu、内存、io的限制，扩展了平台的灵活性。

Description

一种容器化云平台及服务器

技术领域

本发明涉及云平台领域，尤其涉及一种容器化云平台及服务器。

背景技术

现有技术在云平台中使用容器技术有两种主要的方案，分别为：

方案一：通过ansible或其它自动化运维工具来部署云平台组件容器。这种方案在容器事先编译好后，通过容器部署方式部署云平台，部署时间快，但缺乏后期对容器生命周期的管理，某个容器发生故障，难以进行自动替换，需要依赖人为干预。

方案二：通过kubernetes容器编排框架来部署云平台组件容器，利用kubernetes自身的Replication Controllers来保证服务的高可用性。这种方案kubernetes的使用需要依赖yaml，kubernetes里的replicationcontroller、service、pod的创建都需要一个配置的yaml文件来表示，而如果云平台环境比较繁琐时不可避免会产生很多yaml，从而导致更新部署繁杂且容易出错。鉴于kubernetes版本更新速度快，为了支持新特性，不断升级的成本高。

此外，现有技术中实现配置都是基于二进制包或源码方式安装，软件包依赖问题严重。

发明内容

为了解决上述技术问题，本发明提出了一种容器化云平台及服务器。本发明具体是以如下技术方案实现的：

第一方面，所述云平台以基于容器技术的分布式架构构建而得，在所述分布式架构中，包括至少一个服务用容器，所述服务用容器用于运行一个目标服务，所述服务用容器与所述目标服务一一对应。

第二方面，一种计算机可读存储介质，用于存储程序，所述程序用于实现所述容器化云平台。

第三方面，一种服务器，所述服务器用于运行所述容器化云平台。

本发明提供了一种容器化云平台及服务器，具备下述有益效果：

对比现有技术中的方案一和方案二，提供了容器管理的功能，而不只是单纯的容器部署方案。减少了部署时间，降低了云平台维护难度，提供了一个有自愈功能的云平台，

对比现有技术中的对比方案二，提供了容器应用管理功能，无须维护复杂的配置文件。

平台服务之间采用容器方式隔离，便于维护，同时可以对每个容器进行cpu、内存、io的限制，扩展了平台的灵活性。容器启动速度快，容器故障替换对用户而言是无感知的。

便于平滑升级或回滚云平台，测试人员便于模拟线上环境的一致性。解决由于安装时间不同，造成的包版本不一致的情况。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本发明实施例提供的容器化云平台示意图；

图2是本发明实施例提供的容器镜像意图；

图3是本发明实施例提供的容器示意图；

图4是本发明实施例提供的云平台服务容器化流程图；

图5是本发明实施例提供的第一部分容器镜像关系示意图；

图6是本发明实施例提供的第二部分容器镜像关系示意图；

图7是本发明实施例提供的第三部分容器镜像关系示意图；

图8是本发明实施例提供的第四部分容器镜像关系示意图；

图9是本发明实施例提供的第五部分容器镜像关系示意图；

图10是本发明实施例提供的应用管理工具应用启动流程图；

图11是本发明实施例提供的云平台部署容器流程图；

图12是本发明实施例提供的服务器结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例提供一种容器化云平台，如图1所示，所述云平台以基于容器技术的分布式架构构建而得，在所述分布式架构中，包括至少一个服务用容器，所述服务用容器用于运行一个目标服务，所述服务用容器与所述目标服务一一对应。

在所述容器化平台中可以运行不止一个服务，每个服务均具备自身对应的服务用容器，在所述容器化平台的维护过程中，通过维护服务用容器来达到维护服务的目的。

为了解决现有技术的容器配置对于安装包的依赖问题，本发明实施例中为每个目标服务生成目标容器镜像。在所述容器化平台中，对于目标服务的操作均通过操作所述目标服务对应的服务用容器实现，对于所述目标服务的修改通过修改所述目标容器镜像对应的配置文件实现。具体地，所述相关操作可以使开启、停止、更新和修复。

对于容器化部署，容器编译是最耗费时间的环节，事先把软件包和/或源码都安装在容器镜像里面，从而实现了服务的预安装，在后续服务的相关操作中，只需要修改相关配置，直接启动容器即可，从而提升了容器的启动速度，避免了频繁编译，也避免了对于安装包的过分依赖。

本发明实施例中的容器服务依赖于容器组件Docker完成，Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。一个完整的Docker由以下几个部分组成：dockerClient客户端，DockerDaemon守护进程，Docker Image镜像，DockerContainer容器。

在本发明实施例中，一个容器是一个精简版的Linux操作***，一个镜像是加载到这个容器的软件，当容器被启动后，容器引擎会自动检查是否存在容器镜像，若有则自动获取容器镜像，加载容器镜像到容器中并开始运行。

容器镜像可以被理解为只读层(read-only layer)的统一视角。如图2所示，从图的左侧可见多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在运行Docker的机器的文件***上访问到。统一文件***(union file system)技术能够将不同的层整合成一个文件***，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件***，可以在图片的右边看到这个视角的形式。

容器的定义和容器镜像的定义相类似，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。如图3所示，因此，容器和容器镜像的关系可以被简单表述为容器＝容器镜像+读写层。

当一个容器被运行后，即成为一个运行态容器，运行态容器被定义为一个可读写的统一文件***加上隔离的进程空间和包含其中的进程。一个运行态容器可以对文件进行修改、删除、创建，这些改变都将作用于可读写层，因此，可以将服务容器化，通过运行容器的方式运行以及维护服务。

当云平台存在多个服务时，必然产生对于容器的编排以及管理问题，本发明实施例使用容器编排工具kubernetes进行容器编排以及管理。所述容器编排工具用于提供容器组件的运行环境并基于所述容器组件构建应用服务。Kubernetes作为一个全新的基于容器技术的分布式架构领先方案，是一个开放的开发平台，也是一个完备的分布式***支撑平台。除此之外，Kubernetes还具备了超强的横向扩容能力。

Kubernetes(通常写成“k8s”)是最开始由***设计开发最后贡献给CloudNative Computing Foundation的开源容器集群管理项目。它的设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。Kubernetes通常结合docker容器工具工作，并且整合多个运行着docker容器的主机集群。

Kubernetes定义了一套堆积木，这些堆积木统一提供部署、维护和扩展应用的机制。构成Kubernetes的这些组件让Kubernetes变得松耦合可延伸，因此它能满足各种不同的工作负载。Kubernetes的延展性在很大程度上是由Kubernetes的API提供的，这些API被运行在Kubernetes的内部组件、延伸组件和容器使用。

Kubernetes提供了丰富的kubectl命令，可以较为方便地处理常见任务。如果需要自动化处理复杂的Kubernetes任务，常常需要编写yaml配置文件。

yaml代表着基于人类可读的文本格式的信息，使用yaml用于Kubernetes具备以下优势：

便捷性：不再需要添加大量的参数到命令行中执行命令；

可维护性：yaml文件可以通过源头控制，可以跟踪每次的操作；

灵活性：通过yaml可以创建比命令行更加复杂的结构。

yaml是一个JSON的超集，意味着任何有效的JSON文件也都是一个有效的yaml文件。然而，纵使懂得JSON和yaml，由于yaml文件格式比较复杂，即使是资深编程人员也不可避免地会犯错或需要查询文档。并且，基于yaml操控kubernetes，也会存在更新部署繁杂和容易出错的弊端。

为了摆脱使用kubernetes的过程中对于yaml的依赖，本发明实施例使用应用管理工具helm进行kubernetes的管理。所述应用管理工具用于以应用包的形式管理所述容器编排工具构建的应用服务。

helm可以理解为Kubernetes的包管理工具，可以方便地发现、共享和使用为Kubernetes构建的应用。helm包括两个部分，helm客户端和tiller服务端。helm客户端是一个命令行工具，负责管理charts、reprepository和Release。它通过gPRCAPI(使用kubectlport-forward将tiller的端口映射到本地，然后再通过映射后的端口跟tiller通信)向tiller发送请求，并由tiller来管理对应的Kubernetes资源。tiller接收来自helm客户端的请求，并把相关资源的操作发送到Kubernetes，负责管理(安装、查询、升级或删除等)和跟踪Kubernetes资源。为了方便管理，tiller把Release的相关信息保存在kubernetes的ConfigMap中。tiller对外暴露gRPCAPI，供helm客户端调用。

helm有三个基本概念：

Chart：应用包(helm包)，包括该应用的所有Kubernetes manifest模版，类似于YUM RPM或Apt dpkg文件；

Repository：应用包存储仓库；

Release：chart的部署实例，每个chart可以部署一个或多个Release。

关于Chart和Release，本实施例将在后续进行详细介绍。

为了在容器化云平台中基于docker容器、kubernetes容器编排工具和helm容器应用管理技术达到把云平台服务容器化的目的，需要进行下述两个步骤，如图4所示：

S1.定义容器镜像的依赖关系。

为了表明本发明实施例中的依赖关系，请参考本发明实施例提供的部分容器镜像关系图5-9。所述容器组件中的容器镜像采用分层设计，上层镜像的使用依赖所述上层镜像对应的下层镜像，所述容器镜像之间的层级关系均存储在helm之中。

S3.使用应用管理工具定义容器应用的依赖关系。

容器镜像编译好后，下面是使用helm定义容器应用依赖。在helm中，Chart是一个helm包，其中包含了运行一个应用所需要的工具、资源定义等，还可能包含Kubernetes集群中的服务定义，类似Homebrew中的formula，APT的dpkg或者Yum的RPM文件，Release是在Kubernetes集群上运行的Chart的一个实例。在同一个集群上，一个Chart可以安装很多次。每次安装都会创建一个新的Release。helm应用启动的流程如图10所示，包括：

S2、在应用包存储仓库中查找需要的应用包后。

S4、把所述应用包实例化并部署到容器编排工具构建的应用服务之中。

当完成前期准备工作(生成容器镜像、定义容器镜像依赖关系、定义容器应用依赖关系)后，即可在云平台部署容器，如图11所示，包括下述步骤：

S101.根据目标服务拉取目标容器镜像。

S102.部署基础设施容器服务。

具体地，所述基础设施容器服务包括ntp和rabbitmq。

ntp是网络时间协议(Network Time Protocol)，它是用来同步网络中各个计算机的时间的协议。

rabbitm全称为Message Queue，是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息(针对应用程序的数据)来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBMWEBSPHERE MQ等等。

S103.部署分布式存储容器服务。

具体地，所述分布式存储容器服务包括ceph和glusterfs。

ceph为分布式文件***，Linux持续不断进军可扩展计算空间，特别是可扩展存储空间。ceph是一个分布式文件***，能够在维护POSIX兼容性的同时加入了复制和容错功能。

glusterfs是一款自由软件，主要由Z RESEARCH公司负责开发。主要应用在集群***中，具有很好的可扩展性。软件的结构设计良好，易于扩展和配置，通过各个模块的灵活搭配以得到针对性的解决方案。可解决以下问题：网络存储，联合存储(融合多个节点上的存储空间)，冗余备份，大文件的负载均衡(分块)。目前适合应用于大数据量的离线应用。glusterfs可以通过Infiniband RDMA或者Tcp/Ip方式将许多廉价的x86主机，通过网络互联成一个并行的网络文件***

S104.部署负载均衡和高可用套件容器服务。

所述负载均衡和高可用套件容器服务包括haproxy、lvs和keepalived。

haproxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。

haproxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。haproxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进当前的架构中，同时可以保护web服务器不被暴露到网络上。

haproxy实现了一种事件驱动，单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制、***调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space)实现所有这些任务，所以没有这些问题。包括GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter和Tuenti在内的知名网站，及亚马逊网络服务***都使用了haproxy。

lvs是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群***。其使用集群技术和Linux操作***实现一个高性能、高可用的服务器。Lvs具备高可伸缩性(Scalability)、高可靠性(Reliability)、高可管理性(Manageability)。

keepalived作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从***中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

S105.部署云平台容器服务。

本发明实施例提供了一种容器化云平台，并且云平台中对于服务的维护都通过容器实现。容器化的云平台可以很容易模拟出一个线上环境，从而进行升级测试，若升级失败可以进行回滚等操作。容器化的云平台可以是扩平台的，只要它支持跑容器。

本发明实施例基于基于docker容器、kubernetes容器编排工具、helm容器应用管理技术，能够构建得到一种支持快速部署，并且具有自愈功能的云平台。

相比于现有技术中在云平台使用容器的两种技术方案，本发明实施例提供的技术方案具备下述显著优势：

(1)对比方案一和方案二，提供了容器管理的功能，而不只是单纯的容器部署方案。减少部署时间，降低云平台维护难度，提供一个有自愈功能的云平台。

(2)对比方案二，提供了容器应用管理功能，无须维护kubernetes复杂的yaml配置文件。

(3)从管理员角度看，平台服务之间采用容器方式隔离，便于维护，同时可以对每个容器进行cpu、内存、io的限制，扩展了平台的灵活性。容器启动速度快，容器故障替换对用户而言是无感知的。

(4)从管理员角度看，便于平滑升级或回滚云平台，测试人员便于模拟线上环境的一致性。解决由于安装时间不同，造成的包版本不一致的情况。

进一步地，本发明实施例可以广泛应用于私有云和/或专有云的部署以及后期的运维，开发人员可以基于容器化平台进行开发，测试人员也可以在线下快速模拟线上的环境，便于升级回滚测试。因此，本发明实施例具备广阔的应用前景。

本发明的实施例还提供了一种存储介质，所述存储介质可用于保存用于实现实施例中需要用到的的程序代码。可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络设备中的至少一个网络设备。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

具体地，图12是本发明实施例提供的一种服务器结构示意图，所述服务器结构可以用于运行上述容器化平台。该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processing units，CPU)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在服务器800上执行存储介质830中的一系列指令操作。服务器800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作***841，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。上述方法实施例所执行的步骤可以基于该图12所示的服务器结构。

需要说明的是：上述本发明实施例的先后顺序仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种容器化云平台，其特征在于：

所述云平台以基于容器技术的分布式架构构建而得，在所述分布式架构中，包括至少一个服务用容器，所述服务用容器用于运行一个目标服务，所述服务用容器与所述目标服务一一对应。

2.根据权利要求1所述的容器化云平台，其特征在于：

在所述容器化平台中运行不止一个服务，每个服务均具备自身对应的服务用容器，在所述容器化平台中通过维护服务用容器来维护服务。

3.根据权利要求1所述的容器化云平台，其特征在于：

为每个目标服务生成目标容器镜像；

对于目标服务的操作均通过操作所述目标服务对应的服务用容器实现，对于所述目标服务的修改通过修改所述目标容器镜像对应的配置文件实现。

4.根据权利要求1所述的容器化云平台，其特征在于：

所述容器化云平台基于容器组件、容器编排工具和应用管理工具实现，所述容器编排工具用于提供容器组件的运行环境并基于所述容器组件构建应用服务，所述应用管理工具用于以应用包的形式管理所述容器编排工具构建的应用服务。

5.根据权利要求4所述的容器化云平台，其特征在于，所述容器组件中的容器镜像采用分层设计，上层镜像的使用依赖所述上层镜像对应的下层镜像，容器镜像之间的层级关系均存储在所述应用管理工具之中。

6.根据权利要求4所述的容器化云平台，其特征在于，应用管理工具启动的方法包括：

在应用包存储仓库中查找需要的应用包；

把所述应用包实例化并部署到容器编排工具构建的应用服务之中。

7.根据权利要求6所述的容器化云平台，其特征在于：

在同一个集群上，一个应用包能够生成一个或多个实例，每个实例均能够被安装在容器编排工具构建的应用服务之中。

8.根据权利要求1所述的容器化云平台，其特征在于，在所述容器化云平台部署容器包括下述步骤：

根据目标服务拉取目标容器镜像；

部署基础设施容器服务；

部署分布式存储容器服务；

部署负载均衡和高可用套件容器服务；

部署所述容器化云平台中的容器。

9.根据权利要求8所述的容器化云平台，其特征在于：

所述基础设施容器服务包括网络时间服务和应用程序间的通信服务；

所述分布式存储容器服务包括网络存储服务和网络备份服务；

所述负载均衡和高可用套件容器服务包括应用程序代理服务、虚拟服务器和服务器状态检测服务。

10.一种计算机可读存储介质，用于存储程序，其特征在于，所述程序用于实现权利要求1中容器化云平台。

11.一种服务器，其特征在于，所述服务器用于运行权利要求1所述的容器化云平台。