CN114077577A

CN114077577A - Cross-container based file data acquisition method and file data acquisition device

Info

Publication number: CN114077577A
Application number: CN202111367619.2A
Authority: CN
Inventors: 徐杨
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-11-18
Filing date: 2021-11-18
Publication date: 2022-02-22

Abstract

The embodiment of the specification provides a cross-container-based file data acquisition method and a cross-container-based file data acquisition device. In the file data acquisition method, an acquisition process independent of each business container on a host machine is deployed on the host machine to replace the acquisition process of offline in each business container; configuring the access authority of the deployed acquisition process in the host machine so that the acquisition process has cross-container access capability; and collecting the target file data through the business container to which the access path of the target file data belongs by using a collection process.

Description

Cross-container based file data acquisition method and file data acquisition device

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to a cross-container-based file data acquisition method and a cross-container-based file data acquisition device.

Background

Kubernetes (namely K8S) is a layout management tool of a portable container for serving containers, in K8S, a small-scale environment (namely the container) can be virtualized by a containerization technology for development of technical personnel, and the containerization technology is different from a virtual machine in that the whole operation needs to be virtualized, so that the technical problems of slow starting, large occupied space, difficulty in migration and the like in the virtual machine are solved. These advantages of containerization technology have led to the widespread use of K8S.

The K8S cluster may be composed of multiple hosts as nodes, where each host may run multiple pods, and each Pod runs a container. The resources of the containers are isolated from each other, the process started in each container comprises a service process and an acquisition process, the service process is used for executing corresponding service operation, and the acquisition process is a process which is deployed along with the service and is used for acquiring service related information. Through the deployment mode of the container, resource isolation among all services is realized.

Disclosure of Invention

In view of the foregoing, embodiments of the present specification provide a cross-container based file data collection method and a file data collection apparatus. According to the technical scheme of the embodiment of the specification, the acquisition process is independent of each business container and is deployed on the host machine, the cross-container access capability is provided, the file data are acquired from each business container, the number of the acquisition processes deployed on the host machine is reduced, and the resource isolation between the business process and the business container is realized.

According to an aspect of an embodiment of the present specification, there is provided a cross-container based file data collection method, including: deploying an acquisition process independent of each service container on the host machine to replace the acquisition process of offline in each service container; configuring the access authority of the deployed acquisition process in the host machine so that the acquisition process has cross-container access capability; and collecting the target file data through the business container to which the access path of the target file data belongs by using the collection process.

According to another aspect of the embodiments of the present specification, there is also provided a cross-container based file data collection apparatus, including: the acquisition process deployment unit is used for deploying an acquisition process independent of each service container on the host machine so as to replace the acquisition process of offline in each service container; the access authority configuration unit is used for configuring the access authority of the deployed acquisition process in the host machine so as to enable the acquisition process to have cross-container access capability; and the file data acquisition unit is used for acquiring the target file data through the service container to which the access path of the target file data belongs by using the acquisition process.

According to another aspect of embodiments herein, there is also provided an electronic device, including: at least one processor, a memory coupled with the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement a cross-container based document data collection method as described in any of the above.

According to another aspect of embodiments of the present specification, there is also provided a computer-readable storage medium storing a computer program which, when executed by a processor, implements the cross-container based file data collection method as described above.

According to another aspect of embodiments of the present specification, there is also provided a computer program product comprising a computer program which, when executed by a processor, implements the cross-container based file data collection method as described in any one of the above.

Drawings

A further understanding of the nature and advantages of the contents of the embodiments of the present specification may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals.

FIG. 1 shows a schematic diagram of one example of a traffic container deployed in a host.

Fig. 2 is a schematic diagram illustrating an example of a structure of a K8S cluster according to an embodiment of the present specification.

FIG. 3 illustrates a flow diagram of one example of a cross-container based file data collection method in accordance with embodiments of the present description.

FIG. 4 is a diagram illustrating an example of separating a traffic container from an acquisition process according to an embodiment of the present description.

Fig. 5 is a flowchart illustrating an example of configuring access rights of an acquisition process in a host according to an embodiment of the present specification.

FIG. 6 is a flow diagram illustrating an example of a collection process collecting target file data via a business container according to an embodiment of the present description.

FIG. 7 illustrates a block diagram of one example of a cross-container based document data collection apparatus in accordance with embodiments of the present description.

FIG. 8 illustrates a block diagram of another example of a cross-container based document data collection apparatus in accordance with an embodiment of the present description.

FIG. 9 illustrates a block diagram of another example of a cross-container based document data collection apparatus in accordance with an embodiment of the present description.

FIG. 10 illustrates a block diagram of an electronic device for implementing a cross-container based document data collection method, in accordance with an embodiment of the present specification.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

Kubernetes is a layout management tool of a portable container for container service, in K8S, a small-scale environment (namely a container) can be virtualized by a containerization technology for development of technical personnel, and the containerization technology is different from a virtual machine in that the virtual machine needs to virtualize the whole operation, so that the technical problems of slow starting, large occupied space, difficult migration and the like in the virtual machine are solved. These advantages of containerization technology have led to the widespread use of K8S.

The K8S cluster may be composed of multiple hosts as nodes, where each host may run multiple Pod, each Pod runs a container, and the resources between the containers are isolated from each other. Fig. 1 is a schematic diagram illustrating an example of service containers deployed in a host, where, as shown in fig. 1, a process started in each container includes a service process and an acquisition process (agent process), the service process is used for executing a corresponding service operation, and the acquisition process is a process deployed along with a service and used for acquiring service-related information. Through the deployment mode of the container, resource isolation among all services is realized.

However, in the above deployment approach, each container needs to be deployed with one collection process, which results in high resource cost overhead, and especially when the size of the container is doubled due to the fact that the K8S cluster carries more traffic, the resource cost overhead is also multiplied. In addition, the collection process and the service are deployed in the same container, resources and risks are not isolated, and the service has safety risks.

In view of the above, embodiments of the present specification provide a cross-container based file data collection method and a file data collection apparatus, in the file data collection method, a collection process independent of each business container on a host is deployed on the host to replace a collection process offline in each business container; configuring the access authority of the deployed acquisition process in the host machine so that the acquisition process has cross-container access capability; and collecting the target file data through the business container to which the access path of the target file data belongs by using a collection process. According to the technical scheme of the embodiment of the specification, the acquisition process is independent of each business container and is deployed on the host machine, the cross-container access capability is provided, the file data are acquired from each business container, the number of the acquisition processes deployed on the host machine is reduced, and the resource isolation between the business process and the business container is realized.

The following describes a cross-container based file data collection method and a file data collection device provided in an embodiment of the present specification in detail with reference to the accompanying drawings.

The cross-container-based file data acquisition method and the file data acquisition device provided by the embodiment of the specification can be applied to the application environment of a K8S cluster, so that cross-container file data acquisition can be realized in the K8S cluster. Fig. 2 is a schematic diagram illustrating an example of a structure of a K8S cluster according to an embodiment of the present specification.

As shown in fig. 2, the K8S cluster may be composed of a Master Node and Node nodes, and the Master Node may be communicatively connected to each Node. In the K8S cluster, the Master Node and each Node may be formed by hosts, each host may run multiple pods, and each Pod runs one Container according to the OCI (Open Container Initiative) standard.

The Master Node may be used as a cluster control Node for managing and controlling the entire K8S cluster, and the Master Node may send a control command to each Node. Master nodes may include components such as Kubernets Controller Manager, Kubernets Scheduler, and Etcd. The kubernets Controller Manager can be used as an automation control center of all resource objects in the K8S cluster, and is used for maintaining and managing the state of the cluster, such as fault detection, automatic expansion, rolling update and the like. The Kubernetes Scheduler may be configured to schedule resources, and schedule Pod to corresponding machines according to a predetermined scheduling policy. Etcd may be used to save the state of the entire K8S cluster.

The Node can be distributed with workload by the Master Node, and the Node can comprise Kubelet, Kube-Proxy, Docker and other components. The Kubelet can be used for being responsible for tasks such as creation, start and stop of containers corresponding to the Pod, and can also cooperate with the Master node to achieve basic functions of K8S cluster management. The Kube-Proxy can be used for realizing communication and load balance of Service. Docker may be used to take charge of the creation and management of containers for the host.

