Method and system for automatically managing virtual machine images based on k8s

Abstract

The application discloses a method and system for automatically managing virtual machine images based on K8S, and belongs to the technical field of virtual machine images. The application aims to solve the technical problem of how to reduce the cost of managing virtual machine images. The technical solution is as follows: the method combines the government cloud deployment scene with site construction and packaging operation, automatically outputs the virtual machine image cr file and the virtual machine image file package corresponding to the current site, deploys the virtual machine image operator, automatically uploads the virtual machine image according to the cr and the image file package, and later users directly use glance for reference. The specific implementation is as follows: the virtual machine image cr is deployed to a specified environment, and the virtual machine image file is stored in a specified position; the virtual machine image operator polls the environment cr; when the current cr is detected, the virtual machine image is uploaded, the correctness of the virtual machine image is verified, the image data is updated, and the processing of multi-architecture support is performed; and according to the configuration, it is selected whether the cleaning processing after uploading is needed.

Description

Technical Field

[0001] This invention relates to the field of virtual machine image technology, specifically a method and system for automated management of virtual machine images based on K8S. Background Technology

[0002] Operators are a form of Kubernetes extension that helps users manage applications and services in a declarative API style. In Kubernetes, Deployments, DamenSets, StatefulSets, Services, Ingresses, ConfigMaps, and Secrets are all resources. The creation, updating, and deletion of these resources are called events. The Kubernetes Controller Manager listens for these events and triggers corresponding actions to meet the specified expectations. This declarative approach means that users only need to focus on the final state of the application. Kubernetes also provides custom resources and operators to extend applications based on Kubernetes.

[0003] Virtual machine images are system images used by virtual machines. As the types of virtual machine images increase, the number of corresponding virtual machine image files also gradually increases. Due to the different needs of local government cloud environments, the required virtual machine images and corresponding virtual machine image files also vary. Therefore, how to reduce the cost of managing virtual machine images is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] The technical objective of this invention is to provide a method and system for automated management of virtual machine images based on Kubernetes (K8S) to address the problem of reducing the cost of managing virtual machine images.

[0005] The technical task of this invention is achieved as follows: a method for automated management of virtual machine images based on Kubernetes. This method combines government cloud deployment scenarios with site building and packaging operations to automatically generate the virtual machine image CR file and virtual machine image file package corresponding to the current site. Then, a virtual machine image operator is deployed, and the virtual machine image is automatically uploaded according to the CR and image file package. Later, users can directly use Glance to reference it. Specifically, as follows:

[0006] Deploy the virtual machine image (cr) to the specified environment and store the virtual machine image file in the specified location;

[0007] Virtual machine image operator polling environment cr;

[0008] Upon detecting the current cr, perform the following steps: upload virtual machine image, verify the correctness of the virtual machine image, update image data, and handle multi-architecture support.

[0009] Depending on the configuration, select whether post-upload cleanup is required.

[0010] As a preferred choice, cr is a resource instance corresponding to crd, and the deployment of cr is as follows:

[0011] Generate CRD: Based on the metadata attributes currently used by virtual machine images, summarize and adjust a common CRD format;

[0012] Generate cr: Create metadata cr for each virtual machine image according to the configuration;

[0013] Deploying cr: Store the cr file in the chart project that uses the virtual machine image, and deploy the chart project, which completes the current cr deployment.

[0014] As a preferred option, the virtual machine image file is stored in the specified location as follows:

[0015] The virtual machine image operator connects to a specified folder on the host machine using the host machine folder mounting method;

[0016] In the cr file of each virtual machine image, the path attribute is maintained to configure the location of the virtual machine file relative to the mount folder, which facilitates subsequent image uploads.

[0017] As a preferred method, the specific steps for uploading the virtual machine image are as follows:

[0018] Ceph upload method: Import the image into Ceph using the RBD command, and then synchronize the uploaded data to Glance. Glance operates using the API and simultaneously retrieves the image list data and stores it in the cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data is forced to be refreshed once.

[0019] Glance upload method: Upload virtual machine images via Glance. Glance operates via API and simultaneously retrieves image list data and stores it in a cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data is forcibly refreshed.

