I / O speed limiting method and device, electronic equipment, storage medium and program product

By building and deploying target virtual machines and images, the I/O speed limit daemon process is used to solve the problem of I/O speed limit in edge container clusters, achieving the stability and reliability of container business.

CN119829194APending Publication Date: 2025-04-15CHINA TELECOM CLOUD TECH CO LTD
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202411744402.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-30
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

Edge container clusters lack effective I/O speed limit solutions, resulting in I/O performance interference and read and write instability when containers use cloud disks or share local disks, affecting other container services.

Method used

By getting the target kernel, build the target virtual machine and deploying it into the target container in the container cluster. Based on the target virtual machine and preset executable files, the target image is built. The executable file is used to run the I/O speed limit daemon to achieve I/O speed limit of the target container.

Benefits of technology

It realizes I/O speed limit management of containers in container clusters, avoids I/O performance interference, ensures the stability and reliability of container services, and can seamlessly connect to the existing container ecosystem.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119829194A_ABST
    Figure CN119829194A_ABST
Patent Text Reader

Abstract

The invention provides an I / O speed limiting method and device, electronic equipment, a storage medium and a program product, and belongs to the technical field of containers. According to the embodiment of the invention, a target virtual machine is constructed based on a target kernel; then deploying the target virtual machine to at least one target container of the container cluster, and constructing to obtain a target mirror image based on the target virtual machine and a preset executable file; and finally, running the target mirror image in the target container, so that the target virtual machine runs an I / O speed limiting daemon process corresponding to the executable file, and carrying out I / O speed limiting on the target container. According to the embodiment of the invention, the executable file used for carrying out I / O speed limiting on the container is deployed into the target mirror image, so that the target virtual machine can run the I / O speed limiting daemon process when the container is started, I / O speed limiting management on the target container is realized, and the running stability of a container cluster is effectively ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of container technology, and in particular to an I / O speed limiting method, device, electronic equipment, storage medium and program product. Background Art

[0002] Edge container clusters have become an important development trend by sinking cloud computing capabilities to the edge, which can give full play to the advantages of containers' lightweight, easy migration and easy replication.

[0003] However, due to the lack of effective I / O speed limiting solutions in edge container clusters, containers are prone to I / O performance interference, unstable reading and writing, and mutual impact on container services when using cloud disks and sharing local disks. For example, when the I / O of a disk in a distributed storage cluster increases dramatically, it may affect the entire distributed storage cluster, thereby affecting other container services.

[0004] Therefore, how to limit the I / O speed of containers in the edge container cluster is a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present invention provides an I / O speed limiting method, device, electronic device, storage medium and program product to solve the problem that it is currently difficult to limit the I / O speed of containers in an edge container cluster.

[0006] In order to solve the above problems, the present invention adopts the following technical solutions:

[0007] In a first aspect, an embodiment of the present invention provides an I / O speed limiting method, the method comprising:

[0008] Obtaining a target kernel, and constructing a target virtual machine based on the target kernel;

[0009] Deploy the target virtual machine into at least one target container of the container cluster;

[0010] Based on the target virtual machine and a preset executable file, a target image is constructed; the executable file is used to limit the I / O speed of the container;

[0011] The target image is run in the target container, so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file, and performs I / O speed limit on the target container.

[0012] In one embodiment of the present invention, before obtaining the target kernel, the method further includes:

[0013] Based on a preset file I / O mode, the target kernel is determined; the target kernel is a kernel that supports the file I / O mode.

[0014] In one embodiment of the present invention, deploying the target virtual machine into at least one target container of the container cluster includes:

[0015] The container runtime attribute of the target container is configured as the target container runtime corresponding to the target virtual machine, so that the target container is started with the target container runtime.

[0016] In one embodiment of the present invention, a target image is constructed based on the target virtual machine and a preset executable file, including:

[0017] Compile the root file system corresponding to the operating system of the target virtual machine;

[0018] Packaging and exporting the root file system as an initial image;

[0019] The executable file is deployed into the initial image to construct the target image.

[0020] In one embodiment of the present invention, running the target image in the target container so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file and performs I / O speed limit on the target container includes:

[0021] The executable file is configured to a target path, so that the target virtual machine obtains the executable file through the target path, and runs an I / O speed limit daemon process corresponding to the executable file to perform I / O speed limit on the target container.

[0022] In one embodiment of the present invention, the I / O rate limiting daemon is used to perform the following steps:

[0023] Obtain a structure object of the target container; the structure object includes a mount point path and mounted disk information;

[0024] Receive I / O speed limit information; the I / O speed limit information includes a device identifier and a speed limit parameter;

[0025] Based on the device identifier, a target disk is determined in the disk information; and based on the speed limit information, an I / O configuration file located under the mount point path is configured to perform I / O speed limit on the target disk.

[0026] In a second aspect, based on the same inventive concept, an embodiment of the present invention provides an I / O speed limiting device, the device comprising:

[0027] A virtual machine construction module, used to obtain a target kernel and construct a target virtual machine based on the target kernel;

[0028] A virtual machine deployment module, used to deploy the target virtual machine into at least one target container of the container cluster;

[0029] An image building module, used to build a target image based on the target virtual machine and a preset executable file; the executable file is used to limit the I / O speed of the container;

[0030] The speed limit control module is used to run the target image in the target container so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file to perform I / O speed limit on the target container.

[0031] In one embodiment of the present invention, the I / O speed limiting device further includes:

[0032] The kernel determination module is used to determine the target kernel based on a preset file I / O mode; the target kernel is a kernel that supports the file I / O mode.

[0033] In one embodiment of the present invention, the virtual machine deployment module includes:

[0034] The attribute configuration submodule is used to configure the container runtime attribute of the target container to the target container runtime corresponding to the target virtual machine, so that the target container is started with the target container runtime.

[0035] In one embodiment of the present invention, the image building module includes:

[0036] A compiling submodule, used to compile the root file system corresponding to the operating system of the target virtual machine;

[0037] An image packaging submodule is used to package the root file system and export it as an initial image;

[0038] The file deployment submodule is used to deploy the executable file into the initial image to construct the target image.

[0039] In one embodiment of the present invention, the speed limit control module includes:

[0040] The path configuration submodule is used to configure the executable file to the target path so that the target virtual machine obtains the executable file through the target path, and runs the I / O speed limit daemon corresponding to the executable file to perform I / O speed limit on the target container.

[0041] In one embodiment of the present invention, the I / O rate limiting daemon is used to perform the following steps:

[0042] Obtain a structure object of the target container; the structure object includes a mount point path and mounted disk information;

[0043] Receive I / O speed limit information; the I / O speed limit information includes a device identifier and a speed limit parameter;

[0044] Based on the device identifier, a target disk is determined in the disk information; and based on the speed limit information, an I / O configuration file located under the mount point path is configured to perform I / O speed limit on the target disk.

[0045] In a third aspect, an embodiment of the present invention provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements the I / O speed limiting method as described in the first aspect of the present invention.

[0046] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the I / O speed limiting method as described in the first aspect of the present invention.

[0047] In a fifth aspect, an embodiment of the present invention provides a computer program product, including a computer program / instruction, which is implemented by a processor to implement the steps in the I / O speed limiting method described in the first aspect of the present invention.

[0048] Compared with the prior art, the present invention has the following advantages:

[0049] An I / O speed limiting method provided by an embodiment of the present invention first obtains a target kernel, and based on the target kernel, constructs a target virtual machine; then deploys the target virtual machine to at least one target container of a container cluster, and constructs a target image based on the target virtual machine and a preset executable file, and the executable file is used to perform I / O speed limiting on the container; finally, the target image is run in the target container, so that the target virtual machine runs the I / O speed limiting daemon corresponding to the executable file, and performs I / O speed limiting on the target container. An embodiment of the present invention deploys an executable file for performing I / O speed limiting on the container into the target image, so that the target virtual machine can run the I / O speed limiting daemon when the container starts, thereby achieving I / O speed limiting management of the target container. In this way, the container ecosystem can be seamlessly connected without affecting the existing container business architecture, so as to achieve the purpose of container speed limiting, thereby effectively ensuring the operational stability of the container cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0051] Figure 1 The present invention is a flowchart of an I / O speed limiting method according to an embodiment of the present invention.

[0052] Figure 2 1 is a diagram of the Kata runtime architecture in one embodiment of the present invention.

[0053] Figure 3 4 is a diagram of a rate limiting architecture of a target virtual machine in one embodiment of the present invention.

[0054] Figure 4 It is a schematic diagram of functional modules of an I / O speed limiting device in one embodiment of the present invention.

[0055] Figure 5 It is a schematic structural diagram of an electronic device in one embodiment of the present invention. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0057] It should be noted that with the advent of the era of the Internet of Everything, the number of Internet intelligent terminal devices has increased dramatically, and with the popularization of 5G (Fifth Generation I / On, the fifth generation of mobile communication technology) communication networks, the scale of Internet data has shown exponential growth. Under the centralized architecture of traditional cloud computing, the transmission, storage, and calculation of data from terminals to cloud centers can no longer meet the needs of end users for timeliness, capacity, and computing power. Edge container clusters have become an important development trend by sinking cloud computing capabilities to the edge side, which can give full play to the advantages of containers' lightweight, easy migration, and easy replication.

[0058] In edge container cluster scenarios, kubernetes is the most widely used and common container cluster orchestration solution. Kubernetes automates container management operations and has built-in commands for deploying applications, changing applications, scaling applications according to changing needs, monitoring applications, etc., to make it easier to manage applications.

