CN116414515A - 一种信息处理方法、装置、电子设备及存储介质 - Google Patents

一种信息处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN116414515A
CN116414515A CN202210006427.7A CN202210006427A CN116414515A CN 116414515 A CN116414515 A CN 116414515A CN 202210006427 A CN202210006427 A CN 202210006427A CN 116414515 A CN116414515 A CN 116414515A
Authority
CN
China
Prior art keywords
address
target
service
mapping information
predetermined service
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
CN202210006427.7A
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.)
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software 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 China Mobile Communications Group Co Ltd, China Mobile Suzhou Software Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202210006427.7A priority Critical patent/CN116414515A/zh
Publication of CN116414515A publication Critical patent/CN116414515A/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
    • 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/45562—Creating, deleting, cloning virtual machine instances
    • 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/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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/45579—I/O management, e.g. providing access to device drivers or storage
    • 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/45595—Network integration; Enabling network access in virtual machine instances

Abstract

本申请的技术方案提供了一种信息处理方法，包括：创建预定服务；从IP地址资源池中为所述预定服务分配目标IP地址；其中，所述预定服务映射有一个或多个容器；广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。

Description

一种信息处理方法、装置、电子设备及存储介质
技术领域
本发明实施例涉及信息处理领域，尤其涉及一种信息处理方法、装置、电子设备及存储介质。
背景技术
随着云服务技术的发展，例如本地云(Cloud Native)，越来越多的应用基于容器管理平台实现了容器化，例如通过Kubernetes实现容器化和容器编排等，而应用或服务的种类也从小规模的单机应用向大规模的分布式系统转变。
由于Kubernetes等容器管理平台的网络架构，服务只能在Kubernetes集群中通过内部的Pod IP进行访问。公网或该网络下的其他子网无法直接使用Pod IP进行服务访问，因此需要将服务有效暴露。
发明内容
本发明实施例提供一种信息处理方法、装置、电子设备及存储介质。
本公开实施例第一方面提供一种信息处理方法，包括：创建预定服务；从 IP地址资源池中为所述预定服务分配目标IP地址；其中，所述预定服务映射有一个或多个容器；广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。
在另一实施例中，所述IP地址资源池中包括多个IP地址；其中，一个所述IP地址具有一个映射信息；所述映射信息的字符长度小于所述IP地址的字符长度；所述方法，包括：根据目标IP地址对应的映射信息，生成所述预定服务分配的IP地址配置。
在另一实施例中，在所述预定服务的数量为N个时，所述从IP地址资源池中为所述预定服务分配目标IP地址，包括：从所述映射信息中依次顺序确定N个目标映射信息，所述目标映射信息用于确定所述目标IP地址。
在另一实施例中，所述预定服务，包括：支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。
在另一实施例中，所述预定服务包括：负载均衡服务。
本公开实施例第二方面提供一种信息处理装置，包括：创建模块，用于创建预定服务；目标IP分配模块，用于从IP地址资源池中为所述预定服务分配目标IP地址；其中，所述预定服务映射有一个或多个容器；广播模块，用于广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。
在另一实施例中，所述IP地址资源池中包括多个IP地址；其中，一个所述IP地址具有一个映射信息；所述映射信息的字符长度小于所述IP地址的字符长度；所述装置包括：生成模块，用于根据目标IP地址对应的映射信息，生成所述预定服务分配的IP地址配置。
在另一实施例中，所述目标IP分配模块，还用于在所述预定服务的数量为 N个时，从所述映射信息中依次顺序确定N个目标映射信息，所述目标映射信息用于确定所述目标IP地址。
在另一实施例中，所述预定服务，包括：支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。
在另一实施例中，所述预定服务包括：负载均衡服务。
本公开实施例第三方面提供一种电子设备，包括：处理器；存储器，其存储有程序指令，当所述程序指令被所述处理器执行时，使得所述电子设备执行上述任一项所述的方法。
本公开实施例第四方面提供一种存储介质，其存储有程序，当所述程序由处理器运行时，执行上述任一项所述的方法。
本公开实施例的技术方案通过创建预定服务，例如负载均衡服务，然后从 IP地址资源池中为预定服务分配目标IP地址，各个预定服务分别映射有一个或多个容器。例如一个预定服务映射一个至少包括一个容器的容器集合(pod)。通过预定服务与容器之间的映射关系，在为预定服务分配目标IP地址后即可通过预定服务的目标IP地址确定相应的容器。由于预定服务与容器之间存在映射关系，每个预定服务都分别映射有相应的容器，将预定服务的目标IP地址广播出去之后，外部访问端即可通过目标IP地址对该目标IP地址映射的一个或多个容器进行访问，如此，可以实现了客户端通过一个IP地址访问多个容器的功能。
本方案中创建的预定服务与容器存在映射关系，不需要加入其他额外的节点对目标IP进行广播从而实现目标IP的暴露，从而省去了对其他额外的节点的配置操作。另外，在容器的规模增加时，也不需要增加其他额外节点的数量，减少了对其他额外节点的管理，减少了成本。另外，没有预定服务的数量限制，提高了信息处理能力。
附图说明
图1为本公开实施例提供的一种信息处理的示意图；
图2为本公开实施例提供的一种基于图1的一种示意图；
图3为本公开实施例提供的一种基于图2的示意图；
图4为本公开实施例提供的一种基于图3的示意图；
图5为本公开实施例提供的一种信息的处理方法的示意图；
图6为本公开实施例提供的一种基于图5创建的示意图；
图7为本公开实施例提供的一种部署与图6对应组件的示意图；
图8为本公开实施例提供的一种与图6对应的示意图；
图9为本公开实施例提供的一种基于图6的另一种示意图；
图10为本公开实施例提供的一种信息处理装置的结构示意图。
具体实施方式
以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。
在裸金属架构上部署的Kubernetes集群，原生并不支持LoadBalancer类型的服务暴露方式，想要使用LoadBalancer服务，通常需要借助第三方云服务厂商。而Ingress暴露服务的方式是基于Nginx的转发，比较适合小规模微服务的场景。所以对于大型的分布式服务，NodePort暴露服务的模式是经常使用到的方法。
参考图1，为一种信息处理的示意图。某分布式服务中，代理(Agent)节点以有状态应用编排(StatefulSet)的方式进行编排，3个Agent Pod所提供的端口(Port)分别为30001、30002、30003。即Agent-1的端口为30001，Agent-2 的端口为30002，Agent-3的端口为30003。对外提供服务时，使用外部机器可以访问的节点端口(NodePort)进行服务暴露，NodePort40001、NodePort40002、 NodePort40003分别转发到Port30001、Port30002和Port30003。当用户流量需要发送到Agent Pod时，只需要以节点Node的任一IP和对应的NodePort作为 Socket连接串进行连接即可。如：通过192.168.1.1:40001访问Agent-1。
于是，这三个Agent服务可以分别以节点IP地址(NodeIp)和节点端口 (NodePort)的方式暴露，比如：
Agent-1通过192.168.1.1:40001进行暴露，即通过192.168.1.1:40001即可访问Agent-1。Agent-2通过192.168.1.2:40002进行暴露，通过192.168.1.2:40002 即可访问Agent-2。Agent-3通过192.168.1.3:40003进行暴露，通过 192.168.1.2:40003即可访问Agent-3。
由于NodePort是全局暴露方式，例如基于Kube-proxy的全局暴露方式，即所有节点共用Port，所以也可以使用同一Node Ip进行服务暴露。比如：
Agent-1通过192.168.1.1:40001进行暴露，Agent-2通过192.168.1.1:40002 进行暴露，Agent-3通过192.168.1.1:40003进行暴露。
另外，当Kubernetes集群中，某个节点Node发生宕机时，由于 Deployment/StatefulSet等容器编排机制，该宕机Node的所有Pod会被转移到其他节点再次启动，即服务的完整性不会受到影响。
参考图2，为基于图1的一种示意图。比如当Node192.168.1.1宕机时，Agent-1会被编排到其他节点再次启动，该分布式服务的工作节点数量不会发生任何变化。
但是如果Agent-1是以192.168.1.1:40001方式暴露服务的话，客户端将无法完成连接请求，因为Node 192.168.1.1已经宕机下线。此时就会出现服务感知不一致的现象：客户端认为Agent-1已经下线，而服务端则认为仍然有三个 Agent处于运行中。
通常情况下需要引入一个机制，保证不会因某个Node的宕机而导致服务不可用，由于NodePort具有全局性，于是对于这样的单点故障，最常见的做法之一就是引入Keepalived VIP，提供高可用的IP暴露服务。参考图3，为一种基于图2的示意图。比如：将Node 192.168.1.1与192.168.1.2进行配对，生成 VIP 192.168.1.100，这样VIP下的任意一个节点的单点故障，都不会影响集群的整体使用。于是服务暴露的方式将变为：
Agent-1通过192.168.1.100:40001暴露，Agent-2通过192.168.1.100:40002 暴露，Agent-3通过192.168.1.100:40003暴露。
在这种方式下，流量可能会成为整个集群的瓶颈。现在所有流量都经过该Keepalived VIP节点192.168.1.100。
无法充分发挥分布式环境下多节点的网络优势，除了Keepalived VIP节点，其他节点的网络均处于空闲状态。
于是引入多个Keepalived VIP来分担流量。参考图4，为一种基于图3的示意图。此时该分布式服务暴露服务的方式，可能像这样：
Agent-1通过192.168.1.100:40001暴露，Agent-2通过192.168.1.100:40002暴露， Agent-3通过192.168.1.101:40003暴露。这种多Keepalived VIP的方式虽然能够解决单点的故障，不过也同样带入了新的问题，例如：1)流量缩减，可用流量只有集群总容量的一半:VIPNumber＝NodeNumber/2。2)不易扩展。当集群节点规模增加时，需要同时增加Keepalive的节点。3)可管理性差。需要额外管理等同于集群数量的VIP服务。4)开发成本高。部署软件时，需要维护多个IP，设计NodePort，耦合程度高。
参考图5，为本申请的技术方案提供的一种信息的处理方法的示意图，该方法包括以下步骤：
步骤S100，创建预定服务。
步骤S200，从IP地址资源池中为预定服务分配目标IP地址；预定服务映射有一个或多个容器。
步骤S300，广播目标IP地址；目标IP地址，用于访问预定服务映射的容器。
该预定服务包括但不限于：代理服务和/或轮询服务。
代理服务接收到访问请求之后，可以将对应的访问请求传输给容器，最终由容器响应最后的访问请求；当容器返回请求响应之后，代理服务将该请求响应进一步发送给访问请求的发送方。
轮询服务可为一种特殊的代理服务，通过轮询具有相同功能的容器，将访问请求以轮询方式发送给其连接或者映射的多个容器，以实现访问请求的响应。
在该实施例中，通过创建多个预定服务，然后为预定服务分配目标IP地址，每个预定服务分别具有一个目标IP地址，每个预定服务都映射有一个或多个容器，这样即可建立预定服务与容器之间的映射关系。
将每个预定服务的目标IP地址广播出去之后，外部机器(例如，客户端的运行设备)即可通过目标IP地址访问对应的预定服务，由于预定服务与容器之间存在映射关系，所以可以通过预定服务的目标IP地址访问预定服务对应的容器。
在一个实施例中，预定服务为均衡负载服务，即LoadBalancer Service，通过LoadBalancer Service的方式实现对容器的访问，暴露以容器的形式运行在集群中的服务。每个LoadBalancer Service具体可以通过负载均衡器执行。
IP地址资源池可以是预先配置的IP地址资源池，IP地址资源池中包括多个IP地址，IP地址数量并不进行限定，可以根据实际需求进行确定。从IP地址资源池中为预定服务分配目标IP地址的具体方法也不进行限定，例如可以是随机分配，也可以是按照一定的顺序进行分配等。
广播目标IP地址的方式并不进行限定，可以基于标准的路由协议进行广播，例如Speaker协议，使用Speaker中的Layer2模式或者边界网关协议(BGP) 模式，将预定服务的目标IP地址广播出去，使得外部主机可以通过路由策略访问到该分配出去的目标IP地址，进而可以通过该目标IP地址访问相应的容器。在该实施例中，采取了Layer2模式对目标IP地址进行广播。
参考图6，为一种基于图5创建的示意图。集群中可以包括多个容器，一个或多个容器以容器组(pod)的方式绑定在物理节点(Node)上，每个Node 上绑定有一个Pod。通过为Pod创建预定服务，然后为预定服务分配目标IP地址，通过预定服务的目标IP地址即可访问对应的Pod。预定服务的数量与Node 节点的数量和Pod的数量相同。
例如，创建了3个LoadBalancer Service服务，为每个LoadBalancer Service 服务分配目标地址，为最左侧的LoadBalancer Service服务分配目标IP地址192.168.1.100，为中间的LoadBalancer Service服务分配目标地址192.168.1.101，为最右边的LoadBalancer Service服务分配目标地址192.168.1.102。目标IP地址192.168.1.100的LoadBalancer Service服务映射最左边的Pod，目标地址为192.168.1.101的LoadBalancer Service服务映射中间的Pod，目标地址为 192.168.1.102的LoadBalancer Service服务映射最右边的Pod。
目标IP地址192.168.1.100可以用于访问最左边的Pod，将目标IP地址192.168.1.100广播出去之后外部机器即可通过该目标IP地址访问最左边的 Pod。目标IP地址192.168.1.101可以用于访问中间的Pod，将目标IP地址 192.168.1.101广播出去之后外部机器即可通过该目标IP地址访问中间的Pod。将目标地址192.168.1.102广播出去之后，外部机器即可通过该目标地址访问最右边的Pod。
通过创建预定预设，并且一个预定服务映射一个Pod，通过为预定服务分配的目标IP地址即可访问该预定服务映射的Pod，不需要加入其他额外的节点对目标IP进行广播从而实现目标IP的暴露，从而省去了对其他额外的节点的配置操作。另外，在容器的规模增加时，也不需要增加其他额外节点的数量，减少了对其他额外节点的管理，减少了成本。另外，没有预定服务的数量限制，提高了信息处理能力。减少了流量缩减、不易扩展、可管理性差和开发成本高等问题。
在一个实施例中，在Layer2模式中，会从多个Node节点中选出一个主节点(LeaderNode)，LoadBalancer Service的目标IP地址会通过这个Leader Node 节点所在Speaker组件进行广播。所有流量到达路由器会后，会被分配到Leader Node节点，Leader Node节点再根据LoadBalancer Service所对应的Pod进行流量转发。
参考图6，中间的节点即为主节点，即Leader Node节点，图6所示的组件可以通过部署守护进程(Daemonset)部署。
在另一实施例中，参考图6，集群中还包括控制器组件，可以监控各个LoadBalancer Service服务，如果发现LoadBalancer Service服务没有可用的负载均衡器进行装配，那么控制器组件会自动为该LoadBalancer Service服务从地址资源池中选择目标IP地址进行分配。
参考图7，为一种部署与图6对应组件的示意图。
创建集群(例如Namespace)，之后要部署在Kubernetes内的相关资源全部都要处于这个Namespace之下。
部署配置文件，例如Configmap文件，用于配置IP地址资源池，IP地址资源池中包括IP池名字、IP地址和IP地址范围。从IP地址资源池中可以确定出目标IP地址分配给各个预定服务。这些IP能否可用，取决于Kubernetes集群的网络环境，通常情况下IP地址资源池中的IP地址在同一个子网下。
部署相关的容器组件，包括：第一控制器组件Controller和协议组件 Speaker。
部署第二控制器组件，例如Operator组件，这个组件是部署在Kubernetes 外部的，需要可以连接到Kubernetes集群。部署完毕后，便可以使用此组件自动向Kubernetes集群内提交包含LoadBalancer Service服务的容器应用，同时也实现了IP地址的自动分配。
当为预定服务分配目标IP地址后，Speaker组件会根据标准的路由协议对外宣广播目标IP地址，外部机器可以通过该目标IP地址真正访问容器中的服务。
参考图8，为与图6对应的示意图。
每个Agent Pod对应一个LoadBalancer Service服务，在检测到LoadBalancerService服务后，为该LoadBalancer Service服务分配目标IP地址并广播。
当某个Node节点发生故障，Pod进行迁移时，LoadBalancer Service服务的目标IP地址也会被迁移，这保证了客户端与服务端感知的一致性。
当需要扩容Pod时，只需要相对应的增加LoadBalancer Service服务即可。
通过创建与Pod一对应映射的LoadBalancer Service服务，在为 LoadBalancerService服务分配目标IP地址后，每个Pod都也就具有了独立的 IP地址，且该IP地址与Node节点的IP地址处于同一子网下。
本方案中创建的预定服务与容器存在映射关系，不需要加入其他额外的节点对目标IP进行广播从而实现目标IP的暴露，从而省去了对其他额外的节点的配置操作。另外，在容器的规模增加时，也不需要增加其他额外节点的数量，减少了对其他额外节点的管理，减少了成本。另外，没有预定服务的数量限制，提高了信息处理能力。
在另一实施例中，IP地址资源池中包括多个IP地址；其中，一个IP地址具有一个映射信息；映射信息的字符长度小于IP地址的字符长度。映射信息的格式并不进行限制，例如字符串或标识等。
IP地址资源池中包括多IP地址，可以便于在预定服务为多个时，需要为每个预定服务分配目标IP地址。每个IP地址都具有一个映射信息，该映射信息的字符长度小于IP地址的字符长度，通过分配映射信息实现对IP地址的分配。由于映射信息的字符长度小于IP地址的字符长度，所以便于对IP地址的分配管理。
在从IP地址资源池中为预定服务分配目标IP地址时，根据映射信息进行分配，例如可以将映射信息分配给预定服务，映射信息用于确定预定服务，根据映射信息即可确定对应的目标IP地址。
在另一实施例中，所述方法包括：根据目标IP地址对应的映射信息，生成预定服务分配的IP地址配置。
为预定服务分配目标IP地址后，可以根据目标IP地址对应的映射信息生成分配记录信息，即预定服务分配的IP地址配置，用于记录目标IP地址的分配情况。
在另一实施例中，在预定服务的数量为N个时，从IP地址资源池中为预定服务分配目标IP地址，包括：
从映射信息中依次顺序确定N个目标映射信息，目标映射信息用于确定目标IP地址。N为正整数。
在预定服务的数量为多个时，则访问多个Pod，通过为多个预定服务分配目标IP地址，从而将多个预定服务的目标IP地址广播出去，外部机器通过多个不同的目标IP地址访问多个Pod。
例如，创建N个LoadBalancer Service服务，每个LoadBalancer Service服务映射一个Pod，则需要为N个LoadBalancer Service服务分别分配目标IP地址。
具体目标IP地址分配方式可以包括：从映射信息根据映射信息的排序依次顺序确定N个目标映射信息，然后将这N个目标映射信息分配给N个 LoadBalancer Service服务，不需要直接分配目标IP地址，减少了由于IP地址资源池中IP地址较多和较乱时导致的容易出现分配错乱等问题。
由于一个IP地址具有一个映射信息，IP地址和映射信息是一对一的，每个 IP地址的映射信息都不同，这样可以减少多个IP地址对应一个映射信息导致的关系混乱情况，从而可以减少将多个目标IP地址分配至同一个预定服务上，导致总是访问某一个预定服务对应的容器，其他预定服务可能处于空闲状态的情况发生。
在另一实施例中，预定服务可以包括：支持IPv4的第一类预定服务和支持 IPv6的第二类预定服务。例如，包括IPv4服务和IPv6服务的双栈服务。
一个LoadBalancer Service服务只能支持IPv4或IPv6中的一种网络服务，如果要支持双栈，则需要为一个Pod创建两个分别支持IPv4和IPv6的 LoadBalancer Service服务。
目前支持的路由协议有三种：ARP、NDP和BGP。其中ARP、NDP属于 layer2模式，ARP用于广播IPV4地址，NDP用于广播IPV6地址。
对Kubernetes进行双栈网络配置，在此模式下，在Kubernetes环境中创建 Pod会有IPv4、IPv6两组地址。用户通过Operator提交的应用在Kubernetes内部的通信方式不会干扰到外部网络服务暴露，内部通信方式由应用自己决定。外部通信方式由应用的LoadBalancer Service决定，这一部分功能由Operator 支持，创建LoadBalancer Service时写入的share key和IP需要从预先写入IPv4 地址和IPv6地址的Configmap中获取。
对于Pod而言，可以创建两个LoadBalancer Service服务，支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。即同一个Pod映射两个不同类的预定服务，同时映射一个支持IPv4的第一类预定服务和一个支持IPv6的第二类预定服务。通过以上方法，客户端就可以分别获得IPv4和IPv6共两组地址用于服务访问，客户端只需要更换hosts映射信息，就可以轻松的在双栈网络之间进行切换。
参考图9，为基于图6的另一中示意图。
在访问Port：30001对应的Pod时，通过支持IPv4的第一类预定服务，即 IP地址为192.168.1.100:40001的第一类预定服务即可访问Port：30001对应的 Pod。同时，还可以通过支持Ipv6的第二类预定服务，即IP地址为 [2401::ff01]:40001的第二类预定服务即可访问Port：30001对应的Pod。
同理，在访问Port：30002对应的Pod时，通过支持IPv4的第一类预定服务，即IP地址为192.168.1.101:40002的第一类预定服务即可访问Port：30002 对应的Pod。同时，还可以通过支持Ipv6的第二类预定服务，即IP地址为 [2401::ff02]:40002的第二类预定服务即可访问Port：30002对应的Pod。
同理，在访问Port：30003对应的Pod时，通过支持IPv4的第一类预定服务，即IP地址为192.168.1.102:40003的第一类预定服务即可访问Port：30003 对应的Pod。同时，还可以通过支持Ipv6的第二类预定服务，即IP地址为 [2401::ff03]:40003的第二类预定服务即可访问Port：30003对应的Pod。
在另一实施例中，主要通过在LoadBalancer Service上添加Annotations的方式指定VIP。metallb.universe.tf/address-pool用于指定所使用的的IP池，metallb.universe.tf/allow-shared-ip用于分配IP池内的IP。具有相同metallb.universe.tf/allow-shared-ip的share key的Service会使用相同的IP。
默认情况下，映射信息(例如share key)不是逐一对应IP地址的，这样会导致对应关系混乱，并且集群在某些情况下，会出现一个share key对应多个IP。这些都给管理带来了压力，同时也不便于IP扩缩容。
例如：
Operator会实现这一部分的功能。在启动后，Operator会首先初始化整个 IP池(支持IPv4、IPv6和双栈)，在初始化的IP池中，已经使share key和IP 一一绑定。当用户提交一个应用时，Operator会从已经初始化的IP池中选取一组share key和IP，再按组分配metallb.universe.tf/allow-shared-ip的share key值和spec.loadBalancerIP的IP值到某个Service上，以此来绑定share key和IP的对应关系。如果这个应用中含有多个Service，Operator会以轮询的方式从IP池中选取多组share key和IP分配到这些Service上。在Operator的生命周期内，轮询分配的顺序不会被重置。
上述实施例的方法可以自动完成对Service的IP地址分配和端口分配。
上述实施例的方法采用轮询的机制对Operator生命周期内的所有应用中的所有LoadBalancer Service分配相应的IP地址。
上述实施例的方法对share key和IP值进行了绑定，避免默认的生成对应关系的方法可能产生的对应关系的混乱。
上述实施例的方法支持IPv4、IPv6和双栈三种模式的网络地址分配。
上述实施例的方法通过软件实现了Kubernetes对LoadBalancer网络暴露的支持，无需依赖第三方云厂商。
服务感知方式不同。当分配好IP以后，Keepalived两个服务之间会使用VRRP不停的交换信息，来判断服务是否存活；本方法则使用MemberList来感知Node是否无法访问，当发现Node下线时，会重新选举Node。
VIP数量限制。由于VRRP协议的限制，Keepalive最多只允许255个负载均衡器；本方法无IP数量限制。
配置方式不同。Keepalived需要两两进行配对，当负载均衡节点数量较多时，管理较为困难。本方法则为全局配置，配置项较为简单，比如不需要配置 Virtual Router IDs。
IP飘移行为不同。Keepalive的IP只会在两个节点之间转移，而本方法的飘移会在Kubernetes整个集群的节点上进行飘移。
上述实施例的方法实现了自动分配IP地址，对IP分配方式进行了优化，避免了可能出现的share key和IP对应关系混乱的问题，同时采用轮询机制保证了流量负载均衡。
在另一实施例中，参考图10，为一种信息处理装置的结构示意图，该装置包括：
创建模块1，用于创建预定服务；
目标IP分配模块2，用于从IP地址资源池中为所述预定服务分配目标IP 地址；其中，所述预定服务映射有一个或多个容器；
广播模块3，用于广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。
在另一实施例中，所述IP地址资源池中包括多个IP地址；其中，一个所述IP地址具有一个映射信息；所述映射信息的字符长度小于所述IP地址的字符长度；
所述装置包括：
生成模块，用于根据目标IP地址对应的映射信息，生成所述预定服务分配的IP地址配置。
在另一实施例中，所述目标IP分配模块，还用于在所述预定服务的数量为N个时，从所述映射信息中依次顺序确定N个目标映射信息，所述目标映射信息用于确定所述目标IP地址。
在另一实施例中，所述预定服务，包括：支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。
在另一实施例中，所述预定服务包括：负载均衡服务。
本申请的技术方案还提供了一种电子设备，包括：
处理器；
存储器，其存储有程序指令，当程序指令被处理器执行时，使得电子设备执行上述任一项实施例中的方法。
本申请的技术方案还提供了一种存储介质，其存储有程序，当程序由处理器运行时，执行上述任一项实施例中的方法。该存储介质包括非瞬间存储介质。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
在一些情况下，上述任一两个技术特征不冲突的情况下，可以组合成新的方法技术方案。
在一些情况下，上述任一两个技术特征不冲突的情况下，可以组合成新的设备技术方案。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种信息处理方法，其特征在于，包括：
创建预定服务；
从IP地址资源池中为所述预定服务分配目标IP地址；其中，所述预定服务映射有一个或多个容器；
广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。
2.根据权利要求1所述的方法，其特征在于，所述IP地址资源池中包括多个IP地址；其中，一个所述IP地址具有一个映射信息；所述映射信息的字符长度小于所述IP地址的字符长度；
所述方法，包括：
根据目标IP地址对应的映射信息，生成所述预定服务分配的IP地址配置。
3.根据权利要求1或2所述的方法，其特征在于，在所述预定服务的数量为N个时，所述从IP地址资源池中为所述预定服务分配目标IP地址，包括：
从所述映射信息中依次顺序确定N个目标映射信息，所述目标映射信息用于确定所述目标IP地址。
4.根据权利要求1所述的方法，其特征在于，所述预定服务，包括：
支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。
5.根据权利要求1所述的方法，其特征在于，所述预定服务包括：负载均衡服务。
6.一种信息处理装置，其特征在于，包括：
创建模块，用于创建预定服务；
目标IP分配模块，用于从IP地址资源池中为所述预定服务分配目标IP地址；其中，所述预定服务映射有一个或多个容器；
广播模块，用于广播所述目标IP地址；其中，所述目标IP地址，用于访问所述预定服务映射的容器。
7.根据权利要求6所述的装置，其特征在于，所述IP地址资源池中包括多个IP地址；其中，一个所述IP地址具有一个映射信息；所述映射信息的字符长度小于所述IP地址的字符长度；
所述装置包括：
生成模块，用于根据目标IP地址对应的映射信息，生成所述预定服务分配的IP地址配置。
8.根据权利要求6或7所述的装置，其特征在于，
所述目标IP分配模块，还用于在所述预定服务的数量为N个时，从所述映射信息中依次顺序确定N个目标映射信息，所述目标映射信息用于确定所述目标IP地址。
9.根据权利要求6所述的装置，其特征在于，所述预定服务，包括：
支持IPv4的第一类预定服务和支持IPv6的第二类预定服务。
10.根据权利要求6所述的装置，其特征在于，所述预定服务包括：负载均衡服务。
11.一种电子设备，包括：
处理器；
存储器，其存储有程序指令，当所述程序指令被所述处理器执行时，使得所述电子设备执行如权利要求1～5任一项所述的方法。
12.一种存储介质，其存储有程序，当所述程序由处理器运行时，执行如权利要求1～5任一项所述的方法。
CN202210006427.7A 2022-01-05 2022-01-05 一种信息处理方法、装置、电子设备及存储介质 Pending CN116414515A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210006427.7A CN116414515A (zh) 2022-01-05 2022-01-05 一种信息处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210006427.7A CN116414515A (zh) 2022-01-05 2022-01-05 一种信息处理方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN116414515A true CN116414515A (zh) 2023-07-11

