CN114221773B - Method for automatically adding agent based on container cloud - Google Patents
Method for automatically adding agent based on container cloud Download PDFInfo
- Publication number
- CN114221773B CN114221773B CN202111551795.1A CN202111551795A CN114221773B CN 114221773 B CN114221773 B CN 114221773B CN 202111551795 A CN202111551795 A CN 202111551795A CN 114221773 B CN114221773 B CN 114221773B
- Authority
- CN
- China
- Prior art keywords
- resource object
- side car
- field
- pod
- adder
- 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
- 238000000034 method Methods 0.000 title claims abstract description 23
- 238000012544 monitoring process Methods 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method for automatically adding agents based on container cloud, comprising the following operation steps: (1) Creating and initializing an automatic side car adder into a Kubernetes cluster; (2) After the automatic side car adder is successfully initialized, a ConfigMap resource object containing side car information is deployed in a Kubernetes cluster, the ConfigMap resource object in the Kubernetes is monitored, and the side car information contained in the ConfigMap resource object is stored; (3) And creating a Pod resource object, and before the Pod resource object is persisted to the Kubernetes cluster, if the automatic sidecar adder stores the sidecar specified by the Pod resource object, modifying the Pod resource object description file and adding specified sidecar information to the Pod resource object description file.
Description
Technical Field
The invention relates to a method for automatically adding agents based on container cloud, and belongs to the technical field of cloud primordial.
Background
In recent years, cloud technology is gradually warmed up, and many enterprises start cloud transformation, so that the conventional application is expected to be migrated to the cloud. In the cloud-native technical solution, applications are placed in a agile, immutable infrastructure to run, so that the applications can be seamlessly migrated in different environments completely, and the mainstream method is realized by container technology at present. When the number of containers is large and distributed among different machines, how to manage large-scale containers becomes an issue. To solve this problem, kubernetes has been developed as a container arrangement system capable of continuously and automatically managing the application of containerization, improving the management efficiency of operation and maintenance personnel.
The sidecar (sidecar) mode adds additional functionality to existing services that does not affect business logic, but rather serves auxiliary functions such as collecting logs, managing files. Splitting business logic and auxiliary logic into different applications can reduce the degree of coupling between applications and the complexity of the business, which is an advantage of the side car mode. In Kubernetes (container cloud), it is shown that each Pod resource object runs multiple containers that communicate with each other, share a file system, have containers that carry specific business functions, and also have containers that function as auxiliary functions, the latter being called a sidecar (i.e., a kind of internal agent). Since the auxiliary functions are generic, the sidecar can be multiplexed in multiple Pod resource objects, resulting in a large duplication of information of the sidecar in different Pod resource object description files. The operation and maintenance personnel need to manually add information of the side car in each Pod resource object description file, which can lead to a great deal of data redundancy and reduce management efficiency.
At present, how to solve the problems of data redundancy and low efficiency caused by manually adding a large amount of repeated side car information becomes a technical problem which needs to be solved in the cloud primary technical field.
Disclosure of Invention
In view of the above, the present invention aims to provide a method for automatically adding a sidecar, so as to solve the problems of data redundancy and low efficiency caused by that operation and maintenance personnel need to manually add a large amount of repeated sidecar information in each Pod resource object description file.
In order to achieve the above purpose, the invention provides a method for automatically adding an agent based on a container cloud, which comprises the following operation steps:
step 1, creating and initializing an automatic side car adder to enter a Kubernetes cluster;
step 2, after the automatic side car adder is initialized successfully, a ConfigMap resource object containing side car information is deployed in a Kubernetes cluster, and the automatic side car adder monitors the ConfigMap resource object in the Kubernetes and stores the side car information contained in the ConfigMap resource object;
and 3, creating a Pod resource object to the Kubernetes cluster, and before the Pod resource object is persisted to the Kubernetes cluster, if the automatic sidecar adder stores the sidecar appointed by the Pod resource object, modifying the Pod resource object description file and adding appointed sidecar information to the Pod resource object description file.
The step 1 further comprises the following steps:
step 11, configuring public key and private key certificates required by TLS connection for the automatic side car adder, and having a service account number for monitoring ConfigMap resource object authority, namely a ServiceAccount resource object;
step 12, deploying a Deployment and Service resource object, designating parameters of an automatic side car adder, and starting an automatic side car adder Service, wherein the parameters of the automatic side car adder comprise: the label key value pair which can be met by the monitored ConfigMap resource object and the Pod resource object are assigned to add the annotation name space of the side car;
and step 13, configuring event matching rules for creating the Pod resource object, service references of the automatic side car adder and CA certificates for verifying TLS connection of the automatic side car adder service by deploying the MutingWebHookconfiguration resource object.
In the step 2, the automatic side car adder monitors the ConfigMap resource object in the Kubernetes and stores the specific content of the side car information contained in the ConfigMap resource object as follows:
the automatic side car adder monitors ConfigMap resource objects meeting corresponding label key value pairs, if the data of the ConfigMap resource objects meet the format of side car information, the ConfigMap resource objects are stored, and the name of the side car is used as the unique identifier of the side car; the side car information contains the following fields: name, containers, initContainers, volumes, volumeMounts, env, hostAliases, serviceAccountName; the name field represents the name of the side car, is in a character string format, is an optional field and is used as a unique identifier of the side car; the other fields are specific information of the side car and are optional fields;
the contacts field: the Container contained by the sidecar can contain a plurality of containers in a Container v1 core format;
initcontrollers field: the side car contains initial containers which can contain a plurality of initial containers in a Container v1 core format;
the volumes field: the side car contains volumes which can contain a plurality of volumes and are in a Volume v1 core format;
the volumeMounts field: the side car comprises a plurality of coil mounts which are in VolumeMount v1 core format;
env field: the side car contains environment variables which can contain a plurality of environment variables in EnvVar v1 core format;
the hostAliases field: the side car contains a host alias which can contain a plurality of host aliases and is in the HostAlias v1 core format;
the serviceAccountName field: the service account name contained in the side car is in a character string format.
The step 3 further comprises the following steps:
step 31, writing annotation key value pairs for designating the addition of the sidecar into the Pod resource object description file, wherein the key designates an annotation name space for adding the sidecar for the Pod resource object, namely a preset parameter of an automatic sidecar adder, and the value is the name of the sidecar; specific writing methods for designating annotation key value pairs for adding side vehicles are as follows:
< annotation namespace of Pod resource object specified add side cart >/request: side cart 1; a sidecar 2; ... A plurality of side vehicles can be specified in the values of the side vehicle n annotation key value pairs, and the side vehicles are separated by semicolon;
step 32, the original MutingAdmission Webhook controller in the Kubernetes cluster recognizes a creation event of the Pod resource object, and invokes the automatic sidecar adder service to add sidecars for the Pod resource object;
step 33, the automatic side car adder analyzes the transmitted request into a Pod resource object description file, identifies the annotation key value pair of the appointed side car, searches side car information according to the name of the side car, adds the side car information to the Pod resource object description file according to a specified field merging rule if the side car information exists, and constructs a response of the modified Pod resource object description file to be returned to the multiplexing Webhook controller; the automatic side car adder adds a plurality of side car information to the Pod resource object description file from left to right according to the value of the appointed side car annotation key value pair; when the side car information is successfully added, the automatic side car adder adds an annotation key value pair of a Pod resource object description file, which indicates that the side car information is successfully added, and the specific writing method is as follows:
< Pod resource object specifies annotation namespace of added edge >/inserted: true.
The field merging rule in the step 33 is:
the contacts field: merging with the spec.containers field of the Pod resource object, if a rename container exists, reporting errors and discarding merging;
initcontrollers field: merging with the spec.initContainers field of the Pod resource object, if a rename initial container exists, reporting errors and discarding merging;
the volumes field: merging with the spec.volumes field of the Pod resource object, if a rename volume exists, reporting errors and discarding merging;
the volumeMounts field: merging with spec. Containers, volume modules and spec. Initcon modules of the Pod resource object respectively, and if the Pod resource object has a mount of a rename volume, not replacing the Pod resource object;
env field: merging with spec. Containers [. Times ]. Env and spec. Initcon tains [. Times ]. Env fields of the Pod resource object respectively, and if a renamed environment variable exists, not replacing;
the hostAliases field: merging with the spec.hostaliases field of the Pod resource object, even if there is a duplicate ip field;
the serviceAccountName field: if the spec.serviceaccountname field of the Pod resource object is null or default, replacing, otherwise, not replacing.
The beneficial effects of the invention are as follows: the invention creates the automatic sidecar adder based on the access control mechanism of the Kubernetes, which can enable sidecar information to be added to the Pod resource object according to annotations before the Pod resource object is persisted to the Kubernetes cluster, and finally the Pod resource object added with the sidecar is persisted to the Kubernetes cluster and started.
Drawings
FIG. 1 is a flow diagram of a method for automatically adding an agent based on a container cloud in accordance with the present invention;
FIG. 2 is a deployment diagram of a method for automatically adding agents based on container clouds in an embodiment of the invention;
fig. 3 is a format example of side car information in the embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the following detailed description of the specific embodiments of the present invention is provided with reference to the accompanying drawings.
Referring to fig. 1 and 2, the invention provides a method for automatically adding an agent based on a container cloud, which comprises the following operation steps:
step 1, creating and initializing an automatic side car adder to enter a Kubernetes cluster;
step 2, after the automatic side car adder is initialized successfully, a ConfigMap resource object containing side car information is deployed in a Kubernetes cluster, and the automatic side car adder monitors the ConfigMap resource object in the Kubernetes and stores the side car information contained in the ConfigMap resource object;
and 3, creating a Pod resource object to the Kubernetes cluster, and before the Pod resource object is persisted to the Kubernetes cluster, if the automatic sidecar adder stores the sidecar appointed by the Pod resource object, modifying the Pod resource object description file and adding appointed sidecar information to the Pod resource object description file.
The step 1 further comprises the following steps:
step 11, configuring public key and private key certificates required by TLS connection for the automatic side car adder, and having a service account number for monitoring ConfigMap resource object authority, namely a ServiceAccount resource object;
step 12, deploying a Deployment and Service resource object, designating parameters of an automatic side car adder, and starting an automatic side car adder Service, wherein the parameters of the automatic side car adder comprise: the label key value pair which can be met by the monitored ConfigMap resource object and the Pod resource object are assigned to add the annotation name space of the side car;
the embodiment designates a label key value pair that can be satisfied by a monitorable ConfigMap resource object: app=sidecar, then a ConfigMap resource object that satisfies the "app=sidecar" tab key value pair would be monitored by the automated sidecar adder.
The present embodiment specifies that the Pod resource object specifies adding the annotation namespaces of the sidecar: the side car, then the key contains an annotation key value pair of "side car" whose value specifies the added sidecar name for the Pod resource object.
And step 13, configuring event matching rules for creating the Pod resource object, service references of the automatic side car adder and CA certificates for verifying TLS connection of the automatic side car adder service by deploying the MutingWebHookconfiguration resource object.
In the step 2, the automatic side car adder monitors the ConfigMap resource object in the Kubernetes and stores the specific content of the side car information contained in the ConfigMap resource object as follows:
the automatic side car adder monitors ConfigMap resource objects meeting corresponding label key value pairs (preset parameters of the automatic side car adder), if the data of the ConfigMap resource objects meet the format of side car information, the ConfigMap resource objects are stored, and the name of the side car is used as a unique identification of the side car;
an example of the format of the side car information is shown in fig. 3, and the side car information includes the following fields: name, containers, initContainers, volumes, volumeMounts, env, hostAliases, serviceAccountName; the name field represents the name of the side car, is in a character string format, is an optional field and is used as a unique identifier of the side car; the other fields are specific information of the side car and are optional fields;
the contacts field: the Container contained by the sidecar can contain a plurality of containers in a Container v1 core format;
initcontrollers field: the side car contains initial containers which can contain a plurality of initial containers in a Container v1 core format;
the volumes field: the side car contains volumes which can contain a plurality of volumes and are in a Volume v1 core format;
the volumeMounts field: the side car comprises a plurality of coil mounts which are in VolumeMount v1 core format;
env field: the side car contains environment variables which can contain a plurality of environment variables in EnvVar v1 core format;
the hostAliases field: the side car contains a host alias which can contain a plurality of host aliases and is in the HostAlias v1 core format;
the serviceAccountName field: the service account name contained in the side car is in a character string format.
The step 3 further comprises the following steps:
step 31, writing annotation key value pairs for designating the addition of the sidecar into the Pod resource object description file, wherein the key designates an annotation name space for adding the sidecar for the Pod resource object, namely a preset parameter of an automatic sidecar adder, and the value is the name of the sidecar; specific writing methods for designating annotation key value pairs for adding side vehicles are as follows:
< annotation namespace of Pod resource object specified add side cart >/request: side cart 1; a sidecar 2; ... A plurality of side vehicles can be specified in the values of the side vehicle n annotation key value pairs, and the side vehicles are separated by semicolon;
in this embodiment, the annotation key pair is: sidecar/request: sidecar1; sidecar2, i.e., the sidecar designated add names sidecar1 and sidecar 2.
Step 32, the original MutingAdmission Webhook controller in the Kubernetes cluster recognizes a creation event of the Pod resource object, and invokes the automatic sidecar adder service to add sidecars for the Pod resource object;
step 33, the automatic side car adder analyzes the transmitted request into a Pod resource object description file, identifies the annotation key value pair of the appointed side car, searches side car information according to the name of the side car, adds the side car information to the Pod resource object description file according to a specified field merging rule if the side car information exists, and constructs a response of the modified Pod resource object description file to be returned to the multiplexing Webhook controller;
the automatic side car adder adds a plurality of side car information to the Pod resource object description file from left to right according to the value of the appointed side car annotation key value pair; when the side car information is successfully added, the automatic side car adder adds an annotation key value pair of a Pod resource object description file, which indicates that the side car information is successfully added, and the specific writing method is as follows:
< annotation namespace of Pod resource object specified added edge vehicle >/inserted: true
In this embodiment, the annotation key pair is: sidecar/inserted, true.
The field merging rule in the step 33 is:
the contacts field: merging with the spec.containers field of the Pod resource object, if a rename container exists, reporting errors and discarding merging;
initcontrollers field: merging with the spec.initContainers field of the Pod resource object, if a rename initial container exists, reporting errors and discarding merging;
the volumes field: merging with the spec.volumes field of the Pod resource object, if a rename volume exists, reporting errors and discarding merging;
the volumeMounts field: merging with spec. Containers, volume modules and spec. Initcon modules of the Pod resource object respectively, and if the Pod resource object has a mount of a rename volume, not replacing the Pod resource object;
env field: merging with spec.containers [ ] env and spec.initcon tainas [ ] env fields of the Pod resource object (the environment variables of each container and the initial container of the Pod resource object), respectively, and if there is a renamed environment variable, not replacing;
the hostAliases field: merging with the spec.hostaliases field of the Pod resource object, even if there is a duplicate ip field;
the serviceAccountName field: if the spec.serviceaccountname field of the Pod resource object is null or default, the Pod resource object is replaced (corresponding replacement will occur for the volume and the volume mount related to the service account number, otherwise, the Pod resource object is not replaced.
The inventor performs a large number of experiments on the method, and experimental results prove that the method effectively solves the problems of data redundancy and low efficiency caused by manually adding a large amount of repeated side car information.
Claims (5)
1. A method for automatically adding agents based on container cloud, comprising the following operation steps:
step 1, creating and initializing an automatic side car adder to enter a Kubernetes cluster;
step 2, after the automatic side car adder is initialized successfully, a ConfigMap resource object containing side car information is deployed in a Kubernetes cluster, and the automatic side car adder monitors the ConfigMap resource object in the Kubernetes and stores the side car information contained in the ConfigMap resource object;
and 3, creating a Pod resource object to the Kubernetes cluster, and before the Pod resource object is persisted to the Kubernetes cluster, if the automatic sidecar adder stores the sidecar appointed by the Pod resource object, modifying the Pod resource object description file and adding appointed sidecar information to the Pod resource object description file.
2. The method for automatically adding agents based on container cloud as claimed in claim 1, wherein said step 1 further comprises:
step 11, configuring public key and private key certificates required by TLS connection for the automatic side car adder, and having a service account number for monitoring ConfigMap resource object authority, namely a ServiceAccount resource object;
step 12, deploying a Deployment and Service resource object, designating parameters of an automatic side car adder, and starting an automatic side car adder Service, wherein the parameters of the automatic side car adder comprise: the label key value pair which can be met by the monitored ConfigMap resource object and the Pod resource object are assigned to add the annotation name space of the side car;
and step 13, configuring event matching rules for creating the Pod resource object, service references of the automatic side car adder and CA certificates for verifying TLS connection of the automatic side car adder service by deploying the MutingWebHookconfiguration resource object.
3. The method for automatically adding an agent based on a container cloud according to claim 1, wherein the automatic sidecar adder in step 2 monitors a ConfigMap resource object in Kubernetes and stores the sidecar information contained in the ConfigMap resource object as follows:
the automatic side car adder monitors ConfigMap resource objects meeting corresponding label key value pairs, if the data of the ConfigMap resource objects meet the format of side car information, the ConfigMap resource objects are stored, and the name of the side car is used as the unique identifier of the side car; the side car information contains the following fields: name, containers, initContainers, volumes, volumeMounts, env, hostAliases, serviceAccountName; the name field represents the name of the side car, is in a character string format, is an optional field and is used as a unique identifier of the side car; the other fields are specific information of the side car and are optional fields;
the contacts field: the Container contained by the sidecar can contain a plurality of containers in a Container v1 core format;
initcontrollers field: the side car contains initial containers which can contain a plurality of initial containers in a Container v1 core format;
the volumes field: the side car contains volumes which can contain a plurality of volumes and are in a Volume v1 core format;
the volumeMounts field: the side car comprises a plurality of coil mounts which are in VolumeMount v1 core format;
env field: the side car contains environment variables which can contain a plurality of environment variables in EnvVar v1 core format;
the hostAliases field: the side car contains a host alias which can contain a plurality of host aliases and is in the HostAlias v1 core format;
the serviceAccountName field: the service account name contained in the side car is in a character string format.
4. The method for automatically adding an agent based on a container cloud as claimed in claim 1, wherein said step 3 further comprises:
step 31, writing annotation key value pairs for designating the addition of the sidecar into the Pod resource object description file, wherein the key designates an annotation name space for adding the sidecar for the Pod resource object, namely a preset parameter of an automatic sidecar adder, and the value is the name of the sidecar; specific writing methods for designating annotation key value pairs for adding side vehicles are as follows:
< annotation namespace of Pod resource object specified add side cart >/request: side cart 1; a sidecar 2; ... A plurality of side vehicles can be specified in the values of the side vehicle n annotation key value pairs, and the side vehicles are separated by semicolon;
step 32, the original MutingAdmission Webhook controller in the Kubernetes cluster recognizes a creation event of the Pod resource object, and invokes the automatic sidecar adder service to add sidecars for the Pod resource object;
step 33, the automatic side car adder analyzes the transmitted request into a Pod resource object description file, identifies the annotation key value pair of the appointed side car, searches side car information according to the name of the side car, adds the side car information to the Pod resource object description file according to a specified field merging rule if the side car information exists, and constructs a response of the modified Pod resource object description file to be returned to the multiplexing Webhook controller; the automatic side car adder adds a plurality of side car information to the Pod resource object description file from left to right according to the value of the appointed side car annotation key value pair; when the side car information is successfully added, the automatic side car adder adds an annotation key value pair of a Pod resource object description file, which indicates that the side car information is successfully added, and the specific writing method is as follows:
< Pod resource object specifies annotation namespace of added edge >/inserted: true.
5. The method for automatically adding an agent based on a container cloud as recited in claim 4, wherein the field merging rule in step 33 is:
the contacts field: merging with the spec.containers field of the Pod resource object, if a rename container exists, reporting errors and discarding merging;
initcontrollers field: merging with the spec.initContainers field of the Pod resource object, if a rename initial container exists, reporting errors and discarding merging;
the volumes field: merging with the spec.volumes field of the Pod resource object, if a rename volume exists, reporting errors and discarding merging;
the volumeMounts field: merging with spec. Containers, volume modules and spec. Initcon modules of the Pod resource object respectively, and if the Pod resource object has a mount of a rename volume, not replacing the Pod resource object;
env field: merging with spec. Containers [. Times ]. Env and spec. Initcon tains [. Times ]. Env fields of the Pod resource object respectively, and if a renamed environment variable exists, not replacing;
the hostAliases field: merging with the spec.hostaliases field of the Pod resource object, even if there is a duplicate ip field;
the serviceAccountName field: if the spec.serviceaccountname field of the Pod resource object is null or default, replacing, otherwise, not replacing.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111551795.1A CN114221773B (en) | 2021-12-17 | 2021-12-17 | Method for automatically adding agent based on container cloud |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111551795.1A CN114221773B (en) | 2021-12-17 | 2021-12-17 | Method for automatically adding agent based on container cloud |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114221773A CN114221773A (en) | 2022-03-22 |
| CN114221773B true CN114221773B (en) | 2024-02-06 |
Family
ID=80703595
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111551795.1A Active CN114221773B (en) | 2021-12-17 | 2021-12-17 | Method for automatically adding agent based on container cloud |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114221773B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110262899A (en) * | 2019-06-20 | 2019-09-20 | 无锡华云数据技术服务有限公司 | Monitor component elastic telescopic method, apparatus and controlled terminal based on Kubernetes cluster |
| CN110535831A (en) * | 2019-07-30 | 2019-12-03 | 平安科技（深圳）有限公司 | Cluster safety management method, device and storage medium based on Kubernetes and network domains |
| CN111212129A (en) * | 2019-12-30 | 2020-05-29 | 北京浪潮数据技术有限公司 | Container application high-availability method, device and equipment based on side car mode |
| CN111865971A (en) * | 2020-07-17 | 2020-10-30 | 成都三零凯天通信实业有限公司 | Kubernetes service container security detection method based on sidecar scheme |
| WO2020253347A1 (en) * | 2019-06-17 | 2020-12-24 | 深圳前海微众银行股份有限公司 | Container cluster management method, device and system |
| CN112506617A (en) * | 2020-12-16 | 2021-03-16 | 新浪网技术(中国)有限公司 | Mirror image updating method and device for sidecar container in Kubernetes cluster |
| CN112596762A (en) * | 2020-12-16 | 2021-04-02 | 中国建设银行股份有限公司 | Rolling upgrading method and device |
| CN112929180A (en) * | 2021-02-05 | 2021-06-08 | 中国—东盟信息港股份有限公司 | Kubernetes zero trust network security system and implementation method thereof |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11249856B2 (en) * | 2018-10-25 | 2022-02-15 | EMC IP Holding Company LLC | Application consistent snapshots as a sidecar of a containerized application |
| US10715388B2 (en) * | 2018-12-10 | 2020-07-14 | Sap Se | Using a container orchestration service for dynamic routing |
-
2021
- 2021-12-17 CN CN202111551795.1A patent/CN114221773B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020253347A1 (en) * | 2019-06-17 | 2020-12-24 | 深圳前海微众银行股份有限公司 | Container cluster management method, device and system |
| CN110262899A (en) * | 2019-06-20 | 2019-09-20 | 无锡华云数据技术服务有限公司 | Monitor component elastic telescopic method, apparatus and controlled terminal based on Kubernetes cluster |
| CN110535831A (en) * | 2019-07-30 | 2019-12-03 | 平安科技（深圳）有限公司 | Cluster safety management method, device and storage medium based on Kubernetes and network domains |
| CN111212129A (en) * | 2019-12-30 | 2020-05-29 | 北京浪潮数据技术有限公司 | Container application high-availability method, device and equipment based on side car mode |
| CN111865971A (en) * | 2020-07-17 | 2020-10-30 | 成都三零凯天通信实业有限公司 | Kubernetes service container security detection method based on sidecar scheme |
| CN112506617A (en) * | 2020-12-16 | 2021-03-16 | 新浪网技术(中国)有限公司 | Mirror image updating method and device for sidecar container in Kubernetes cluster |
| CN112596762A (en) * | 2020-12-16 | 2021-04-02 | 中国建设银行股份有限公司 | Rolling upgrading method and device |
| CN112929180A (en) * | 2021-02-05 | 2021-06-08 | 中国—东盟信息港股份有限公司 | Kubernetes zero trust network security system and implementation method thereof |
Non-Patent Citations (2)
| Title |
|---|
| 一种面向异常传播的微服务故障诊断方法;王焘;《计算机科学》;全文 * |
| 基于云原生的5G核心网演进解决方案研究;李铭轩;童俊杰;刘秋妍;;信息通信技术(第01期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114221773A (en) | 2022-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2022022477A1 (en) | Management operation and maintenance platform and data processing method | |
| US8667482B2 (en) | Automated application modeling for application virtualization | |
| CN113508403A (en) | System and method for interoperable communication of automation system components with multiple information sources | |
| JP5265549B2 (en) | Consolidated Discovery Web Service | |
| EP2442489A1 (en) | Distributed management monitoring system, monitoring method and creating method thereof | |
| US20140136809A1 (en) | Storage black box | |
| US9146813B2 (en) | Presenting a file system for a file containing items | |
| CN107797767A (en) | One kind is based on container technique deployment distributed memory system and its storage method | |
| CN104731943A (en) | Server and data processing method | |
| CN114995841B (en) | Method and system for realizing database cloud service upgrade | |
| CN105635311A (en) | Method for synchronizing resource pool information in cloud management platform | |
| CN102202087A (en) | Method for identifying storage equipment and system thereof | |
| CN113468221A (en) | System integration method based on kafka message data bus | |
| CN113937894A (en) | Cloud edge cooperation-based electric intelligent terminal management system and method | |
| CN113486095A (en) | Civil aviation air traffic control cross-network safety data exchange management platform | |
| CN114374701B (en) | Transparent sharing device for sample model of multistage linkage artificial intelligent platform | |
| CN114221773B (en) | Method for automatically adding agent based on container cloud | |
| CN114866416A (en) | Multi-cluster unified management system and deployment method | |
| CN106202585B (en) | The more scene Multi-state data systems of electric power and management method | |
| CN113641760A (en) | Data synchronization method and device | |
| CN114024822A (en) | Block chain-based Internet of things equipment management method, equipment, server and medium | |
| CN109947451A (en) | A kind of cluster application file updating method, system, medium and equipment | |
| US20240007876A1 (en) | Restoration of a network slice | |
| CN109167826A (en) | The restocking method, apparatus and system of WEB application | |
| CN115801811B (en) | Cloud edge cooperation method and device |
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 |