FIG. 3 illustrates a flow diagram of one example 300 of a cross-container based file data collection method in accordance with embodiments of the present description.

As shown in FIG. 3, at 310, an acquisition process is deployed on the host that is independent of the individual business containers on the host to replace the acquisition process that is offline in the individual business containers.

In this embodiment, the K8S cluster may configure DaemenSet, and DaemenSet may serve as a Pod controller, so as to ensure that a copy of a Pod runs on a Node.

In one example, the acquisition process may be deployed on the host by way of DaemenSet, which may control the deployed acquisition process. The collection process deployed on the host is independent of each service container on the host, and the collection process and each service container belong to different containers.

After the collection process independent from each service container is deployed, the collection in each service container can be offline, and the deployed collection process can replace the offline collection process in each service container, that is, the deployed collection process can realize the function that the collection process in each service container can execute before offline.

In one example, a new and separate acquisition process for each traffic container on the host may be initiated on the host. And then switching the flow of the acquisition process in each service container to a new acquisition process. The collection process in each business container may then be taken offline. In the offline mode of the acquisition process, the acquisition process in each service container can be offline from the basic mirror image, and the acquisition thread does not exist in the subsequent newly deployed service container.

After the collection process in each service container is offline, only the collection process independent from each service container is deployed in the host machine, and the collection process can collect file data from each service container.

FIG. 4 is a diagram illustrating an example of separating a traffic container from an acquisition process according to an embodiment of the present description. As shown in fig. 4, before the collection process is separated, a collection process is deployed in each service container in the host, and the collection process in each service container can only collect file data in the service container. After the operation of 310, only one collection process independent of other service containers is stored in the host, and there is no collection process in each service container. Therefore, only one acquisition process needs to be operated in the host machine, and the resource consumption in the host machine is reduced.

At 320, access rights of the deployed harvesting process in the host are configured to enable the harvesting process cross-container access capabilities.

In the embodiment of the present specification, a collection process with cross-container access capability can access a file system mounted on each service container, so that file data can be collected from each service container. The file systems that the harvesting process has access to may include physical file systems (e.g., storage volumes) having a physical structure and virtual file systems (e.g., Overlay file systems) that are presented in a virtual structure that depends on and builds on top of the physical file systems.

Fig. 5 shows a flowchart of an example 500 of configuring access rights of an acquisition process in a host according to an embodiment of the present description.

As shown in FIG. 5, at 322, the deployed acquisition process may be configured by switching the Mnt Namespace of the acquisition process so that the acquisition process has the same view of the file system as the host.

In this example, the Mnt Namespace may be used in the host to implement environment isolation of the file systems mounted by the respective containers, and different Mnt namespaces may correspond to different file systems. Different file systems can be pointed to by switching the Mnt Namespace.

The file system view refers to the view of the file system, and the root directory which can be seen by the acquisition process with the same file system view as the host is the root directory of the host. In one example, the collection process can see all directory files under the host, including the root directory of the file system mounted by each other service container isolated by the Mnt Namespace.

In one example, when a Pod where the collection process is located starts, the Proc file system of the host may be mounted on the Pod.

In this example, the Proc filesystem may be a virtual filesystem, which may be used to view information of the system hardware and running processes. Thus, the Proc file system of the host can provide the process information started by the host.

In this embodiment of the present specification, the storage directory of the Proc file system of the host may be/Proc, and the mount manner of the Proc file system may be a mount manner of a container volume. In one example, the Proc file system of the host may be mounted on the Pod where the collection process is located through DaemenSet.

Then, the mode of the pid (process id) Namespace of the acquisition process may be set to the Host mode.

The Pid Namespace can be used for virtualizing the containers of the process Pid, and isolation among the containers is realized from the perspective of the Pid. Each business container can only see the pids in its own container, while the host can see the pids of all processes.

The acquisition progress is configured to be in a Host mode, and the Proc file system is mounted at the Pod where the acquisition progress is located, so that the progress of a Host in the Proc file system can be read through the acquisition progress.

