CN109150987B - Two-layer container cluster elastic expansion method based on host layer and container layer - Google Patents
Two-layer container cluster elastic expansion method based on host layer and container layer Download PDFInfo
- Publication number
- CN109150987B CN109150987B CN201810846155.5A CN201810846155A CN109150987B CN 109150987 B CN109150987 B CN 109150987B CN 201810846155 A CN201810846155 A CN 201810846155A CN 109150987 B CN109150987 B CN 109150987B
- Authority
- CN
- China
- Prior art keywords
- layer
- container
- cluster
- resources
- arc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a two-layer container cluster elastic capacity expansion method based on a host layer and a container layer, and relates to the technical field of resource calculation. The method provides a scheduling scheme with telescopic cluster resources of the containers on the cloud, when the containers are uniformly scheduled, if insufficient cluster resources are found, the number of the expansion nodes can be calculated through the method based on the resource load condition, the nodes are created by calling API of a cloud service provider, so that automatic elastic expansion of a host layer is achieved, and the RC is combined to control the number of the Pod, so that the uniform elastic expansion of the host layer and the container layer is realized, and the integral scheduling and management of the container clusters are facilitated.
Description
Technical Field
The invention relates to the technical field of resource calculation, in particular to a two-layer container cluster elastic capacity expansion method based on a host layer and a container layer.
Background
In the cloud computing era, all resources are elastically scalable, such as computing resources represented by cloud servers. The traditional IT application architecture is also adapted to change, and the application service not only realizes the decoupling between different components of a large-scale system, but also facilitates the management and independent development, operation, maintenance and deployment of each service. Docker, as a representative technology of the currently popular container runtime, can pack the runtime environment of software into mirror images, and store the mirror images in a unified manner through a mirror image warehouse. The application can directly pull the mirror image to quickly start on the node when being deployed. After being decoupled, a large-scale system is divided into a plurality of modules, and a container arrangement technology represented by Kubernetes can enable Docker of the plurality of modules to uniformly organize and abstract, so that a software organization framework for mutual communication among a plurality of services is finally formed. For a plurality of container groups (Pod in Kubernetes) at each back end, Kubernetes proposes a Replication Control controller for controlling the number of pods with the same configuration, and the number of pods can be expanded and contracted by configuring the attributes of replicates. Each container can define the minimum quantity and the maximum quantity of resource application such as memory, CPU and the like in a configuration file, and then the container cluster can encounter the situation that cluster resources are insufficient. At present, in this case, it is necessary to add nodes to the container cluster manually, and a quantitative index is set for the number of the added nodes. It is not conducive to overall scheduling and management of the container cluster.
Disclosure of Invention
The invention aims to provide a two-layer container cluster elastic capacity expansion method based on a host layer and a container layer, so that the problems in the prior art are solved.
In order to achieve the purpose, the technical scheme adopted by the invention is as follows:
a two-layer container cluster elastic capacity expansion method based on a host layer and a container layer comprises the following steps:
s1, building a Kubernetes cluster;
s2, deploying an autoScaling process and a Master-Server process on a main node of the Kubernetes cluster, and respectively starting the two processes;
s3, creating and deploying a typical RC object in Kubernets for controlling the number of Pod copies;
s4, creating a corresponding ARC object aiming at the deployed RC object, and submitting Post to a Master-Server process, wherein the Master-Server process encapsulates the ARC object into JSON format and stores the JSON format in a background ETCD in a persistent manner;
and S5, monitoring whether an ARC object is created in the ETCD after the autoScaling process is started, and if yes, establishing a thread to maintain the ARC object, thereby realizing uniform and flexible capacity expansion of a certain service in a host layer and a container layer.
Preferably, in S5, the newly building a thread to maintain the ARC object, and implementing unified flexible capacity expansion of a certain service at the host layer and the container layer specifically includes: acquiring the occupation condition of cluster resources, calculating the proportion of the occupation of the resources to the resource application, judging whether the resources need to be elastically expanded, if so, judging whether the overall resources of the cluster are sufficient after the expansion according to an expected value, if so, calculating the Pod number of the expanded resources, and directly modifying the replicas parameters of the associated RC objects to realize the expansion on the container level; and if the cluster total resources are insufficient after the expansion, calculating the number of the expanded cloud hosts, creating the cloud hosts with the corresponding number, realizing the automatic flexible expansion of the host level, calculating the number of the expanded Pods after the host level is successfully expanded, and expanding the container level.
Preferably, the cluster resource occupancy is obtained according to the following method: deploying a Heapster on the Kubernets cluster, wherein the Heapster acquires the performance data of all containers on each node by accessing the API of the kubelelet on each node and calling the API of the cAdvison through the kubelelet, so as to obtain the occupation condition of the cluster resources.
Preferably, an inflixdb database is deployed on a kubernets cluster, and the Heapster puts the collected performance data of all containers on each node into the inflixdb database.
Preferably, the resource application condition is obtained according to the following method: the configuration file Pod definition part of the RC defines the limit value and the application value of the whole Pod to the CPU and the memory through spec.contacts [ ]. resources, and the autoScaling process obtains the CPU and the memory application value of all the pods by requesting a Pod list in the cluster from the kube-apiserver.
Preferably, S2 specifically is to deploy a jar packet containing the autoScaling process and the Master-Server process on the Master node of the kubernets cluster, and start the two processes respectively.
The invention has the beneficial effects that: the two-layer container cluster elastic expansion method based on the host layer and the container layer provided by the embodiment of the invention provides a scheduling scheme for the telescopic resource of the container cluster on the cloud, when the container is uniformly scheduled, if the cluster resource is found to be insufficient, the number of expansion nodes can be calculated through the method based on the resource load condition, the nodes are created through the API of a cloud service provider, so that the automatic elastic expansion of the host layer is achieved, and the RC is combined to control the number of the Pod, so that the uniform elastic expansion of the host layer and the container layer is realized, and the integral scheduling and management of the container cluster are facilitated.
Drawings
FIG. 1 is a schematic flow chart of a two-layer container cluster elastic expansion method based on a host layer and a container layer, provided by the invention;
fig. 2 is a schematic flow chart illustrating the process of maintaining the ARC object to achieve unified flexible expansion of the host layer and the container layer.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
As shown in fig. 1, an embodiment of the present invention provides a two-layer container cluster flexible capacity expansion method based on a host layer and a container layer, including the following steps:
s1, building a Kubernetes cluster;
s2, deploying an autoScaling process and a Master-Server process on a main node of the Kubernetes cluster, and respectively starting the two processes;
s3, creating and deploying a typical RC object in Kubernets for controlling the number of Pod copies;
s4, creating a corresponding ARC object aiming at the deployed RC object, and submitting Post to a Master-Server process, wherein the Master-Server process encapsulates the ARC object into JSON format and stores the JSON format in a background ETCD in a persistent manner;
and S5, monitoring whether an ARC object is created in the ETCD after the autoScaling process is started, and if yes, establishing a thread to maintain the ARC object, thereby realizing uniform and flexible capacity expansion of a certain service in a host layer and a container layer.
In the above method, arc (auto Replication control) is a package of the RC of Kubernetes itself, and can be associated with the target RC through targetRef. checkPeriod defines the period of checking, by default 30 s. In addition, RC of the target is related through spec, and the occupation ratio of all Pod actual operation occupied resources and pre-application resources, which are used for realizing automatic elastic expansion of the host layer and the container layer and judging whether the Pod needs resource expansion, is defined in metrics. Currently, two resources, a CPU and a memory, are supported.
The client can send an instruction for creating the ARC to a Master-Server on a Kubernetes container cluster with a same-name RC object, wherein the Master-Server is a typical HTTP Server and provides an interface and is responsible for receiving a request for creating the ARC object from an external client, and simultaneously, the ARC object is constructed according to the request and written into an ETCD storage. The Master-Server is realized based on a Jersey open source framework, and the Jersey-client class library is used for realizing access to the ETCD API.
After being created, the ARC is periodically checked by the autoScaling process, on one hand, the ARC is associated with the RC for specifically managing the copy, on the other hand, the ARC defines the resource type, and the ARC is written into the ETCD storage as the attribute of the ARC object and is queried by the autoScaling process. The autoScaling is an independent JAVA process, is located on a Master node of a kubernets container cluster, and is responsible for maintaining an ARC object, so that uniform and flexible expansion of the node and the container is performed on a certain service.
In the implementation process of S1, the following method may be adopted: taking the CentOS7 operating system as an example, services such as kubernets-Master, kubernets-Slave, etc. and Flannel are respectively installed by using yum installation mode, and then the services are sequentially started on respective nodes of the cluster. Both the Kubernetes-Master and Kubernetes-Slave services contain the respective processes required as Kubernetes memory Master and Slave nodes.
As shown in fig. 2, in the embodiment of the present invention, in S5, the newly creating a thread to maintain the ARC object, so as to implement uniform and flexible capacity expansion of a certain service in the host layer and the container layer, specifically: acquiring the occupation condition of cluster resources, calculating the proportion of the occupation of the resources to the resource application, judging whether the resources need to be elastically expanded, if so, judging whether the overall resources of the cluster are sufficient after the expansion according to an expected value, if so, calculating the Pod number of the expanded resources, and directly modifying the replicas parameters of the associated RC objects to realize the expansion on the container level; and if the cluster total resources are insufficient after the expansion, calculating the number of the expanded cloud hosts, creating the cloud hosts with the corresponding number, realizing the automatic flexible expansion of the host level, calculating the number of the expanded Pods after the host level is successfully expanded, and expanding the container level.
In the specific implementation process, the real-time cluster resource occupation condition and the resource application condition are firstly obtained, so that the proportion of the resource occupation and the resource application is calculated to determine whether the resource needs to be elastically expanded. And if so, calculating whether the cluster total resources are sufficient after the cluster total resources are expanded according to the expected values, calculating the number of the Pod of the expanded resources if the cluster total resources are sufficient, and then directly modifying the replicas parameters of the associated RC objects to realize the expansion of the container level. When the total resources of the cluster are insufficient, the number of the expanded cloud hosts needs to be calculated, then a command for creating the cloud server is sent to a public cloud service provider, and when the cloud server is successfully created through polling judgment, a command for adding the host to the cluster is sent to the public cloud service provider, so that automatic elastic expansion of the host layer is realized. And after the host level expansion is successful, calculating the number of expanded Pod to realize the expansion of the container level.
The cluster resource occupation condition is obtained according to the following method: deploying a Heapster on the Kubernets cluster, wherein the Heapster acquires the performance data of all containers on each node by accessing the API of the kubelelet on each node and calling the API of the cAdvison through the kubelelet, so as to obtain the occupation condition of the cluster resources.
An inflixdb database is deployed on a Kubernets cluster, and the Heapster puts the collected performance data of all containers on each node into the inflixdb database.
For the above method, the details are as follows:
the cluster is composed of a plurality of nodes, and the total resource of the cluster can be understood as the sum of the resources of the nodes. The resources can be divided into application resources and resources actually occupied by the application. For actually occupied computing resources, a scheme for monitoring and collecting the resource use condition of each node is needed, and the Heapster service is adopted in the invention to collect the resource use condition of each node.
Kubernetes embeds a monitoring process named cAdvisor in a kubelet process of each node, the cAdvisor can acquire performance indexes of each node and performance indexes of containers running on the nodes in real time, the performance indexes comprise information such as CPU use condition, memory use condition, network throughput and file system use condition, and REST API is provided for clients to call. And the total actual occupied computing resource of the cluster is the sum of the computing resources actually occupied by each node, so a collection process is needed to collect the monitoring information of the cAsvisor process of each node, and the total actual occupied resource of the cluster is calculated. For this problem, the present invention is addressed using a Heapster. The Heapster collects the performance data of all containers on each Node by accessing the API of kubel on the Node and calling the API of cAdvisor through kubel. The collected data may be placed in a time-series database such as infiluxdb.
In the embodiment of the present invention, the resource application condition may be obtained according to the following method: the configuration file Pod definition part of the RC defines the limit value and the application value of the whole Pod to the CPU and the memory through spec.contacts [ ]. resources, and the autoScaling process obtains the CPU and the memory application value of all the pods by requesting a Pod list in the cluster from the kube-apiserver.
In a preferred embodiment of the present invention, S2 may specifically be that a jar packet containing an autoScaling process and a Master-Server process is deployed on a Master node of a kubernets cluster, and the two processes are respectively started.
By adopting the technical scheme disclosed by the invention, the following beneficial effects are obtained: the two-layer container cluster elastic expansion method based on the host layer and the container layer provided by the embodiment of the invention provides a scheduling scheme for the telescopic resource of the container cluster on the cloud, when the container is uniformly scheduled, if the cluster resource is found to be insufficient, the number of expansion nodes can be calculated through the method based on the resource load condition, the nodes are created through the API of a cloud service provider, so that the automatic elastic expansion of the host layer is achieved, and the RC is combined to control the number of the Pod, so that the uniform elastic expansion of the host layer and the container layer is realized, and the integral scheduling and management of the container cluster are facilitated.
The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and improvements can be made without departing from the principle of the present invention, and such modifications and improvements should also be considered within the scope of the present invention.
Claims (4)
1. A two-layer container cluster elastic capacity expansion method based on a host layer and a container layer is characterized by comprising the following steps:
s1, building a Kubernetes cluster;
s2, deploying an autoScaling process and a Master-Server process on a main node of the Kubernetes cluster, and respectively starting the two processes; s2 specifically comprises deploying jar packages containing an autoScaling process and a Master-Server process on a main node of the Kubernets cluster, and respectively starting the two processes;
s3, creating and deploying an RC object in Kubernets for controlling the number of Pod copies;
s4, creating a corresponding ARC object aiming at the deployed RC object, and submitting Post to a Master-Server process, wherein the Master-Server process encapsulates the ARC object into JSON format and stores the JSON format in a background ETCD in a persistent manner; the Master-Server is an HTTP Server, provides an interface, is responsible for receiving a request for creating an ARC object by an external client, constructs the ARC object according to the request and writes the ARC object into an ETCD (electronic toll Collection) storage; the Master-Server is realized based on a Jersey open source framework, and the Jersey-client class library is used for realizing access to the ETCD API;
s5, monitoring whether an ARC object is created in the ETCD after the autoScaling process is started, and if yes, establishing a thread to maintain the ARC object, so as to realize uniform and flexible capacity expansion of a certain service in a host layer and a container layer; in S5, the newly creating a thread to maintain the ARC object, and implementing uniform flexible capacity expansion of a certain service in the host layer and the container layer specifically includes: acquiring the occupation condition of cluster resources, calculating the proportion of the occupation of the resources to the resource application, judging whether the resources need to be elastically expanded, if so, judging whether the overall resources of the cluster are sufficient after the expansion according to an expected value, if so, calculating the Pod number of the expanded resources, and directly modifying the replicas parameters of the associated RC objects to realize the expansion on the container level; if the cluster total resources are insufficient after the expansion, calculating the number of the expanded cloud hosts, creating a corresponding number of cloud hosts, realizing the automatic flexible expansion of the host level, calculating the number of expanded Pods after the host level is successfully expanded, and expanding the container level;
after being created, the ARC is periodically checked by an autoScaling process, on one hand, the ARC is associated with RC for specifically managing the copy, on the other hand, the ARC defines the resource type, and the ARC is written into an ETCD storage as the attribute of the ARC object and is inquired by the autoScaling process; the autoScaling is an independent JAVA process, is located on a Master node of a kubernets container cluster, and is responsible for maintaining an ARC object, so that uniform and flexible expansion of the node and the container is performed on a certain service.
2. The flexible capacity expansion method for the two-layer container cluster based on the host layer and the container layer as claimed in claim 1, wherein the cluster resource occupation is obtained according to the following method: deploying a Heapster on the Kubernets cluster, wherein the Heapster acquires the performance data of all containers on each node by accessing the API of the kubelelet on each node and calling the API of the cAdvison through the kubelelet, so as to obtain the occupation condition of the cluster resources.
3. The flexible capacity expansion method for the two-layer container cluster based on the host layer and the container layer as claimed in claim 2, wherein an inflixdb database is deployed on a kubernets cluster, and a Heapster puts collected performance data of all containers on each node into the inflixdb database.
4. The flexible capacity expansion method for the two-layer container cluster based on the host layer and the container layer as claimed in claim 1, wherein the resource application condition is obtained as follows: the configuration file Pod definition part of the RC defines the limit value and the application value of the whole Pod to the CPU and the memory through spec.contacts [ ]. resources, and the autoScaling process obtains the CPU and the memory application value of all the pods by requesting a Pod list in the cluster from the kube-apiserver.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810846155.5A CN109150987B (en) | 2018-07-27 | 2018-07-27 | Two-layer container cluster elastic expansion method based on host layer and container layer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810846155.5A CN109150987B (en) | 2018-07-27 | 2018-07-27 | Two-layer container cluster elastic expansion method based on host layer and container layer |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109150987A CN109150987A (en) | 2019-01-04 |
| CN109150987B true CN109150987B (en) | 2021-11-30 |
Family
ID=64798145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810846155.5A Active CN109150987B (en) | 2018-07-27 | 2018-07-27 | Two-layer container cluster elastic expansion method based on host layer and container layer |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109150987B (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111752701B (en) * | 2019-03-29 | 2024-01-26 | 北京数安鑫云信息技术有限公司 | System cluster and resource scheduling method thereof |
| CN112291288B (en) * | 2019-07-24 | 2022-10-04 | 北京金山云网络技术有限公司 | Container cluster expansion method and device, electronic equipment and readable storage medium |
| CN110531987A (en) * | 2019-07-30 | 2019-12-03 | 平安科技（深圳）有限公司 | Management method, device and computer readable storage medium based on Kubernetes cluster |
| CN110784347A (en) * | 2019-10-18 | 2020-02-11 | 北京浪潮数据技术有限公司 | Node management method, system, equipment and storage medium for container cluster |
| CN113190324B (en) * | 2020-01-14 | 2024-09-13 | 阿里巴巴集团控股有限公司 | Traffic distribution method, device, system and storage medium |
| CN111464355B (en) * | 2020-03-31 | 2022-11-15 | 北京金山云网络技术有限公司 | Method and device for controlling expansion and contraction capacity of Kubernets container cluster and network equipment |
| CN111522636B (en) * | 2020-04-03 | 2023-03-14 | 安超云软件有限公司 | Application container adjusting method, application container adjusting system, computer readable medium and terminal device |
| CN114327846A (en) * | 2020-09-30 | 2022-04-12 | 腾讯科技（深圳）有限公司 | Cluster capacity expansion method and device, electronic equipment and computer readable storage medium |
| CN112532722B (en) * | 2020-11-27 | 2023-03-24 | 中国—东盟信息港股份有限公司 | Kubernetes cloud native cluster node-based graceful shutdown method |
| CN112600942B (en) * | 2021-02-18 | 2022-12-02 | 杭州网银互联科技股份有限公司 | Method and system for improving routing calculation efficiency in sd-wan |
| CN112882794B (en) * | 2021-02-25 | 2022-10-28 | 重庆紫光华山智安科技有限公司 | pod capacity expansion method, device, node and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107704310A (en) * | 2017-09-27 | 2018-02-16 | 郑州云海信息技术有限公司 | A kind of method, apparatus and equipment for realizing container cluster management |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9985827B2 (en) * | 2016-05-24 | 2018-05-29 | Futurewei Technologies, Inc. | Automated generation of deployment workflows for cloud platforms based on logical stacks |
| CN107426034B (en) * | 2017-08-18 | 2020-09-01 | 国网山东省电力公司信息通信公司 | Large-scale container scheduling system and method based on cloud platform |
-
2018
- 2018-07-27 CN CN201810846155.5A patent/CN109150987B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107704310A (en) * | 2017-09-27 | 2018-02-16 | 郑州云海信息技术有限公司 | A kind of method, apparatus and equipment for realizing container cluster management |
Non-Patent Citations (1)
| Title |
|---|
| 基于Kubernetes的大数据流式计算Spark平台设计与实现;杜威科;《中国优秀硕士学位论文全文库数据库（电子期刊）》;20180215;第2.3，3.1-3.4，4.2-4.4，5.1-5.4节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109150987A (en) | 2019-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109150987B (en) | Two-layer container cluster elastic expansion method based on host layer and container layer | |
| CN111880936B (en) | Resource scheduling method, device, container cluster, computer equipment and storage medium | |
| CN107463582B (en) | Distributed Hadoop cluster deployment method and device | |
| CN108920153B (en) | Docker container dynamic scheduling method based on load prediction | |
| US11321139B2 (en) | Streaming traffic pattern for public cloud auto scaling | |
| CN102868736B (en) | A kind of cloud computing Monitoring framework design basis ground motion method and cloud computing treatment facility | |
| CN105357296A (en) | Elastic caching system based on Docker cloud platform | |
| CN105472042A (en) | WEB terminal controlled message middleware system and data transmission method thereof | |
| CN111563018B (en) | Resource management and monitoring method of man-machine-object fusion cloud computing platform | |
| CN110932912A (en) | Method for realizing unified management of configuration files under micro-service architecture | |
| CN110138753B (en) | Distributed message service system, method, apparatus, and computer-readable storage medium | |
| CN113382077B (en) | Micro-service scheduling method, micro-service scheduling device, computer equipment and storage medium | |
| CN112463290A (en) | Method, system, apparatus and storage medium for dynamically adjusting the number of computing containers | |
| CN112631680B (en) | Micro-service container scheduling system, method, device and computer equipment | |
| CN112468310B (en) | Streaming media cluster node management method and device and storage medium | |
| CN112965817B (en) | Resource management method and device and electronic equipment | |
| CN113055461A (en) | ZooKeeper-based unmanned cluster distributed cooperative command control method | |
| WO2022267646A1 (en) | Pod deployment method and apparatus | |
| CN112559138B (en) | Resource scheduling system and method | |
| CN114565502A (en) | GPU resource management method, scheduling method, device, electronic equipment and storage medium | |
| CN114338670A (en) | Edge cloud platform and three-level cloud control platform for internet traffic with same | |
| CN104657240B (en) | The Failure Control method and device of more kernel operating systems | |
| CN112698930A (en) | Method, device, equipment and medium for obtaining server identification | |
| CN115225645B (en) | Service updating method, device, system and storage medium | |
| CN109525443B (en) | processing method and device for distributed pre-acquisition communication link and computer equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |