A method and system for migrating applications to edge light-weight Kubernetes

Abstract

The application is suitable for the technical field of power Internet of Things edge computing, and relates to a method and system for migrating applications to edge lightweight Kubernetes, comprising: packing an executable file of an application process into a binary file, configuring an application package file, and classifying the application; configuring a dockerfile file of a basic image, optimizing the image, and building the image in multiple stages; configuring a K3s configuration file and performing application service orchestration; integrating a Portworx tool to realize application migration; if it is cluster migration, the target cluster is configured to be prepared for pairing with the source cluster, an object storage endpoint is set on the target cluster as a location for grading data in the migration process, and then a token is created for the source cluster for use in the pairing process; and migrating data and configuration of the stateful application. The application supports single application migration and cluster migration, and also supports migration of the configuration and data of the stateful application together, is simple and flexible, occupies few resources, and has high migration efficiency.

Description

Technical Field

[0001] The present invention belongs to the field of edge computing technology for the power Internet of Things, and in particular relates to a method and system for migrating applications to edge lightweight Kubernetes. Background Art

[0002] Edge computing, a variant of cloud computing, has since become a proven runtime platform, helping solve challenges in telecommunications, media, transportation, logistics, agriculture, retail, and other sectors. Kubernetes (K8s, an open source framework for managing containerized applications across multiple hosts in a cloud platform) has also quickly become a key element of edge computing. Using Kubernetes, enterprises can run containers at the edge, maximizing resource utilization, simplifying testing, and enabling faster and more efficient migrations, as organizations can use and analyze more data in the field. Edge computing offers numerous advantages, including low latency, which improves the performance of field devices, enabling them to respond not only faster but also to more events. Low traffic volume reduces costs and increases overall throughput, enabling core data centers to support more field devices. Finally, for single-machine applications, it provides high availability in the event of network outages between the edge and data centers.

[0003] With the growing number of smart devices in the Internet of Things (IoT) and the arrival of 5G networks, edge computing has had a significant impact. Due to the increasing importance of edge computing for executing AI tasks, enterprises are increasingly interested in edge computing. As power grid companies accelerate their development of the Power Internet of Things (PoI), the number of connected devices and the amount of data are growing exponentially. Centralizing application deployment in the cloud can no longer meet fundamental requirements for real-time services, application intelligence, security, and privacy protection. Consequently, power grid companies are increasingly demanding the decentralization of applications to the edge. Given the limited resources at the edge, they need to consider how to ensure smooth application migration while minimizing resource usage and ensuring the simultaneous migration of application configurations and data. Furthermore, with the increasing number of applications deployed at the edge, deployment clustering is also increasing. If a cluster's resources are nearing full utilization, workloads need to be migrated to new locations with greater computing resources. However, migrating these services requires transferring applications and data, making cluster migration a pressing issue. Patent publication number CN110535896B provides a method for migrating edge computing applications, including: a first edge computing application on a first edge computing host receives a first message from an edge computing platform on the first edge computing host, the first message containing edge computing application information on a second edge computing host; the first edge computing application sends a second message to a second edge computing application on the second edge computing host based on the edge computing application information on the second edge computing host; wherein the second message carries user context information. Although this patent also involves edge computing and application migration, its purpose is to improve the security of user context information and does not address the pain points of the existing technology.

[0004] Therefore, how to provide a simple and flexible application migration method that consumes less resources and has high migration efficiency to ensure fast and smooth application migration is an urgent problem to be solved by people in this technical field. Summary of the Invention

[0005] In view of the shortcomings of the existing technology, the purpose of the present invention is to provide a method for migrating applications to edge lightweight Kubernetes, so as to solve the problems in the existing technology of complicated application migration process, excessive waste of resources, and low application migration efficiency; in addition, the present invention also provides a system for migrating applications to edge lightweight Kubernetes.

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

[0007] In a first aspect, the present invention provides a method for migrating an application to an edge lightweight Kubernetes, comprising the following steps:

[0008] S10. Package the executable file of the application process into a binary file, configure the application package file, and classify the application into stateful applications and stateless applications;

