Method and apparatus for collecting metrics for a container cluster

Abstract

The embodiment of the present specification provides a kind of method and device for the index collection of container cluster, method includes: controller obtains the message that first node is online from the center node for managing the container cluster by listening mechanism;The first node is the node in container cluster;First customized resource is created for the first node in the container cluster, and the address of first index collection component is deployed in the first customized resource;So that the index data of the container in the first node is pushed to the first index collection component.Can meet the performance requirement of index collection component and guarantee the uniqueness of data.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computers, and more particularly to a method and apparatus for collecting metrics for container clusters. Background Technology

[0002] Container clusters are typically implemented using a management system. For example, Kubernetes (k8s) is an open-source container cluster management system used to automatically deploy, scale, and manage containerized applications. Container clusters can be used to perform privacy-preserving computing tasks.

[0003] In network isolation scenarios, data analysis systems often cannot directly collect metric data from containers in a container cluster. A metric collection component can be provided to collect metric data first, and then the data analysis system can collect the metric data from the metric collection component.

[0004] The query per second (QPS) rate of the metric collection component is not high. However, as the number of nodes and containers increases in computing scenarios, the metric collection component can be deployed with multiple replicas to meet performance requirements. In multi-replica deployments, it is often difficult to guarantee data uniqueness. Therefore, a solution is needed that can meet the performance requirements of the metric collection component while ensuring data uniqueness. Summary of the Invention

[0005] This specification describes one or more embodiments of a method and apparatus for collecting metrics for container clusters, which can meet the performance requirements of the metric collection component and ensure the uniqueness of the data.

[0006] Firstly, a method for collecting metrics for container clusters is provided, which is executed by the controller and includes:

[0007] The system uses a listening mechanism to obtain a message that the first node has come online from the central node used to manage the container cluster; the first node is a node in the container cluster.

[0008] In the container cluster, a first custom resource is created exclusively for the first node, and the address of the first indicator collection component is deployed in the first custom resource; so that the indicator data of the containers in the first node can be pushed to the first indicator collection component.

[0009] In one possible implementation, the container cluster also includes a second custom resource dedicated to the second node, in which the address of the first metric collection component is deployed.

[0010] In one possible implementation, the monitoring mechanism is a list / watch mechanism; before receiving the message that the first node has come online, it also includes:

[0011] The central node is requested to listen for messages about new nodes coming online via a list mechanism.

[0012] The message indicating that the first node has come online includes:

[0013] A long-lived connection established through the watch mechanism receives a first event notification from the central node, which indicates that the first node has come online.

[0014] In one possible implementation, the first custom resource is a namespace-level CRD.

[0015] In one possible implementation, the name of the first customized resource is the name of the first node or the name of the host where the first node is located.

[0016] In one possible implementation, the container cluster is used to perform privacy-preserving computation tasks.

[0017] In one possible implementation, the container is implemented within a pod.

[0018] In one possible implementation, the first metric collection component is deployed at the central node.

[0019] Secondly, a method for collecting metrics from container clusters is provided. This method is executed by the target container in a first node, which is a node in the container cluster. The method includes:

[0020] Through a listening mechanism, a message indicating that the first custom resource exclusively for the first node has been created is obtained from the central node used to manage the container cluster.

[0021] Obtain the address of the first indicator collection component from the first customized resource;

[0022] Based on the address, the metric data of the target container is pushed to the first metric collection component.

[0023] In one possible implementation, the monitoring mechanism is a list / watch mechanism; before obtaining the message that the first custom resource exclusively for the first node has been created, the method further includes:

[0024] The first name is reported to the central node through the list mechanism. The first name is either the name of the first node or the name of the host where the first node is located.

[0025] The message indicating that the first customized resource exclusively for the first node has been created includes:

[0026] A long connection established through the watch mechanism receives a second event notification from the central node, the second event notification indicating that a first custom resource with the first name has been created.

[0027] In one possible implementation, the container cluster is used to perform privacy-preserving computation tasks.

[0028] In one possible implementation, the container is implemented within a pod.

[0029] In one possible implementation, the metric data includes one or more of the following: CPU, memory, disk space, and network bandwidth used by the container.

[0030] Thirdly, a method for collecting metrics for container clusters is provided. This method is executed by an aggregation tool in a first node, which is a node in the container cluster. The method includes:

[0031] Through a listening mechanism, a message indicating that the first custom resource exclusively for the first node has been created is obtained from the central node used to manage the container cluster.

[0032] Obtain the address of the first indicator collection component from the first customized resource;

[0033] Receive the respective running metric data pushed to it by multiple containers of the first node, and aggregate them to obtain aggregated data;

[0034] Based on the address, the aggregated data is pushed to the first indicator collection component.

[0035] In one possible implementation, the aggregation tool is embodied as a container in the first node.

[0036] Fourthly, a metric collection device for container clusters is provided, which is located on the controller and includes:

[0037] The listening unit is used to obtain the message that the first node is online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster.

[0038] A creation unit is used to create a first custom resource exclusively for the first node monitored by the monitoring unit in the container cluster. The first custom resource contains the address of the first indicator collection component, so that the indicator data of the containers in the first node can be pushed to the first indicator collection component.

[0039] Fifthly, a metric collection device for a container cluster is provided. This device is installed in a target container within a first node, where the first node is a node in the container cluster. The device includes:

[0040] The listening unit is used to obtain, through a listening mechanism, a message from the central node that manages the container cluster that the first custom resource exclusively for the first node has been created;

[0041] The address acquisition unit is used to obtain the address of the first indicator collection component from the first customized resource monitored by the monitoring unit;

[0042] The push unit is used to push the target container's running indicator data to the first indicator collection component based on the address obtained by the address acquisition unit.

[0043] Sixthly, a metric collection device for container clusters is provided, wherein the device is an aggregation tool installed in a first node, the first node being a node in the container cluster, and the device includes:

[0044] The listening unit is used to obtain, through a listening mechanism, a message from the central node that manages the container cluster that the first custom resource exclusively for the first node has been created;

[0045] The address acquisition unit is used to obtain the address of the first indicator collection component from the first customized resource monitored by the monitoring unit;

[0046] The aggregation unit is used to receive the respective running metric data pushed to it by multiple containers of the first node, and aggregate them to obtain aggregated data.

[0047] The push unit is used to push the aggregated data obtained by the aggregation unit to the first indicator collection component based on the address obtained by the address acquisition unit.

[0048] In a seventh aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of the first to third aspects.

[0049] Eighthly, a computing device is provided, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, it implements the method of any one of the first to third aspects.

[0050] According to the method and apparatus provided in the embodiments of this specification, the controller first obtains a message that a first node has come online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; then, a first custom resource dedicated to the first node is created in the container cluster, and the address of a first indicator collection component is deployed in the first custom resource; so that the indicator data of the containers in the first node is pushed to the first indicator collection component; then, the target container in the first node obtains a message that the first custom resource dedicated to the first node has been created from the central node used to manage the container cluster through the listening mechanism; then, the address of the first indicator collection component is obtained from the first custom resource; finally, the indicator data of the target container is pushed to the first indicator collection component according to the address. As can be seen from the above, in the embodiments of this specification, by creating a dedicated custom resource for a node in the container cluster, the containers on the node can know their corresponding indicator collection component, realizing a feasible load balancing scheme with nodes as the granularity. After the indicator collection component is deployed in multiple replicas, the indicator data of each container on the node can always be pushed to the designated indicator collection component, ensuring the uniqueness of the data, thereby meeting the performance requirements of the indicator collection component and ensuring the uniqueness of the data.

[0051] According to another method and apparatus provided in the embodiments of this specification, the controller first obtains a message that a first node has come online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; then, a first custom resource dedicated to the first node is created in the container cluster, and the address of a first indicator collection component is deployed in the first custom resource; so that the indicator data of the containers in the first node are pushed to the first indicator collection component; then, the aggregation tool in the first node obtains a message that the first custom resource dedicated to the first node has been created from the central node used to manage the container cluster through the listening mechanism; then, it obtains the address of the first indicator collection component from the first custom resource; then, it receives the indicator data of each running container pushed to it by multiple containers of the first node, and aggregates it to obtain aggregated data; finally, according to the address, the aggregated data is pushed to the first indicator collection component. As can be seen from the above, in the embodiments of this specification, the containers on the nodes do not perceive the existence of customized resources through a listening mechanism. Instead, an aggregation tool is first deployed on the nodes to aggregate the metric data of multiple containers on the nodes and then push them together to the metric receiving component. Therefore, only the aggregation tool needs to perceive the existence of customized resources, which can not only meet the performance requirements of the metric collection component and ensure the uniqueness of the data, but also help reduce development costs and container access costs. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0054] Figure 2 This diagram illustrates an interactive method for collecting metrics from a container cluster according to one embodiment.

[0055] Figure 3 This diagram illustrates an interactive method for collecting metrics from a container cluster according to another embodiment.

[0056] Figure 4 This diagram illustrates an interactive method for collecting metrics from a container cluster according to another embodiment.

[0057] Figure 5 A schematic block diagram of an indicator collection device for a container cluster according to one embodiment is shown;

[0058] Figure 6 A schematic block diagram of an indicator collection apparatus for a container cluster according to another embodiment is shown;

[0059] Figure 7 A schematic block diagram of a metrics collection apparatus for a container cluster according to another embodiment is shown. Detailed Implementation

[0060] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0061] Figure 1This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification. This implementation scenario involves metric collection for container clusters, which can be implemented, but is not limited to, based on a Kubernetes management system. A data analysis system is used to collect metric data from containers within the container cluster. In network isolation scenarios, the data analysis system often cannot directly collect metric data from containers within the container cluster. This can be addressed by providing a metric collection component, allowing metric data to be temporarily aggregated within this component, awaiting collection from the data analysis system. For example, Prometheus: an open-source system monitoring and alerting system that provides data storage and analysis functions. Pushgateway: an open-source metric collection component provided by Prometheus, where metric data can be temporarily aggregated, awaiting collection by Prometheus. In network isolation scenarios, this solves the problem of Prometheus being unable to directly collect metric data. Grafana: an open-source monitoring dashboard display system.

[0062] The open-source Pushgateway component has low QPS, and as the number of nodes and pods in computing scenarios increases, a single-replica deployment of Pushgateway cannot meet performance requirements. However, Pushgateway is stateful because the metric data is time-series data, meaning it can only exist once across all replicas and be updated periodically. A simple multi-replica deployment, where metric data can be pushed to any Pushgateway replica, would result in data redundancy. When Prometheus collects metric data from multiple Pushgateway replicas, it cannot determine which replica's data is usable. Therefore, this specification proposes a feasible node-level load balancing scheme in its implementation examples. After deploying Pushgateway with multiple replicas, this scheme ensures that metric data from each pod on a node is always pushed to a designated Pushgateway, guaranteeing data uniqueness.

[0063] Reference Figure 1The pushgateway uses a multi-replica deployment, with multiple replicas designated as pushgateway-1, pushgateway-2, and pushgateway-3. Nodes node-1, node-2, and node-3 are assigned the replica pushgateway-1, and all nodes push pod metrics data to pushgateway-1 through service svc-1. Nodes node-4 and node-5 are assigned the replica pushgateway-2, and both nodes push pod metrics data to pushgateway-2 through service svc-2. Nodes node-6 and node-7 are assigned the replica pushgateway-3, and both nodes push pod metrics data to pushgateway-3 through service svc-3.

[0064] Because the metric data of the same pod cannot exist in multiple pushgateways, otherwise it will cause data chaos when collecting metrics, pushgateways cannot be horizontally scaled, and nodes need to know which pushgateway they are bound to.

[0065] This specification's embodiments define a custom resource unique to each node to help the node know which pushgateway it corresponds to.

[0066] In the embodiments described in this specification, the container cluster can be a platform for orchestrating, deploying, and managing various applications in a multi-party secure computing scenario. It is a cross-organizational Kubernetes cluster, where the Kubernetes master is located at the central node, responsible for managing, scheduling, and coordinating the resources and status of the entire cluster. Kubernetes nodes are located at downstream nodes, deployed at the main site and various partner institutions, responsible for executing offline training tasks and running online model services.

[0067] In this context, nodes can be privacy-preserving computation nodes. Privacy-preserving computation nodes are single machines or clusters deployed within organizations that possess the data in multi-party secure computation scenarios, executing privacy-preserving computation protocol algorithms. Through connectivity between these nodes, cross-organizational privacy-preserving computation is achieved.

[0068] Privacy computing is a computational theory and method for protecting privacy information throughout its entire lifecycle. Specifically, it refers to the description, measurement, evaluation, and fusion of privacy information involved in the processing of information such as video, audio, images, graphics, text, numerical values, and ubiquitous network behavioral information streams. This forms a set of symbolic, formulaic privacy computing theories, algorithms, and application technologies with quantitative evaluation standards, supporting privacy information protection across multiple systems.

[0069] In the embodiments described in this specification, applications can be deployed in containers. An application is a program that performs a specific function, such as model training, model prediction, or data feedback. It may be executed as a short job or may be permanently hosted as a service.

[0070] Multi-party secure computation: Under the premise of meeting data security, privacy protection, and regulatory compliance requirements, it utilizes cryptographic algorithms such as secret sharing, obfuscated circuits, and homomorphic encryption to ensure that data from multiple parties remains within its own domain, thereby unlocking data value. It is understood that the data from each party is private data, which can be any data that is not suitable for public disclosure, including but not limited to data representing users' personal information or trade secrets.

[0071] Figure 2 This diagram illustrates an interactive method for collecting metrics from a container cluster according to one embodiment. The method can be based on... Figure 1 The implementation scenario shown mainly involves the processing of the target container in the controller and the first node, where the container on the node is aware of its corresponding metric collection component. For example... Figure 2 As shown, the metric collection method for container clusters in this embodiment includes the following steps: Step 21, the controller obtains a message that a first node is online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; Step 22, the controller creates a dedicated first customized resource for the first node in the container cluster, and the address of the first metric collection component is deployed in the first customized resource; so that the metric data of the containers in the first node are pushed to the first metric collection component; Step 23, the target container in the first node obtains a message that the dedicated first customized resource for the first node has been created from the central node used to manage the container cluster through a listening mechanism; Step 24, the target container in the first node obtains the address of the first metric collection component from the first customized resource; Step 25, the target container in the first node pushes the metric data of the target container to the first metric collection component according to the address. The specific execution method of each of the above steps is described below.

[0072] First, in step 21, the controller obtains a message from the central node managing the container cluster indicating that the first node has come online through a listening mechanism; the first node is a node in the container cluster. It is understood that one or more nodes can come online at the same time. For example, the controller obtains messages from the central node managing the container cluster indicating that the first and second nodes have come online through a listening mechanism.

[0073] In one example, the listening mechanism is a list / watch mechanism; before receiving the message that the first node has come online, it also includes:

[0074] The central node is requested to listen for messages about new nodes coming online via a list mechanism.

[0075] The message indicating that the first node has come online includes:

[0076] A long-lived connection established through the watch mechanism receives a first event notification from the central node, which indicates that the first node has come online.

[0077] In one example, the container cluster is used to perform privacy-preserving computation tasks.

[0078] In one example, the container is implemented in a pod.

[0079] Then, in step 22, the controller creates a dedicated first custom resource for the first node in the container cluster. This first custom resource contains the address of the first metric collection component, so that metric data from the containers in the first node is pushed to the first metric collection component. It is understood that the metric collection component is deployed with multiple replicas; for example, a second metric collection component may also be deployed. Metric data from the containers in the first node will not be pushed to the second metric collection component.

[0080] In one example, the container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

[0081] In this example, the first metric collection component corresponds to both the first node and the second node. The metric data of the containers in the first node and the containers in the second node will be pushed to the first metric collection component.

[0082] In one example, the first custom resource is a namespace-level CRD.

[0083] In Kubernetes, namespaces provide a mechanism to divide resources within the same cluster into isolated groups. Resource names within the same namespace must be unique, but this requirement does not apply when crossing namespaces.

[0084] In one example, the name of the first customized resource is the name of the first node or the name of the host where the first node is located.

[0085] In one example, the first metric collection component is deployed at the central node.

[0086] Next, in step 23, the target container in the first node obtains a message from the central node that manages the container cluster, indicating that the first custom resource exclusively for the first node has been created, through a listening mechanism. It is understood that the target container can be any container in the first node.

[0087] In one example, the listening mechanism is a list / watch mechanism; before obtaining the message that the first custom resource exclusively for the first node has been created, the process also includes:

[0088] The first name is reported to the central node through the list mechanism. The first name is either the name of the first node or the name of the host where the first node is located.

[0089] The message indicating that the first customized resource exclusively for the first node has been created includes:

[0090] A long connection established through the watch mechanism receives a second event notification from the central node, the second event notification indicating that a first custom resource with the first name has been created.

[0091] In step 24, the target container in the first node obtains the address of the first metric collection component from the first customized resource. It is understood that the address of the first metric collection component can be configured according to a load balancing strategy.

[0092] The address of the first indicator collection component can be identified by its hostname and / or port number.

[0093] Finally, in step 25, the target container in the first node pushes the metric data it is running to the first metric collection component according to the address. It is understood that when the metric collection component is deployed with multiple replicas, the metric data of the target container is only pushed to the first metric collection component and not to other metric collection components.

[0094] In one example, the metric data includes one or more of the following: CPU, memory, disk space, and network bandwidth used by the container.

[0095] According to the method and apparatus provided in the embodiments of this specification, the controller first obtains a message that a first node has come online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; then, a first custom resource dedicated to the first node is created in the container cluster, and the address of a first indicator collection component is deployed in the first custom resource; so that the indicator data of the containers in the first node is pushed to the first indicator collection component; then, the target container in the first node obtains a message that the first custom resource dedicated to the first node has been created from the central node used to manage the container cluster through the listening mechanism; then, the address of the first indicator collection component is obtained from the first custom resource; finally, the indicator data of the target container is pushed to the first indicator collection component according to the address. As can be seen from the above, in the embodiments of this specification, by creating a dedicated custom resource for a node in the container cluster, the containers on the node can know their corresponding indicator collection component, realizing a feasible load balancing scheme with nodes as the granularity. After the indicator collection component is deployed in multiple replicas, the indicator data of each container on the node can always be pushed to the designated indicator collection component, ensuring the uniqueness of the data, thereby meeting the performance requirements of the indicator collection component and ensuring the uniqueness of the data.

[0096] Figure 3 This diagram illustrates an interaction of a metric collection method for container clusters according to another embodiment, which can be based on... Figure 1 The implementation scenario shown mainly involves the processing of the aggregation tool in the controller and the first node, where the aggregation tool on the node is aware of its corresponding metric collection component. For example... Figure 3As shown, the metric collection method for container clusters in this embodiment includes the following steps: Step 31, the controller obtains a message that a first node is online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; Step 32, the controller creates a dedicated first customized resource for the first node in the container cluster, and the address of the first metric collection component is deployed in the first customized resource; so that the metric data of the containers in the first node are pushed to the first metric collection component; Step 33, the aggregation tool in the first node obtains a message that the dedicated first customized resource for the first node has been created from the central node used to manage the container cluster through a listening mechanism; Step 34, the aggregation tool in the first node obtains the address of the first metric collection component from the first customized resource; Step 35, the aggregation tool in the first node receives the respective running metric data pushed to it by multiple containers of the first node, and aggregates them to obtain aggregated data; Step 36, the aggregation tool in the first node pushes the aggregated data to the first metric collection component according to the address. The specific execution method of each of the above steps is described below.

[0097] First, in step 31, the controller obtains a message that the first node is online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster.

[0098] Then in step 32, the controller creates a first custom resource dedicated to the first node in the container cluster, in which the address of the first metric collection component is deployed, so that the metric data of the containers in the first node can be pushed to the first metric collection component.

[0099] It is understandable that step 31 is the same as step 21, and step 32 is the same as step 22, so they will not be repeated here.

[0100] Next, in step 33, the aggregation tool in the first node obtains a message from the central node used to manage the container cluster that the first customized resource exclusively for the first node has been created through a listening mechanism. It is understood that only the aggregation tool in the first node needs to be aware of the first customized resource, without the individual pods in the first node needing to be aware of it.

[0101] In one example, the aggregation tool is embodied as a container in the first node.

[0102] In step 34, the aggregation tool in the first node obtains the address of the first metric collection component from the first customized resource. It is understood that only the aggregation tool in the first node needs to obtain the address of the first metric collection component; it is not necessary for each pod in the first node to obtain the address of the first metric collection component.

[0103] Then, in step 35, the aggregation tool in the first node receives the respective running metric data pushed to it by multiple containers of the first node, and aggregates them to obtain aggregated data. It can be understood that the aggregated data includes metric data from multiple containers.

