CN117193934A

CN117193934A - Method and device for configuring scheduling mode of container group

Info

Publication number: CN117193934A
Application number: CN202311037271.XA
Authority: CN
Inventors: 曹兴明; 张金柱
Original assignee: Jingdong Technology Information Technology Co Ltd
Current assignee: Jingdong Technology Information Technology Co Ltd
Priority date: 2023-08-17
Filing date: 2023-08-17
Publication date: 2023-12-08

Abstract

The embodiment of the disclosure discloses a method and a device for configuring a container group scheduling mode. One embodiment of the method comprises the following steps: monitoring a resource creation action in the container cluster, wherein the resource creation action is used for indicating to create a target resource, and the target resource is used for running a containerized application; in response to monitoring the resource creation action, injecting a container group scheduling configuration into the target resource, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; and performing persistent storage on the target resource. This embodiment enables a highly available deployment of containerized applications.

Description

Method and device for configuring scheduling mode of container group

Technical Field

The embodiment of the disclosure relates to the technical field of computers, in particular to a method and a device for configuring a container group scheduling mode.

Background

With the rapid development of application deployment by way of deployment containers, many deployment tools for containerized applications have emerged. For example, the containerization platform kubernetes and the containerization platform Docker, etc. High availability is a very important aspect for the practical application of these deployment tools. Currently, these deployment tools achieve high availability through various measures such as cluster setup, copy set, automatic fault tolerance mechanism, and load balancing mechanism.

Among them, duplicate sets are a common measure of achieving high availability. In general, high availability is ensured by scheduling container groups by setting up copies of multiple container groups (e.g., pod, etc.), and breaking up the copies onto different nodes (nodes) to run the same containerized application, etc. However, the existing container group scheduling is usually implemented by the service application side to configure the scheduling policy by itself or by using some existing tools. The existing container group scheduling methods need to know in advance the deployment of the whole preconfigured container clusters in the tools, use planning, labels (Label) required by the container groups during scattering, and the like, so that the interaction cost and the coupling performance with the container clusters are naturally increased.

Disclosure of Invention

The embodiment of the disclosure provides a method and a device for configuring a container group scheduling mode.

In a first aspect, an embodiment of the present disclosure provides a method for configuring a container group scheduling manner, the method including: monitoring a resource creation action in the container cluster, wherein the resource creation action is used for indicating to create a target resource, and the target resource is used for running a containerized application; in response to monitoring the resource creation action, injecting a container group scheduling configuration into the target resource, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; and performing persistent storage on the target resource.

In a second aspect, an embodiment of the present disclosure provides an apparatus for configuring a container group scheduling manner, where the apparatus includes: a monitoring unit configured to monitor resource creation actions in the container cluster, wherein the resource creation actions are used for indicating to create target resources, and the target resources are used for running the containerized application; a configuration unit configured to inject a container group scheduling configuration to a target resource in response to monitoring of the resource creation action, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; and the storage unit is configured to store the target resource in a persistent mode.

In a third aspect, embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage means for storing one or more programs; the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method as described in any of the implementations of the first aspect.

In a fourth aspect, embodiments of the present disclosure provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method as described in any of the implementations of the first aspect.

According to the method and the device for configuring the container group scheduling mode, the resource creating action in the container cluster is monitored, and when the corresponding resource creating action is monitored, the container group scheduling configuration is injected into the target resource created by the resource creating action, so that the container group scheduling configuration is uniformly carried out on the container cluster layer before the target resource is durable, and further when the container cluster schedules the container group, the container group scheduling can be directly realized according to the container group scheduling configuration, so that high availability is ensured. This container scheduling is transparent to the service application side, and does not require the aid of other scheduling tools or the like.

Drawings

Other features, objects and advantages of the present disclosure will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings:

FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present disclosure may be applied;

FIG. 2 is a flow chart of one embodiment of a method of configuring a container group scheduling approach according to the present disclosure;

FIG. 3 is a schematic illustration of one application scenario of a method of configuring a container group scheduling approach in accordance with an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of one embodiment of an apparatus for configuring a container group scheduling approach in accordance with the present disclosure;