[0009] S20. Configure the Dockerfile file of the base image, select the most streamlined base image, reduce the number of image layers, clean up the intermediate products of image construction, and build the image in multiple stages;

[0010] S30. Configure the K3s configuration file and perform application service orchestration.

[0011] S40: Integrate Portworx tools to migrate stateful and stateless applications. For cluster migrations, configure the target cluster to prepare it for pairing with the source cluster. Set up an object storage endpoint on the target cluster as the location where data will be staged during the migration process. Then create a token for the source cluster to use during the pairing process.

[0012] S50: Migrate the data and configuration of stateful applications, persist pod data, and deploy the applications to K3s.

[0013] Furthermore, the specific steps in step S20 are as follows:

[0014] S201. Minimize the image: When using Docker to build an image, use && to connect multiple instructions;

[0015] S202. Speed ​​up application image building: Delete unnecessary files during the build process or create a separate directory. When building an image, collect all required files into a specified directory. When building, put the least changed parts at the front of the Dockerfile.

[0016] S203. Optimize Dockerfile build instructions: Avoid using the sudo command during image building, or use the gosu command instead; use absolute paths, and use WORKDIR when switching directories; avoid using the CMD instruction in conjunction with the ENTRYPOINT instruction. If both the CMD and ENTRYPOINT instructions are present in a Dockerfile, if the CMD instruction is an executable command, the CMD instruction will be run before the ENTRYPOINT instruction. If the CMD instruction is not an executable command, it will be appended as a command parameter to the ENTRYPOINT instruction. Use the COPY instruction for all file copies, and use the ADD instruction only when automatic decompression is required.

[0017] S204. Automatically build the application image package: obtain the application package file, create the Dockerfile file, optimize the build command and the image file, generate the Docker build command, and execute it in the Docker environment. Push the generated image to the executed Harbor image repository. If the build process is slow, asynchronous processing is used. After receiving the build command, the result processing is immediately returned, and the build progress is polled. In case of an error, the corresponding error information is returned.

[0018] Furthermore, the specific steps in step S30 are as follows:

[0019] S301, K3s configuration is responsible for service registration and discovery. All applications deployed on K3s call each other through K3s services.

[0020] S302. K3s creates environment variables when creating a container. When the application process runs in the container, it reads shared parameters from the environment variables to achieve shared parameters between the application process and K3s.

[0021] Furthermore, in step S40, the steps of integrating the Portworx tool are as follows:

[0022] Download the Portworx plug-in and do not enable it for now;

[0023] Create a directory that will be mounted on the installed Portworx plugin and run etcd;

[0024] Configure the Portworx plugin.

[0025] Modify the / etc / pwx / config.json file, delete the / etc / pwx / .private* files, and rebuild Portworx.

[0026] Use the pxctl cli tool;

[0027] The docker command creates and uses Portworx volumes.

[0028] Furthermore, in step S40, the cluster pairing steps are as follows:

[0029] Establish access to pxctl and check that pxctl works on the workstation with kubectl access.

[0030] Set up the target cluster so it's ready to pair with the source cluster. Set up an object storage endpoint on the target cluster as the location where data will be staged during the migration process. Create a token for the source cluster to use during the pairing process.

[0031] Create a clusterpair.yaml configuration file and apply it to the source Kubernetes cluster. The clusterpair.yaml configuration file will contain information on how to authenticate with the target cluster scheduler and Portworx storage.

[0032] Use storkctl to check the status of the cluster pairing that has been set up.

[0033] Furthermore, the specific steps of the migration in step S50 are as follows:

[0034] S501, initializing migration data and setting the migration flag to the initial state;

[0035] S502. Back up data and configuration before data migration;

[0036] S503. Call the migration CLI generated by storkctl to migrate the applications in batches. The migration batches are defined by the application configuration file.

[0037] S504: During cluster migration, if the source cluster has no write traffic or has timed out, the migration flag is set to pending migration, and all requests are forwarded to the destination cluster. If it is a read request, it is read from the new cluster first. If the new cluster does not have write traffic, it is read from the remote cluster.