[0059] However, Kubernetes currently lacks a universal I / O speed limiting solution, which results in I / O performance interference, unstable reading and writing, and mutual impact on container services when containers use cloud disks and share local disks. For example, the krbd kernel mounting method used by Ceph (CephDistributedStorage, a distributed storage system) cloud disks does not have the I / O speed limiting capability. When the I / O of a Ceph cloud disk increases dramatically, it will affect the entire Ceph cluster, thereby affecting other container services.

[0060] In view of the current difficulty in performing I / O speed limiting on containers in edge container clusters, the present invention aims to provide an I / O speed limiting method, which deploys an executable file for performing I / O speed limiting on containers into a target image, so that the target virtual machine can run the I / O speed limiting daemon when the container is started, thereby achieving I / O speed limiting management on the target container. In this way, the container ecosystem can be seamlessly connected without affecting the existing container business architecture, achieving the purpose of container speed limiting, and thus effectively ensuring the operating stability of each target container in the container cluster.

[0061] Reference Figure 1 , shows a flow chart of the steps of an I / O speed limiting method of the present invention, the method may include the following steps:

[0062] S101: Obtain a target kernel, and build a target virtual machine based on the target kernel.

[0063] It should be noted that the kernel is the core part of the operating system, responsible for managing the system's hardware resources and providing basic services so that user space applications can run efficiently and securely.

[0064] In this implementation, in order to enable the target virtual machine to achieve speed limit on the container, a suitable target kernel is configured for the target virtual machine according to the speed limit requirement.

[0065] In a specific implementation, before obtaining the target kernel, the target kernel may be determined based on a preset file I / O mode; the target kernel is a kernel that supports the file I / O mode.

[0066] It should be noted that file I / O (input / output) mode usually includes two modes, Direct I / O mode and Buffered I / O mode; among them, Direct I / O mode means that data is directly transmitted between user space (application) and hardware device without passing through the operating system's buffer (PageCache); Buffered I / O mode means that data is first written to or read from the operating system's buffer (PageCache) and then interacts with the hardware device.

[0067] Take the Linux system as an example. In Direct I / O mode, if the user process wants to write a disk file, it will write to the disk through the path of the Linux kernel's file system layer (filesystem) -> block device layer (blocklayer) -> disk driver -> disk hardware; in Buffered I / O mode, the user process only writes the file data to the memory (PageCache) and returns, and the Linux kernel itself has a thread that will write the data in the memory to the disk. In Linux, due to performance considerations, most applications will use Buffered I / O mode.

[0068] In this implementation, to improve the applicability of the speed limit, the preset file I / O mode may include a Direct I / O mode and a Buffered I / O mode, and the target kernel is a kernel that supports both modes.

[0069] For example, for Linux systems, cgroupv1 provided by Linux systems can only limit Direct I / O but not Buffered I / O due to architectural reasons. Therefore, in order to use cgroupv2 to limit Direct I / O and Buffered I / O, the target kernel will use a kernel version of Linux-4.5 or above.

[0070] It should be noted that cgroups (ControlGroups) is a feature of the Linux kernel that is used to perform fine-grained control and monitoring of resource usage of process groups. Cgroups provides a mechanism that allows system administrators or process schedulers to organize processes into tree-structured groups and to restrict and prioritize resource usage (such as CPU time, system memory, disk I / O, etc.) of these groups. Currently, the Linux system can provide two versions: cgroupv1 and cgroupv2.

[0071] In this embodiment, after determining the target kernel, the target kernel of the target virtual machine can be packaged through the packaging script in the Kata project. Specifically, the Kata project can be downloaded first, and then the download path can be determined based on the target kernel of the target virtual machine, and then the target kernel and dependent packages of the target version can be downloaded according to the download path.

[0072] For example, you can use the following packaging script to build a target kernel:

[0073] . / kata-containers / tools / packaging / kernel / build-kernel.sh-ax86_64-d-v5.4.71setup

[0074] It should be noted that:

[0075] . / kata-containers / tools / packaging / kernel / build-kernel.sh: indicates the path of the script file to be executed.

[0076] -ax86_64: Specifies that the kernel architecture to be built is x86_64.

[0077] -d: This parameter is usually used to enable debug mode, which may provide more output information during the build process.

[0078] -v5.4.71: specifies the kernel version to build, here is 5.4.71.

[0079] setup: This may be a parameter to the script that specifies a particular phase or configuration of the build process.

[0080] Through the above packaging script, you can download the 5.4.7 version of the Linux kernel and dependent packages, and then build a target virtual machine with the 5.4.7 version of the kernel. The target virtual machine supports both Direct I / O mode and Buffered I / O mode.

[0081] S102: Deploy a target virtual machine into at least one target container of a container cluster.

[0082] In a specific implementation, the container runtime attribute of the target container can be configured as the target container runtime corresponding to the target virtual machine, so that the target container is started with the target container runtime. Among them, the target container runtime can adopt the Kata container runtime.

[0083] It should be noted that KataContainers (Kata for short) is an open source container runtime technology that combines the advantages of lightweight virtual machines (VMs) and container technologies. KataContainers can build lightweight virtual machines that seamlessly access the container ecosystem, providing higher security and isolation while maintaining performance. Using hardware virtualization technology as the second layer of defense provides stronger workload isolation, isolating the host kernel and the container kernel, with zero impact on the host.

[0084] In this implementation, the container cluster may adopt a Kubernetes cluster, and a Kata container runtime is deployed in the Kubernetes cluster, and the target container is set to start using the Kata runtime.

[0085] Reference Figure 2 , shows the Kata runtime architecture diagram. Specifically, Figure 2 This is an architecture diagram of KataContainers integrated with Kubernetes. The following is an explanation of the components in the diagram:

[0086] Kubernetes: This is a container orchestration platform for automating the deployment, scaling, and management of applications.

[0087] Shim: Before Kubernetes 1.20, Shim was an independent component used to pass information between Kubelet and container runtime. In Kubernetes 1.20, Shim was integrated into Kubelet.

[0088] Runtime: This is the implementation of the container runtime, which is responsible for the actual container lifecycle management, such as creating, starting, stopping, and deleting containers. In the case of Kata Containers, the Runtime interacts with the hypervisor.

[0089] Proxy: This component is responsible for network proxy, ensuring communication between containers.

[0090] gRPC: This is a high-performance remote procedure call (RPC) framework for communication between Kubelet and container runtime.

[0091] OCIcmd / spec: These are commands and specifications defined by the Open Container Initiative (OCI) to standardize the runtime environment of containers.

[0092] Virtual Machine: A virtual machine is the environment in which containers run. It provides the resource isolation required by containers.

[0093] Container Command: This is the command or application that runs inside the container.

[0094] Containernamespace: Container namespace provides resource isolation, making the processes within the container appear to be running in an independent system.

[0095] Agent: This is the agent running in the VM that interacts with the container runtime.

[0096] Kernel: This is the kernel of the virtual machine, which provides the core functions of the operating system.

[0097] Hypervisor: This is the virtual machine monitor that allows multiple virtual machines to run on the same physical hardware.

[0098] gRPCoverYamux: This is a feature of gRPC that allows multiplexing of multiple gRPC streams over a single TCP connection.

[0099] It should be noted that the above architecture shows how Kubernetes interacts with the Kata Containers container runtime through CRI and how containers run in virtual machines. This architecture allows Kubernetes to integrate with Kata Containers, providing container isolation while maintaining the lightweight and fast startup characteristics of containers.

[0100] In the specific implementation, you can download the installation package from the official website, unzip it to the corresponding directory according to the document, and configure it according to the document; then create a crd object RuntimeClass in the kubernetes cluster. The RuntimeClass is as follows:

[0101] apiVersion: node.k8s.io / v1beta1

[0102] handler: kata-shimv2

[0103] kind:RuntimeClass

[0104] metadata:

[0105] name:kata-shimv2

[0106] It should be noted that:

[0107] apiVersion: node.k8s.io / v1beta1: specifies the version of Kubernetes API, which is the v1beta1 version under the node.k8s.io group;

[0108] handler:kata-shimv2: defines the name of the handler, here is kata-shimv2, the handler is the specific runtime that implements RuntimeClass.

[0109] kind: RuntimeClass: Specifies the type of Kubernetes object, here is RuntimeClass.

[0110] metadata: indicates metadata.

[0111] name: kata-shimv2: Specifies a name for the RuntimeClass object, which is also kata-shimv2.

[0112] RuntimeClass allows cluster administrators to configure different container runtimes for different purposes. For example, you can configure a RuntimeClass for a Pod that requires specific security features, or another RuntimeClass for a Pod that requires specific resource configuration. Therefore, by setting the Runtimeclass attribute of the pod container to kata-shimv2, you can deploy the kata container runtime in the kubernetes cluster.

[0113] S103: constructing a target image based on the target virtual machine and the preset executable file.

[0114] In this embodiment, the executable file is used to perform I / O speed limit on the container. That is, by executing the executable file, the I / O speed limit daemon process can be run, and the I / O speed limit daemon process can perform I / O speed limit on the target container during the use of the target container.

[0115] It should be noted that a daemon is a special process that runs in the background, which is independent of the control terminal and periodically performs certain tasks or loops to wait for certain events to occur. In this embodiment, the I / O speed limit daemon can limit the I / O speed of the target disk when it detects that the target disk has an I / O operation.