And then, switching the Mnt Namespace of the acquisition process to the read process of the host machine so that the acquisition process has the same file system view angle with the host machine.

In one example, the Mnt Namespace of the acquisition process may be switched to any process of the fetched hosts. In another example, the switched host process may be the first process of the host, i.e., Mnt Namespace of the acquisition process may be switched to/Proc/1/ns/Mnt on the host, where/Proc/1 represents the first process of the host. By switching the Mnt Namespace to the first process, it can be ensured that the process switched by the Mnt Namespace exists in the host.

In one example, the acquisition process may switch its own Mnt Namespace to the read process of the host through Linux Setns system call.

After the process of switching to the host machine through the Mnt Namespace is carried out, all file systems in the host machine can be seen due to the fact that the process of the host machine has the file system visual angle of the host machine, and therefore all file systems in the host machine and root directories under all the file systems can be seen through the collecting process with the same file system visual angle as that of the host machine.

Returning to FIG. 5, at 324, the storage meta-information for each service container is obtained through the acquisition process.

The storage meta-information of the service container may be used to determine the mounting points on the service container, and further may determine the locations of the respective mounting points on the host, where the locations determined by the storage meta-information are physical locations on the host.

In one example, each storage meta-information of a traffic container may be used to correspondingly characterize a mount point on the traffic container. The storage meta information of each service container may include a physical file system mounted on the service container and a virtual file system configured in the service container, where the physical file system may include a storage volume (volume), and the like, the virtual file system may include Overlay, Overlay2, and the like, and Overlay2 may serve as a Docker image Graphdriver in K8S. The following description will use an Overlay as an example for the virtual file system.

In addition, the storage meta information of the service container may further include a container identifier, an IP address, and a mapping relationship between the container identifier and the IP address, which are used to determine the meta information of the service container.

Returning to FIG. 3, after the collection process has cross-container access capability, the collection process may be used to collect the target file data at 330 via the business container to which the access path of the target file data belongs.

FIG. 6 illustrates a flow diagram of one example 600 of a collection process collecting target file data via a business container in accordance with an embodiment of the present description.

As shown in fig. 6, at 332, the collection process may determine, based on the same file system perspective as the host, a storage directory on which the service container to which the access path of the target file data belongs is mounted.

In this example, the target file data may be file data to be collected, and the access path is a path for accessing the target file data and is provided to the collection process, so that the collection process collects the target file data according to the access path. The access path of the target file data may include a storage directory mounted in the service container, where the storage directory may be a root directory, or may be composed of the root directory and its lower directories of different levels. For example, the access path of the target file data is: log, where/home/admin/logs may be a storage directory mounted on a business container.

After the access path of the target file data is determined, the acquisition process can see each root directory in each service container and the storage directory under each root directory based on the same file system view angle as the host. The storage directory included in the access path may be compared with the storage directories in the respective service containers to determine the service container to which the access path of the target file data belongs and the storage directory on which the belonging service container is mounted. For example, based on the above example, one of the storage directories mounted on the service container a in the host is/home/admin/logs, and is matched with the storage directory included in the access path of the target file data, so as to determine that the access path of the target file data belongs to the storage directory/home/admin/logs mounted on the service container a.

At 334, a location of the target file data on the host is determined based on the storage meta information of the access path corresponding to the determined storage directory.

In this example, the storage meta-information corresponding to the storage directory is used to characterize the file system to which the storage directory belongs, and the storage directory is one of the directories in the file system characterized by the corresponding storage meta-information. For example, a storage volume mounted on a service container includes a storage directory/home/admin/logs, and the storage meta information corresponding to the storage directory is the storage volume. Further, the determined location of the target file data on the host is a physical location.

In one example, the physical location of the storage directory on the host corresponding to the storage directory to which the access path belongs may be determined according to the storage meta information corresponding to the storage directory.

In this embodiment of the present description, the storage meta information may be used to determine a physical location of the mount point on the host, so as to determine a physical location of the file system represented by the storage meta information, which corresponds to the host, and further determine a physical location of each storage directory in the file system, which corresponds to the host.