[0038] S505: When the migration is completed, the migration flag is set to migration completed and data verification is performed.

[0039] Furthermore, in step S10, stateful applications and stateless applications are distinguished by the state field.

[0040] In a second aspect, the present invention further provides a system for migrating applications to edge lightweight Kubernetes, comprising:

[0041] The application package file configuration module is used to package the executable files of the application process into binary files, configure the application package files, and classify the applications;

[0042] Automatically build application image module, used to automatically build application image packages and optimize the images;

[0043] K3s service orchestration module, used to configure K3s configuration files and perform application service orchestration;

[0044] The migration module integrates the Portworx tool to migrate stateful and stateless applications, enabling batch and orderly migration.

[0045] The data storage module is used to save application data and configuration files and persist them as needed;

[0046] The deployment module is used to deploy applications to K3s to ensure their normal operation.

[0047] Furthermore, the persistent storage in the data storage module is to first create a persistent volume declaration list, specify the required minimum capacity requirements and access mode, and the user submits the persistent volume declaration list to the K3s API server. K3s will find a matching persistent volume and bind it to the persistent volume declaration.

[0048] Furthermore, the deployment steps of the deployment module are as follows:

[0049] After the application image is built, it is pushed to the image repository;

[0050] Call the Kubectl command locally to deploy the application;

[0051] After receiving the REST API request, the K3s server node creates a Pod and schedules it to the worker node;

[0052] After the worker node receives the deployment request, Kubelet notifies Docker to pull the image from the image repository;

[0053] After Docker pulls the image from the image repository, it deploys it directly.

[0054] Compared with the prior art, the method and system for migrating applications to edge lightweight Kubernetes provided by the present invention have at least the following beneficial effects:

[0055] In the existing technology, power grid companies have an increasing demand for decentralizing applications to the edge side, but the resources on the edge side are limited, making it difficult to ensure the efficiency of application migration. The present invention automatically builds an application mirror module, optimizes the mirror, reduces the size of the migration and deployment mirror to speed up the efficiency of migration and deployment, reduces resource overhead, and shortens the application migration and deployment time. At the same time, it classifies applications into stateful and stateless categories for migration, supports single application migration and cluster migration, and supports migrating the configuration and data of stateful applications together. This provides great convenience for K3s, which has already migrated a large number of applications deployed on public cloud platforms to the resource-limited edge side, and brings full portability to large amounts of data-based workloads on the cloud, allowing IT staff to deliver applications faster and more reliably during the IT development / testing and production lifecycles. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the scheme of the present invention, a brief introduction is given below to the figures required for use in the description of the embodiments. Obviously, the figures described below are some embodiments of the present invention. For ordinary technicians in this field, other figures can be obtained based on these figures without paying any creative work.

[0057] Figure 1 A flowchart of a method for migrating applications to lightweight edge Kubernetes provided by an embodiment of the present invention;

[0058] Figure 2 A schematic diagram of a flowchart for automatically building an image for a method of migrating applications to edge lightweight Kubernetes provided by an embodiment of the present invention;

[0059] Figure 3 A schematic diagram of the overall migration flow chart of a method for migrating applications to edge lightweight Kubernetes provided by an embodiment of the present invention;

[0060] Figure 4 A schematic diagram of the deployment process of a deployment module of a system for migrating applications to edge lightweight Kubernetes provided by an embodiment of the present invention;

[0061] Figure 5 A flowchart of creating a persistent volume for a data storage module of a system that migrates an application to an edge lightweight Kubernetes system is provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0062] To facilitate understanding of the present invention, the present invention will be described more fully below with reference to the accompanying drawings. Preferred embodiments of the present invention are shown in the accompanying drawings. However, the present invention may be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the present disclosure.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0064] The present invention provides a method for migrating applications to edge lightweight Kubernetes, which is applied to the migration process of applications in the field of power Internet of Things. The method for migrating applications to edge lightweight Kubernetes includes the following steps:

[0065] S10. Package the executable file of the application process into a binary file, configure the application package file, and classify the application into stateful applications and stateless applications;