[0116] In this embodiment, by copying the executable file to the target image, the target container can automatically execute the I / O speed limit daemon after startup, and configure the block device cgroup to achieve the I / O speed limit effect.

[0117] In a specific implementation, the root file system corresponding to the operating system of the target virtual machine can be compiled first; then the root file system is packaged and exported as an initial image; finally, the executable file is deployed to the initial image to build the target image.

[0118] In this embodiment, taking the CentOS operating system as an example, the root file system (rootfs) of CentOS can be compiled according to the following packaging script:

[0119] EXTRA_PKGS='kmod'. / tools / osbuilder / rootfs-builder / rootfs.sh-r / root / katabuild / kata-containers-main / tools / osbuilder / rootfs-builder / rootfscentos

[0120] It should be noted that:

[0121] EXTRA_PKGS = 'kmod': This environment variable specifies additional packages that need to be installed when building rootfs. Here, the kmod package is included, which provides tools and libraries for loading and unloading kernel modules.

[0122] . / tools / osbuilder / rootfs-builder / rootfs.sh: This is the script for executing rootfs building. It is located in the tools / osbuilder / rootfs-builder / directory of the KataContainers project.

[0123] -r / root / katabuild / kata-containers-main / tools / osbuilder / rootfs-builder / rootfs: This parameter specifies the root directory for rootfs building. All files and directories in the building process will be created and managed under this path. This path is the output directory for storing the rootfs after the building is completed.

[0124] centos: This parameter specifies the operating system distribution to build. In this example, the target is CentOS.

[0125] It should be noted that the above rootfs can be used for lightweight virtual machines in the KataContainers project. This packaging script adds additional packages to the CentOS rootfs build process and specifies the output directory.

[0126] Then, follow the following script to package and export the rootfs as an initial image:

[0127] script-fec'sudo-EUSE_DOCKER=true. / image_builder.sh / root / katabuild / kata-containers-main / tools / osbuilder / rootfs-builder / rootfs'

[0128] It should be noted that:

[0129] script-fec: The script command is used to record terminal sessions. The -f option indicates that a file of type typescript is not automatically created. The -e option indicates that the script is exited after execution. The -c option indicates that the command is executed.

[0130] 'sudo-EUSE_DOCKER=true. / image_builder.sh...': This is a command recorded by the script command. sudo-E means to execute the command with root privileges, and the -E option (or --preserve-env) will preserve the environment variables. USE_DOCKER=true sets an environment variable to instruct the image_builder.sh script to use Docker to build the image.

[0131] . / image_builder.sh: This is a script that performs packaging and export operations and is located in the / root / katabuild / kata-containers-main / tools / osbuilder / rootfs-builder / directory.

[0132] / root / katabuild / kata-containers-main / tools / osbuilder / rootfs-builder / rootfs: This is the path to rootfs, that is, the location of the root file system built previously.

[0133] Through the above script, after building the root file system (rootfs), it can be packaged and exported as an image file to obtain the initial image.

[0134] In this embodiment, by further deploying the executable file into the initial image, the target image can be finally constructed, so that the I / O speed limit daemon process can be automatically executed after the target container is started.

[0135] S104: Run the target image in the target container, so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file, and performs I / O speed limit on the target container.

[0136] In this embodiment, in order to ensure that the target virtual machine can successfully execute the I / O speed limit daemon process, the executable file will be configured to the target path so that the target virtual machine can obtain the executable file through the target path and run the I / O speed limit daemon process corresponding to the executable file to perform I / O speed limit on the target container.

[0137] In the specific implementation, the I / O rate limit daemon can be started through the Kata hook mechanism, and the executable file is configured to the hook path. The hook path is set by the following parameters:

[0138] io.Kata Containers.config.hypervisor.guest_hook_path

[0139] It should be noted that the above parameter is a parameter in the KataContainers configuration, which specifies the path inside the virtual machine (VM) for placing hooks. The hook includes executable files that are called at specific moments in the container life cycle, such as before the container is started (prestart), after it is started (poststart), and after it is stopped (poststop). By setting this parameter, you can customize the behavior of the container so that it can be rate-limited by the I / O rate-limiting daemon at the appropriate time.

[0140] In this implementation, the I / O rate limiting daemon is used to perform the following steps:

[0141] S201: Obtain the structure object of the target container.

[0142] In this embodiment, the structure object includes the mount point path and the mounted disk information. Different types of containers may correspond to different structure objects. Among them, the mount point path defines how the file system inside the container interacts with the file system of the target virtual machine.

[0143] For example, in a Kata container, the structure object may be a specs.State object. As a structure, the specs.State object contains various state information when the container is started. This object is passed to hook scripts or programs at different stages of the container life cycle so that they can access and manipulate the state of the container. Specifically, the specs.State object may include the cgroupv2 path of the container and the mounted disk information.

