CN114938375B - 一种容器组更新设备及容器组更新方法 - Google Patents

一种容器组更新设备及容器组更新方法 Download PDF

Info

Publication number
CN114938375B
CN114938375B CN202210528978.XA CN202210528978A CN114938375B CN 114938375 B CN114938375 B CN 114938375B CN 202210528978 A CN202210528978 A CN 202210528978A CN 114938375 B CN114938375 B CN 114938375B
Authority
CN
China
Prior art keywords
container group
node
group
container
load balancing
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
Application number
CN202210528978.XA
Other languages
English (en)
Other versions
CN114938375A (zh
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.)
Juhaokan Technology Co Ltd
Original Assignee
Juhaokan 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 Juhaokan Technology Co Ltd filed Critical Juhaokan Technology Co Ltd
Priority to CN202210528978.XA priority Critical patent/CN114938375B/zh
Publication of CN114938375A publication Critical patent/CN114938375A/zh
Application granted granted Critical
Publication of CN114938375B publication Critical patent/CN114938375B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开涉及一种容器组更新设备及容器组更新方法，涉及互联网技术领域。容器组更新设备包括：控制器，被配置为：在第一节点上创建第一容器组，第一容器组与服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组；在第一容器组创建完成之后，生成容器组变化信息以触发从服务器集群中的每个节点中删除第二容器组的路由转发信息，并获取第二容器组所属群组的负载均衡信息，群组中包括第一容器组和第二容器组，第二容器组为运行在第二节点上的一个容器组；从负载均衡信息中，获取第二容器组的流量分配状态；在流量分配状态表征不再向第二容器组分配流量时，删除第二容器组。

Description