[0066] S20. Configure the Dockerfile file of the base image, select the most streamlined base image, reduce the number of image layers, clean up the intermediate products of image construction, and build the image in multiple stages;

[0067] S30. Configure the K3s configuration file and perform application service orchestration.

[0068] S40: Integrate Portworx tools to migrate stateful and stateless applications. For cluster migrations, configure the target cluster to prepare it for pairing with the source cluster. Set up an object storage endpoint on the target cluster as the location where data will be staged during the migration process. Then create a token for the source cluster to use during the pairing process.

[0069] S50: Migrate the data and configuration of stateful applications, persist pod data, and deploy the applications to K3s.

[0070] The present invention supports single application migration and cluster migration, and also supports the migration of configuration and data of stateful applications together. It is simple and flexible, occupies few resources, and has high migration efficiency.

[0071] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0072] The present invention provides a method for migrating applications to edge lightweight Kubernetes, which is applied to the migration process of applications in the field of power Internet of Things, combined with Figures 1 to 3 In this embodiment, the method for migrating applications to edge lightweight Kubernetes includes the following steps:

[0073] S10. Package the executable file of the application process into a binary file, configure the application package file, and classify the applications into stateful applications and stateless applications, distinguishing them by the state field;

[0074] Specifically, the application package file structure is as follows:

[0075] app01

[0076] --app.conf

[0077] --bin

[0078] --app001

[0079] --lib

[0080] --libsg.so

[0081] --version.cfg

[0082] app.conf file

[0083] json structure, describing the following information of the APP:

[0084] {

[0085] "appname":"app01", / / app name

[0086] "exename":"bin / app001", / / Execution file name

[0087] "libpath":"lib", / / dependency library folder

[0088] "state": 0, / / 0 indicates a stateless application, 1 indicates a stateful application

[0089] }

[0090] bin folder, which stores APP program files;

[0091] lib folder, which stores the APP's dependent library files;

[0092] version.cfg, application version declaration file;

[0093] Example of file content: SV01.001.

[0094] S20. Configure the Dockerfile file of the base image, select the most streamlined base image, reduce the number of image layers, clean up the intermediate products of image construction, and build the image in multiple stages;

[0095] Furthermore, application image packages are automatically built and optimized. When deploying applications using Docker, some images can be at least 1GB in size. Over time, if image size changes and optimizations are not monitored, the image size will continue to grow. This increase in image size not only increases disk and network resource usage but also impacts application deployment efficiency, increasing deployment time. Therefore, it's necessary to reduce the size of deployed images to speed up deployment and reduce resource overhead. Image optimization can be achieved by optimizing the Dockerfile.

[0096] Specifically, step S20 includes the following steps:

[0097] S201. Minimize the image: Selecting a smaller base image can reduce the image size, such as alpine, busybox, etc. The image is a layered storage file. Improper use will cause the image to become increasingly bloated. When using Dockerfile to build an image, each instruction in the Dockerfile will generate a layer. You can use && to connect multiple commands. This way, by merging the instructions in the Dockerfile, the number of layers of the final generated image can be reduced. At the same time, during the image building process, delete files that are not needed for the image. After the Dockerfile instructions are executed, if yum installation components are involved, use the system rm command to delete unnecessary source files or use the yum clean command to clean up unnecessary image files.

[0098] S202. Speed ​​up the application image building process: delete unnecessary files during the building process or create a separate directory, for example, only the files needed for the image building process exist. When building an image, collect all the required files into the specified directory. If there are a large number of irrelevant files in the directory, it will not only lead to a slow build, but also increase the size of the image. When building, put the part that changes the least in front of the dockerfile. It is best to put commands such as WORKDIR, CMD, ENV, ADD, etc. at the bottom of the dockerfile. This way, you can make full use of the image cache so that you can maximize the use of the cache during the image building process. Because the docker build will turn on the cache by default, there are three key points for the cache to take effect: the build instructions remain unchanged, the checksum of the added files is consistent, and the parent layer of the image has not changed. As long as a build instruction meets these three conditions, the image build of this layer will not be executed again. It will directly use the results of the previous build. After the image cache of a certain layer expires, the cache of the image layer after it will also expire.