[0104] Finally, in step 36, the aggregation tool in the first node pushes the aggregated data to the first metric collection component based on the address. It is understood that only the aggregation tool in the first node needs to push the aggregated data to the first metric collection component, without each pod in the first node needing to push the aggregated data to the first metric collection component.

[0105] According to another method and apparatus provided in the embodiments of this specification, the controller first obtains a message that a first node has come online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster; then, a first custom resource dedicated to the first node is created in the container cluster, and the address of a first indicator collection component is deployed in the first custom resource; so that the indicator data of the containers in the first node are pushed to the first indicator collection component; then, the aggregation tool in the first node obtains a message that the first custom resource dedicated to the first node has been created from the central node used to manage the container cluster through the listening mechanism; then, it obtains the address of the first indicator collection component from the first custom resource; then, it receives the indicator data of each running container pushed to it by multiple containers of the first node, and aggregates it to obtain aggregated data; finally, according to the address, the aggregated data is pushed to the first indicator collection component. As can be seen from the above, in the embodiments of this specification, the containers on the nodes do not perceive the existence of customized resources through a listening mechanism. Instead, an aggregation tool is first deployed on the nodes to aggregate the metric data of multiple containers on the nodes and then push them together to the metric receiving component. Therefore, only the aggregation tool needs to perceive the existence of customized resources, which can not only meet the performance requirements of the metric collection component and ensure the uniqueness of the data, but also help reduce development costs and container access costs.

[0106] Figure 4 This diagram illustrates an interaction of a metric collection method for container clusters according to another embodiment, which can be based on... Figure 1 The implementation scenario shown primarily involves the interaction between the controller, customized resources, central node, downstream nodes, and metric collection components. Downstream nodes are simply referred to as nodes, and the containers on these nodes are aware of their corresponding metric collection components. For example... Figure 4As shown, the metric collection method for the container cluster in this embodiment includes the following process: First, nodes node-1 and node-2 come online. The metricsserver controller (or simply controller) detects that nodes-1 and node-2 are online through a list / watch mechanism. Then, the controller creates namespace-level CRDs for the two nodes, called custom resources called metricsservers. Next, the pods on the nodes detect the creation of the custom resources metricservers through a list / watch mechanism and resolve the access address of the metric collection component pushgateway from it. Finally, the pods on the nodes push the metrics to the corresponding pushgateway.

[0107] The custom resource `metricsserver` can include the access address of a metrics collection component, `pushgateway`. The controller fills in the address of the `pushgateway` component according to the load balancing strategy. The name of the custom resource `metricsserver` is based on the node name or hostname, etc., so that pods on the node can quickly find the mapping between the CRD and the node.

[0108] The following is an example of a customized resource, metricssserser, as described in this specification:

[0109] "apiVersion:kuscia.secretflow / v1

[0110] kind:MetricsServer

[0111] metadata:

[0112] name:alice-xxxxxx

[0113] namespace:alice

[0114] spec:

[0115] pushgateway:

[0116] host:test.alipay.com

[0117] port:9091

[0118] status:

[0119] nodeStatus:ready

[0120] Understandably, "host:test.alipay.com" and "port:9091" identify the address of the metrics collection component.

[0121] In the embodiments described in this specification, the controller no longer needs to be aware of the pod's lifecycle, while the node's lifecycle is relatively stable. This reduces the load balancing burden on the controller.

[0122] The embodiments in this specification are applicable to privacy-preserving computing scenarios. In privacy-preserving computing scenarios, the number of pods on each node is limited, and there is no situation that would exceed the QPS performance range of the metric collection component. In addition, because the number of pods is limited, the difference in the number of metrics between nodes is also small, so nodes are more suitable for load balancing at a granular level.

[0123] According to another embodiment, a metric collection device for container clusters is also provided. This device is disposed on a controller and is used to execute embodiments described in this specification. Figure 2 or Figure 3 The actions performed by the controller in the provided methods. Figure 5 A schematic block diagram of a metrics collection apparatus for a container cluster according to one embodiment is shown. Figure 5 As shown, the device 500 includes:

[0124] The listening unit 51 is used to obtain the message that the first node is online from the central node used to manage the container cluster through a listening mechanism; the first node is a node in the container cluster.

[0125] Creation unit 52 is used to create a first custom resource exclusively for the first node monitored by the monitoring unit 51 in the container cluster. The first custom resource has the address of the first indicator collection component deployed in it, so that the indicator data of the container in the first node can be pushed to the first indicator collection component.