Family

ID=87057029

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210006427.7A Pending CN116414515A (zh) 2022-01-05 2022-01-05 一种信息处理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN116414515A (zh)

Similar Documents

Publication Publication Date Title
CN110113441B (zh) 实现负载均衡的计算机设备、系统和方法
US10375015B2 (en) Methods and system for allocating an IP address for an instance in a network function virtualization (NFV) system
CN106686085B (zh) 一种负载均衡的方法、装置和系统
CN110012125B (zh) 集群网络通信方法、装置、存储介质和设备
JP4897927B2 (ja) 複数のアダプタにわたり複数の仮想ｉｐアドレスを同時にサポートしているホストにおけるフェイルオーバのための方法、システム、およびプログラム
CN109194525B (zh) 一种网络节点配置方法及管理节点
CN113225214B (zh) 协同管理边缘cdn节点的方法、装置及计算机可读介质
US8458303B2 (en) Utilizing a gateway for the assignment of internet protocol addresses to client devices in a shared subset
US20050125575A1 (en) Method for dynamic assignment of slot-dependent static port addresses
CN114070723A (zh) 裸金属服务器的虚拟网络配置方法、系统及智能网卡
CN107517129B (zh) 一种基于OpenStack配置设备上行接口的方法和装置
CN112968976B (zh) 外网访问控制系统、方法、装置、设备及存储介质
CN114448937A (zh) 访问请求的响应方法和装置、存储介质
JP2004356920A (ja) Ｄｈｃｐサーバシステム
CN110247778B (zh) 操作系统安装方法、装置、电子设备及存储介质
CN110636149B (zh) 远程访问方法、装置、路由器及存储介质
CN107172229B (zh) 路由器的配置方法及装置
CN116414515A (zh) 一种信息处理方法、装置、电子设备及存储介质
JP2000183874A (ja) マルチプロトコルネットワーク管理方法、マルチプロトコルネットワーク管理プロキシサーバシステム、マルチプロトコルアドレス管理サーバシステム、および、マルチプロトコルネットワーク管理システム
CN109819027A (zh) 一种服务器系统远程启动方法、装置、设备及存储介质
EP4184873A1 (en) Communication method, cp device, and nat device
JP4962451B2 (ja) 負荷分散方法およびｄｈｃｐサーバ装置
CN111630814B (zh) 由第一装置与第二装置自动设立符合动态路由协议的会话的方法
CN114765601A (zh) 一种地址前缀获取方法及装置
WO2024001549A1 (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