[0099] S203. Optimize Dockerfile build instructions: Avoid using the sudo command during image building. If you really need to use the sudo function, you can use the gosu command instead, because the terminal used by the sudo command is uncertain, which will also affect the reception of signals; try to use absolute paths, and try to use WORKDIR when switching directories instead of using RUNCD to a certain directory; try to avoid using the CMD and ENTRYPOINT instructions together. If there are both CMD and ENTRYPOINT instructions in the Dockerfile, when the CMD instruction is executable, it will be before the ENTRYPOINT instruction. Run; if CMD is not an executable command, it will be appended as a command parameter to ENTRYPOINT; use COPY instead of ADD whenever possible. ADD contains more complex functions and its behavior may not be very clear. The ADD instruction will invalidate the image build cache, which may make the image build slower. The most suitable occasion for using the ADD instruction is the occasion where automatic decompression is required. The semantics of the COPY instruction are very clear, that is, copying files. Therefore, when choosing between the COPY and ADD instructions, you can follow this principle: use the COPY instruction for all file copies and use the ADD instruction only when automatic decompression is required;

[0100] S204. Automatically build the application image package: obtain the application package file, create the Dockerfile file, optimize the build command and the image file, generate the docker build command, and execute it in the docker environment, and push the generated image to the harbor image repository for execution. If the build process is too slow, asynchronous processing is used. After receiving the build command, it immediately returns "Processing", and then polls the build progress. In case of an error, the corresponding error information is returned.

[0101] S30, K3s service orchestration, shared parameters and configuration: Configure K3s configuration files and perform application service orchestration;

[0102] Specifically, the specific steps of step S30 are as follows:

[0103] S301, K3s configuration is responsible for service registration and discovery. All applications deployed on K3s call each other through K3s services.

[0104] K3s configuration directory structure:

[0105] Program folder

[0106] --k3s

[0107] --k3s.sh

[0108] --program-deployment.yaml deployment configuration file

[0109] --program-service.yaml service configuration file

[0110] --program-volume.yaml persistent volume configuration file

[0111] Database folder

[0112] --database.sh

[0113] --database-deployment.yaml deployment database file

[0114] --database-service.yaml service database file

[0115] --database-volume.yaml persistent volume database file

[0116] K3s-config.yaml

[0117] K3s-security.yaml

[0118] The K3s configuration file directory structure has two subdirectories, "Program" and "Database", which are used to store the configuration files of the backend program and database respectively. There are two "yaml" files, "k3s-config.yaml" and "k3s-security.yaml", which allow parameters to be shared between services and are therefore placed in the outermost layer. There is also a "k3s.sh" file, which is the k3s command file used to create k3s objects.

[0119] S302. Shared parameters and deployment configuration files: Shared parameters can be implemented through environment variables. The "k3s-config.yaml" and "k3s-security.yaml" files store common parameters and confidential parameters, respectively. These parameters belong to the entire application and are shared by all services. Deploying services requires the K3s deployment yaml file, program-deployment.yaml. Each application is treated as a microservice, and each microservice is independently developed and deployed. This can effectively avoid the situation where changes to a single microservice cause the entire system to be redeployed. Each microservice is independently deployed, which speeds up deployment and facilitates scalability. Multiple microservices can also be deployed, and they have load balancing capabilities. Each microservice has independent basic components, such as databases and caches.

[0120] The format of the program-deployment.yaml file is as follows:

[0121]

[0122]

[0123] S303. Sharing parameters between the application process and K3s: When K3s creates a container, it creates environment variables. When the application process runs in the container, it can read the shared parameters from the environment variables, thus achieving the purpose of parameter sharing between the application process and K3s.

[0124] S40, integrates Portworx tools to migrate stateful and stateless applications. For cluster migration, you need to configure the target cluster to prepare it for pairing with the source cluster, set up an object storage endpoint on the target cluster for staging data during the migration process, and then create a token for the source cluster to use during the pairing process.

[0125] Specifically, a. Download the Portworx plugin but do not enable it for now;

