Method and device for adjusting storage space of container data volume

Abstract

The invention provides a method and a device for adjusting a storage space of a container data volume. Relates to the field of container data volume storage capacity expansion, and aims at a scene that a kata security container uses an external iscsi disk as a data volume, when a container storage plug-in controller module (controller) receives a capacity expansion request, the method comprises the following steps: firstly, carrying out capacity expansion on an iscsi LUN on an external storage system, then executing an operation of scanning the disk on a host running by the container to obtain a new size of the iscsi disk, and finally, carrying out data volume expansion on the new size of the iscsi disk. The method comprises the following steps: when a file system is mounted on a kata virtual machine, a container storage plug-in node module notifies a kata container to update the size of a data volume, finally, after a kata-agent running in the kata virtual machine receives a capacity expansion request, the space size of a virtual disk is refreshed, the file system on the virtual disk is expanded in a mounting state, and finally the capacity expansion processing is completed.

Description

Technical Field

[0001] This disclosure relates to the field of container data volume storage expansion, and in particular to a method and apparatus for adjusting the storage space of a container data volume. Background Technology

[0002] With the rapid development of cloud computing and containerization technologies, Kubernetes, as a core component of container orchestration systems, has become crucial in enterprise application deployments. In a Kubernetes environment, the Container Storage Module (CSI) enables dynamic management of container data volumes through the collaborative work of the controller and Node modules. Specifically, this storage system covers key aspects from storage resource allocation, volume creation and mounting, to volume expansion and unloading. Persistent Volume Claims (PVCs) describe the container's storage resource requirements, while external storage systems provide persistent storage capabilities via the iSCSI protocol. To enhance container security, Kata containers utilize lightweight virtualization technology, employing a customized QEMU virtual machine to achieve isolation from the host machine, thus building a container runtime environment that balances security and performance.

[0003] However, existing technologies for Kata containers using iSCSI disks as data volumes typically lack a complete mechanism for dynamically expanding storage space during container operation. Specifically, traditional container expansion operations often rely on manual intervention or require interrupting container services, leading to impaired application continuity. While Kata containers offer isolation advantages, their expansion coordination mechanism with external storage systems is not yet perfect, especially after iSCSI LUN expansion, where significant deficiencies exist in areas such as disk information synchronization between the host and virtual machines, and online file system adjustments. Furthermore, existing solutions cannot automatically recover from incomplete expansion operations if node outages occur during expansion, such as system crashes, thus impacting system stability and operational efficiency. Therefore, there is an urgent need for a technical solution that enables automatic, continuous, and recoverable expansion of container data volume storage space during operation to meet the pressing demand for high-availability storage in cloud-native environments. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] This invention proposes a method for adjusting the storage space of a container data volume.

[0006] Another object of the present invention is to provide an apparatus for adjusting the storage space of a container data volume.

[0007] To achieve the above objectives, a first aspect of the present invention provides a method for adjusting the storage space of a container data volume, comprising:

[0008] S1, monitor changes in the storage space size field of the persistent volume declaration PVC corresponding to the container data volume, and trigger the expansion process when an update to the storage space size field is detected; S2 calls the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and calls the management interface of the external storage system to expand the iSCSI LUN. S3 scans the SCSI bus on the host through the container storage plugin node module to obtain the updated iSCSI disk size, and notifies the virtual machine where the Kata container is located of the change in disk size through the QEMU block_resize message; S4 sends a gRPC request to the kata-agent process within the kata virtual machine to expand the data volume. Upon receiving the request, kata-agent scans the disk list within the virtual machine, updates the size of the virtio-blk device, and, when the file system is in a mounted state, calls the file system expansion command to complete the online expansion of the file system.

[0009] In one embodiment of the present invention, S1 includes: S11 monitors changes to the resources.requests.storage field of PVC objects in real time through listeners in Kubernetes helper containers; S12, when an increase in the value of the resources.requests.storage field is detected, a scaling event is generated and sent to the controller module of the container storage plugin.

[0010] In one embodiment of the present invention, S2 includes: S21. Query the corresponding StorageClass configuration based on the storageClassName field of the PVC, and extract the management IP address and storage pool name of the external storage system from it; S22 obtains user authentication information from the backend storage system through the Kubernetes Secret object, including the administrator username and encrypted password, and performs authentication when calling the management interface.

[0011] In one embodiment of the present invention, S4 includes: S41, after receiving the gRPC request, kata-agent first scans the virtio-blk device inside the virtual machine to confirm that its corresponding disk size has been updated; S42, if the file system is detected to be in a mounted state, a hidden file .filesystem_resize is created in the root directory of the file system to record the start time of the expansion operation, and the file is deleted after the expansion is successful.

[0012] In one embodiment of the present invention, it further includes: S5. When the expansion operation is interrupted due to node crash or other abnormalities, if the existence of the .filesystem_resize file is detected when the container starts up again, the file system expansion process will be automatically triggered to complete the previously unfinished expansion operation.

[0013] To achieve the above objectives, another aspect of the present invention provides an apparatus for adjusting the storage space of a container data volume, comprising: The monitoring module is used to monitor changes in the storage space size field of the persistent volume declaration PVC corresponding to the container data volume. When an update to the storage space size field is detected, the expansion process is triggered. The expansion request module is used to call the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and call the management interface of the external storage system to expand the iSCSI LUN. The disk update module is used to scan the SCSI bus on the host through the container storage plugin node module, obtain the updated iSCSI disk size, and notify the virtual machine where the Kata container is located of the change in disk size through the QEMU block_resize message. The container notification module is used to send a gRPC request for data volume expansion to the kata-agent process inside the kata virtual machine. After receiving the request, kata-agent scans the disk list inside the virtual machine, updates the size of the virtio-blk device, and calls the file system expansion command to complete the online expansion of the file system when the file system is in a mounted state.

[0014] The method and apparatus for adjusting container data volume storage space according to embodiments of the present invention enable dynamic expansion of data volume storage space based on iSCSI disk during container operation without interrupting container services, thereby improving the automation level of storage management and the continuity of system operation.

[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for adjusting the storage space of a container data volume according to an embodiment of the present invention; Figure 2 This is a module deployment diagram according to an embodiment of the present invention; Figure 3 This is a flowchart of a data volume expansion process according to an embodiment of the present invention; Figure 4 This is a structural diagram of an apparatus for adjusting the storage space of a container data volume according to an embodiment of the present invention. Detailed Implementation

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0019] A method and apparatus for adjusting the storage space of a container data volume according to an embodiment of the present invention are described below with reference to the accompanying drawings.

[0020] The following describes the technical terms that may be used in the embodiments of the present invention: Kubernetes: A software system for container scheduling and cluster management, providing basic mechanisms for the scalability of container applications and managing the lifecycle of containers.

