Stateful service management method and device, equipment and storage medium

Abstract

The application provides a stateful service management method and device, equipment and storage medium, applied to the technical field of cloud computing, cloud service, database and the like, comprising: obtaining initial configuration information corresponding to a stateful service; determining N shards corresponding to the stateful service based on Pod shard information and Pod replica information included in the initial configuration information, and creating a corresponding number of Pods under each replica of each shard; determining a Pod naming interval corresponding to each shard based on the Pod shard information and the Pod replica information; for the i-th shard, the naming of each Pod under each replica in the i-th shard can be determined within the Pod naming interval corresponding to the i-th shard. That is, the application combines Pod naming with shard information and replica information where the Pod is located, and subsequent independent operations can be performed on the Pod under any replica in any shard based on Pod naming, enhancing the management of stateful services and enabling smooth and stable containerization of stateful services.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for managing stateful services. Background Technology

[0002] Stateful services refer to services that need to maintain the state of data to ensure reliability and consistency. In Kubernetes, stateful services typically refer to services that require persistent data storage, such as database services.

[0003] In Kubernetes, the built-in StatefulSet workload is used to deploy and manage stateful services. For example, a StatefulSet provides a unique name for the Pods corresponding to a stateful service. To enable Pod scaling and rolling updates, the current StatefulSet assigns sequential unique names to each Pod for a stateful service. However, this sequential naming prevents users from manipulating arbitrary Pods, resulting in less than ideal stateful service management. Therefore, proper Pod naming is crucial. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for managing stateful services, which can improve the naming rationality of pods and thus enhance the management effect of stateful services.

[0005] Firstly, this application provides a method for managing stateful services, including:

[0006] Obtain the initial configuration information corresponding to the stateful service, including Pod sharding information and Pod replica information;

[0007] Based on the Pod sharding information and the Pod replica information, N shards corresponding to the stateful service are determined, and a corresponding number of Pods are created under each replica of each shard, where N is a positive integer;

[0008] Based on the Pod shard information and the Pod replica information, determine the Pod naming range corresponding to each of the N shards;

[0009] For the i-th shard among the N shards, within the Pod naming range corresponding to the i-th shard, determine the name of each Pod under each replica in the i-th shard, where i is a positive integer less than or equal to N.

[0010] Secondly, this application provides a management device for stateful services, including:

[0011] The acquisition unit is used to acquire the initial configuration information corresponding to the stateful service, the initial configuration information including Pod sharding information and Pod replica information;

[0012] A creation unit is used to determine N shards corresponding to the stateful service based on the Pod shard information and the Pod replica information, and to create a corresponding number of Pods under each replica of each shard, where N is a positive integer;

[0013] The interval determination unit is used to determine the Pod naming interval corresponding to each of the N shards based on the Pod shard information and the Pod replica information;

[0014] The naming unit is used to determine the name of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard, where i is a positive integer less than or equal to N.

[0015] In some embodiments, the Pod shard information further includes a preset number of shards and a maximum number of replicas in each shard, and the Pod replica information includes the maximum number of Pods coexisting in each replica; the interval determination unit is specifically used to determine the index of the i-th shard in the N shards based on the preset number of shards for the i-th shard; and to determine the Pod naming interval corresponding to the i-th shard based on the index of the i-th shard in the N shards, the maximum number of replicas in each shard, and the maximum number of Pods coexisting in each replica.

[0016] In some embodiments, the interval determination unit is specifically used to determine the length of the Pod naming interval corresponding to each of the N shards based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; and to determine the Pod naming interval corresponding to the i-th shard based on the length of the Pod naming interval and the index of the i-th shard in the N shards.

[0017] In some embodiments, the interval determination unit is specifically used to determine the starting point value of the Pod naming interval corresponding to the i-th shard as the product of the length of the Pod naming interval and the index of the i-th shard in the N shards; and to determine the ending point value of the Pod naming interval corresponding to the i-th shard as the sum of the starting point of the Pod naming interval corresponding to the i-th shard and the length of the Pod naming interval minus 1.

[0018] In some embodiments, the naming unit is specifically used to determine, for the j-th Pod in the i-th shard, the replica index of the k-th replica where the j-th Pod is located in the i-th shard, where k and j are both positive integers; and to determine the name of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

[0019] In some embodiments, the naming unit is specifically used to multiply the replica index of the k-th replica by the maximum number of Pods coexisting in each replica to obtain a first product; to determine the name of the first Pod in the k-th replica by the sum of the starting point value of the Pod naming interval corresponding to the i-th shard and the first product; and to determine the name of the j-th Pod based on the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica.

[0020] In some embodiments, the naming unit is specifically used to determine the name of the first Pod as the name of the j-th Pod if the j-th Pod is the first Pod in the k-th replica; and to determine the name of the j-th Pod as the sum of the index of the j-th Pod in the k-th replica and the name of the first Pod if the j-th Pod is not the first Pod in the k-th replica.

[0021] In some embodiments, after determining the names of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard, the naming unit is further configured to obtain configuration change information corresponding to the stateful service. The configuration change information includes at least one of Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. Based on the configuration change information, the Pod information currently corresponding to the stateful service is modified.

[0022] In some embodiments, if the configuration change information includes the new Pod indication information, the naming unit is specifically used to determine the names of the M first Pods to be added based on the Pod addition indication information, where M is a positive integer; for each of the M first Pods, the first shard and the first replica where the first Pod is located are determined based on the name of the first Pod; and the first Pod is added in the first replica under the first shard.

[0023] In some embodiments, if the configuration change information includes the Pod deletion instruction information, the naming unit is specifically used to determine the names of the K second Pods to be deleted based on the Pod deletion instruction information, where K is a positive integer; for each of the K second Pods, the second shard and the second replica where the second Pod is located are determined based on the name of the second Pod; and the second Pod under the second replica in the second shard is deleted.

[0024] In some embodiments, if the configuration change information includes the Pod addition indication information and the Pod deletion indication information, and the first Pod to be added indicated by the Pod addition indication information and the second Pod to be deleted indicated by the Pod deletion indication information are the same Pod, then the step of adding the first Pod is skipped.

[0025] In some embodiments, if the configuration change information includes the Pod template update indication information, the naming unit is specifically used to determine, based on the Pod template update indication information, the names of the P third Pods whose templates are to be changed and the template configuration adjustment information corresponding to each of the P third Pods, where P is a positive integer; for each of the P third Pods, based on the name of the third Pod, the third shard and the third replica where the third Pod is located are determined; based on the template configuration adjustment information corresponding to the third Pod, the template configuration of the third Pod in the third replica under the third shard is adjusted, wherein the template configurations of each Pod corresponding to the stateful service are not completely the same.

[0026] In some embodiments, if the configuration change information includes the replica rolling upgrade instruction information, the naming unit is specifically used to determine the names of the Q fourth Pods to be upgraded based on the replica rolling upgrade instruction information, where Q is a positive integer; for each of the Q fourth Pods, the fourth shard and the fourth replica where the fourth Pod is located are determined based on the name of the fourth Pod; the fourth Pod is created under the fourth replica in the fourth shard, and after the fourth Pod is successfully created, the old Pod under the fourth replica in the fourth shard is deleted.

[0027] In some embodiments, the naming unit is specifically used to obtain the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; determine the length of the Pod naming interval corresponding to each shard based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; determine the shard where the Pod is located based on the Pod's name and the length of the Pod naming interval; determine the replica where the Pod is located based on the Pod's name, the length of the Pod naming interval, and the maximum number of Pods coexisting in each replica; wherein, if the Pod is the first Pod, then the shard where the Pod is located is the first shard and the replica where the Pod is located is the first replica; if the Pod is the second Pod, then the shard where the Pod is located is the second shard and the replica where the Pod is located is the second replica; if the Pod is the third Pod, then the shard where the Pod is located is the third shard and the replica where the Pod is located is the third replica; if the Pod is the fourth Pod, then the shard where the Pod is located is the fourth shard and the replica where the Pod is located is the fourth replica.

[0028] In some embodiments, the naming unit is specifically used to round down the quotient of the Pod's name and the length of the Pod's naming range to obtain the shard where the Pod is located.

[0029] In some embodiments, the naming unit is specifically used to perform a modulo operation between the name of the Pod and the length of the Pod naming range to obtain a remainder; and to round down the quotient of the remainder and the maximum number of Pods coexisting in each replica to obtain the replica where the Pod is located.

[0030] Thirdly, an electronic device is provided, including a processor and a memory. The memory is used to store a computer program, and the processor is used to invoke and run the computer program stored in the memory to perform the methods described in the first aspect and its various implementations.

[0031] Fourthly, a chip is provided for implementing the methods of any one of the first aspects or their respective implementations. Specifically, the chip includes a processor for calling and running a computer program from a memory, causing a device on which the chip is installed to perform the methods of the first aspect and its respective implementations as described above.

[0032] Fifthly, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the methods described in the first aspect and its various implementations.

[0033] In a sixth aspect, a computer program product is provided, including computer program instructions that cause a computer to perform the methods described in the first aspect and its various implementations.

[0034] In a seventh aspect, a computer program is provided that, when run on a computer, causes the computer to perform the methods described in the first aspect and its various implementations.

[0035] In summary, this embodiment of the application obtains the initial configuration information corresponding to the stateful service, which includes Pod shard information and Pod replica information. Then, based on the Pod shard information and Pod replica information included in the initial configuration information, it determines N shards corresponding to the stateful service and creates a corresponding number of Pods under each replica of each shard. Simultaneously, based on the Pod shard information and Pod replica information, it determines the Pod naming range corresponding to each of these N shards. Thus, for each of the N shards, such as the i-th shard, the names of each Pod under each replica of the i-th shard can be determined within the Pod naming range corresponding to the i-th shard. In this embodiment, the Pods corresponding to stateful services are grouped according to Pod shard information and Pod replica information, and the Pod naming range corresponding to each shard is determined. Then, the Pods under each replica in the shard are named within the Pod naming range corresponding to the shard. This combines the Pod naming with the shard information and replica information of the Pod, improving the rationality of Pod naming. In this way, Pods under any replica in any shard can be operated independently based on the Pod naming, which fully enhances the management of stateful services in cloud-native scenarios and can help the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a schematic diagram of a Kubernetes (k8s) architecture.

[0038] Figure 2 This is a diagram illustrating the deletion of a pod using relevant technologies.

[0039] Figure 3 This is a schematic diagram of an implementation environment involved in an embodiment of this application;

[0040] Figure 4A schematic diagram of a stateful service management method provided in an embodiment of this application;

[0041] Figure 5 A diagram showing the correspondence between SSS objects and SSS controllers;

[0042] Figure 6 This is an example diagram illustrating the partitioning of shards, replicas, and Pods.

[0043] Figure 7 Example diagram of a Pod naming convention;

[0044] Figure 8 An example diagram of another way to name a Pod;

[0045] Figure 9 A schematic diagram of a stateful service management method provided in an embodiment of this application;

[0046] Figure 10 This is a diagram illustrating the changes made to a pod.

[0047] Figure 11 This is a diagram illustrating the addition of a new pod.

[0048] Figure 12 A diagram illustrating the deletion of a pod;

[0049] Figure 13A This is a diagram illustrating a copy upgrade.

[0050] Figure 13B This is a diagram illustrating another type of copy upgrade;

[0051] Figure 14 This is a schematic block diagram of a stateful service management device provided in an embodiment of this application;

[0052] Figure 15 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0054] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein. In embodiments of the invention, "B corresponding to A" means that B is associated with A. In one implementation, B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0055] The technical solution proposed in this application can be applied to the fields of cloud computing, cloud services, databases, etc., to improve the management flexibility of stateful services.

[0056] In some embodiments, the technical solutions of this application can be applied to cloud-native cluster use cases, which can fully enhance the management of stateful services in cloud-native scenarios and help stateful services such as databases, middleware, and consensus systems to be containerized smoothly and stably.

[0057] The relevant technologies involved in the embodiments of this application are described below.

[0058] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0059] Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, resources in the "cloud" appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0060] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called an IaaS (Infrastructure as a Service) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0061] Kubernetes, or Kubernetes for short, is an open-source application used to manage containerized applications across multiple hosts in a cloud platform. The goal of Kubernetes is to make deploying containerized applications simple and powerful; Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance.

[0062] like Figure 1 As shown, a Kubernetes cluster typically consists of a master node and multiple worker nodes. A node can be viewed as a physical machine or a virtual machine.

[0063] The master node is used to manage and control the entire Kubernetes cluster. The master node occupies a dedicated server.

[0064] The components running on the master node include:

[0065] apiserver: It is the unified entry point of the Kubernetes cluster. It provides interface services via HTTP REST. All operations such as adding and deleting object resources are handled by apiserver and then handed over to Etcd storage.

[0066] controller-manager: It is the control center for all resource objects in Kubernetes, and handles regular background tasks in the cluster. For example, one resource corresponds to one controller, and kube-controller-manager is used to control these controllers.

[0067] schedule (work plan): Selects a worker node for the newly created Pod according to the scheduling algorithm. It can be deployed arbitrarily, on the same node or on different nodes.

[0068] Etcd is a distributed, consistent key-value store, primarily used for sharing configuration and service discovery, and for storing cluster state data, such as information about Pods and Services.

[0069] Worker nodes are the workload nodes in a Kubernetes cluster. Each worker node is assigned some workload by the master node. When a worker node fails, its workload will be automatically transferred to other worker nodes by the master node.

