Container creation method, apparatus, and electronic device

Abstract

This application discloses a container creation method, apparatus, and electronic device. The method includes: receiving a container creation request, the creation request carrying a state set, the state set including first container resource description information of a first container to be created and second container resource description information of a second container; responding to the creation request, scheduling a first topology domain from multiple topology domains according to the first container resource description information, and creating a first container in the first topology domain according to the first container resource description information, scheduling a second topology domain from multiple topology domains according to the second container resource description information, and creating a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; forming a target cluster according to the first topology domain and the second topology domain, assigning the first container to a first role in the target cluster, and assigning the second container to a second role in the target cluster.

Description

Technical Field

[0001] This application relates to the field of containerization technology, and in particular to a container creation method, apparatus and electronic device. Background Technology

[0002] With the development of cloud-native technologies, containerization has become an important component. Kubernetes is a portable container orchestration and management tool designed for container services. Helm charts are file formats that describe how to deploy applications to Kubernetes. Developers package the resource files required by their applications according to the Helm chart format. Helm is a management tool for application packages in Kubernetes, primarily used to manage charts. A chart is a collection of YAML resource files used to encapsulate a Kubernetes native application. Redis Cluster is a decentralized cluster where each node maintains connections with other nodes to exchange information. To ensure service availability, Redis Cluster adopts a Master-Slave architecture, where each Redis node can have one or more Slaves. When the Master fails, a Slave is elected to become the new Master. In Kubernetes, StatefulSets are used to manage stateful application objects. Each StatefulSet provides at least two container (pod) replicas, one of which becomes the Redis Master, and the other two become Redis Slaves.

[0003] In some scenarios, a combination of Helm-charts and Kubernetes is used to schedule nodes and build a containerized Redis cluster. At least two container (pod) replicas from each StatefulSet are deployed to the optimal Kubernetes node to build the Redis cluster. This means that at least two container (pod) replicas from each StatefulSet are deployed within the same Kubernetes topology. However, with this topology distributed across the same domain, if that topology fails, all container replicas within the same StatefulSet will also fail. This results in both the Master and Slave roles of the Redis cluster going down, leading to low reliability and failing to meet high availability requirements. Summary of the Invention

[0004] This application provides a container creation method, apparatus, and electronic device to improve the reliability of the constructed Redis cluster.

[0005] In a first aspect, this application provides a container creation method, comprising: receiving a container creation request, the creation request carrying a state set, the state set including first container resource description information of a first container to be created and second container resource description information of a second container; responding to the creation request, scheduling a first topology domain from multiple topology domains according to the first container resource description information, and creating a first container in the first topology domain according to the first container resource description information; scheduling a second topology domain from multiple topology domains according to the second container resource description information, and creating a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; and constructing a target cluster according to the first topology domain and the second topology domain, wherein the first container is assigned a first role in the target cluster, and the second container is assigned a second role in the target cluster.

[0006] Secondly, this application provides a container creation apparatus, comprising: a receiving module, configured to receive a container creation request, the creation request carrying a state set, the state set including first container resource description information of a first container to be created and second container resource description information of a second container; a scheduling module, configured to, in response to the creation request, schedule a first topology domain from multiple topology domains according to the first container resource description information, and create a first container in the first topology domain according to the first container resource description information; the scheduling module is further configured to, according to the second container resource description information, schedule a second topology domain from multiple topology domains, and create a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; a building module, configured to build a target cluster according to the first topology domain and the second topology domain; and an allocation module, configured to allocate the first container as a first role in the target cluster and allocate the second container as a second role in the target cluster.

[0007] Thirdly, this application provides an electronic device, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the first aspect.

[0008] Fourthly, this application provides a computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method described in the first aspect.

[0009] As can be seen, when creating containers, the first container and the second container are created in different topology domains. In the target cluster, the first container, which is assigned the first role, and the second container, which is assigned the second role, are also distributed in different topology domains. This prevents the entire topology domain containing containers with different roles in the same stateful set from going down if one topology domain fails. For example, if the topology domain containing the first container goes down, it will not affect the normal operation of the topology domain containing the second container. In this way, the reliability of the target cluster is improved and the high availability of the target cluster is met. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0011] Figure 1 A flowchart illustrating a container creation method provided in an embodiment of this application;

[0012] Figure 2 This is a schematic diagram illustrating an application scenario of the container creation method provided in the embodiments of this application;

[0013] Figure 3 This is a schematic diagram of the structure of a container creation apparatus provided in an embodiment of this application;