[0021] PVC (PersistentVolumeClaim): A persistent volume declaration used to describe a container's storage resource requirements, such as the size of the data volume, the file system type, and the storage pool it resides in.

[0022] Kata Container: A secure container based on lightweight virtualization. In this invention, the Kata container runs in a customized QEMU virtual machine process. User container applications are isolated from the host machine through virtualization, ensuring that container applications will not damage the host machine system and improving the security of both the container and the host machine.

[0023] kata-agent: A process that runs in the virtual machine where the Kata container resides. It is used to initialize the Kata container's runtime environment, monitor the container's status, and receive gRPC requests from external sources to perform operations such as querying data volume status and scaling up.

[0024] Example 1 Figure 1 This is a flowchart of a method for adjusting the storage space of a container data volume according to an embodiment of the present invention, such as... Figure 1 As shown, it includes: S1 monitors changes to the storage size field of the persistent volume declaration PVC corresponding to the container data volume. When an update to the storage size field is detected, the expansion process is triggered.

[0025] Specifically, this step involves listening to the `storage` field of a Persistent Volume Claim (PVC) in Kubernetes and triggering the container volume expansion process when an update to this field is detected. In practice, a listening mechanism is deployed in an auxiliary container of the container storage plugin to monitor PVC object change events in real time. When a change in the `storage` field value is detected, the system calls the `VolumeResize` interface of the container storage plugin's Controller module to initiate subsequent expansion operations. This listening mechanism is typically based on Kubernetes' Watch mechanism, dynamically sensing the storage size field by monitoring changes to the `ResourceVersion` of the PVC object in the API Server. After detecting an update event, the system verifies whether the PVC's `storageClassName` field points to a storage class that supports dynamic expansion (StorageClass) and confirms whether its associated iSCSI LUN has expansion capabilities.

[0026] The `storage` field of a PVC declares the required volume size for the container, typically in Gi (Gibibyte) or GB (Gigabyte), depending on the storage class configuration specification. In expansion requests, the updated value of this field must be greater than the currently allocated storage capacity; otherwise, the system will ignore invalid requests. Furthermore, the `provisioner` field in the StorageClass must be configured to support iSCSI dynamic expansion (such as `kubernetes.io / iscsi` or a custom CSI plugin), and `volumeBindingMode` in `parameters` must be set to `WaitForFirstConsumer` to ensure that storage resource binding and expansion preparation are completed before container scheduling. For authentication, the administrator username and password of the backend storage system must be stored in Base64 encoded form in a Kubernetes Secret object, such as `iscsi-storage-secret`, and bound to the PVC via the `annotations` or `spec` fields.

[0027] This step is applicable to stateful application deployments based on Kata containers in Kubernetes environments, particularly for applications such as databases, log systems, and file servers that require dynamic adjustment of storage capacity. When a user updates the `storage` field of a PVC via the Kubernetes API, the system can automatically recognize and trigger the scaling process without manual intervention or container restart, thereby achieving elastic scaling of storage resources. This mechanism is especially suitable for automated operation and maintenance scenarios in cloud-native architectures, supporting container applications to dynamically adjust storage space based on changes in business load during runtime, improving resource utilization and system responsiveness.

[0028] This step automates and non-disruptively adjusts container data volume storage space by monitoring changes to the `storage` field of the PVC and triggering the expansion process. This mechanism effectively solves the problem of traditional container storage expansion requiring downtime or manual operation, improving the availability and operational efficiency of container applications. Simultaneously, by integrating with the Kubernetes Secret mechanism, it ensures the security and manageability of storage system authentication information, enhancing the overall system security and scalability. As the starting point of the entire expansion process, this step provides the triggering conditions and control entry point for subsequent iSCSI LUN expansion, virtual disk updates, and file system adjustments, making it a crucial link in achieving elastic management of container storage.

[0029] Furthermore, S1 includes: S11 monitors changes to the resources.requests.storage field of PVC objects in real time through listeners in Kubernetes helper containers.

[0030] Specifically, in a Kubernetes environment, real-time monitoring of changes to the `resources.requests.storage` field of a PVC object via a listener in the auxiliary container is a key technical step for enabling dynamic scaling of container data volumes. This step leverages the Watch mechanism provided by the Kubernetes API Server, combined with the CSI (Container Storage Interface) plugin architecture, to achieve real-time response and processing of storage resource requests.

[0031] In Kubernetes, the `resources.requests.storage` field of a PVC object declares the size of the storage space required by the container. When a user updates this field via kubectl or the API, the Kubernetes API Server broadcasts the change event to registered listeners. This invention deploys listeners in the auxiliary container of the storage plugin, continuously monitoring PVC object change events through the Watch interface. The listeners are implemented based on the Kubernetes Client-go library, subscribe to PVC resources under a specific namespace, and trigger a scaling process when the event type is `Modified`. After receiving a change event, the listener parses the `storage` field in the PVC object, determines whether it is a valid scaling request, and calls the `VolumeResize` interface of the container storage plugin's Controller module to pass the new storage request to the backend storage system.

[0032] The listener monitors the `resources.requests.storage` field, whose values ​​are typically represented as strings, such as `200G`, `500Gi`, etc., and must conform to the resource unit specifications defined by Kubernetes (such as `Gi`, `G`, `Ti`, etc.). The listener must support storage changes with a minimum granularity of 1 Gi, and upon detecting a change, send a `VolumeResize` request to the Controller module via the CSI interface. The request includes parameters such as the PVC name, namespace, and target storage size. After receiving the request, the Controller module must verify the backend storage IP address, storage pool name, and other parameters configured in the StorageClass, and combine this with the authentication information (such as username and password) stored in the Kubernetes Secret to complete the authentication and scaling operation of the backend storage system.

[0033] This step applies to stateful application deployments based on Kata containers, especially in environments using external iSCSI storage systems as data volume backends. For example, when a database container runs in a Kata virtual machine and uses iSCSI LUNs as persistent storage, if data growth during application operation leads to insufficient storage space, the user can initiate a scaling request by updating the `storage` field of the PVC. The listener captures this change in real time, triggering the subsequent storage scaling process, ensuring that the container application can obtain more storage space without restarting, thereby improving system availability and operational efficiency.

[0034] By monitoring changes to the `storage` field of PVC objects, a dynamic awareness and response mechanism for container storage resources is implemented, effectively solving the problem that traditional container storage expansion requires manual intervention or container restart. This step, as the trigger point for the entire expansion process, ensures the timeliness and accuracy of expansion requests, providing reliable prerequisites for subsequent iSCSI LUN expansion, virtual disk updates, and file system adjustments, thereby guaranteeing the continuous operation and data consistency of container applications during the expansion process.

