CN111857975A - 一种服务更新方法、装置、设备及介质 - Google Patents

一种服务更新方法、装置、设备及介质 Download PDF

Info

Publication number
CN111857975A
CN111857975A CN202010752556.1A CN202010752556A CN111857975A CN 111857975 A CN111857975 A CN 111857975A CN 202010752556 A CN202010752556 A CN 202010752556A CN 111857975 A CN111857975 A CN 111857975A
Authority
CN
China
Prior art keywords
target
service
docker container
pod
state
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.)
Pending
Application number
CN202010752556.1A
Other languages
English (en)
Inventor
程鸿志
范渊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
DBAPPSecurity Co Ltd
Hangzhou Dbappsecurity Technology Co Ltd
Original Assignee
Hangzhou Dbappsecurity Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou Dbappsecurity Technology Co Ltd filed Critical Hangzhou Dbappsecurity Technology Co Ltd
Priority to CN202010752556.1A priority Critical patent/CN111857975A/zh
Publication of CN111857975A publication Critical patent/CN111857975A/zh
Pending legal-status Critical Current

Links

Images

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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本申请公开了一种服务更新方法、装置、设备、介质，该方法包括：获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；运行所述目标Docker容器，并检测所述目标Docker容器的运行状态；如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。这样在更新服务的过程中，可以正常提供服务，提升了用户体验。

Description