[0014] Figure 4 This is a schematic diagram of an electronic device provided as an embodiment of the present specification. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0016] The terms "first," "second," etc., used in this specification and claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0017] As mentioned above, by using Helm-charts and Kubernetes to schedule nodes and build a containerized Redis cluster, at least two container (pod) replicas provided by each StatefulSet are deployed to the best Kubernetes node to build and deploy the Redis cluster. This means that at least two container (pod) replicas provided by each StatefulSet are deployed within the same Kubernetes topology. With this approach, since at least two container (pod) replicas provided by each StatefulSet are distributed within the same topology, if that topology fails, all container replicas within the same StatefulSet will also fail. This means that both the Master and Slave roles in the constructed Redis cluster will fail, resulting in low reliability and failing to meet the high availability requirements of Redis clusters.

[0018] This application provides a container creation method, comprising: receiving a container creation request, the creation request carrying a state set, the state set including first container resource description information of a first container to be created and second container resource description information of a second container; responding to the creation request, scheduling a first topology domain from multiple topology domains according to the first container resource description information, and creating a first container in the first topology domain according to the first container resource description information, scheduling a second topology domain from multiple topology domains according to the second container resource description information, and creating a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; forming a target cluster according to the first topology domain and the second topology domain, assigning the first container to a first role in the target cluster, and assigning the second container to a second role in the target cluster.

[0019] The technical solution provided by the embodiments of this application allows the first container and the second container to be created in different topological domains when creating containers. In the target cluster, the first container, which is assigned the first role, and the second container, which is assigned the second role, are also distributed in different topological domains. This prevents the entire topological domain containing containers with different roles in the same stateful set from going down if one topological domain fails. For example, if the topological domain containing the first container goes down, it will not affect the normal operation of the topological domain containing the second container. In this way, the reliability of the target cluster is improved and the high availability of the target cluster is met.

[0020] It should be understood that the container creation methods provided in the embodiments of this application can all be executed by an electronic device or by software installed in an electronic device, specifically by a terminal device or a server device. The container creation methods can be executed by the same electronic device or by different electronic devices.

[0021] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0022] Please refer to Figure 1 This is a flowchart illustrating a container creation method provided in one embodiment of this specification, applied to an electronic device. The method may include:

[0023] Step S101: Receive the container creation request.

[0024] The creation request carries a state set, which includes the first container resource description information of the first container to be created and the second container resource description information of the second container.

[0025] Specifically, a creation request can be submitted by a user through a Kubernetes client. This request is used to request the creation of a container and carries a stateful set. Each stateful set contains container resource description information for the container to be created. The stateful set can be generated based on the orchestration capabilities provided by Helm-chart, according to the values.yaml parameter configuration file of Helm-chart, resulting in a specified number of stateful sets. Then, a set of container resource description files is generated based on the replicas definition of each stateful set. Each set of container resource description files in a stateful set contains resource description information for at least two containers. This stateful set is responsible for the entire lifecycle management of the container.

[0026] Each statefulSet has a corresponding name, which contains the set's ID. The first and second container resource descriptions in the container resource description files of each statefulSet include, but are not limited to, the container creation order, container names (which include the container ID), container start times, and container types. The priority order of container creation can be determined by the container name, which contains the container ID. The ID can be a numeric number; the smaller the number, the higher the container's creation priority and the earlier it is created. The container name can be a combination of the statefulSet name and the container ID. For example, the names of stateful sets can be "redis-cluster-shard-0" and "redis-cluster-shard-1", where "0" and "1" are the numbers of the stateful sets. The container name of the first container in the stateful set "redis-cluster-shard-0" can be "redis-cluster-shard-0-0", and the container name of the second container in the stateful set "redis-cluster-shard-0" can be "redis-cluster-shard-0-1". Here, "redis-cluster-shard-0" in the container name is the name of the stateful set to which the container belongs, and the last "0" and "1" in the container name represent the container number in that stateful set.

[0027] Step S103: In response to the creation request, the first topology domain is scheduled from multiple topology domains according to the first container resource description information, and the first container is created in the first topology domain according to the first container resource description information.