[0035] S12, when an increase in the value of the resources.requests.storage field is detected, a scaling event is generated and sent to the controller module of the container storage plugin.

[0036] Specifically, when an increase in the value of the `resources.requests.storage` field is detected, generating and sending an expansion event to the controller module of the container storage plugin is one of the key technical steps in this invention for realizing dynamic expansion of container data volumes. This step is based on the Kubernetes (k8s) resource declaration mechanism, triggering the subsequent storage expansion process by listening to change events of PVC (PersistentVolumeClaim) objects.

[0037] In Kubernetes, PVC objects are used to declare a container's storage resource requirements. When a user updates the `resources.requests.storage` field of a PVC via API or kubectl commands, the Kubernetes API Server broadcasts this change event to the cluster. This invention deploys a PVC watcher in the auxiliary container of the storage plugin. This watcher monitors changes to the PVC object in real time using Kubernetes' Watch mechanism. When the watcher detects an increase in the `storage` field value, it triggers event handling logic, calling the `VolumeResize` interface of the container storage plugin's Controller module to pass the scaling request to the backend storage system.

[0038] Key parameters involved in this step include the `storageClassName` field of the PVC, which specifies the type and configuration of the backend storage system; and the `resources.requests.storage` field, which declares the required storage space size in GiB or GB (e.g., 200G). Furthermore, the management IP address of the backend storage system, the storage pool name, and user authentication information (such as username and password) are securely stored and transmitted through Kubernetes Secret objects to ensure that sensitive information is not exposed in plaintext.

[0039] This step is applicable to stateful application deployments based on Kata containers, especially in environments using iSCSI LUNs as container data volumes. When application data grows during container operation, leading to insufficient storage space, users can automatically trigger the expansion process without manual intervention by updating the storage field of the PVC, thereby achieving elastic scaling of storage resources.

[0040] By monitoring changes in the storage field of the PVC and automatically invoking the expansion interface of the Controller module, this invention achieves automated adjustment of container data volume storage space. This mechanism not only improves the flexibility and response speed of storage management but also effectively reduces operational complexity, ensuring the continuous operation of container applications during the expansion process and avoiding service interruptions due to insufficient storage. Furthermore, this step provides a triggering mechanism for subsequent disk scanning, virtual disk updates, and file system expansion, serving as the starting point and core control point of the entire expansion process.

[0041] S2 calls the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and calls the management interface of the external storage system to expand the iSCSI LUN.

[0042] Specifically, calling the VolumeResize interface in the container storage plugin controller module to expand the iSCSI LUN is one of the core technical steps in this invention for achieving dynamic expansion of container data volumes. This step is triggered by updating the storage field of the Kubernetes Persistent Volume Declaration (PVC), and interacts with the management interface of the external storage system through the CSI (Container Storage Interface) standard interface, thereby enabling online expansion of the underlying storage space of the container data volume.

[0043] In some implementations, when a user updates the storage field of a PVC via the Kubernetes API, a listener (such as an Operator or Controller Watcher) in the storage plugin auxiliary container detects the change and triggers a call to the VolumeResize interface. The controller module queries the corresponding StorageClass configuration based on the PVC's storageClassName field, extracting the management IP address and storage pool name of the external storage system. Simultaneously, it obtains the storage system's authentication information (such as username and password) through the Kubernetes Secret mechanism and uses HTTPS to call the external storage system's REST API interface to perform the iSCSI LUN resizing operation. This interface typically follows the API specifications defined by the storage vendor; for example, the REST endpoint supporting LUN capacity adjustment is ` / api / v1 / luns / {lun_id} / resize`, and the request body includes the target capacity (e.g., `"size": "250Gi"`).

[0044] Calling the VolumeResize interface depends on several key parameters, including but not limited to: PVC name, storage class name (storageClassName), target capacity (e.g., 200GiB to 250GiB), storage pool name (e.g., `pool-iscsi`), management IP address (e.g., `192.168.1.100`), and authentication credentials (Base64 encoded username and password). When calling external storage system APIs, ensure that the request header includes authentication information (e.g., `Authorization: Basic`).<base64_encoded_credentials> Set a timeout parameter (e.g., `timeout=30s`) to avoid congestion caused by network latency.

[0045] This step applies to stateful applications based on Kata containers in a Kubernetes environment, such as databases and logging systems that require persistent storage. When the data volume space is insufficient during container operation, users can update the PVC to expand the storage space online without manually stopping the container or virtual machine, thus ensuring business continuity.

[0046] Through the implementation of the VolumeResize interface, the controller module can automatically obtain and verify the configuration information of the external storage system, ensuring the accuracy and security of the expansion operation. This step effectively decouples the container storage plugin from the external storage system, improves the system's scalability and compatibility, and provides the foundation for subsequent SCSI bus scanning and file system expansion. It is an indispensable control hub in the entire expansion process.

[0047] Furthermore, S2 includes: S21. Query the corresponding StorageClass configuration based on the storageClassName field of the PVC, and extract the management IP address and storage pool name of the external storage system.

[0048] Specifically, after the container storage plugin controller module receives a data volume expansion request, it needs to query the corresponding StorageClass configuration based on the `storageClassName` field in the PVC object to extract the management IP address and storage pool name of the external storage system. This step is a crucial step in enabling dynamic expansion of container data volumes, and its technical implementation involves calling Kubernetes APIs, parsing storage class information, and obtaining security authentication information.

[0049] In some implementations, this step first queries the metadata of the specified PVC object via the Kubernetes API Server, specifically at the path ` / apis / v1 / namespaces / `. <namespace> / persistentvolumeclaims / <pvc-name>The system retrieves the complete structure of the PVC. Within the PVC's `spec` field, `storageClassName` specifies the storage class to which the PVC is bound; this field is a string type, such as `external-iscsi-storage`. Subsequently, the system calls ` / apis / storage.k8s.io / v1 / storageclasses / `. <storageclassname>The interface retrieves the configuration information of the storage class, which includes the `parameters` field, used to store the management IP address of the backend storage system (e.g., `192.168.1.100`) and the storage pool name (e.g., `iscsi-pool-01`).

[0050] Furthermore, to ensure access to the backend storage system, the system also needs to obtain authentication information from the Kubernetes Secret. The name of the Secret is typically associated with the `provisioner` field in the StorageClass configuration, such as `iscsi-storage-secret`. This is achieved by calling ` / apis / v1 / namespaces / `. <namespace> / secrets / <secret-name>The system can obtain the encrypted administrator username and password (e.g., `username: Admin`, `password: UyFCXGQkekRzYj0=`) through the interface and perform Base64 decoding for use when calling the storage system management interface later.

