CN117640359A - Kubernetes cluster network link nano-tube method, device, equipment and storage medium - Google Patents
Kubernetes cluster network link nano-tube method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN117640359A CN117640359A CN202311836991.2A CN202311836991A CN117640359A CN 117640359 A CN117640359 A CN 117640359A CN 202311836991 A CN202311836991 A CN 202311836991A CN 117640359 A CN117640359 A CN 117640359A
- Authority
- CN
- China
- Prior art keywords
- pod
- kubernetes
- network link
- exporter
- kubeskoop
- 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
- 239000002071 nanotube Substances 0.000 title claims abstract description 41
- 238000000034 method Methods 0.000 title claims abstract description 24
- 230000002159 abnormal effect Effects 0.000 claims abstract description 13
- 238000012544 monitoring process Methods 0.000 claims description 30
- 238000002347 injection Methods 0.000 claims description 5
- 239000007924 injection Substances 0.000 claims description 5
- 230000000007 visual effect Effects 0.000 claims description 4
- 230000005856 abnormality Effects 0.000 claims description 3
- 238000004590 computer program Methods 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 244000035744 Hura crepitans Species 0.000 description 2
- 238000013480 data collection Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to the field of computers and discloses a Kubernetes cluster network link nano-tube method, equipment and a storage medium. The method comprises the following steps: creating Pod in the Kubernetes cluster, and injecting the Sidecar containers into the Pod through OpenKruise, wherein the Pod is formed by injecting a plurality of Sidecar containers; according to the Sidecar container and the Pod, acquiring Pod network information in a Kubernetes cluster through KubeSkoop exporter; acquiring index data from KubeSkoop exporter by Prometaus according to a preset configuration file, wherein the index data is KubeSkoop exporter monitored target Pod data; and pushing alarm information to an alert manager according to the index data and a preset PromQL rule so as to locate abnormal Pod on a network link. In the embodiment of the invention, pod network information can be acquired in a SideCar mode through KubeSkoop exporter, a KubeSkoop exporter SideCar nanotube is realized through OpenKruise, index data is acquired through Prometheus, and Kubernetes network link early warning, recording and backtracking are realized by utilizing the warning capability of Prometheus.
Description
Technical Field
The present invention relates to the field of computers, and in particular, to a Kubernetes cluster network link nanotube method, apparatus, device, and storage medium.
Background
In the original climax of the cloud, many enterprises migrate own business into the Kubernetes cluster, and when enjoying the convenience of the Kubernetes management iteration business, the business is also affected by the complexity of the Kubernetes cluster network, for example: the influence of CNI plug-in of the Kubernetes cluster network connectivity, the influence of Service discovery mechanism, the influence of network policy and the like, wherein problems in one ring easily cause link problems in Service data interaction.
Meanwhile, under the use condition of multiple public clouds, the network interface card driver and the matching rules such as a firewall, a routing table and the like can be influenced by IaaS layer network fluctuation abnormality of each cloud manufacturer. Therefore, when packet loss or occasional jitter occurs on the service data plane, the service data plane cannot be traced back.
Disclosure of Invention
The invention mainly aims to solve the technical problem of how to realize early warning, recording and backtracking of a Kubernetes network link.
The first aspect of the invention provides a Kubernetes cluster network link nanotube method, which comprises the following steps:
creating a Pod in a Kubernetes cluster, and injecting a Sidecar container into the Pod through OpenKruise, wherein the Pod is formed by injecting a plurality of Sidecar containers;
acquiring Pod network information in a Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and the Pod;
acquiring index data from the KubeSkoop exporter through Prometaus according to a preset configuration file, wherein the index data refers to target Pod data monitored by the KubeSkoop exporter;
and pushing alarm information to an alert manager according to the index data and a preset PromQL rule so as to locate abnormal Pod on a network link.
Optionally, in a first implementation manner of the first aspect of the present invention, the collecting, by KubeSkoop exporter, pod network information in a Kubernetes cluster according to the Sidecar container and the Pod includes:
checking whether the Pod is already running;
if so, checking whether the Sidecar container in the Pod is started normally;
if yes, pod network information is collected in the Kubernetes cluster through KubeSkoop exporter.
Optionally, in a second implementation manner of the first aspect of the present invention, creating a Pod in the Kubernetes cluster, and injecting, by OpenKruise, a Sidecar container into the Pod includes:
deploying OpenKruise, and acquiring SidecarSet resources in the OpenKruise;
creating a Pod in a Kubernetes cluster;
and injecting the Sidecar container into the Pod according to the Sidecar set resource.
Optionally, in a third implementation manner of the first aspect of the present invention, the obtaining, according to a preset configuration file, the index data from the KubeSkoop exporter through promethaus includes:
instantiating the KubeSkoop exporter as a monitoring target by promethaus;
setting Prometaus acquisition indexes, and defining configuration to obtain a preset configuration file;
and acquiring index data from the monitoring target according to the preset configuration file.
Optionally, in a fourth implementation manner of the first aspect of the present invention, the obtaining, according to the preset configuration file, the index data from the monitoring target includes:
acquiring the association information of the Pod through a CRI interface;
according to the preset configuration file, monitoring a kernel event of the Pod network by the monitoring target through the eBPF;
and analyzing a preset network protocol according to the kernel event to obtain index data.
Optionally, in a fifth implementation manner of the first aspect of the present invention, pushing the alert information to the alert manager according to the index data and the preset PromQL rule to locate the abnormal Pod on the network link includes:
issuing a preset PromQL rule to the Prometheus;
executing the preset PromQL rule through the Prometaus to judge whether the index data hits the preset PromQL rule or not;
if yes, sending alarm information to an alert manager, and locating abnormal Pod on a network link through visual index data. Optionally, in a sixth implementation manner of the first aspect of the present invention, if the Sidecar container is upgraded, a new image corresponding to the Sidecar container is obtained, and the Sidecar container in the Pod is rebuilt through the new image; and monitoring configuration information of the rebuilt Sidecar container through the KubeSkoop exporter.
A second aspect of the present invention provides a Kubernetes cluster network link nanotube device, comprising: a memory and at least one processor, the memory having instructions stored therein, the memory and the at least one processor being interconnected by a line; the at least one processor invokes the instructions in the memory to cause the Kubernetes clustered network link nanotube device to perform the Kubernetes clustered network link nanotube method described above.
A third aspect of the present invention provides a computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the Kubernetes cluster network link nanotube method described above.
In the embodiment of the invention, a Pod is created in a Kubernetes cluster, and Sidecar containers are injected into the Pod through OpenKruise, wherein the Pod is formed by injecting a plurality of Sidecar containers; acquiring Pod network information in a Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and the Pod; acquiring index data from the KubeSkoop exporter through Prometaus according to a preset configuration file, wherein the index data refers to target Pod data monitored by the KubeSkoop exporter; and pushing alarm information to an alert manager according to the index data and a preset PromQL rule so as to locate abnormal Pod on a network link. According to the invention, pod network information can be acquired in a SideCar mode through KubeSkoop exporter, a KubeSkoop exporter SideCar nanotube is realized through OpenKruise, index data is acquired through Prometaus finally, and Kubernetes network link early warning, recording and backtracking are realized by utilizing the warning capability of Prometaus.
Drawings
FIG. 1 is a schematic diagram of one embodiment of a Kubernetes cluster network link nanotube method according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of one embodiment of a Kubernetes Cluster network Link nanotube arrangement in accordance with embodiments of the present invention;
fig. 3 is a schematic diagram of an embodiment of a Kubernetes cluster network link nanotube device according to an embodiment of the present invention.
Detailed Description
The embodiment of the invention provides a Kubernetes cluster network link nano-tube method, a device, equipment and a storage medium.
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the present disclosure has been illustrated in the drawings in some form, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and examples of the present disclosure are for illustrative purposes only and are not intended to limit the scope of the present disclosure.
In describing embodiments of the present disclosure, the term "comprising" and its like should be taken to be open-ended, i.e., including, but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first," "second," and the like, may refer to different or the same object. Other explicit and implicit definitions are also possible below.
For ease of understanding, the following describes a specific flow of an embodiment of the present invention, referring to fig. 1, and one embodiment of a Kubernetes cluster network link nanotube method in an embodiment of the present invention includes:
s100, creating Pod in the Kubernetes cluster, and injecting Sidecar containers into the Pod through OpenKruise.
In this embodiment, first, a user needs to define and issue simcarase yaml required by openkruis and PromQL configuration rules required by promethaus alarm in the system, when the user formally creates a Pod, the Pod normally includes an App application Container required by service operation, and when the Pod is created, openkruis judges and matches a label required by injection, and the Sidecar is injected into the created Pod. The OpenKruise is an expansion suite based on the Kubernetes, not only supports basic functions similar to the original works of the Kubernetes, but also provides in-place upgrading, configurable expansion/release strategies, concurrent operation and the like. Injection can be easily achieved by OpenKruise implementation of the nanotubes to the sidocar.
And S200, acquiring Pod network information in the Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and Pod.
In this embodiment, kubeSkoop is a Kubernetes network diagnostic tool, and a network access map of Pod in the Kubernetes cluster is automatically built for different network plug-ins and IaaS providers, so that Pod network information can be collected in the Kubernetes cluster through KubeSkoop exporter according to status information of Pod and Sidecar containers in the Pod.
S300, acquiring index data from KubeSkoop exporter through Prometaus according to a preset configuration file.
In this embodiment, kubeSkoop exporter monitors the data plane, and by defining a configuration preset configuration file prometheu. Yml, prometheus Server can obtain monitoring data (multi-dimensional index data) from the current KubeSkoop exporter, and the multi-dimensional index data can realize rapid discovery of service abnormality, wherein Prometheus Server is responsible for collecting, storing and querying the monitoring data. It periodically acquires index data from various data sources (e.g., applications, operating systems, containers, and other monitoring targets) and stores it in a built-in time-series database. The promethaus server also executes alarm rules, triggers alarms and sends notifications according to the rules.
S400, pushing alarm information to an alert manager according to the index data and a preset PromQL rule so as to locate abnormal Pod on a network link.
In this embodiment, kubeSkoop exporter reports the collected data to promethaus to implement an alarm through rule integration, and the cluster events are used to identify whether the status of Pod is normal, specifically, when the collected index data matches a PromQL configuration rule that is defined by a user in advance for alarm needs, the alarm is pushed to an alert manager, and then the alert manager can suppress, group, silence or send notification to a corresponding receiver according to the configured rule, so that the user can quickly locate network anomaly information related to the corresponding Pod, where PromQL is used to query and analyze stored monitoring data, and is a query language of promethaus, supporting rich operations and aggregation functions, so that the user can perform advanced query, data analysis and alarm setting.
In an alternative embodiment of the first aspect of the present invention, collecting Pod network information in the Kubernetes cluster by KubeSkoop exporter according to the Sidecar container and Pod includes:
checking whether Pod is already running; if so, checking whether the Sidecar container in the Pod is started normally; if yes, pod network information is collected in the Kubernetes cluster through KubeSkoop exporter.
In this embodiment, after the App application container for service operation of the Pod is normally started, after the KubeSkoop exporter Sidecar container is also normally started, the Pod state Running and the Containers in the Pod are normally started and the state is status.
In an alternative embodiment of the first aspect of the present invention, creating a Pod in the Kubernetes cluster, and injecting the Sidecar container into the Pod by OpenKruise includes:
deploying OpenKruise, and acquiring SidecarSet resources in the OpenKruise; creating a Pod in a Kubernetes cluster; injecting the Sidecar container into the Pod according to the Sidecar set resource.
In this embodiment, the sidecar set can help to inject a particular sidecar container at the time of creation of all matching Pod, even to upgrade sidecar container images already injected in place, and without affecting other containers in the Pod. The invention can automatically inject the sidecar container for the Pod which meets the conditions and is created in the cluster through admission webhook, and after the OpenKruis is deployed, a user can define the sidecar set resources in the OpenKruis to set which Pod to inject sidecar containers for the subsequent creation.
In an optional implementation manner of the first aspect of the present invention, according to a preset configuration file, obtaining, by promethaus, the index data from KubeSkoop exporter includes:
instantiating KubeSkoop exporter as a monitoring target by promethaus; setting Prometaus acquisition indexes, and defining configuration to obtain a preset configuration file; and acquiring index data from the monitoring target according to the preset configuration file.
In this embodiment, by promethaus, instantiation KubeSkoop exporter is used as a monitoring target, specifically, the procedure of providing monitoring sample data to promethaus may be referred to as an exporter, and an instance of exporter is referred to as a target, and the exporter is KubeSkoop exporter, and exporter does not deliver an acquisition index to promethaus, and by defining configuration promethaus.yml, prometheus Server can obtain monitoring data from current KubeSkoop exporter (i.e. configuration target).
In an optional implementation manner of the first aspect of the present invention, according to a preset configuration file, acquiring the index data from the monitoring target includes:
acquiring association information of the Pod through a CRI interface; according to a preset configuration file, monitoring a kernel event of the Pod network by a monitoring target through an eBPF; and analyzing a preset network protocol according to the kernel event to obtain index data.
In this embodiment, the network isolation state in the node and the association information between the network isolation state and the Pod are obtained through the CRI interface, the kernel event of the compiled eBPF program monitoring Pod network is loaded and compiled according to the preset configuration file, the network protocol is resolved, and then the network protocol is aggregated into an index, and the Trace is output. The eBPF is a technology capable of safely running a sandbox program in a kernel, and running the sandbox program when a kernel user mode program event occurs without modifying codes. The method can realize non-invasive and non-invasive Kernel Montor (Kernel monitoring) acquisition of Pod network information because no code is required to be modified and the process is not required to be restarted.
In an optional implementation manner of the first aspect of the present invention, pushing the alert information to the alert manager according to the index data and the preset PromQL rule to locate the abnormal Pod on the network link includes:
issuing a preset PromQL rule to Prometheus; executing a preset PromQL rule by Prometaus to judge whether index data hit the preset PromQL rule; if yes, sending alarm information to an alert manager, and locating abnormal Pod on a network link through visual index data.
In this embodiment, the user needs to configure the rule to issue to the promthens in advance, so that whether to alarm is detected and judged according to the rule defined by the user, for example, the following judgment alarm rule (1-sum (node_cpu_seconds_total { mode= "idle" } [1m ])) by (instance)/sum (node_cpu_seconds_total [1m ]) by (instance)) > 100>50. In fact, by defining the configuration promethaus. Yml, prometheus Server can obtain the monitoring data from the current KubeSkoop exporter, these individual data indexes may be called metrics, and these metrics are collected and stored. The alarm rule issued to Prometheus is to execute the corresponding rule to collect the metrics and then judge whether to alarm.
In an optional embodiment of the first aspect of the present invention, if the Sidecar container is upgraded, a new image corresponding to the Sidecar container is obtained, and the Sidecar container in the Pod is rebuilt through the new image; configuration information of the rebuilt Sidecar container is monitored by KubeSkoop exporter.
In this embodiment, openKruise provides an in-place upgrade function, which is a completely new way to upgrade application container images and even environmental variables. It will reconstruct a particular container in the Pod with the new mirror image and the entire Pod, as well as other containers therein, will not be affected. It results in faster release speeds and avoids the negative impact on other Scheduler, CNI, CSI components. The configuration information of the rebuilt sidocar container is monitored through KubeSkoop exporter to determine if the rebuilt sidocar container is configured in error.
Referring to fig. 2, a second aspect of the present invention provides a Kubernetes clustered network link nanotube apparatus, the Kubernetes clustered network link nanotube apparatus comprising:
a container injection module 100, configured to create Pod in the Kubernetes cluster, and inject Sidecar containers into the Pod by openkruis, where the Pod is formed by injecting a plurality of Sidecar containers;
the network information acquisition module 200 is configured to acquire Pod network information in the Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and Pod;
the index data acquisition module 300 is configured to acquire index data from KubeSkoop exporter through promethaus according to a preset configuration file, where the index data is KubeSkoop exporter monitored target Pod data;
the anomaly locating module 400 is configured to push alarm information to the alert manager according to the index data and a preset PromQL rule, so as to locate an anomaly Pod on the network link.
In an alternative embodiment of the second aspect of the present invention, the network information collecting module 200 is further configured to check whether the Pod is already running; if so, checking whether the Sidecar container in the Pod is started normally; if yes, pod network information is collected in the Kubernetes cluster through KubeSkoop exporter.
In an alternative embodiment of the second aspect of the present invention, the container injection module 100 is further configured to deploy OpenKruise and obtain SidecarSet resources in OpenKruise; creating a Pod in a Kubernetes cluster; injecting the Sidecar container into the Pod according to the Sidecar set resource.
In an alternative embodiment of the second aspect of the present invention, the index data collection module 300 is further configured to instantiate KubeSkoop exporter as a monitoring target by promethaus; setting Prometaus acquisition indexes, and defining configuration to obtain a preset configuration file; and acquiring index data from the monitoring target according to the preset configuration file.
In an optional embodiment of the second aspect of the present invention, the index data collection module 300 is further configured to obtain association information of Pod through a CRI interface; according to a preset configuration file, monitoring a kernel event of the Pod network by a monitoring target through an eBPF; and analyzing a preset network protocol according to the kernel event to obtain index data.
In an alternative embodiment of the second aspect of the present invention, the anomaly locating module 400 is further configured to issue a preset PromQL rule to promethaus; executing a preset PromQL rule by Prometaus to judge whether index data hit the preset PromQL rule; if yes, sending alarm information to an alert manager, and locating abnormal Pod on a network link through visual index data.
In an alternative embodiment of the second aspect of the present invention, the Kubernetes cluster network link nanotube device further includes:
the container upgrading module is used for acquiring a new image corresponding to the Sidecar container if the Sidecar container is upgraded, and rebuilding the Sidecar container in the Pod through the new image; configuration information of the rebuilt Sidecar container is monitored by KubeSkoop exporter.
Fig. 3 is a schematic structural diagram of a Kubernetes trunking network link nanotube device according to an embodiment of the present invention, where the Kubernetes trunking network link nanotube device 500 may have a relatively large difference due to different configurations or performances, and may include one or more processors (central processing units, CPU) 510 (e.g., one or more processors) and a memory 520, and one or more storage media 530 (e.g., one or more mass storage devices) storing application programs 533 or data 532. Wherein memory 520 and storage medium 530 may be transitory or persistent storage. The program stored on the storage medium 530 may include one or more modules (not shown), each of which may include a series of instruction operations on the Kubernetes clustered network link nanotube device 500. Still further, the processor 510 may be arranged to communicate with the storage medium 530 to execute a series of instruction operations in the storage medium 530 on the Kubernetes clustered network link nanotube device 500.
Kubernetes-based clustered network link nanotube device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input/output interfaces 560, and/or one or more operating systems 531, such as Windows service, mac OS X, unix, linux, free BSD, and the like. Those skilled in the art will appreciate that the Kubernetes-based clustered network link nanotube device structure shown in fig. 3 is not limiting and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.
The present invention also provides a computer readable storage medium, which may be a non-volatile computer readable storage medium, and may also be a volatile computer readable storage medium, where instructions are stored in the computer readable storage medium, when the instructions are executed on a computer, cause the computer to perform the steps of the Kubernetes cluster network link nanotube method.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Moreover, although operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims.
Claims (10)
1. The Kubernetes cluster network link nanotube method is characterized by comprising the following steps of:
creating a Pod in a Kubernetes cluster, and injecting a Sidecar container into the Pod through OpenKruise, wherein the Pod is formed by injecting a plurality of Sidecar containers;
acquiring Pod network information in a Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and the Pod;
acquiring index data from the KubeSkoop exporter through Prometaus according to a preset configuration file, wherein the index data refers to target Pod data monitored by the KubeSkoop exporter;
and pushing alarm information to an alert manager according to the index data and a preset PromQL rule so as to locate abnormal Pod on a network link.
2. The Kubernetes cluster network link nanotube method of claim 1, wherein the collecting Pod network information in the Kubernetes cluster by KubeSkoop exporter according to the Sidecar container and the Pod comprises:
checking whether the Pod is already running;
if so, checking whether the Sidecar container in the Pod is started normally;
if yes, pod network information is collected in the Kubernetes cluster through KubeSkoop exporter.
3. The Kubernetes cluster network link nanotube method of claim 1, wherein creating a Pod in the Kubernetes cluster and injecting a Sidecar container into the Pod by openkruis comprises:
deploying OpenKruise, and acquiring SidecarSet resources in the OpenKruise;
creating a Pod in a Kubernetes cluster;
and injecting the Sidecar container into the Pod according to the Sidecar set resource.
4. The Kubernetes trunking network link nanotube method of claim 1, wherein the obtaining, from the KubeSkoop exporter, the index data via promethaus according to a preset profile comprises:
instantiating the KubeSkoop exporter as a monitoring target by promethaus;
setting Prometaus acquisition indexes, and defining configuration to obtain a preset configuration file;
and acquiring index data from the monitoring target according to the preset configuration file.
5. The Kubernetes trunking network link nanotube method of claim 4, wherein the obtaining the index data from the monitoring target according to the preset configuration file comprises:
acquiring the association information of the Pod through a CRI interface;
according to the preset configuration file, monitoring a kernel event of the Pod network by the monitoring target through the eBPF;
and analyzing a preset network protocol according to the kernel event to obtain index data.
6. The Kubernetes trunking network link nanotube method of claim 1, wherein pushing the alert message to the alert manager to locate the abnormal Pod on the network link according to the index data and the preset PromQL rule comprises:
issuing a preset PromQL rule to the Prometheus;
executing the preset PromQL rule through the Prometaus to judge whether the index data hits the preset PromQL rule or not;
if yes, sending alarm information to an alert manager, and locating abnormal Pod on a network link through visual index data.
7. The Kubernetes trunking network link nanotube method of claim 1, wherein if the Sidecar container is upgraded, obtaining a new image corresponding to the Sidecar container, and rebuilding the Sidecar container in the Pod by the new image; and monitoring configuration information of the rebuilt Sidecar container through the KubeSkoop exporter.
8. A Kubernetes clustered network link nanotube device, the Kubernetes clustered network link nanotube device comprising:
a container injection module, configured to create a Pod in a Kubernetes cluster, and inject Sidecar containers into the Pod through OpenKruise, where the Pod is formed by injecting a plurality of Sidecar containers;
the network information acquisition module is used for acquiring Pod network information in a Kubernetes cluster through KubeSkoop exporter according to the Sidecar container and the Pod;
the index data acquisition module is used for acquiring index data from the KubeSkoop exporter through Prometaus according to a preset configuration file, wherein the index data refer to target Pod data monitored by the KubeSkoop exporter;
and the abnormality positioning module is used for pushing alarm information to the alert manager according to the index data and a preset PromQL rule so as to position an abnormal Pod on a network link.
9. A Kubernetes clustered network link nanotube device, the Kubernetes clustered network link nanotube device comprising: a memory and at least one processor, the memory having instructions stored therein, the memory and the at least one processor being interconnected by a line;
the at least one processor invoking the instructions in the memory to cause the Kubernetes clustered network link nanotube device to perform the Kubernetes clustered network link nanotube method of any of claims 1-7.
10. A computer readable storage medium having stored thereon a computer program, which when executed by a processor implements the Kubernetes cluster network link nanotube method of any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311836991.2A CN117640359A (en) | 2023-12-27 | 2023-12-27 | Kubernetes cluster network link nano-tube method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311836991.2A CN117640359A (en) | 2023-12-27 | 2023-12-27 | Kubernetes cluster network link nano-tube method, device, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117640359A true CN117640359A (en) | 2024-03-01 |
Family
ID=90020078
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311836991.2A Pending CN117640359A (en) | 2023-12-27 | 2023-12-27 | Kubernetes cluster network link nano-tube method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117640359A (en) |
-
2023
- 2023-12-27 CN CN202311836991.2A patent/CN117640359A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10810074B2 (en) | Unified error monitoring, alerting, and debugging of distributed systems | |
| US10503623B2 (en) | Monitoring containerized applications | |
| US9459995B2 (en) | Compliance testing engine for integrated computing system | |
| US8166458B2 (en) | Method and system for automated distributed software testing | |
| US11323463B2 (en) | Generating data structures representing relationships among entities of a high-scale network infrastructure | |
| WO2020024376A1 (en) | Method and device for processing operation and maintenance monitoring alarm | |
| US10848839B2 (en) | Out-of-band telemetry data collection | |
| US8521865B2 (en) | Method and apparatus for populating a software catalog with automated use signature generation | |
| CN114189430A (en) | Three-dimensional log full-link monitoring system, method, medium and equipment | |
| US9548891B2 (en) | Configuration of network devices | |
| WO2016188100A1 (en) | Information system fault scenario information collection method and system | |
| US9058330B2 (en) | Verification of complex multi-application and multi-node deployments | |
| US10951509B1 (en) | Methods, systems, and computer readable media for providing intent-driven microapps for execution on communications network testing devices | |
| CN109218401B (en) | Log collection method, system, computer device and storage medium | |
| WO2018106555A1 (en) | Device driver telemetry | |
| CN112148616B (en) | Performance test management platform | |
| CN111177239B (en) | Unified log processing method and system based on HDP big data cluster | |
| US10848371B2 (en) | User interface for an application performance management system | |
| CN117640359A (en) | Kubernetes cluster network link nano-tube method, device, equipment and storage medium | |
| CN115994075A (en) | Unified observable method and system for heterogeneous micro-service system | |
| CN116414594A (en) | Fault tree updating method, device, computer equipment and storage medium | |
| CN114816914A (en) | Data processing method, equipment and medium based on Kubernetes | |
| US20220405115A1 (en) | Server and application monitoring | |
| WO2022214200A1 (en) | Method and network element for pre-upgrade use case validation | |
| CN112882892A (en) | Data processing method and device, electronic equipment and storage medium |
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 |