fig. 5 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.

Detailed Description

The present disclosure is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.

In the technical scheme of the invention, the related aspects of acquisition/collection, updating, analysis, use, transmission, storage and the like of the personal information of the user accord with the regulations of related laws and regulations, are used for legal and reasonable purposes, are not shared, leaked or sold outside the legal use aspects and the like, and are subjected to supervision and management of the national supervision and management department. Necessary measures should be taken for the personal information of the user, the use or access of the personal information data should be selectively prevented to prevent illegal access to such personal information data, to ensure that personnel having access to the personal information data comply with the regulations of the relevant laws and regulations, and to ensure the personal information security of the user. Furthermore, once such user personal information data is no longer needed, the risk should be minimized by limiting or even prohibiting the data collection and/or deletion.

It should be noted that, without conflict, the embodiments of the present disclosure and features of the embodiments may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 illustrates an exemplary architecture 100 of an embodiment of a method of configuring a container group scheduling approach or an apparatus of configuring a container group scheduling approach to which the present disclosure may be applied.

As shown in fig. 1, a system architecture 100 may include a container cluster 101 and clients 102. The container cluster 101 and the client 102 may be communicatively connected by various connection types such as a wired or wireless communication link or a fiber optic cable. Applications of the client 102 may be deployed in the container cluster 101 in a containerized manner to provide services to the client 102.

The container clusters may be built based on various existing containerized deployment tools (e.g., kubernetes, et al). For example, the container cluster may be a Kubernetes cluster. In general, a plurality of nodes may be included in a container cluster.

The client 102 may be various terminal devices used on the service application side. The client 102 may be hardware or software. When the client 102 is hardware, it may be a variety of electronic devices with a display screen including, but not limited to, smartphones, tablets, electronic book readers, laptop and desktop computers, and the like. When the client 102 is software, it can be installed in the electronic device enumerated above. Which may be implemented as multiple software or software modules (e.g., multiple software or software modules for providing distributed services) or as a single software or software module. The present invention is not particularly limited herein.

It should be noted that, the method for configuring the container group scheduling manner provided by the embodiment of the present disclosure is generally performed by the container cluster 101, and accordingly, the device for configuring the container group scheduling manner is generally disposed in the container cluster 101.

It should be understood that the number of container clusters and clients in fig. 1 is merely illustrative. There may be any number of container clusters and clients, as desired for implementation.

With continued reference to FIG. 2, a flow 200 of one embodiment of a method of configuring a container group schedule according to the present disclosure is shown. The method for configuring the scheduling mode of the container group comprises the following steps:

step 201, monitoring a resource creation action in a container cluster.

In this embodiment, the container clusters may be based on clusters built by existing various containerized deployment tools. For example, the container cluster may be a Kubernetes cluster. The resource creation action may be used to indicate the creation of the target resource. The target resource may refer to various resources in the container cluster for running the containerized application, among others. Taking the Kubernetes cluster as an example, the target resource may be a workload type resource, such as Deployment, statefulSet, daemonSet.

The execution body of the method for configuring the container group scheduling mode can monitor the resource creation action in the container cluster by adopting various methods. For example, a corresponding listener is pre-written by a relevant technician according to the container cluster's listening mechanism to effect listening to the resource creation actions in the container cluster.

As another example, taking a Kubernetes cluster as an example, interception of resource creation actions in a container cluster may be implemented using a MutingAdmissionWebhook et al service. Specifically, listening content, listening rules, and the like may be preset in a file such as a MutatingWebhookConfiguration.

Step 202, in response to monitoring the resource creation action, injecting a container group scheduling configuration into the target resource.

In this embodiment, a group of containers may refer to a unit that runs one or more containers. For example, the set of containers may be Pod in Kubernetes. The container group corresponds to the containerized application described above, i.e., the containers in the container group are used to run the containerized application described above. The container group scheduling configuration may be used to describe the manner in which the container group is scheduled. For example, a container group scheduling configuration may refer to a specific scheduling policy or scheduling rule for a container group.

Specifically, upon hearing the resource creation actions, various methods may be employed to inject the target resource into the container group scheduling configuration. For example, for different container clusters, the target resource may be injected into the container group schedule configuration in a corresponding resource allocation manner.

As another example, taking a Kubernetes cluster as an example, injection of a target resource into a container group scheduling configuration may be accomplished by writing a WebHook service.

And 203, performing persistent storage on the target resource.

In this embodiment, after the target resource is injected into the container group scheduling configuration, the created target resource may be further subjected to persistent storage. In other words, the container schedule configuration described above is performed prior to persistent storage of the target resource. Specifically, various methods may be employed to persist the target resource. For example, for different clusters of containers, the target resource may be persisted in a corresponding persisted manner.

As another example, using a Kubernetes cluster as an example, persistent storage of target resources may be implemented using Etcd.

In some alternative implementations of the present embodiment, the target resource creation action in the container cluster may also be monitored by:

step one, obtaining preset resource filtering conditions.

In this step, the execution body may acquire a preset resource filtering condition from a local or other storage space. Resource filtering conditions may be used to describe resources that do not need to be listened to. Specifically, the setting may be performed in advance by a relevant technician according to actual application requirements. The resource filtering condition can also be described by adopting various methods according to the actual application scene. For example, resource filtering conditions may filter resources by constraining the name, type, or namespace of the resources, etc.

Taking the Kubernetes cluster as an example, the resource filtering conditions may be specified using Webhook. Specifically, resources that do not need to be snooped may be constrained by specifying such things as objectSelector and naspaceselector.

And step two, monitoring a target resource creation action in the container cluster according to the resource filtering condition.

In this step, the target resource creation action in the container cluster may be monitored in combination with the resource filtering condition. At this time, if the resource created by the resource creation action in the container cluster belongs to the resource specified by the resource filtering condition, the resource creation action is not monitored, that is, the container group scheduling configuration is not performed on the resource by using the method. Correspondingly, if the resource created by the resource creation action in the container cluster does not belong to the resource specified by the resource filtering condition, the resource creation action can be monitored so as to perform container scheduling configuration on the resource according to the method.

By setting the resource filtering condition, some resources can be ignored to avoid the container scheduling configuration of the resources in the above manner, so that the resource deployment of some special applications can be flexibly processed.

In some alternative implementations of the present embodiment, the container group scheduling configuration corresponds to the described scheduling manner may be implemented by constraining the topological distribution of the container groups. The topology distribution of the constraint container groups can control the topology distribution among the container groups to meet the specified conditions so as to realize the requirements of balanced deployment and the like.

Taking Kubernetes cluster as an example, the topologypearedconstraints can be flexibly configured according to actual requirements to realize topology distribution constraint on the container group.

For example, the topologypearconstraints may be configured as follows:

topologySpreadConstraints:

—maxSkew：

topologyKey:

whenUnsatisfiable：

labelSelector：

where "maxSkew" is used to describe the degree of Pod maldistribution, representing the maximum allowable difference between matched pods in any two topology domains in a given topology type. Typically greater than zero. "topologyKey" means a key of a node label. Typically, if two nodes use this key label and have the same label value, then they will be considered to be in the same topology domain at the time of scheduling. The usual scheduling may try to place a balanced number of Pod in each topology domain. "whenunassisable" means how to handle if Pod does not meet the distribution constraint. The value "DoNotSchedule" or "ScheduleAnyway" may generally be taken. Wherein "DoNotSchedule" means not scheduled, belonging to a hard policy. "ScheduleAnyway" means that scheduling is continued, e.g. scheduling can be performed with minimized bias, belonging to a soft policy. The "labelSelector" is used to find matching Pod. The found matching Pod can be counted to determine the number of Pod in the corresponding topology domain.

It should be noted that the above examples only show some configurable parameters and the like, and in particular, specific parameter values may be determined according to an actual application scenario. Thus, the Pod topology distribution constraints can be utilized to achieve a high availability deployment of containerized applications.