[0028] Specifically, a topology domain can be within Kubernetes (k8s). There are multiple topology domains in k8s, which can be categorized as data centers, boards, racks, etc. Each topology domain has a corresponding topology domain label. This label can be the name of the topology domain, which can include the name and ID of the entity corresponding to the topology domain. This ID can be a numeric number, and different topology domains have different numeric IDs. For example, when the topology domain is at the board level, the topology domain name can be set to "kubernetes.io / switch-card-0", where "kubernetes.io / switch-card" represents the name of the physical board corresponding to the topology domain, and "0" represents the numeric ID of the topology domain. When the topology domain is at the rack level, the topology domain name can be set to "kubernetes.io / rack-0", where "kubernetes.io / rack" represents the name of the physical rack corresponding to the topology domain, and "0" represents the numeric ID of the topology domain.

[0029] Upon responding to the creation request, the first topology domain is scheduled from multiple topology domains according to the first container resource description information in the same stateful set. Scheduling the first topology domain can be done randomly or by calculating an optimal topology domain. Scheduling the first topology domain refers to selecting a topology domain from multiple Kubernetes topology domains and scheduling the resources within that topology domain. Then, a first container is created within the selected topology domain according to the first container resource description information. Specifically, the first container is created using the resources in the first topology domain based on the container's creation order, name (including the container's ID), start time, and type. The resources in the topology domain include, but are not limited to, storage resources, network resources, and computing resources.

[0030] In one possible implementation, scheduling a first topology domain from multiple topology domains based on first container resource description information includes:

[0031] Obtain the number of topology domains and the ID of the stateful set carried in the first container resource description information, wherein each topology domain has a corresponding topology domain label; schedule the first topology domain from multiple topology domains according to the ID of the stateful set, the number of topology domains, and the topology domain label.

[0032] Specifically, as described above, the container name in the first container resource description information carries the name of the stateful set, and the name of the stateful set carries its numerical ID. Each topology domain corresponds to a topology domain label, which includes both the topology domain name and its numerical ID. The first topology domain is determined based on the numerical ID of the stateful set and the number of topology domains. Specifically, a value is obtained by calculating the numerical ID of the stateful set and the number of topology domains. Based on this value, a topology domain label matching the numerical ID is searched from multiple topology domain label numbers, and the first topology domain corresponding to that label is scheduled. In this way, each stateful set has a different ID, and the corresponding first topology domain is also different, thus avoiding the creation of first containers from multiple stateful sets in the same topology domain, further improving the reliability of the target cluster.

[0033] The process of scheduling a first topological domain from multiple topological domains based on the state set's index and the number of topological domains includes: performing a modulo operation on the state set's index and the number of topological domains to obtain the modulus value corresponding to the state set; determining the first topological domain label corresponding to the modulus value from multiple topological domain labels; and scheduling the first topological domain from multiple topological domains based on the first topological domain label. When scheduling the first topological domain, an affinity scheduling strategy can be used. This strategy prioritizes scheduling the topological domain corresponding to the first topological domain label from multiple topological domains as the first topological domain. If the resources of the topological domain corresponding to the first topological domain label do not meet the resource requirements for creating the first container as described in the first container resource description information, then the topological domain whose resources meet the resource requirements for creating the first container is scheduled from the remaining topological domains (excluding the first topological domain label) as the first topological domain.

[0034] Specifically, as mentioned above, each stateful set has a corresponding numerical ID. This numerical ID is moduloed by the number of topological domains to obtain a value. Each topological domain label contains the name and numerical ID of the topological domain. The numerical ID matching this value is searched from the numerical IDs in each topological domain label. The first topological domain is then searched for and scheduled according to the numerical ID and the corresponding topological domain name. When scheduling the first topological domain, the affinity scheduling strategy in Kubernetes can be used to schedule the first topological domain. The affinity scheduling strategy refers to prioritizing the scheduling of topological domains related to the stateful set, that is, prioritizing the scheduling of topological domains corresponding to the first topological domain label. For example, if a stateful set numbered 0 is moduloed with a topology domain of 3, the result is 0. The topology domain corresponding to this value is labeled kubernetes.io / switch-card-0. During scheduling, the topology domain labeled kubernetes.io / switch-card-0 will be prioritized for affinity scheduling. However, if the remaining resources in the topology domain corresponding to the first topology domain label kubernetes.io / switch-card-0 do not meet the resource requirements for creating the first container as stated in the first container resource description information, other topology domains may also be selected. The topology domain that satisfies the resource requirements of the remaining topology domains other than kubernetes.io / switch-card-0 is designated as the first topology domain. For example, if the remaining resources of kubernetes.io / switch-card-1 meet the resource requirements for creating the first container as described in the resource description information, resources in the topology domain corresponding to kubernetes.io / switch-card-1 can be called, and the first container can be created in that topology domain. In this way, the first topology domain is determined differently depending on the number of each stateful set, thus avoiding the creation of first containers for multiple stateful sets in the same topology domain. This further improves the reliability of the target cluster. When scheduling the first topology domain, affinity scheduling is used, prioritizing topology domains related to the stateful set, which facilitates container operation and further improves the reliability of container creation.