[0126] b. Create directories that will be mounted on the installed Portworx plugin and run etcd;

[0127] c. Configure the Portworx plugin;

[0128] d. Modify the / etc / pwx / config.json file, delete the / etc / pwx / .private* files, and rebuild Portworx.

[0129] e. Use the pxctl CLI tool;

[0130] f.docker command to create and use Portworx volume.

[0131] Specifically, a. Establish access to pxctl and check that pxctl works on the workstation with kubectl access.

[0132] b. Set up the target cluster to prepare it for pairing with the source cluster. Set up an object storage endpoint on the target cluster for the location where data will be staged during the migration process, and create a token for the source cluster to use during the pairing process.

[0133] c. Create a clusterpair.yaml configuration file to apply to the source Kubernetes cluster. The clusterpair.yaml file will contain information on how to authenticate with the target cluster scheduler and Portworx storage.

[0134] d. Use storkctl to check the status of the cluster pairing that has been set up.

[0135] S50: Migrate the data and configuration of stateful applications, persist pod data, and deploy the applications to K3s.

[0136] Specifically, the steps of migration in step S50 are as follows:

[0137] a. Initialize the migration data and set the migration flag to the initial state;

[0138] b. Data and configurations must be backed up before data migration to ensure timely data recovery in the event of an abnormality.

[0139] c. For stateless applications, directly call the deployment module to go through the deployment process. For stateful applications, go through the migration process.

[0140] d. Call the migration CLI generated by storkctl to migrate the migrated applications in batches. The migration batches of applications are divided into three batches. The migration batches are defined by the application configuration file and are placed in the last batch by default. The principles are as follows: For applications with high real-time requirements, those with the shortest possible business interruption time are placed in the first batch. For applications with high real-time requirements but long migration time and high traffic consumption, they are placed in the second batch. For applications with high real-time requirements but long migration time and high traffic consumption, they are placed in the second batch. For stateless applications, they are placed in the third batch. After the first batch is executed, the data in the process is not affected, so the time interval between batch executions should be minimized as much as possible.

[0141] e. For cluster migration, when it is found that the source cluster has no write traffic, or the timeout period (half an hour) is reached, the migration flag will be set to the pending migration state, and all requests will be forwarded to the destination cluster. If it is a read request, it will be read from the new cluster first. If the new cluster does not exist, it will be read from the remote end (source centralization). Similarly, write operations can be roughly divided into object deletion, object metadata update, and object overwrite. Since object deletion is a logical deletion, the processing logic is the same as that of object metadata update; the update of object metadata also first has a local read and remote read process: if it exists locally, it means that it has been migrated, and it will be updated directly locally; if it does not exist locally, it needs to be read from the remote end first, and then the metadata will be updated locally;

[0142] f. When the migration is complete (based on the migration progress), the migration flag is set to complete and data verification is performed.

[0143] In a second aspect, an embodiment of the present invention further provides a system for migrating applications to edge lightweight Kubernetes, including:

[0144] The application package file configuration module is used to package the executable files of the application process into binary files, configure the application package files, and classify the applications;

[0145] Automatically build application image module, used to automatically build application image packages and optimize the images;

[0146] K3s service orchestration module, used to configure K3s configuration files and perform application service orchestration;

[0147] The migration module integrates the Portworx tool to migrate stateful and stateless applications, enabling batch and orderly migration.

[0148] The data storage module is used to store application data and configuration files and persist them on demand. K3s containers are stateless. Once a container is destroyed, the data stored in it is lost. A persistence layer is needed to store data that still exists after the container is destroyed, so a persistent volume needs to be created.

[0149] The deployment module is used to deploy non-state applications and deploy applications to K3s without migration to ensure their normal operation.

[0150] Furthermore, in this embodiment, if Figure 4 As shown, the deployment steps of the deployment module are as follows:

[0151] a. After the application image is built, push it to the image repository;

[0152] b. Locally call the Kubectl command to deploy the application;

[0153] c. After receiving the REST API request, the K3s server node creates a Pod and schedules it to the worker node;