[0051] The technical specifications for this step include: PVC object query response time should be less than 500ms, storage class configuration resolution latency should be controlled within 200ms, and Secret access permissions must comply with the RBAC (Role-Based Access Control) specification to ensure that only authorized components can access sensitive information. Furthermore, the management IP address and storage pool name fields must conform to the Kubernetes StorageClass API standard (`kubernetes.io / v1`) to ensure compatibility and scalability.

[0052] In practical applications, this step runs on the Master node of the Kubernetes cluster and is executed by the Container Storage plugin Controller module. Its purpose is to provide the necessary configuration parameters for subsequent iSCSI LUN scaling operations, ensuring that scaling requests are accurately routed to the corresponding storage system. Through this step, the system achieves dynamic mapping and management of storage resources, improving the automation and security of container storage, and laying the foundation for subsequent disk space updates and file system adjustments.

[0053] S22 obtains user authentication information from the backend storage system through the Kubernetes Secret object, including the administrator username and encrypted password, and performs authentication when calling the management interface.

[0054] Specifically, this step involves obtaining user authentication information from the backend storage system through the Kubernetes Secret object and performing authentication when calling the management interface. This is a crucial step in enabling dynamic scaling of container data volumes. In the Kubernetes architecture, the Secret object is used to securely store sensitive information such as usernames, passwords, and API keys, and its data is stored in the `data` field in Base64 encoded form. In this invention, the administrator username and encrypted password of the backend storage system are encapsulated through the Secret object.

[0055] In the Controller module of the container storage plugin, upon receiving a data volume expansion request, it first queries the corresponding StorageClass object based on the `storageClassName` field in the PVC, extracting the management IP address and storage pool name of the backend storage system. Then, it queries the Secret object bound to this StorageClass via the Kubernetes API, decodes the `username` and `password` fields, and obtains the administrator credentials. This Secret object must have RBAC (Role-Based Access Control) permissions to ensure the Controller module can access its content.

[0056] Furthermore, when calling the management interface (such as a REST API or CLI interface) of the backend storage system, the decoded username and password must be used for authentication. Typically, the backend storage system supports interface access methods based on HTTP Basic Auth or Token authentication. In this invention, HTTP Basic Auth is preferred, combining the username and password into `Authorization: Basic`. <base64-encoded-credentials>The request header is sent to the storage system's management interface to perform the expansion operation of the iSCSI LUN.

[0057] From a technical implementation perspective, this step ensures the secure management and dynamic retrieval of storage system authentication information, avoiding security risks associated with hard-coded sensitive information. Simultaneously, through the integration of the Kubernetes API with storage plugins, automated and policy-based management of storage resources is achieved, complying with the requirements for storage controller modules in the CSI (Container Storage Interface) standard specification.

[0058] In practical applications, this step is commonly used in stateful applications based on Kata containers in cloud-native environments, such as databases and logging systems. Through the Secret mechanism, operations personnel can flexibly configure authentication information for different storage systems, achieving unified management of multiple storage backends. Furthermore, this step provides the necessary permission foundation for subsequent iSCSI LUN expansion, virtual disk updates, and file system adjustments, making it a core component for security control and system integration in the entire expansion process. Its technical value lies in enhancing the security, flexibility, and maintainability of container storage management, providing reliable authentication guarantees for non-disruptive expansion.

[0059] S3 scans the SCSI bus on the host through the container storage plugin node module to obtain the updated iSCSI disk size, and notifies the virtual machine where the Kata container is located of the change in disk size through the QEMU block_resize message.

[0060] Specifically, in the Node module of the container storage plugin, the updated iSCSI disk size is obtained by performing a SCSI bus scan operation, and the virtual machine hosting the Kata container is notified of the change in disk size via a QEMU `block_resize` message. This is one of the key steps in achieving dynamic storage expansion in this invention. The core of this step is to ensure that storage changes on the host side can be perceived and synchronously updated by the container environment within the virtual machine, thereby achieving seamless storage space expansion.

[0061] In the `NodeVolumeResize` interface of the Node module, the `rescan-scsi-bus` command provided by the Linux kernel is first invoked to scan the SCSI bus on the host. This command triggers the kernel to re-identify connected iSCSI LUN devices by sending SCSI RESCAN requests to device nodes under ` / sys / class / scsi_host`. After the scan is complete, the system updates ` / dev / disk / by-path` or ` / dev / sd`. The module obtains the latest disk size by checking the capacity information of the device nodes. Then, the Node module sends a disk capacity update message to the virtual machine running the Kata container via QEMU's `block_resize` interface. Upon receiving this message, QEMU updates its internal block device size and transmits the new disk capacity information to the virtual machine's operating system via the virtio-blk device.

[0062] When performing a SCSI bus scan, the `rescan-scsi-bus -a` command is typically used, where the `-a` parameter indicates that all SCSI hosts should be scanned. QEMU's `block_resize` interface supports sending requests via JSON-RPC or QMP protocols. Typical parameters include `device` (target device name) and `size` (new disk size in bytes). For example, `{"execute":"block_resize","arguments":{"device":"virtio0","size":214748364800}}` indicates that the disk size of device `virtio0` will be resized to 200GB. Furthermore, after calling `block_resize`, the Node module sends a scaling request to `kata-agent` within the Kata virtual machine via the gRPC interface. This request includes key parameters such as the target disk path (e.g., ` / dev / vda`) and the operation type (e.g., `resize`).

[0063] This step applies to scenarios where Kata containers are running in a Kubernetes environment, especially when external storage systems are mapped to container volumes using the iSCSI protocol. When a user initiates a scaling request by updating the `storage` field of the PVC, the Node module needs to execute this process on the container's running node to ensure that the Kata container can promptly detect and adapt to the new disk capacity. This process does not require stopping the container, making it suitable for high-availability, low-interruption production environments.

[0064] By linking SCSI bus scanning with QEMU's `block_resize` message, this step synchronizes the storage state between the host and the virtual machine, ensuring that Kata containers can accurately identify and use the expanded disk space. This mechanism effectively solves the problem of traditional container storage expansion requiring container restarts, improves the automation level of storage management and system stability, and reduces operational complexity, demonstrating significant practical value and innovation.

[0065] S4 sends a gRPC request to the kata-agent process within the kata virtual machine to expand the data volume. Upon receiving the request, kata-agent scans the disk list within the virtual machine, updates the size of the virtio-blk device, and, when the file system is in a mounted state, calls the file system expansion command to complete the online expansion of the file system.

[0066] Specifically, in a Kata container environment, when online expansion of a container data volume is required, this step involves sending a gRPC request to the `kata-agent` process within the Kata virtual machine to automatically expand the data volume. This step is a crucial part of the entire container data volume expansion process. Its technical implementation is based on deep integration between the Container Storage Interface (CSI) and the Kata container, ensuring dynamic expansion of storage space without interrupting container operation.