一种容器组更新设备及容器组更新方法
技术领域
本公开涉及互联网技术领域，尤其涉及一种容器组更新设备及容器组更新方法。
背景技术
Kubernetes***简称K8s***，K8s***是开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩应用容器化管理，K8s***用于管理云平台中多个主机上的容器化的应用，当在K8s***中执行部署(Deployment)滚动升级过程中，会先创建一个新的容器组(Pod)，之后再删除一个旧的Pod，在删除该旧的Pod的过程中，会存在两个异步操作：一个操作为删除该旧的Pod的路由转发信息，另一个操作为删除该旧的Pod。由于这两个操作是异步执行的，因此无法控制这两个异步操作的先后顺序，这样有可能存在先删除了该旧的Pod的路由转发信息，后删除该旧的Pod的情况，在出现这种情况时，会出现将网络流量转发到已经删除的该旧的Pod的情况，这样就会出现连接超时的问题。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种容器组更新设备及容器组更新方法，可以保证在先删除了该旧的Pod的路由转发信息之后，再删除该旧的Pod。
为了实现上述目的，本公开实施例提供的技术方案如下：
第一方面，提供一种容器组更新设备，其特征在于，包括：
控制器，被配置为：在服务器集群的第一节点上创建第一容器组，所述第一容器组与所述服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除第二容器组的路由转发信息，并获取所述第二容器组所属群组的负载均衡信息，所述群组中包括所述第一容器组和所述第二容器组，所述第二容器组为运行在第二节点上的一个容器组，所述第一节点和所述第二节点为所述服务器集群中任意两个相同或不同的节点；
从所述负载均衡信息中，获取所述第二容器组的流量分配状态；
在所述流量分配状态表征不再向所述第二容器组分配流量时，删除所述第二容器组。
作为本公开实施例一种可选的实施方式，所述负载均衡信息包括所述第一容器组和所述第二容器组的IP地址分别对应的流量分配信息；
所述控制器，具体被配置为：
在所述第一节点上创建所述第一容器组时，为所述第一容器组分配第一IP地址作为所述第一容器组的路由转发信息，并在所述服务器集群中的每个节点上保存所述第一容器组的路由转发信息，以使得根据所述第一IP地址将所述目标服务对应的流量转发至所述第一容器组；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的第二IP地址，从所述负载均衡信息中获取所述第二IP地址对应的流量分配状态。
作为本公开实施例一种可选的实施方式，所述控制器，具体被配置为：
在接收到删除所述第二容器组的指示消息的情况下，获取第二容器组所属群组的负载均衡信息。
作为本公开实施例一种可选的实施方式，所述第二节点为所述服务器集群中的工作节点，所述容器组更新设备还包括：
通信器，被配置为：实现控制节点与工作节点之间的信息交互；
所述控制器，具体被配置为：通过所述通信器将所述指示消息从所述控制节点发送至所述第二节点；以及控制所述第二节点响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
作为本公开实施例一种可选的实施方式，所述第二节点为所述服务器集群中的控制节点，所述容器组更新设备还包括：
用户输入接口，被配置为：接收用户输入的所述指示消息；
所述控制器，具体被配置为，响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
作为本公开实施例一种可选的实施方式，所述控制器，具体被配置为：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，再次获取所述第二容器组所属群组的负载均衡信息，并基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
作为本公开实施例一种可选的实施方式，所述控制器，具体被配置为：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，等待第一时长，在所述第一时长之后再次获取所述第二容器组所属群组的负载均衡信息，并基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
作为本公开实施例一种可选的实施方式，所述控制器，具体被配置为：
连续多次获取第二容器组所属群组的负载均衡信息；
根据连续多次获取的负载均衡信息，确定多个所述第二容器组的流量分配状态；
在所述多个所述第二容器组的流量分配状态均表征仍向所述第二容器组分配流量时，删除所述第二容器组。
第二方面，提供一种容器组更新方法，包括：
在服务器集群的第一节点上创建第一容器组，所述第一容器组与所述服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除第二容器组的路由转发信息，并获取所述第二容器组所属群组的负载均衡信息，所述群组中包括所述第一容器组和所述第二容器组，所述第二容器组为运行在第二节点上的一个容器组，所述第一节点和所述第二节点为所述服务器集群中任意两个相同或不同的节点；
从所述负载均衡信息中，获取所述第二容器组的流量分配状态；
在所述流量分配状态表征不再向所述第二容器组分配流量时，删除所述第二容器组。
作为本公开实施例一种可选的实施方式，所述负载均衡信息包括所述第一容器组和所述第二容器组的IP地址分别对应的流量分配信息；
所述方法还包括：
在所述第一节点上创建所述第一容器组时，为所述第一容器组分配第一IP地址作为所述第一容器组的路由转发信息，并在所述服务器集群中的每个节点上保存所述第一容器组的路由转发信息，以使得根据所述第一IP地址将所述目标服务对应的流量转发至所述第一容器组；
所述生成容器组变化信息以触发从所述服务器集群中的每个节点中删除第二容器组的路由转发信息，包括：
生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的第二IP地址；
所述从所述负载均衡信息中，获取所述第二容器组的流量分配状态，包括：
从所述负载均衡信息中获取所述第二IP地址对应的流量分配状态。
第三方面，本公开提供了一种计算机可读存储介质，包括：计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如第二方面所示的容器组更新方法。
第四方面，本公开提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当该计算机程序在计算机上运行时，使得计算机实现如第二方面所示的容器组更新方法。
本公开实施例提供的容器组更新设备和容器组更新方法，容器组更新设备包括：控制器，被配置为：在服务器集群的第一节点上创建第一容器组，第一容器组与服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组；在第一容器组创建完成之后，生成容器组变化信息以触发从服务器集群中的每个节点中删除第二容器组的路由转发信息，并获取第二容器组所属群组的负载均衡信息，群组中包括第一容器组和第二容器组，第二容器组为运行在第二节点上的一个容器组，第一节点和第二节点为服务器集群中任意两个相同或不同的节点；从负载均衡信息中，获取第二容器组的流量分配状态；在流量分配状态表征不再向第二容器组分配流量时，删除第二容器组。通过该方案，在容器组更新场景中，创建用于替代第二容器组的第二容器组，并在触发从服务器集群中的每个节点中删除第二容器组的路由转发信息时，由于可以获取第二容器组所在群组的负载均衡信息并从中确定第二容器组的流量分配状态，这样就可以判断出为第二容器组分配流量的情况，在流量分配状态表征不再向第二容器组分配流量时，说明此时第二容器组的路由转发信息已经从每个节点中删除，此时再去删除该第二容器组，就不会再出现网络流量转发到已经删除的旧的第二容器组的情况，也不会存在连接超时的问题，从而提升了K8s***中执行Deployment滚动升级过程中的性能，实现用户无感知的滚动升级。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的一个节点中运行容器组示例图；
图2A为本公开实施例提供的一种K8s集群的架构示意图；
图2B为本公开实施例提供的一种K8s集群中控制节点与工作节点之间关系的架构示意图；
图2C为本公开实施例提供的一种为在执行部署滚动升级过程中，在如图2A所示的K8s***中创建一个新的Pod的流程示意图；
图2D为本公开实施例提供的一种为在执行部署滚动升级过程中，在如图2A所示的K8s***中删除一个旧的Pod的流程示意图；
图3为本公开实施例提供的一种容器组更新设备300的硬件配置框图；
图4为本公开实施例提供的一种容器组更新方法的流程示意图；
图5为本公开实施例提供的一种删除第一Pod的流程示意图；
图6为本公开实施例提供的另一种删除第一Pod的流程示意图；
图7为本公开实施例中提供的一种通过设置等待时间删除第一Pod的方法的流程示意图；
图8为本公开实施例提供的一种两个异步操作的执行时序示意图；
图9为本公开实施例提供的另一种两个异步操作的执行时序示意图；
图10为本公开实施例提供的一种通过负载均衡信息删除第一Pod的方法的流程示意图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
为了更好的理解本公开实施例中所提供的方案，以下先针对本公开实施例中涉及到的一些相关技术进行介绍：
容器组(Pod)：是K8s***中最小的可部署单元。容器组代表了K8s***中一个独立运行实例，该实例可能由单个容器或者几个耦合在一起的容器组成。K8s***中可以包括多个节点，每个节点中可以运行一个容器组或多个容器组。示例性的，如图1所示，为本公开实施例提供的一个节点中运行容器组示例图，图1中的节点中运行有两个容器组，分别为容器组A和容器组B，容器组A中包括容器1和容器2，容器组B中包括容器3和容器4。
K8s***：是开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩应用容器化管理，K8s***用于管理云平台中多个主机上的容器化的应用，K8s***可以应用在服务器集群，服务器集群中可以包括多个服务器，这种应用了K8s***的服务器集群也称为K8s集群，其中，每个服务器可以作为一个节点。
示例性的，如图2A所示，为本公开实施例提供的一种K8s集群的架构示意图，可以看出在该K8s集群中，包括一个控制节点(Master Node)、多个工作节点(Woker Node)以及覆盖网络(Overlay Network)。
其中，Overlay Network在网络技术领域，指的是一种网络架构上叠加的虚拟化技术模式，Overlay Network大体框架是对基础网络不进行大规模修改的条件下，实现应用在网络上的承载，并能与其它网络业务分离，并且以基于网际互连协议(Internet Protocol，IP)的基础网络技术为主。Overlay Network是在现有的物理网络之上构建的一个虚拟网络，上层应用只与虚拟网络相关。Overlay Network主要由三部分组成：
边缘设备：是指与虚拟机直接相连的设备；
控制平面：主要负责虚拟隧道的建立维护以及主机可达性信息的通告；
转发平面：承载Overlay报文的物理网络。
如图2A中所示，控制节点(Master节点)中包括：
数据库(etcd)：etcd为分布式以键值对存储数据(Key-value，KV)的数据库，通常称为KV数据库，etcd用于保存集群中的相关数据。
应用程序接口(Application Program Interface，API)服务(API Server)：APIServer是集群的统一入口，以软件架构风格(Representational State Transfer，RESTful)进行操作，同时交给etcd存储(是唯一能访问etcd的组件)。API Server可以提供认证、授权、访问控制、API注册和发现等机制。API Server可以通过命令行工具(kubectl)，可视化面板(dashboard)，或者软件开发工具包(Software Development Kit，SDK)等访问。
节点调度(Scheduler)：Scheduler用于选择节点应用部署。
控制器管理器，用于处理集群中常规后台任务，一个资源对应一个控制器，同时监控集群的状态，确保实际状态和最终状态一致。
如图2A中所示，每个工作节点(Node节点)中包括：
节点管理模块(kubelet)：kubelet相当于Master节点派到Node节点代表，管理本机容器，上报数据给API Server。
容器运行时(Container Runtime)：Container Runtime是容器运行环境，该Container Runtime中可以运行多个Pod，K8s集群可以支持多个容器运行环境以及任何实现容器运行环境接口(Container Runtime Interface，CRI)的软件。
实现服务(Service)抽象组件(kube-proxy)：kube-proxy用于实现k8s集群通信与负载均衡。
当在K8s***中执行部署(Deployment)滚动升级过程中，会先创建一个新的容器组(Pod)之后，再删除一个旧的Pod，在删除该旧的Pod的过程中，会存在两个异步操作：一个操作为删除该旧的Pod的路由转发信息，另一个操作为删除该旧的Pod。由于这两个操作是异步执行的，因此无法控制这两个异步操作的先后顺序，这样有可能存在先删除了该旧的Pod的路由转发信息，后删除该旧的Pod的情况，在出现这种情况时，会出现将网络流量转发到已经删除的该旧的Pod的情况，这样就会出现连接超时的问题。
从上面的图2A可以看出来，K8s集群的节点有两个角色，分别为控制节点和工作节点，K8s集群中控制节点和工作节点之间的关系如下图2B所示，控制节点负责整个集群的管理控制，包括针对多个工作节点的管理控制，需要说明的是图2B中是以包括3个工作节点：工作节点1、工作节点2和工作节点3为例进行说明的，实际中在K8s集群内部可以包括更多或更少的工作节点，本公开实施例不作限定。
本公开实施例中，该容器组更新设备，可以为服务器集群；该容器组更新设备，也可以为服务器集群中的一个节点或多个节点，例如，该容器组更新设备可以是上述第一节点或上述第二节点组成的设备；该容器组更新设备还可以为独立于该服务器集群用于管理该服务器集群的设备。示例性的，服务器集群可以为如图2A所示的K8s集群，上述第一节点和上述第二节点可以为服务器集群中的同一个节点，或者，上述第一节点和上述第二节点可以为服务器集群中的不同的两个节点，例如，该第一节点和/或第二节点可以为图2A中示出的控制节点和多个工作节点中的任一个节点。
由于服务器集群中每个节点(主机)通常会运行多个Pod(相当于多个虚拟机)，为区分每个Pod，需要为每个节点的每个容器组分配IP地址，以区分服务器集群中的每个Pod，而在客户端想要访问某个Pod对应的服务时，一开始客户端访问到的工作节点可能并不是运行这个Pod所运行的节点，此时被访问到的工作节点需要获知该Pod的IP地址对应的路由转发信息，才可以将客户端的访问请求对应的流量根据该路由转发信息转发至这个Pod。那么在目前的服务器集群中会将该Pod分配的IP地址对应的路由转发信息保存到每个节点，这样在任意节点接收到针对其他节点中Pod对应服务的访问请求时，可以通过查询路由转发表，来找到对应该服务的Pod，并将流量转发到该服务对应的Pod中。为了实现这样的方案，需要在服务器集群中每个节点上都保存一致的路由转发表(iptables)，该路由转发表中记录了该服务器中不同Pod的路由转发信息，根据该路由转发表可以获取流量转发的规则。
在执行部署(Deployment)滚动升级过程中，会先创建一个新的Pod，并删除一个旧的Pod。
如图2C所示，为在执行部署滚动升级过程中，在如图2A所示的K8s***中创建一个新的Pod的流程示意图，该过程中包括以下步骤：21、应用程序服务接口(API Server)接收管理员触发的增加新的Pod的请求，其中，该管理员可以为该服务器集群的管理人员。22、API Server将新的Pod对应的资源内容存储到数据库(etcd)。23、etcd将新的Pod添加到调度程序的队列中。24、节点调度(Scheduler)为新的Pod确定适合的工作节点。25、并通知确定的工作节点上的节点管理模块(kubelet)新的Pod需要调度到该工作节点上，该工作节点上的节点管理模块创建新的Pod。26、容器网络接口(CNI)为该新的Pod分配IP地址。27、容器存储接口(CSI)为该新的Pod分配存储空间。28、容器运行环境接口CRI中创建该新的Pod，即该Pod。29、在创建新的Pod完成后，节点管理模块将为该新的Pod分配的IP地址存储在etcd中。30、监听到etcd中Pod变化信息。31、由每个节点中的实现服务抽象组件(kube-proxy)来更新每个节点上的iptables。其中，更新每个节点上的iptables可以是增加新的Pod的IP地址对应的路由转发信息。
可以看出，在创建一个新的Pod的过程中，需要在每个节点中增加新的Pod的IP地址对应的路由转发信息，这样在每个节点中都会保存该Pod的路由转发信息。
相应的，在创建一个新的Pod完成之后，还需要删除一个旧的Pod在删除该一个旧的Pod的过程中，如图2D所示，为在执行部署滚动升级过程中，在如图2A所示的K8s***中删除一个旧的Pod的流程示意图，该过程中包括以下步骤：211、应用程序服务接口(APIServer)接收管理员触发的删除旧的Pod的请求，其中，该管理员可以为该服务器集群的管理人员。221、API Server将旧的Pod在数据库(etcd)中的状态变为终止状态(Terminating)。231、API Server将旧的Pod添加到调度程序的队列中。241、节点调度(Scheduler)确定旧的Pod所运行的工作节点。251、并通知确定的工作节点上的节点管理模块(kubelet)旧的Pod需要被删除，该工作节点上的节点管理模块触发删除旧的Pod，触发在CNI、CSI和CRI中的异步操作。261、CNI为删除旧的Pod的IP地址对应的路由转发信息。271、CSI删除旧的Pod的存储数据。281、CRI中删除该旧的Pod。在执行上述步骤261时，需要将服务器群组中每个节点中旧的Pod的IP地址对应的路由转发信息删除，具体的该删除操作可以由每个节点中的实现服务抽象组件(kube-proxy)来删除每个节点上的iptables中保存的旧的Pod的IP地址对应的路由转发信息实现。
其中，上述旧的Pod的路由转发信息也是存储在每个节点中的，其存储过程可以参考上述创建一个新的Pod的过程中的描述。在删除该旧的Pod的过程中，会存在两个异步操作：一个操作为删除该旧的Pod的路由转发信息，另一个操作为从该旧的Pod所在节点上删除该旧的Pod。由于每个节点上均有该旧的Pod的路由转发信息，因此在删除该旧的Pod的路由转发信息时，需要kube-proxy从每个节点的iptables中删除该旧的Pod的IP地址对应的路由转发信息，这样的过程可能需要一段时间。在这段时间内，如果已经执行了从该旧的Pod所在节点上删除该旧的Pod的异步操作，那么针对部分节点中未被删除该旧的Pod的IP地址对应的路由转发信息的情况，这些部分节点有可能根据该旧的Pod的IP地址对应的路由转发信息继续向该旧的Pod转发流量，这样就会出现连接超时的问题。
为了解决上述问题，本公开实施例提供了一种容器组更新设备和容器组更新方法，在容器组更新场景中，在第一节点上创建用于替代第二节点中运行的第二容器组(旧的Pod)的第一容器组(新的Pod)，并在触发从服务器集群中的每个节点中删除第二容器组的路由转发信息时，由于可以获取第二容器组所在群组的负载均衡信息并从中确定第二容器组的流量分配状态，这样就可以判断出为第二容器组分配流量的情况，在流量分配状态表征不再向第二容器组分配流量时，说明此时第二容器组的路由转发信息已经从每个节点中删除，此时再去删除该第二容器组，就不会再出现网络流量转发到已经删除的旧的第二容器组的情况，也不会存在连接超时的问题，从而提升了K8s***中执行Deployment滚动升级过程中的性能，实现用户无感知的滚动升级。
如图3所示，为本公开实施例提供的一种容器组更新设备300的硬件配置框图，如图3所示该容器组更新设备300包括：通信器310、控制器320、存储器330、用户输入接口340以及供电电源350等。
其中，通信器310是用于根据各种通信协议类型与外部设备或服务器进行通信的组件。例如：通信器310可以包括Wifi模块，蓝牙模块，有线以太网模块等其他网络通信协议芯片或近场通信协议芯片，以及红外接收器中的至少一种。
控制器320包括中央处理器(CentralProcessingUnit，CPU)，视频处理器，音频处理器，图形处理器(GraphicsProcessingUnit，GPU)，RAMRandomAccessMemory，RAM)，ROM(Read-OnlyMemory,ROM)，用于输入/输出的第一接口至第n接口，通信总线(Bus)等中的至少一种。
存储器330包括计算机可读介质中的非永久性存储器，随机存取存储器(randomaccess memory,RAM)和/或非易失性内存等形式，如只读存储器(Read-Only Memory，ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质。存储介质可以由任何方法或技术来实现信息存储，信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
用户输入接口340，用于接收用户输入命令。对于容器组更新设备来说用户可以是指服务器集群的管理人员。
在一些实施例中，控制器320，用于：在服务器集群的第一节点上创建第一容器组，所述第一容器组与所述服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除第二容器组的路由转发信息，并获取所述第二容器组所属群组的负载均衡信息，所述群组中包括所述第一容器组和所述第二容器组，所述第二容器组为运行在第二节点上的一个容器组，所述第一节点和所述第二节点为所述服务器集群中任意两个相同或不同的节点；
从所述负载均衡信息中，获取所述第二容器组的流量分配状态；
在所述流量分配状态表征不再向所述第二容器组分配流量时，删除所述第二容器组。
在一些实施例中，所述负载均衡信息包括所述第一容器组和所述第二容器组的IP地址分别对应的流量分配信息；
控制器320，具体用于在所述第一节点上创建所述第一容器组时，为所述第一容器组分配第一IP地址作为所述第一容器组的路由转发信息，并在所述服务器集群中的每个节点上保存所述第一容器组的路由转发信息，以使得根据所述第一IP地址将所述目标服务对应的流量转发至所述第一容器组；在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的第二IP地址，从所述负载均衡信息中获取所述第二IP地址对应的流量分配状态。
在一些实施例中，控制器320，具体用于在接收到删除所述第二容器组的指示消息的情况下，获取第二容器组所属群组的负载均衡信息。
在一些实施例中，所述第二节点为所述服务器集群中的工作节点，所述容器组更新设备300还包括：
通信器310，用于：实现控制节点与工作节点之间的信息交互；
所述控制器320，具体用于：通过所述通信器310将所述指示消息从所述控制节点发送至所述第二节点；以及控制所述第二节点响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
在一些实施例中，所述第二节点为所述服务器集群中的控制节点，所述容器组更新设备还包括：
用户输入接口340，用于：接收用户输入的所述指示消息；
所述控制器320，具体用于，响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
在一些实施例中，所述控制器320，具体用于：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，再次获取所述第二容器组所属群组的负载均衡信息，以使得基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
在一些实施例中，所述控制器320，具体用于：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，等待第一时长，在所述第一时长之后再次获取所述第二容器组所属群组的负载均衡信息，并基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
在一些实施例中，所述控制器320，具体用于：
连续多次获取第二容器组所属群组的负载均衡信息；
根据连续多次获取的负载均衡信息，确定多个所述第二容器组的流量分配状态；
在所述多个所述第二容器组的流量分配状态均表征仍向所述第二容器组分配流量时，删除所述第二容器组。
为了更加详细的说明本方案，以下将以示例性的方式结合附图进行说明，可以理解的是，以下附图中所涉及的步骤在实际实现时可以包括更多的步骤，或者更少的步骤，并且这些步骤之间的顺序也可以不同，以能够实现本公开实施例中提供的容器组更新方法为准。
本公开实施例提供的容器组更新方法可以通过容器组更新设备实现，或者上述容器组更新设备上的部分功能模块或者部分功能实体实现。
如图4所示，为本公开实施例提供的一种容器组更新方法的流程示意图，该方法可以包括以下步骤401至步骤406：
401、在服务器集群的第一节点上创建第一容器组。
其中，服务器集群包括但不限于第一节点和第二节点。第二节点中运行有已存在的第二容器组。上述第一节点和第二节点可以为该服务器中的物理机，也可以为物理机上运行的虚拟机。
上述第一容器组(以下也称为第一Pod)与第二容器组(以下也称为第二Pod)为针对目标服务的不同版本容器组。
在一些实施例中，在第一节点上创建第一容器组时，为第一容器组分配第一IP地址作为第一容器组的路由转发信息，并在服务器集群中的每个节点上保存第一容器组的路由转发信息，以使得根据第一IP地址将目标服务对应的流量转发至第一容器组。
需要说明的是，上述在服务器集群的第一节点上创建第一Pod的描述，可以参照如图2C中创建新的Pod的描述，此处不再赘述。
402、在第一容器组创建完成之后，生成容器组变化信息以触发从服务器集群中的每个节点中删除第二容器组的路由转发信息。
在一些实施例中，在第一容器组创建完成之后，生成容器组变化信息以触发从服务器集群中的每个节点中删除第二容器组的第二IP地址，从负载均衡信息中获取第二IP地址对应的流量分配状态。
在第一节点上创建第一Pod完成后，第一节点上的kubelet会将第一Pod的路由转发信息保存到etcd中，etcd会生成容器组变化信息，在监听到创建第一Pod的容器组变化信息之后，会触发从服务器集群中的每个节点中删除第一Pod的路由转发信息。具体的，可以由每个节点的kube-proxy，从每个节点的iptables中删除该旧的Pod的IP地址对应的路由转发信息。
403、获取第二容器组所属群组的负载均衡信息。
其中，群组中包括第一容器组和第二容器组。负载均衡信息包括第一容器组和第二容器组的IP地址分别对应的流量分配信息。
在一些实施例中，该群组中还可以包括第一容器组和第二容器组之外的其他容器组，通过调度该群组中不同容器组的流量分配情况，可以实现负载均衡。
第二容器组为运行在第二节点上的一个容器组，第一节点和第二节点为服务器集群中任意两个相同或不同的节点。
上述负载均衡信息可以是第二节点上的kube-proxy先获取第二节点上iptables中各个Pod的路由转发信息，之后再根据各个Pod的路由转发信息，确定相同服务对应的Pod的路由转发信息，最后基于相同服务对应的Pod的路由转发信息在进行流量分配是进行负载均衡，以得到上述负载均衡信息。
在一些实施例中，在上述402之后，可以在接收到删除第二容器组的指示消息的情况下，获取第二容器组所属群组的负载均衡信息。
其中，上述负载均衡信息包括该群组中各个容器组的IP地址分别对应的流量分配信息，在一些实施例中，获取第二容器组群组的负载均衡信息可以是：从负载均衡信息中获取第二IP地址对应的流量分配状态；其中，第二IP地址为第二容器组的IP地址。
示例性的，如表1所示，为群组内负载均衡信息中容器组、IP地址以及对应流量分配状态的示意表。如表1所示多个容器组中每个容器组对应一个IP地址，每个IP地址会对应流量分配状态(称为target状态)。
表1
Pod IP地址 target状态
Pod1 IP地址1 流量结束状态
Pod2 IP地址2 非流量结束状态
Pod3 IP地址3 非流量结束状态
Pod4 IP地址4 非流量结束状态
如表1所示，可以看出群组内包括4个Pod，其中，Pod1对应的流量分配状态为流量结束状态，此时Pod1已经不再有网络流量流入，说明服务器集群中各个节点的iptables中Pod1的路由转发信息已经被删除；相应的，Pod2、Pod3、Pod4对应的流量分配状态为非流量结束状态，此时Pod2、Pod3、Pod4仍然有网络流量流入，说明服务器集群中各个节点的iptables中Pod2、Pod3、Pod4的路由转发信息未被删除，Pod2、Pod3、Pod4之间还可以继续进行负载均衡。
本公开实施例中提供的容器组更新方法，可以应用于K8s集群中的工作节点或者控制节点，也就是说，上述第二Pod可以为工作节点上运行的Pod，上述第二Pod也可以为控制节点上运行的Pod。
示例性的，结合如图2A所示的K8s集群的架构，如图5所示，为本公开实施例提供的一种删除第二Pod的流程示意图。图5中在K8s集群中业务滚动更新过程中删除第二Pod时，API服务(API Server)会先收到管理员触发的删除第二Pod(即第二容器组)的指示消息(可以是指令)，在接收到删除第二Pod的指示消息后，同步将etcd中第二Pod的状态变为终止状态(Terminating)，第二Pod被节点调度(Scheduler)添加到调度程序的队列中，API Server可以向第二Pod所在节点的节点管理模块(kubelet)发送上述删除第二Pod的指示消息，kubelet接收到删除第二Pod的指示消息之后，执行异步操作，异步操作可以包括，容器运行时接口(CRI)删除第二Pod的操作，容器网络接口(CNI)删除第二Pod的路由转发信息的操作，容器存储接口(CSI)删除第二Pod的存储信息的操作。
第二节点为服务器集群中的工作节点，上述第二Pod为工作节点上运行的Pod，控制节点可以接收用户输入的指示消息，并且控制节点响应于指示消息，获取第二容器组所属群组的负载均衡信息。也就是说，上述图5所示的整个工作流程均可以在控制节点中完成。需要说明的是，控制节点中除了包括如图2A中所示的模块以外，还可以包括工作节点中的相关模块，以实现如图5所示的整个工作流程。
第二节点为服务器集群中的控制节点，上述第二Pod为控制节点上运行的Pod，在删除第二容器组时，工作节点可以接收控制节点发送的指示消息，并且工作节点响应于指示消息，获取第二容器组所属群组的负载均衡信息。也就是说，上述图5所示的整个工作流程需要通过控制节点和工作节点共同完成。
示例性的，如图6所示，为本公开实施例提供的另一种删除第二Pod的流程示意图，图6中，在K8s集群中业务滚动更新过程中删除第二Pod时，控制节点中的API服务(APIServer)会先收到管理员触发的删除第二Pod(即第二容器组)的指示消息(可以是指令)，在接收到删除第二Pod的指示消息后，同步将控制节点的etcd中第二Pod的状态变为终止状态(Terminating)，第二Pod被控制节点中节点调度(Scheduler)添加到调度程序的队列中，API Server可以向第二Pod所在工作节点的节点管理模块(kubelet)发送上述删除第二Pod的指示消息，kubelet接收到删除第二Pod的指示消息之后，执行异步操作，异步操作可以包括，容器运行时接口(CRI)删除第二Pod的操作，容器网络接口(CNI)删除第二Pod的路由转发信息的操作，容器存储接口(CSI)删除第二Pod的存储信息的操作。
404、根据负载均衡信息，确定第二容器组的流量分配状态。
示例性的，可以从如表1所示的负载均衡信息中，确定第二容器组的流量分配状态。
405、判断第二容器组的流量分配状态是否表征不再向第二容器组分配流量。
在确定第二容器组的流程分配状态表征不再向第二容器组分配流量的情况下，例如流程分配状态是流量结束状态，执行下述406，删除第二容器组；在确定第二容器组的流程分配状态表征仍向第二容器组分配流量的情况下，返回执行上述402，再次获取第二容器组所属群组的负载均衡信息。
在一些实施例中，在根据上一次获取的第二容器组的流量分配状态表征仍向第二容器组分配流量时，再次获取第二容器组所属群组的负载均衡信息，以使得基于负载均衡信息获取第二容器组的流量分配状态。
在一些实施例中，在根据上一次获取的第二容器组的流量分配状态表征仍向第二容器组分配流量时，等待第一时长，在第一时长之后再次获取第二容器组所属群组的负载均衡信息，并基于负载均衡信息获取第二容器组的流量分配状态。
示例性的，可以预设获取负载均衡信息的间隔时长为第一时长，即可以每间隔第一时长获取一次第二容器组所属群组的负载均衡信息。
上述实施例中，获取的第二容器组的流量分配状态表征仍向第二容器组分配流量时，说明当前服务器集群中可能还存在一些节点未删除第二容器组对应的路由转发信息，此时可以等待第一时长后，再次获取第二容器组所属群组的负载均衡信息，并基于负载均衡信息获取第二容器组的流量分配状态，再次进行判断，直到第二容器组的流量分配状态表征不再向第二容器组分配流量时，确认服务器集群中所有节点均删除了第二容器组对应的路由转发信息，此时可以删除第二容器组。
406、删除第二容器组。
根据如图5和图6所示的删除第二Pod的流程可以看出，当管理员删除第二Pod的请求到达API Server之后，kubelet收到删除第二Pod的通知，kubelet会启动两个异步的动作，一个负责删除第二Pod的路由转发信息，一个负责删除第二Pod。
(1)删除第二Pod的路由转发信息：
端点(Endpoint)控制器(Controller)会监听API Server的事件，然后把第二Pod从对应的Endpoint中删除。其中，Endpoint用于连接服务和Pod，Endpoint是一个服务的IP地址和端口(port)的列表。
进一步的，Endpoint Controller处理完成后，会把请求发送给API Server，kube-proxy,核心域名***(Core Domain Name System，CoreDNS)都会监听到这个事件，kube-proxy会更新节点上的iptables，CoreDNS会更新域名***(Domain Name System，缩写：DNS)。
(2)删除第二Pod过程：
Kubelet监听到API Server的事件，Kubelet开始向第二Pod运行的进程(应用程序)发送终止信号(SIGTERM信号)。
上述两个工作流是异步的，两项操作没有依赖关系，在接收到删除指令后两个工作流同时工作，如果在删除第二Pod时，第二Pod的路由转发信息还未从服务器集群中的所有节点中删除，会出现将第二Pod的流量转发到已经删除的Pod，导致连接超时，使得用户以连接到的服务突然断开，以及新用户连接不上服务，用户使用和体验很差。
相关技术中，K8s为Pod在其生命周期内提供了两种钩子(hook)，分别是容器启动后(postStart)与容器终止前(preStop)两种事件，为了保证在删除第二Pod前，删除第二Pod的路由转发信息，相关技术中提供了设置等待时间的删除第二Pod的实现方式。
示例性的，如图7所示，为本公开实施例中提供的一种通过设置等待时间删除第二Pod的方法的流程示意图，该流程可以包括以下步骤：
701、接收删除第二Pod的指示消息。
在节点接收删除第二Pod的指示消息，删除第二Pod之前，执行下述702和703。
702、执行容器终止前钩子(PreStop hook)，设置等待时间。
703、在等待时间后删除第二Pod。
上述设置等待时间的目的时为了预留时间给删除服务器集群中每个节点上第二Pod的路由转发信息。示例性的，上述等待时间可以设置为5s至10s。
由于删除服务器集群中每个节点上第二Pod的路由转发信息和删除第二Pod的这两个操作时异步处理的，因此在使用上述解决方案时，需要保证在删除第二Pod前，删除服务器集群中所有节点上第二Pod的路由转发信息。
示例性的，如图8所示，为本公开实施例提供的一种两个异步操作的执行时序示意图，假设在T1时刻接收到执行删除第二Pod的指示消息，此时执行容器终止前钩子PreStophook，设置等待时间为10s，在T3时刻执行删除第二Pod操作，如果删除服务器集群中每个节点上第二Pod的路由转发信息的操作在图8所示的T2时刻就已经执行完毕，那么就可以保证在删除第二Pod之前，删除完服务器集群中所有节点上第二Pod的路由转发信息。
示例性的，如图9所示，为本公开实施例提供的另一种两个异步操作的执行时序示意图；假设在T1时刻接收到执行删除第二Pod的指示消息，此时执行容器终止前钩子PreStop hook，设置等待时间为10s，在T3时刻执行删除第二Pod操作，如果删除第二Pod的路由转发信息的操作在图9所示的T4时刻执行，那么就无法保证在删除第二Pod之前，删除完服务器集群中所有节点上第二Pod的路由转发信息。
相关技术中，上述解决方案存在以下缺陷：
1、等待时间没有规律，只能根据经验设置；
2、每调整一次等待时间需要对线上整体业务进行更新，影响范围大；
3、随着K8s集群中服务器数量增加，需要加长等待时间，因此需要随时调整等待时间；
4、原本无需等待10s删除第二Pod的情况，也会等待10s后删除第二Pod；
例如，如图8所示的情况，在T1时刻的2s之后已经删除第二Pod的路由转发信息，但是依然等到10s之后的T3时刻才删除第二Pod。
5、滚动更新时间增长。
本公开实施例中，为了达到更好的效果，通过如上述401至405的方法通过获取去第二Pod群组的负载均衡信息来确认第二Pod的流量分配状态。
示例性的，可以在Pod停止前，同样执行PreStop hook，但是不是去设置等待时间，而是启用1个边车容器组(sidecar Pod)保证两个异步操作的顺序性。如图10所示，为本公开实施例提供的一种通过负载均衡信息删除第二Pod的方法的流程示意图，该方法可以包括以下步骤1001至1005：
1001、接收删除第二Pod的指示消息。
1002、执行PreStop hook，启用sidecar Pod的目标脚本。
其中，该目标脚本设置为每隔几秒钟从第二Pod所属群组(target groups)的负载均衡信息中获取当前IP的流量分配状态(target状态)
其中，K8s集群中每个target groups用于将请求路由到一个或多个已注册的目标。当创建每个侦听器规则时，指定一个目标组和条件。当满足规则条件时，流量将被转发到相应的目标组。可以为不同类型的请求创建不同的目标组。
1003、通过执行该目标脚本，每隔几秒钟从第二Pod所属群组的负载均衡信息中获取当前IP的流量分配状态。
1004、流量分配状态是否不再向第二容器组分配流量。
若流量分配状态处于draining，则不再向第二容器组分配流量，退出执行目标脚本，执行下述905。
若流量分配状态不处于draining，则继续探测，返回执行上述903，从第二Pod所属群组的负载均衡信息中获取当前第二Pod的IP地址的流量分配状态。
其中，流量分配状态处于draining，说明第二Pod的路由转发信息已经删除，不存在流量流入。
1005、删除第二Pod。
本公开实施例中上述实施例存在的有益效果可以包括：
1、不需要再去配置等待时间，可以根据实际负载均衡的流量转发情况，在确定第二Pod无转发流量后，删除第二Pod；
2、只需改动一次线上配置；
3、不受K8s集群范围扩大影响；
4、滚动更新时间短。
本公开实施例提供的容器组更新方法，可以获取第二容器组所属群组的负载均衡信息，群组中包括多个容器组，第二容器组为运行在节点上的一个容器组；根据负载均衡信息，确定第二容器组的流量分配状态；在第二容器组的流量分配状态表征不再向第二容器组分配流量的情况下，删除第二容器组。通过该方案，由于可以根据负载均衡信息，确定第二容器组的流量分配状态，并在第二容器组的流量分配状态表征不再向第二容器组分配流量的情况下，获知服务器集群中的所有节点均已删除该第二容器组的路由转发信息，在此之后再去删除该旧的Pod，就不会再出现网络流量转发到已经删除的旧的Pod的情况，也不会存在连接超时的问题，从而提升了K8s***中执行Deployment滚动升级过程中的性能，实现用户无感知的滚动升级。
在一些实施例中，在执行上述1001至1005的过程中，还可以连续多次获取第二容器组所属群组的负载均衡信息；根据连续多次获取的负载均衡信息，确定多个第二容器组的流量分配状态；在多个第二容器组的流量分配状态均表征仍向第二容器组分配流量时，删除第二容器组。
考虑到实际实现过程中，根据一次获取的负载均衡信息判断出第二容器组的流量分配状态可能存在误判，因此通过连续多次获取第二容器组所属群组的负载均衡信息，根据连续多次获取的负载均衡信息，确定多个第二容器组的流量分配状态；在多个第二容器组的流量分配状态均为流量结束状态的情况下，删除第二容器组。通过该方法可以提高判断的准确性。
本公开实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现上述容器组更新方法容器组更新方法执行的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，该计算机可读存储介质可以为只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
本公开提供一种计算机程序产品，该计算机程序产品中包括计算机程序，当该计算机程序在计算机上运行时，使得计算机实现上述的容器组的容器组更新方法。
为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述在一些实施例中讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好的解释原理以及实际的应用，从而使得本领域技术人员更好的使用实施方式以及适于具体使用考虑的各种不同的变形的实施方式。

Claims (10)

1.一种容器组更新设备，其特征在于，所述容器组更新设备包括：控制器，被配置为：在服务器集群的第一节点上创建第一容器组，所述第一容器组与所述服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组，所述服务器集群中包括一个控制节点和多个工作节点；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的路由转发信息，并获取所述第二容器组所属群组的负载均衡信息，所述群组中包括所述第一容器组和所述第二容器组，所述第二容器组为运行在第二节点上的一个容器组，所述第一节点和所述第二节点为所述服务器集群中任意两个相同或不同的节点；
从所述负载均衡信息中，获取所述第二容器组的流量分配状态；
在所述流量分配状态表征不再向所述第二容器组分配流量时，删除所述第二容器组。
2.根据权利要求1所述的容器组更新设备，其特征在于，所述负载均衡信息包括所述第一容器组和所述第二容器组的IP地址分别对应的流量分配信息；
所述控制器，具体被配置为：
在所述第一节点上创建所述第一容器组时，为所述第一容器组分配第一IP地址作为所述第一容器组的路由转发信息，并在所述服务器集群中的每个节点上保存所述第一容器组的路由转发信息，以使得根据所述第一IP地址将所述目标服务对应的流量转发至所述第一容器组；在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的第二IP地址，从所述负载均衡信息中获取所述第二IP地址对应的流量分配状态。
3.根据权利要求1所述的容器组更新设备，其特征在于，所述控制器，具体被配置为：
在接收到删除所述第二容器组的指示消息的情况下，获取第二容器组所属群组的负载均衡信息。
4.根据权利要求3所述的容器组更新设备，其特征在于，所述第二节点为所述服务器集群中的所述工作节点，所述容器组更新设备还包括：
通信器，被配置为：实现所述控制节点与所述工作节点之间的信息交互；
所述控制器，具体被配置为：通过所述通信器将所述指示消息从所述控制节点发送至所述第二节点；以及控制所述第二节点响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
5.根据权利要求3所述的容器组更新设备，其特征在于，所述第二节点为所述服务器集群中的所述控制节点，所述容器组更新设备还包括：
用户输入接口，被配置为：接收用户输入的所述指示消息；
所述控制器，具体被配置为，响应于所述指示消息，获取所述第二容器组所属群组的负载均衡信息。
6.根据权利要求1所述的容器组更新设备，其特征在于，所述控制器，具体被配置为：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，再次获取所述第二容器组所属群组的负载均衡信息，以使得基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
7.根据权利要求6所述的容器组更新设备，其特征在于，所述控制器，具体被配置为：
在根据上一次获取的所述第二容器组的流量分配状态表征仍向所述第二容器组分配流量时，等待第一时长，在所述第一时长之后再次获取所述第二容器组所属群组的负载均衡信息，并基于所述负载均衡信息获取所述第二容器组的所述流量分配状态。
8.根据权利要求1所述的容器组更新设备，其特征在于，所述控制器，具体被配置为：
连续多次获取第二容器组所属群组的负载均衡信息；
根据连续多次获取的负载均衡信息，确定多个所述第二容器组的流量分配状态；
在所述多个所述第二容器组的流量分配状态均表征仍向所述第二容器组分配流量时，删除所述第二容器组。
9.一种容器组更新方法，其特征在于，包括：
在服务器集群的第一节点上创建第一容器组，所述第一容器组与所述服务器集群中已存在的第二容器组为针对目标服务的不同版本容器组，所述服务器集群中包括一个控制节点和多个工作节点；
在所述第一容器组创建完成之后，生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的路由转发信息，并获取所述第二容器组所属群组的负载均衡信息，所述群组中包括所述第一容器组和所述第二容器组，所述第二容器组为运行在第二节点上的一个容器组，所述第一节点和所述第二节点为所述服务器集群中任意两个相同或不同的节点；
从所述负载均衡信息中，获取所述第二容器组的流量分配状态；
在所述流量分配状态表征不再向所述第二容器组分配流量时，删除所述第二容器组。
10.根据权利要求9所述的方法，其特征在于，所述负载均衡信息包括所述第一容器组和所述第二容器组的IP地址分别对应的流量分配信息；
所述方法还包括：
在所述第一节点上创建所述第一容器组时，为所述第一容器组分配第一IP地址作为所述第一容器组的路由转发信息，并在所述服务器集群中的每个节点上保存所述第一容器组的路由转发信息，以使得根据所述第一IP地址将所述目标服务对应的流量转发至所述第一容器组；所述生成容器组变化信息以触发从所述服务器集群中的每个节点中删除第二容器组的路由转发信息，包括：
生成容器组变化信息以触发从所述服务器集群中的每个节点中删除所述第二容器组的第二IP地址；
所述从所述负载均衡信息中，获取所述第二容器组的流量分配状态，包括：
从所述负载均衡信息中获取所述第二IP地址对应的流量分配状态。
CN202210528978.XA 2022-05-16 2022-05-16 一种容器组更新设备及容器组更新方法 Active CN114938375B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210528978.XA CN114938375B (zh) 2022-05-16 2022-05-16 一种容器组更新设备及容器组更新方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210528978.XA CN114938375B (zh) 2022-05-16 2022-05-16 一种容器组更新设备及容器组更新方法

Publications (2)

Publication Number Publication Date
CN114938375A CN114938375A (zh) 2022-08-23
CN114938375B true CN114938375B (zh) 2023-06-02

Family

ID=82865769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210528978.XA Active CN114938375B (zh) 2022-05-16 2022-05-16 一种容器组更新设备及容器组更新方法

Country Status (1)

Country Link
CN (1) CN114938375B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116233070A (zh) * 2023-03-20 2023-06-06 北京奇艺世纪科技有限公司 一种集群静态ip地址的分配***及分配方法

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109067828A (zh) * 2018-06-22 2018-12-21 杭州才云科技有限公司 基于Kubernetes和OpenStack容器云平台多集群构建方法、介质、设备
CN109150608A (zh) * 2018-08-22 2019-01-04 苏州思必驰信息科技有限公司 用于语音对话平台的接口服务升级方法及***
CN110213309A (zh) * 2018-03-13 2019-09-06 腾讯科技（深圳）有限公司 一种绑定关系管理的方法、设备及存储介质
CN111163189A (zh) * 2020-01-07 2020-05-15 上海道客网络科技有限公司 一种基于网络命名空间管控的ip监控和回收***与方法
CN111258609A (zh) * 2020-01-19 2020-06-09 北京百度网讯科技有限公司 Kubernetes集群的升级方法、装置、电子设备和介质
CN113254165A (zh) * 2021-07-09 2021-08-13 易纳购科技(北京)有限公司 虚拟机和容器的负载流量分配方法、装置及计算机设备
CN113364727A (zh) * 2020-03-05 2021-09-07 北京金山云网络技术有限公司 容器集群***、容器控制台和服务器
CN113656168A (zh) * 2021-07-16 2021-11-16 新浪网技术(中国)有限公司 一种流量的自动容灾和调度的方法、***、介质和设备
CN113835836A (zh) * 2021-09-23 2021-12-24 证通股份有限公司 动态发布容器服务的***、方法、计算机设备及介质
CN113923257A (zh) * 2021-09-22 2022-01-11 北京金山云网络技术有限公司 容器组实例终止和创建方法、装置、电子设备和存储介质
CN113949707A (zh) * 2021-09-30 2022-01-18 上海浦东发展银行股份有限公司 基于OpenResty和K8S的容器云服务发现和负载均衡方法
CN114385349A (zh) * 2021-12-06 2022-04-22 阿里巴巴（中国）有限公司 容器组部署方法和装置
CN114461303A (zh) * 2022-02-10 2022-05-10 京东科技信息技术有限公司 一种访问集群内部服务的方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210011816A1 (en) * 2019-07-10 2021-01-14 Commvault Systems, Inc. Preparing containerized applications for backup using a backup services container in a container-orchestration pod
US20210072966A1 (en) * 2019-09-05 2021-03-11 International Business Machines Corporation Method and system for service rolling-updating in a container orchestrator system

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213309A (zh) * 2018-03-13 2019-09-06 腾讯科技（深圳）有限公司 一种绑定关系管理的方法、设备及存储介质
CN109067828A (zh) * 2018-06-22 2018-12-21 杭州才云科技有限公司 基于Kubernetes和OpenStack容器云平台多集群构建方法、介质、设备
CN109150608A (zh) * 2018-08-22 2019-01-04 苏州思必驰信息科技有限公司 用于语音对话平台的接口服务升级方法及***
CN111163189A (zh) * 2020-01-07 2020-05-15 上海道客网络科技有限公司 一种基于网络命名空间管控的ip监控和回收***与方法
CN111258609A (zh) * 2020-01-19 2020-06-09 北京百度网讯科技有限公司 Kubernetes集群的升级方法、装置、电子设备和介质
CN113364727A (zh) * 2020-03-05 2021-09-07 北京金山云网络技术有限公司 容器集群***、容器控制台和服务器
CN113254165A (zh) * 2021-07-09 2021-08-13 易纳购科技(北京)有限公司 虚拟机和容器的负载流量分配方法、装置及计算机设备
CN113656168A (zh) * 2021-07-16 2021-11-16 新浪网技术(中国)有限公司 一种流量的自动容灾和调度的方法、***、介质和设备
CN113923257A (zh) * 2021-09-22 2022-01-11 北京金山云网络技术有限公司 容器组实例终止和创建方法、装置、电子设备和存储介质
CN113835836A (zh) * 2021-09-23 2021-12-24 证通股份有限公司 动态发布容器服务的***、方法、计算机设备及介质
CN113949707A (zh) * 2021-09-30 2022-01-18 上海浦东发展银行股份有限公司 基于OpenResty和K8S的容器云服务发现和负载均衡方法
CN114385349A (zh) * 2021-12-06 2022-04-22 阿里巴巴（中国）有限公司 容器组部署方法和装置
CN114461303A (zh) * 2022-02-10 2022-05-10 京东科技信息技术有限公司 一种访问集群内部服务的方法和装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Nguyen Nguyen ; Taehong Kim.Toward Highly scalable load balancing in Kubernetes clusters.《IEEE》.2020,全文. *
基于容器的NFV平台关键技术研究与实现;刘彪;《中国优秀硕士学位论文全文数据库》;全文 *

Also Published As

Publication number Publication date
CN114938375A (zh) 2022-08-23

Similar Documents

Publication Publication Date Title
CN110113441B (zh) 实现负载均衡的计算机设备、***和方法
US9999030B2 (en) Resource provisioning method
US10701139B2 (en) Life cycle management method and apparatus
CN111542064B (zh) 一种用于无线接入网的容器编排管理***及编排方法
US10129096B2 (en) Commissioning/decommissioning networks in orchestrated or software-defined computing environments
CN111880902A (zh) 一种pod创建方法、装置、设备及可读存储介质
US9912633B2 (en) Selective IP address allocation for probes that do not have assigned IP addresses
CN108777640B (zh) 一种服务器探测方法、装置、***及存储介质
TW201444320A (zh) 主從裝置環境的部署方法與系統
US10884880B2 (en) Method for transmitting request message and apparatus
CN113810230B (zh) 对容器集群中的容器进行网络配置的方法、装置及***
CN110716787A (zh) 容器地址设置方法、设备和计算机可读存储介质
US20220318071A1 (en) Load balancing method and related device
CN102497409A (zh) 一种云计算***资源管理的方法
CN113382077B (zh) 微服务调度方法、装置、计算机设备和存储介质
CN107809495B (zh) 地址管理方法及装置
CN114938375B (zh) 一种容器组更新设备及容器组更新方法
WO2022267646A1 (zh) 一种容器集的部署方法及装置
WO2021248972A1 (zh) 默认网关管理方法、网关管理器、服务器及存储介质
CN111163140A (zh) 资源获取和分配的方法、装置和计算机可读存储介质
CN108881460B (zh) 一种云平台统一监控的实现方法和实现装置
EP3860050B1 (en) Commissioning/decommissioning networks in software-defined computing environments
CN109067573B (zh) 一种流量调度方法及装置
CN114615268B (zh) 基于Kubernetes集群的服务网络、监控节点、容器节点及设备
CN111404978A (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
GR01 Patent grant
GR01 Patent grant