[0035] Step S105: Schedule a second topology domain from multiple topology domains according to the second container resource description information, and create a second container in the second topology domain according to the second container resource description information.

[0036] The first topological domain and the second topological domain are different.

[0037] Specifically, as mentioned above, the second container resource description information includes, but is not limited to, the container creation order, the container name (including the container number), the container start time, and the container type. When scheduling the second topology domain, it is scheduled from multiple topology domains according to the second container resource description information in the same stateful set. Scheduling the second topology domain means selecting a topology domain from multiple Kubernetes topology domains whose remaining resources meet the requirements for creating the second container, and creating the second container in the selected topology domain according to the second container resource description information. It is worth noting that for different containers in the same stateful set, a hard anti-affinity scheduling strategy is adopted to perform hard anti-affinity scheduling on the second topology domain based on the resource description information of the second container. The hard anti-affinity scheduling strategy can be provided by Kubernetes. The hard anti-affinity scheduling strategy indicates that the second topology domain is scheduled from the remaining topology domains other than the first topology domain. If there is no topology domain among the remaining topology domains other than the first topology domain that meets the resource requirements in the resource description information of the second container, the second container to be created corresponding to the resource description information of the second container is placed in a waiting state. This is to ensure that different containers in the same stateful set can be scheduled to different topology domains.For example, during container creation, multiple containers controlled by the same stateful set will each have a unique name. This name includes the name of the stateful set to which the container belongs and the container's number within that stateful set. For instance, if the first and second containers in the stateful set `redis-cluster-shard-0` are named `redis-cluster-shard-0-0` and `redis-cluster-shard-0-1` respectively, then according to Kubernetes' hard anti-affinity scheduling policy, these two containers with the aforementioned names will be scheduled using hard anti-affinity scheduling. Specifically, after scheduling the first topology domain with the first topology domain label for the first container `redis-cluster-shard-0-0` as described above, then scheduling the second container `redis-cluster-shard-0-1` within the same stateful set... When scheduling topology domains, ard-0-1 schedules from all topology domains except the first one. If there are no remaining resources in the remaining topology domains that meet the requirements for creating the second container redis-cluster-shard-0-1, the topology domain corresponding to the first topology domain label will not be scheduled for the second container redis-cluster-shard-0-1. Instead, the second container redis-cluster-shard-0-1, whose resource description information is correct, will be placed in a waiting state. If, during the waiting process, a topology domain releases resources that meet the requirements for creating the second container redis-cluster-shard-0-1, then the topology domain will be scheduled for the second container redis-cluster-shard-0-1. In this way, this method ensures that the first and second containers in the same stateful set can be created in different topology domains. If the topology domain corresponding to one container in the same stateful set goes down, it will not affect the normal operation of the topology domain corresponding to another container in the same stateful set, resulting in high reliability of the target cluster.

[0038] In one possible implementation, scheduling a second topology domain from multiple topology domains according to the second container resource description information includes: scheduling the second topology domain from the remaining topology domains (excluding the first topology domain) from the multiple topology domains according to the second container resource description information, wherein the resources of the second topology domain satisfy the resource requirements in the second container resource description information.

[0039] Specifically, when scheduling the second topology domain, resources are scheduled from the remaining topology domains other than the first topology domain to meet the resource requirements for creating the second container. The resources required to create the second container can be determined based on the container type, container opening time, etc. in the resource description information of the second container.

[0040] Step S107: Build the target cluster based on the first topology domain and the second topology domain.

[0041] Specifically, after determining the first topology domain and the second topology domain, a target cluster is constructed according to the first topology domain and the second topology domain. The target cluster can be a Redis cluster.

[0042] Step S109: Assign the first container to the first role in the target cluster, and assign the second container to the second role in the target cluster.

[0043] Specifically, for a Redis cluster, the first container can be assigned the first role in the target cluster, and the second container can be assigned the second role in the target cluster. The first role can be the master role, and the second role can be the slave role.