一种服务更新方法、装置、设备及介质
技术领域
本申请涉及计算机技术领域，特别涉及一种服务更新方法、装置、设备、介质。
背景技术
越来越多的企业选择Docker容器去部署产品项目，而在各种服务部署的过程中，需要对服务进行更新，发布一个新版本的服务来代替原有的旧服务，以便利用新版本的服务继续提供服务。目前，Docker容器的服务更新方法主要是先利用新版本替换旧版本，然后再重启整个Docker容器，以便新版本的服务可以正常运行，但是这会造成在利用新版本替换旧版本到整个Docker容器重启并进入正常工作状态之前接收到的服务请求得不到应答，造成无法正常提供服务，影响用户体验。
发明内容
有鉴于此，本申请的目的在于提供一种服务更新方法、装置、设备、介质，能够在更新服务的过程中，可以正常提供服务，提升了用户体验。其具体方案如下：
第一方面，本申请公开了一种服务更新方法，应用于Kubernetes集群，包括：
获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；
根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；
运行所述目标Docker容器，并检测所述目标Docker容器的运行状态；
如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
可选的，所述根据所述服务创建请求创建目标pod，包括：
处理所述服务创建请求，以创建所述目标pod；
为所述目标pod分配目标主机；
将所述目标pod与所述目标主机绑定；
执行目标处理操作，以完成所述目标pod创建。
可选的，所述为所述目标pod分配目标主机，包括：
根据预先获取到的第一预设规则从所述Kubernetes集群中的各个主机中确定出预选主机；
根据预先获取到的第二预设规则对所述预选主机中的各个主机进行打分；
将所述预选主机中得分最高的主机确定为所述目标主机。
可选的，所述获取到的请求所述目标服务的流量接入所述目标Docker容器中之后，还包括：
根据所述Kubernetes集群的负载控制所述目标pod的副本数量。
可选的，所述检测所述目标Docker容器的运行状态，包括：
利用预设请求确定所述目标Docker容器的启动状态；
如果所述目标Docker容器正常启动，则确定所述目标Docker容器的服务准备状态；
根据所述服务准备状态确定所述目标Docker容器的运行状态。
可选的，所述利用预设请求确定所述目标Docker容器的启动状态，包括：
向所述目标服务对应的服务站点发送HTTP Get请求，其中，所述HTTP Get请求中包括所述目标Docker容器的信息；
接收所述服务站点返回的响应码；
根据所述响应码确定所述目标Docker容器的启动状态。
可选的，所述确定所述目标Docker容器的服务准备状态，包括：
在所述目标Docker容器对应的目标端口上建立TCP Socket连接，其中，所述目标端口为所述目标主机上的端口；
如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态；
相应的，所述根据所述服务准备状态确定所述目标Docker容器的运行状态，包括：
如果所述服务准备状态为服务准备就绪状态，则将所述目标Docker容器的运行状态确定为正常运行状态。
第二方面，本申请公开了一种服务更新装置，应用于Kubernetes集群，包括：
信息获取模块，用于获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；
Pod创建模块，用于根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；
容器运行模块，用于运行所述目标Docker容器；
容器运行状态确定模块，用于检测所述目标Docker容器的运行状态；
流量分发模块，用于在所述目标Docker容器处于正常运行状态时，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
第三方面，本申请公开了一种电子设备，包括：
存储器和处理器；
其中，所述存储器，用于存储计算机程序；
所述处理器，用于执行所述计算机程序，以实现前述公开的服务更新方法。
第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的服务更新方法。
可见，本申请应用于Kubernetes集群，先获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据，然后根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器，再运行所述目标Docker容器，并检测所述目标Docker容器的运行状态，如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。这样先创建目标pod，目标pod上运行提供新版本的目标服务的目标Docker容器，然后启动目标Docker容器并检测目标Docker容器的运行状态，在目标Docker容器处于正常运行状态之后，便可以将请求所述目标服务的流量转接到目标Docker容器，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，而在服务更新期间，依然由原Docker容器提供旧版本的目标服务，这样在服务更新期间正常提供服务，提升了用户体验。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请公开的一种服务更新方法流程图；
图2为本申请公开的一种具体的服务更新方法流程图；
图3为本申请公开的一种服务更新装置结构示意图；
图4为本申请公开的一种电子设备结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
目前，Docker容器的服务更新方法主要是先利用新版本替换旧版本，然后再重启整个Docker容器，以便新版本的服务可以正常运行，但是这会造成在利用新版本替换旧版本到整个Docker容器重启并进入正常工作状态之前接收到的服务请求得不到应答，造成无法正常提供服务，影响用户体验。有鉴于此，本身请提出了一种服务更新方法，能够在更新服务的过程中，可以正常提供服务，提升了用户体验。
参见图1所示，本申请实施例公开了一种服务更新方法，应用于Kubernetes集群，该方法包括：
步骤S11：获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据。
在实际应用中，当需要对集群中的目标服务进行更新时，需要先获取服务创建请求，其中，所述服务创建请求中包括用于更新所述目标服务的数据。也即，在需要对集群中的目标服务进行更新时，先由用户输入服务创建请求，相应的，就需要获取所述服务创建请求，以便根据所述服务创建请求创建新版本的目标服务，以更新旧版本的目标服务。
步骤S12：根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器。
可以理解的是，在获取到所述服务创建请求之后，还需要根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的目标服务的目标Docker容器。Pod可以由Kubernete直接管理，在pod上运行一个容器之后，便可以将pod视为单个封装的容器。
在实际的应用中，根据所述服务创建请求创建目标pod，包括：处理所述服务创建请求，以创建所述目标pod；为所述目标pod分配目标主机；将所述目标pod与所述目标主机绑定；执行目标处理操作，以完成所述目标pod创建。
具体的，可以通过API(Application Programming Interface，应用程序接口)Server的Restful API，也可以使用kubectl命令行工具获取到所述服务创建请求。所述服务创建请求的数据类型可以是JSON(JavaScriptObject Notation，JS对象简谱)和YAML。API Server处理所述服务创建请求，创建目标pod并存储pod数据到etcd。调度器通过APIServer查看未绑定的Pod，尝试为所述目标pod分配目标主机。确定出所述目标主机之后，将所述目标主机和所述目标pod绑定。根据所述目标主机的信息将所述目标pod存储到etcd中所述目标主机对应的boundpod对象下，以便运行在每个工作节点上的kubelet定期与etcd同步boundpod信息，并发现应该在自身工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动所述目标pod内的容器，以完成所述目标pod创建。在Kubernetes集群中，scheduler会调用API Server的API在etcd中创建一个boundpod对象，一个boundpod对象描述在一个工作节点上绑定运行的所有pod信息，而运行在每个工作节点上的kubelet会定期与etcd同步boundpod信息，并发现应该在自身工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动相应的容器。
在为所述目标pod分配目标主机时，包括：根据预先获取到的第一预设规则从所述Kubernetes集群中的各个主机中确定出预选主机；根据预先获取到的第二预设规则对所述预选主机中的各个主机进行打分；将所述预选主机中得分最高的主机确定为所述目标主机。
具体的，就是由调度器用第一预设规则对所述Kubernetes集群中的各个主机进行过滤，过滤掉不符合要求的主机，得到预选主机。比如所述目标pod指定了所需要的资源量，那么可用资源比所述目标pod需要的资源量少的主机会被过滤掉。再根据第二预设规则对所述预选主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如使用最低负载的主机等。将所述预选主机中得分最高的主机确定为所述目标主机。
步骤S13：运行所述目标Docker容器，并检测所述目标Docker容器的运行状态。
在创建完成所述目标pod之后，还需要运行所述目标Docker容器，并检测所述目标Docker容器的运行状态。也即，需要目标Docker容器，并检测所述目标Docker容器的运行状态是否处于正常运行状态，以便确定所述目标Docker容器是否可以正常提供新版本的所述目标服务。
步骤S14：如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
在对所述目标Docker容器的运行状态进行检测之后，如果所述目标Docker容器处于正常运行状态，则表示所述目标Docker容器可以正常提供服务，所以可以将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。并停止运行所述原Docker容器。
可见，本申请应用于Kubernetes集群，先获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据，然后根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器，再运行所述目标Docker容器，并检测所述目标Docker容器的运行状态，如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。这样先创建目标pod，目标pod上运行提供新版本的目标服务的目标Docker容器，然后启动目标Docker容器并检测目标Docker容器的运行状态，在目标Docker容器处于正常运行状态之后，便可以将请求所述目标服务的流量转接到目标Docker容器，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，而在服务更新期间，依然由原Docker容器提供旧版本的目标服务，这样在服务更新期间正常提供服务，提升了用户体验。
参见图2所示，本申请实施例公开了一种具体的服务更新方法，应用于Kubernetes集群，该方法包括：
步骤S21：获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据。
步骤S22：根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器。
步骤S23：运行所述目标Docker容器。
步骤S21至步骤S23的具体实施过程可以参考前述实施例中公开的相应内容，再次不再进行赘述。
步骤S24：利用预设请求确定所述目标Docker容器的启动状态。
在运行所述目标Docker容器之后，还需要检测所述目标Docker容器的运行状态，具体的，可以先利用预设请求确定所述目标Docker容器的启动状态。其中，所述预设请求可以为HTTP(HyperText Transfer Protocol，超文本传输协议)Get请求。利用预设请求确定所述目标Docker容器的启动状态，包括：向所述目标服务对应的服务站点发送HTTP Get请求，其中，所述HTTP Get请求中包括所述目标Docker容器的信息；接收所述服务站点返回的响应码；根据所述响应码确定所述目标Docker容器的启动状态。
具体的，当所述响应码为2开头的响应码时，表示成功，例如200；当所述响应码为3开头的响应码时，表示重定向，例如307；当所述响应码为4开头的响应码时，表示客户端出现错误，例如400；当所述响应码为5开头的响应码时，表示服务端出现错误，例如500。当所述响应码为2开头的响应码时，表示所述目标Docker容器正常启动。
步骤S25：如果所述目标Docker容器正常启动，则确定所述目标Docker容器的服务准备状态。
当所述目标Docker容器正常启动时，则确定所述目标Docker容器的服务准备状态。具体的，确定所述目标Docker容器的服务准备状态，包括：在所述目标Docker容器对应的目标端口上建立TCP Socket连接，其中，所述目标端口为所述目标主机上的端口；如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态。
具体的，就是在所述目标Docker容器对应的目标端口上建立TCP Socket连接，所述目标端口为所述目标主机上的端口。如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态。如果通过所述TCPSocket连接打不开所述目标端口，则表示所述目标Docker容器的服务还未准备就绪。
步骤S26：根据所述服务准备状态确定所述目标Docker容器的运行状态。
在确定出目标Docker容器的服务准备状态，便可确定出所述目标Docker容器的运行状态。具体的，就是如果所述服务准备状态为服务准备就绪状态，则将所述目标Docker容器的运行状态确定为正常运行状态。如果所述服务准备状态为服务未准备就绪状态，则将所述目标Docker容器的运行状态确定为非正常运行状态，此时所述目标Docker容器不能正常接收流量以及产生应答等。
步骤S27：如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
确定出所述目标Docker容器的运行状态之后，如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。如果所述目标Docker容器尚未准备就绪，则重启所述目标Docker容器。
步骤S28：根据所述Kubernetes集群的负载控制所述目标pod的副本数量。
在所述目标Docker容器可以正常提供所述目标服务之后，可以根据所述Kubernetes集群的负载控制所述目标pod的副本数量，以提高系统的稳固性。
参见图3所示，本申请实施例公开了一种服务更新装置，应用于Kubernetes集群，包括：
信息获取模块11，用于获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；
Pod创建模块12，用于根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；
容器运行模块13，用于运行所述目标Docker容器；
容器运行状态确定模块14，用于检测所述目标Docker容器的运行状态；
流量分发模块15，用于在所述目标Docker容器处于正常运行状态时，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
可见，本申请应用于Kubernetes集群，先获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据，然后根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器，再运行所述目标Docker容器，并检测所述目标Docker容器的运行状态，如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。这样先创建目标pod，目标pod上运行提供新版本的目标服务的目标Docker容器，然后启动目标Docker容器并检测目标Docker容器的运行状态，在目标Docker容器处于正常运行状态之后，便可以将请求所述目标服务的流量转接到目标Docker容器，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，而在服务更新期间，依然由原Docker容器提供旧版本的目标服务，这样在服务更新期间正常提供服务，提升了用户体验。
具体的，所述Pod创建模块12，具体用于：
处理所述服务创建请求，以创建所述目标pod；
为所述目标pod分配目标主机；
将所述目标pod与所述目标主机绑定；
执行目标处理操作，以完成所述目标pod创建。
进一步的，所述Pod创建模块12，具体用于：
根据预先获取到的第一预设规则从所述Kubernetes集群中的各个主机中确定出预选主机；
根据预先获取到的第二预设规则对所述预选主机中的各个主机进行打分；
将所述预选主机中得分最高的主机确定为所述目标主机。
在具体的应用中，所述服务更新装置，还包括：
副本控制模块，用于根据所述Kubernetes集群的负载控制所述目标pod的副本数量。
具体的，所述容器运行状态确定模块14，用于：
利用预设请求确定所述目标Docker容器的启动状态；
如果所述目标Docker容器正常启动，则确定所述目标Docker容器的服务准备状态；
根据所述服务准备状态确定所述目标Docker容器的运行状态。
进一步的，所述容器运行状态确定模块14，用于：
向所述目标服务对应的服务站点发送HTTP Get请求，其中，所述HTTP Get请求中包括所述目标Docker容器的信息；
接收所述服务站点返回的响应码；
根据所述响应码确定所述目标Docker容器的启动状态。
进一步的，所述容器运行状态确定模块14，用于：
在所述目标Docker容器对应的目标端口上建立TCP Socket连接，其中，所述目标端口为所述目标主机上的端口；
如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态；
相应的，所述根据所述服务准备状态确定所述目标Docker容器的运行状态，包括：
如果所述服务准备状态为服务准备就绪状态，则将所述目标Docker容器的运行状态确定为正常运行状态。
进一步的，参见图4所示，本申请实施例还公开了一种电子设备，包括：处理器21和存储器22。
其中，所述存储器22，用于存储计算机程序；所述处理器21，用于执行所述计算机程序，以实现前述实施例中公开的服务更新方法。
其中，关于上述服务更新方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现以下步骤：
获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；运行所述目标Docker容器，并检测所述目标Docker容器的运行状态；如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
可见，本申请应用于Kubernetes集群，先获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据，然后根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器，再运行所述目标Docker容器，并检测所述目标Docker容器的运行状态，如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。这样先创建目标pod，目标pod上运行提供新版本的目标服务的目标Docker容器，然后启动目标Docker容器并检测目标Docker容器的运行状态，在目标Docker容器处于正常运行状态之后，便可以将请求所述目标服务的流量转接到目标Docker容器，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，而在服务更新期间，依然由原Docker容器提供旧版本的目标服务，这样在服务更新期间正常提供服务，提升了用户体验。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：处理所述服务创建请求，以创建所述目标pod；为所述目标pod分配目标主机；将所述目标pod与所述目标主机绑定；执行目标处理操作，以完成所述目标pod创建。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：根据预先获取到的第一预设规则从所述Kubernetes集群中的各个主机中确定出预选主机；根据预先获取到的第二预设规则对所述预选主机中的各个主机进行打分；将所述预选主机中得分最高的主机确定为所述目标主机。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：根据所述Kubernetes集群的负载控制所述目标pod的副本数量。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：利用预设请求确定所述目标Docker容器的启动状态；如果所述目标Docker容器正常启动，则确定所述目标Docker容器的服务准备状态；根据所述服务准备状态确定所述目标Docker容器的运行状态。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：向所述目标服务对应的服务站点发送HTTP Get请求，其中，所述HTTP Get请求中包括所述目标Docker容器的信息；接收所述服务站点返回的响应码；根据所述响应码确定所述目标Docker容器的启动状态。
本实施例中，所述计算机可读存储介质中保存的计算机子程序被处理器执行时，可以具体实现以下步骤：在所述目标Docker容器对应的目标端口上建立TCP Socket连接，其中，所述目标端口为所述目标主机上的端口；如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态；相应的，所述根据所述服务准备状态确定所述目标Docker容器的运行状态，包括：如果所述服务准备状态为服务准备就绪状态，则将所述目标Docker容器的运行状态确定为正常运行状态。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
最后，还需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得一系列包含其他要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本申请所提供的一种服务更新方法、装置、设备、介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种服务更新方法，其特征在于，应用于Kubernetes集群，包括：
获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；
根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；
运行所述目标Docker容器，并检测所述目标Docker容器的运行状态；
如果所述目标Docker容器处于正常运行状态，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
2.根据权利要求1所述的服务更新方法，其特征在于，所述根据所述服务创建请求创建目标pod，包括：
处理所述服务创建请求，以创建所述目标pod；
为所述目标pod分配目标主机；
将所述目标pod与所述目标主机绑定；
执行目标处理操作，以完成所述目标pod创建。
3.根据权利要求2所述的服务更新方法，其特征在于，所述为所述目标pod分配目标主机，包括：
根据预先获取到的第一预设规则从所述Kubernetes集群中的各个主机中确定出预选主机；
根据预先获取到的第二预设规则对所述预选主机中的各个主机进行打分；
将所述预选主机中得分最高的主机确定为所述目标主机。
4.根据权利要求2所述的服务更新方法，其特征在于，所述获取到的请求所述目标服务的流量接入所述目标Docker容器中之后，还包括：
根据所述Kubernetes集群的负载控制所述目标pod的副本数量。
5.根据权利要求2至4任一项所述的服务更新方法，其特征在于，所述检测所述目标Docker容器的运行状态，包括：
利用预设请求确定所述目标Docker容器的启动状态；
如果所述目标Docker容器正常启动，则确定所述目标Docker容器的服务准备状态；
根据所述服务准备状态确定所述目标Docker容器的运行状态。
6.根据权利要求5所述的服务更新方法，其特征在于，所述利用预设请求确定所述目标Docker容器的启动状态，包括：
向所述目标服务对应的服务站点发送HTTP Get请求，其中，所述HTTP Get请求中包括所述目标Docker容器的信息；
接收所述服务站点返回的响应码；
根据所述响应码确定所述目标Docker容器的启动状态。
7.根据权利要求5所述的服务更新方法，其特征在于，所述确定所述目标Docker容器的服务准备状态，包括：
在所述目标Docker容器对应的目标端口上建立TCP Socket连接，其中，所述目标端口为所述目标主机上的端口；
如果通过所述TCP Socket连接可打开所述目标端口，则将所述目标Docker容器的服务准备状态确定为服务准备就绪状态；
相应的，所述根据所述服务准备状态确定所述目标Docker容器的运行状态，包括：
如果所述服务准备状态为服务准备就绪状态，则将所述目标Docker容器的运行状态确定为正常运行状态。
8.一种服务更新装置，其特征在于，应用于Kubernetes集群，包括：
信息获取模块，用于获取服务创建请求，其中，所述服务创建请求中包括用于更新目标服务的数据；
Pod创建模块，用于根据所述服务创建请求创建目标pod，其中，所述目标pod上运行提供新版本的所述目标服务的目标Docker容器；
容器运行模块，用于运行所述目标Docker容器；
容器运行状态确定模块，用于检测所述目标Docker容器的运行状态；
流量分发模块，用于在所述目标Docker容器处于正常运行状态时，则将获取到的请求所述目标服务的流量转接至所述目标Docker容器中，以便利用所述目标Docker容器替换提供所述目标服务的原Docker容器，以完成对所述目标服务的更新。
9.一种电子设备，其特征在于，包括：
存储器和处理器；
其中，所述存储器，用于存储计算机程序；
所述处理器，用于执行所述计算机程序，以实现权利要求1至7任一项所述的服务更新方法。
10.一种计算机可读存储介质，其特征在于，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的服务更新方法。
CN202010752556.1A 2020-07-30 2020-07-30 一种服务更新方法、装置、设备及介质 Pending CN111857975A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010752556.1A CN111857975A (zh) 2020-07-30 2020-07-30 一种服务更新方法、装置、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010752556.1A CN111857975A (zh) 2020-07-30 2020-07-30 一种服务更新方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
CN111857975A true CN111857975A (zh) 2020-10-30