[0126] Optionally, as an embodiment, the container cluster also includes a second custom resource created exclusively for the second node, wherein the address of the first metric collection component is deployed in the second custom resource.

[0127] Optionally, as an embodiment, the listening mechanism is a list / watch mechanism; the listening unit 51 is also used to apply to the central node to listen for the message of the new node coming online through the list mechanism before obtaining the message of the first node coming online.

[0128] The message indicating that the first node has come online includes:

[0129] A long-lived connection established through the watch mechanism receives a first event notification from the central node, which indicates that the first node has come online.

[0130] According to another embodiment, another metric collection device for container clusters is also provided. This device is installed in a target container within a first node, and is used to execute the embodiments described in this specification. Figure 2 The action performed by the target container in the first node of the provided method. Figure 6 A schematic block diagram of a metrics collection apparatus for a container cluster according to another embodiment is shown. Figure 6 As shown, the device 600 includes:

[0131] The listening unit 61 is used to obtain a message from the central node used to manage the container cluster that the first customized resource exclusively for the first node has been created through a listening mechanism.

[0132] Address acquisition unit 62 is used to obtain the address of the first indicator collection component from the first customized resource monitored by the monitoring unit 61;

[0133] The push unit 63 is used to push the target container's running indicator data to the first indicator collection component based on the address obtained by the address acquisition unit 62.

[0134] Optionally, as an embodiment, the listening mechanism is a list / watch mechanism; the listening unit 61 is also used to report a first name to the central node through the list mechanism before obtaining the message that the first customized resource exclusively enjoyed by the first node has been created, whereby the first name is the name of the first node or the name of the host where the first node is located.

[0135] The message indicating that the first customized resource exclusively for the first node has been created includes:

[0136] A long connection established through the watch mechanism receives a second event notification from the central node, the second event notification indicating that a first custom resource with the first name has been created.

[0137] According to another embodiment, another metric collection device for container clusters is also provided. This device is integrated into an aggregation tool within a first node and is used to execute the embodiments described in this specification. Figure 3 The action performed by the aggregation tool in the first node of the provided method. Figure 7 A schematic block diagram of a metrics collection apparatus for a container cluster according to another embodiment is shown. Figure 7 As shown, the device 700 includes:

[0138] The listening unit 71 is used to obtain, through a listening mechanism, a message from the central node used to manage the container cluster that the first custom resource exclusively for the first node has been created;

[0139] Address acquisition unit 72 is used to obtain the address of the first indicator collection component from the first customized resource monitored by the monitoring unit 71;

[0140] Aggregation unit 73 is used to receive the respective running indicator data pushed to it by multiple containers of the first node, and aggregate them to obtain aggregated data.

[0141] The push unit 74 is used to push the aggregated data obtained by the aggregation unit 73 to the first indicator collection component based on the address obtained by the address acquisition unit 72.

[0142] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figures 2 to 4 The method described.

[0143] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figures 2 to 4 The method described.

[0144] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0145] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for collecting metrics for container clusters, the method being executed by a controller, comprising: The system uses a listening mechanism to obtain the message that the first node has come online from the central node used to manage the container cluster. The first node is a node in the container cluster; In the container cluster, a dedicated first custom resource is created for the first node. The first custom resource deploys the address of the first indicator collection component among multiple indicator collection components. This allows the indicator data of the containers in the first node to be pushed to the first indicator collection component. The indicator data in the multiple indicator collection components is then collected by the data analysis system. The address of the first indicator collection component is configured according to a load balancing strategy. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

2. The method as described in claim 1, wherein, The monitoring mechanism is a list / watch mechanism; before receiving the message that the first node has come online, it also includes: The central node is requested to listen for messages about new nodes coming online via a list mechanism. The message indicating that the first node has come online includes: A long-lived connection established through the watch mechanism receives a first event notification from the central node, which indicates that the first node has come online.

3. The method as described in claim 1, wherein, The first customized resource is a namespace-level CRD.

4. The method of claim 1, wherein, The name of the first customized resource is the name of the first node or the name of the host where the first node is located.

5. The method of claim 1, wherein, The container cluster is used to perform privacy-preserving computation tasks.