[0154] d. After the worker node receives the deployment request, Kubelet notifies Docker to pull the image from the image repository;

[0155] f.Docker pulls the image from the image repository and deploys it directly.

[0156] Furthermore, in this embodiment, the data storage module adopts a static persistent volume for the persistent volume, and its configuration file structure is as follows:

[0157]

[0158]

[0159] When a cluster user needs to use persistent storage in its Pod, it first creates a Persistent Volume Claim (PVC) list, specifies the minimum capacity requirements and access mode required, and submits the Persistent Volume Claim list to the K3s API server. K3s will find a matching persistent volume and bind it to the persistent volume claim.

[0160] Furthermore, in this embodiment, if Figure 5 As shown, the specific steps to create a persistent volume are:

[0161] a. The cluster administrator creates an NFS interface or other type of network storage;

[0162] b. The administrator creates a persistent volume by passing a PV declaration to the Kubernetes API;

[0163] c. The user creates a persistent volume claim (PVC);

[0164] d. Kubernetes finds a PV with sufficient capacity, puts it into access mode, and binds the PVC to it.

[0165] e. The user creates a Pod and applies the PVC through volume configuration.

[0166] The method and system for migrating applications to the edge lightweight Kubernetes described in the above embodiment are compared with the existing technology. In the existing technology, power grid companies have more and more demands for delegating applications to the edge side, while the resources on the edge side are limited, making it difficult to ensure the efficiency of application migration. The present invention automatically builds an application mirror module, optimizes the mirror, reduces the volume of the migration and deployment mirror to speed up the efficiency of migration and deployment, reduces resource overhead, shortens the application migration and deployment time, and at the same time migrates applications according to stateful and stateless classifications, supports single application migration and cluster migration, and supports migrating the configuration and data of stateful applications together. It provides great convenience for K3s, which has already migrated a large number of applications deployed on public cloud platforms to the edge end with limited resources, and brings sufficient portability to large amounts of data-type workloads on the cloud, allowing IT staff to deliver applications faster and more reliably during the IT development / testing and production life cycle.

[0167] Obviously, the embodiments described above are only preferred embodiments of the present invention, rather than all embodiments. The preferred embodiments of the present invention are given in the accompanying drawings, but they do not limit the patent scope of the present invention. The present invention can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present invention more thorough and comprehensive. Although the present invention has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present invention specification and drawings, directly or indirectly used in other related technical fields, is also within the scope of patent protection of the present invention.

Claims

1. A method for migrating applications to edge lightweight Kubernetes, characterized in that: The following steps are involved: S10. Package the executable file of the application process into a binary file, configure the application package file, and classify the application into stateful applications and stateless applications; S20. Configure the Dockerfile file of the base image, select the most streamlined base image, reduce the number of image layers, clean up the intermediate products of image construction, and build the image in multiple stages; The specific steps in step S20 are as follows: S201. Minimize the image: When using Docker to build an image, use && to connect multiple instructions; S202. Speed ​​up application image building: Delete unnecessary files during the build process or create a separate directory. When building an image, collect all required files into a specified directory. When building, put the least changed parts at the front of the Dockerfile. S203. Optimize Dockerfile build instructions: Avoid using the sudo command during image building, or use the gosu command instead; use absolute paths, and use WORKDIR when switching directories; avoid using the CMD instruction in conjunction with the ENTRYPOINT instruction. If both the CMD and ENTRYPOINT instructions are present in a Dockerfile, if the CMD instruction is an executable command, then the CMD instruction will be run before the ENTRYPOINT instruction. If the CMD instruction is not an executable command, then it will be appended as a command parameter to the ENTRYPOINT instruction. Use the COPY instruction for all file copies, and use the ADD instruction only when automatic decompression is required. S204, automatically build the application image package: obtain the application package file, create a Dockerfile file, optimize the build command and the image file, generate the Docker build command, and execute it in the Docker environment, and push the generated image to the executed Harbor image repository. If the build process is slow, asynchronous processing is used. After receiving the build command, the result processing is immediately returned, and the build progress is polled. If an error occurs, the corresponding error information is returned; S30. Configure the K3s configuration file and perform application service orchestration. S40: Integrate Portworx tools to migrate stateful and stateless applications. For cluster migrations, configure the target cluster to prepare it for pairing with the source cluster. Set up an object storage endpoint on the target cluster as the location where data will be staged during the migration process. Then create a token for the source cluster to use during the pairing process. S50: Migrate the data and configuration of stateful applications, persist pod data, and deploy the applications to K3s.