In some alternative implementations of the present embodiment, scheduling of the container groups may be performed according to a container group scheduling configuration in response to a time of arrival at the scheduled container group.

Specifically, when the container cluster schedules the container group, the scheduling of the container group can be completed according to the scheduling mode indicated by the container group scheduling configuration. The time for scheduling the container group can be flexibly determined according to an actual application scene. For example, when a newly created group of containers in the container cluster is listened to and not scheduled to on any node. As another example, when a preset specified event occurs, and so forth.

As an example, the Kubernetes cluster may schedule and deploy a Pod on a pre-configured scheduling manner (e.g., a topologypreadconstraints configuration, etc.) as described above when the Pod is monitored as having a newly created Pod in the container cluster and not being scheduled to any Node.

By uniformly carrying out scheduling configuration on the container group in the cluster level in advance, high-availability deployment of the application can be realized under the condition that the service application side does not perceive.

With continued reference to fig. 3, fig. 3 is an exemplary application scenario 300 of a configuration container group scheduling approach according to the present embodiment. In the application scenario of fig. 3, when a user deploys an application in a Kubernetes cluster, the Kubernetes cluster may listen to requests of ApiServer to intercept the creation of Deployment, statefulSet, daemonSet and other types of resources. After intercepting the creation actions of these types of resources, and before persisting the created resources, a pre-written Webhook Server may be utilized to inject a topologySpreadConstraints related configuration on the created resources. Then, the created resources are persisted by the ETCD. After that, when the Kubernetes cluster schedules the corresponding Pod, the Pod can be scattered to the nodes in different domains as uniformly as possible according to the relevant configuration of the topologySpreadConstrants, so that the high-availability deployment effect of the service application is realized.

According to the method provided by the embodiment of the invention, the high-availability configuration related to the scheduling of the container groups is uniformly injected in the cluster layer before the resource data of the operation container in the container cluster is persistence, so that the scheduling of the container groups of the service application can be completed according to the specified rule, and the high-availability deployment of the service application is realized under the condition that the service side does not perceive the information such as the deployment and the use planning of the cluster. Meanwhile, other scheduling tools and the like are not needed in the mode, so that the information such as deployment and use planning of the clusters is not needed to be preconfigured to the scheduling tools and the like, and the increase of the interaction cost and the coupling of the scheduling tools and the cluster environment is avoided.

With further reference to fig. 4, as an implementation of the method shown in the foregoing figures, the present disclosure provides an embodiment of an apparatus for configuring a container group scheduling manner, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus may be specifically applied in various electronic devices.

As shown in fig. 4, the apparatus 400 for configuring a container group scheduling manner provided in this embodiment includes a listening unit 401, a configuring unit 402, and a storage unit 403. Wherein the listening unit 401 is configured to listen to a resource creation action in the container cluster, wherein the resource creation action is for indicating to create a target resource for running the containerized application; the configuration unit 402 is configured to inject a container group scheduling configuration into the target resource in response to monitoring the resource creation action, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; the storage unit 403 is configured to persistent store the target resource.

In this embodiment, in the apparatus 400 for configuring a container group scheduling method: the specific processes of the monitor unit 401, the configuration unit 402 and the storage unit 403 and the technical effects thereof may refer to the descriptions related to step 201, step 202 and step 203 in the corresponding embodiment of fig. 2, and are not repeated herein.

In some optional implementations of this embodiment, the above-mentioned listening unit 401 is further configured to: acquiring preset resource filtering conditions, wherein the resource filtering conditions are used for describing resources which do not need to be monitored; monitoring a target resource creation action in the container cluster according to the resource filtering condition; and the target resource does not meet the resource filtering condition.

In some alternative implementations of this embodiment, the scheduling is implemented by constraining the topological distribution of the container groups.

In some optional implementations of this embodiment, the apparatus 400 further includes: a scheduling unit (not shown in the figure) is configured to schedule the group of containers according to a container group scheduling configuration in response to a moment of arrival at the scheduled group of containers.