[0044] Through the technical solutions disclosed in the embodiments of this application, the first container and the second container are created in different topological domains. In the target cluster, the first container, which is assigned the first role, and the second container, which is assigned the second role, are also distributed in different topological domains. This prevents the entire topological domain containing containers with different roles in the same stateful set from going down after a failure in one topological domain. For example, if the topological domain containing the first container goes down, it will not affect the normal operation of the topological domain containing the second container. In this way, the reliability of the target cluster is improved and the high availability of the target cluster is met.

[0045] In one possible implementation, after determining the first topological domain label corresponding to the modulus from multiple topological domain labels, the method further includes: in the case that multiple stateful sets correspond to the same first topological domain label, assigning the first topological domain label to the multiple stateful sets according to the priority of the stateful sets.

[0046] As described above, for multiple stateful sets, the determined topology domains may correspond to the same topology domain. If the first container with the same role is created in the same topology domain, it will also fail to run after the topology domain goes down, preventing cluster election. Therefore, when multiple stateful sets correspond to multiple topology domains, the first topology domain corresponding to the first topology domain label is scheduled according to the priority of each stateful set (this priority can be determined by the numerical number in the stateful set name, with smaller numbers indicating higher priority). Alternatively, the first topology domain corresponding to the first topology domain label is scheduled according to the top N stateful sets in descending order of priority, where N is less than the number of stateful sets corresponding to the same first topology domain label. The remaining stateful sets without assigned first topology domain labels are scheduled for the other topology domains. In this way, the first containers with the same role in different stateful sets can be created in different topology domains, reducing the probability of first containers with the same role from multiple stateful sets appearing in the same topology domain. Cluster election can still be performed when a topology domain fails.

[0047] In one possible implementation, assigning a first topological domain label to multiple stateful sets based on their priority includes: assigning the first topological domain label to the first stateful set with the highest priority, according to the priority of each stateful set.

[0048] After assigning a first topology domain label to multiple stateful sets according to the priority of the stateful sets, the method further includes: assigning a second topology domain label to a second stateful set among the multiple stateful sets, wherein the second topology domain label is one of the multiple topology domain labels.

[0049] The third topology is scheduled from multiple topologies for the second stateful set based on the second topology label.

[0050] Specifically, for multiple stateful sets, the determined topology domains may correspond to the same topology domain. If the first container with the same role is created in the same topology domain, the first container on that topology domain will also be unable to run after the topology domain goes down, making cluster election impossible. Therefore, when multiple stateful sets correspond to multiple topology domains, the first topology domain corresponding to the first topology domain label is scheduled firstly for the stateful set with the highest priority (this priority can be determined by the numerical number in the stateful set name, the smaller the number, the higher the priority). Then, from the remaining topology domains, the third topology domain corresponding to the second topology domain label corresponding to the second stateful set with the same first topology domain label is scheduled. Specifically, a soft anti-affinity scheduling strategy can be used to schedule a third topology from multiple topology domains for a second stateful set based on the second topology domain label. This soft anti-affinity scheduling strategy can be provided by Kubernetes. The strategy instructs that the topology domain corresponding to the second topology domain label be prioritized from multiple topology domains as the third topology domain. If the resources of the topology domain corresponding to the second topology domain label do not meet the resource requirements in the first container resource description information, a topology domain whose resources meet the resource requirements is scheduled from the remaining topology domains (excluding the second topology domain label) as the third topology domain. In other words, the topology domain corresponding to the second topology domain label is first scheduled from multiple topology domains as the third topology domain. If the resources of the topology domain corresponding to the second topology domain label do not meet the resource requirements in the first container resource description information, a topology domain whose resources meet the resource requirements is scheduled from the remaining topology domains (excluding the second topology domain label) as the third topology domain.

[0051] Furthermore, if no topology domain, other than the first and second topology domain labels, has resources sufficient to meet the resource requirements for creating a first container in the second stateful set, the first topology domain can be scheduled for the first container in the second stateful set. That is, if resources exist in the topology domains other than the first topology domain to meet the resource requirements of the first container to be created in the second stateful set, the first container in the second stateful set can be scheduled to a third topology domain different from the first topology domain. If no resources exist in the topology domains other than the first topology domain to meet the resource requirements of the first container to be created in the second stateful set, the first topology domain can also be scheduled for the first container in the second stateful set; that is, the first topology domain becomes the third topology domain. In this way, first containers with the same role in different stateful sets can be created in different topology domains, reducing the probability of first containers with the same role from multiple stateful sets appearing in the same topology domain. Even if a topology domain fails, cluster election can still be performed.