[0067] In an architecture where Kata containers run on QEMU virtual machines, `kata-agent` acts as the management agent process within the virtual machine, responsible for receiving and processing gRPC requests from the host side. After the Node module of the container storage plugin completes its scan of the host-side SCSI disks and updates the LUN size, it notifies the Kata virtual machine of the disk size change via QEMU's `block_resize` mechanism. Subsequently, the Node module sends a `ResizeVolume` request to `kata-agent` via the gRPC interface. This request encapsulates the target disk's path (e.g., ` / dev / vda`) and the new disk capacity information. Upon receiving the request, `kata-agent` first calls commands such as `lsblk` or `blkid` to scan the disk list within the virtual machine and identify the corresponding virtio-blk device. Then, `kata-agent` updates the device size using tools such as `blockdev --setsize` or `parted`, ensuring that the virtual disk space has been correctly expanded.

[0068] The gRPC request must include key parameters such as the target disk identifier (e.g., `devicePath`), the new disk capacity (in bytes), and the file system type (e.g., ext4). Before performing file system resizing, `kata-agent` checks if the file system is mounted. If mounted correctly, it calls the `resize2fs / dev / vda` command to perform online resizing. Furthermore, to ensure the atomicity and recoverability of the resizing operation, `kata-agent` creates a hidden file `.filesystem_resize` in the file system root directory before resizing, recording the start timestamp of the operation. This file is deleted after the resizing is complete. This mechanism conforms to the standard operating procedure for online resizing of Linux file systems and enhances system fault tolerance.

[0069] This step applies to Kata containers running in a Kubernetes environment, especially in scenarios where stateful applications (such as databases and logging systems) require dynamic expansion of storage space. This mechanism allows users to expand data volumes during container runtime without manual intervention, thereby improving system availability and operational efficiency.

[0070] This step implements online expansion of Kata container data volumes, effectively solving the problem of traditional containers needing to restart or unmount volumes during expansion. Through gRPC communication and dynamic adjustment of the virtio-blk device, continuous operation of container applications is ensured during the expansion process. Simultaneously, a hidden file mechanism guarantees the reliability and recoverability of the expansion operation, significantly improving the automation level of container storage management and system stability.

[0071] Furthermore, S4 includes: S41, after receiving the gRPC request, kata-agent first scans the virtio-blk device inside the virtual machine to confirm that its corresponding disk size has been updated.

[0072] Specifically, after receiving the gRPC request, the kata-agent first performs a virtio-blk device scan within the virtual machine to confirm whether the corresponding disk size has been updated. This step is a crucial part of the entire container data volume expansion process, and its technical implementation is based on a collaborative mechanism between the virtualization device driver and the container storage plugin.

[0073] Kata-agent, the core management process running in the Kata container virtual machine (Guest VM), is responsible for receiving gRPC requests from the node module, a container storage plugin. Upon receiving a scaling request, Kata-agent first scans the virtio-blk device within the virtual machine by calling the Linux kernel's `sysfs` or ` / dev / disk / by-path` interface to obtain its current disk capacity information. This scan is typically implemented using the `blockdev --getsize64` or `lsblk` command to ensure the latest disk size is obtained. If a change in disk size is detected, the file system scaling process is further triggered.

[0074] The scan results of the virtio-blk device need to be compared with the previously recorded disk capacity to determine whether the expansion conditions are met. For example, if the original disk size is 200GB, and the scan result shows 300GB, it means that the backend iSCSI LUN has been successfully expanded. In addition, before performing file system expansion, kata-agent creates a hidden file `.filesystem_resize` in the root directory of the file system. This file records the start timestamp of the expansion operation (e.g., `2024-04-05T14:30:00Z`) for an exception recovery mechanism. If the expansion fails or is interrupted, this file will be retained so that the container can automatically retry the next time it starts.

[0075] This step is applicable to stateful container applications based on Kubernetes, especially data volume scenarios using iSCSI LUNs as persistent storage. In actual deployments, when a user initiates a scaling request by modifying the `storage` field of the PVC, the entire process must be completed without interrupting container operation. The kata-agent's scanning operation ensures the synchronous update of the virtual machine's internal storage state, providing accurate disk information for subsequent file system adjustments.

[0076] By scanning the virtio-blk device to confirm disk size updates, kata-agent can accurately identify storage changes and trigger file system expansion operations accordingly. This mechanism effectively avoids expansion failures or data inconsistencies caused by asynchronous storage states, improves the automation and reliability of container storage management, and ensures the continuous operation of container applications and data integrity.

[0077] S42, if the file system is detected to be in a mounted state, a hidden file .filesystem_resize is created in the root directory of the file system to record the start time of the expansion operation, and the file is deleted after the expansion is successful.

[0078] Specifically, in a Kata container runtime environment, when a data volume expansion request is received and the file system is detected to be mounted, the kata-agent process needs to create a hidden file `.filesystem_resize` in the root directory of the file system and delete this file after the expansion operation is completed. This step is a crucial part of the entire container data volume expansion process. Its technical implementation is based on the Linux file system management mechanism and the container runtime status monitoring capabilities, ensuring the atomicity and recoverability of the expansion operation.

[0079] After receiving a capacity expansion request from the node module via the gRPC interface, kata-agent first performs a disk scan to identify the capacity change of the virtio-blk device. Then, kata-agent checks whether the target disk is mounted using the `df -h` or `mount` command and confirms its file system type (e.g., ext4). If the file system is mounted, it calls the `resize2fs` command to expand the file system online. Before executing `resize2fs`, kata-agent creates a hidden file `.filesystem_resize` in the file system root directory (e.g., ` / `). This file typically records the start timestamp of the expansion operation in text format (e.g., `2024-04-05T14:30:00Z`) to mark the start status of the expansion operation. After the expansion is complete, kata-agent deletes this file via a script or system call, indicating that the expansion process has successfully ended.

[0080] Key parameters involved in this step include the file system type (e.g., ext4), disk device path (e.g., ` / dev / vda1`), mount point (e.g., ` / mnt / data`), execution parameters of the expansion command (e.g., `resize2fs -p / dev / vda1`), and the naming conventions and content format of hidden files. Furthermore, the file system expansion operation must be performed in a Linux kernel version that supports online expansion (e.g., kernel 3.6 or later), and the file system must be in a read-write mount state (not a read-only mount).

[0081] This step is applicable to scenarios where the data volume capacity is dynamically adjusted during container operation, especially in stateful applications (such as databases and logging systems), where container data volumes need to be expanded without service interruption. By creating and deleting the `.filesystem_resize` file, the system can automatically detect and resume incomplete expansion operations after an abnormal node restart, thereby improving system fault tolerance and operational efficiency.