6. The method of claim 1, wherein, The container is implemented in a pod.

7. A method for collecting metrics for a container cluster, the method being executed by a target container in a first node, wherein the first node is a node in the container cluster, the method comprising: Through a listening mechanism, a message indicating that the first custom resource exclusively for the first node has been created is obtained from the central node used to manage the container cluster. The address of the first indicator collection component among multiple indicator collection components is obtained from the first customized resource; the address of the first indicator collection component is configured according to the load balancing strategy. According to the address, the indicator data of the target container is pushed to the first indicator collection component, and the indicator data in the multiple indicator collection components is collected by the data analysis system. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

8. The method of claim 7, wherein, The monitoring mechanism is a list / watch mechanism; before obtaining the message that the first customized resource exclusively for the first node has been created, it also includes: The first name is reported to the central node through the list mechanism. The first name is either the name of the first node or the name of the host where the first node is located. The message indicating that the first customized resource exclusively for the first node has been created includes: A long connection established through the watch mechanism receives a second event notification from the central node, the second event notification indicating that a first custom resource with the first name has been created.

9. The method of claim 7, wherein, The container cluster is used to perform privacy-preserving computation tasks.

10. The method of claim 7, wherein, The container is implemented in a pod.

11. The method of claim 7, wherein, The metrics data include one or more of the following: CPU, memory, disk space, and network bandwidth used by the container.

12. A method for collecting metrics for a container cluster, the method being executed by an aggregation tool in a first node, the first node being a node in the container cluster, the method comprising: Through a listening mechanism, a message indicating that the first custom resource exclusively for the first node has been created is obtained from the central node used to manage the container cluster. The address of the first indicator collection component among multiple indicator collection components is obtained from the first customized resource; the address of the first indicator collection component is configured according to the load balancing strategy. Receive the respective running metric data pushed to it by multiple containers of the first node, and aggregate them to obtain aggregated data; According to the address, the aggregated data is pushed to the first indicator collection component, and the indicator data in the multiple indicator collection components is collected by the data analysis system. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

13. The method of claim 12, wherein, The aggregation tool is represented as a container in the first node.

14. A metric collection device for container clusters, the device being disposed in a controller, comprising: The listening unit is used to obtain the message of the first node coming online from the central node used to manage the container cluster through a listening mechanism; The first node is a node in the container cluster; A creation unit is used to create a dedicated first customized resource for the first node monitored by the listening unit in the container cluster. The first customized resource deploys the address of the first indicator collection component among multiple indicator collection components. This allows the indicator data of the containers in the first node to be pushed to the first indicator collection component, and the indicator data in the multiple indicator collection components is collected by the data analysis system. The address of the first indicator collection component is configured according to a load balancing strategy. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

15. A metric collection device for a container cluster, the device being disposed in a target container in a first node, the first node being a node in the container cluster, the device comprising: The listening unit is used to obtain, through a listening mechanism, a message from the central node that manages the container cluster that the first custom resource exclusively for the first node has been created; The address acquisition unit is used to obtain the address of the first indicator collection component among multiple indicator collection components from the first customized resource monitored by the monitoring unit; the address of the first indicator collection component is configured according to the load balancing strategy. The push unit is used to push the indicator data of the target container to the first indicator collection component according to the address obtained by the address acquisition unit. The indicator data in the multiple indicator collection components are collected by the data analysis system. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

16. A metric collection device for a container cluster, the device being an aggregation tool located in a first node, the first node being a node in the container cluster, the device comprising: The listening unit is used to obtain, through a listening mechanism, a message from the central node that manages the container cluster that the first custom resource exclusively for the first node has been created; The address acquisition unit is used to obtain the address of the first indicator collection component among multiple indicator collection components from the first customized resource monitored by the monitoring unit; the address of the first indicator collection component is configured according to the load balancing strategy. The aggregation unit is used to receive the respective running metric data pushed to it by multiple containers of the first node, and aggregate them to obtain aggregated data. The push unit is used to push the aggregated data obtained by the aggregation unit to the first indicator collection component according to the address obtained by the address acquisition unit. The indicator data in the multiple indicator collection components are collected by the data analysis system. The first indicator collection component is deployed at the central node; The container cluster also includes a second custom resource created exclusively for the second node, in which the address of the first metric collection component is deployed.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-13.

18. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-13.

Images