[0070] The components running on the worker nodes include:

[0071] Kubelet is the agent (proxy) of the master node on the worker nodes. It works closely with the master node to manage the lifecycle of containers running on the local machine, and is responsible for tasks such as creating, starting and stopping containers corresponding to Pods, thus realizing the basic functions of cluster management.

[0072] kube-proxy is a Pod network proxy implemented on worker nodes, enabling communication between Kubernetes services, maintaining network rules, and performing Layer 4 load balancing.

[0073] Docker (a container engine): responsible for creating and managing containers on the local machine. For example... Figure 1 As shown, a Docker container can contain multiple Pods.

[0074] A Pod is the smallest deployable unit of computing that can be created and managed in Kubernetes; it is a collection of containers.

[0075] like Figure 1 As shown, a Pod can contain one or more containers, in which applications and services can run.

[0076] Services in Kubernetes include stateless services and stateful services.

[0077] Stateful services refer to services that need to maintain the state of data to ensure reliability and consistency. In Kubernetes, stateful services typically refer to services that require persistent data storage, such as database services.

[0078] Managing stateful services on Kubernetes is challenging. On one hand, these underlying capabilities adapt to the Kubernetes environment, providing resource allocation / binding / release mechanisms as resource objects. On the other hand, the higher-level stateful service management plane must correctly utilize Kubernetes' declarative interface to associate service instance nodes (Pods) with underlying resources, thus achieving stateful service management. This dynamic binding capability allows stateful services to be migrated from a Pets architecture to a Cattle architecture, improving their availability and stability.

[0079] Pods are associated with underlying resources that have persistent state. From a management perspective, nodes composed of different Pods in a stateful service are often not peer-to-peer, and this asymmetry may be perceptible to both the management and user ends. Different Pods have different roles. For example, in a master / slave architecture MySQL cluster, online service programs connect to Pods with the master role to write data, while some background services connect to Pods with the slave role to read data for analysis.

[0080] Perceived asymmetry requires Pods to have unique and identifiable IDs. Furthermore, the lifecycle of a Pod is shorter than the lifecycle of these underlying resources. When a Pod migrates and a new Pod object is created, the historical state needs to be associated with the newly created Pod. This requires that the IDs of stateful service Pods be stable, because only stable IDs can be found in the underlying system to correspond to persistent resources.

[0081] Kubernetes has a built-in StatefulSet, a stateful service workload. Kubernetes uses workloads to manage a group of Pods, reducing the complexity of managing Pods.

[0082] One of the core capabilities of StatefulSet is to provide unique and stable IDs, which are expressed through Pod naming.

[0083] For example, a StatefulSets workload will create a batch of Pods with fixed names in the cluster, as described in the spec: `p-0, p-1, p-2`.

[0084]

[0085] In addition to providing a stable and unique ID mechanism for Pods, StatefulSets workloads also assume that these IDs are sequentially ordered, thus providing scaling and rolling update capabilities (including a range rolling update function). For example, when you need to reduce the number of Pods, modify the StatefulSet by decreasing the `Replicas` field, and the StatefulSet will delete Pods one by one, starting from the largest ID. Figure 2 This demonstrates the process of reducing Replicas from 4 to 2 and deleting Pods in a StatefulSet. First, the Pod with the largest ID, named p-3, is deleted. Then, the remaining Pod with the largest ID, named p-2, is deleted.

[0086] In one example, a Redis cluster with a "multi-shard + multi-replica + master / slave" architecture has the following requirements for Pod management:

[0087] 1. Processes in a Pod need to know which shard they belong to, which is necessary for detecting the continuity of data;

[0088] 2. Add or delete a shard;

[0089] 3. Allows adding or deleting replicas for any number of shards;

[0090] 4. There are non-peer configurations between Pods (e.g., image, CPU, memory);

[0091] 5. Stable upgrade: To upgrade a shard (e.g., image), a new shard must be added first. The corresponding old shard will only be terminated after the new shard has stabilized.

[0092] To achieve the above functionality, independent operations (adding / deleting / modifying) of Pods are required. However, the sequential and ordered naming provided by StatefulSets workloads, if unreasonable, prevents users from operating on any Pod, thus making the management of stateful services unsatisfactory. Therefore, in stateful services, how to reasonably name Pods to enable operations on any independent Pod has become a pressing technical problem to be solved in this field.

[0093] To address the aforementioned technical issues, this application provides a novel Pod controller (also known as a workload) that enables flexible management of stateful services. Specifically, it obtains initial configuration information corresponding to the stateful service, including Pod shard information and Pod replica information. Then, based on the Pod shard and Pod replica information included in the initial configuration information, it determines N shards corresponding to the stateful service and creates a corresponding number of Pods under each replica of each shard. Simultaneously, based on the Pod shard and Pod replica information, it determines the Pod naming range corresponding to each of the N shards. Thus, for each of the N shards, such as the i-th shard, the names of each Pod under each replica of the i-th shard can be determined within the Pod naming range corresponding to the i-th shard. In this embodiment, the Pods corresponding to stateful services are grouped according to Pod shard information and Pod replica information, and the Pod naming range corresponding to each shard is determined. Then, the Pods under each replica in the shard are named within the Pod naming range corresponding to the shard. This combines the Pod naming with the shard information and replica information of the Pod. In this way, the Pods under any replica in any shard can be operated independently based on the Pod naming, which greatly enhances the management of stateful services in cloud-native scenarios and can help the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems.

[0094] The implementation environment of the embodiments of this application is described below.

[0095] Figure 3 This is a schematic diagram of an implementation environment according to an embodiment of this application, including a terminal device 101, a first working node 102, and multiple second working nodes 103. Figure 3 As shown, terminal device 101 is communicatively connected to first working node 102, and first working node 102 is communicatively connected to multiple second working nodes 103.

[0096] In this embodiment, the first worker node 102 can be a physical node or a virtual node, and a Pod controller is deployed on the first worker node 102. In one example, the Pod controller can be called a StateSliceSet(sss) controller. One or more Pods can be deployed on each of the plurality of second worker nodes 103. Optionally, one or more Pods can also be deployed on the first worker node 102.

[0097] In one possible implementation of this application embodiment, a user can send initial configuration information corresponding to a stateful service to a first working node 102 via a terminal device 101. This initial configuration information includes Pod shard information and Pod replica information. The first working node 102 can create Pods and name the created Pods based on the Pod shard information and Pod replica information in the initial configuration information sent by the terminal device 101 in the first working node 102 and / or multiple second working nodes 103. Specifically, the Pod controller in the first working node 102 determines N shards corresponding to the stateful service based on the Pod shard information and Pod replica information, and creates a corresponding number of Pods under each replica of each shard, where N is a positive integer. Then, based on the Pod shard information and Pod replica information, it determines the Pod naming range corresponding to each of the N shards. Thus, for the i-th shard among the N shards, within the Pod naming range corresponding to the i-th shard, it determines the names of each Pod under each replica of the i-th shard. The names of the Pods in the i-th shard are not consecutive, where i is a positive integer less than or equal to N. This application embodiment groups the Pods corresponding to stateful services according to Pod shard information and Pod replica information, and determines the Pod naming range corresponding to each shard. Then, it names the Pods under each replica in the shard within the Pod naming range corresponding to the shard, so that the Pod naming is combined with the shard information and replica information of the Pod. In this way, the Pods under any replica in any shard can be operated independently based on the Pod naming, which greatly enhances the management of stateful services in cloud-native scenarios and can help the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems.

[0098] In some embodiments, the second working node 102 of this application determines the names of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard through the Pod controller, and also obtains the configuration change information corresponding to the stateful service. The configuration change information includes at least one of Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. Based on the configuration change information, the Pod information currently corresponding to the stateful service is changed, such as adding a specified Pod, deleting a specified Pod, updating the template of a specified Pod, or performing a rolling upgrade of a specified Pod replica, etc., thereby realizing effective management of the Pods corresponding to the stateful service.

[0099] In some embodiments, the second working node 102 and / or the third working node 103 involved in this application embodiment can be one or more servers. When there are multiple servers, at least two servers are used to provide different services, and / or at least two servers are used to provide the same service, such as providing the same service in a load-balanced manner. This application embodiment does not limit this. The aforementioned servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The second working node 102 and / or the third working node 103 can also become nodes in the blockchain.

[0100] In some embodiments, the terminal device 101 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited thereto. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0101] It should be noted that the implementation environment of this application embodiment includes, but is not limited to, Figure 3 As shown.

[0102] The technical solutions of the embodiments of this application will be described in detail below through some examples. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0103] Figure 4 This is a schematic flowchart illustrating a stateful service management method according to an embodiment of this application. The stateful service management method provided in this embodiment can be implemented by a device with management functions, such as a stateful service management device. In one example, the stateful service management device can be a worker node, for example... Figure 3 The second worker node, or a part of a second worker node, is used to manage stateful services. In one example, the management device for a stateful service can be a Pod controller within the second worker node, used to configure and manage the Pods corresponding to the stateful service. For ease of description, the following example uses a Pod controller as the execution entity.

[0104] like Figure 4 As shown, the stateful service management method of this application embodiment includes the following steps:

[0105] S101. Obtain the initial configuration information corresponding to the stateful service.

[0106] The initial configuration information includes Pod shard information and Pod replica information.

[0107] A stateful service is one that needs to maintain the state of data to ensure reliability and consistency, such as saving user login sessions and shopping cart information. Stateful services require the use of shared data storage to store and manage state information.

[0108] In this embodiment of the application, the stateful service can be any stateful service such as a database service or a message queue service.

[0109] In some embodiments, a stateful service instance can be divided into one or more stateful services according to its function, such as a database service and a traffic statistics service. Each of these stateful services corresponds to a group of Pods. In this embodiment, a group of Pods can be created for each stateful service, and this group of Pods can be sharded and replicated. Then, based on the Pod sharding information and Pod replica information, each Pod in this group is named to obtain a unique name for each Pod in the group corresponding to the stateful service. For example, assuming that the stateful service in this embodiment is a database service, the Pod manager creates a group of Pods for the database service and uses the naming method provided in this embodiment to name each Pod in the group corresponding to the database service.

[0110] As described above, the stateful service in this embodiment can be understood as a stateful service under a stateful service instance, such as a database service. Before creating a group of Pods for the database service in the cluster, the Pod controller first obtains the initial configuration information corresponding to the stateful service. This initial configuration information is used to indicate the Pod information corresponding to the stateful service, such as Pod shard information and Pod replica information.

[0111] This application does not limit the specific content of Pod shard information. For example, it may include information such as the preset number of shards, the maximum number of replicas included in each shard, and the default number of replicas for each shard.

[0112] This application does not limit the specific content of the Pod replica information, but may include information such as the maximum number of Pods coexisting in each replica and the default number of Pods in each replica.

[0113] This application embodiment does not restrict the specific method by which the Pod controller obtains the initial configuration information corresponding to the stateful service.

[0114] In one possible implementation, the user generates initial configuration information corresponding to the stateful service and sends this initial configuration information to the Pod controller. For example, the user sends this initial configuration information to the worker node where the Pod controller resides via a terminal device, so that the Pod controller can pull the initial configuration from that worker node.

[0115] In one possible implementation, the user inputs the required information for the stateful service, such as the preset number of shards and replicas. After obtaining the user's required information, the Pod controller generates the initial configuration information for the stateful service based on this information.

[0116] In one example, the Pod controller in this embodiment can be a StateSliceSet controller, or SSS controller for short. That is, this embodiment adds a custom resource (CR) of the StateSliceSet in Kubernetes based on the operator's running mode. Figure 5 As shown, the initial configuration information mentioned above can be understood as an SSS object. The SSS controller monitors this SSS object and thus obtains the initial configuration information corresponding to the stateful service.

[0117] In one example, the initial configuration information for a stateful service is shown below:

[0118]

[0119]

[0120] In this example, the initial configuration information corresponding to the stateful service includes Pod sharding information such as: the number of shards in the cluster (e.g., 3), the default number of replicas per shard (e.g., 2), and the maximum number of replicas per shard (e.g., 5). Replica information includes: the maximum number of Pods coexisting in each replica (e.g., 2), and the default number of Pods per replica (e.g., 1). In this example, the default number of Pods per replica can be omitted, defaulting to 1. Optionally, the default number of replicas per shard can also be omitted, for example, defaulting to 2. That is, the initial configuration information in this embodiment can include the number of shards in the cluster, the maximum number of replicas per shard, and the maximum number of Pods coexisting in each replica, while the default number of replicas per shard and the default number of Pods per replica can be omitted.

[0121] It should be noted that the specific values ​​in the above initial configuration information, such as the number of cluster shards being 3 and the default number of replicas per shard being 2, are just examples. Other values ​​are also possible, and this application embodiment does not limit them.

[0122] In this embodiment of the application, after the Pod controller obtains the initial configuration information corresponding to the stateful service, it executes the following step S102.

[0123] S102. Based on Pod shard information and Pod replica information, determine the N shards corresponding to the stateful service, and create the corresponding number of Pods under each replica of each shard.

[0124] Where N is a positive integer.

[0125] In this embodiment, after obtaining the initial configuration information corresponding to the stateful service, the Pod controller can determine the N shards corresponding to the stateful service based on the Pod shard information and Pod replica information included in the initial configuration information, as well as the number of replicas included in each of the N shards and the number of Pods included under each replica. This allows the creation of a corresponding number of Pods under each replica of the N shards based on the number of replicas included in each of the N shards and the number of Pods included under each replica.