[0082] This step, by introducing a status marking mechanism, effectively prevents the expansion operation from being interrupted due to node crashes or abnormal process exits, ensuring the integrity and recoverability of the expansion operation. At the same time, this mechanism avoids system instability caused by repeated expansions, improves the robustness and automation level of container storage management, and is an indispensable technical guarantee for realizing online expansion of container data volumes.

[0083] Also includes: S5. When the expansion operation is interrupted due to node crash or other abnormalities, if the existence of the .filesystem_resize file is detected when the container starts up again, the file system expansion process will be automatically triggered to complete the previously unfinished expansion operation.

[0084] Specifically, when the expansion operation is interrupted due to node crash or other abnormalities, if the existence of the `.filesystem_resize` file is detected when the container starts up again, the file system expansion process is automatically triggered to complete the previously incomplete expansion operation. This step is the key mechanism in this invention to ensure the atomicity and fault tolerance of the expansion operation. Its technical implementation principle is based on state marking and the self-check logic at container startup, combined with the collaborative process of Kubernetes Persistent Volume Declaration (PVC) and CSI (Container Storage Interface) storage plugin.

[0085] When kata-agent executes a file system expansion command (such as `resize2fs`), it first creates a hidden file `.filesystem_resize` in the root directory of the file system. This file marks the expansion operation as started but not yet completed. The file content may include metadata information such as the operation start timestamp and the target file system size. If the expansion operation is interrupted due to node failure, abnormal process exit, or other reasons, this file will be retained on disk. When the container starts again, kata-agent will actively scan the root directory of the file system during the initialization phase to check if this file exists. If the `.filesystem_resize` file is detected, it is considered that there is an incomplete expansion task, and the file system expansion process is automatically triggered without manual intervention.

[0086] The creation and deletion of `.filesystem_resize` files must adhere to the POSIX file system standard to ensure compatibility across different Linux distributions. File names should follow a fixed format, such as `.filesystem_resize`, to avoid confusion with other temporary files. Furthermore, file content should be in standard text format for easy script parsing and recovery. In Kubernetes, this mechanism works in conjunction with the `NodeVolumeResize` interface of the CSI storage plugin to ensure that after a SCSI disk size update is completed at the host level, the virtual machine can correctly recognize and execute file system expansion.

[0087] This mechanism is suitable for stateful applications based on Kata containers, such as databases and logging systems, which have high requirements for storage space continuity and data consistency. If the expansion operation is interrupted due to node failure during execution, the expansion process can be automatically resumed after the container restarts, avoiding data volume space inconsistency issues caused by expansion failure.

[0088] The technical benefits of this step are a significant improvement in the reliability and automation of container storage expansion. By introducing status marker files, the system can automatically complete any unfinished expansion operations after an anomaly recovery, thereby ensuring data availability and consistency for container applications after expansion interruptions, reducing operational complexity, and enhancing system fault tolerance.

[0089] The method for adjusting the storage space of a container data volume according to embodiments of the present invention enables dynamic expansion of the iSCSI disk during the operation of the container data volume, ensuring that the expansion operation does not interrupt the operation of the container, and improving system stability and the level of automation of storage management.

[0090] Example 2 Understandably, when containers are deployed in a Kubernetes environment, to achieve automated management of data volume storage space, a container storage plugin is typically deployed in Kubernetes. This plugin consists of a controller module and a node module. The controller module runs on the master node of the Kubernetes cluster, while the node module runs on the Kubernetes workload nodes. Typically, the controller module primarily handles the creation, deletion, attachment, and removal of data volumes from Kata virtual machines (VMs), while the node module mainly handles the mounting and unmounting of data volumes within Kata VMs.

[0091] It is understood that the method of this invention achieves expansion support for iSCSI disks by adding expansion interfaces to the container storage plugin controller module, node module, and kata-agent. The specific invention details are as follows: When expanding a data volume, first update the storage field of the PVC (Persistent Volume Declaration) corresponding to the data volume. The definition of a PVC is as follows: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-iscsi-pvc spec: accessModes: - ReadWriteOnce resources: requests: Storage: 200G storageClassName:external-iscsi-storage Call the Kubernetes interface to update the storage field in the PersistentVolumeClaim structure, and notify Kubernetes to start the expansion operation of the data volume.

[0092] The storage plugin auxiliary container listens for PVC objects. When the storage size field corresponding to the data volume changes, the storage plugin controller's VolumeResize interface is called to expand the data volume.

[0093] Implement the VolumeResize interface in the container storage plugin controller module. When the controller module receives a data volume expansion request, it expands the iSCSI LUN by calling the management interface of the backend storage system.

[0094] The NodeVolumeResize interface is implemented in the node module of the container storage plugin. After the csi-controller module completes the expansion operation of the iSCSI LUN, the kubelet process on the container runtime node calls the expansion interface in csi-node to perform subsequent expansion operations. In the NodeVolumeResize interface, the SCSI disk is first scanned to obtain the updated iSCSI LUN size. Then, the Kata virtual machine data volume size is notified of the change via the QEMU block_resize message. Finally, a gRPC request to expand the data volume is sent to the kata-agent running in the Kata virtual machine.

[0095] When the kata-agent running in the Kata virtual machine receives a gRPC request to expand a data volume, it first checks whether a file system exists on the virtual disk. If the container uses the virtual disk as a raw disk, no file system expansion operation is needed. If a file system exists on the virtual disk and is mounted, it then calls file system expansion commands such as resize2fs to expand the mounted ext4 file system.

[0096] In summary, the method for adjusting the storage space of a container data volume according to the present invention is implemented according to the following steps: S101, When expanding a data volume, first update the space size field of the corresponding PVC (Persistent Volume Declaration). The PVC definition format is as follows: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-iscsi-pvc spec: accessModes: - ReadWriteOnce resources: requests: Storage: 200G storageClassName:external-iscsi-storage S102, above storageClassName is the storage class corresponding to the PVC, which defines the management IP of the backend storage system and the name of the storage pool, etc.

[0097] User authentication information in the backend storage system is stored using Kubernetes Secrets, with the following record format: apiVersion: v1 kind: Secret metadata: name: iscsi-storage-secret type: Opaque data: username: Admin password: UyFCXGQkekRzYj0= S103: Set the storage field of the expanded data volume size in the PVC data structure, and then call the Kubernetes interface to start the expansion operation of the data volume.

[0098] The storage plugin auxiliary container listens for PVC objects. When the size field of the PVC corresponding to the data volume changes, the VolumeResize interface of the container storage plugin controller module is called to expand the data volume.