[0144] S202: Receive I / O speed limit information.

[0145] In this embodiment, the administrator can design a human-computer interaction interface and input I / O speed limit information through the human-computer interaction interface, so that the I / O speed limit daemon process performs targeted speed limit based on the received I / O speed limit information.

[0146] In this embodiment, the I / O speed limit information includes a device identifier and a speed limit parameter. The speed limit parameter may specifically include a BPS parameter and an IOPS parameter, wherein BPS (Bits Per Second) is a unit for measuring data transmission rate. It indicates the number of bits that can be transmitted in one second; IOPS (Input / Output Operations Per Second) is an indicator for measuring the performance of a storage device, which indicates the number of input / output operations that can be completed per second, which can be read operations, write operations, or a combination of read and write operations.

[0147] S203: Based on the device identifier, determine the target disk in the disk information; and based on the speed limit information, configure the I / O configuration file located under the mount point path to perform I / O speed limit on the target disk.

[0148] In this implementation, the disk information includes all disks that can be used by the target virtual machine. Each disk has a corresponding device identifier. Therefore, based on the device identifier, the target disk can be indexed.

[0149] In this implementation, the I / O profile is a control group that limits each disk I / O.

[0150] In the specific implementation, the I / O configuration file can be the io.max file under the cgroupv2 path. Specifically, after the I / O speed limit daemon is started, the hook mechanism will pass the specs.State object of the target container, which contains all the information of the container, including the cgroupv2 path of the container and the mounted disk information. The io.max file under the cgroupv2 path is the control group that limits I / O.

[0151] Specifically, based on the I / O limits of BPS and IOPS, the block device (i.e., the target disk) is specified by the ¥MAJ:¥MIN device number. The following parameters can be defined to control the I / O performance of the block device:

[0152] =======================================

[0153] rbps Maxreadbytespersecond

[0154] wbps Maxwritebytespersecond

[0155] riopsMaxreadIOoperationspersecond

[0156] wiopsMaxwriteIOoperationspersecond

[0157] =======================================

[0158] rbps (Maxreadbytespersecond): This parameter is used to set the maximum number of bytes that a block device can read per second. By limiting the amount of reads per second, you can control the speed at which containers access storage resources and avoid excessive I / O pressure on the host or other containers.

[0159] wbps (Maxwritebytespersecond): Similar to rbps, this parameter is used to set the maximum number of bytes written per second to the block device. It is also used to control the I / O performance of the container to ensure that write operations do not consume excessive storage resources.

[0160] riops (MaxreadIOoperationspersecond): This parameter defines the maximum number of read I / O operations per second for a block device. The number of I / O operations refers to the count of disk read and write operations. Limiting this value can control the frequency of container access to the disk.

[0161] wiops (MaxwriteIOoperationspersecond): This parameter defines the maximum number of write I / O operations per second for a block device. Corresponding to riops, wiops is used to control the frequency of write operations to avoid excessive pressure on the storage system.

[0162] The above parameters allow the I / O rate limit daemon to fine-tune the I / O performance of the container based on the needs of the container and the availability of system resources, so as to achieve reasonable resource allocation and optimize the operating efficiency of the container. In this way, KataContainers provides an effective mechanism to manage the storage I / O of containers, ensuring that containers can run efficiently and securely in a virtualized environment.

[0163] In an example, suppose there is a device / dev / rbd0, the device number is 8:0, and the iops needs to be limited to 100 and the throughput bandwidth is 100M / s. You only need to set io.max as follows:

[0164] echo'8: 0rbps=104857600wbps=104857600riops=100wiops=100'>io.max

[0165] It should be noted that rbps and wbps are set to 104857600 bytes / second respectively. Since 1MB=1048576 bytes, 100MB / s=100*1048576; riops and wiops are both set to 100, indicating a maximum of 100 read and write operations per second.

[0166] In this implementation, by writing the speed limit information into the corresponding position of the io.max file, a custom speed limit setting for the target disk can be implemented.

[0167] In the specific implementation, when using cgroupv2 to implement I / O speed limit, you can develop the BlkioDaemon daemon process and copy the executable file of the BlkioDaemon daemon process to the rootfs image. In this way, the BlkioDaemon daemon process will be automatically executed after the container is started, and the block device cgroup will be configured to achieve the I / O speed limit effect. Figure 3 , shows the speed limit architecture diagram of the target virtual machine. Specifically, the figure shows the workflow of the BlkioDaemon daemon process used to implement container I / O speed limit in KataContainers. The following is a Figure 3 Explanation of each part:

[0168] ContainerCommand: This is the container command or process that runs inside the virtual machine and needs to perform I / O operations.

[0169] IO: Indicates the input and output operations between container commands and block devices. The container's I / O requests are sent to the block device through this interface.