[0126] In one example, suppose the initial state information for a stateful service includes a preset number of shards, a default number of replicas per shard, and a default number of pods per replica. Alternatively, the initial state information may include the preset number of shards but exclude at least one of the default number of replicas per shard and the default number of pods per replica. In this case, the Pod controller can determine the default number of replicas per shard and the default number of pods per replica based on at least one of the default values ​​corresponding to these values. Thus, the Pod controller creates Pods for the stateful service based on the preset number of shards, the default number of replicas per shard, and the default number of pods per replica, and then partitions the Pods into shards.

[0127] For example, suppose the initial configuration information for this stateful service includes a preset number of shards of 2, a default number of replicas per shard of 2, and a default number of Pods per replica of 1. Based on this information, we can obtain the following... Figure 6 The diagram shown illustrates the partitioning of shards, replicas, and Pods. It includes two shards, s0 and s1. Shard s0 has two replicas, denoted as s0r0 and s0r1, and s1 has two replicas, denoted as s1r0 and s1r1. Each replica contains one Pod. This allows the Pod controller to be based on... Figure 6 The structure shown creates a corresponding number of Pods under each replica in each shard. For example, a Pod is created under replicas s0r0 and s0r1 in shard s0, and a Pod is created under replicas s1r0 and s1r1 in shard s1.

[0128] In some embodiments, the initial configuration information also includes Pod specifications (CPU, memory, disk, etc.), image information, environment variables, startup parameters, Pod container information (starting container group and running container group), and differential configurations, etc. The Pod controller can create Pods based on these parameters.

[0129] In some embodiments, the Pod controller of this application can first determine the total number of Pods corresponding to the stateful service based on a preset number of shards, the default number of replicas for each shard, and the default number of Pods for each replica, and then create that total number of Pods. Next, based on the above... Figure 6 The partitioning structure of shards, replicas, and Pods shown assigns the created Pods to replicas of the corresponding shards. For example, each replica in each shard is assigned a created Pod.

[0130] In some embodiments, if a Pod exists in the cluster, the Pod controller can delete the existing Pod and then recreate it. Alternatively, the Pod controller can update the existing Pod, for example, by updating the configuration of the existing Pod based on the Pod configuration information included in the initial configuration information, such as updating at least one of the following configurations of the existing Pod: annotations, labels, tolerances, image information, etc.

[0131] In some embodiments, there are non-equivalent configurations between the Pods created in this application, such as at least two Pods having unequal template configuration resources for image, CPU, memory, etc. (i.e., different).

[0132] Based on Pod shard information and Pod replica information, the Pod controller determines the N shards corresponding to the stateful service, and after creating the corresponding number of Pods under each replica of each shard, executes the following steps S103.

[0133] S103. Based on Pod shard information and Pod replica information, determine the Pod naming range corresponding to each of the N shards.

[0134] It should be noted that, in this embodiment, after determining the N shards corresponding to the stateful service, the Pod controller can first create the corresponding number of Pods under each replica of each shard, and then determine the Pod naming range corresponding to each of the N shards based on the Pod shard information and Pod replica information. Alternatively, after determining the N shards corresponding to the stateful service, the Pod controller can first determine the Pod naming range corresponding to each of the N shards based on the Pod shard information and Pod replica information, and then create the corresponding number of Pods under each replica of each shard. Or, after determining the N shards corresponding to the stateful service, the Pod controller can simultaneously create the corresponding number of Pods under each replica of each shard while determining the Pod naming range corresponding to each of the N shards based on the Pod shard information and Pod replica information.

[0135] In this embodiment, after the Pod controller determines the N shards corresponding to the stateful service, it can determine the Pod naming range corresponding to each of the N shards based on the Pod shard information and Pod replica information. That is, in this embodiment, each of the N shards corresponds to a Pod naming range. Based on this Pod naming range, the names of each Pod under that shard can be determined, making the Pod name related to the shard and replica to which the Pod belongs. This allows for subsequent determination of the shard and replica of the Pod based on its name, enabling independent operations such as deletion and updating of specified Pods. This achieves effective management of Pods corresponding to the stateful service, significantly enhancing the management of stateful services in cloud-native scenarios and facilitating the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems.

[0136] The following section describes the specific process by which Pod control determines the Pod naming range corresponding to each of the N shards based on Pod shard information and Pod replica information.

[0137] In this application's embodiments, Pod naming can be understood as a unique identifier for the Pod, referred to as PodID in some embodiments. Pod naming ranges can be understood as identifier ranges, ID ranges, or ID segments. In this application's embodiments, the Pod naming ranges corresponding to different shards in the N shards are different and do not overlap. For example, the Pod naming range corresponding to shard 1 is 0 to 99, the Pod naming range corresponding to shard 2 is 100 to 199, and the Pod naming range corresponding to shard 3 is 200 to 299.

[0138] In some examples, the length of the Pod naming range corresponding to each of the N shards is the same. For example, the length of the Pod naming range corresponding to each of the N shards is 100. For instance, N=3, the Pod naming range corresponding to shard 1 is 0 to 99, the Pod naming range corresponding to shard 2 is 100 to 199, and the Pod naming range corresponding to shard 3 is 200 to 299.

[0139] In some examples, the length of the Pod naming range corresponding to each of the N shards is not consistent. For example, when N=3, the Pod naming range corresponding to shard 1 is 0 to 99 with a length of 100, the Pod naming range corresponding to shard 2 is 100 to 299 with a length of 200, and the Pod naming range corresponding to shard 3 is 300 to 379 with a length of 80.

[0140] In some examples, the Pod naming ranges corresponding to some of the N shards have the same length, while the shard lengths corresponding to other shards are different. For example, when N=4, the Pod naming range for shard 1 has a length of 100, the naming range for shard 2 has a length of 100, the Pod naming range for shard 3 has a length of 200, and the Pod naming range for shard 4 has a length of 300.

[0141] In some examples, the Pod naming ranges corresponding to each of the N shards are consecutive. For example, the ending point of the Pod naming range corresponding to shard 1 is consecutive to the starting point of the Pod naming range corresponding to shard 2.

[0142] In this embodiment of the application, for each of the N shards, the length of the Pod naming interval corresponding to the shard is equal to the number of Pods under the shard. For example, if the shard includes 10 Pods, then the length of the Pod naming interval corresponding to the shard is greater than 10, such as 20, 100, 200, etc. This ensures that the Pod names under the shard are not consecutive, which makes it convenient to add Pods to the replicas under the shard.

[0143] This application does not restrict the specific method by which the Pod controller determines the Pod naming range corresponding to each of the N shards based on Pod shard information and Pod replica information.

[0144] In some embodiments, the Pod sharding information includes a preset number of shards N and the number of replicas under each shard. The Pod replica information includes the number of Pods included under each replica, wherein the number of replicas under each shard can be different, and the number of Pods included under each replica can also be different. Thus, for each shard in the N shards, the Pod naming range corresponding to that shard is determined based on the number of replicas under that shard and the number of Pods included in each replica under that shard. For example, for shard 1 in the N shards, shard 1 includes 2 replicas. The first replica includes 1 Pod, and the second replica includes 2 Pods. Since the second replica includes more Pods, a longer Pod naming range can be assigned to the second replica, for example, a Pod naming range of 40. The first replica includes fewer Pods, so a shorter Pod naming range can be assigned to the first replica, for example, a Pod naming range of 10. Therefore, the Pod naming range corresponding to shard 1 can be a Pod naming range greater than or equal to 40 + 10 = 50.

[0145] In some embodiments, if the Pod shard information includes a preset number of shards N and a maximum number of replicas in each shard, and the Pod replica information includes the maximum number of Pods coexisting in each replica, and the maximum number of replicas in each shard is the same, and the maximum number of Pods coexisting in each replica is also the same, then S103 includes the following steps S103-A and S103-B:

[0146] S103-A: For the i-th fragment, determine the index of the i-th fragment among the N fragments based on the preset number of fragments N;

[0147] S103-B: Based on the index of the i-th shard in the N shards, the maximum number of replicas in each shard, and the maximum number of Pods coexisting in each replica, determine the Pod naming range corresponding to the i-th shard.

[0148] In the embodiments of this application, the specific methods for determining the Pod naming range corresponding to each of the N shards are basically the same. For ease of description, the i-th shard among the N shards will be used as an example for explanation.

[0149] When determining the Pod naming range corresponding to the i-th shard, the index of the i-th shard among these N shards is first determined. In one example, the indices of the N shards start from 0, as shown in Table 1:

[0150] Table 1

[0151] N partitions The index of the shard First fragment 0 Second fragment 1 …… …… The i-th slice i-1 …… …… The Nth partition N-1

[0152] As shown in Table 1 above, the shard index starts from 0. For example, the index of the first shard in N shards is 0, the index of the i-th shard is i-1, and the index of the N-th shard is N-1.

[0153] In some embodiments, the indexes of the N shards may also start from numbers such as 1 or 2, and this application embodiment does not limit this.

[0154] For the i-th shard among N shards, after determining the index of the i-th shard among the N shards, the Pod naming range corresponding to the i-th shard is determined based on the index, the maximum number of replicas included in each shard, and the maximum number of Pods coexisting in each replica.

[0155] This application does not restrict the specific method for determining the Pod naming range corresponding to the i-th shard based on the index of the i-th shard in the N shards, the maximum number of replicas included in each shard, and the maximum number of Pods coexisting in each replica.

[0156] In some embodiments, the length of the Pod naming interval corresponding to the i-th shard is determined based on any two or three of the following: the index of the i-th shard among the N shards, the maximum number of replicas in each shard, and the maximum number of Pods that can coexist in each replica. Then, the product of this length and the index of the i-th shard is determined as the starting point value of the Pod naming interval corresponding to the i-th shard. For example, assuming the maximum number of replicas in each shard is 5 and the maximum number of Pods that can coexist in each replica is 2, and the index of the i-th shard among the N shards is 1, then the length of the Pod naming interval corresponding to the i-th shard can be 5 + 2 + 1 = 8, and the Pod naming interval corresponding to the i-th shard can be determined to be 8 to 15.

[0157] In some embodiments, S103-B above includes the following steps S103-B1 and S103-B2:

[0158] S103-B1. Based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica, determine the length of the Pod naming interval corresponding to each of the N shards.

[0159] S103-B2. Based on the length of the Pod naming range and the index of the i-th shard in the N shards, determine the Pod naming range corresponding to the i-th shard.

[0160] In this implementation, when determining the Pod naming interval corresponding to the i-th shard, the length of the Pod naming interval corresponding to each of the N shards is first determined based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica. For example, the product of the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica is used to determine the length of the Pod naming interval corresponding to each of the N shards.

[0161] Next, based on the length of the Pod naming range and the index of the i-th shard in the N shards, the Pod naming range corresponding to the i-th shard is determined.

[0162] For example, the starting point of the Pod naming interval is determined by multiplying the length of the Pod naming interval by the index of the i-th shard in the N shards; the ending point of the Pod naming interval is determined by subtracting 1 from the sum of the starting point of the Pod naming interval corresponding to the i-th shard and the length of the Pod naming interval.

[0163] For example, suppose each shard has a maximum of 5 replicas and a maximum of 2 Pods in each replica. The index of the i-th shard in the N shards is 0. Then the length of the Pod naming range corresponding to the i-th shard can be 5*2=10. The starting value of the Pod naming range corresponding to the i-th shard is 0 of 10*0, and the ending value of the Pod naming range corresponding to the i-th shard is 0+10-1=9. Therefore, the Pod naming range corresponding to the i-th shard is from 0 to 9.

[0164] The above describes the specific process of determining the Pod naming range corresponding to the i-th shard among N shards. Following this method, the Pod naming range corresponding to each of the N shards can be determined. For example, suppose N=2, each shard has a maximum of 100 replicas and a maximum of 2 Pods per replica, the first shard has an index of 0 in the two shards, and the second shard has an index of 1. When determining the Pod naming range corresponding to the first shard, firstly, based on the maximum of 100 replicas and the maximum of 2 Pods per replica, determine the length of the Pod naming range corresponding to each of the two shards. For example, the product of the maximum of 100 replicas and the maximum of 2 Pods per replica, 200, is used as the length of the Pod naming range corresponding to each of the two shards. Next, based on the length of the Pod naming range and the index 0 of the first shard in the two shards, determine the Pod naming range corresponding to the first shard. For example, the product of the index 0 of the first shard within these two shards and the length 200 of the Pod naming range (i.e., 0) is used to determine the starting value of the Pod naming range corresponding to the first shard. The sum of the starting value 0 and the length 200 of the Pod naming range, minus 1 (i.e., 199), is used to determine the ending value of the Pod naming range corresponding to the first shard. This gives us the Pod naming range for the first shard as 0 to 199. Similarly, for the second shard, the Pod naming range is determined based on the length of the Pod naming range and the index 1 of the second shard within these two shards. For example, the product of the index 1 of the second shard in these two shards and the length 200 of the Pod naming range (i.e., 200) is determined as the starting value of the Pod naming range corresponding to the second shard. The sum of the starting value 200 of the Pod naming range corresponding to the second shard and the length 200 of the Pod naming range minus 1 (i.e., 399) is determined as the ending value of the Pod naming range corresponding to the second shard. In this way, the Pod naming range corresponding to the second shard can be obtained as 200 to 399.