In this example, the storage directories and physical locations on the hosts may correspond one-to-one, such that a correspondence of the storage directories to the physical locations may be established. For example, taking the example that the storage meta information is a storage volume, the storage volume mount is a storage directory included under the service container: the method comprises the following steps of/home/admin/logs, determining the physical position of a storage volume on a host machine through storage meta information of the storage volume, and further determining that the physical position corresponding to the storage directory is as follows: and/roofs/PodA/logs, which indicates that the actual storage location of the storage directory on the host is/roofs/PodA/logs.

For another example, taking the example that the storage meta information is an Overlay file system, one storage directory in the Overlay file system mounted in the service container is a root directory "/", and it can be determined through the storage meta information of the Overlay file system that the physical location on the host is: and/roofs/PodA/graph/mergeDir, it can indicate that the actual storage location of the storage directory on the host is/roofs/PodA/graph/mergeDir.

After the physical position corresponding to the storage directory is determined, the access path can be converted into the position of the target file data on the host according to the determined physical position and the storage directory.

The determined physical locations correspond one-to-one to the storage directories, and the composition of the access path may include the storage directories, that is, the access path is one of the paths under the storage directories. Based on this, the storage directory included in the composition of the access path may be replaced with the determined physical location, so as to obtain a path including a physical location corresponding to the storage directory, where the path is used to indicate a physical location of the target file data on the host.

Taking the storage meta information as an example of a storage volume, one storage directory of the storage volume is: the physical positions corresponding to the storage directory are: the access path of the target file data is as follows: log/home/admin/logs/log, then the storage directory included in the composition of the access path is: and/home/admin/logs, the partial storage directory can be replaced by a path of a physical location, so that the location of the obtained target file data on the host is as follows: log/roofs/PodA/logs/a.

Taking the example that the storage meta information is the Overlay file system, the storage directory of the Overlay file system is a root directory, that is: the physical location on the host by the Overlay file system is: the access path of the target file data is as follows: and/etc/localtime, replacing the root directory in the access path with a path of a physical position, and obtaining the position of the target file data on the host as follows: the method comprises the following steps of/roofs/PodA/graph/mergeDir/etc/localtime.

In one way of determining the physical location of the target file data, the storage meta information may include the storage volume and the virtual file system. First, it may be determined whether a directory of an access path belongs to a storage directory of a storage volume according to the access path of the target file data.

When the directory to which the access path belongs is judged to belong to the storage directory of the storage volume, the physical position of the directory, corresponding to the storage directory, in the storage volume on the host computer can be determined according to the storage meta information of the storage volume, and then the access path is converted into the position of the target file data on the host computer based on the determined physical position, the storage directory and the access path.

When the directory to which the access path belongs is judged not to belong to the storage directory of the storage volume, the directory to which the access path belongs can be determined to belong to the storage directory of the virtual file system, so that the physical position of the directory in the virtual file system, corresponding to the storage directory, on the host computer can be determined according to the storage meta information of the virtual file system, and then the access path is converted into the position of the target file data on the host computer based on the determined physical position, the storage directory and the access path.

Returning to FIG. 6, at 336, the collection process collects the target file data from the determined location.

By the cross-container-based file data acquisition method and the file data acquisition device provided by the embodiments of the present specification, the acquisition process is deployed on the host independently from each service container, and the cross-container access capability is provided, so that the number of acquisition processes deployed on the host is reduced while the file data is acquired from each service container, and resource isolation between the service processes and the service containers is realized.

FIG. 7 illustrates a block diagram of one example of a cross-container based document data collection apparatus 700 in accordance with embodiments of the present description.

As shown in fig. 7, the file data collection apparatus 700 includes a collection process deployment unit 710, an access authority configuration unit 720, and a file data collection unit 730.

The collection process deployment unit 710 is configured to deploy, on the host, a collection process independent of each service container on the host to replace the collection process offline in each service container.

In one example, the acquisition process deployment unit 710 may be further configured to: starting a new acquisition process independent of each service container on the host machine; switching the flow of the acquisition process in each service container to a new acquisition process; and the collection process in each service container is offline.

And an access right configuration unit 720, configured to configure the access right of the deployed collection process in the host, so that the collection process has cross-container access capability.