2. A method for migrating applications to edge lightweight Kubernetes according to claim 1, characterized in that: The specific steps in step S30 are as follows: S301, K3s configuration is responsible for service registration and discovery. All applications deployed on K3s call each other through K3s services. S302. K3s creates environment variables when creating a container. When the application process runs in the container, it reads shared parameters from the environment variables to achieve shared parameters between the application process and K3s.

3. A method for migrating applications to edge lightweight Kubernetes according to claim 1, characterized in that: In step S40, the steps for integrating the Portworx tool are as follows: Download the Portworx plug-in and do not enable it for now; Create a directory that will be mounted on the installed Portworx plugin and run etcd; Configure the Portworx plugin. Modify the / etc / pwx / config.json file, delete the / etc / pwx / .private* files, and rebuild Portworx. Use the pxctl cli tool; The docker command creates and uses Portworx volumes.

4. A method for migrating applications to edge lightweight Kubernetes according to claim 1, characterized in that: In step S40, the cluster pairing steps are as follows: Establish access to pxctl and check that pxctl works on the workstation with kubectl access. Set up the target cluster so it's ready to pair with the source cluster. Set up an object storage endpoint on the target cluster as the location where data will be staged during the migration process. Create a token for the source cluster to use during the pairing process. Create a clusterpair.yaml configuration file and apply it to the source Kubernetes cluster. The clusterpair.yaml configuration file will contain information on how to authenticate with the target cluster scheduler and Portworx storage. Use storkctl to check the status of the cluster pairing that has been set up.

5. A method for migrating applications to edge lightweight Kubernetes according to claim 1, characterized in that: The specific steps of the migration in step S50 are as follows: S501, initializing migration data and setting the migration flag to the initial state; S502. Back up data and configuration before data migration; S503. Call the migration CLI generated by storkctl to migrate the applications in batches. The migration batches are defined by the application configuration file. S504: During cluster migration, if the source cluster has no write traffic or has timed out, the migration flag is set to pending migration, and all requests are forwarded to the destination cluster. If it is a read request, it is read from the new cluster first. If the new cluster does not have write traffic, it is read from the remote cluster. S505: When the migration is completed, the migration flag is set to migration completed and data verification is performed.

6. A method for migrating applications to edge lightweight Kubernetes according to claim 1, characterized in that: In step S10, stateful applications and stateless applications are distinguished by the state field.

7. A system using the method according to any one of claims 1 to 6, characterized in that: include: The application package file configuration module is used to package the executable files of the application process into binary files, configure the application package files, and classify the applications; Automatically build application image module, used to automatically build application image packages and optimize the images; K3s service orchestration module, used to configure K3s configuration files and perform application service orchestration; The migration module integrates the Portworx tool to migrate stateful and stateless applications, enabling batch and orderly migration. The data storage module is used to save application data and configuration files and persist them as needed; The deployment module is used to deploy applications to K3s to ensure their normal operation.

8. The system according to claim 7, characterized in that Persistent storage in the data storage module is to first create a persistent volume declaration list, specify the required minimum capacity requirements and access mode, and the user submits the persistent volume declaration list to the K3s API server. K3s will find a matching persistent volume and bind it to the persistent volume declaration.

9. The system according to claim 7, wherein: The deployment steps of the deployment module are as follows: After the application image is built, it is pushed to the image repository; Call the Kubectl command locally to deploy the application; After receiving the REST API request, the K3s server node creates a Pod and schedules it to the worker node; After the worker node receives the deployment request, Kubelet notifies Docker to pull the image from the image repository; After Docker pulls the image from the image repository, it deploys it directly.

Images