[0165] Based on the above steps, the Pod controller determines the Pod naming range corresponding to each of the N shards, and then executes the following step S104.

[0166] S104. For the i-th shard among N shards, within the Pod naming range corresponding to the i-th shard, determine the names of each Pod under each replica in the i-th shard.

[0167] In this context, the Pods in the i-th shard are not named consecutively, and i is a positive integer less than or equal to N.

[0168] In this embodiment, based on the above steps, the Pod naming range corresponding to each of the N shards is determined. Then, based on the Pod naming range corresponding to each shard, the Pods under each shard are named to obtain a unique identifier for each Pod. Specifically, for each of the N shards, the naming method for each Pod under each replica within the Pod naming range corresponding to that shard is basically the same. For ease of description, the i-th shard among the N shards is used as an example for illustration.

[0169] For the i-th shard, based on the steps above, after determining the Pod naming range corresponding to the i-th shard, each Pod under the i-th shard is named within this Pod naming range. In other words, the names of each Pod under the i-th shard are all within the Pod naming range corresponding to the i-th shard. For example, if the Pod naming range corresponding to the i-th shard is 0 to 99, then the names of each Pod under the i-th shard are values ​​from 0 to 99.

[0170] In this embodiment, the specific method by which the Pod controller determines the naming of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard is not limited.

[0171] In some embodiments, based on the steps described above, the Pod controller determines the number of replicas included in the i-th shard and the number of Pods included in each replica, creates the corresponding number of Pods under each replica, and determines the Pod naming range corresponding to the i-th shard. Then, based on the number of replicas included in the i-th shard, the Pod naming range corresponding to the i-th shard can be differentiated. For example, based on the number of replicas, the Pod naming range corresponding to the i-th shard can be evenly divided to obtain a naming sub-range corresponding to each replica in the i-th shard. For each replica, the Pods under that replica are named within that naming sub-range. For example, assuming the Pod naming range corresponding to the i-th shard is 0 to 99, then the i-th shard includes 2 replicas. Thus, the Pod naming range 0 to 99 corresponding to the i-th shard is evenly divided into two naming sub-ranges: the naming sub-range 0 to 49 corresponding to replica 1, and the naming sub-range 50 to 99 corresponding to replica 2. Thus, within the naming sub-range 0 to 49, the names of Pods under Replica 1 are determined. For example, if Replica 1 includes one Pod, then 0 can be used as the Pod's name, or any value from 0 to 99 can be used. Similarly, within the naming sub-range 50 to 99, the names of Pods under Replica 2 are determined. For example, if Replica 2 includes one Pod, then 50 can be used as the Pod's name, or any value from 50 to 99 can be used. The above describes the process of dividing the naming range of Pods corresponding to the i-th shard into equal parts based on the number of replicas in the i-th shard, obtaining the naming sub-ranges corresponding to each replica under the i-th shard, and then naming the Pods under each replica within the naming sub-ranges corresponding to each replica. In some embodiments, based on the number of replicas included in the i-th shard and the number of Pods included in each replica, the naming interval of the Pods corresponding to the i-th shard is divided unequally. For example, more naming sub-intervals are divided for replicas with more Pods and fewer naming sub-intervals are divided for replicas with fewer Pods. Then, within the naming sub-intervals corresponding to each replica, the Pods under each replica are named.

[0172] In some embodiments, S104 above includes the following steps S104-A and S104-B:

[0173] S104-A: For the j-th Pod in the i-th shard, determine the replica index of the k-th replica where the j-th Pod is located in the i-th shard, where k and j are both positive integers;

[0174] S104-B: Determine the name of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

[0175] In the embodiments of this application, the specific method for determining the naming of each Pod in the i-th shard is basically the same. For ease of description, the j-th Pod in the i-th shard will be used as an example for illustration.

[0176] When determining the name of the j-th Pod in the i-th shard, the Pod controller first determines the replica index of the replica containing the j-th Pod within the i-th shard. For example, if the replica containing the j-th Pod is the k-th replica in the i-th shard, and the i-th shard contains m replicas, then the replica index of the k-th replica is determined among the m replicas in the i-th shard.

[0177] In some examples, the replica index under a shard starts from 0. Of course, it can also start from other values ​​such as 1 or 2, and this application embodiment does not limit this.

[0178] For example, such as Figure 6 As shown, assume a stateful service corresponds to two shards, N=2, denoted as s0 and s1 respectively. Each shard has two replicas: s0r0 and s0r1 for s0, and s1r0 and s1r1 for s1. Replicas s0r0, s0r1, and s1r0 each contain one Pod, while replica s1r1 contains two Pods. Assume the i-th shard is s0, and the j-th Pod is a Pod under replica s0r1. Figure 7 As shown, the replica s0r1 containing the j-th Pod is the second replica of the two replicas included in s0, and its replica index is 1 (it can also be other values, for example, if the replica index starts from 1, then the replica index of replica s0r1 is 2). Assuming the i-th shard is s1, and the j-th Pod is the first Pod under replica s1r1, then the replica s1r0 containing the j-th Pod is the first replica of the two replicas included in s1, and its replica index is 0 (it can also be other values, for example, if the replica index starts from 1, then the replica index of replica s1r0 is 1).

[0179] After determining the replica index of the k-th replica where the j-th Pod resides in the i-th shard, the Pod controller executes the steps of S104-B above, determining the name of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

[0180] In this embodiment, there are no restrictions on the specific method of determining the naming of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

[0181] In one possible implementation, the Pod controller divides the Pod naming range corresponding to the i-th shard into multiple naming sub-ranges based on the number of replicas included in the i-th shard. For example, if the Pod naming range corresponding to the i-th shard is 0 to 99, and the i-th shard includes 2 replicas, then the Pod naming range 0 to 99 can be divided into 2 naming sub-ranges: the naming sub-range 0 to 49 corresponding to the first replica under the i-th shard and the naming sub-range 50 to 99 corresponding to the second replica. Then, based on the replica index of the k-th replica where the j-th Pod resides, the name of the j-th Pod is determined. For example, if the j-th Pod is a Pod under the second replica, then the replica index of the second replica is 1, and the naming subrange corresponding to the second replica is 50 to 99. Thus, based on the replica index 1 of the second replica and the naming subrange 50 to 99 corresponding to the second replica, the name of the j-th Pod is determined. For example, if the j-th Pod is the first Pod in the second replica, then the sum of the starting value 50 of the naming subrange corresponding to the second replica and the replica index 1 of the second replica (i.e., 51) is used to determine the name of the j-th Pod. If the j-th Pod is the second Pod in the second replica, then the sum of the starting value 50 of the naming subrange corresponding to the second replica and the replica index 1 of the second replica, plus a preset value (e.g., 1) (e.g., 52) is used to determine the name of the j-th Pod.

[0182] In one possible implementation, S104-B above includes the following steps S104-B1 to S104-B3:

[0183] S104-B1: Multiply the replica index of the k-th replica by the maximum number of Pods that coexist in each replica to obtain the first product;

[0184] S104-B2, The sum of the starting point value of the Pod naming interval corresponding to the i-th shard and the first product is used as the name of the first Pod in the k-th replica;

[0185] S104-B3. Based on the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica, determine the name of the j-th Pod.

[0186] In this implementation, the Pod controller determines the replica index of the k-th replica where the j-th Pod resides in the i-th shard. Then, based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard, it determines the name of the first Pod in the k-th replica. Specifically, it multiplies the replica index of the k-th replica by the maximum number of concurrent Pods in each replica to obtain a first product. The sum of the starting point of the Pod naming range corresponding to the i-th shard and the first product is used to determine the name of the first Pod in the k-th replica.

[0187] In one example, the Pod controller can determine the name of the first Pod in the k-th replica where the j-th Pod in the i-th shard resides using the following formula (1):

[0188] ID=(slots*interval) *a + interval * b (1)

[0189] Where ID is the name of the first Pod in the k-th replica where the j-th Pod in the i-th shard resides, slots is the maximum number of replicas in each shard, interval is the maximum number of Pods that can coexist in each replica, a is the index of the i-th shard in the N shards, and b is the replica index of the k-th replica in the i-th shard.

[0190] For example, suppose each shard has a maximum of 100 replicas (slots), and each replica has a maximum of 2 concurrent Pods (interval). Assume the i-th shard is the second shard out of N shards, with a shard index of 1, and the j-th Pod is the first replica of the second shard, with a replica index of 0. Then, (slots*interval)*1 + interval*0 = (100*2)*1 + 2*0 = 200 can be used to name the first Pod in the first replica of the second shard.

[0191] Next, based on the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica, the name of the j-th Pod is determined.

[0192] For example, if the j-th Pod is the first Pod in the k-th replica, then the name of the first Pod in the k-th replica will be used as the name of the j-th Pod.

[0193] For example, if the j-th Pod is not the first Pod in the k-th replica, then the sum of the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica is used to determine the name of the j-th Pod.

[0194] To further illustrate the technical solutions of the embodiments of this application, the following examples are provided.

[0195] Example 1: The initial configuration information for a stateful service includes the following code:

[0196]

[0197] In this example, the stateful service has 2 shards (N), each shard has a maximum of 100 replicas (slots), each shard has a default of 2 replicas, each replica has a maximum of 2 concurrent Pods (interval), and each replica has a default of 1 Pod. Based on this information, the correspondence between shards, replicas, and Pods for this stateful service can be obtained as follows: Figure 7 As shown, this stateful service corresponds to two shards, namely s0 and s1. Shard s0 includes two replicas, namely replica s0r0 and replica s0r1, and s1 includes two replicas, namely replica s1r0 and s1r1. Each replica includes one Pod by default.

[0198] The Pod controller names each Pod under each replica in shards s0 and s1 based on the method shown in the steps above.

[0199] Specifically, for shard s0, the length of the Pod naming interval corresponding to shard s0 is first determined based on the maximum number of replicas (100) in each shard and the maximum number of Pods (2) that can coexist in each replica. For example, the product of the length of the Pod naming interval (200) and the index of shard s0 in these two shards (e.g., 0) is used to determine the starting value of the Pod naming interval corresponding to shard s0, which is 0. The sum of the starting point (e.g., 0) and the length (200) of the Pod naming interval corresponding to shard s0 minus 1 is used to determine the ending value of the Pod naming interval corresponding to shard s0, which is 199. Then, the two Pods under shard s0 are named within the Pod naming interval from 0 to 199. For example, for the first Pod in the first replica s0r0 of s0, multiply the replica index 0 of the first replica s0r0 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 0. The sum of the starting value 0 of the Pod naming interval corresponding to s0 and the first product 0 is used to determine the name of the first Pod in the first replica s0r0, i.e., P-0. For the first Pod in the second replica s0r1 of s0, multiply the replica index 1 of the second replica s0r1 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 2. The sum of the starting value 0 of the Pod naming interval corresponding to s0 and the first product 2 is used to determine the name of the first Pod in the second replica s0r1, i.e., P-2.

[0200] For shard s1, firstly, based on the maximum number of replicas (100) in each shard and the maximum number of Pods (2) coexisting in each replica, the length of the Pod naming interval corresponding to shard s1 is determined. For example, the product of the length of the Pod naming interval (200) and the index of shard s1 in these two shards (e.g., 1) is used to determine the starting value of the Pod naming interval corresponding to shard s1, which is 200. The sum of the starting point (e.g., 200) and the length (200) of the Pod naming interval corresponding to shard s1 minus 1 is used to determine the ending value of the Pod naming interval corresponding to shard s1, which is 399. Next, the two Pods under shard s1 are named within the Pod naming interval 200 to 399. For example, for the first Pod in the first replica s1r0 of s1, multiply the replica index 0 of the first replica s1r0 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 0. The sum of the starting value 200 of the Pod naming interval corresponding to s1 and the first product 0 is used to determine the name of the first Pod in the first replica s1r0, i.e., P-200. For the first Pod in the second replica s1r1 of s1, multiply the replica index 1 of the second replica s1r1 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 2. The sum of the starting value 200 of the Pod naming interval corresponding to s1 and the first product 2 is used to determine the name of the first Pod in the second replica s1r1, i.e., P-202.

[0201] like Figure 7 As shown in the embodiment of this application, two shards are created, each containing two replicas, and each shard can hold a maximum of 100 replicas. Thus, the Pod controller will generate a total of four Pods: `p-0, p-2, p-200, and p-202`. `p-0 and p-2` belong to the first shard; `p-200 and p-202` belong to the second shard.

[0202] In this embodiment, the Pod controller reserves a portion of IDs based on the `slots` field to add replicas for shard expansion. Figure 7 In the example, the Pod controller creates Pods named `p-200, p-202` for the second shard, while even numbers from `p-4` to `p-198` are reserved for the first shard. This way, if the first shard needs to be expanded in the future, multiple replicas can be added sequentially, such as `p-4`, `p-6`, ..., `p-198`.

[0203] Example 2: The initial configuration information for a stateful service includes the following code:

[0204]

[0205]