[0052] The technical solutions provided in the embodiments of this application will be described in detail below with reference to practical application scenarios, such as... Figure 2As shown, the topology domain labels provided by Kubernetes are switch-card-0, switch-card-1, and switch-card-2, respectively. The names corresponding to the stateful sets are shard-0, shard-2, and shard-3, respectively. The container names in the stateful set shard-0 are shard-0-0 and shard-0-1, respectively; the container names in the stateful set shard-1 are shard-1-0 and shard-1-1, respectively; and the container names in the stateful set shard-2 are shard-2-0 and shard-2-1, respectively. Here, shard-0 corresponds to the stateful set of redis-cluster-shard-0 in the above embodiment, shard-0-0 corresponds to redis-cluster-shard-0-0 in the above embodiment, and shard-0-1 corresponds to redis-cluster-shard-0-1 in the above embodiment.

[0053] When scheduling using the above-described method provided in the embodiments of this application, the hard anti-affinity scheduling strategy of Kubernetes is used to schedule different containers shard-0-0 and shard-0-1 in the same stateful set shard-0 into the topology domains of switch-card-0 and switch-card-1, respectively. Different containers shard-1-0 and shard-1-1 in the same stateful set shard-1 are scheduled into the topology domains of switch-card-1 and switch-card-2, respectively. Different containers shard-2-0 and shard-2-1 in the same stateful set shard-2 are scheduled into the topology domains of switch-card-2 and switch-card-0, respectively. The topology domains of switch-card-0, switch-card-1, and switch-card-2 form a Redis cluster. One container in the same stateful set assumes the role of master in the Redis cluster, and the other container assumes the role of slave. In this way, containers with different roles in the same stateful set are created in different topology domains. This prevents all topology domains containing containers with different roles in the same stateful set from going down if one topology domain fails. This improves the reliability of the Redis cluster and meets the high availability requirements of the Redis cluster.

[0054] Furthermore, the soft anti-affinity scheduling strategy based on Kubernetes schedules containers with the same role from different stateful sets to different topology domains, preventing the probability of multiple containers with the same role appearing in the same topology domain. This ensures that cluster election can be performed when a topology domain fails, further improving the reliability of the target cluster. For example, Figure 2 In this context, containers with different roles in the state sets shard-0, shard-1, and shard-2 are scheduled to different topology domains. Specifically, switch-card-0 schedules the master role of shard-0-0 and the slave role of shard-2-1, switch-card-1 schedules the master role of shard-1-0 and the slave role of shard-0-1, and switch-card-2 schedules the master role of shard-2-0 and the slave role of shard-1-1.

[0055] In addition, with the above Figure 1 Corresponding to the container creation method shown, this application also provides a container creation apparatus. Figure 3 This is a schematic diagram of the structure of a container creation apparatus 300 provided in an embodiment of this application, comprising: a receiving module 301, configured to receive a container creation request, the creation request carrying a state set, the state set including first container resource description information of a first container to be created and second container resource description information of a second container; a scheduling module 302, configured to, in response to the creation request, schedule a first topology domain from multiple topology domains according to the first container resource description information, and create a first container in the first topology domain according to the first container resource description information; the scheduling module 302 is further configured to, according to the second container resource description information, schedule a second topology domain from multiple topology domains, and create a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; a building module 303, configured to build a target cluster according to the first topology domain and the second topology domain; and an allocation module 304, configured to allocate the first container as a first role in the target cluster and allocate the second container as a second role in the target cluster.

[0056] By utilizing the technical solutions disclosed in the embodiments of this application, when creating containers, the first container and the second container are created in different topological domains. In the target cluster, the first container, which is assigned the first role, and the second container, which is assigned the second role, are also distributed in different topological domains. This prevents all topological domains containing containers with different roles in the same stateful set from going down after a failure in one topological domain. For example, if the topological domain containing the first container goes down, it will not affect the normal operation of the topological domain containing the second container. In this way, the reliability of the target cluster is improved, and the high availability of the target cluster is met.

[0057] In one possible implementation, the scheduling module 302 is further configured to obtain the number of topology domains and the number of the stateful set carried in the first container resource description information, and the topology domains are labeled accordingly; and to schedule the first topology domain from multiple topology domains according to the number of the stateful set, the number of topology domains and the topology domain labels.

[0058] In one possible implementation, the scheduling module 302 is further configured to perform a modulo operation on the number of the stateful set and the number of topological domains to obtain a modulo value corresponding to the stateful set; determine a first topological domain label corresponding to the modulo value from multiple topological domain labels; and schedule the first topological domain from multiple topological domains according to the first topological domain label.