[0170] / dev / rbd0 and / dev / rbd1: Device files, representing block devices inside the virtual machine. In KataContainers, these device files may represent virtual disks or other storage devices.

[0171] cgroupV2fordevice: This is Linux's control group (cgroups) version 2, which is used for resource management and isolation. Here, it is used to limit the I / O resources that can be allocated to containers, such as bandwidth and IOPS.

[0172] settingdevicecgroup2toio.max: indicates that the I / O speed limit information is applied to a specific device to limit the I / O performance of the container.

[0173] BlkioDaemon: A daemon process responsible for managing I / O operations of block devices. It controls the rate of I / O requests based on I / O speed limit information to implement the speed limit function.

[0174] Agent: In KataContainers, the agent is a key component that is responsible for communicating with the hypervisor and managing the container lifecycle and resource allocation.

[0175] CustomKemel(supportcgroupV2): This is a customized kernel that supports cgroups version 2. This kernel provides support for advanced resource management features, including I / O rate limiting.

[0176] Hypervisor: A virtual machine monitor that manages the hardware resources of a virtual machine, including CPU, memory, and I / O devices. In KataContainers, the Hypervisor is also responsible for forwarding the container's I / O requests to the block devices inside the virtual machine.

[0177] Specifically, the target container command sends I / O requests through the IO interface, and these requests are passed to BlkioDaemon through the device file ( / dev / rbd0 or / dev / rbd1). BlkioDaemon configures the io.max file based on the received I / O speed limit information to control the rate of I / O requests. Agent and CustomKernel provide the necessary support to ensure the correct implementation of the I / O speed limit function. Hypervisor is responsible for managing the resources of the virtual machine at the bottom layer and ensuring that the container's I / O requests can be processed correctly.

[0178] In this embodiment, by doing secondary development based on the Kata container runtime and customizing the Kata lightweight virtual machine kernel, the BlkioDaemon daemon process can be run on the target virtual machine to set the cgroupv2blkio module of the virtual machine, thereby achieving the effect of container disk I / O speed limit. Specifically, the embodiment of the present invention has the following beneficial effects:

[0179] (1) Improve the stability and reliability of container clusters. Applicable to all disk types, it can customize the I / O speed limit for each target container in the container cluster, so that disk reading and writing between containers are stable and do not interfere with each other.

[0180] (2) High security. Since the Kata container runtime runs container services in a lightweight virtual machine, the container kernel is isolated from the host kernel, and can be seamlessly connected to the container ecosystem with zero impact on the host.

[0181] (3) There is no need to modify the existing customer container business architecture, and the impact on customer container business is minimal.

[0182] (4) The I / O speed limit implemented based on cgroupv2 can meet the speed limits of both Direct I / O and Buffered I / O file I / O modes.

[0183] In the second aspect, based on the same inventive concept, refer to Figure 4 , an embodiment of the present invention provides an I / O speed limiting device 400, the I / O speed limiting device 400 comprising:

[0184] A virtual machine construction module 401 is used to obtain a target kernel and construct a target virtual machine based on the target kernel;

[0185] A virtual machine deployment module 402, configured to deploy a target virtual machine into at least one target container of a container cluster;

[0186] The image building module 403 is used to build a target image based on the target virtual machine and a preset executable file; the executable file is used to limit the I / O speed of the container;

[0187] The speed limit control module 404 is used to run the target image in the target container so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file to perform I / O speed limit on the target container.

[0188] In one embodiment of the present invention, the I / O speed limiting device 400 further includes:

[0189] The kernel determination module is used to determine the target kernel based on a preset file I / O mode; the target kernel is a kernel that supports the file I / O mode.

[0190] In one embodiment of the present invention, the virtual machine deployment module 400 includes:

[0191] The attribute configuration submodule is used to configure the container runtime attribute of the target container to the target container runtime corresponding to the target virtual machine, so that the target container is started with the target container runtime.

[0192] In one embodiment of the present invention, the image building module 403 includes:

[0193] Compile submodule, used to compile the root file system corresponding to the operating system of the target virtual machine;

[0194] The image packaging submodule is used to package the root file system and export it as the initial image;

[0195] The file deployment submodule is used to deploy the executable file into the initial image to build the target image.

[0196] In one embodiment of the present invention, the speed limit control module 404 includes:

[0197] The path configuration submodule is used to configure the executable file to the target path so that the target virtual machine obtains the executable file through the target path and runs the I / O speed limit daemon corresponding to the executable file to limit the I / O speed of the target container.

[0198] In one embodiment of the present invention, the I / O rate limiting daemon is used to perform the following steps:

[0199] Get the structure object of the target container; the structure object includes the mount point path and the mounted disk information;

[0200] Receive I / O speed limit information; the I / O speed limit information includes device identification and speed limit parameters;