[0099] S104, implement the VolumeResize interface in the container storage plugin controller module. When the controller module receives a data volume expansion request, it queries the PVC information based on the data volume name and obtains the storage class corresponding to the data volume from the storageClassName field of the PVC structure. Based on the definition of the storage class external-iscsi-storage, it obtains the IP address of the external storage and the storage pool where the container data volume resides. Then, it queries the Kubernetes secret information and obtains the user authentication information of the backend storage system from iscsi-storage-secret, facilitating the calling of the backend storage management interface for storage information queries and expansion operations.

[0100] In step S105, after obtaining the management IP, username, and password information of the backend storage in the VolumeResize interface of the controller module, the backend storage's storage pool status query interface is called to check whether the free capacity of the storage pool meets the expansion requirements. If the conditions are met, the iscsi LUN is expanded by calling the management interface of the backend storage system. After the iscsi LUN expansion is completed, FilesystemResized is set to False in the returned information, and the container storage plugin node module performs subsequent file system expansion operations.

[0101] S106, the NodeVolumeResize expansion interface is implemented in the csi-node module of the container storage plugin. After the storage plugin controller module completes the expansion operation of the iSCSI LUN, the kubelet process on the container runtime node calls the expansion interface in the plugin node module to perform subsequent expansion operations. In the NodeVolumeResize interface, firstly, a scan of the iSCSI disk is performed on the host system to obtain the updated iSCSI disk size. Then, the QEMU block_resize message notifies the Kata virtual machine that the data volume size has changed. Finally, a gRPC request to expand the data volume is sent to the kata-agent running in the Kata virtual machine.

[0102] In S107, after receiving a gRPC request to expand a data volume, the kata-agent running in the Kata virtual machine first checks if a file system exists on the virtual disk. If the container uses the virtual disk as a raw disk, no file system expansion is needed. If a file system exists on the virtual disk and is mounted, it calls file system expansion commands such as `resize2fs` to expand the mounted ext4 file system. Before the expansion begins, a hidden file `.filesystem_resize` is created in the root directory of the file system, recording the start time of the operation. This file is deleted after the expansion is complete. This file is used to prevent interruption of the expansion operation (e.g., node crash). When the container starts again, it checks if this file exists in the container volume and performs the expansion operation again, completing the previously interrupted operation.

[0103] The method of this invention defines an expansion interface in the container storage plugin, obtains the user authentication information of the external storage system recorded in the Kubernetes secret, calls the management interface of the storage system, and expands the container data volume, thus ensuring the continuity of container application operation.

[0104] In one embodiment of the present invention, Figure 2 This is a schematic diagram of the module implementation of the present invention. The management IP and storage pool information of the external storage system are recorded in the storage class corresponding to the container data volume, and the user authentication information of the external storage system is recorded using a Kubernetes secret. In the auxiliary container, changes in the PVC space size corresponding to the data volume are monitored. When an expansion request is received, the VolumeResize interface in the container storage plugin controller module is called to obtain the management IP, storage pool, and user authentication information of the external storage system. The external storage management interface is then called to expand the iSCSI LUN corresponding to the container volume. Then, in the container storage plugin node module, the SCSI bus is rescanned, the expanded iSCSI LUN size is updated, and the virtual machine where the Kata container resides is notified that the size of the iSCSI disk it uses has changed. The node module initiates a gRPC request to the kata-agent process in the virtual machine where the Kata container resides. After receiving the gRPC request, the kata-agent in the Kata virtual machine rescans the disk list within the virtual machine and calls file system expansion commands such as resize2fs to expand the data volume space. Figure 3 As shown, the expansion process of the thought data volume of this invention may include the following technical solutions: Using the iSCSI LUN of the external storage system as the storage space for the data volume, during container operation, when the auxiliary container detects a change in the size of the PVC corresponding to the data volume, it calls the VolumeResize interface of the container storage plugin controller module to obtain the IP and authentication information of the external storage, and then calls the management interface of the external storage to expand the iSCSI LUN. Subsequently, the node module scans the SCSI bus on the host and notifies the virtual machine where the container is located of the change in the size of the iSCSI LUN, updates the virtual disk size in the Kata virtual machine, and finally, the kata-agent process in the virtual machine performs the file system expansion operation after receiving the gRPC data volume expansion request.

[0105] The storage class used is specified in the storageClassName field of the PVC corresponding to the container data volume. The storage class defines the management IP of the external storage and the name of the storage pool where the data volume is located.

[0106] User authentication information of the external storage system, such as administrator name and password, is recorded in the form of a Kubernetes secret for authorization when calling the storage management interface.

[0107] By monitoring changes in the PVC size corresponding to the data volume through the auxiliary container, when a request to update the data volume size is received, the VolumeResize interface of the container storage plugin controller module is called to perform subsequent expansion operations.

[0108] Implement the VolumeResize interface in the controller module of the container storage plugin. Query the corresponding storage class based on the data volume name to obtain the management IP and storage pool of the external storage. Then, obtain the user authentication information of the external storage from the Kubernetes secret information. Investigate the management interface of the external storage to check whether there is available space on the storage pool for expansion. If the conditions are met, perform expansion operation on the iSCSI LUN corresponding to the data volume.

[0109] In the VolumeResize interface's return information, the FilesystemResized property is set to False, and the subsequent file system expansion operation is performed by the container storage plugin node module. The storage plugin controller module is deployed on the Kubernetes master node, and the node module is deployed on the Kubernetes worker nodes.

[0110] After the controller module completes the expansion operation, the NodeVolumeResize interface needs to be implemented in the storage plugin node module to rescan the SCSI bus on the host and update the size of the iSCSI LUN.

[0111] In the NodeVolumeResize interface, the qemu block_resize command notifies the virtual machine hosting the Kata container that the size of its iSCSI LUN has changed, and the OS within the virtual machine updates the virtual disk size. Then, the node module sends a gRPC request to the kata-agent process in the virtual machine hosting the container to expand the data volume, notifying kata-agent to perform the file system expansion operation.

[0112] When kata-agent receives a gRPC request to expand a data volume, it scans the disk list within the virtual machine, updates the size of the virtio-blk device, and then checks the file system mount status. If the file system is mounted normally, it completes the file system expansion using the resize2fs command.

[0113] Before expanding the file system, a hidden file named `.filesystem_resize` is first created in the root directory of the file system. This file records the start time of the operation. When the expansion is completed normally, this file is deleted. This file is used to prevent abnormal interruption during the expansion process (such as node crashes). When the container starts again and checks the existence of this file in the data volume, it will perform the expansion operation again, completing the previously interrupted operation.