The device provided by the embodiment of the disclosure monitors, through a monitoring unit, a resource creation action in a container cluster, where the resource creation action is used to instruct to create a target resource, and the target resource is used to run a containerized application; the configuration unit is used for responding to the monitored resource creation action and injecting a container group scheduling configuration to the target resource, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; the storage unit performs persistent storage on the target resources so as to uniformly inject high-availability configuration related to container group scheduling in a cluster layer before the resource data of the operation container in the container cluster is persistent, thereby realizing high-availability deployment of service application, and enabling a service application side to not need to perceive information such as deployment and use planning of the cluster.

Referring now to fig. 5, a schematic diagram of an electronic device (e.g., server in fig. 1) 500 suitable for use in implementing embodiments of the present disclosure is shown. The server illustrated in fig. 5 is merely an example, and should not be construed as limiting the functionality and scope of use of embodiments of the present disclosure in any way.

As shown in fig. 5, the electronic device 500 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 501, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 502 or a program loaded from a storage means 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the electronic apparatus 500 are also stored. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.

In general, the following devices may be connected to the I/O interface 505: input devices 506 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 507 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 508 including, for example, magnetic tape, hard disk, etc.; and communication means 509. The communication means 509 may allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. While fig. 5 shows an electronic device 500 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 5 may represent one device or a plurality of devices as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication means 509, or from the storage means 508, or from the ROM 502. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 501.

It should be noted that, the computer readable medium according to the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In an embodiment of the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: monitoring a resource creation action in the container cluster, wherein the resource creation action is used for indicating to create a target resource, and the target resource is used for running a containerized application; in response to monitoring the resource creation action, injecting a container group scheduling configuration into the target resource, wherein the container group scheduling configuration is used for describing a scheduling mode of the container group, and the container group corresponds to the containerized application; and performing persistent storage on the target resource.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes a snoop unit, a configuration unit, and a storage unit. Where the names of the units do not constitute a limitation on the unit itself in some cases, for example, a storage unit may also be described as a "unit that persists a target resource".

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A method of configuring a container group scheduling scheme, comprising:

monitoring a resource creation action in a container cluster, wherein the resource creation action is used for indicating to create a target resource, and the target resource is used for running a containerized application;

injecting a container group scheduling configuration to the target resource in response to the monitoring of the resource creation action, wherein the container group scheduling configuration is used for describing a scheduling mode of a container group, and the container group corresponds to the containerized application;

and performing persistent storage on the target resource.

2. The method of claim 1, wherein the resource creation action in the listening container cluster comprises:

acquiring preset resource filtering conditions, wherein the resource filtering conditions are used for describing resources which do not need to be monitored;

monitoring a target resource creation action in the container cluster according to the resource filtering condition; and

the target resource does not meet the resource filtering condition.

3. The method of claim 1, wherein the scheduling is implemented by constraining a topological distribution of the set of containers.

4. A method according to one of claims 1-3, wherein the method further comprises:

scheduling the group of containers according to the group of containers scheduling configuration in response to reaching a time of scheduling the group of containers.

5. An apparatus for configuring a container group scheduling scheme, comprising:

a listening unit configured to listen to resource creation actions in a container cluster, wherein the resource creation actions are used for indicating to create a target resource, and the target resource is used for running a containerized application;

a configuration unit configured to inject a container group scheduling configuration to the target resource in response to monitoring the resource creation action, wherein the container group scheduling configuration is used for describing a scheduling manner of a container group, and the container group corresponds to the containerized application;

and the storage unit is configured to store the target resource in a persistent mode.

6. The apparatus of claim 5, wherein the listening unit is further configured to:

the target resource does not meet the resource filtering condition.

7. The apparatus of claim 5, wherein the scheduling is implemented by constraining a topological distribution of the set of containers.

8. The apparatus according to one of claims 5-7, wherein the apparatus further comprises:

and a scheduling unit configured to schedule the container group according to the container group scheduling configuration in response to reaching a time to schedule the container group.

9. A server, comprising:

one or more processors;

a storage device having one or more programs stored thereon;

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-4.

10. A computer readable medium having stored thereon a computer program, wherein the program when executed by a processor implements the method of any of claims 1-4.