CN107256178B - 一种容器管理平台 - Google Patents
一种容器管理平台 Download PDFInfo
- Publication number
- CN107256178B CN107256178B CN201710289847.XA CN201710289847A CN107256178B CN 107256178 B CN107256178 B CN 107256178B CN 201710289847 A CN201710289847 A CN 201710289847A CN 107256178 B CN107256178 B CN 107256178B
- Authority
- CN
- China
- Prior art keywords
- application
- instance
- scheduler
- user
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种容器管理平台，包括：调度器，为基于Mesos Restful API编写的应用调度框架，用于容器应用的生命周期管理；监控报警系统，用于监控容器的性能指标和应用的健康状态；日志处理系统，用于日志检索和日志统计；发布系统，用于实现应用的发布和回滚。本发明提供的一种容器管理平台，可以非常快速的定位一个服务的位置，又能高效利用集群资源下的多租户管理，还可以灵活的设置监控报警系统，并提供关联背景下的日志查看。
Description
技术领域
本发明涉及计算机领域，特别涉及一种容器管理平台。
背景技术
在一个平台即服务(PaaS)平台中，可能需要管理数量巨大的容器，而这些容器无规律的分布在不同的虚拟机中，同时还会根据外部命令或内部资源的改变而迁移到其他的虚拟机上，而应用编排、服务发现等功能的实现需要快速的定位一个服务的位置。同时，一个容器管理平台，需要保持高效率的利用集群资源，并且需要监控系统可以对容器的性能指标和应用的健康状态进行有效灵活的监控，并在出现问题时，可以提供更全面的日志信息以方便查看分析。
目前的容器管理平台，存在当容器数量增多，在大规模集群的情况下，定位速度较慢的缺点。且对多租户管理时，目前的容器管理平台对集群资源的利用率不高，同时传统的监控报警系统灵活度不高，需要较复杂的配置，复杂的配置导致了可靠性不高的风险，且传统的日志检索不直接提供关联背景下的日志信息，使得日志分析不够方便。
由此需要提出一种容器管理平台，既可以非常快速的定位一个服务的位置，又能高效利用集群资源下的多租户管理，还可以灵活的设置监控报警系统，并提供关联背景下的日志查看。
发明内容
本发明提供了一种容器管理平台，可以非常快速的定位一个服务的位置，又能高效利用集群资源下的多租户管理，还可以灵活的设置监控报警系统，并提供关联背景下的日志查看。
根据本发明提供的一种容器管理平台，包括：
调度器，为基于Mesos Restful API编写的应用调度框架，用于容器应用的生命周期管理；
监控报警系统，用于监控容器的性能指标和应用的健康状态；
日志处理系统，用于日志检索和日志统计；
发布系统，用于实现应用的发布和回滚。
优选的，所述调度器：
调度器的UI为固定的格式。
优选的，所述调度器：
调度器启动时指定所在集群ID，如果没有指定则使用默认的集群ID；
调度器发应用时需指定用户ID，如果没有指定则使用默认的用户ID，发应用的API里包含有USER字段；
调度器发应用时允许指定所发应用运行时的用户名，用于发应用的API里包含有RUNAS字段；
使用Borg把UID和GID同步到每台Borg Slave，用户的应用实例在Borg Slave上运行在真实的UID下，UID和GID的对应关系维护由外层维护。
优选的，所述调度器：
调度器还用于给实例打标签，所述标签为Docker的Label，所述标签包括：
TASK_ID；
APP_ID；
USER_ID，当有RUNAS字段时，该Label为RUNAS字段的内容；
CLUSTER_ID；
LOG_PATH，当该应用有文件日志时，该Label为应用在容器内输出的日志文件路径，为一条或多条路径。
调度器还按照task_id.app_id.user_id.cluster_id的方式来唯一标识每个应用的每个实例；
调度器命名task_id时按照整数从0开始连续分配；
调度器允许实例暴露多个端口，每个端口对应一个port_id，由调度器来命名port_id，port_id按照整数从0开始连续分配；
实例的名称在实例容错恢复后保持不变；
Mesos上的实例名字也命名为task_id.app_id.user_id.cluster_id；
Mesos调度起来的Docker容器的名字或标签命名为cluster_id.user_id.app_id.task_id。
优选的，所述调度器：
调度器用于容器应用全生命周期管理，包括：
发布应用：强制pull镜像；privileges权限；支持URI机制；停止信号指定；容器中增加marathon对应增加的环境变量，包括宿主机IP；
删除应用，分为两种种情况，一次性删除应用所有的实例，或应用实例收缩：
当应用实例个数收缩减少时，从task_id最大的实例开始删除；
支持优雅终止，每杀掉一个实例的时候，先发送SIGTERM信号给实例，在等待预设的时长后，检查实例是否结束，如果实例还未结束则杀掉实例；
更新应用，每个实例被更新后，要由健康检查机制来保证实例启动成功，如果更新后的实例健康检查不通过则对其进行重启，重启3次健康检查仍然失败则认为实例更新失败，进行回滚，包括三种情况:应用实例扩缩、全量更新和滚动更新：
实例扩缩：当应用实例个数扩张增加时，新增实例的task_id从已有实例最大task_id开始依次递增；
全量更新：老版本先全部删掉，再发布新版本；
滚动更新：老版本的实例依次更新为新版本，保证应用不停服；
滚动更新从第0个实例开始，滚动更新分批次进行；
每次滚动更新操作，需要调度器记录被更新的实例和未被更新的实例；
每次滚动更新完毕之前，无法对应用有其他滚动更新操作；
滚动更新开始之后，设置应用的状态为更新状态，当应用的实例没有全部更新完或全部回滚完时，无法对应用进行扩缩操作，而且调度器最多维护应用的两个版本，老版本和新版本，应用的所有实例更新完毕后结束应用的更新状态；
滚动更新的回滚，分为自动回滚和手动回滚：
自动回滚：滚动更新开始之后，只要有任意一个更新后的实例健康检查不成功，并重新调度超过3次，则回滚所有更新的实例到老版本，并结束应用的更新状态；
手动回滚：滚动更新开始之后，手动触发撤销滚动更新，所有更新的实例回滚到老版本；
滚动更新和实例扩缩时，对应用进行标记，标记出当前应用正在滚动更新和实例扩缩，除取消操作外，禁止用户对该应用任何操作；
查询应用；
容错恢复，调度器在发现某一应用的某一实例失效的时候，自动恢复失效的实例：
当应用的实例为可迁移的，自动恢复时允许把实例迁移到其他节点上重新运行；
当应用的实例绑定特定节点不可迁移时，自动恢复时必须先确认实例绑定的节点可用后再恢复实例。
优选的，所述调度器：
调度器还用于操作审计，记录下所有手动触发的操作的操作人：
调度器的编排文件里有user字段，用于记录应用的变动时实施该操作的user的ID。
优选的，所述调度器：
调度器还用于服务发现与负载均衡：
调度器将所有应用的所有实例的IP以及暴露的端口都写入Consul，并通过Consul的DNS功能查询到每个应用的每个实例的SRV记录，当实例有任何变化时，所述变化包括增加一个实例、删除一个实例、容错恢复或迁移一个实例，调度器把实例的IP和端口的变化同步到Consul，用以保证Consul里每个实例的SRV记录都是可访问的；
七层服务发现，通过http://task_id.app_id.user_id.cluster_id.dataman.io: 80/来访问某个实例的port0暴露的服务，http://task_id.app_id.user_id.cluster_ id.dataman.io:80/进行HTTP重定向到http://task_id.app_id.user_id.cluster_ id.dataman.io:port0/；
七层负载均衡，有三种方式对外提供七层负载均衡：
域名的方式，通过http://app_id.user_id.cluster_id.dataman.io:80/访问某个应用暴露的七层服务，app_id.user_id.cluster_id.dataman.io是域名解析到负载均衡器的IP地址，负载均衡器根据app_id.user_id.cluster_id区分不同的应用服务并把请求分发给应用服务的后台实例，如果应用的实例暴露多个端口，默认只支持port0对应的服务，该方式支持HTTPS实现；
端口的方式，通过http://loadbalancer_ip:app_port/访问某个应用暴露的七层服务，不同的应用通过在负载均衡器上占不同的端口来区分不同的服务，如果应用的实例暴露多个端口，则在负载均衡器上占多个端口；
事件机制加API的方式，调度器通过事件机制触发额外的模块调用F5的API来更新应用在F5上的后台实例；
四层服务发现，对于需要暴露四层服务的应用，该应用的每个实例保持固定IP，每个实例暴露的服务通过tcp://task_id.app_id.user_id.cluster_id.dataman.io:port_number访问，其中task_id.app_id.user_id.cluster_id.dataman.io为解析到该应用的某个实例的固定IP，port_number是该应用所暴露的端口，每个实例暴露一个或多个端口，通过task_id.app_id.user_id.cluster_id.dataman.io加上实例暴露的特定端口进行访问；
四层负载均衡，当四层应用实例扩缩之后，通过调度器的事件机制触发额外的模块调用F5的API来更新应用在F5上的后台实例；
负载均衡支持访问请求速率限制，包括每秒请求次数上限。
优选的，所述调度器：
调度器通过负载均衡器与健康检查机制实现应用实例的优雅启动和优雅终止，包括：
优雅启动，当应用做实例扩展、滚动更新时，负载均衡器不对未通过健康检查的实例分配流量；
优雅终止，当应用做实例收缩、滚动更新时，当一个实例要被关闭时，那负载均衡器暂停给该实例分配新请求，并等待该实例将已有的请求处理完毕，当负载均衡器确定该实例完全没有流量之后，调度器利用Mesos的优雅终止机制来关闭该实例。
优选的，所述的容器管理平台：
每一个容器具有独立的IP，实施为：
Docker Deamon层面以macvlan为driver创建出子网，并且保证docker run--ip之后的网络能够到达互通要求；
调度器下发4层应用时，通过API提供与实例数数量相等的IP数量；
调度器维护IP地址和TaskID之间关系，保证Task异常重启之后使用之前IP；
对4层应用不进行扩展和收缩操作；
调度器将应用划分为两类：replicates类型和fixed类型；其中，fixed类型不能扩缩和滚动升级；replicates类型面向七层应用，通过调度器实现负载服务发现和服务代理，负载均衡，调度器还提供此类应用的task地址元组{ip：port}，用于客户自有代理和负载均衡场景，服务之间和对外使用调度器提供的DNS服务器。
优选的，所述容器管理平台：
所述调度器，还用于在单集群模式下虚拟多租户；
所述监控报警系统，为基于表达式的监控报警系统；
所述日志处理系统，还用于在全文检索日志时进行单个日志行的上下文关联查看。
本发明提供的容器管理平台，可以非常快速的定位一个服务的位置，又能高效利用集群资源下的多租户管理，还可以灵活的设置监控报警系统，并提供关联背景下的日志查看。
本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
图1为本发明实施例中一种容器管理平台的示意图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。
在本发明的一个实施例中，如图1所示，一种容器管理平台，包括：
调度器，为基于Mesos Restful API编写的应用调度框架，用于容器应用的生命周期管理；
监控报警系统，用于监控容器的性能指标和应用的健康状态；
日志处理系统，用于日志检索和日志统计；
发布系统，用于实现应用的发布和回滚。
依据本发明提供的容器管理平台，通过对容器应用的生命周期管理和监控，实现了对容器应用的管理。
在本发明的一个实施例中，调度器：
调度器的UI为固定的格式。
依据本发明提供的容器管理平台，调度器的UI为固定的格式，这样应用即使尚未发布，也可以通过应用或实例的名称，拼出URL用以访问调度器UI来查询详情，比如通过
http://swan_ui/？task_id＝1,3,5&app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查询某个应用的某一个或几个实例；通过
http://swan_ui/？task_id＝0-4&app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查询某个应用的某范围内的实例；通过
http://swan_ui/？app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查询某个应用；通过http://swan_ui/？user_id＝xxxxx&cluster_id＝beijing查询某个用户在某个集群下的所有应用；通过http://swan_ui/？cluster_id＝beijing查询某个集群下的所有应用。
在本发明的一个实施例中，调度器：
调度器启动时指定所在集群ID，如果没有指定则使用默认的集群ID；
调度器发应用时需指定用户ID，如果没有指定则使用默认的用户ID，发应用的API里包含有USER字段；
调度器发应用时允许指定所发应用运行时的用户名，用于发应用的API里包含有RUNAS字段；
使用Borg把UID和GID同步到每台Borg Slave，用户的应用实例在Borg Slave上运行在真实的UID下，UID和GID的对应关系维护由外层维护。
依据本发明提供的容器管理平台，可以实现对集群ID和用户用户ID的同步维护，且在发应用时更加灵活。
在本发明的一个实施例中，调度器：
调度器还用于给实例打标签，所述标签为Docker的Label，所述标签包括：
TASK_ID；
APP_ID；
USER_ID，当有RUNAS字段时，该Label为RUNAS字段的内容；
CLUSTER_ID；
LOG_PATH，当该应用有文件日志时，该Label为应用在容器内输出的日志文件路径，为一条或多条路径。
调度器还按照task_id.app_id.user_id.cluster_id的方式来唯一标识每个应用的每个实例；
调度器命名task_id时按照整数从0开始连续分配；
调度器允许实例暴露多个端口，每个端口对应一个port_id，由调度器来命名port_id，port_id按照整数从0开始连续分配；
实例的名称在实例容错恢复后保持不变；
Mesos上的实例名字也命名为task_id.app_id.user_id.cluster_id；
Mesos调度起来的Docker容器的名字或标签命名为cluster_id.user_id.app_id.task_id。
依据本发明提供的容器管理平台，通过给实例打标签，可以方便快速的对实例进行管理，在大规模集群下，可以非常快速的定位一个应用和实例的位置。
在本发明的一个实施例中，调度器：
调度器用于容器应用全生命周期管理，包括：
发布应用：强制pull镜像；privileges权限；支持URI机制；停止信号指定；容器中增加marathon对应增加的环境变量，包括宿主机IP；
删除应用，分为两种种情况，一次性删除应用所有的实例，或应用实例收缩：
当应用实例个数收缩减少时，从task_id最大的实例开始删除。某个应用有5个实例，task_id为0、1、2、3、4，当实例个数要收缩为3个时，要把task_id是4和3的两个实例删除掉，不能任意删除实例，而是通过实例收缩来删除应用实例；
支持优雅终止，每杀掉一个实例的时候，先发送SIGTERM信号给实例，在等待预设的时长后，检查实例是否结束，如果实例还未结束则杀掉实例；
更新应用，每个实例被更新后，要由健康检查机制来保证实例启动成功，如果更新后的实例健康检查不通过则对其进行重启，重启3次健康检查仍然失败则认为实例更新失败，进行回滚，包括三种情况:应用实例扩缩、全量更新和滚动更新：
实例扩缩：当应用实例个数扩张增加时，新增实例的task_id从已有实例最大task_id开始依次递增，某个应用有3个实例，task_id为0、1、2，当实例个数要扩张为5个时，新增的两个实例的task_id分别为3和4；
全量更新：老版本先全部删掉，再发布新版本；
滚动更新：老版本的实例依次更新为新版本，保证应用不停服；
滚动更新从第0个实例开始，滚动更新分批次进行，每次选择要更新几个实例，某应用有5个实例，先更新一个，把第0个实例更新，再更新两个，把第1个和第2个实例更新，最后再更新两个，把第3个和第4个实例更新；
每次滚动更新操作，需要调度器记录被更新的实例和未被更新的实例；
滚动更新，更新某应用的3个实例(该应用至少有3个以上实例)，只有当3个更新实例的健康检查成功之后，并保持健康至少一分钟(该等待时间可配置)以上，才算这3个实例更新完毕，而且每次滚动更新完毕之前，无法对应用有其他滚动更新操作；
滚动更新开始之后，设置应用的状态为更新状态，当应用的实例没有全部更新完或全部回滚完时，无法对应用进行扩缩操作，而且调度器最多维护应用的两个版本，老版本和新版本，应用的所有实例更新完毕后结束应用的更新状态；
滚动更新的回滚，分为自动回滚和手动回滚：
自动回滚：滚动更新开始之后，只要有任意一个更新后的实例健康检查不成功，并重新调度超过3次，则回滚所有更新的实例到老版本，并结束应用的更新状态；
手动回滚：滚动更新开始之后，手动触发撤销滚动更新，所有更新的实例回滚到老版本；
滚动更新和实例扩缩时，对应用进行标记，标记出当前应用正在滚动更新和实例扩缩，除取消操作外，禁止用户对该应用任何操作；
查询应用；
容错恢复，调度器在发现某一应用的某一实例失效的时候，自动恢复失效的实例：
当应用的实例为可迁移的，自动恢复时允许把实例迁移到其他节点上重新运行；
当应用的实例绑定特定节点不可迁移时，如MySQL等长时间有状态的应用，自动恢复时必须先确认实例绑定的节点可用后再恢复实例。
依据本发明提供的容器管理平台，可以实现对容器应用的全生命周期的管理，能够更安全和稳定的运行应用。
在本发明的一个实施例中，调度器：
调度器还用于操作审计，记录下所有手动触发的操作的操作人：
调度器的编排文件里有user字段，用于记录应用的变动时实施该操作的user的ID。
依据本发明提供的容器管理平台，可以实现对操作的审计，实现对整个平台的更好的管理。
在本发明的一个实施例中，调度器：
调度器还用于服务发现与负载均衡：
调度器将所有应用的所有实例的IP以及暴露的端口都写入Consul，并通过Consul的DNS功能查询到每个应用的每个实例的SRV记录，当实例有任何变化时，所述变化包括增加一个实例、删除一个实例、容错恢复或迁移一个实例，调度器把实例的IP和端口的变化同步到Consul，用以保证Consul里每个实例的SRV记录都是可访问的；
七层服务发现，通过http://task_id.app_id.user_id.cluster_id.dataman.io: 80/来访问某个实例的port0暴露的服务，http://task_id.app_id.user_id.cluster_ id.dataman.io:80/进行HTTP重定向到http://task_id.app_id.user_id.cluster_ id.dataman.io:port0/；
七层负载均衡，有三种方式对外提供七层负载均衡：
域名的方式，通过http://app_id.user_id.cluster_id.dataman.io:80/访问某个应用暴露的七层服务，app_id.user_id.cluster_id.dataman.io是域名解析到负载均衡器的IP地址，负载均衡器根据app_id.user_id.cluster_id区分不同的应用服务并把请求分发给应用服务的后台实例，如果应用的实例暴露多个端口，默认只支持port0对应的服务，该方式支持HTTPS实现；
端口的方式，通过http://loadbalancer_ip:app_port/访问某个应用暴露的七层服务，不同的应用通过在负载均衡器上占不同的端口来区分不同的服务，如果应用的实例暴露多个端口，则在负载均衡器上占多个端口；
事件机制加API的方式，调度器通过事件机制触发额外的模块调用F5的API来更新应用在F5上的后台实例；
四层服务发现，对于需要暴露四层服务的应用，该应用的每个实例保持固定IP，每个实例暴露的服务通过tcp://task_id.app_id.user_id.cluster_id.dataman.io:port_number访问，其中task_id.app_id.user_id.cluster_id.dataman.io为解析到该应用的某个实例的固定IP，port_number是该应用所暴露的端口，每个实例暴露一个或多个端口，通过task_id.app_id.user_id.cluster_id.dataman.io加上实例暴露的特定端口进行访问；
四层负载均衡，当四层应用实例扩缩之后，通过调度器的事件机制触发额外的模块调用F5的API来更新应用在F5上的后台实例；
负载均衡支持访问请求速率限制，包括每秒请求次数上限。
依据本发明提供的容器管理平台，可以实现服务的发现和负载的均衡，能够更高效的利用硬件资源。
在本发明的一个实施例中，调度器：
调度器通过负载均衡器与健康检查机制实现应用实例的优雅启动和优雅终止，包括：
优雅启动，当应用做实例扩展、滚动更新时，负载均衡器不对未通过健康检查的实例分配流量；
优雅终止，当应用做实例收缩、滚动更新时，当一个实例要被关闭时，那负载均衡器暂停给该实例分配新请求，并等待该实例将已有的请求处理完毕，当负载均衡器确定该实例完全没有流量之后，调度器利用Mesos的优雅终止机制来关闭该实例。
依据本发明提供的容器管理平台，通过优雅启动和优雅终止，能够更稳定的实现应用的扩展、收缩和更新。
在本发明的一个实施例中，容器管理平台：
每一个容器具有独立的IP，实施为：
Docker Deamon层面以macvlan为driver创建出子网，并且保证docker run--ip之后的网络能够到达互通要求；
调度器下发4层应用时，通过API提供与实例数数量相等的IP数量；
调度器维护IP地址和TaskID之间关系，保证Task异常重启之后使用之前IP；
对4层应用不进行扩展和收缩操作；
调度器将应用划分为两类：replicates类型和fixed类型；其中，fixed类型不能扩缩和滚动升级；replicates类型面向七层应用，通过调度器实现负载服务发现和服务代理，负载均衡，调度器还提供此类应用的task地址元组{ip：port}，用于客户自有代理和负载均衡场景，服务之间和对外使用调度器提供的DNS服务器。
依据本发明提供的容器管理平台，通过一容器一IP的方式，能够非常快速的定位一个服务的位置，方便对容器和服务的管理。
在本发明的一个实施例中，的容器管理平台：
调度器，还用于在单集群模式下虚拟多租户；
监控报警系统，为基于表达式的监控报警系统；
日志处理系统，调度器通过Http GET链接访问日志处理系统，参数通过URI传递，日志处理系统在全文检索日志时进行单个日志行的上下文关联查看。
依据本发明提供的容器管理平台，通过使用在单集群模式下的虚拟多租户的管理模式，实现了高效利用集群资源下的多租户管理；通过使用基于表达式的监控报警系统，实现了对监控报警系统的灵活的设置，降低了设置监控报警系统的难度，进而降低了监控报警系统的可靠性不高的潜在风险；通过在全文检索日志时进行单个日志行的上下文关联查看，可以方便的在关联背景下查看分析日志信息。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (9)
1.一种容器管理平台，其特征在于，包括：
调度器，为基于Mesos Restful API编写的应用调度框架，用于容器应用的生命周期管理；
监控报警系统，用于监控容器的性能指标和应用的健康状态；
日志处理系统，用于日志检索和日志统计；
发布系统，用于实现应用的发布和回滚；
所述调度器还用于服务发现与负载均衡：
调度器将所有应用的所有实例的IP以及暴露的端口都写入Consul，并通过Consul的DNS功能查询到每个应用的每个实例的SRV记录，当实例有任何变化时，所述变化包括增加一个实例、删除一个实例、容错恢复或迁移一个实例，调度器把实例的IP和端口的变化同步到Consul，用以保证Consul里每个实例的SRV记录都是可访问的；
七层服务发现，通过http://task_id.app_id.user_id.cluster_id.dataman.io:80/来访问某个实例的port0暴露的服务，http://task_id.app_id.user_id.cluster_ id.dataman.io:80/进行HTTP重定向到http://task_id.app_id.user_id.cluster_ id.dataman.io:port0/；
七层负载均衡，有三种方式对外提供七层负载均衡：
域名的方式，通过http://app_id.user_id.cluster_id.dataman.io:80/访问某个应用暴露的七层服务，app_id.user_id.cluster_id.dataman.io是域名解析到负载均衡器的IP地址，负载均衡器根据app_id.user_id.cluster_id区分不同的应用服务并把请求分发给应用服务的后台实例，如果应用的实例暴露多个端口，默认只支持port0对应的服务，该方式支持HTTPS实现；
端口的方式，通过http://loadbalancer_ip:app_port/访问某个应用暴露的七层服务，不同的应用通过在负载均衡器上占不同的端口来区分不同的服务，如果应用的实例暴露多个端口，则在负载均衡器上占多个端口；
事件机制加API的方式，调度器通过事件机制触发额外的模块调用F5 BIG-IP的API来更新应用在F5 BIG-IP上的后台实例；
四层服务发现，对于需要暴露四层服务的应用，该应用的每个实例保持固定IP，每个实例暴露的服务通过tcp://task_id.app_id.user_id.cluster_id.dataman.io:port_number访问，其中task_id.app_id.user_id.cluster_id.dataman.io为解析到该应用的某个实例的固定IP，port_number是该应用所暴露的端口，每个实例暴露一个或多个端口，通过task_id.app_id.user_id.cluster_id.dataman.io加上实例暴露的特定端口进行访问；
四层负载均衡，当四层应用实例扩缩之后，通过调度器的事件机制触发额外的模块调用F5 BIG-IP的API来更新应用在F5 BIG-IP上的后台实例；
负载均衡支持访问请求速率限制，包括每秒请求次数上限。
2.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器的UI为固定的格式。
3.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器启动时指定所在集群ID，如果没有指定则使用默认的集群ID；
调度器发应用时需指定用户ID，如果没有指定则使用默认的用户ID，发应用的API里包含有USER字段；
调度器发应用时允许指定所发应用运行时的用户名，用于发应用的API里包含有RUNAS字段；
使用Borg把UID和GID同步到每台Borg Slave，用户的应用实例在Borg Slave上运行在真实的UID下，UID和GID的对应关系维护由外层维护。
4.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器还用于给实例打标签，所述标签为Docker的Label，所述标签包括：
TASK_ID；
APP_ID；
USER_ID，当有RUNAS字段时，该Label为RUNAS字段的内容；
CLUSTER_ID；
LOG_PATH，当该应用有文件日志时，该Label为应用在容器内输出的日志文件路径，为一条或多条路径，
调度器还按照task_id.app_id.user_id.cluster_id的方式来唯一标识每个应用的每个实例；
调度器命名task_id时按照整数从0开始连续分配；
调度器允许实例暴露多个端口，每个端口对应一个port_id，由调度器来命名port_id，port_id按照整数从0开始连续分配；
实例的名称在实例容错恢复后保持不变；
Mesos上的实例名字也命名为task_id.app_id.user_id.cluster_id；
Mesos调度起来的Docker容器的名字或标签命名为cluster_id.user_id.app_id.task_id。
5.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器用于容器应用全生命周期管理，包括：
发布应用：强制pull镜像；privileges权限；支持URI机制；停止信号指定；容器中增加marathon对应增加的环境变量，包括宿主机IP；
删除应用，分为两种情况，一次性删除应用所有的实例，或应用实例收缩：
当应用实例个数收缩减少时，从task_id最大的实例开始删除；
支持优雅终止，每杀掉一个实例的时候，先发送SIGTERM信号给实例，在等待预设的时长后，检查实例是否结束，如果实例还未结束则杀掉实例；
更新应用，每个实例被更新后，要由健康检查机制来保证实例启动成功，如果更新后的实例健康检查不通过则对其进行重启，重启3次健康检查仍然失败则认为实例更新失败，进行回滚，包括三种情况:应用实例扩缩、全量更新和滚动更新：
实例扩缩：当应用实例个数扩张增加时，新增实例的task_id从已有实例最大task_id开始依次递增；
全量更新：老版本先全部删掉，再发布新版本；
滚动更新：老版本的实例依次更新为新版本，保证应用不停服；
滚动更新从第0个实例开始，滚动更新分批次进行；
每次滚动更新操作，需要调度器记录被更新的实例和未被更新的实例；
每次滚动更新完毕之前，无法对应用有其他滚动更新操作；
滚动更新开始之后，设置应用的状态为更新状态，当应用的实例没有全部更新完或全部回滚完时，无法对应用进行扩缩操作，而且调度器最多维护应用的两个版本，老版本和新版本，应用的所有实例更新完毕后结束应用的更新状态；
滚动更新的回滚，分为自动回滚和手动回滚：
自动回滚：滚动更新开始之后，只要有任意一个更新后的实例健康检查不成功，并重新调度超过3次，则回滚所有更新的实例到老版本，并结束应用的更新状态；
手动回滚：滚动更新开始之后，手动触发撤销滚动更新，所有更新的实例回滚到老版本；
滚动更新和实例扩缩时，对应用进行标记，标记出当前应用正在滚动更新和实例扩缩，除取消操作外，禁止用户对该应用任何操作；
查询应用；
容错恢复，调度器在发现某一应用的某一实例失效的时候，自动恢复失效的实例：
当应用的实例为可迁移的，自动恢复时允许把实例迁移到其他节点上重新运行；
当应用的实例绑定特定节点不可迁移时，自动恢复时必须先确认实例绑定的节点可用后再恢复实例。
6.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器还用于操作审计，记录下所有手动触发的操作的操作人：
调度器的编排文件里有user字段，用于记录应用的变动时实施该操作的user的ID。
7.如权利要求1所述的容器管理平台，所述调度器，其特征在于：
调度器通过负载均衡器与健康检查机制实现应用实例的优雅启动和优雅终止，包括：
优雅启动，当应用做实例扩展、滚动更新时，负载均衡器不对未通过健康检查的实例分配流量；
优雅终止，当应用做实例收缩、滚动更新时，当一个实例要被关闭时，那负载均衡器暂停给该实例分配新请求，并等待该实例将已有的请求处理完毕，当负载均衡器确定该实例完全没有流量之后，调度器利用Mesos的优雅终止机制来关闭该实例。
8.如权利要求1所述的容器管理平台，其特征在于：
每一个容器具有独立的IP，实施为：
Docker Deamon层面以macvlan为driver创建出子网，并且保证docker run--ip之后的网络能够到达互通要求；
调度器下发4层应用时，通过API提供与实例数数量相等的IP数量；
调度器维护IP地址和TaskID之间关系，保证Task异常重启之后使用之前IP；
对4层应用不进行扩展和收缩操作；
调度器将应用划分为两类：replicates类型和fixed类型；其中，fixed类型不能扩缩和滚动升级；replicates类型面向七层应用，通过调度器实现负载服务发现和服务代理，负载均衡，调度器还提供此类应用的task地址元组{ip：port}，用于客户自有代理和负载均衡场景，服务之间和对外使用调度器提供的DNS服务器。
9.如权利要求1所述的容器管理平台，其特征在于：
所述调度器，还用于在单集群模式下虚拟多租户；
所述监控报警系统，为基于表达式的监控报警系统；
所述日志处理系统，还用于在全文检索日志时进行单个日志行的上下文关联查看。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710289847.XA CN107256178B (zh) | 2017-04-27 | 2017-04-27 | 一种容器管理平台 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710289847.XA CN107256178B (zh) | 2017-04-27 | 2017-04-27 | 一种容器管理平台 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107256178A CN107256178A (zh) | 2017-10-17 |
| CN107256178B true CN107256178B (zh) | 2019-12-17 |
Family
ID=60027889
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710289847.XA Active CN107256178B (zh) | 2017-04-27 | 2017-04-27 | 一种容器管理平台 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107256178B (zh) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108063791A (zh) * | 2017-11-01 | 2018-05-22 | 千寻位置网络有限公司 | 基于动态路由的应用部署方法 |
| CN109829665B (zh) * | 2017-11-23 | 2023-11-07 | 菜鸟智能物流控股有限公司 | 物品拣选调度请求的处理方法及相关设备 |
| CN109840132B (zh) * | 2017-11-27 | 2021-05-14 | 华为技术有限公司 | 容器的编排方法、装置及存储介质 |
| CN110099076A (zh) * | 2018-01-29 | 2019-08-06 | 中兴通讯股份有限公司 | 一种镜像拉取的方法及其系统 |
| CN110213309B (zh) * | 2018-03-13 | 2022-02-01 | 腾讯科技（深圳）有限公司 | 一种绑定关系管理的方法、设备及存储介质 |
| CN108616599B (zh) * | 2018-05-11 | 2021-10-29 | 北京辰森世纪科技股份有限公司 | 应用服务注册、更新的方法及装置 |
| CN108737215A (zh) * | 2018-05-29 | 2018-11-02 | 郑州云海信息技术有限公司 | 一种云数据中心Kubernetes集群容器健康检查的方法和装置 |
| CN108810013B (zh) * | 2018-07-02 | 2021-12-24 | 上海浪潮云计算服务有限公司 | 一种基于容器的服务访问方法 |
| CN109445802B (zh) * | 2018-09-25 | 2022-08-26 | 众安信息技术服务有限公司 | 基于容器的私有化Paas平台及其发布应用的方法 |
| CN109302483B (zh) * | 2018-10-17 | 2021-02-02 | 网宿科技股份有限公司 | 一种应用程序的管理方法及系统 |
| CN109361780A (zh) * | 2018-10-23 | 2019-02-19 | 杭州能链科技有限公司 | 获取服务实例的方法、系统以及存储介质 |
| CN109343963B (zh) * | 2018-10-30 | 2021-12-07 | 杭州数梦工场科技有限公司 | 一种容器集群的应用访问方法、装置及相关设备 |
| CN109451065B (zh) * | 2018-12-26 | 2021-06-01 | 中电福富信息科技有限公司 | 一种软负载均衡分流自动化系统及其运行方法 |
| US10922125B2 (en) | 2019-06-13 | 2021-02-16 | Micro Focus Llc | Capability liveness of containerized services |
| CN112199247B (zh) * | 2019-07-08 | 2022-07-01 | 中国移动通信集团浙江有限公司 | 一种无业务状态下Docker容器进程活性的检查方法及装置 |
| CN110457114B (zh) * | 2019-07-24 | 2020-11-27 | 杭州数梦工场科技有限公司 | 应用集群部署方法及装置 |
| CN112583687B (zh) * | 2019-09-30 | 2022-05-27 | 北京国双科技有限公司 | 流量控制方法、系统、计算机设备以及存储介质 |
| CN111221714A (zh) * | 2020-01-02 | 2020-06-02 | 广州虎牙科技有限公司 | 服务拨测方法、装置、系统及存储介质 |
| CN111800458B (zh) * | 2020-05-22 | 2021-04-23 | 浙商银行股份有限公司 | 一种Kubernetes容器云平台的动态负载均衡方法及系统 |
| CN112416575A (zh) * | 2020-11-02 | 2021-02-26 | 中关村科学城城市大脑股份有限公司 | 一种用于城市大脑ai计算的算法模型调度系统及方法 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103269367A (zh) * | 2013-05-16 | 2013-08-28 | 北京邮电大学 | 一种PaaS云平台能力组件的发布系统及方法 |
| CN104639374A (zh) * | 2015-03-03 | 2015-05-20 | 上海瀚银信息技术有限公司 | 一种应用程序部署管理系统 |
| CN105893205A (zh) * | 2015-11-20 | 2016-08-24 | 乐视云计算有限公司 | 监控基于docker创建的container的方法及系统 |
| CN106020930A (zh) * | 2016-05-13 | 2016-10-12 | 深圳市中润四方信息技术有限公司 | 一种基于应用容器的应用管理方法及系统 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070061445A1 (en) * | 2005-09-13 | 2007-03-15 | Deganaro Louis R | Cooperative routing between traffic control device and multi-server application |
| US10541811B2 (en) * | 2015-03-02 | 2020-01-21 | Salesforce.Com, Inc. | Systems and methods for securing data |
-
2017
- 2017-04-27 CN CN201710289847.XA patent/CN107256178B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103269367A (zh) * | 2013-05-16 | 2013-08-28 | 北京邮电大学 | 一种PaaS云平台能力组件的发布系统及方法 |
| CN104639374A (zh) * | 2015-03-03 | 2015-05-20 | 上海瀚银信息技术有限公司 | 一种应用程序部署管理系统 |
| CN105893205A (zh) * | 2015-11-20 | 2016-08-24 | 乐视云计算有限公司 | 监控基于docker创建的container的方法及系统 |
| CN106020930A (zh) * | 2016-05-13 | 2016-10-12 | 深圳市中润四方信息技术有限公司 | 一种基于应用容器的应用管理方法及系统 |
Non-Patent Citations (4)
| Title |
|---|
| 基于Restful和OSGI的Web应用转换容器的研究与实现;李林蓉;《中国优秀硕士学位论文全文数据库 信息科技辑 （月刊 ）》;20151215(第12期);I139-80 * |
| 数人云开源Mesos调度器Swan;CB;《http://soft.chinabyte.com/database/453/13956453.shtml》;20161109;1-2 * |
| 数人云开源Mesos调度器Swan;优云数智;《http://www.sohu.com/a/118643145_332175》;20161110;1-2 * |
| 解析Docker如何催生新一代PaaS;王璞;《软件和集成电路》;20160731;74-76 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107256178A (zh) | 2017-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107256178B (zh) | 一种容器管理平台 | |
| US10747714B2 (en) | Scalable distributed data store | |
| US11663085B2 (en) | Application backup and management | |
| US20240168673A1 (en) | Methods and systems to interface between a multi-site distributed storage system and an external mediator to efficiently process events related to continuity | |
| US11966307B2 (en) | Re-aligning data replication configuration of primary and secondary data serving entities of a cross-site storage solution after a failover event | |
| US11550679B2 (en) | Methods and systems for a non-disruptive planned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system | |
| US11709743B2 (en) | Methods and systems for a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system | |
| US10929247B2 (en) | Automatic creation of application-centric extended metadata for a storage appliance | |
| US20120311377A1 (en) | Replaying jobs at a secondary location of a service | |
| CN103164254A (zh) | 用于维持镜像虚拟环境中存储装置的一致性的方法和系统 | |
| US11200212B2 (en) | Documenting modifications to configuration file | |
| US11726967B2 (en) | Systems and methods for restoring an interface to a global file system | |
| US9747291B1 (en) | Non-disruptive upgrade configuration translator | |
| US11663093B2 (en) | Automated development of recovery plans | |
| EP3942397A1 (en) | Timestamp consistency for synchronous replication | |
| US10474696B2 (en) | Replication groups for content libraries | |
| CN117632374A (zh) | 容器镜像的读取方法、介质、装置和计算设备 | |
| US11093465B2 (en) | Object storage system with versioned meta objects | |
| US11079960B2 (en) | Object storage system with priority meta object replication | |
| US20150074116A1 (en) | Indexing attachable applications for computing systems | |
| US10185759B2 (en) | Distinguishing event type | |
| US11074002B2 (en) | Object storage system with meta object replication | |
| JP6568232B2 (ja) | 計算機システム、及び、装置の管理方法 | |
| US20200348843A1 (en) | Distributor data map for storage volume replication across multiple data centers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220516 Address after: 100000 students at No. 15, Xueyuan Road, study abroad service center of the Ministry of education, Haidian District, Beijing Patentee after: Wang Pu Address before: 100020 806-807, 8th floor, building a, No. 13, Wangjing Dongyuan Fourth District, Chaoyang District, Beijing Patentee before: BEIJING SHUREN TECHNOLOGY CO.,LTD. |