[0206] In this example, the stateful service has 2 shards (N), each shard has a maximum of 5 replicas (slots), each shard has a default of 2 replicas, each replica has a maximum of 2 concurrent Pods (interval), and each replica has a default of 1 Pod. Based on this information, the correspondence between shards, replicas, and Pods for this stateful service can be obtained as follows: Figure 8 As shown, this stateful service corresponds to two shards: s0, s1, and s3. Shard s0 includes two replicas, s0r0 and s0r1; s1 includes two replicas, s1r0 and s1r1; and s2 includes two replicas, s2r0 and s2r1. Each replica includes one Pod by default.

[0207] The Pod controller names each Pod under each replica in shards s0, s1, and s3 based on the method shown in the steps above.

[0208] Specifically, for shard s0, firstly, based on the maximum number of replicas (5) and the maximum number of Pods (2) in each replica, the length of the Pod naming interval corresponding to shard s0 is determined. For example, the product of the maximum number of replicas (5) and the maximum number of Pods (2) in each replica (i.e., 10) is used to determine the length of the Pod naming interval corresponding to shard s0. Next, the product of the length of the Pod naming interval (i.e., 10) and the index of shard s0 in these three shards (e.g., 0) is used to determine the starting value of the Pod naming interval corresponding to shard s0, which is 0. The sum of the starting point (e.g., 0) and the length of the Pod naming interval (10) minus 1 is used to determine the ending value of the Pod naming interval corresponding to shard s0, which is 9. Finally, the two Pods under shard s0 are named within the Pod naming intervals 0 to 9. For example, for the first Pod in the first replica s0r0 of s0, multiply the replica index 0 of the first replica s0r0 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 0. The sum of the starting value 0 of the Pod naming interval corresponding to s0 and the first product 0 is used to determine the name of the first Pod in the first replica s0r0, i.e., P-0. For the first Pod in the second replica s0r1 of s0, multiply the replica index 1 of the second replica s0r1 by the maximum number of Pods that can coexist in each replica by 2 to obtain the first product 2. The sum of the starting value 0 of the Pod naming interval corresponding to s0 and the first product 2 is used to determine the name of the first Pod in the second replica s0r1, i.e., P-2.

[0209] For shard s1, firstly, based on the maximum number of replicas (5) and the maximum number of Pods (2) in each replica, determine the length of the Pod naming interval corresponding to shard s1. For example, multiply the maximum number of replicas (5) and the maximum number of Pods (2) in each replica by 10 to determine the length of the Pod naming interval corresponding to shard s1. Next, multiply the length of the Pod naming interval (10) and the index of shard s1 in these three shards (e.g., 1) to determine the starting value of the Pod naming interval corresponding to shard s1, which is 10. Subtract 1 from the sum of the starting point (e.g., 10) and the length (10) of the Pod naming interval corresponding to shard s1 to determine the ending value of the Pod naming interval corresponding to shard s1, which is 19. Then, name the two Pods under shard s1 within the Pod naming intervals 10 to 19 corresponding to shard s1. For example, for the first Pod in the first replica s1r0 of s1, multiply the replica index 0 of the first replica s1r0 by the maximum number of Pods coexisting in each replica (2) to obtain the first product 0. The sum of the starting value 10 of the Pod naming interval corresponding to s1 and the first product 0 is used to determine the name of the first Pod in the first replica s1r0, i.e., P-10. For the first Pod in the second replica s1r1 of s1, multiply the replica index 1 of the second replica s1r1 by the maximum number of Pods coexisting in each replica (2) to obtain the first product 2. The sum of the starting value 10 of the Pod naming interval corresponding to s1 and the first product 2 is used to determine the name of the first Pod in the second replica s1r1, i.e., P-12.

[0210] For shard s2, firstly, based on the maximum number of replicas (5) and the maximum number of Pods (2) in each replica, determine the length of the Pod naming interval corresponding to shard s2. For example, multiply the maximum number of replicas (5) and the maximum number of Pods (2) in each replica by 10 to determine the length of the Pod naming interval corresponding to shard s2. Next, multiply the length of the Pod naming interval (10) and the index of shard s2 in these three shards (e.g., 2) to determine the starting value of the Pod naming interval corresponding to shard s2, which is 20. Subtract 1 from the sum of the starting point (e.g., 20) and the length (10) of the Pod naming interval corresponding to shard s2 to determine the ending value of the Pod naming interval corresponding to shard s2, which is 29. Then, name the two Pods under shard s2 within the Pod naming interval 20 to 29 corresponding to shard s2. For example, for the first Pod in the first replica s2r0 of shard s2, multiply the replica index 0 of the first replica s2r0 by the maximum number of Pods coexisting in each replica (2) to obtain the first product 0. The sum of the starting value 20 of the Pod naming interval corresponding to shard s2 and the first product 0 is used to determine the name of the first Pod in the first replica s2r0, i.e., P-20. For the first Pod in the second replica s2r1 of shard s2, multiply the replica index 1 of the second replica s2r1 by the maximum number of Pods coexisting in each replica (2) to obtain the first product 2. The sum of the starting value 20 of the Pod naming interval corresponding to shard s2 and the first product 2 is used to determine the name of the first Pod in the second replica s2r1, i.e., P-22.

[0211] like Figure 8 As shown in the embodiment of this application, three shards are created, each containing two replicas, and each shard can hold a maximum of ten replicas. Thus, the Pod controller will generate a total of six Pods: `p-0, p-2, p-10, p-12, p-20, p-22`. Specifically, `p-0, p-2` belong to the first shard; `p-10, p-12` belong to the second shard; and `p-20, p-22` belong to the third shard.

[0212] In this embodiment, the Pod controller reserves a portion of IDs based on the `slots` field to add replicas for shard expansion. Figure 8 In the example, the Pod controller creates Pods named `p-10, p-12` for the second shard, with even numbers from `p-4` to `p-8` reserved for the first shard. This way, if the first shard needs to be expanded in the future, three replicas, `p-4`, `p-6`, and `p-8`, can be added sequentially to the first shard.

[0213] The stateful service management method provided in this application embodiment enables flexible management of stateful services. Specifically, it obtains the initial configuration information corresponding to the stateful service, which includes Pod shard information and Pod replica information. Then, based on the Pod shard information and Pod replica information included in the initial configuration information, it determines N shards corresponding to the stateful service and creates a corresponding number of Pods under each replica of each shard. Simultaneously, based on the Pod shard information and Pod replica information, it determines the Pod naming range corresponding to each of the N shards. Thus, for each of the N shards, such as the i-th shard, the names of each Pod under each replica of the i-th shard can be determined within the Pod naming range corresponding to the i-th shard, wherein the Pod names within each shard are not consecutive. In this embodiment, the Pods corresponding to stateful services are grouped according to Pod shard information and Pod replica information, and the Pod naming range corresponding to each shard is determined. Then, the Pods under each replica in the shard are named within the Pod naming range corresponding to the shard. This combines the Pod naming with the shard information and replica information of the Pod. In this way, the Pods under any replica in any shard can be operated independently based on the Pod naming, which greatly enhances the management of stateful services in cloud-native scenarios and can help the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems.

[0214] The foregoing described the specific method for determining unique names for Pods under stateful services in stateful service management. Based on the above naming convention, the stateful service management method of this application embodiment further includes... Figure 9 The scheme shown.

[0215] Figure 9 A schematic diagram of a stateful service management method provided in an embodiment of this application. Figure 9 The stateful service management method shown can be understood as the process of modifying the Pod corresponding to the stateful service created above.

[0216] like Figure 9 As shown, the stateful service management method of this application embodiment includes:

[0217] S201. Obtain the initial configuration information corresponding to the stateful service.

[0218] The initial configuration information includes Pod shard information and Pod replica information.

[0219] The specific implementation process of S201 is described in the relevant description of S101 above, and will not be repeated here.

[0220] S202. Based on the Pod shard information and the Pod replica information, determine the N shards corresponding to the stateful service, and create a corresponding number of Pods under each replica of each shard.

[0221] Wherein, N is a positive integer.

[0222] The specific implementation process of S202 is described in the relevant description of S102 above, and will not be repeated here.

[0223] S203. Based on the Pod shard information and the Pod replica information, determine the Pod naming range corresponding to each of the N shards.

[0224] The specific implementation process of S203 is described in the relevant description of S103 above, and will not be repeated here.

[0225] S204. For the i-th shard among the N shards, within the Pod naming range corresponding to the i-th shard, determine the name of each Pod under each replica in the i-th shard, where i is a positive integer less than or equal to N.

[0226] The specific implementation process of S204 is described in the relevant description of S104 above, and will not be repeated here.

[0227] The above S201 to S204 can be understood as the specific process of creating a corresponding number of Pods for the replicas of the N shards corresponding to the stateful service based on the initial configuration information corresponding to the stateful service, and naming these Pods.

[0228] As can be seen from the above embodiments, the embodiments of this application group the Pods corresponding to stateful services according to the Pod shard information and Pod replica information, and determine the Pod naming range corresponding to each shard. Then, within the Pod naming range corresponding to the shard, the Pods under each replica in the shard are named, so that the Pod naming is combined with the shard information and replica information of the Pod. In this way, the Pods under any replica in any shard can be operated independently based on the Pod naming.

[0229] S205. Obtain configuration change information corresponding to stateful services.

[0230] The configuration change information includes at least one of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information.

[0231] The stateful service management method provided in this application can be applied to database clusters with multi-shard, multi-replica, and master-slave architectures.

[0232] In a database cluster with a multi-shard, multi-replica, master-slave architecture, the following requirements exist for Pod management:

[0233] 1. Processes in a Pod need to know which shard they belong to, which is necessary for detecting the continuity of data;

[0234] 2. Add or delete a shard;

[0235] 3. Allows adding or deleting replicas for any number of shards;

[0236] 4. There are non-peer configurations between Pods (e.g., image, CPU, memory);

[0237] 5. Stable upgrade: To upgrade a shard (e.g., image), a new shard must be added first. The corresponding old shard will only be terminated after the new shard has stabilized.

[0238] To achieve the above functions, it is necessary to independently operate (add / delete / modify) Pods. However, in the embodiments of this application, after naming a Pod using the above naming method, the processes in the Pod can perceive which shard they belong to based on the Pod's name. They can also add or delete a shard as needed, and / or add or delete replicas for any number of shards, and / or perform non-peer configuration between Pods, and / or achieve stable upgrades of replicas.

[0239] Specifically, in this embodiment, the Pod controller can obtain configuration change information corresponding to the stateful service. This embodiment does not limit the specific method by which the Pod controller obtains the configuration change information corresponding to the stateful service.

[0240] In one possible implementation, the user directly inputs the configuration change information corresponding to the stateful service. For example, the user inputs to add a shard or add a replica under one or more shards, or the user inputs to change the shard and replica corresponding to the stateful service to specific values.

[0241] For example, if a user instructs that the number of shards for a stateful service be adjusted to N1 and the number of replicas to M1, then the number of shards N1 and the number of replicas M1 are compared with the current number of shards and replicas to determine whether to add or delete shards, or add or delete replicas, etc. For example, the Pod corresponding to the current stateful service is as follows: Figure 8As shown, there are 3 shards, each shard has 2 replicas, and each replica has one Pod. If the user instructs that the number of shards for the stateful service be adjusted to 2, and each shard has 2 replicas, then this configuration change indicates that the Pods under one shard will be deleted. If the user instructs that the number of shards for the stateful service be adjusted to 3, and each shard has 3 replicas, then this configuration change indicates that one replica and one Pod will be added to each shard.

[0242] In one possible implementation, the Pod controller can automatically generate configuration change information for stateful services based on the current cluster's running state. For example, if a Pod is detected to be faulty or offline, it can be deleted; or if a Pod in a shard experiences high load, a new Pod can be created.

[0243] In this embodiment of the application, the configuration change information corresponding to the stateful service includes at least one of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information.

[0244] In some embodiments, the configuration change information includes any one of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. For example, the configuration change information includes Pod addition indication information, which is used to indicate the addition of a specific one or several Pods.

[0245] In some embodiments, the configuration change information includes any two of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. For example, the configuration change information includes Pod addition indication information and Pod deletion indication information, where the Pod deletion indication information is used to delete one or more specific Pods.

[0246] In some embodiments, the configuration change information includes any three of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. For example, the configuration change information includes Pod addition indication information, Pod deletion indication information, and Pod template update indication information, wherein the Pod template update indication information is used to update the template resource information of one or more specific Pods.

[0247] In some embodiments, the configuration change information includes all of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. The replica rolling upgrade indication information is used to perform rolling upgrades on Pods in a specific replica.

[0248] S206. Based on the configuration change information, modify the Pod information corresponding to the stateful service.

[0249] In this embodiment, after the Pod controller obtains the configuration change information corresponding to the stateful service, it then changes the Pod information currently corresponding to the stateful service based on at least one of the Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information included in the configuration change information. For example, based on the Pod addition indication information, a specific Pod is added to the current cluster, or based on the Pod deletion indication information, a specific Pod is deleted from the current cluster.

[0250] In one example, assuming the Pod controller in this embodiment is an SSS controller, configuration change information for stateful services is presented in the form of SSS objects. Thus... Figure 10 As shown, the SSS controller monitors SSS objects. After an SSS object is modified (created / updated / deleted), the SSS controller observes the modification, obtains configuration change information, and tunes the existing Pods according to the final expected state described in the configuration change information. This tuning includes at least one of the following:

[0251] Add a specified Pod: For creation scenarios, a new Pod will be created that did not exist previously. For reconstruction scenarios (such as changes in specifications), the Pod will be recreated after it has been deleted.