The file data collection unit 730 is configured to collect the target file data through the service container to which the access path of the target file data belongs using the collection process.

FIG. 8 illustrates a block diagram of another example of a cross-container based document data collection apparatus 700 in accordance with an embodiment of the present description.

The access right configuration unit 720 may include: an acquisition process configuration module 722 and a meta information acquisition module 724. And the acquisition process configuration module 722 is configured to configure the deployed acquisition process by switching the Mnt Namespace of the acquisition process, so that the acquisition process has the same view angle of the file system as the host.

In one example, the acquisition process configuration module 722 is configured to: when the Pod where the collection process is located is started, mounting a Proc file system of a host on the Pod; setting the mode of the Pid Namespace of the acquisition process as a host mode; reading the process of a host machine in the Proc file system through an acquisition process; and switching the Mnt Namespace of the acquisition process to the read process of the host machine so that the acquisition process has the same file system view angle as the host machine.

And a meta information obtaining module 724 configured to obtain storage meta information of each service container through the collection process.

FIG. 9 illustrates a block diagram of another example of a cross-container based document data collection apparatus 700 in accordance with embodiments of the present description.

In one example, the file data collection unit 730 may further include: a traffic container determination module 732, a storage location determination module 734, and a file data collection module 736.

The service container determining module 732 is configured to determine, by the collection process, a storage directory where a service container belonging to an access path of the target file data belongs, based on a view of the file system.

A storage location determination module 734 configured to determine a location of the target file data on the host based on the storage meta information of the access path corresponding to the storage directory.

In one example, the storage location determination module 734 is configured to: determining the physical position of the storage directory on the host machine according to the storage meta information corresponding to the storage directory; and converting the access path into the position of the target file data on the host according to the physical position and the storage directory.

And a document data collection module 736 configured to collect the target document data from the determined position by the collection process.

Embodiments of a cross-container based file data collection method and a file data collection apparatus according to embodiments of the present specification are described above with reference to fig. 1 to 9.

The cross-container based file data acquisition device in the embodiments of the present specification may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The software implementation is taken as an example, and is formed by reading corresponding computer program instructions in the storage into the memory for operation through the processor of the device where the software implementation is located as a logical means. In the embodiment of the present specification, the cross-container based file data collection apparatus may be implemented by an electronic device, for example.

FIG. 10 illustrates a block diagram of an electronic device 1000 for implementing a cross-container based document data collection method in accordance with an embodiment of the present specification.

As shown in fig. 10, the electronic device 1000 may include at least one processor 1010, a memory (e.g., non-volatile memory) 1020, a memory 1030, and a communication interface 1040, and the at least one processor 1010, the memory 1020, the memory 1030, and the communication interface 1040 are connected together via a bus 1050. The at least one processor 1010 executes at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in memory.

In one embodiment, computer-executable instructions are stored in the memory that, when executed, cause the at least one processor 1010 to: deploying an acquisition process independent of each business container on the host machine to replace the acquisition process of offline in each business container; configuring the access authority of the deployed acquisition process in the host machine so that the acquisition process has cross-container access capability; and collecting the target file data through the business container to which the access path of the target file data belongs by using a collection process.

It should be appreciated that the computer-executable instructions stored in the memory, when executed, cause the at least one processor 1010 to perform the various operations and functions described above in connection with fig. 1-9 in the various embodiments of the present description.

According to one embodiment, a program product, such as a machine-readable medium, is provided. A machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions described above in connection with fig. 1-9 in the various embodiments of the present specification.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.

Computer program code required for the operation of various portions of the present specification may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB, NET, Python, and the like, a conventional programming language such as C, Visual Basic 2003, Perl, COBOL2002, PHP, and ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages. The program code may execute on the user's computer, or on the user's computer as a stand-alone software package, or partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical spirit of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the description is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cross-container based file data collection method comprises the following steps:

deploying an acquisition process independent of each service container on the host machine to replace the acquisition process of offline in each service container;

configuring the access authority of the deployed acquisition process in the host machine so that the acquisition process has cross-container access capability; and

