CN111339118A - Kubernetes-based resource change history recording method and device - Google Patents
Kubernetes-based resource change history recording method and device Download PDFInfo
- Publication number
- CN111339118A CN111339118A CN202010227828.6A CN202010227828A CN111339118A CN 111339118 A CN111339118 A CN 111339118A CN 202010227828 A CN202010227828 A CN 202010227828A CN 111339118 A CN111339118 A CN 111339118A
- Authority
- CN
- China
- Prior art keywords
- kube
- apiserver
- incremental data
- data
- local database
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2358—Change logging, detection, and notification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/26—Visual data mining; Browsing structured data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a Kubernetes-based resource change history recording method and device, and the method comprises the following steps: based on a list-watch mechanism, maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster; accessing the kube-apiserver through the watch connection to obtain incremental data stored in the etcd; and storing the incremental data into a local database table. The method and the device can solve the problem that the operation of inquiring the resource change history of the Kubernets is complex, so that the quick response to the abnormity of the Kubernets cluster cannot be made.
Description
Technical Field
The application relates to the technical field of cloud computing, in particular to a Kubernetes-based resource change history recording method and device.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.
Kubernetes (k 8s for short) as an open source container scheduling platform across host clusters provides a container-centric infrastructure and has become a de facto standard in the field of container orchestration. As shown in fig. 1, is a block diagram of kubernets.
The core of kubernets project organization capability lies in the design and use of a declarative Application Programming Interface (API), see fig. 1, a user can acquire and change resource information by performing CRUD (abbreviation of Create, Retrieve, Update, and Delete) operation on an API group under a REST path. There are many resource types in kubernets, such as pods (minimum atomic scheduling unit), server (service), events, etc. In general, most users only concern about the type of resources, such as pod and service, which directly concern about the success of service operation, and only concern about the cluster operation information when the cluster is abnormal or the service deployment is abnormal and problem tracking is required.
Currently, recording of operation information inside a cluster is mainly performed through events. Events contain information generated by a core component kubbelet and a control manager (ControllerManager) in the running process of kubbernees, and analyzing the information contained in the Events and the history record of event resource change can effectively track the problem, so that the problem is solved with pertinence. It is currently seen in the industry that events is mainly performed by kubecect (binary executable file, which generates effect by accessing kube-api) commands, and specific commands such as kubecect events and kubecect descriptor [ resourceName ] can obtain the event content.
The manner of acquiring events is a command row level operation, and access cluster authority needs to be provided. Complicated parameters are required to be set for carrying out multi-condition matching when accurate events information is to be acquired, and the final query result is displayed unfriendly. For some specific requirements, such as querying the change of the corresponding pod name before and after upgrading of an application, multiple times of query manual matching are needed, and operation normalization is not easy to perform. Moreover, when tracing is needed for a complex fault, the debug operation performed by simply using a command line is complex, and certain challenges are brought to quick response and problem solving.
Disclosure of Invention
The embodiment of the application provides a resource change history recording method based on Kubernets, which is used for solving the problem that the operation of inquiring the resource change history of the Kubernets is complex, so that quick response to the abnormality of a Kubernets cluster cannot be made, and comprises the following steps:
based on a list-watch mechanism, maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster; accessing the kube-apiserver through the watch connection to obtain incremental data stored in the etcd; and storing the incremental data into a local database table.
An embodiment of the present application further provides a Kubernetes-based resource change history recording device, so as to solve a problem that an operation of querying a Kubernetes-based resource change history recording is complex, and thus a quick response to an anomaly of a Kubernetes cluster cannot be made, where the device includes:
the communication module is used for maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster based on a list-watch mechanism; the obtaining module is used for accessing the kube-apiserver connected with the communication module through the watch connection and obtaining incremental data stored in the etcd; and the storage module is used for storing the incremental data acquired by the acquisition module into a local database table.
In the embodiment of the application, based on a list-watch mechanism, incremental data of events are continuously acquired from etcd through a watch connection established with a kube-apiserver in a Kubernetes cluster, and the incremental data are stored in a local database table, and because the incremental data stored in the local database table comprise a resource version number corresponding to the incremental data, corresponding resources can be quickly associated and searched; the front end result is associated with the command line result. Moreover, data in the local database table can be stored for a long time, the resource change condition of Kubernets can be known through the resource version number of the incremental data acquired at different time, the problem of complex operation of inquiring the resource change history records of the Kubernets is solved, and quick response can be made to the abnormity of the Kubernets cluster.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts. In the drawings:
FIG. 1 is a block diagram of a Kubernets module of the prior art;
FIG. 2 is a schematic view of an events structure according to an embodiment of the present application;
fig. 3 is a flowchart of a resource change history recording method based on Kubernetes in an embodiment of the present application;
FIG. 4 is a schematic diagram illustrating a communication principle of a list-watch mechanism in an embodiment of the present application;
fig. 5 is a technical architecture diagram of a resource change history recording method based on Kubernetes in an embodiment of the present application;
fig. 6 is a schematic structural diagram of a resource change history recording apparatus based on Kubernetes in an embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the embodiments of the present application are further described in detail below with reference to the accompanying drawings. The exemplary embodiments and descriptions of the present application are provided herein to explain the present application and not to limit the present application.
The Kubelet start/stop pod and the controller manager manage the events generated when each controller works. The inventor of the present application finds that the events stored in etcd have the same structure, and refer to fig. 2, which is a schematic diagram of a complete event structure, and the event structure mainly comprises the following components:
①, kind is resource type;
②, name is the name of the resource;
③, namespace;
④, reason for failure;
⑤, message is event meaning;
⑥, resource, event generation site, including generation node and component;
⑦, firstTimestamp, the first occurrence timestamp of the same type of event;
⑧, lastTimestamp, the last time the same type of event occurred, the new event of the same type will update its lastTimestamp to this value;
⑨, count the number of occurrences of this type of event.
Indeed, the json structure of events contains the elements of the event: who, when, where, what, why. The course of variation can be derived by combining events of the same type and observing events produced at different times. All events are acquired and classified and stored, so that the content of the events occurring in the cluster can be clearly understood. Events data can be obtained by using an officially provided library, such as replacing a kubecect command to access the kube-API, and the complete events data can be obtained by directly calling an API (application programming interface) provided by the kube-API by using the officially provided library (such as https:// githu. com/kubernets/client-go).
The API in Kubernetes strictly follows RESTful API design, has no hidden internal API and can execute CRUD operation under the condition that the authority is satisfied, and the etcd stores all resources and cluster states in a cluster, and the pressure influence on the system needs to be considered when the details of the resources are acquired through the API, so that the real-time reliable transmission of data is ensured.
The data source of the method is storage of events inside kubernets, no additional event grouping classification is carried out, and no overhead caused by the event grouping classification is generated, so that the only important consideration is how to obtain data with low frequency and reliability, and no pressure is generated on a system.
Based on the above research results, an embodiment of the present application provides a resource change history recording method based on Kubernetes, and as shown in fig. 3, the method includes steps 301 to 303:
That is, after the watch connection is established with the kube-apiserver, the watch connection is maintained all the time to acquire newly added events data of the kubernets cluster through the watch connection, so that the data stored in the local database table and the events data in the kubernets cluster are kept synchronous.
In Kubernets, an asynchronous message processing mechanism list-watch mechanism (http streaming) is adopted between a server (club-api) and a client to complete message notification. Before maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster, firstly initiating a list operation request to the kube-apiserver to acquire the total data stored in the etcd, wherein the list operation relates to coding, decoding, sequencing and deserializing the data; and then, storing the full data into a local database. In order to identify the full-volume data which is obtained through the list operation and the incremental data stored in the etcd after the full-volume data is obtained, in the embodiment of the application, a watch request is sent to the kube-api server according to the latest resource version (ResourceVersion) in the full-volume data, and a watch connection with the kube-api server is established. And obtaining incremental data of the resource version updated by the data of the latest resource version in the full amount of data according to the difference of the resource versions. Therefore, in the subsequent process, the data written in the etcd only needs to be read in an increment mode through the watch connection, the updated data and the original data are not read out all at each time, and the pressure on the system is reduced.
It should be noted that, when the full data is stored in the local database table, the full data needs to be parsed to obtain the resource type and the name space of the incremental data, and the full data is stored in the local database table corresponding to the resource type and the name space, as in the operation of storing the incremental data in the local database table in step 103.
In an implementation manner of the embodiment of the present application, when the full amount of data is stored, a local database table corresponding to the resource type and the name space may not exist in the local database, and then the local database table may be established according to the resource type and the name space, and then the full amount of data and the subsequently acquired incremental data are stored in the corresponding local database table.
Considering that a fetch error may be caused by network flash or data asynchronism between the server-api server and the resource change history recording device, when the fetch error does not obtain the incremental data stored in the etcd, a list operation request is sent to the server-api server again, and the full data stored in the etcd is obtained again; and then, restarting the watch request according to the latest resource version in the retrieved full data. That is, after the fetch request fails, the connection with the server is established again through the list-fetch mechanism. As shown in fig. 4, which is a schematic diagram of a communication principle of a list-watch mechanism, when a Client (i.e., a resource change history device) sends a Request to a Server (a Server kube-observer) based on a latest resource version (rv is 3, rv is used to represent the resource version) and does not accept the response, the Client requests to re-acquire full data including a latest version number 4, and if the Client fails to obtain the response after the watch Request is sent, the Client waits for the repeated list Request to acquire the latest version number and sends a watch Request based on the latest version number until the watch Request is responded.
And step 302, accessing the kube-apiserver through the watch connection, and obtaining the incremental data stored in the etcd.
In the embodiment of the application, after the watch connection is established, the action of storing incremental data in the etcd can be automatically sensed, and after the incremental data is stored in the etcd, which part of data in the data stored in the etcd is the incremental data can be determined according to the latest resource version of the full amount of data stored in the local database table.
And step 303, storing the incremental data into a local database table.
The local database table may be a local mysql table, or other available local database.
Specifically, storing the incremental data in the local database table may be performed as: analyzing the incremental data according to a preset analysis rule to obtain the resource type and the name space of the incremental data; and storing the incremental data into a local database table corresponding to the resource type and the name space, wherein the incremental data of the same resource type are stored into the corresponding local database table according to the sequence of the version type values from small to large.
The name of the field to be acquired is defined in the preset parsing rule, for example, the field name of the resource type to be acquired is defined in the preset parsing rule as "kid", and after the field parsing is performed on the incremental data, data corresponding to the field "kid" is extracted from the parsed data, and the obtained data is the resource type. The user may define the preset parsing rule according to the requirement, and the type and number of the fields defined in the preset parsing rule are not limited herein.
Different local database tables are divided by taking the resource type and the name space as a joint, so that the resource searching mode of the local database table is consistent with the resource searching mode in kubernets, and a user of the kubernets can conveniently check data in the local database tables. Illustratively, the following table one shows the structural design of the default pod table in mysql:
After the incremental data are stored in the local database table, the incremental data can be read from the local database table and visually displayed. Specifically, charts such as event failure frequency reasons and the like can be drawn through technologies such as nginx + flash (python)/echo (go) + echarts, ajax and the like, data can be visually displayed on a panel, and the data can also be directly displayed in a grafana adapting mode, so that a user can more intuitively and clearly view resource change details of the Kubernetes cluster.
The technique of the present application is divided into two parts, which may be referred to as watchParser and mirror, respectively.
As shown in fig. 5, the WatchParser is mainly responsible for the above watch operation on the kube-apiserver resource and the parsing of the obtained data, and during the watch and data parsing process, a kubernets official package client-go is mainly used and runs inside the kubernets cluster in a container or kubernets pod form, so that the operations required for establishing connection and security interaction with the kube-apiserver are reduced. And continuously acquiring events data from the kube-apiserver through a list-watch mechanism.
Mirror is mainly responsible for reading out data from mysql and displaying the data visually.
While the incremental data are displayed visually, notification can be set, and notification can be performed through a display interface prompt or channels of short messages, social software and the like in the terminal, so that information can be fed back to a technician at the first time of acquiring the dangerous event, and the technician can perform tracking and troubleshooting quickly and efficiently. Compared with the existing command line mode for acquiring the details of events, the technology expands the acquiring and displaying modes of events, and can be applied to scenes of monitoring and analyzing kubernets resources.
In the embodiment of the application, based on a list-watch mechanism, incremental data of events are continuously acquired from etcd through a watch connection established with a kube-apiserver in a Kubernetes cluster, and the incremental data are stored in a local database table, and because the incremental data stored in the local database table comprise a resource version number corresponding to the incremental data, corresponding resources can be quickly associated and searched; the front end result is associated with the command line result. Moreover, data in the local database table can be stored for a long time, the resource change condition of Kubernets can be known through the resource version number of the incremental data acquired at different time, the problem of complex operation of inquiring the resource change history records of the Kubernets is solved, and quick response can be made to the abnormity of the Kubernets cluster.
The embodiment of the present application provides a Kubernetes-based resource change history recording apparatus, and as shown in fig. 6, the apparatus 600 includes a communication module 601, an obtaining module 602, and a storage module 603.
The communication module 601 is configured to maintain an established watch connection with a kube-apiserver in a Kubernetes cluster based on a list-watch mechanism.
An obtaining module 602, configured to access the kube-apiserver connected to the communication module 601 through the watch connection, and obtain the incremental data stored in the etcd.
The storing module 603 is configured to store the incremental data obtained by the obtaining module 602 into a local database table.
In an implementation manner of the embodiment of the present application, the communication module 601 is further configured to initiate a list operation request to the kube-apiserver.
The obtaining module 602 is further configured to obtain the full amount of data stored in the etcd.
The storage module 603 is further configured to store the full amount of data in the local database;
the communication module 601 is further configured to initiate a fetch request to the kube-apiserver according to the latest resource version in the full-volume data acquired by the acquisition module 602, and establish a fetch connection with the kube-apiserver.
In an implementation manner of the embodiment of the present application, when the watch connection with the kube-apiserver is not established, the communication module 601 is further configured to:
initiating a list operation request to the kube-apiserver again, and obtaining the full data stored in the etcd again;
and reinitiating the fetch request according to the latest resource version in the retrieved full amount of data.
In an implementation manner of the embodiment of the present application, the storage module 603 is configured to:
analyzing the incremental data according to a preset analysis rule to obtain the resource type and the name space of the incremental data;
and storing the incremental data into a local database table corresponding to the resource type and the name space, wherein the incremental data of the same resource type are stored into the corresponding local database table according to the sequence of the version type values from small to large.
In an implementation manner of the embodiment of the present application, the apparatus 600 further includes:
and the display module 604 is configured to read the incremental data from the local database table and visually display the incremental data.
In the embodiment of the application, based on a list-watch mechanism, incremental data of events are continuously acquired from etcd through a watch connection established with a kube-apiserver in a Kubernetes cluster, and the incremental data are stored in a local database table, and because the incremental data stored in the local database table comprise a resource version number corresponding to the incremental data, corresponding resources can be quickly associated and searched; the front end result is associated with the command line result. Moreover, data in the local database table can be stored for a long time, the resource change condition of Kubernets can be known through the resource version number of the incremental data acquired at different time, the problem of complex operation of inquiring the resource change history records of the Kubernets is solved, and quick response can be made to the abnormity of the Kubernets cluster.
The embodiment of the present application further provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the processor implements any of the methods described in steps 301 to 303 and various implementations thereof.
The embodiment of the present application further provides a computer-readable storage medium, where a computer program for executing any one of the methods described in steps 301 to 303 and various implementation manners thereof is stored in the computer-readable storage medium.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The above-mentioned embodiments are further described in detail for the purpose of illustrating the invention, and it should be understood that the above-mentioned embodiments are only illustrative of the present invention and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (12)
1. A resource change history recording method based on Kubernetes is characterized by comprising the following steps:
based on a list-watch mechanism, maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster;
accessing the kube-apiserver through the watch connection to obtain incremental data stored in the etcd;
and storing the incremental data into a local database table.
2. The method of claim 1, wherein prior to maintaining the established watch connection with the kube-apiserver in the kubernets cluster, the method further comprises:
initiating a list operation request to the kube-apiserver to obtain the total data stored in the etcd;
storing the full data into a local database table;
and according to the latest resource version in the full data, initiating a fetch request to the kube-apiserver, and establishing a fetch connection with the kube-apiserver.
3. The method of claim 2, wherein if a watch connection with the kube-apiserver is not established, the method further comprises:
initiating a list operation request to the kube-apiserver again, and obtaining the full data stored in the etcd again;
and reinitiating the fetch request according to the latest resource version in the retrieved full amount of data.
4. The method of claim 1, wherein storing the incremental data in a local database table comprises:
analyzing the incremental data according to a preset analysis rule to obtain the resource type and the name space of the incremental data;
and storing the incremental data into a local database table corresponding to the resource type and the name space, wherein the incremental data of the same resource type are stored into the corresponding local database table according to the sequence of the version type values from small to large.
5. The method of any of claims 1 to 4, wherein after storing the incremental data in a local database table, the method further comprises:
and reading the incremental data from a local database table, and visually displaying the incremental data.
6. A Kubernetes-based resource change history recording apparatus, comprising:
the communication module is used for maintaining the established watch connection with the kube-apiserver in the Kubernetes cluster based on a list-watch mechanism;
the obtaining module is used for accessing the kube-apiserver connected with the communication module through the watch connection and obtaining incremental data stored in the etcd;
and the storage module is used for storing the incremental data acquired by the acquisition module into a local database table.
7. The apparatus of claim 6,
the communication module is also used for initiating a list operation request to the kube-apiserver;
the obtaining module is further configured to obtain the full amount of data stored in the etcd;
the storage module is also used for storing the full data into a local database;
the communication module is further configured to initiate a fetch request to the kube-apiserver according to the latest resource version in the full-volume data acquired by the acquisition module, and establish a fetch connection with the kube-apiserver.
8. The apparatus of claim 7, wherein the communication module, when the watch connection with the kube-apiserver is not established, is further configured to:
initiating a list operation request to the kube-apiserver again, and obtaining the full data stored in the etcd again;
and reinitiating the fetch request according to the latest resource version in the retrieved full amount of data.
9. The apparatus of claim 6, wherein the storage module is configured to:
analyzing the incremental data according to a preset analysis rule to obtain the resource type and the name space of the incremental data;
and storing the incremental data into a local database table corresponding to the resource type and the name space, wherein the incremental data of the same resource type are stored into the corresponding local database table according to the sequence of the version type values from small to large.
10. The apparatus of any one of claims 6 to 9, further comprising:
and the display module is used for reading the incremental data from the local database table and visually displaying the incremental data.
11. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 5 when executing the computer program.
12. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program for executing the method of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010227828.6A CN111339118A (en) | 2020-03-27 | 2020-03-27 | Kubernetes-based resource change history recording method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010227828.6A CN111339118A (en) | 2020-03-27 | 2020-03-27 | Kubernetes-based resource change history recording method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111339118A true CN111339118A (en) | 2020-06-26 |
Family
ID=71182791
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010227828.6A Pending CN111339118A (en) | 2020-03-27 | 2020-03-27 | Kubernetes-based resource change history recording method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111339118A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112035123A (en) * | 2020-08-28 | 2020-12-04 | 北京浪潮数据技术有限公司 | Method for realizing no server based on kubernets platform |
| CN112860435A (en) * | 2021-01-29 | 2021-05-28 | 西藏宁算科技集团有限公司 | Method for solving edge node availability in 5G scene |
| CN114221958A (en) * | 2021-12-10 | 2022-03-22 | 云控智行科技有限公司 | High-precision map data increment distribution method and device and electronic equipment |
| CN114938378A (en) * | 2022-04-22 | 2022-08-23 | 新华智云科技有限公司 | Resource filtering method, system, equipment and storage medium based on kubernets |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015074467A1 (en) * | 2013-11-25 | 2015-05-28 | 腾讯科技（深圳）有限公司 | Data update method, apparatus, and system and storage medium |
| CN108900651A (en) * | 2018-06-22 | 2018-11-27 | 杭州才云科技有限公司 | Kubernetes and Neutron interconnection method, storage medium, equipment based on multi-tenant environment |
| CN109067828A (en) * | 2018-06-22 | 2018-12-21 | 杭州才云科技有限公司 | Based on the more cluster construction methods of Kubernetes and OpenStack container cloud platform, medium, equipment |
| CN109918268A (en) * | 2019-03-05 | 2019-06-21 | 北京达佳互联信息技术有限公司 | System compatible method, apparatus, equipment and computer readable storage medium |
| CN110837407A (en) * | 2018-08-15 | 2020-02-25 | 阿里巴巴集团控股有限公司 | Server-free cloud service system, resource management method thereof and electronic equipment |
-
2020
- 2020-03-27 CN CN202010227828.6A patent/CN111339118A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015074467A1 (en) * | 2013-11-25 | 2015-05-28 | 腾讯科技（深圳）有限公司 | Data update method, apparatus, and system and storage medium |
| CN108900651A (en) * | 2018-06-22 | 2018-11-27 | 杭州才云科技有限公司 | Kubernetes and Neutron interconnection method, storage medium, equipment based on multi-tenant environment |
| CN109067828A (en) * | 2018-06-22 | 2018-12-21 | 杭州才云科技有限公司 | Based on the more cluster construction methods of Kubernetes and OpenStack container cloud platform, medium, equipment |
| CN110837407A (en) * | 2018-08-15 | 2020-02-25 | 阿里巴巴集团控股有限公司 | Server-free cloud service system, resource management method thereof and electronic equipment |
| CN109918268A (en) * | 2019-03-05 | 2019-06-21 | 北京达佳互联信息技术有限公司 | System compatible method, apparatus, equipment and computer readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 元乙: "Kubernetes可观察性：全方位事件监控", 《阿里开发者社区》 * |
| 新胜: "kubernetes设计理念分析 | 从运行流程和list-watch看kubernetes系统的设计理念", 《阿里云云原生》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112035123A (en) * | 2020-08-28 | 2020-12-04 | 北京浪潮数据技术有限公司 | Method for realizing no server based on kubernets platform |
| CN112860435A (en) * | 2021-01-29 | 2021-05-28 | 西藏宁算科技集团有限公司 | Method for solving edge node availability in 5G scene |
| CN114221958A (en) * | 2021-12-10 | 2022-03-22 | 云控智行科技有限公司 | High-precision map data increment distribution method and device and electronic equipment |
| CN114938378A (en) * | 2022-04-22 | 2022-08-23 | 新华智云科技有限公司 | Resource filtering method, system, equipment and storage medium based on kubernets |
| CN114938378B (en) * | 2022-04-22 | 2023-06-27 | 新华智云科技有限公司 | Resource filtering method, system, equipment and storage medium based on kubernetes |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111339118A (en) | Kubernetes-based resource change history recording method and device | |
| EP3543837A1 (en) | Inadvertent input mitigation in robotic process automation | |
| US10528456B2 (en) | Determining idle testing periods | |
| CN112650676A (en) | Software testing method, device, equipment and storage medium | |
| CN111930489A (en) | Task scheduling method, device, equipment and storage medium | |
| CN106649000B (en) | Fault recovery method of real-time processing engine and corresponding server | |
| CN112416803A (en) | Automatic testing method and device | |
| CN112540808B (en) | Recording method of program behavior hierarchy call relationship and related equipment | |
| CN112559525B (en) | Data checking system, method, device and server | |
| CN111752838A (en) | Question checking method and device, server and storage medium | |
| CN117271584A (en) | Data processing method and device, computer readable storage medium and electronic equipment | |
| CN111752918A (en) | Historical data interaction system and configuration method thereof | |
| CN111200654A (en) | Client request error processing method and device | |
| KR101346835B1 (en) | Method and appratus for processing error of application | |
| CN115757045A (en) | Transaction log analysis method, system and device | |
| CN114021756A (en) | Fault analysis method and device and electronic equipment | |
| CN109144788B (en) | Method, device and system for reconstructing OSD | |
| CN111866576A (en) | On-line problem processing system and method | |
| CN112115118A (en) | Database pressure measurement optimization method and device, storage medium and electronic equipment | |
| CN110597603A (en) | Scheduling method and system of distributed scheduling tasks | |
| CN111654410B (en) | Gateway request monitoring method, device, equipment and medium | |
| CN113553197B (en) | Data processing method, device and readable storage medium | |
| CN117077592B (en) | Regression data monitoring method, monitoring device and monitoring system | |
| CN113434509B (en) | Increment index updating method and device, storage medium and electronic equipment | |
| CN116561102A (en) | Data bidirectional migration method, device, equipment, medium and program product |
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 | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20220908 Address after: 25 Financial Street, Xicheng District, Beijing 100033 Applicant after: CHINA CONSTRUCTION BANK Corp. Address before: 25 Financial Street, Xicheng District, Beijing 100033 Applicant before: CHINA CONSTRUCTION BANK Corp. Applicant before: Jianxin Financial Science and Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right |