[0252] Update a specified Pod: For all changes that do not require rebuilding the Pod, the Pod needs to be updated, including but not limited to: annotations, labels, tolerances, image information, etc.

[0253] Delete a specified Pod: This part may be a Pod that is actually expected to be deleted, or it may be a Pod that needs to be rebuilt (after rebuilding, some updates will take effect, such as specification configuration).

[0254] As described above, in this embodiment, the configuration change information corresponding to the stateful service includes one or more of the following: Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. The following describes the specific process of changing the Pod information currently corresponding to the stateful service when any one of these three indicators is included in the configuration change information. If multiple indicators are included in the configuration change information, the change to the Pod information currently corresponding to the stateful service can be a combination of these indicators.

[0255] Scenario 1: If the configuration change information includes a new Pod indication, then S206 above includes the following steps:

[0256] S206-A1. Based on the Pod addition indication information, determine the names of the M first Pods to be added, where M is a positive integer;

[0257] S206-A2. For each of the M first Pods, determine the first shard and the first replica of the first Pod based on the naming of the first Pod;

[0258] S206-A3: Add the first Pod in the first copy under the first shard.

[0259] The Pod addition indication information is used to indicate the addition of one or more specific Pods. This application does not limit the specific form of the Pod addition indication information.

[0260] In one example, the Pod addition indication includes the names of the M first Pods to be added. For instance, the Pod addition indication includes an `extras` field, which contains an array of Pod IDs representing the list of Pods to be added.

[0261] For example, the configuration change information for a stateful service is shown below:

[0262]

[0263] As shown above, the configuration change information includes a new Pod indication. This Pod addition indication indicates that a Pod `p-1` will be added based on the default shards (e.g., 3) and replicas (e.g., 2). Therefore, this Pod addition indication includes the name of the first Pod to be added (i.e., Pod `p-1`).

[0264] In one example, the Pod addition indication information is used to indicate the addition of a replica under a specific shard. Based on the naming rules mentioned above, the name of the Pod under the new replica can be determined. For example, as... Figure 8 As shown, suppose a replica is added to the first shard, resulting in three replicas for the first shard. Each replica contains one Pod. The Pod under the first replica is named p-0, the Pod under the second replica is named p-2, and the Pod to be added under the third replica is named p-3. This is how the naming of the Pod to be added is obtained.

[0265] In this embodiment of the application, the Pod controller determines the names of the M first Pods to be added based on the Pod addition indication information, and then determines the shard and replica of each of the M first Pods based on the names of these M first Pods, and then adds the corresponding first Pod under the corresponding shard and replica.

[0266] In the embodiments of this application, for each of the M first Pods, the specific method of determining the shard and replica where the first Pod is located based on the naming of the first Pod is basically the same. For ease of representation, a first Pod will be used as an example for explanation.

[0267] In this embodiment of the application, for ease of description, the shard where the first Pod is located is referred to as the first shard, and the replica where the first Pod is located is referred to as the first replica.

[0268] As described above, in this embodiment, the naming of a Pod is based on the shard and replica information of the Pod. Thus, given the name of the first Pod, the shard and replica of the first Pod can be deduced by reversing the naming process.

[0269] In one example, determining the first shard and first replica of the first Pod based on its name includes the following steps:

[0270] Step 11: Obtain the maximum number of replicas in each shard and the maximum number of Pods that can coexist in each replica;

[0271] Step 12: Based on the maximum number of replicas in each shard and the maximum number of Pods coexisting in each replica, determine the length of the Pod naming range corresponding to each shard;

[0272] Step 13: Based on the name of the first Pod and the length of the Pod name range, determine the first shard where the first Pod is located;

[0273] Step 14: Determine the first replica where the Pod resides based on the name of the first Pod, the length of the Pod name range, and the maximum number of Pods that can coexist in each replica.

[0274] In this implementation, when determining the first shard and first replica of the first Pod, the Pod controller first obtains the maximum number of replicas in each shard and the maximum number of concurrent Pods in each replica. For example, this can be obtained from configuration change information or initial configuration information. Next, based on these parameters, the length of the Pod naming interval corresponding to each shard is determined. For instance, the product of the maximum number of replicas and the maximum number of concurrent Pods in each replica is used to determine the length of the Pod naming interval. This allows the first shard containing the first Pod to be determined based on its name and the length of its naming interval. For example, the quotient of the first Pod's name and the length of its naming interval can be rounded down to obtain the first shard containing the first Pod.

[0275] For example, the first shard where the first Pod is located is determined according to the following formula (2):

[0276] ShardID=PodID / (Slots * Interval) (2)

[0277] Where ShardID is the index of the first shard where the first Pod is located, PodID is the name of the first Pod, Slots is the maximum number of replicas included in each shard, Interval is the maximum number of Pods that can coexist in each replica, Slots*Interval is the length of the Pod naming interval, and " / " is used to round down the quotient.

[0278] Additionally, the first replica where the Pod resides can be determined by the name of the first Pod, the length of the Pod name range, and the maximum number of Pods that can coexist in each replica. For example, the first replica where the first Pod resides can be determined by taking the remainder between the name of the first Pod and the length of the Pod name range; the quotient of this remainder and the maximum number of Pods that can coexist in each replica can then be rounded down to obtain the first replica where the first Pod resides.

[0279] For example, the first replica where the first Pod resides is determined according to the following formula (3):

[0280] ReplicaID=PodID % (Slots * Interval)) / Interval (3)

[0281] Where ReplicaID is the index of the first replica where the first Pod resides, PodID is the name of the first Pod, Slots is the maximum number of replicas included in each shard, Interval is the maximum number of Pods that can coexist in each replica, Slots*Interval is the length of the Pod naming interval, and "%" is the modulo operation.

[0282] Following the method described above, based on the naming of the M first Pods, the first shard and first replica of each of the M first Pods can be determined, and then the first Pod can be added under the corresponding first shard and first replica.

[0283] For example, assuming the first Pod is named p-1, has 5 slots, and an interval of 2, then the Pod currently corresponding to the stateful service is as follows: Figure 8 As shown. Based on the above method, it can be determined that the first shard where the first Pod is located is the first shard, i.e., s0, and the first replica where it is located is the first replica, i.e., s0r0. Thus, as... Figure 11 As shown, a first Pod named p-1 is created under the replica s0r0 of s0. At this time, the list of Pods in the cluster is: `p-0, p-1, p-2, p-10, p-12, p-20, p-22`.

[0284] Scenario 2: If the configuration change information includes a Pod deletion instruction, then S206 above includes the following steps:

[0285] S206-B1. Based on the Pod deletion instruction information, determine the names of the K second Pods to be deleted, where K is a positive integer;

[0286] S206-B2. For each of the K second Pods, determine the second shard and second replica where the second Pod is located based on the naming of the second Pod.

[0287] S206-B3, Delete the second Pod under the second copy in the second shard.

[0288] The Pod deletion instruction information is used to indicate the deletion of one or more specific Pods. This application does not limit the specific form of the Pod deletion instruction information.

[0289] In one example, the Pod deletion instruction includes the names of the K second Pods to be deleted. For instance, the Pod deletion instruction includes a `suppressions` field, which contains an array of Pod IDs representing the list of Pods to be deleted.

[0290] For example, the configuration change information for a stateful service is shown below:

[0291]

[0292] As shown above, the configuration change information includes a Pod deletion instruction. This instruction specifies that Pod `p-0` should be deleted based on the default shards (e.g., 3) and replicas (e.g., 2). Therefore, the Pod deletion instruction includes the name of the second Pod to be deleted (i.e., Pod `p-0`).

[0293] In one example, Pod deletion instructions are used to indicate the deletion of a specific replica within a specific shard. Based on the naming rules described above, the name of the Pod under the replica to be deleted can be determined. For example, ... Figure 8 As shown, assuming the first replica under the second shard is deleted, and the first replica includes a Pod named p-0, then the Pod named p-0 is identified as the second Pod to be deleted.

[0294] In this embodiment, the Pod controller determines the names of the K second Pods to be deleted based on the Pod deletion instruction information, and then determines the shard and replica of each of the K second Pods based on the names of these K second Pods, and then deletes the corresponding second Pod under the corresponding shard and replica.

[0295] In the embodiments of this application, for each of the K second Pods, the specific method of determining the shard and replica where the second Pod is located based on the naming of the second Pod is basically the same. For ease of representation, a second Pod is used as an example for illustration.

[0296] In this embodiment of the application, for ease of description, the shard where the second Pod is located is referred to as the second shard, and the replica where the second Pod is located is referred to as the second replica.

[0297] As described above, in this embodiment, the naming of a Pod is based on the shard and replica information of the Pod. Therefore, when the name of a second Pod is known, the shard and replica of the second Pod can be deduced by reversing the naming process.

[0298] In one example, determining the second shard and second replica where the second Pod resides, based on the second Pod's naming, involves the following steps:

[0299] Step 21: Obtain the maximum number of replicas in each shard and the maximum number of Pods that can coexist in each replica;

[0300] Step 22: Based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica, determine the length of the Pod naming range corresponding to each shard;

[0301] Step 23: Based on the naming of the second Pod and the length of the Pod naming range, determine the second shard where the second Pod is located;

[0302] Step 24: Determine the second replica where the Pod resides based on the naming of the second Pod, the length of the Pod naming range, and the maximum number of Pods that can coexist in each replica.

[0303] The specific processes of steps 21 to 24 can be referred to the specific descriptions of steps 11 to 14 above. The first Pod in steps 11 to 14 can be understood as the second Pod, and will not be repeated here.

[0304] For example, assuming the second Pod is named p-0, has 5 slots, and an interval of 2, then the Pod currently corresponding to the stateful service is as follows: Figure 8 As shown. Based on the above method, it can be determined that the second shard where the second Pod is located is the second shard, i.e., s0, and the second replica where it is located is the second replica, i.e., s0r0. Thus, as... Figure 12 As shown, the second Pod named p-0 under replica s0r0 of s0 is deleted. At this time, the list of Pods in the cluster is: `p-2, p-10, p-12, p-20, p-22`.

[0305] In some embodiments, Pod deletion indication information has higher priority than Pod addition indication information. If the configuration change information includes both Pod addition and Pod deletion indication information, and the first Pod to be added indicated by the Pod addition indication information and the second Pod to be deleted indicated by the Pod deletion indication information are the same Pod, then the step of adding the first Pod is skipped. For example, if extras:[1,3], suppressions:[0,1], that is, the names of the first Pod to be added are p-1 and p-3, and the names of the second Pod to be deleted are p-0 and p-1, then when adding the first Pod, only the Pod named p-3 is added, and the Pod named p-1 is not added.

[0306] Scenario 3: If the configuration change information includes Pod template update indication information, then S206 above includes the following steps:

[0307] S206-C1. Based on the Pod template update indication information, determine the names of the P third Pods whose templates need to be changed and the template configuration adjustment information corresponding to each of the P third Pods, where P is a positive integer;

[0308] S206-C2, For each of the P third Pods, determine the third shard and third replica where the third Pod is located based on the naming of the third Pod;

[0309] S206-C3: Based on the template configuration adjustment information corresponding to the third Pod, adjust the template configuration of the third Pod in the third replica under the third shard. The template configurations of each Pod corresponding to the stateful service are not completely the same.

[0310] In this embodiment, at least two Pods in each Pod corresponding to a stateful service can have different template configurations to maintain asymmetric configurations. The asymmetric configurations include at least one of the following:

[0311] Resources include CPU and memory;

[0312] Volume (PVC) size (container specifications);

[0313] image(the image address of the container);

[0314] Pod labels & annotations;

[0315] PVC labels & annotations.

[0316] Here, label is a key-value pair, and Label defines the metadata of a Kubernetes object. Annotation is "additional" information that the user can define arbitrarily. Annotation is similar to Label, and is also defined in the form of key / value pairs.

[0317] In this embodiment, Pod template update instruction information can be used to indicate adjustments to the template resources of one or more specific Pods. This embodiment does not limit the specific form of the Pod template update instruction information.

[0318] In one example, the Pod template update indication information includes the names of P third Pods for which the template is to be updated. For example, the Pod template update indication information includes an `ordinals` field, which consists of an array of Pod IDs recording which Pod applies the configuration. Optionally, the `mixture` field is included in `partial`, which is used to describe different template configurations. In one example, the same Pod name will only appear once in the `mixture`, and configurations like `[{ordinals:"0"},{ordinals:"0,2}]` are not allowed.

[0319] For example, the configuration change information for a stateful service is shown below:

[0320]

[0321] As shown above, the configuration change information includes Pod template update instructions. These instructions specify that the configurations of Pods p-0 and p-2, and their associated PVCs, should be adjusted as follows: CPU and memory resource requirements should be adjusted to 1GB and 2GB respectively, with maximum values ​​of 2GB and 4GB; the image should be changed to xxx:v1; and the PVC capacity should be adjusted to 20GB. Simultaneously, the instructions also specify that the images of Pods p-4 and p-6 should be changed to xxx:v2. In this example, the naming of the third Pod to be adjusted and the corresponding template configuration adjustment information for each third Pod can be directly obtained.

[0322] In this embodiment, the Pod controller determines the names of the P third Pods whose templates need to be changed based on the Pod template update instruction information. Then, based on the names of these P third Pods, it determines the shard and replica where each of the P third Pods is located, and then adjusts the template of the third Pod under the corresponding shard and replica.