[0020] Preferably, the correctness verification of the virtual machine image includes the following:

[0021] ① Convert the virtual machine image from qcow2 format to raw format. Before conversion, it will check whether the hash value of the current virtual machine image file is consistent with the one defined in cr.

[0022] ② Verify whether the hash value of the uploaded image is consistent with the hash value of the raw format virtual machine image file;

[0023] ③ Verify whether the uploaded image is in an active state.

[0024] More specifically, image data updates allow changes to the image's tag attributes and the addition of custom attributes. Other metadata attributes, except when releasing a new version, are not allowed to be updated within the same version.

[0025] Multi-architecture support means that when creating a Dockerfile, you only need to select a simple image under different architectures as the base image, install the required commands in sequence, and execute the build instructions to obtain a specific image that is suitable for different architectures.

[0026] More specifically, the state transition process for a single cr is as follows:

[0027] (1) When the Operator first starts processing the current image (cr), the state switches to pending; during the current process, it connects to Glance to perform image detection, and the detection point is to determine whether the current image architecture matches.

[0028] ① If there is no match, the system enters the archskip state and proceeds to step (11).

[0029] ② If a match is found, proceed to step (2);

[0030] (2) Determine if the current image already exists in glance, and also determine if its status is active:

[0031] ① If the lookup does not exist or / and the status is not active, then proceed to step (3);

[0032] ② If it exists in glance and its status is active, then execute step (4);

[0033] (3) Determine if the local virtual machine image file for the current image exists:

[0034] ① If it exists, the state enters the uploading state, and the next step is to execute step (5);

[0035] ② If it does not exist, the status will enter error, and the next step will be to execute step (10);

[0036] (4) Determine whether custom attributes need to be updated:

[0037] ① If an update is required, enter the updating state and proceed to step (9);

[0038] ② If no update is needed, enter the active state and proceed to step (12).

[0039] (5) When the status is "uploading" and requires uploading, check whether the hash value of the current image file is consistent with the hash value provided in cr:

[0040] ① If there is a discrepancy, enter the error state and proceed to step (10);

[0041] ② If they match, proceed to step (6);

[0042] (6) Determine if the available space under the currently mounted folder on the host machine is greater than the limit:

[0043] ① If there is insufficient space, the system will enter an error state and proceed to step (10).

[0044] ② If there is sufficient space, proceed to step (7);

[0045] (7) Depending on the configuration, choose to upload directly from Glance or upload from RBD first and then synchronize Glance, and determine if there are any errors during the upload process:

[0046] ① If there is an error, the system will enter the error state and proceed to step (10).

[0047] ② If there are no errors, proceed to step (8);

[0048] (8) After successful upload, verify the status and hash value of the uploaded image to ensure they match the hash value of the converted raw format:

[0049] ① If the test fails, the system will enter the error state and proceed to step (10).

[0050] ② If the verification passes, proceed to step (9);

[0051] (9) When the status is "updating" and needs to be updated, retrieve the tags and custom attributes defined in the current cr, update the data in the glance data, and determine whether the update was successful:

[0052] ① If the update fails, it will enter the error state and proceed to step (10).

[0053] ② If the update is successful, the system will enter the active state and proceed to step (12).

[0054] (10) When the status enters error each time, the failure reason is recorded in the status.reason property of cr. The cr in the error status will be retried after a set time and added to the cache queue for the next round of processing. Then, jump to step (1) and start again from the pending status. The retry strategy is to retry once at a set time interval.

[0055] (11) archskip is the final state of CR when the architecture defined in CR does not match the architecture of the government cloud environment; and according to the actual use case, to adapt to the situation of human configuration error, CR that supports the archskip state will perform an architecture matching check again after restarting the operator's pod; and for the current round, it is still regarded as the final state, and the archskip state will not be processed again after the architecture is checked for the first time in the current environment.

[0056] (12) "Active" is the final state of the CR that matches the architecture defined in the CR with the architecture of the government cloud environment. In the "active" state, it is determined whether the CR has been updated:

[0057] ① If cr is no longer updated, it will not be processed again;

[0058] ② If the tag or custom attribute of cr is updated, jump to step (1) and enter a new round of processing.