[0059] In one possible implementation, the scheduling module 302 is further configured to perform affinity scheduling on the first topology domain according to the first topology domain label using an affinity scheduling strategy. The affinity scheduling strategy indicates that the topology domain corresponding to the first topology domain label is preferentially scheduled from multiple topology domains as the first topology domain. If the resources of the topology domain corresponding to the first topology domain label do not meet the resource requirements in the first container resource description information, the topology domain whose resources meet the resource requirements is scheduled from the remaining topology domains other than the first topology domain label as the first topology domain.

[0060] In one possible implementation, it also includes: an allocation module, used to allocate the first topology domain label to multiple stateful sets according to the priority of the stateful sets when multiple stateful sets correspond to the same first topology domain label.

[0061] In one possible implementation, the allocation module is also used to allocate the first topological domain label to the first stateful set with the highest priority, according to the priority of each stateful set.

[0062] In one possible implementation, the allocation module is further configured to allocate a second topology domain label to a second state set among a plurality of state sets, wherein the second topology domain label is one of a plurality of topology domain labels.

[0063] In one possible implementation, the scheduling module 302 is further configured to schedule a third topology from multiple topology domains for a second stateful set based on the second topology domain label.

[0064] In one possible implementation, the scheduling module 302 is further configured to use a soft anti-affinity scheduling strategy to schedule a third topology domain from multiple topology domains for a second stateful set based on the second topology domain label. The soft anti-affinity scheduling strategy indicates that the topology domain corresponding to the second topology domain label should be scheduled first from multiple topology domains as the third topology domain. If the resources of the topology domain corresponding to the second topology domain label do not meet the resource requirements in the first container resource description information, the topology domain whose resources meet the resource requirements should be scheduled from the remaining topology domains other than the second topology domain label as the third topology domain.

[0065] In one possible implementation, the scheduling module 302 is further configured to schedule a second topology domain from the remaining topology domains (excluding the first topology domain) among multiple topology domains according to the second container resource description information, wherein the resources of the second topology domain satisfy the resource requirements in the second container resource description information.

[0066] In one possible implementation, the scheduling module 302 is further configured to perform hard anti-affinity scheduling on the second topology domain according to the resource description information of the second container using a hard anti-affinity scheduling strategy. The hard anti-affinity scheduling strategy indicates that the second topology domain is scheduled from the remaining topology domains other than the first topology domain. If there is no topology domain among the remaining topology domains other than the first topology domain that meets the resource requirements in the resource description information of the second container, the second container to be created corresponding to the resource description information of the second container is placed in a waiting state.

[0067] Obviously, the container creation apparatus disclosed in this application can serve as the execution subject of the container creation method shown in the above embodiments, and thus can realize the functions implemented by the container creation method in the above embodiments. Since the principle is the same, it will not be described again here.

[0068] Figure 4 This is a schematic diagram of the structure of an electronic device according to one embodiment of this specification. Please refer to it. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0069] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0070] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0071] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a container creation device at the logical level. The processor executes the program stored in memory and is specifically used to perform the container creation method mentioned in any of the above method embodiments.

[0072] The above is as described in this instruction manual. Figure 1The container creation apparatus disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0073] It should be understood that the electronic device in the embodiments of this application can realize the container creation device in Figure 1 The embodiments shown have the same function. Since the principle is the same, the embodiments of this application will not be described again here.

[0074] Of course, in addition to software implementation, the electronic device described in this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0075] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform the container creation method of any of the above embodiments.

[0076] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0077] In summary, the above are merely preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

[0078] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0079] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0080] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0081] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A method for creating a container, characterized in that, include: Receive a container creation request, the creation request carrying a state set, the state set including first container resource description information of the first container to be created and second container resource description information of the second container; In response to the creation request, a first topology domain is scheduled from multiple topology domains according to the first container resource description information, and a first container is created in the first topology domain according to the first container resource description information; The second topology domain is scheduled from multiple topology domains according to the second container resource description information, and a second container is created in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; The target cluster is constructed based on the first and second topological domains; The first container is assigned to the first role in the target cluster, and the second container is assigned to the second role in the target cluster.

2. The container creation method according to claim 1, characterized in that, The step of scheduling the first topology domain from multiple topology domains based on the first container resource description information includes: Obtain the number of the topology domains and the number of the stateful set carried in the first container resource description information, wherein each topology domain has a corresponding topology domain label; The first topology domain is scheduled from multiple topology domains based on the number of the stateful set, the number of topology domains, and the topology domain label.