[0323] In the embodiments of this application, for each of the P third Pods, the specific method of determining the shard and replica where the third Pod is located based on the naming of the third Pod is basically the same. For ease of representation, a third Pod is used as an example for illustration.

[0324] In this embodiment of the application, for ease of description, the shard where the third Pod is located is referred to as the third shard, and the replica where the third Pod is located is referred to as the third replica.

[0325] As described above, in this embodiment, Pods are named based on the shard and replica information of the Pod. Therefore, if the name of a third Pod is known, the shard and replica of the third Pod can be deduced by reversing the naming process.

[0326] In one example, determining the third shard and third replica where the third Pod resides, based on its naming, involves the following steps:

[0327] Step 31: Obtain the maximum number of replicas in each shard and the maximum number of Pods that can coexist in each replica;

[0328] Step 32: Based on the maximum number of replicas in each shard and the maximum number of Pods coexisting in each replica, determine the length of the Pod naming range corresponding to each shard;

[0329] Step 33: Based on the naming of the third Pod and the length of the Pod naming range, determine the third shard where the third Pod is located;

[0330] Step 34: Determine the third replica where the Pod resides based on the naming of the third Pod, the length of the Pod naming range, and the maximum number of Pods that can coexist in each replica.

[0331] The specific processes of steps 31 to 34 can be referred to the specific descriptions of steps 11 to 14 above. The first Pod in steps 11 to 14 can be understood as the third Pod, and will not be repeated here.

[0332] Based on the above steps, the third shard and third replica of each of the P third Pods are determined. Then, based on the template configuration adjustment information corresponding to the third Pod, the template configuration of the third Pod in the third replica under the third shard is adjusted. For example, for a third Pod named p-0, based on the above steps, it is determined that the third shard where the third Pod named p-0 is located is the first shard, and the third replica where it is located is the first replica. Therefore, the template configuration of the third Pod p-0 under the first replica of the first shard is adjusted as follows: CPU and memory resource requirements are adjusted to 1G and 2G respectively, and the upper limit is adjusted to 2G and 4G; image is adjusted to xxx:v1; PVC capacity is adjusted to 20G.

[0333] In this embodiment of the application, under the stateful service, non-peer Pod configuration is required. Therefore, in this embodiment of the application, the template configuration of each Pod corresponding to the stateful service is not completely the same, thereby realizing the non-peer configuration of Pods.

[0334] Case 4: If the configuration change information includes a copy rolling upgrade instruction, then the above S206 includes the following steps:

[0335] S206-D1. Based on the replica rolling upgrade instruction information, determine the names of the Q fourth Pods to be upgraded, where Q is a positive integer;

[0336] S206-D2, For each of the Q fourth Pods, determine the fourth shard and the fourth replica where the fourth Pod is located based on the naming of the fourth Pod;

[0337] S206-D3. Create the fourth Pod under the fourth replica in the fourth shard, and delete the old Pod under the fourth replica in the fourth shard after the fourth Pod is successfully created.

[0338] In this embodiment, the Pod IDs in each shard are not consecutive, and the missing names, such as `p-1`, are reserved for replicas to use for rolling upgrades.

[0339] In this embodiment, the copy rolling upgrade instruction information is used to indicate that one or more specific copies should be upgraded. This embodiment does not limit the specific form of the P-copy rolling upgrade instruction information.

[0340] In one example, the replica rolling upgrade instruction includes the names of the Q fourth Pods to be upgraded. For instance, the replica rolling upgrade instruction includes a `primedReplicas` field, which contains an array of PodIDs recording the IDs of the Pods to be upgraded.

[0341] For example, the configuration change information for a stateful service is shown below:

[0342]

[0343] As shown above, the configuration change information includes a replica rolling upgrade instruction, which upgrades the fourth replica where the Pod named p-1 resides.

[0344] In this embodiment, the Pod controller determines the names of the Q fourth Pods to be upgraded based on the replica rolling upgrade instruction information. Then, based on the names of these Q fourth Pods, it determines the shard and replica where each of the Q fourth Pods is located, and then upgrades the fourth Pods under the corresponding shard and replica.

[0345] In the embodiments of this application, for each of the Q fourth Pods, the specific method of determining the shard and replica where the fourth Pod is located based on the naming of the fourth Pod is basically the same. For ease of representation, a fourth Pod is used as an example for illustration.

[0346] In this embodiment of the application, for ease of description, the shard where the fourth Pod is located is referred to as the fourth shard, and the replica where the fourth Pod is located is referred to as the fourth replica.

[0347] As described above, in this embodiment, the naming of a Pod is based on the shard and replica information of the Pod. Therefore, if the name of a fourth Pod is known, the shard and replica of the fourth Pod can be deduced by reversing the naming process.

[0348] In one example, determining the fourth shard and fourth replica where the fourth Pod resides, based on its naming, involves the following steps:

[0349] Step 41: Obtain the maximum number of replicas in each shard and the maximum number of Pods that can coexist in each replica;

[0350] Step 42: Based on the maximum number of replicas in each shard and the maximum number of Pods coexisting in each replica, determine the length of the Pod naming range corresponding to each shard;

[0351] Step 43: Based on the naming of the fourth Pod and the length of the Pod naming range, determine the fourth shard where the fourth Pod is located;

[0352] Step 44: Based on the naming of the fourth Pod, the length of the Pod naming range, and the maximum number of Pods that can coexist in each replica, determine the fourth replica where the Pod resides.

[0353] The specific processes of steps 41 to 44 can be referred to the specific descriptions of steps 11 to 14 above. Just understand the first Pod in steps 11 to 14 as the fourth Pod, and it will not be repeated here.

[0354] Based on the above steps, the fourth shard and fourth replica of each of the Q fourth Pods are determined. For each of the Q fourth Pods, the fourth Pod is created under the fourth replica of the fourth shard where it resides, and after the fourth Pod is created, the old Pod under the fourth replica of the fourth shard is deleted.

[0355] For example, assuming the fourth Pod is named p-1, has 5 slots, and an interval of 2, then the Pod currently corresponding to the stateful service is as follows: Figure 8 As shown. Based on the above method, it can be determined that the fourth pod is located on the fourth shard, i.e., shard s0, and the fourth replica is located on the fourth replica, i.e., s0r0 (hereinafter referred to as R-0). Thus, as follows... Figure 13AAs shown, in replica s0r0 of s0, a fourth Pod named p-1 is created based on the upgraded information. In this embodiment, to improve cluster stability, the Pod named p-0 is not deleted until the fourth Pod is fully created. After the creation of the fourth Pod named p-1 is detected, the old Pod named p-0 in replica R-0 of s0 is deleted, thereby achieving a rolling upgrade of replica R-0 of s0. In some embodiments, p-0 can also be deleted after migrating the data on p-0 to p-1.

[0356] In some embodiments, when upgrading a copy, the upgrade can be performed copy by copy, for example... Figure 13B As shown, when upgrading instance R-0, the upgrade of instance R-1 is paused to increase the upgrade speed of the instance.

[0357] As can be seen from the above, in this embodiment of the application, as long as the Pod name and segment (interval, slot) size are known, the shard and replica to which the Pod belongs can be calculated, without the need to explicitly maintain the mapping table between Pod and shard, thereby improving the management effect of stateful services.

[0358] In some embodiments, the following constraints apply to the descriptions in the configuration change information: Pods in `primedReplicas` must exist, and a Pod cannot be in both `suppressions` and `primedReplicas` simultaneously; the `slots` and `interval` fields are read-only and cannot be modified after creation; `extras`, `suppressions`, and `primedReplicas` can only operate on Pods within the `shards` range, and shards cannot be added or removed via `extras`; if `suppressions` specifies the deletion of all Pods (including the Pod specified by `extras`), it will be converted to `replicas:0` and `extras:[]` will be cleared.

[0359] As can be seen from the above, the stateful service control method provided in this application embodiment can achieve stable and unique IDs and network IDs, grouping Pods by shards / replicas, arbitrarily adding or deleting specified Pods, configuring and stably changing non-peer Pods, thereby enabling effective management of stateful services.

[0360] The stateful service management method provided in this application groupes Pods corresponding to stateful services according to Pod shard information and Pod replica information, determines the Pod naming range corresponding to each shard, and then names the Pods under each replica in that shard within the Pod naming range, so that the Pod name is combined with the shard information and replica information of the Pod. In this way, when the configuration change information corresponding to the stateful service is obtained, and based on the Pod name to be changed indicated by the configuration change information, the shard and replica of the Pod to be changed can be determined, and then the Pods under that shard and replica can be changed (e.g., added, deleted, or updated). Furthermore, based on the Pod name, Pods under any replica in any shard can be operated independently, which greatly enhances the management of stateful services in cloud-native scenarios and can help the smooth and stable containerization of stateful services such as databases, middleware, and consensus systems.

[0361] The above text combined Figures 4 to 13B The present application describes in detail an embodiment of the stateful service management method, which is illustrated below in conjunction with... Figure 14 The following describes in detail the device embodiments of this application.

[0362] Figure 14 This is a schematic block diagram of a stateful service management device provided in an embodiment of this application. The device 10 can be the Pod controller described above, or a part of the Pod controller.

[0363] like Figure 14 As shown, the stateful service management device 10 includes:

[0364] The acquisition unit 11 is used to acquire the initial configuration information corresponding to the stateful service, the initial configuration information including Pod sharding information and Pod replica information;

[0365] The creation unit 12 is used to determine N shards corresponding to the stateful service based on the Pod shard information and the Pod replica information, and to create a corresponding number of Pods under each replica of each shard, where N is a positive integer;

[0366] The interval determination unit 13 is used to determine the Pod naming interval corresponding to each of the N shards based on the Pod shard information and the Pod replica information;

[0367] The naming unit 14 is used to determine the name of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard in the N shards, where i is a positive integer less than or equal to N.

[0368] In some embodiments, the Pod shard information further includes a preset number of shards and a maximum number of replicas in each shard, and the Pod replica information includes the maximum number of Pods coexisting in each replica; the interval determination unit 13 is specifically used to determine the index of the i-th shard in the N shards based on the preset number of shards for the i-th shard; and to determine the Pod naming interval corresponding to the i-th shard based on the index of the i-th shard in the N shards, the maximum number of replicas in each shard, and the maximum number of Pods coexisting in each replica.

[0369] In some embodiments, the interval determination unit 13 is specifically used to determine the length of the Pod naming interval corresponding to each of the N shards based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; and to determine the Pod naming interval corresponding to the i-th shard based on the length of the Pod naming interval and the index of the i-th shard in the N shards.

[0370] In some embodiments, the interval determination unit 13 is specifically used to determine the starting point value of the Pod naming interval corresponding to the i-th shard as the product of the length of the Pod naming interval and the index of the i-th shard in the N shards; and to determine the ending point value of the Pod naming interval corresponding to the i-th shard as the sum of the starting point of the Pod naming interval corresponding to the i-th shard and the length of the Pod naming interval minus 1.

[0371] In some embodiments, the naming unit 14 is specifically used to determine, for the j-th Pod in the i-th shard, the replica index of the k-th replica where the j-th Pod is located in the i-th shard, where k and j are both positive integers; and to determine the name of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

[0372] In some embodiments, the naming unit 14 is specifically used to multiply the replica index of the k-th replica by the maximum number of Pods coexisting in each replica to obtain a first product; to determine the name of the first Pod in the k-th replica by the sum of the starting point value of the Pod naming interval corresponding to the i-th shard and the first product; and to determine the name of the j-th Pod based on the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica.

[0373] In some embodiments, the naming unit 14 is specifically used to determine the name of the first Pod as the name of the j-th Pod if the j-th Pod is the first Pod in the k-th replica; and to determine the name of the j-th Pod as the sum of the index of the j-th Pod in the k-th replica and the name of the first Pod if the j-th Pod is not the first Pod in the k-th replica.

[0374] In some embodiments, after determining the names of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard, the naming unit 14 is further configured to obtain configuration change information corresponding to the stateful service. The configuration change information includes at least one of Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information. Based on the configuration change information, the Pod information currently corresponding to the stateful service is modified.

[0375] In some embodiments, if the configuration change information includes the new Pod indication information, then the naming unit 14 is specifically used to determine the names of the M first Pods to be added based on the Pod addition indication information, where M is a positive integer; for each of the M first Pods, the first shard and the first replica where the first Pod is located are determined based on the name of the first Pod; and the first Pod is added in the first replica under the first shard.

[0376] In some embodiments, if the configuration change information includes the Pod deletion instruction information, then the naming unit 14 is specifically used to determine the names of the K second Pods to be deleted based on the Pod deletion instruction information, where K is a positive integer; for each of the K second Pods, based on the name of the second Pod, determine the second shard and the second replica where the second Pod is located; and delete the second Pod under the second replica in the second shard.

[0377] In some embodiments, if the configuration change information includes the Pod addition indication information and the Pod deletion indication information, and the first Pod to be added indicated by the Pod addition indication information and the second Pod to be deleted indicated by the Pod deletion indication information are the same Pod, then the step of adding the first Pod is skipped.

[0378] In some embodiments, if the configuration change information includes the Pod template update indication information, then the naming unit 14 is specifically used to determine, based on the Pod template update indication information, the names of the P third Pods whose templates are to be changed and the template configuration adjustment information corresponding to each of the P third Pods, where P is a positive integer; for each of the P third Pods, based on the name of the third Pod, determine the third shard and the third replica where the third Pod is located; based on the template configuration adjustment information corresponding to the third Pod, adjust the template configuration of the third Pod in the third replica under the third shard, wherein the template configurations of each Pod corresponding to the stateful service are not completely the same.

[0379] In some embodiments, if the configuration change information includes the replica rolling upgrade instruction information, then the naming unit 14 is specifically used to determine the names of the Q fourth Pods to be upgraded based on the replica rolling upgrade instruction information, where Q is a positive integer; for each of the Q fourth Pods, the fourth shard and the fourth replica where the fourth Pod is located are determined based on the name of the fourth Pod; the fourth Pod is created under the fourth replica in the fourth shard, and after the fourth Pod is successfully created, the old Pod under the fourth replica in the fourth shard is deleted.

[0380] In some embodiments, the naming unit 14 is specifically used to obtain the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; determine the length of the Pod naming interval corresponding to each shard based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica; determine the shard where the Pod is located based on the Pod's name and the length of the Pod naming interval; determine the replica where the Pod is located based on the Pod's name, the length of the Pod naming interval, and the maximum number of Pods coexisting in each replica; wherein, if the Pod is the first Pod, then the shard where the Pod is located is the first shard and the replica where the Pod is located is the first replica; if the Pod is the second Pod, then the shard where the Pod is located is the second shard and the replica where the Pod is located is the second replica; if the Pod is the third Pod, then the shard where the Pod is located is the third shard and the replica where the Pod is located is the third replica; if the Pod is the fourth Pod, then the shard where the Pod is located is the fourth shard and the replica where the Pod is located is the fourth replica.

[0381] In some embodiments, the naming unit 14 is specifically used to round down the quotient of the Pod's name and the length of the Pod's naming range to obtain the shard where the Pod is located.

[0382] In some embodiments, the naming unit 14 is specifically used to perform a modulo operation between the name of the Pod and the length of the Pod naming range to obtain a remainder; and to round down the quotient of the remainder and the maximum number of Pods coexisting in each replica to obtain the replica where the Pod is located.

[0383] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 14 The apparatus shown can perform the embodiments of the above-described method, and the foregoing and other operations and / or functions of each module in the apparatus are respectively for implementing the method embodiments, which will not be described in detail here for the sake of brevity.

[0384] The apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0385] Figure 15 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Figure 15 The electronic devices can be the aforementioned working nodes.

[0386] like Figure 15 As shown, the electronic device 30 may include:

[0387] The system includes a memory 31 and a processor 32. The memory 31 stores a computer program 33 and transfers the program code 33 to the processor 32. In other words, the processor 32 can retrieve and run the computer program 33 from the memory 31 to implement the methods described in the embodiments of this application.

[0388] For example, the processor 32 can be used to execute the steps in the above method according to the instructions in the computer program 33.

[0389] In some embodiments of this application, the processor 32 may include, but is not limited to:

[0390] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0391] In some embodiments of this application, the memory 31 includes, but is not limited to:

[0392] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROP), programmable ROP (PROP), erasable PROP (EPROP), electrically erasable EPROP (EEPROP), or flash memory. Volatile memory can be random access memory (RAP), used as an external cache. By way of example, but not limitation, many forms of RAP are available, such as Static RAP (SRAP), Dynamic RAP (DRAP), Synchronous DRAP (SDRAP), Double Data Rate SDRAP (DDR SDRAP), Enhanced SDRAP (ESDRAP), Synchronous Link DRAP (SLDRAP), and Direct Rambus RAP (DR RAP).

[0393] In some embodiments of this application, the computer program 33 may be divided into one or more modules, which are stored in the memory 31 and executed by the processor 32 to complete the page recording method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 33 in the electronic device.

[0394] like Figure 15 As shown, the electronic device 30 may further include:

[0395] Transceiver 34, which can be connected to processor 32 or memory 31.

[0396] The processor 32 can control the transceiver 34 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 34 may include a transmitter and a receiver. The transceiver 34 may further include antennas, and the number of antennas may be one or more.

[0397] It should be understood that the various components in the electronic device 30 are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0398] According to one aspect of this application, a computer storage medium is provided that stores a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0399] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in the above-described method embodiments.

[0400] In other words, when implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0401] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0402] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0403] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0404] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing stateful services, characterized in that, include: Obtain the initial configuration information corresponding to the stateful service. The initial configuration information includes Pod shard information and Pod replica information. The Pod shard information also includes the preset number of shards and the maximum number of replicas included in each shard. The Pod replica information includes the maximum number of Pods that can coexist in each replica. Based on the Pod sharding information and the Pod replica information, N shards corresponding to the stateful service are determined, and a corresponding number of Pods are created under each replica of each shard, where N is a positive integer; For the i-th fragment among the N fragments, the index of the i-th fragment among the N fragments is determined based on the preset number of fragments, where i is a positive integer less than or equal to N; Based on the index of the i-th shard in the N shards, the maximum number of replicas in each shard, and the maximum number of Pods coexisting in each replica, the Pod naming range corresponding to the i-th shard is determined, and the length of the Pod naming range corresponding to the i-th shard is greater than the number of Pods under the i-th shard; Within the Pod naming range corresponding to the i-th shard, determine the name of each Pod under each replica in the i-th shard. The name of each Pod is determined based on the index of the shard where the Pod is located, the replica index of the replica where the Pod is located, and the index of the Pod in the replica where the Pod is located. The Pod names in the i-th shard are not consecutive.

2. The method according to claim 1, characterized in that, The process of determining the Pod naming range corresponding to the i-th shard based on the index of the i-th shard among the N shards, the maximum number of replicas in each shard, and the maximum number of Pods coexisting in each replica includes: Based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica, the length of the Pod naming interval corresponding to each of the N shards is determined; Based on the length of the Pod naming range and the index of the i-th shard in the N shards, the Pod naming range corresponding to the i-th shard is determined.

3. The method according to claim 2, characterized in that, The process of determining the Pod naming range corresponding to the i-th shard based on the length of the Pod naming range and the index of the i-th shard among the N shards includes: The starting point value of the Pod naming interval is determined by multiplying the length of the Pod naming interval and the index of the i-th shard in the N shards; The sum of the starting point of the Pod naming interval corresponding to the i-th shard and the length of the Pod naming interval minus 1 is determined as the ending point of the Pod naming interval corresponding to the i-th shard.

4. The method according to claim 1, characterized in that, The step of determining the names of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard includes: For the j-th Pod in the i-th shard, determine the replica index of the k-th replica of the j-th Pod in the i-th shard, where k and j are both positive integers; The name of the j-th Pod is determined based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard.

5. The method according to claim 4, characterized in that, The process of determining the name of the j-th Pod based on the replica index of the k-th replica and the Pod naming range corresponding to the i-th shard includes: Multiply the replica index of the k-th replica by the maximum number of Pods coexisting in each replica to obtain the first product; The sum of the starting point of the Pod naming range corresponding to the i-th shard and the first product is determined as the name of the first Pod in the k-th replica; The name of the j-th Pod is determined based on the index of the j-th Pod in the k-th replica and the name of the first Pod in the k-th replica.

6. The method according to claim 5, characterized in that, The process of determining the name of the j-th Pod based on its index in the k-th replica and the name of the first Pod in the k-th replica includes: If the j-th Pod is the first Pod in the k-th replica, then the name of the first Pod is determined as the name of the j-th Pod; If the j-th Pod is not the first Pod in the k-th replica, then the sum of the index of the j-th Pod in the k-th replica and the name of the first Pod is used to determine the name of the j-th Pod.

7. The method according to any one of claims 1-6, characterized in that, After determining the names of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard, the method further includes: Obtain the configuration change information corresponding to the stateful service, wherein the configuration change information includes at least one of Pod addition indication information, Pod deletion indication information, Pod template update indication information, and replica rolling upgrade indication information; Based on the configuration change information, the Pod information corresponding to the stateful service is changed.

8. The method according to claim 7, characterized in that, If the configuration change information includes the Pod addition indication information, then the step of changing the Pod information currently corresponding to the stateful service based on the configuration change information includes: Based on the Pod addition indication information, determine the names of the M first Pods to be added, where M is a positive integer; For each of the M first Pods, the first shard and first replica of the first Pod are determined based on the naming of the first Pod; Add the first Pod to the first replica under the first shard.

9. The method according to claim 7, characterized in that, If the configuration change information includes the Pod deletion instruction information, then the step of changing the Pod information currently corresponding to the stateful service based on the configuration change information includes: Based on the Pod deletion instruction information, determine the names of the K second Pods to be deleted, where K is a positive integer; For each of the K second Pods, the second shard and second replica where the second Pod resides are determined based on the naming of the second Pod; Delete the second Pod under the second replica in the second shard.

10. The method according to claim 7, characterized in that, If the configuration change information includes the Pod addition indication information and the Pod deletion indication information, and the first Pod to be added indicated by the Pod addition indication information and the second Pod to be deleted indicated by the Pod deletion indication information are the same Pod, then the step of adding the first Pod is skipped.

11. The method according to claim 7, characterized in that, If the configuration change information includes the Pod template update indication information, then the step of changing the Pod information currently corresponding to the stateful service based on the configuration change information includes: Based on the Pod template update indication information, determine the names of the P third Pods whose templates need to be changed and the template configuration adjustment information corresponding to each of the P third Pods, where P is a positive integer; For each of the P third Pods, the third shard and third replica of the third Pod are determined based on the naming of the third Pod; Based on the template configuration adjustment information corresponding to the third Pod, the template configuration of the third Pod in the third replica under the third shard is adjusted, wherein the template configurations of each Pod corresponding to the stateful service are not completely the same.

12. The method according to claim 7, characterized in that, If the configuration change information includes the replica rolling upgrade instruction information, then the step of changing the Pod information currently corresponding to the stateful service based on the configuration change information includes: Based on the replica rolling upgrade instruction information, determine the names of the Q fourth Pods to be upgraded, where Q is a positive integer; For each of the Q fourth Pods, the fourth shard and the fourth replica of the fourth Pod are determined based on the naming of the fourth Pod; The fourth Pod is created under the fourth replica in the fourth shard, and after the fourth Pod is successfully created, the old Pod under the fourth replica in the fourth shard is deleted.

13. The method according to any one of claims 8, 9, 11, and 12, characterized in that, Based on the Pod's name, determine the shard and replica where the Pod resides, including: Get the maximum number of replicas in each shard and the maximum number of Pods that can coexist in each replica; Based on the maximum number of replicas included in each shard and the maximum number of Pods coexisting in each replica, the length of the Pod naming range corresponding to each shard is determined; Based on the Pod's name and the length of the Pod's name range, determine the shard where the Pod belongs; The replica where the Pod resides is determined based on the Pod's name, the length of the Pod's name range, and the maximum number of Pods that coexist in each replica. Wherein, if the Pod is the first Pod, then the shard where the Pod is located is the first shard and the replica where the Pod is located is the first replica; if the Pod is the second Pod, then the shard where the Pod is located is the second shard and the replica where the Pod is located is the second replica; if the Pod is the third Pod, then the shard where the Pod is located is the third shard and the replica where the Pod is located is the third replica; if the Pod is the fourth Pod, then the shard where the Pod is located is the fourth shard and the replica where the Pod is located is the fourth replica.

14. The method according to claim 13, characterized in that, The process of determining the shard where the Pod belongs based on the Pod's name and the length of the Pod's name range includes: The quotient of the Pod's name and the length of the Pod's name range is rounded down to obtain the shard where the Pod is located.

15. The method according to claim 13, characterized in that, The process of determining the replica where the Pod resides, based on the Pod's name, the length of the Pod's name range, and the maximum number of Pods coexisting in each replica, includes: The remainder is obtained by taking the modulo operation between the name of the Pod and the length of the Pod name range; The remainder is rounded down by the quotient of the maximum number of Pods coexisting in each replica to obtain the replica where the Pod resides.

16. A stateful service management device, characterized in that, include: The acquisition unit is used to acquire the initial configuration information corresponding to the stateful service. The initial configuration information includes Pod shard information and Pod replica information. The Pod shard information also includes the preset number of shards and the maximum number of replicas included in each shard. The Pod replica information includes the maximum number of Pods that can coexist in each replica. A creation unit is used to determine N shards corresponding to the stateful service based on the Pod shard information and the Pod replica information, and to create a corresponding number of Pods under each replica of each shard, where N is a positive integer; An interval determination unit is used to determine, for the i-th shard among the N shards, the index of the i-th shard among the N shards based on the preset number of shards, where i is a positive integer less than or equal to N; and to determine the Pod naming interval corresponding to the i-th shard based on the index of the i-th shard among the N shards, the maximum number of replicas included in each shard, and the maximum number of Pods coexisting in each replica, where the length of the Pod naming interval corresponding to the i-th shard is greater than the number of Pods under the i-th shard. The naming unit is used to determine the name of each Pod under each replica in the i-th shard within the Pod naming range corresponding to the i-th shard. The name of each Pod is determined based on the index of the shard where the Pod is located, the replica index of the replica where the Pod is located, and the index of the Pod in the replica where the Pod is located. The Pod names in the i-th shard are not consecutive.

17. An electronic device, comprising a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program to implement the method as described in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, Used to store computer programs; The computer program causes the computer to perform the method as described in any one of claims 1 to 15.

Images