[0201] Based on the device identifier, the target disk is determined in the disk information; and based on the speed limit information, the I / O configuration file located under the mount point path is configured to perform I / O speed limit on the target disk.

[0202] It should be noted that the specific implementation of the I / O speed limiting device 400 of the embodiment of the present invention refers to the specific implementation of the I / O speed limiting method proposed in the first aspect of the embodiment of the present invention, which will not be repeated here.

[0203] Based on the same inventive concept, Figure 5 An embodiment of the present invention further provides an electronic device 500, comprising a memory 501, a processor 502, and a computer program stored in the memory 501 and executable on the processor 502, which, when executed by the processor, implements the steps in the I / O speed limiting method of any of the above embodiments.

[0204] It should be noted that the specific implementation of the electronic device 500 in the embodiment of the present invention refers to the specific implementation of the I / O speed limiting method proposed in the first aspect of the embodiment of the present invention, which will not be repeated here.

[0205] Based on the same inventive concept, an embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the steps in the I / O speed limiting method of any of the above embodiments are implemented.

[0206] It should be noted that the specific implementation of the computer-readable storage medium in the embodiment of the present invention refers to the specific implementation of the I / O speed limiting method proposed in the first aspect of the embodiment of the present invention, and will not be repeated here.

[0207] Based on the same inventive concept, an embodiment of the present invention provides a computer program product, including a computer program / instruction, which implements the steps in the I / O speed limiting method of any of the above embodiments when executed by a processor.

[0208] It should be noted that the specific implementation of the computer program product in the embodiment of the present invention refers to the specific implementation of the I / O speed limiting method proposed in the first aspect of the above-mentioned embodiment of the present invention, and will not be repeated here.

[0209] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0210] It should be understood by those skilled in the art that the embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0211] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0212] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0213] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0214] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0215] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0216] The above is a detailed introduction to an I / O speed limiting method, device, electronic device, storage medium and program product provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for a person skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. An I / O speed limiting method, characterized in that: The method comprises: Obtaining a target kernel, and constructing a target virtual machine based on the target kernel; Deploy the target virtual machine into at least one target container of the container cluster; Based on the target virtual machine and a preset executable file, a target image is constructed; the executable file is used to limit the I / O speed of the container; The target image is run in the target container, so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file, and performs I / O speed limit on the target container.

2. The I / O speed limiting method according to claim 1, characterized in that: Before obtaining the target kernel, the method further includes: Based on a preset file I / O mode, the target kernel is determined; the target kernel is a kernel that supports the file I / O mode.

3. The I / O speed limiting method according to claim 1, characterized in that: Deploying the target virtual machine into at least one target container of the container cluster includes: The container runtime attribute of the target container is configured as the target container runtime corresponding to the target virtual machine, so that the target container is started with the target container runtime.

4. The I / O speed limiting method according to claim 1, characterized in that: Based on the target virtual machine and the preset executable file, a target image is constructed, including: Compile the root file system corresponding to the operating system of the target virtual machine; Packaging and exporting the root file system as an initial image; The executable file is deployed into the initial image to construct the target image.

5. The I / O speed limiting method according to claim 1, characterized in that: Running the target image in the target container so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file and performs I / O speed limit on the target container includes: The executable file is configured to a target path, so that the target virtual machine obtains the executable file through the target path, and runs an I / O speed limit daemon process corresponding to the executable file to perform I / O speed limit on the target container.

6. The I / O speed limiting method according to claim 5, characterized in that: The I / O rate limiting daemon is used to perform the following steps: Obtain a structure object of the target container; the structure object includes a mount point path and mounted disk information; Receive I / O speed limit information; the I / O speed limit information includes a device identifier and a speed limit parameter; Based on the device identifier, a target disk is determined in the disk information; and based on the speed limit information, an I / O configuration file located under the mount point path is configured to perform I / O speed limit on the target disk.

7. An I / O speed limiting device, characterized in that: The device comprises: A virtual machine construction module, used to obtain a target kernel and construct a target virtual machine based on the target kernel; A virtual machine deployment module, used to deploy the target virtual machine into at least one target container of the container cluster; An image building module, used to build a target image based on the target virtual machine and a preset executable file; the executable file is used to limit the I / O speed of the container; The speed limit control module is used to run the target image in the target container so that the target virtual machine runs the I / O speed limit daemon corresponding to the executable file to perform I / O speed limit on the target container.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the I / O speed limiting method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the I / O speed limiting method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps in the I / O speed limiting method described in any one of claims 1 to 6 are implemented.

Citation Information

Cited By

  • Virtual block device I / O speed limit control method and system based on device mapping framework

    CN121957502A

  • Method and system for controlling virtual block device I / O throttling based on device mapping framework

    CN121957502B