CN114466017B - Data monitoring method and device for kubernetes edge cluster - Google Patents
Data monitoring method and device for kubernetes edge cluster Download PDFInfo
- Publication number
- CN114466017B CN114466017B CN202210249606.3A CN202210249606A CN114466017B CN 114466017 B CN114466017 B CN 114466017B CN 202210249606 A CN202210249606 A CN 202210249606A CN 114466017 B CN114466017 B CN 114466017B
- Authority
- CN
- China
- Prior art keywords
- data
- monitoring data
- service
- node
- edge
- 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
- 238000012544 monitoring process Methods 0.000 title claims abstract description 375
- 238000000034 method Methods 0.000 title claims abstract description 68
- 238000003780 insertion Methods 0.000 claims description 24
- 230000037431 insertion Effects 0.000 claims description 24
- 238000012545 processing Methods 0.000 claims description 17
- 238000012806 monitoring device Methods 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 6
- 238000013500 data storage Methods 0.000 claims description 5
- 238000004458 analytical method Methods 0.000 abstract description 9
- 230000008602 contraction Effects 0.000 abstract description 4
- 230000003993 interaction Effects 0.000 abstract description 4
- 238000010586 diagram Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 238000013480 data collection Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 206010033799 Paralysis Diseases 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
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
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- 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
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The application provides a data monitoring method and device for kubernetes edge clusters. According to the method, the acquisition agent is deployed on each edge node, the acquisition agent and the monitoring data providing service are operated on the edge node, the monitoring data can be acquired through interaction of the acquisition agent on the edge node and the monitoring data providing service of the edge node through a host network, the monitoring data is pushed to the load balancing service on the central node in a data push mode, the monitoring data acquisition flow and the control surface flow are separated, the control surface flow uses downlink bandwidth, the monitoring data acquisition flow uses uplink bandwidth, and the control command channel is guaranteed not to be influenced; the collecting agents of all the edge nodes only need to be connected with the load balancing service, the monitoring service is not required to be strongly bound with the Tunnel route analysis example, and the transverse expansion of the monitoring service and the transverse expansion of the Tunnel route analysis example are decoupled, so that the elastic expansion and contraction capacity is realized.
Description
Technical Field
The present disclosure relates to data processing technologies, and in particular, to a method and an apparatus for monitoring data of kubernetes edge clusters.
Background
In a typical edge computing scenario, it is often necessary to monitor the resource overhead of the edge nodes and containers on the edge nodes, such as index data of CPU, memory, disk, network, etc.; it is also necessary to monitor the operational status of the container, such as the index data of the CPU, memory, disk, network, etc. of the container. Thus, the operation state of the edge computing cluster can be comprehensively controlled. When the method is applied to an edge computing scene, the kubernetes cluster is also called a kubernetes edge cluster, edge nodes in the cluster are often in a closed local area network, and the edge nodes cannot be directly accessed from the central node, namely a network environment with unidirectional communication is formed. Limited to a unidirectional communication network environment, a traditional monitoring scheme for acquiring index data by means of active Pull (Pull) of a monitoring service (such as promethaus) cannot work normally.
In order to solve this problem, the industry (for example OpenYurt, superEdge, etc.) generally adopts a Tunnel mode to open a connection path between the central node and the edge node, so that a monitoring service deployed at the central node can communicate with the edge node by means of the Tunnel, and data acquisition is completed.
However, this approach has the following technical problems: firstly, the collected flow of index data and the flow of a control surface share a Tunnel, so that great pressure is brought to a Tunnel component, the stability of a system is affected, and a control instruction (such as kubecl logs/exec and the like) cannot be executed correctly when serious; and secondly, a route analysis instance (Tunnel Server) of the Tunnel needs to be strongly bound to the same node with a monitoring service (such as an API Server of a Prometheus instance), and the lateral expansion of the monitoring service and the lateral expansion of the route analysis instance of the Tunnel are strongly coupled, so that the elastic expansion and contraction capacity cannot be realized.
Disclosure of Invention
The application provides a data monitoring method and device for kubernetes edge clusters.
In one aspect, the present application provides a data monitoring method of kubernetes edge clusters, which is applied to edge nodes in kubernetes edge clusters, where an acquisition agent is run on the edge nodes, and includes:
the following data acquisition processing is executed through the acquisition agent:
mounting acquisition configuration information, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data;
accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
and pushing the monitoring data of the edge node to a central node according to the target address information.
On the other hand, the application provides a data monitoring method of kubernetes edge clusters, which is applied to a central node in kubernetes edge clusters, wherein load balancing service is operated on the central node, and the method comprises the following steps:
receiving monitoring data of the edge node pushed by the edge node through the load balancing service;
And storing the monitoring data of the edge node.
On the other hand, the application provides data monitoring of kubernetes edge clusters, which is applied to kubernetes edge clusters, wherein the kubernetes edge clusters comprise edge nodes and central nodes, an acquisition agent is operated on the edge nodes, and a load balancing service is operated on the central nodes, and the method comprises the following steps:
the edge node mounts acquisition configuration information through the acquisition agent, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data; accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service; pushing the monitoring data of the edge node to a central node according to the target address information;
and the central node receives the monitoring data of the edge node pushed by the edge node through the load balancing service and stores the monitoring data of the edge node.
On the other hand, the application provides a data monitoring device of kubernetes edge cluster, which is applied to edge nodes in kubernetes edge cluster, wherein an acquisition agent is operated on the edge nodes, and the data monitoring device comprises:
The data acquisition module is used for executing the following data acquisition processing through the acquisition agent:
mounting acquisition configuration information, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data;
accessing the monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
and pushing the monitoring data of the edge node to a central node according to the target address information.
On the other hand, the application provides a data monitoring device of kubernetes edge cluster, which is applied to a central node in the kubernetes edge cluster, wherein load balancing service is operated on the central node, and the data monitoring device comprises:
the data receiving module is used for receiving the monitoring data of the edge node pushed by the edge node through the load balancing service;
and the data storage module is used for storing the monitoring data of the edge node.
In another aspect, the present application provides an electronic device, including: a processor, and a memory communicatively coupled to the processor; the memory stores computer-executable instructions; the processor executes computer-executable instructions stored in the memory to implement the method of any of the above aspects.
In another aspect, the present application provides a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, are configured to implement the method of any one of the above aspects.
According to the data monitoring method and device for the kubernetes edge cluster, the collection Agent is deployed on each edge node, the collection Agent and monitoring data providing services such as node-importer service, kuberet service and cadvisor service are operated on the edge nodes, the collection Agent and the node-importer service start pod in a hostNetwork mode, the collection Agent on each edge node can collect monitoring data only by interacting with the monitoring data providing service of the host network, a data push mode is adopted, the monitoring data is pushed to the monitoring service (comprising load balancing service) on the central node through the collection Agent, the monitoring data collection flow and the control plane flow are separated, the control plane flow uses downlink bandwidth, the monitoring data collection flow uses uplink bandwidth, different TCP connections are used, the monitoring data collection flow is thoroughly stripped from a downlink channel, and the control command channel is guaranteed not to be affected. Further, the monitoring service end provides a load balancing service for receiving the monitoring data, the collecting agents of all edge nodes can realize monitoring data pushing only by connecting the load balancing service, the monitoring data is in a push way to travel up the channel, and because only the downlink traffic in the edge scheme needs to be routed by the Tunnel Server, the monitoring service does not need to be deployed at the node where the Tunnel Server is located any more, the monitoring service and the Tunnel Server are not required to be strongly bound to the same node, the lateral expansion of the monitoring service and the lateral expansion of the Tunnel route analysis example are decoupled, the elastic expansion and contraction capacity can be realized, and the flexibility of the monitoring service is improved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.
FIG. 1 is a diagram illustrating an example architecture of a conventional monitoring scheme provided herein;
fig. 2 is a schematic diagram of a deployment architecture used in a data monitoring method of kubernetes edge clusters provided in the present application;
FIG. 3 is a flowchart of a method for monitoring data of kubernetes edge clusters according to an embodiment of the present disclosure;
FIG. 4 is a flowchart of a method for monitoring data of kubernetes edge clusters according to another embodiment of the present disclosure;
FIG. 5 is a schematic diagram of an architecture of an acquisition agent for acquiring monitoring data through a host network according to an embodiment of the present disclosure;
FIG. 6 is a schematic diagram of an overall architecture of a data monitoring method of kubernetes edge clusters according to an embodiment of the present disclosure;
FIG. 7 is a diagram of an exemplary architecture and data link according to one embodiment of the present application;
fig. 8 is a schematic structural diagram of a data monitoring device of kubernetes edge clusters according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of a data monitoring device of kubernetes edge clusters according to another embodiment of the present application.
Specific embodiments thereof have been shown by way of example in the drawings and will herein be described in more detail. These drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.
The terms referred to in this application are explained first:
a container: a process-based isolated operation technique.
kubernetes: abbreviated as K8s, the container orchestration system is responsible for managing automated deployment, telescoping, and managing containers.
kubelet: program components in kubernetes, which are run on each node, are responsible for tasks such as creation, start and stop of a container corresponding to a pod. And meanwhile, the method is closely cooperated with kubernetes clusters to realize the basic functions of cluster management.
cadvisor: a service contained in kubelet that gathers container related information.
Node: the independent hosts managed in kubernetes cluster are called nodes, also called nodes, and can be physical machines or virtual machines.
Node resources: the computing resources provided by the Node include, but are not limited to, CPU, memory, GPU, etc.
pod: is the smallest deployable computing unit created and managed in kubernetes, consisting of one or more containers.
DaemonSet: the method is a mode of deploying resources by using an application in kubernetes, and when a certain functional module is deployed in a DaemonSet mode, the method can deploy a pod of the functional module at most on each Node, thereby playing a role in deploying Node-level applications.
Confimap: one of the resources in kubernetes may be used to store string-based data.
Edge calculation: a cloud computing technology adopts a mode of data consumption and processing close to local data to solve the problem of computation delay caused by data transmission.
Center node: i.e., cloud nodes, and nodes in the edge computing cluster for deploying the management and control components.
Edge node: nodes in the edge computing cluster for service data processing can operate in a network-free scenario.
Tunnel: and the network channel in the kubernetes edge cluster, which is used for connecting the central node and the edge node, is used for transmitting the data packet called by the kubernetes api.
Prometheus (Promelplus): an overall solution for monitoring control data comprises the functions of data acquisition, data storage, data query interfaces and the like.
Metrics: and monitoring index items (monitoring data) exposed by the business and system components are collected by the collecting system. Typically exposed in an http/https interface.
Prometheus Pull: the method of acquisition of metrics in Prometheus scheme, namely, acquisition of Prometheus, uses the http/https interface of the Metrics provider to acquire monitoring index items.
And (3) an acquisition agent: namely, an acquisition agent, and metrics acquisition programs deployed on edge nodes. Has the functions of meta collection, caching and transmission.
And (3) acquisition configuration: a protocol, IP address, port, acquisition data format, data transmission destination address, etc. for declaring provider access to metrics services.
node-exporter: a program for collecting node CPU, memory, disk and network metrics is used for node monitoring.
LB (Load Balance): load balancing services for distributing workload to multiple servers to improve performance and reliability of the service.
In addition, the terms "first," "second," "third," etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. In the following description of the embodiments, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.
In a typical edge computing scenario, it is often necessary to monitor resource overhead of edge nodes, such as index data of CPU, memory, disk, network, etc.; it is also necessary to monitor the operational status of the container, such as the index data of the CPU, memory, disk, network, etc. of the container. Thus, the operation state of the edge computing cluster can be comprehensively controlled. When the method is applied to an edge computing scene, the kubernetes cluster is also called a kubernetes edge cluster, edge nodes in the cluster are often in a closed local area network, and the edge nodes cannot be directly accessed from the central node, namely a network environment with unidirectional communication is formed. A conventional monitoring server that acquires index data by means of active Pull (Pull) by a monitoring service (such as promethaus) will not work properly due to the network environment of unidirectional connectivity.
In order to solve this problem, the industry (for example OpenYurt, superEdge, etc.) generally adopts a Tunnel mode to open a connection path between the central node and the edge node, so that a monitoring service deployed at the central node can communicate with the edge node by means of the Tunnel, and data acquisition is completed.
Taking the monitoring service as Prometheus as an example, the system architecture of the conventional monitoring scheme such as OpenYurt, superEdge is exemplified, and in the conventional monitoring scheme such as OpenYurt, superEdge, the system architecture shown in fig. 1 is adopted, the monitoring acquisition application in fig. 1 refers to Prometheus, and the API Server is an interface service of Prometheus, namely Prometheus example. Edge Agent is an Edge Agent deployed on an Edge node. The monitoring data (metrics) on the edge nodes are collected by means of the native promethaus.
The traditional monitoring scheme has the following technical problems:
firstly, the collected flow of index data and the flow of control surface share a Tunnel, which can bring great pressure to the Tunnel component, affect the stability of the system, and cause the control instruction (such as kubecl logs/exec) to be unable to be executed correctly when serious.
Secondly, a Tunnel Server based on an IPtables (forwarding routing rule) scheme has constraint on the deployment form of a component, and requires that a routing analysis instance (Tunnel Server) of a Tunnel and a Prometaus instance be deployed on the same node to work, when a pod drift occurs in the Prometaus instance (such as when a pod on one machine fails, kubernetes can automatically migrate the pod on the machine to another machine which works normally), the problem of acquisition interruption is easy to occur due to lack of routing configuration, and the deployment form binds flexible deployment of the Prometaus, and the lateral expansion of the Prometaus and the lateral expansion of the routing analysis instance of the Tunnel are strongly coupled, so that elastic expansion capacity cannot be realized.
Thirdly, the problem of edge node IP address repetition is difficult to process based on a Tunnel monitoring scheme (the edge node IP address repetition is quite common in an edge computing scene), and because the acquired destination addresses are the same IP, the problems are encountered in both Tunnel data forwarding and Prometheus data acquisition, and in order to solve the problem, the defects of complex configuration, low automation degree, easiness in influencing system stability and the like exist in the mode of accessing the edge node through the node name in the industry.
Finally, if the Tunnel is disconnected, prometaus will not be able to collect any data and the weak network operation state of the edge node will not be perceived.
The data monitoring method of the kubernetes edge cluster is applied to kubernetes edge clusters in an edge computing scene, an acquisition agent (instance) is distributed and configured to each edge node according to kubernetes, and the acquisition agent initiates acquisition of metrics on the edge nodes and sends the metrics to monitoring services on intermediate nodes in a push mode. The monitoring service is declared in the collection configuration information through a unique EIP (Enterprise Information Portal ), so that the monitoring service (such as Prometaus instance) is not connected with a Tunnel route analysis instance any more, and the coupling constraint on the lateral expansion is solved. Meanwhile, the load balancing service receiving the metric pushing result on the central node can automatically determine whether to transversely expand the capacity or not, and the availability of the monitoring scheme is higher. In addition, the metrics is pushed in a push mode, the control surface flow and the monitoring data acquisition flow in the kubernetes edge cluster are decoupled, and the usability and the stability of cluster management and control are improved. And finally, the acquisition end of the monitoring data operates on the edge node and is provided with a storage space for acquiring the data to buffer the monitoring data so as to cope with the operation states of weak network and broken network of the edge node and reserve the metrics data to the maximum extent. In conclusion, the brand new monitoring scheme solves the core problems of difficult transverse expansion of the data channel pressure and the monitoring service, monitoring of data integrity and the like, and improves the competitiveness of the edge container products.
The following describes the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
The data monitoring method of the kubernetes edge cluster is applied to the kubernetes edge cluster in an edge computing scene, is deployed based on the architecture shown in fig. 2, and deploys an acquisition Agent (acquisition Agent) to each edge node in a Daemoset mode, wherein the acquisition Agent occupies one or more pod. Monitoring data (metrics) of the edge nodes and containers are monitored at each edge node by collecting agents. Node-exporter services and Edge agents in the Kubernetes Edge cluster are also deployed to each Edge node in the manner of Daemonset. Wherein, both the acquisition Agent and the node-exporter service start pod in a hostNetwork manner. In addition, a kubelet component is deployed on each edge node, and the kubelet component contains a kubelet service and a cadvisor service. The node-exporter service is used for providing monitoring data at the node level, the kubelet service is used for providing monitoring data at the pod level, and the cadvisor service is used for providing monitoring data at the container level. Therefore, through the host network, the acquisition Agent on each edge node only needs to interact with the local monitoring data providing service (including node-exporter service, kubelet service and cadvisor service), a closed loop for monitoring data acquisition is formed in the network of the edge node itself, and cross-network access is not needed, so that a closed and stable acquisition environment is realized. The acquisition Agent is docked with the node-exporter, kubelet, cadvisor on the same node by mounting acquisition configuration information (acquisition configuration ConfigMap shown in fig. 2) and a kubelet certificate file (kubelet certificate secret shown in fig. 2) to the acquisition Agent, monitoring data is acquired, docking of the acquisition Agent with monitoring service on a central node is realized, and monitoring data is pushed (push).
In addition, in practical application, the monitoring data required to be collected by the collecting agent can be configured according to practical requirements. The acquisition agent may be configured to acquire the monitoring data from one or more monitoring data providing services of a node-exporter service, a kubelet service, and a cadvisor service.
Fig. 3 is a flowchart of a data monitoring method of kubernetes edge clusters according to an embodiment of the present application. The data monitoring method for kubernetes edge cluster provided in the embodiment may be specifically applied to monitoring data (metrics) of monitoring edge nodes in kubernetes edge cluster.
As shown in fig. 3, the method specifically comprises the following steps:
step S101, the edge node mounts acquisition configuration information through an acquisition agent, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data.
In this embodiment, each edge node is running an acquisition agent, and the acquisition agent is mounted with acquisition configuration information.
The acquisition configuration information comprises a data format of monitoring data to be acquired, access configuration information required by access to the monitoring data providing service and target address information of pushing index data.
The access configuration information required for accessing the monitoring data providing service includes: the access monitoring data provides information such as protocol, IP address, port number, etc. required for service. According to the access configuration information, the monitoring data providing service can be accessed, and the monitoring data can be acquired from the monitoring data providing service.
The target address information of the push index data refers to address information of a service which is deployed on the central node and is used for receiving the monitoring data in the monitoring service, and may be address information of a load balancing service on the central node.
Step S102, accessing the monitoring data providing service in the local host network through the acquisition agent according to the data format and the access configuration information of the monitoring data, and acquiring the monitoring data of the edge node from the monitoring data providing service.
Wherein monitoring the data providing service includes: one or more of a node-exporter service, a kubelet service, and a cadvisor service.
In this embodiment, monitoring data providing services such as an acquisition Agent and a node-exporter service, a kubelet service, a cadvisor service and the like are all operated on an edge node, and the acquisition Agent and the node-exporter service start pod in a hostNetwork manner. When pod is configured as a hostNetwork: on true, an application running in such a pod can directly view the network interface of the edge node that initiated the pod. Therefore, through the host network, the acquisition Agent on each edge node can realize the acquisition of the monitoring data through the service interaction with the monitoring data of the host, a closed loop for the acquisition of the monitoring data is formed in the network of the edge node, and the cross-network access is not needed, so that a closed and stable acquisition environment is realized.
In the step, according to the data format and the access configuration information of the monitoring data, the monitoring data providing service is accessed through the acquisition agent, and the monitoring data of the edge node is acquired from the monitoring data providing service.
Illustratively, the node-exporter service defaults to http protocol 9101 port exposure monitoring data (metrics), the kubelet service defaults to http protocol 10255 port exposure monitoring data (metrics), and the cadvisor service defaults to https protocol 10250 port exposure monitoring data (metrics). The collecting Agent directly accesses the port and the corresponding uniform resource identifier (Uniform Resource Identifier, URI for short) through the localhost of the host machine to obtain the corresponding monitoring data (metrics).
Step S103, pushing the monitoring data of the edge node to the central node through the acquisition agent according to the target address information.
After the monitoring data are collected, the monitoring agent pushes the monitoring data of the edge node to the central node according to the target address information, a data push mode is adopted, the monitoring service end provides a written service interface (such as a load balancing service interface), and the monitoring service is not required to solve the problem of searching the routing of the edge node, so that the high availability of the monitoring system is realized.
Step S104, the central node receives the monitoring data of the edge node pushed by the edge node through the load balancing service.
In this embodiment, the monitoring service is deployed on the central node, where the monitoring service includes a load balancing service, and receives the monitoring data pushed by the edge node through the load balancing service.
Step S105, storing the monitoring data of the edge node.
And after receiving the monitoring data of the edge node, storing the monitoring data of the edge node in the central node according to the load balancing strategy.
According to the data monitoring method for the kubernetes edge cluster, the collection Agent is deployed on each edge node, the collection Agent and monitoring data providing services such as node-exporter service, kuberet service, cadvisor service and the like are operated on the edge nodes, the collection Agent and the node-exporter service start pod in a hostNetwork mode, the collection Agent on each edge node can collect monitoring data only by providing service interaction with the monitoring data of the host network, the monitoring data is pushed to the monitoring service (comprising load balancing service) on the central node through the collection Agent in a data push mode, the monitoring data collection flow and the control surface flow are separated, the control surface flow uses downlink bandwidth, the monitoring data collection flow uses uplink bandwidth, different TCP connections are used for thoroughly stripping the monitoring data collection flow from a downlink channel, and the control command channel is guaranteed not to be affected.
Further, the monitoring service end provides a load balancing service for receiving the monitoring data, the collecting agents of all edge nodes can realize monitoring data pushing only by connecting the load balancing service, the monitoring data is in a push way to travel up the channel, and because only the downlink traffic in the edge scheme needs to be routed by the Tunnel Server, the monitoring service does not need to be deployed at the node where the Tunnel Server is located any more, the monitoring service and the Tunnel Server are not required to be strongly bound to the same node, the lateral expansion of the monitoring service and the lateral expansion of the Tunnel route analysis example are decoupled, the elastic expansion and contraction capacity can be realized, and the flexibility of the monitoring service is improved.
On the basis of the corresponding embodiment of fig. 1, the monitoring data providing services running on the edge node include a node-exporter service, a kubelet service and a cadvisor service. The monitoring data to be collected may include at least one of: the edge node comprises first index data of an edge node, second index data of a pod running on the edge node and third index data of a container on the edge node, wherein the first index data is index data of a node level, the second index data is index data of a pod level, and the third index data is index data of a container level.
In this embodiment, taking the case that the monitoring data to be collected includes the first index data of the edge node, the second index data of the pod running on the edge node, and the third index data of the container on the edge node, that is, the monitoring data to be collected provided by the node-exporter service, the kubrelet service, and the cadvisor service as examples, a detailed flow of a data monitoring method of kubrennetes edge cluster is exemplarily described.
As shown in fig. 4, the method specifically comprises the following steps:
and S201, the edge node mounts acquisition configuration information and kubelet certificate files through an acquisition agent.
The acquisition configuration information comprises a data format of monitoring data to be acquired, access configuration information required by access to the monitoring data providing service and target address information of pushing index data.
The access configuration information required for accessing the monitoring data providing service includes: the access monitoring data provides information such as protocol, IP address, port number, etc. required for service. According to the access configuration information, the monitoring data providing service can be accessed, and the monitoring data can be acquired from the monitoring data providing service.
The target address information of the push index data refers to address information of a service which is deployed on the central node and is used for receiving the monitoring data in the monitoring service, and may be address information of a load balancing service on the central node.
In this embodiment, a kubelet certificate used by an API Server may be multiplexed, and a kubelet certificate file (i.e., a kubelet certificate of kubelet) generated according to a kubelet certificate used by an interface Server (i.e., an API Server) in a kubeletes cluster may be stored on an edge node for use by an acquisition agent to mount and connect to the cadvisor service.
Optionally, the edge node may pull up a pod that is affinitive to the central node through a job, generate a corresponding certificate file (secret) for the kubelet certificate used by the API Server, and store the certificate file (secret) to the host for the acquisition agent to mount and use.
The job is a special pod, and uses a task executed once to execute released resources.
After the collection configuration information and kubelet certificate file are mounted through the collection agent, steps S202-S204 are executed, the monitoring data providing service is accessed in the local host network through the collection agent operated by the edge node, and the monitoring data of the edge node is obtained from the monitoring data providing service.
In this embodiment, monitoring data providing services such as an acquisition Agent and a node-exporter service, a kubelet service, a cadvisor service and the like are all operated on an edge node, and the acquisition Agent and the node-exporter service start pod in a hostNetwork manner. When pod is configured as a hostNetwork: on true, an application running in such a pod can directly view the network interface of the edge node that initiated the pod. Thus, as shown in fig. 5, through the host network, the collection Agent (Agent pod shown in fig. 5 refers to the pod of the collection Agent) on each edge node can collect the monitoring data through interaction with the local monitoring data providing service, and a closed loop for collecting the monitoring data is formed in the network of the edge node itself, so that cross-network access is not needed, and a closed and stable collection environment is realized.
And mounting acquisition configuration information and kubelet certificate files when the pod of the acquisition Agent is started.
Step S202, accessing a node-exporter service in a local host network through an acquisition agent, and acquiring first index data of an edge node from the node-exporter service, wherein the first index data is index data of a node level.
The first index data is node-level monitoring data provided by a node-exporter service, and comprises index data of at least one index item.
Illustratively, the first index data may include index data of index items related to a CPU, a memory, a disk, a network, and the like of the node.
In addition, the first index data in the monitoring data to be collected specifically includes which index items, and can be set and adjusted in the collection configuration information according to the requirement of the actual monitoring scene, which is not specifically limited herein.
Illustratively, the node-exporter service defaults to http protocol 9101 port exposure monitoring data (metrics). In addition, the port used by the node-exporter service can be set and adjusted according to actual needs, and is not particularly limited herein.
In the step, the collecting Agent can obtain the monitoring data (first index data) of the node level by adding the corresponding URI to the port corresponding to the node-exporter service accessed by the localhost of the host.
And step 203, accessing the kubelet service in the local host network through the acquisition agent, and acquiring second index data of the pod running on the edge node from the kubelet service, wherein the second index data is pod-level index data.
Wherein the second index data is pod-level monitoring data provided by kubelet service, and comprises index data of at least one index item.
Illustratively, the second index data may include index data of a CPU, memory, disk, network, etc. related index item used by the pod on the edge node.
In addition, the second index data in the monitoring data to be collected specifically includes which index items, and can be set and adjusted in the collection configuration information according to the needs of the actual monitoring scene, which is not specifically limited herein.
Illustratively, kubelet service defaults to http protocol 10255 port exposure monitoring data (metrics). In addition, the ports used by kubelet service can be set and adjusted according to actual needs, and are not particularly limited herein.
In the step, the collecting Agent accesses a port corresponding to the kubelet service through the localhost and adds a corresponding URI to obtain the pod-level monitoring data (second index data) on the edge node.
Step S204, accessing the cadvisor service in the local host network through the acquisition agent, and acquiring third index data of a container on the edge node from the cadvisor service, wherein the third index data is container-level index data.
Wherein the third index data is container-level monitoring data provided by the cadvisor service, and comprises index data of at least one index item.
Illustratively, the third index data may include index data of index items related to CPU, memory, disk, network, etc. of the container on the edge node, life cycle of the container, running state of the container, etc.
In addition, the third index data in the monitoring data to be collected specifically includes which index items, and can be set and adjusted in the collection configuration information according to the requirement of the actual monitoring scene, which is not specifically limited herein.
Illustratively, the cadvisor service defaults to https protocol 10250 port exposure monitoring data (metrics). In addition, the ports used by the cadvisor service can be set and adjusted according to actual needs, and are not particularly limited herein.
In the step, the collecting Agent accesses the port corresponding to the cadvisor service through the localhost and adds the corresponding URI to obtain the container-level monitoring data (third index data) on the edge node.
The three steps S202, S203, and S204 may be performed in parallel, or may be performed sequentially in a specific order, and the order of execution of the three steps is not particularly limited.
Step S205, pushing the node name and the monitoring data of the edge node to the central node according to the target address information.
After the monitoring data are collected, the monitoring data of the edge nodes are pushed to the central node by the collecting agent according to the target address information, a data push mode is adopted, and the monitoring service end provides a written service interface (such as a load balancing service interface), so that the problem of searching the routing of the edge nodes is not needed to be solved by the monitoring service, and the high availability of the monitoring system is realized.
The destination address information may be access address information of a load balancing service on the central node.
In this embodiment, since the pod of the collection Agent is deployed on each edge node, the node name (nodeName) of the edge node may be obtained by using the manner of kubernetes native, and loaded onto the pod of the collection Agent.
Prior to this step, the acquisition agent obtains the node name of the edge node where it is located. When the monitoring data of the edge nodes are pushed, the node names of the edge nodes and the monitoring data are pushed together, so that the monitoring data are marked with the node names of the edge nodes, the monitoring data of different edge nodes can be distinguished easily, and the problem of repeated IP addresses of the edge nodes is solved.
Optionally, after the load balancing service of the central node receives the monitoring data of the edge node successfully, a response message is fed back to the collecting Agent of the edge node. If the acquisition Agent on the edge node does not receive the corresponding response message within the preset waiting time, determining that the monitoring data of the edge node fails to be pushed, and storing the monitoring data of the edge node in a local storage space by the acquisition Agent. And the collecting Agent re-pushes the monitoring data of the edge node according to the re-pushing rule.
For example, if the edge node is in a network outage or weak network environment, the collection Agent of the edge node fails to push the monitoring data to the central node, and the collection Agent stores the monitoring data of the edge node in the local storage space; according to the re-pushing rule, the monitoring data of the edge node are re-pushed, and the problem that the monitoring data cannot be collected in the broken network or weak network environment in the traditional monitoring scheme is solved.
According to the re-pushing rule, as the pushing times of the monitoring data of the edge node increase, the interval time of the monitoring data of the edge node is increased.
Illustratively, the re-push rule may be: the monitoring data is tried to be pushed again according to the time intervals of 30 seconds, 1 minute, 2 minutes, 4 minutes, 16 minutes, 32 minutes and 1 hour … …, and the probability of push storm occurrence is reduced by using the time intervals of multiplication and pushing to back off the abnormality of the network.
Optionally, the upper limit of the local storage space may be set, if the amount of data stored in the local storage space is greater than or equal to the upper limit of the local storage space, the edge node may delete the earlier part of data in the local storage space according to the time information of the monitored data stored in the local storage space, so as to control the upper limit of the local storage space, and prevent the storage space of the edge node from being exploded, thereby causing paralysis of the edge node.
In addition, after the monitoring data of the edge node is successfully re-pushed, the monitoring data which is successfully pushed is deleted from the local storage space.
Step S206, the central node receives the monitoring data of the edge node pushed by the edge node through the load balancing service.
After the monitoring data are collected, the monitoring agent pushes the monitoring data of the edge node to the central node according to the target address information, a data push mode is adopted, the monitoring service end provides a written service interface (interface of load balancing service), and the monitoring service is not required to solve the problem of searching the routing of the edge node, so that the high availability of the monitoring system is realized.
In this embodiment, the monitoring service includes a load balancing service, a data insertion service, and a storage service.
The load balancing service is used for receiving monitoring data pushed by the edge node, and according to the load condition of the pod of each data insertion service, the data insertion service is preferentially selected, and the currently received monitoring data is sent to the data insertion service.
The data insertion service is a service dedicated to writing monitoring data, in particular to sending the monitoring data to a storage service.
The storage service is a service specially used for storing and managing the monitoring data, and can realize the storage of the monitoring data, the data redundancy processing, the data compression and the like.
The central node has at least one data insertion service and at least one storage service running thereon. Wherein the number of data insertion services is greater than or equal to the number of storage services.
By providing a large number of data insertion services, the plurality of data insertion services can perform the writing processing of the monitor data in parallel, and the throughput and the connection number of the monitor data can be improved.
By setting a plurality of storage services, the storage efficiency and the storage disaster tolerance of the monitoring data can be improved.
Optionally, the number of data insertion services and/or the number of storage services may be dynamically extended depending on the real-time load situation.
Illustratively, the architecture of the monitoring scheme provided in this embodiment is shown in fig. 6, taking the monitoring service as a promethaus instance as an example, the monitoring service is split into a load balancing service (such as LB shown in fig. 6), a data insertion service (such as Prometheus insert shown in fig. 6), and a storage service (such as promethaus store shown in fig. 6). The collection Agent on the edge node (Agent as shown in fig. 6) pushes the collected monitoring data of the edge node to the load balancing service LB. The edge node locally sets up a local storage space for storing the monitor data metrics, and the/tmp/metrics-data shown in fig. 6 represents the local storage space on the edge node for storing the monitor data metrics. And collecting agents when the network is disconnected, caching the monitoring data of the edge nodes into a local storage space, reading the monitoring data of the edge nodes from the local storage space after the network is recovered (when the network is connected), and pushing the monitoring data to the load balancing service again.
Step S207, the edge node monitoring data is sent to the data insertion service through the load balancing service according to the load balancing strategy, and a response message is fed back to the edge node.
After receiving the monitoring data, the load balancing service sends the edge node monitoring data to the data insertion service according to a load balancing strategy.
The rule of how to write the monitoring data with the data insertion service is preferably selected in the load balancing policy, specifically, the rule can be set and adjusted according to the needs of the actual application scenario, and the rule is not specifically limited herein.
After the edge node monitoring data is sent to the data insertion service, a response message is fed back to the collecting Agent of the edge node so as to inform the collecting Agent of successful pushing of the monitoring data.
Step S208, the monitoring data of the edge node are sent to the storage service through the data insertion service.
After the data insertion service receives the monitoring data of the edge node, the monitoring data of the edge node is sent to the storage service, so that the monitoring data writing process is realized.
Step S209, storing the monitoring data of the edge node by the storage service.
The storage service stores the received monitoring data of the edge node, and realizes the storage of the monitoring data.
An example architecture and a data link of the kubernetes edge cluster data monitoring method provided in this embodiment are shown in fig. 7, control plane traffic between a central node and an edge node is still implemented through a Tunnel, in this embodiment, a monitoring system is deployed on the central node, a unified load balancing service (such as LB in fig. 7) provided by the monitoring system on the edge node is deployed on each edge node, a collecting Agent is deployed on each edge node, the collecting Agent further deploys a node-exporter, collects monitoring data of the edge node from the node-exporter through a local network, and pushes the monitoring data to a load balancing service (LB) in a push manner, and the load balancing service (LB) sends the monitoring data of the edge node to the monitoring system to implement storage of the monitoring data. In addition, the edge node is also provided with a local storage space for storing the monitoring data metrics locally (as shown in fig. 7, tmp/metrics-data is a storage path of the monitoring data). And collecting agents when the network is disconnected, caching the monitoring data of the edge nodes into a local storage space, reading the monitoring data of the edge nodes from the local storage space after the network is recovered (when the network is connected), and pushing the monitoring data to the load balancing service again. As shown in fig. 7, in the data monitoring method for kubernetes edge clusters provided in this embodiment, a Tunnel link used for management and control is separated from a push link used for monitoring data reporting, so that the monitored data acquisition flow and the control plane flow are separated, the control plane flow uses a downlink bandwidth, the monitored data acquisition flow uses an uplink bandwidth, different TCP connections are used, the monitored data acquisition flow is thoroughly stripped from a downlink channel, and the control command channel is guaranteed not to be affected.
In this embodiment, by splitting the monitoring service into the load balancing service, the data inserting service and the storage service, splitting the whole monitoring process into the plurality of modules such as acquisition, insertion, storage and query, for acquisition, only the load balancing service (LB) Agent is required to be well inserted into the module (for example, kubernetes Service in the LoadBalancer mode in the NodePort mode), and the collecting Agent is connected with the LB, so that the monitoring data adopts the push mode to walk up-going channel, only the downlink traffic in the edge scheme needs to be routed by the Tunnel Server to route the edge node, so that the monitoring service no longer requires to be deployed at the node where the Tunnel Server is located, no strong binding of the monitoring service and the Tunnel Server to the same node is required, and the flexible expansion capacity can be realized, so that the flexibility of the monitoring service is improved.
Fig. 8 is a schematic structural diagram of a data monitoring device of kubernetes edge clusters according to an embodiment of the present application. The data monitoring device of the kubernetes edge cluster provided by the embodiment of the application can execute the processing flow provided by the embodiment of the data monitoring method of the kubernetes edge cluster. The data monitoring device of the kubernetes edge cluster provided by the embodiment of the application is applied to edge nodes in the kubernetes edge cluster, and the edge nodes are operated with acquisition agents. As shown in fig. 8, the data monitoring device 80 of kubernetes edge cluster includes: a data acquisition module 801.
Specifically, the data acquisition module 801 is configured to perform, by means of an acquisition agent, the following data acquisition processes:
mounting acquisition configuration information, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data; accessing a monitoring data providing service in a local host network according to the data format and the access configuration information of the monitoring data, and acquiring the monitoring data of the edge node from the monitoring data providing service; and pushing the monitoring data of the edge node to the central node according to the target address information.
Optionally, the monitoring data providing service running on the edge node includes a node-exporter service, a kubelet service, and a cadvisor service.
The data acquisition module is also used for:
accessing a node-exporter service in a local host network through an acquisition agent, and acquiring first index data of an edge node from the node-exporter service, wherein the first index data is monitoring data of a node level; accessing kubelet service in a local host network through an acquisition agent, and acquiring second index data of a pod running on an edge node from the kubelet service, wherein the second index data is monitoring data of a pod level; and accessing the cadvisor service in the local host network by the acquisition agent, and acquiring third index data of the container on the edge node from the cadvisor service, wherein the third index data is container-level monitoring data.
Optionally, the data acquisition module is further configured to:
generating a kubelet certificate file according to kubelet certificates used by an interface server in the kubelet edge cluster; and mounting the kubelet certificate file through the acquisition agent.
Optionally, the data acquisition module is further configured to:
acquiring node names of edge nodes; and pushing the monitoring data of the edge node and the node name to the central node according to the target address information.
Optionally, the data acquisition module is further configured to:
after the monitoring data of the edge node are pushed to the central node according to the target address information, if the monitoring data of the edge node are determined to be failed to be pushed, the monitoring data of the edge node are stored in a local storage space; and re-pushing the monitoring data of the edge node according to the re-pushing rule, wherein the interval time for re-pushing the monitoring data of the edge node increases as the pushing times of the monitoring data of the edge node increases.
Optionally, the data acquisition module is further configured to:
and if the data quantity stored in the local storage space is greater than or equal to the storage upper limit, deleting part of data in the local storage space according to the time information of the monitoring data of the edge node.
The device provided in this embodiment of the present application may be specifically configured to execute the processing flow executed by the edge node in any of the foregoing method embodiments, and specific functions and technical effects that can be achieved are not described herein again.
Fig. 9 is a schematic structural diagram of a data monitoring device of kubernetes edge clusters according to another embodiment of the present application. The data monitoring device of the kubernetes edge cluster provided by the embodiment of the application can execute the processing flow provided by the embodiment of the data monitoring method of the kubernetes edge cluster. The data monitoring device of the kubernetes edge cluster provided by the embodiment of the invention is applied to a central node in the kubernetes edge cluster, and load balancing service is operated on the central node. As shown in fig. 9, the data monitoring device 90 of kubernetes edge cluster includes: the data receiving module 901 and the data storing module 902.
Specifically, the data receiving module 901 is configured to receive, through a load balancing service, monitoring data of an edge node pushed by the edge node.
A data storage module 902, configured to store monitoring data of the edge node.
Optionally, at least one data insertion service and at least one storage service run on the central node.
The data storage module is also for:
according to the load balancing strategy, the edge node monitoring data is sent to the data insertion service through the load balancing service, and a response message is fed back to the edge node; sending the monitoring data of the edge node to a storage service through a data insertion service; the monitoring data of the edge node is stored by the storage service.
The device provided in this embodiment of the present application may be specifically configured to execute the processing flow executed by the central node in any of the foregoing method embodiments, and specific functions and technical effects that can be achieved are not described herein again.
The application also provides an electronic device comprising: a processor, and a memory communicatively coupled to the processor, the memory storing computer-executable instructions. The processor executes the computer-executed instructions stored in the memory to implement the processing flow executed by the edge node in any of the above method embodiments, and specific functions and technical effects that can be implemented are not described herein.
The application also provides an electronic device comprising: a processor, and a memory communicatively coupled to the processor, the memory storing computer-executable instructions. The processor executes the computer-executed instructions stored in the memory to implement the processing flow executed by the central node in any of the above method embodiments, and specific functions and technical effects that can be implemented are not described herein.
The embodiment of the application also provides a computer readable storage medium, in which computer executable instructions are stored, and when the computer executable instructions are executed by a processor, the computer readable storage medium is used to implement a processing flow executed by the edge node or the central node in any of the method embodiments.
The embodiment of the application also provides a computer program product, which comprises: computer program stored in a readable storage medium, from which the computer program can be read by at least one processor of an electronic device, the at least one processor executing the computer program causing the electronic device to perform the process flow performed by the edge node or the center node in any of the method embodiments described above.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in hardware plus software functional units.
The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above. The specific working process of the above-described device may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (12)
1. The data monitoring method of the kubernetes edge cluster is characterized by being applied to edge nodes in the kubernetes edge cluster, wherein an acquisition agent is operated on the edge nodes, and the method comprises the following steps:
the following data acquisition processing is executed through the acquisition agent:
mounting acquisition configuration information, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data;
accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
acquiring the node name of the edge node;
and pushing the monitoring data of the edge node and the node name to a central node according to the target address information.
2. The method of claim 1, wherein the monitoring data providing services running on the edge node include a node-exporter service, a kubelet service, and a cadvisor service,
and accessing the monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service, wherein the monitoring data comprises at least one of the following steps:
Accessing a node-exporter service in a local host network through the acquisition agent, and acquiring first index data of the edge node from the node-exporter service, wherein the first index data is monitoring data of a node level;
accessing kubelet service in a local host network through the acquisition agent, and acquiring second index data of a pod running on the edge node from the kubelet service, wherein the second index data is pod-level monitoring data;
and accessing a cadvisor service in a local host network through the acquisition agent, and acquiring third index data of a container on the edge node from the cadvisor service, wherein the third index data is container-level monitoring data.
3. The method of claim 2, wherein accessing, by the acquisition agent, a cadvisor service within a local host network, and prior to obtaining third metric data for a container on the edge node from the cadvisor service, further comprises:
generating a kubelet certificate file according to kubelet certificates used by an interface server in the kubelet edge cluster;
and mounting a kubelet certificate file through the acquisition agent.
4. A method according to any of claims 1-3, characterized in that after said pushing the monitoring data of the edge node to a central node according to the destination address information, it comprises:
If the monitored data pushing of the edge node is determined to be failed, storing the monitored data of the edge node in a local storage space;
and re-pushing the monitoring data of the edge node according to a re-pushing rule, wherein the interval time for re-pushing the monitoring data of the edge node increases along with the increase of the pushing times of the monitoring data of the edge node.
5. The method as recited in claim 4, further comprising:
and if the data quantity stored in the local storage space is greater than or equal to the storage upper limit, deleting part of data in the local storage space according to the time information of the monitoring data of the edge node.
6. The data monitoring method of the kubernetes edge cluster is characterized by being applied to a central node in the kubernetes edge cluster, wherein load balancing service is operated on the central node, and the method comprises the following steps of:
receiving monitoring data of the edge node pushed by the edge node and node names of the edge node through the load balancing service; the edge node is provided with an acquisition agent, and the edge node mounts acquisition configuration information through the acquisition agent, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data; accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
And storing the monitoring data of the edge node.
7. The method of claim 6, wherein the central node has at least one data insertion service and at least one storage service running thereon;
the storing the monitoring data of the edge node includes:
sending the edge node monitoring data to a data insertion service according to a load balancing strategy through the load balancing service, and feeding back a response message to the edge node;
sending the monitoring data of the edge node to a storage service through the data insertion service;
and storing the monitoring data of the edge node through the storage service.
8. The utility model provides a data monitoring method of kubernetes edge cluster, which is characterized in that the method is applied to kubernetes edge cluster, the kubernetes edge cluster comprises edge nodes and a central node, an acquisition agent is operated on the edge nodes, and a load balancing service is operated on the central node, and the method comprises the following steps:
the edge node mounts acquisition configuration information through the acquisition agent, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data; accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service; acquiring the node name of the edge node; pushing the monitoring data of the edge node and the node name to a central node according to the target address information;
And the center node receives the monitoring data of the edge node pushed by the edge node and the node name of the edge node through the load balancing service, and stores the monitoring data of the edge node.
9. The utility model provides a data monitoring device of kubernetes edge cluster, its characterized in that is applied to the edge node in kubernetes edge cluster, the edge node is last to be run has collection agency, includes:
the data acquisition module is used for executing the following data acquisition processing through the acquisition agent:
mounting acquisition configuration information, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data;
accessing the monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
acquiring the node name of the edge node;
and pushing the monitoring data of the edge node and the node name to a central node according to the target address information.
10. The utility model provides a data monitoring device of kubernetes edge cluster which characterized in that is applied to the central node in kubernetes edge cluster, the operation of the central node has load balancing service, includes:
The data receiving module is used for receiving the monitoring data of the edge node pushed by the edge node and the node name of the edge node through the load balancing service; the edge node is provided with an acquisition agent, and the edge node mounts acquisition configuration information through the acquisition agent, wherein the acquisition configuration information comprises a data format of monitoring data, access configuration information required by accessing the monitoring data to provide service and target address information of pushing index data; accessing a monitoring data providing service in a local host network according to the data format of the monitoring data and the access configuration information, and acquiring the monitoring data of the edge node from the monitoring data providing service;
and the data storage module is used for storing the monitoring data of the edge node.
11. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;
the memory stores computer-executable instructions;
the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1-7.
12. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210249606.3A CN114466017B (en) | 2022-03-14 | 2022-03-14 | Data monitoring method and device for kubernetes edge cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210249606.3A CN114466017B (en) | 2022-03-14 | 2022-03-14 | Data monitoring method and device for kubernetes edge cluster |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114466017A CN114466017A (en) | 2022-05-10 |
| CN114466017B true CN114466017B (en) | 2024-03-12 |
Family
ID=81416589
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210249606.3A Active CN114466017B (en) | 2022-03-14 | 2022-03-14 | Data monitoring method and device for kubernetes edge cluster |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114466017B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102244685A (en) * | 2011-08-11 | 2011-11-16 | 中国科学院软件研究所 | Distributed type dynamic cache expanding method and system supporting load balancing |
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN108712464A (en) * | 2018-04-13 | 2018-10-26 | 中国科学院信息工程研究所 | A kind of implementation method towards cluster micro services High Availabitity |
| CN111431740A (en) * | 2020-03-16 | 2020-07-17 | 深信服科技股份有限公司 | Data transmission method, device, equipment and computer readable storage medium |
| CN111538590A (en) * | 2020-04-17 | 2020-08-14 | 姜海强 | Distributed data acquisition method and system based on CS framework |
| CN113225214A (en) * | 2021-05-07 | 2021-08-06 | 浪潮软件科技有限公司 | Method and device for cooperative management of edge CDN node and computer readable medium |
| CN113656168A (en) * | 2021-07-16 | 2021-11-16 | 新浪网技术(中国)有限公司 | Method, system, medium and equipment for automatic disaster recovery and scheduling of traffic |
| CN113900794A (en) * | 2021-08-31 | 2022-01-07 | 艾普工华科技（武汉）有限公司 | Industrial data acquisition platform and method |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7694011B2 (en) * | 2006-01-17 | 2010-04-06 | Cisco Technology, Inc. | Techniques for load balancing over a cluster of subscriber-aware application servers |
| EP3229405B1 (en) * | 2015-12-31 | 2020-07-15 | Huawei Technologies Co., Ltd. | Software defined data center and scheduling and traffic-monitoring method for service cluster therein |
| US10523540B2 (en) * | 2017-03-29 | 2019-12-31 | Ca, Inc. | Display method of exchanging messages among users in a group |
-
2022
- 2022-03-14 CN CN202210249606.3A patent/CN114466017B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102244685A (en) * | 2011-08-11 | 2011-11-16 | 中国科学院软件研究所 | Distributed type dynamic cache expanding method and system supporting load balancing |
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN108712464A (en) * | 2018-04-13 | 2018-10-26 | 中国科学院信息工程研究所 | A kind of implementation method towards cluster micro services High Availabitity |
| CN111431740A (en) * | 2020-03-16 | 2020-07-17 | 深信服科技股份有限公司 | Data transmission method, device, equipment and computer readable storage medium |
| CN111538590A (en) * | 2020-04-17 | 2020-08-14 | 姜海强 | Distributed data acquisition method and system based on CS framework |
| CN113225214A (en) * | 2021-05-07 | 2021-08-06 | 浪潮软件科技有限公司 | Method and device for cooperative management of edge CDN node and computer readable medium |
| CN113656168A (en) * | 2021-07-16 | 2021-11-16 | 新浪网技术(中国)有限公司 | Method, system, medium and equipment for automatic disaster recovery and scheduling of traffic |
| CN113900794A (en) * | 2021-08-31 | 2022-01-07 | 艾普工华科技（武汉）有限公司 | Industrial data acquisition platform and method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114466017A (en) | 2022-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3230868B1 (en) | Multiple transaction logs in a distributed storage system | |
| US11405300B2 (en) | Methods and systems to adjust resources and monitoring configuration of objects in a distributed computing system | |
| US8260924B2 (en) | User load balancing systems and methods thereof | |
| US10540211B2 (en) | Elasticity for highly available applications | |
| CN110865867B (en) | Method, device and system for discovering application topological relation | |
| US10158579B2 (en) | Resource silos at network-accessible services | |
| EP1701263B1 (en) | Computer system and data backup method in computer system | |
| CN113296792B (en) | Storage method, device, equipment, storage medium and system | |
| US20210208922A1 (en) | Seamless virtual standard switch to virtual distributed switch migration for hyper-converged infrastructure | |
| CN107544783B (en) | Data updating method, device and system | |
| US20120117246A1 (en) | Method And System For The Efficient And Automated Management of Virtual Networks | |
| CN112202853B (en) | Data synchronization method, system, computer device and storage medium | |
| CN113127133A (en) | Cross-platform virtual machine live migration method, device, equipment and medium | |
| CN111835862A (en) | Method for realizing reference flow type deployment object storage back-end service | |
| CN116382585A (en) | Temporary volume storage method, containerized cloud platform and computer readable medium | |
| CN104793981A (en) | Online snapshot managing method and device for virtual machine cluster | |
| Cogo et al. | FITCH: supporting adaptive replicated services in the cloud | |
| CN114466017B (en) | Data monitoring method and device for kubernetes edge cluster | |
| US11579911B1 (en) | Emulated edge locations in cloud-based networks for testing and migrating virtualized resources | |
| US10979303B1 (en) | Segmentation of maintenance on distributed systems | |
| CN111756800A (en) | Method and system for processing burst flow | |
| US11765098B1 (en) | Customized cross-premise resource selection for containerized applications | |
| CN112398668B (en) | IaaS cluster-based cloud platform and node switching method | |
| CN111078135A (en) | Enhanced data storage for virtual nodes in a data processing environment | |
| CN116010111B (en) | Cross-cluster resource scheduling method, system and terminal 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 |