and acquiring the target file data through the business container to which the access path of the target file data belongs by using the acquisition process.

2. The file data collection method of claim 1, wherein configuring access rights of the deployed collection process in the host to enable the collection process with cross-container access capability comprises:

configuring the deployed acquisition process by switching the Mnt Namespace mode of the acquisition process so as to enable the acquisition process to have the same file system view angle as the host machine; and

and acquiring the storage meta information of each service container through the acquisition process.

3. The file data collection method of claim 2, wherein configuring the deployed collection process by switching its Mnt Namespace to have the same view of the file system as the host comprises:

when the Pod where the acquisition process is located is started, mounting a Proc file system of the host on the Pod;

setting the mode of the Pid Namespace of the acquisition process as a Host mode;

reading the process of the host machine in the Proc file system through the acquisition process; and

and switching the Mnt Namespace of the acquisition process to the read process of the host machine, so that the acquisition process has the same file system view angle as the host machine.

4. The file data collection method of claim 3, wherein switching the Mnt Namespace of the collection process to the read process of the host to make the collection process have the same view of the file system as the host comprises:

and switching the Mnt Namespace of the acquisition process to the first process of the host machine so that the acquisition process has the same file system view angle as the host machine.

5. The file data collection method of claim 2, wherein the storage meta information comprises a storage volume and a virtual file system.

6. The file data collection method according to claim 2, wherein collecting the target file data through a service container to which an access path of the target file data belongs using the collection process comprises:

the acquisition process determines a storage directory mounted by a service container to which an access path of the target file data belongs based on the view angle of the file system;

determining a location of the target file data on the host based on storage meta information of the access path corresponding to the storage directory; and

the collection process collects the target file data from the determined location.

7. The file data collection method of claim 6, wherein determining the location of the target file data on the host based on the storage meta information of the access path corresponding to the storage directory comprises:

determining the physical position of the storage directory on the host machine according to the storage meta information corresponding to the storage directory; and

and converting the access path into the position of the target file data on the host according to the physical position and the storage directory.

8. The file data collection method of claim 1, wherein deploying a collection process on a host that is independent of each business container on the host to replace a collection process that is offline in each business container comprises:

starting a new acquisition process independent of each service container on the host machine;

switching the flow of the acquisition process in each service container to the new acquisition process; and

and taking the collection process in each service container off line.

9. A cross-container based document data collection apparatus comprising:

the acquisition process deployment unit is used for deploying an acquisition process independent of each service container on the host machine so as to replace the acquisition process of offline in each service container;

the access authority configuration unit is used for configuring the access authority of the deployed acquisition process in the host machine so as to enable the acquisition process to have cross-container access capability; and

and the file data acquisition unit acquires the target file data through the service container to which the access path of the target file data belongs by using the acquisition process.

10. The document data collecting apparatus according to claim 9, wherein the access right configuring unit includes:

the acquisition process configuration module is used for configuring the deployed acquisition process in a mode of switching Mnt Namespace of the acquisition process so as to enable the acquisition process to have the same file system visual angle as the host machine; and

and the meta-information acquisition module acquires the storage meta-information of each service container through the acquisition process.

11. The document data collection apparatus of claim 10, wherein the collection process configuration module is configured to:

12. The document data collection apparatus according to claim 10, wherein the document data collection unit comprises:

a storage location determination module that determines a location of the target file data on the host based on the storage meta information of the access path corresponding to the storage directory; and

a file data collection module, the collection process collecting the target file data from the determined location.

13. The file data collection apparatus of claim 12, wherein the storage location determination module is configured to:

14. The file data collecting apparatus according to claim 9, wherein the collecting process deploying unit is configured to:

and taking the collection process in each service container off line.

15. An electronic device, comprising: at least one processor, a memory coupled to the at least one processor, and a computer program stored on the memory, the at least one processor executing the computer program to implement the document data collection method of any one of claims 1-8.

16. A computer-readable storage medium, which stores a computer program that, when executed by a processor, implements the file data collection method according to any one of claims 1 to 8.

17. A computer program product comprising a computer program which, when executed by a processor, implements a file data collection method as claimed in any one of claims 1 to 8.