Family

ID=72945731

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010752556.1A Pending CN111857975A (zh) 2020-07-30 2020-07-30 一种服务更新方法、装置、设备及介质

Country Status (1)

Country Link
CN (1) CN111857975A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112860435A (zh) * 2021-01-29 2021-05-28 西藏宁算科技集团有限公司 一种5g场景下解决边缘节点可用性的方法
CN113590146A (zh) * 2021-06-04 2021-11-02 聚好看科技股份有限公司 服务器及容器升级方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112860435A (zh) * 2021-01-29 2021-05-28 西藏宁算科技集团有限公司 一种5g场景下解决边缘节点可用性的方法
CN113590146A (zh) * 2021-06-04 2021-11-02 聚好看科技股份有限公司 服务器及容器升级方法
CN113590146B (zh) * 2021-06-04 2023-10-27 聚好看科技股份有限公司 服务器及容器升级方法

Similar Documents

Publication Publication Date Title
US7127635B2 (en) Method for correcting a program running on a computer system
US8825817B1 (en) Using a template to update a stack of resources
CN111857975A (zh) 一种服务更新方法、装置、设备及介质
KR20170049375A (ko) 가상 머신 시스템 디스크 스냅 샷의 생성 방법 및 장치
US20160301758A1 (en) Generic cloud enabling of stateful applications
CN101211272A (zh) 动态虚拟机生成
CN108255708B (zh) 测试环境中访问生产文件的方法、装置、存储介质及设备
CN101321187A (zh) 用于备份数据的系统和方法
CN111324377B (zh) 应用灰度发布方法、系统、设备及存储介质
CN112860282B (zh) 集群插件的升级方法、装置和服务器
CN111880816A (zh) Kubernetes工作负载升级方法、装置及设备
EP2513786A1 (en) A method of updating versioned software using a shared cache
CN110674095A (zh) 一种ctdb集群扩展方法、装置、设备及可读存储介质
CN113206877A (zh) 一种会话保持方法及装置
CN111625498A (zh) 一种数据迁移方法、系统、电子设备及存储介质
CN111309365A (zh) 一种响应访问请求的方法、装置及计算机可读存储介质
CN110213213B (zh) 应用的定时任务处理方法及系统
CN112860787A (zh) 分布式主从系统中主节点的切换方法、主节点设备和存储介质
CN106293790B (zh) 基于Firefox操作系统的应用程序升级方法和装置
CN105530323A (zh) 一种文件升级方法、相关设备及系统
CN113596087A (zh) 应用升级方法、装置及计算机可读存储介质
CN111162952A (zh) 一种设备容错方法及装置
CN107085514B (zh) 共享库升级方法及装置
JP2012226391A (ja) 更新情報配布装置、更新情報配布配信システム、更新情報配布方法、及びプログラム
CN115309457A (zh) 应用实例的重启方法、装置、电子设备及可读存储介质

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