3. The container creation method according to claim 2, characterized in that, The step of scheduling the first topology domain from multiple topology domains based on the number of the stateful set and the number of topology domains includes: The modulo operation is performed between the number of the stateful set and the number of the topological domains to obtain the modulo value corresponding to the stateful set; Determine the first topological domain label corresponding to the modulus value from a plurality of topological domain labels; The first topology domain is scheduled from multiple topology domains based on the first topology domain label.

4. The container creation method according to claim 3, characterized in that, The step of scheduling the first topology domain from multiple topology domains according to the first topology domain label includes: An affinity scheduling strategy is used to schedule the first topology domain based on the first topology domain label. The affinity scheduling strategy indicates that the topology domain corresponding to the first topology domain label is scheduled first from multiple topology domains. If the resources of the topology domain corresponding to the first topology domain label do not meet the resource requirements in the first container resource description information, the topology domain whose resources meet the resource requirements is scheduled from the remaining topology domains other than the first topology domain label as the first topology domain.

5. The container creation method according to claim 3, characterized in that, After determining the first topological domain label corresponding to the modulus value from a plurality of topological domain labels, the method further includes: When multiple stateful sets correspond to the same first topology domain label, the first topology domain label is assigned to the multiple stateful sets according to the priority of the stateful sets.

6. The container creation method according to claim 5, characterized in that, The step of assigning the first topological domain label to multiple stateful sets according to the priority of the stateful sets includes: According to the priority of each stateful set, the first topological domain label is assigned to the first stateful set with the highest priority. After assigning the first topological domain label to multiple stateful sets according to the priority of the stateful sets, the method further includes: Assign a second topological domain label to the second stateful set among the plurality of stateful sets, wherein the second topological domain label is one of the plurality of topological domain labels; The third topology domain is scheduled from the plurality of topology domains for the second stateful set based on the second topology domain label.

7. The container creation method according to claim 6, characterized in that, The step of scheduling a third topology domain from the plurality of topology domains for the second stateful set based on the second topology domain label includes: A soft anti-affinity scheduling strategy is used to schedule a third topology domain from the plurality of topology domains for the second stateful set based on the second topology domain label. The soft anti-affinity scheduling strategy indicates that the topology domain corresponding to the second topology domain label is preferentially scheduled from the plurality of topology domains as the third topology domain. If the resources of the topology domain corresponding to the second topology domain label do not meet the resource requirements in the first container resource description information, the topology domain whose resources meet the resource requirements is scheduled from the remaining topology domains other than the second topology domain label as the third topology domain.

8. The container creation method according to claim 1, characterized in that, The step of scheduling the second topology domain from multiple topology domains based on the second container resource description information includes: The second topology domain is scheduled from the remaining topology domains (excluding the first topology domain) among the plurality of topology domains according to the second container resource description information, and the resources of the second topology domain satisfy the resource requirements in the second container resource description information.

9. The container creation method according to claim 8, characterized in that, The step of scheduling the second topology domain from the remaining topology domains (excluding the first topology domain) according to the second container resource description information includes: A hard anti-affinity scheduling strategy is used to perform hard anti-affinity scheduling on the second topology domain based on the second container resource description information. The hard anti-affinity scheduling strategy indicates that the second topology domain is scheduled from the remaining topology domains other than the first topology domain. If there is no topology domain among the remaining topology domains other than the first topology domain that meets the resource requirements in the second container resource description information, the second container to be created corresponding to the second container resource description information is placed in a waiting state.

10. A container creation apparatus, characterized in that, include: A receiving module is used to receive a container creation request, wherein the creation request carries a state set, and the state set includes first container resource description information of the first container to be created and second container resource description information of the second container. The scheduling module is used to respond to the creation request, schedule the first topology domain from multiple topology domains according to the first container resource description information, and create the first container in the first topology domain according to the first container resource description information; The scheduling module is further configured to schedule a second topology domain from multiple topology domains according to the second container resource description information, and create a second container in the second topology domain according to the second container resource description information, wherein the first topology domain and the second topology domain are different; A component module is used to build a target cluster based on the first topology domain and the second topology domain. The allocation module is used to allocate the first container as a first role in the target cluster and the second container as a second role in the target cluster.

11. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the container creation method as described in any one of claims 1 to 9.

Images