[0059] A system for automated management of virtual machine images based on Kubernetes, the system includes,

[0060] The deployment module is used to deploy the virtual machine image (cr) to a specified environment and store the virtual machine image file in a specified location;

[0061] The polling module is used for virtual machine image operators to poll the environment cr;

[0062] The processing module is used to detect the current CR, and perform tasks such as uploading virtual machine images, verifying the correctness of virtual machine images, updating image data, and supporting multiple architectures.

[0063] The cleanup module is used to select whether post-upload cleanup is required based on the configuration.

[0064] An electronic device includes: a memory and a processor;

[0065] The memory stores computer-executed instructions;

[0066] The processor executes the computer execution instructions stored in the memory, causing the processor to perform the above-described method for automated management of virtual machine images based on K8S.

[0067] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method for automated management of virtual machine images based on Kubernetes.

[0068] The method and system for automated management of virtual machine images based on Kubernetes (K8S) of the present invention have the following advantages:

[0069] (I) This invention provides Inspur Cloud with a method for automated management of virtual machine images based on k8s. Users only need to provide the cr of the virtual machine image and the virtual machine image file package used to automatically complete the upload of the corresponding virtual machine image file. The file content can be adjusted as needed, and it has good portability.

[0070] (ii) This invention can reduce the complexity of virtual machine image management: During deployment, the cr file will be deployed directly to the environment along with the component deployment, and this process does not require manual operation; the image file will be created along with the operation, and only needs to be copied from the packaging environment to the deployment environment by human; the virtual machine image operator itself is a component and can be deployed through LCM; during updates, only the cr file corresponding to the image needs to be modified, and the operator will automatically complete the image update.

[0071] (III) This invention can improve the correctness of uploaded images: each image is verified three times during the upload process to ensure the availability of successfully uploaded images;

[0072] (iv) The present invention has an automatic retry mechanism: virtual machine images that fail to upload for various reasons will be automatically retried every once in a period of time without human intervention;

[0073] (V) This invention automates the management of custom resources (virtual machine images) through the operator, including functions such as detection, update, and upload. It is maintained in each component chart through cr and deployed to the environment along with the chart. At the same time, the virtual machine image upload supports two upload methods, RBD and Glance, which can be configured according to the actual situation. It is easy to operate and has great value for promotion and use. Attached Figure Description

[0074] The invention will be further described below with reference to the accompanying drawings.

[0075] Appendix Figure 1 This is a flowchart of a method for automating virtual machine image management based on Kubernetes;

[0076] Appendix Figure 2 A flowchart of the state transitions for a single cr. Detailed Implementation

[0077] The method and system for automated management of virtual machine images based on K8S of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0078] Example 1:

[0079] As attached Figure 1 As shown, the present invention provides a method for automated management of virtual machine images based on Kubernetes. This method combines government cloud deployment scenarios with site building and packaging operations to automatically generate the virtual machine image CR file and virtual machine image file package corresponding to the current site. Then, a virtual machine image operator is deployed to automatically upload the virtual machine image based on the CR and image file package. Later, users can directly use Glance to reference it. The details are as follows:

[0080] S1. Deploy the virtual machine image cr to the specified environment and store the virtual machine image file in the specified location;

[0081] S2, Virtual machine image operator polling environment cr;

[0082] S3. Upon detecting the current cr, perform the following steps: upload virtual machine image, verify the correctness of the virtual machine image, update image data, and handle multi-architecture support.

[0083] S4. Based on the configuration, select whether post-upload cleanup is required.

[0084] In step S1 of this embodiment, cr is a resource instance corresponding to crd, and the deployment of cr is as follows:

[0085] S101. Generate CRD: Based on the metadata attributes currently used by virtual machine images, summarize and adjust a common CRD format.

[0086] S102. Generate cr: Create metadata cr for each virtual machine image according to the configuration;

[0087] S103. Deploy cr: Store the cr file in the chart project that uses the virtual machine image, and deploy the chart project to complete the current cr deployment.

[0088] In this embodiment, the virtual machine image file is stored in the specified location in step S1 as follows:

[0089] The virtual machine image operator connects to a specified folder on the host machine by mounting the host machine folder. In the cr file of each virtual machine image, the path attribute is maintained to configure the position of the virtual machine file relative to the mounted folder, which facilitates subsequent image uploads.

[0090] The specific method for uploading the virtual machine image in step S3 of this embodiment is as follows:

[0091] ① Ceph upload method: Import the image into Ceph using the RBD command, and then synchronize the uploaded data to Glance. Glance operates using the API and simultaneously retrieves the image list data and stores it in the cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data will be forcibly refreshed.

[0092] ② Glance upload method: Upload virtual machine images through Glance. Glance operates via API and simultaneously retrieves image list data and stores it in the cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data will be forcibly refreshed once.

[0093] The correctness verification of the virtual machine image in step S3 of this embodiment includes the following situations:

[0094] ① Convert the virtual machine image from qcow2 format to raw format. Before conversion, it will check whether the hash value of the current virtual machine image file is consistent with the one defined in cr.

[0095] ② Verify whether the hash value of the uploaded image is consistent with the hash value of the raw format virtual machine image file;

[0096] ③ Verify whether the uploaded image is in an active state.

[0097] In this embodiment, step S3, updating the image data specifically refers to allowing changes to the image's tag attribute and the addition of custom attributes. Other metadata attributes are not allowed to be updated within the same version unless a new version is released.

[0098] In step S3 of this embodiment, multi-architecture support means that when creating a Dockerfile, you only need to select a simple image under different architectures as the base image, install the required commands in sequence, and execute the build instructions to obtain a specific image that is suitable for different architectures.

[0099] As attached Figure 2 As shown, the state transition process of a single cr is as follows:

[0100] (1) When the Operator first starts processing the current image (cr), the state switches to pending; during the current process, it connects to Glance to perform image detection, and the detection point is to determine whether the current image architecture matches.

[0101] ① If there is no match, the system enters the archskip state and proceeds to step (11).

[0102] ② If a match is found, proceed to step (2);

[0103] (2) Determine if the current image already exists in glance, and also determine if its status is active:

[0104] ① If the lookup does not exist or / and the status is not active, then proceed to step (3);

[0105] ② If it exists in glance and its status is active, then execute step (4);

[0106] (3) Determine if the local virtual machine image file for the current image exists:

[0107] ① If it exists, the state enters the uploading state, and the next step is to execute step (5);

[0108] ② If it does not exist, the status will enter error, and the next step will be to execute step (10);

[0109] (4) Determine whether custom attributes need to be updated:

[0110] ① If an update is required, enter the updating state and proceed to step (9);

[0111] ② If no update is needed, enter the active state and proceed to step (12).

[0112] (5) When the status is "uploading" and requires uploading, check whether the hash value of the current image file is consistent with the hash value provided in cr:

[0113] ① If there is a discrepancy, enter the error state and proceed to step (10);

[0114] ② If they match, proceed to step (6);

[0115] (6) Determine if the available space under the currently mounted folder on the host machine is greater than the limit:

[0116] ① If there is insufficient space, the system will enter an error state and proceed to step (10).

[0117] ② If there is sufficient space, proceed to step (7);

[0118] (7) Depending on the configuration, choose to upload directly from Glance or upload from RBD first and then synchronize Glance, and determine if there are any errors during the upload process:

[0119] ① If there is an error, the system will enter the error state and proceed to step (10).

[0120] ② If there are no errors, proceed to step (8);

[0121] (8) After successful upload, verify the status and hash value of the uploaded image to ensure they match the hash value of the converted raw format:

[0122] ① If the test fails, the system will enter the error state and proceed to step (10).

[0123] ② If the verification passes, proceed to step (9);

[0124] (9) When the status is "updating" and needs to be updated, retrieve the tags and custom attributes defined in the current cr, update the data in the glance data, and determine whether the update was successful:

[0125] ① If the update fails, it will enter the error state and proceed to step (10).

[0126] ② If the update is successful, the system will enter the active state and proceed to step (12).

[0127] (10) When the status enters error each time, the failure reason is recorded in the status.reason property of cr. The cr in the error status will be retried after a set time and added to the cache queue for the next round of processing. Then, jump to step (1) and start again from the pending status. The retry strategy is to retry once after an interval of (number of retries * 2).