[0114] Example 3 To achieve the above embodiments, such as Figure 4 As shown, this embodiment also provides a device 10 for adjusting the storage space of a container data volume, including: The listening module 100 is used to monitor changes in the storage space size field of the persistent volume declaration PVC corresponding to the container data volume. When an update to the storage space size field is detected, the expansion process is triggered. The expansion request module 200 is used to call the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and call the management interface of the external storage system to expand the iSCSI LUN. The disk update module 300 is used to scan the SCSI bus on the host through the container storage plugin node module, obtain the updated iSCSI disk size, and notify the virtual machine where the kata container is located of the change in disk size through the QEMU block_resize message. The container notification module 400 is used to send a gRPC request for data volume expansion to the kata-agent process in the kata virtual machine. After receiving the request, kata-agent scans the disk list in the virtual machine, updates the size of the virtio-blk device, and calls the file system expansion command to complete the online expansion of the file system when the file system is in the mounted state.

[0115] Furthermore, the listening module is also used for: Monitor changes to the resources.requests.storage field of PVC objects in real time using a listener in a Kubernetes helper container; When an increase in the value of the resources.requests.storage field is detected, a scaling event is generated and sent to the controller module of the container storage plugin.

[0116] Furthermore, the expansion request module is also used for: Query the corresponding StorageClass configuration based on the storageClassName field of the PVC, and extract the management IP address and storage pool name of the external storage system from it; The system obtains user authentication information from the backend storage system through the Kubernetes Secret object, including the administrator username and encrypted password, and performs authentication when calling the management interface.

[0117] Furthermore, the container notification module is also used for: After receiving a gRPC request, kata-agent first scans the virtio-blk device inside the virtual machine to confirm that its corresponding disk size has been updated. If the file system is detected to be mounted, a hidden file named .filesystem_resize is created in the root directory of the file system to record the start time of the expansion operation, and the file is deleted after the expansion is successful.

[0118] Furthermore, it also includes: The exception recovery module is used to automatically trigger the file system expansion process when the expansion operation is interrupted due to node crash or other exceptions, and the .filesystem_resize file is detected when the container starts up again, so as to complete the previously incomplete expansion operation.

[0119] The apparatus for adjusting the storage space of a container data volume according to embodiments of the present invention can improve the stability of container operation and reduce the complexity of operation and maintenance without interrupting container operation.

[0120] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0121] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified. < / namespace> < / storageclassname> < / namespace>

Claims

1. A method for adjusting the storage space of a container data volume, characterized in that, include: S1, monitor changes in the storage space size field of the persistent volume declaration PVC corresponding to the container data volume, and trigger the expansion process when an update to the storage space size field is detected; S2 calls the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and calls the management interface of the external storage system to expand the iSCSI LUN. S3 scans the SCSI bus on the host through the container storage plugin node module to obtain the updated iSCSI disk size, and notifies the virtual machine where the Kata container is located of the change in disk size through the QEMU block_resize message; S4 sends a gRPC request to the kata-agent process within the kata virtual machine to expand the data volume. Upon receiving the request, kata-agent scans the disk list within the virtual machine, updates the size of the virtio-blk device, and, when the file system is in a mounted state, calls the file system expansion command to complete the online expansion of the file system.

2. The method as described in claim 1, characterized in that, S1 includes: S11 monitors changes to the resources.requests.storage field of PVC objects in real time through listeners in Kubernetes helper containers; S12, when an increase in the value of the resources.requests.storage field is detected, a scaling event is generated and sent to the controller module of the container storage plugin.

3. The method as described in claim 1, characterized in that, S2 includes: S21. Query the corresponding StorageClass configuration based on the storageClassName field of the PVC, and extract the management IP address and storage pool name of the external storage system from it; S22 obtains user authentication information from the backend storage system through the Kubernetes Secret object, including the administrator username and encrypted password, and performs authentication when calling the management interface.

4. The method as described in claim 1, characterized in that, The S4 includes: S41, after receiving the gRPC request, kata-agent first scans the virtio-blk device inside the virtual machine to confirm that its corresponding disk size has been updated; S42, if the file system is detected to be in a mounted state, a hidden file .filesystem_resize is created in the root directory of the file system to record the start time of the expansion operation, and the file is deleted after the expansion is successful.

5. The method as described in claim 1, characterized in that, Also includes: S5. When the expansion operation is interrupted due to node crash or other abnormalities, if the existence of the .filesystem_resize file is detected when the container starts up again, the file system expansion process will be automatically triggered to complete the previously unfinished expansion operation.

6. An apparatus for adjusting the storage space of a container data volume, characterized in that, include: The monitoring module is used to monitor changes in the storage space size field of the persistent volume declaration PVC corresponding to the container data volume. When an update to the storage space size field is detected, the expansion process is triggered. The expansion request module is used to call the VolumeResize interface of the container storage plug-in controller module to obtain the management IP address, storage pool name and user authentication information of the external storage system, and call the management interface of the external storage system to expand the iSCSI LUN. The disk update module is used to scan the SCSI bus on the host through the container storage plugin node module, obtain the updated iSCSI disk size, and notify the virtual machine where the Kata container is located of the change in disk size through the QEMU block_resize message. The container notification module is used to send a gRPC request for data volume expansion to the kata-agent process inside the kata virtual machine. After receiving the request, kata-agent scans the disk list inside the virtual machine, updates the size of the virtio-blk device, and calls the file system expansion command to complete the online expansion of the file system when the file system is in a mounted state.

7. The apparatus as claimed in claim 2, characterized in that, The monitoring module is also used for: Monitor changes to the resources.requests.storage field of PVC objects in real time using a listener in a Kubernetes helper container; When an increase in the value of the resources.requests.storage field is detected, a scaling event is generated and sent to the controller module of the container storage plugin.

8. The apparatus as claimed in claim 3, characterized in that, The expansion request module is also used for: Query the corresponding StorageClass configuration based on the storageClassName field of the PVC, and extract the management IP address and storage pool name of the external storage system from it; The system obtains user authentication information from the backend storage system through the Kubernetes Secret object, including the administrator username and encrypted password, and performs authentication when calling the management interface.

9. The apparatus as claimed in claim 4, characterized in that, The container notification module is also used for: After receiving a gRPC request, kata-agent first scans the virtio-blk device inside the virtual machine to confirm that its corresponding disk size has been updated. If the file system is detected to be mounted, a hidden file named .filesystem_resize is created in the root directory of the file system to record the start time of the expansion operation, and the file is deleted after the expansion is successful.

10. The apparatus as claimed in claim 5, characterized in that, Also includes: The exception recovery module is used to automatically trigger the file system expansion process when the expansion operation is interrupted due to node crash or other exceptions, and the .filesystem_resize file is detected when the container starts up again, so as to complete the previously incomplete expansion operation.

Images