[0128] (11) archskip is the final state of CR when the architecture defined in CR does not match the architecture of the government cloud environment; and according to the actual use case, to adapt to the situation of human configuration error, CR that supports the archskip state will perform an architecture matching check again after restarting the operator's pod; and for the current round, it is still regarded as the final state, and the archskip state will not be processed again after the architecture is checked for the first time in the current environment.

[0129] (12) "Active" is the final state of the CR that matches the architecture defined in the CR with the architecture of the government cloud environment. In the "active" state, it is determined whether the CR has been updated:

[0130] ① If cr is no longer updated, it will not be processed again;

[0131] ② If the tag or custom attribute of cr is updated, jump to step (1) and enter a new round of processing.

[0132] Example 2:

[0133] The present invention relates to a system for automated management of virtual machine images based on Kubernetes (K8S), the system comprising:

[0134] The deployment module is used to deploy the virtual machine image (cr) to a specified environment and store the virtual machine image file in a specified location;

[0135] The polling module is used for virtual machine image operators to poll the environment cr;

[0136] The processing module is used to detect the current CR, and perform tasks such as uploading virtual machine images, verifying the correctness of virtual machine images, updating image data, and supporting multiple architectures.

[0137] The cleanup module is used to select whether post-upload cleanup is required based on the configuration.

[0138] Example 3:

[0139] This invention also provides an electronic device, including: a memory and a processor;

[0140] The memory stores computer-executed instructions;

[0141] A processor executes computer execution instructions stored in the memory, causing the processor to perform the method for automated management of virtual machine images based on K8S as described in any one of the present invention.

[0142] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0143] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.

[0144] Example 4:

[0145] This invention also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the method for automated management of virtual machine images based on Kubernetes in any embodiment of this invention. Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0146] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0147] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0148] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0149] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0150] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automated management of virtual machine images based on Kubernetes, characterized in that, This method combines government cloud deployment scenarios with site building and packaging operations to automatically generate the virtual machine image (CR) file and virtual machine image package corresponding to the current site. Then, a virtual machine image operator is deployed, and the virtual machine image is automatically uploaded based on the CR and image package. Users can then directly reference it using Glance. Details are as follows: Deploy the virtual machine image (cr) to the specified environment and store the virtual machine image file in the specified location; Virtual machine image operator polling environment cr; Upon detecting the current cr, perform the following steps: upload virtual machine image, verify the correctness of the virtual machine image, update image data, and handle multi-architecture support. Depending on the configuration, select whether post-upload cleanup is required; Here, cr is a resource instance corresponding to crd, and the deployment of cr is as follows: Generate CRD: Based on the metadata attributes currently used by virtual machine images, summarize and adjust a common CRD format; Generate cr: Create metadata cr for each virtual machine image according to the configuration; Deploying cr: Store the cr file in the chart project that uses the virtual machine image, deploy the chart project, and the current cr deployment is completed; The virtual machine image file is stored in the specified location as follows: The virtual machine image operator connects to a specified folder on the host machine using the host machine folder mounting method; In the cr file of each virtual machine image, the path attribute is maintained to configure the location of the virtual machine file relative to the mount folder, which facilitates subsequent image uploads; The specific methods for uploading a virtual machine image are as follows: Ceph upload method: Import the image into Ceph using the RBD command, and then synchronize the uploaded data to Glance. Glance operates using the API and simultaneously retrieves the image list data and stores it in the cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data is forced to be refreshed once. Glance upload method: Upload virtual machine images through Glance. Glance operates via API and simultaneously retrieves image list data and stores it in the cache. The list data is refreshed once within a set time period. If there is an upload operation within the set time period, the list data will be forcibly refreshed. The correctness verification of virtual machine images includes the following situations: ① Convert the virtual machine image from qcow2 format to raw format. Before conversion, it will check whether the hash value of the current virtual machine image file is consistent with the one defined in cr. ② Verify whether the hash value of the uploaded image is consistent with the hash value of the raw format virtual machine image file; ③ Verify whether the uploaded image is in an active state; Image data updates specifically refer to allowing changes to the image's tag attribute and the addition of custom attributes. Other metadata attributes, except when releasing a new version, are not allowed to be updated within the same version. Multi-architecture support means that when creating a Dockerfile, you only need to select a simple image under different architectures as the base image, install the required commands in sequence, and execute the build instructions to obtain a specific image that is suitable for different architectures. The state transition process of a single cr is as follows: (1) When the Operator first starts processing the current image CR, the state switches to pending; during the current process, it connects to Glance to perform image detection, and the detection point is to determine whether the current image architecture matches: ① If there is no match, enter the archskip state and proceed to step (11). ② If a match is found, proceed to step (2); (2) Determine if the current image already exists in glance, and also determine if its status is active: ① If the lookup does not exist or / and the status is not active, then proceed to step (3); ② If it exists in glance and its status is active, then execute step (4); (3) Determine if the local virtual machine image file for the current image exists: ① If it exists, the state enters the uploading state, and the next step is to execute step (5). ② If it does not exist, the status will enter error, and the next step will be to execute step (10). (4) Determine whether custom attributes need to be updated: ① If an update is required, enter the updating state and proceed to step (9). ② If no update is needed, enter the active state and proceed to step (12). (5) When the status is "uploading" and requires uploading, determine whether the hash value of the current image file is consistent with the hash value provided in cr: ① If there is a discrepancy, the error state will be entered and the next step (10) will be executed. ② If they match, proceed to step (6); (6) Determine if the available space under the currently mounted folder on the host machine is greater than the limit: ① If there is insufficient space, the system will enter an error state and proceed to step (10). ② If there is sufficient space, proceed to step (7); (7) Depending on the configuration, select to upload directly to Glance or upload to RBD first and then synchronize Glance, and determine if there are any errors during the upload process: ① If there is an error, enter the error state and proceed to step (10). ② If there are no errors, proceed to step (8); (8) After successful upload, verify whether the status and hash value of the uploaded image are consistent with the hash value of the converted raw format: ① If the test fails, the system will enter the error state and proceed to step (10). ② If the verification passes, proceed to step (9); (9) When the status is "updating" and needs to be updated, retrieve the tags and custom attributes defined in the current cr, update the data in the glance data, and determine whether the update was successful: ① If the update fails, the system will enter an error state and proceed to step (10). ② If the update is successful, the system will enter the active state and proceed to step (12). (10) When the status enters error each time, the failure reason is recorded in the status.reason property of cr. The cr in the error status will be retried after a set time and added to the cache queue for the next round of processing, and jump to step (1) to start again from the pending status; where the retry strategy is to retry once at a set time interval. (11) archskip is the final state of CR when the architecture defined in CR does not match the architecture of the government cloud environment; and according to the actual use case, to adapt to the situation of human configuration error, CR that supports the archskip state will perform an architecture matching check again after restarting the operator's pod; and for the current round, it is still regarded as the final state, and the archskip state will not be processed again after the architecture is checked for the first time in the current environment. (12) "active" is the final state of the CR that matches the architecture defined in the CR with the architecture of the government cloud environment. In the "active" state, it is determined whether the CR has been updated: ① If cr is no longer updated, it will not be processed again; ② If the tag or custom attribute of cr is updated, jump to step (1) and enter a new round of processing.

2. A system for automated management of virtual machine images based on Kubernetes, characterized in that, This system is used to implement the method for automated management of virtual machine images based on Kubernetes as described in claim 1; the system includes, The deployment module is used to deploy the virtual machine image (cr) to a specified environment and store the virtual machine image file in a specified location; The polling module is used for virtual machine image operators to poll the environment cr; The processing module is used to detect the current CR, and perform tasks such as uploading virtual machine images, verifying the correctness of virtual machine images, updating image data, and supporting multiple architectures. The cleanup module is used to select whether post-upload cleanup is required based on the configuration.

3. An electronic device, characterized in that, include: Memory and at least one processor; The memory stores computer-executed instructions; The at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the method for automated management of virtual machine images based on K8S as described in claim 1.

4. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processor, implement the method for automated management of virtual machine images based on K8S as described in claim 1.

Images