A non-container application orchestration method and device based on Kubernetes CRI plug-in

Abstract

The present invention relates to a non-container application orchestration method and device based on Kubernetes CRI plug-in, and the non-container application orchestration method includes: S1, definition of description information of non-container application; S2, creation and startup of container; S3, configuration of container; S4, patch management of container. The present invention can be hosted in Kubernetes cluster without modifying the original non-container application, and can make full use of the automatic deployment and expansion capabilities, health check and self-repair capabilities, monitoring and log collection capabilities, security and isolation and other features provided by Kubernetes, allowing developers to unify the management of non-containerized applications and containerized applications, which helps to simplify operation and maintenance work and improve management efficiency. After the non-container application is hosted, Kubernetes can be used to dynamically schedule and allocate resources to optimize resource utilization efficiency.

Description

Technical Field

[0001] The present invention relates to the field of orchestration of non-container applications based on Kubernetes CRI, and in particular to a method and device for orchestrating non-container applications based on Kubernetes CRI plug-ins. Background Art

[0002] Currently, there are several common management methods for non-container applications on the market:

[0003] 1. Manually install, configure, and deploy non-containerized applications on physical servers or virtual machines;

[0004] 2. Write automated scripts to deploy non-containerized applications on multiple servers or virtual machines.

[0005] 3. Deploy, configure, and update non-containerized applications through the open source automated configuration management tool Ansible;

[0006] 4. Through the configuration management tool Puppet, the configuration and status of non-containerized applications can be managed;

[0007] 5. Deploy non-containerized applications in a hybrid cloud or multi-cloud environment to take advantage of the resources of different cloud service providers;

[0008] 6. Choose to use a proprietary platform provided by a third party to manage non-containerized applications, such as Walrus, ZohoCreator, Ali Yida, and Puppet;

[0009] The above-mentioned non-container application management methods all have certain problems during use, as follows:

[0010] For method 1, when managing non-container applications manually, it requires a high level of technical skills and a lot of time investment, and it is easy to have configuration errors and version inconsistencies.

[0011] Regarding method 2, although this method improves deployment efficiency when deploying automated scripts, the script writing and maintenance costs are high and it is not flexible enough for complex deployment environments.

[0012] Regarding method 3, Ansible, as an automated operation and maintenance tool, has many advantages when maintaining non-containerized applications, but it also has some technical defects, including the following:

[0013] 1) When dealing with some complex non-containerized application management tasks, Ansible may need to write a lot of Playbook code or even write custom plug-ins to solve the problem;

[0014] 2) Although Ansible has the ability to execute tasks in parallel, when dealing with large-scale environments with thousands or even tens of thousands of servers, performance bottlenecks may occur, resulting in reduced execution efficiency;

[0015] 3) Ansible communicates based on the SSH protocol, so sensitive information of the server, such as passwords and private keys, may be exposed during configuration management and task execution;

[0016] Regarding method 4, Puppet is a popular automated configuration management tool. Although it has powerful functions and flexibility when managing non-containerized applications, it also has some technical defects, including the following:

[0017] 1) Puppet consumes certain system resources during operation. Especially in large-scale environments, when multiple Puppet Agents send requests to the Puppet Master at the same time, it may bring greater load pressure to the Master.

[0018] 2) Puppet's configuration and management are relatively complex, requiring administrators to have certain programming and automation tool usage experience;

[0019] 3) Puppet's Manifests (configuration files) are written in a custom declarative language. For administrators who are not familiar with this language, it takes a certain amount of time and effort to learn it.

[0020] 4) Puppet's communication and configuration process needs to ensure security, especially when it comes to sensitive information (such as passwords, keys, etc.). However, Puppet's security mechanism has certain loopholes or deficiencies, requiring administrators to perform additional security reinforcement and permission management.

[0021] Regarding method 5, hybrid cloud or multi-cloud deployment mode, although it improves the flexibility and scalability of deployment, it also needs to consider the compatibility and management complexity between different cloud service providers.

[0022] For method 6, using a proprietary platform provided by a third party can easily expose sensitive server information, such as passwords and private keys;

[0023] In summary, the above six common management methods of non-container applications all have certain technical defects. Based on this, the inventors have developed a non-container application orchestration method and device based on the Kubernetes CRI plug-in. Summary of the invention

[0024] In order to solve the above technical problems, the present invention provides a non-container application orchestration method and device based on Kubernetes CRI plug-in, which can be hosted in Kubernetes cluster without modifying the original non-container application, and can make full use of the automated deployment and expansion capabilities, health check and self-repair capabilities, monitoring and log collection capabilities, security and isolation and other features provided by Kubernetes, allowing developers to unify the management of non-containerized applications and containerized applications, which helps to simplify operation and maintenance work and improve management efficiency.

[0025] In a first aspect, the present invention provides a non-container application orchestration method based on Kubernetes CRI plug-in, which adopts the following technical solution:

[0026] A non-container application orchestration method based on Kubernetes CRI plug-in includes the following steps:

[0027] S1. Definition of description information of non-container applications;

[0028] S11, application.yaml: defines the basic information of non-container applications;

[0029] S12, ApplicationVersion.yaml: defines the current version of the non-container application, records the CPU architecture of the current version and the media information to which each version is applied;

[0030] S2, container creation and startup;

[0031] S21. The server hosts the media of each version defined in ApplicationVersion.yaml in the media warehouse. The media includes image media, common media, and script files. The server provides a media list for non-container images. The media list includes common media and script files. The download path of the media list meets the image naming rules and is configured as the Image name of the Pod. The name of the media list contains the fixed prefix "ncri-manifest".

[0032] S22, the media manifest file NcriManifest.yaml of the non-container image describes the media list included in the non-container image;

[0033] S23: The Pod is scheduled to the Kubernetes node, and Kubelet notifies CRI-O to create a container.

[0034] After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format.

[0035] S24: NCRI downloads the image media. When it detects that it is a non-container image, it first downloads the media list, and then downloads the non-container media and scripts in the list;

[0036] If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent;

[0037] S25: Kubelet creates a container on the node based on the pulled image or non-container media;

[0038] After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it;

[0039] S3, container configuration;

[0040] S31. When kubelet calls the CRI interface to create a container, NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volumes in the root directory of the non-container application instance, and sets the root directory of the container to the container's environment variable APPLICATION_INSTANCE_HOME.

[0041] S32. Create a configuration file for the container, recording the required environment variables and cgroup;

[0042] S33. Set a user for the container and grant permissions;

[0043] S34. Execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

[0044] Preferably, the method further comprises the following steps:

[0045] S4. Container patch management;

[0046] S41. Inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod;

[0047] S42. After node-agent detects the patch information that needs to be installed in the annotation under the Pod, it checks conflicts, downloads, and installs the patches in sequence, and determines the restart timing after installation according to the configuration;

[0048] S43. After node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, it controls the uninstallation of the patch in reverse order, and determines whether it is necessary to restart the non-container application process according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. If restart is not required, it is skipped.

[0049] Preferably, the S1 further comprises the following steps:

[0050] S13, ApplicationPatch.yaml: defines the patch information with a specific number under a specific version of the application medium. The patch information includes: application version series, patch version number, module, upgrade path, conflicting patch list, upgrade prerequisite, whether uninstallation is supported, uninstallation prerequisite, shelf status, and medium list;

[0051] S14. Maintain image files, non-container media, non-container patch media, and non-container script files used by non-container applications.

[0052] Preferably, the basic information in S11 includes application name, category, service discovery image, and version sequence.

[0053] Preferably, the media information in S12 includes container images, non-container application media, dependency libraries, patch media, and media script files;

[0054] The media script files include installation scripts, start and stop scripts, upgrade scripts, backup scripts, and service discovery scripts.

[0055] Preferably, the environment variables in S32 include: container root directory, container workingDir, media directory of the container corresponding to the image, script directory of the container corresponding to the image, and port information assigned to the current pod.

[0056] Preferably, the restart timing after installation in S42 includes immediate restart after installation, delayed restart after installation, and manual restart after installation.

[0057] Preferably, the restart timing after uninstallation in S43 includes immediate restart after uninstallation, delayed restart after uninstallation, and manual restart after uninstallation.

[0058] In a second aspect, the present invention provides a non-container application orchestration device based on Kubernetes CRI plug-in, which adopts the following technical solution:

[0059] A non-container application orchestration device based on Kubernetes CRI plug-in, including the following modules:

[0060] Definition module, used to define the description information of non-container applications, including:

[0061] Basic information definition unit, application.yaml: defines the basic information of non-container applications, including application, category, service discovery image, and version sequence;

[0062] Current version definition unit, ApplicationVersion.yaml: defines the current version of the non-container application, records the CPU architecture of the current version and the media information to which each version is applied;

[0063] The container creation and startup module is used to create and start containers, including:

[0064] The download path unit of the media manifest is used to enable the server to host the media of each version defined in ApplicationVersion.yaml in the media warehouse. The media includes image media, common media, and script files. The server provides a media manifest for non-container images. The media manifest includes common media and script files. The download path of the media manifest meets the image naming rules and is configured as the Image name of the Pod. The name of the media manifest contains the fixed prefix "ncri-manifest".

[0065] Describes the media list unit, which is used for media manifest files of non-container images.

[0066] NcriManifest.yaml describes the list of media included in the non-container image;

[0067] Kubelet notifies CRI-O to create a container unit. After the Pod is scheduled to the Kubernetes node, Kubelet notifies CRI-O to create a container.

[0068] After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format.

[0069] The media list download unit, NCRI downloads the image media. When a non-container image is detected, the media list is downloaded first, and then the non-container media and scripts in the list are downloaded;

[0070] If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent;

[0071] The container creation and startup unit is used to create a container based on the pulled image or non-container media on the node by Kubelet;

[0072] After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it;

[0073] Container configuration module, used for container configuration, including:

[0074] The root directory unit is used when kubelet calls the CRI interface to create a container. NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volume in the root directory of the non-container application instance, and sets the container's root directory to the container's environment variable APPLICATION_INSTANCE_HOME.

[0075] The configuration file unit is used to form the configuration file of the container and record the required environment variables and cgroup;

[0076] User unit, used to set users and grant permissions for containers;

[0077] The association unit is used to execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

[0078] Preferably, the following modules are also included:

[0079] Container patch management module, used for container patch management, including:

[0080] The patch information injection unit is used to inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod;

[0081] The patch installation unit is used to check conflicts, download and install patches in order after the node-agent detects the patch information that needs to be installed in the annotation under the Pod, and determines the restart timing after installation according to the configuration;

[0082] The patch uninstallation unit is used to control the uninstallation of patches in reverse order after the node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, and decides whether to restart the non-container application process according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. If restart is not required, it is skipped.

[0083] In summary, the present invention includes the following beneficial technical effects:

[0084] 1. The present invention can be hosted in a Kubernetes cluster without modifying the original non-container application. It can make full use of the automated deployment and expansion capabilities, health check and self-repair capabilities, monitoring and log collection capabilities, security and isolation and other features provided by Kubernetes, allowing developers to manage non-containerized applications together with containerized applications, which helps to simplify operation and maintenance work and improve management efficiency.

[0085] 2. After the non-container application in the present invention is hosted in the Kubernetes cluster, Kubernetes can be used to dynamically schedule and allocate resource capabilities, thereby optimizing resource utilization efficiency and ensuring that the non-container application obtains sufficient resources to run when needed.

[0086] 3. The present invention can realize elastic expansion of non-containerized applications through functions such as Horizontal Pod Autoscaler of Kubernetes, and automatically adjust the number of non-container application instances according to load conditions, thereby improving the scalability and stability of the system.

[0087] 4. Kubernetes in the present invention can implement various security measures, such as network policies, role-based access control (RBAC), etc., to protect non-containerized applications from external attacks and internal threats.

[0088] 5. Kubernetes in the present invention can ensure that non-containerized applications can quickly resume operation when a failure occurs by providing functions such as self-repair and automatic restart, thereby improving the reliability of the system.

[0089] 6. The present invention includes NCRI through a lightweight node-agent service, has the performance of kubelet and CRI-Runtime, maps local files into files in the image, so that Docker images, OCI images and non-container images can be supported in the same Pod at the same time, and can cope with the deployment of non-container applications and the management of existing non-container applications.

[0090] 7. The present invention supports the creation of containers through non-container images through NCRI, and implements the isolation of network, storage, and resources between non-container application processes based on the CGroup mechanism.

[0091] 8. The present invention provides a consistent operation and maintenance window for non-container applications, and can perform patch upgrades and uninstall operations on non-container applications in batches. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] Figure 1 It is an architecture diagram of a management system used by the orchestration method in an embodiment of the present invention.

[0093] Figure 2 It is a flow chart of the arrangement method in an embodiment of the present invention.

[0094] Figure 3 is a flow chart of step S1 of the arrangement method in an embodiment of the present invention.

[0095] Figure 4 4 is a flow chart of step S2 of the arrangement method in the embodiment of the present invention.

[0096] Figure 5 4 is a flow chart of step S3 of the arrangement method in the embodiment of the present invention.

[0097] Figure 6 4 is a flow chart of step S4 of the arrangement method in the embodiment of the present invention. DETAILED DESCRIPTION

[0098] The present invention is further described in detail below in conjunction with the accompanying drawings.

[0099] An embodiment of the present invention discloses a non-container application orchestration method based on a Kubernetes CRI plug-in.

[0100] The following is an explanation of the nouns used in this arrangement method:

[0101] 1) NCRI: Native Container Runtime Interface, i.e. non-container runtime, is a plug-in implemented based on CRI and is used to manage non-container images and containers created based on non-container images;

[0102] 2) Non-container image: There is no real image file, but an image image mapped based on the media list; the scripts and media defined under the image are stored in the specified directory of the host, and a container can be created based on the image;

[0103] 3) Media list: can be managed by NCRI and is used to describe the common media and scripts contained in non-container images. The download path needs to meet the naming rules of the image.

[0104] In addition, the non-container application orchestration method is applied to Figure 1 The application management platform is a part of the management system shown in the figure. It is the entry point for users to create applications. Then, the kube-apiserver creates application description resources in the cluster. After being processed by the kube-controller or operator, the Pod associated with the application is scheduled to a specific node of Kubernetes. The node-agent manages the Pod on the node, downloads images and common media from the media warehouse, and creates containers.

[0105] Specifically, refer to Figure 2 The non-container application orchestration method includes the following steps:

[0106] S1. Definition of description information of non-container applications;

[0107] Reference Figure 3 , S1 includes the following steps:

[0108] S11, application.yaml: defines the basic information of non-container applications, including application name, category, service discovery image, version sequence, etc.

[0109] S12, ApplicationVersion.yaml: defines the current version of the non-container application, records the CPU architecture of the current version and the media information applied to each version; the media information includes container images, non-container application media, dependency libraries, patch media, media script files, etc. The media script files include installation scripts, start and stop scripts, upgrade scripts, backup scripts (which can be used as recovery scripts), service discovery scripts, etc.;

[0110] S13, ApplicationPatch.yaml: defines the patch information with a specific number under a specific version of the application medium. The patch information includes: application version series, patch version number, module, upgrade path, conflicting patch list, upgrade prerequisites, whether uninstallation is supported, uninstallation prerequisites, shelf status, medium list, etc.

[0111] S14. In addition to the description information of the non-container application, the media server also maintains the image files, non-container media, non-container patch media, non-container script files and other media used by the non-container application.

[0112] S2, container creation and startup;

[0113] Reference Figure 4 , S2 includes the following steps:

[0114] S21. The server hosts the media of each version defined in ApplicationVersion.yaml in the media warehouse. The media includes image media, common media, and script files. The server provides a media list for non-container images. The media list includes common media and script files. The download path of the media list is the image name that meets the image naming rules and is configured as the Pod. The name of the media list contains the fixed prefix "ncri-manifest". For example

[0115] A fragment of NcriManifest of registry-server:443 / ncri-manifest / public / apache-tomcat:8.5.82 is as follows:

[0116] repositories:

[0117]

[0118]

[0119] sha256sum:

[0120] 4e1397500be9e6af7d7de513c10e3cc3a9097c06ec5382fa0b2282fdd8c34185;

[0121] S22, the media manifest file NcriManifest.yaml of the non-container image describes the media list included in the non-container image. For details, please refer to the example code provided in step S21;

[0122] S23: The Pod is scheduled to the Kubernetes node, and Kubelet notifies CRI-O to create a container.

[0123] After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format.

[0124] S24: NCRI downloads the image media. When it detects that it is a non-container image, it first downloads the media list, and then downloads the non-container media and scripts in the list;

[0125] If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent;

[0126] S25: Kubelet creates a container on the node based on the pulled image or non-container media;

[0127] After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it;

[0128] S3, container configuration;

[0129] Reference Figure 5 , S3 includes the following steps:

[0130] S31. When kubelet calls the CRI interface to create a container, NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volumes in the root directory of the non-container application instance, and sets the root directory of the container to the container's environment variable APPLICATION_INSTANCE_HOME.

[0131] S32. Form a configuration file for the container, record the required environment variables and cgroup, where the environment variables include: container root directory, container workingDir, media directory of the container corresponding image, script directory of the container corresponding image, and port information assigned to the current pod;

[0132] S33. Set a user for the container and grant permissions;

[0133] S34. Execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

[0134] S4. Container patch management;

[0135] Reference Figure 6 , S4 comprises the following steps:

[0136] S41. Inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod;

[0137] S42. After node-agent detects the patch information that needs to be installed in the annotation under the Pod, it checks conflicts, downloads, and installs the patch in sequence, and determines the restart timing after installation according to the configuration. The restart timing after installation includes immediate restart after installation, delayed restart after installation, and manual restart after installation. ;

[0138] S43. After node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, it controls the uninstallation of the patch in reverse order and determines whether the non-container application process needs to be restarted according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. The restart timing after uninstallation includes immediate restart after uninstallation, delayed restart after uninstallation, and manual restart after uninstallation. If restart is not required, skip it.

[0139] The above embodiment achieves the following effects by uniformly managing the lifecycles of container applications and non-container applications through the application management platform:

[0140] 1. Through the plug-in NCRI that can implement CRI, non-container media is mapped into images, and then operations such as creation, deletion, and viewing of non-container images and containers are implemented, so as to bring non-container applications into the management scope of Kubernetes, so that these applications and containerized applications share the same management platform, thereby simplifying operation and maintenance work;

[0141] 2. Through the plug-in NCRI that can implement CRI, Kubernetes' Deployment, ReplicaSet, StatefulSet and other resource objects can be used to manage containers created by non-container images. Kubernetes' rolling updates, elastic scaling and other functions can be applied to non-container applications, and you can enjoy the convenience brought by these automated functions;

[0142] 3. Through the NCRI plug-in that can implement CRI, the monitoring and log collection functions provided by Kubernetes are applied to non-container applications to monitor the running status and performance indicators of applications in real time. Through these monitoring data, operation and maintenance personnel can promptly discover and handle potential problems to ensure the stable operation of applications;

[0143] 4. Through the NCRI plug-in that can implement CRI, Kubernetes' cross-cloud deployment capabilities are applied to non-container applications, realizing unified scheduling and deployment of non-container applications in a multi-cloud environment;

[0144] 5. Through the NCRI plug-in that can implement CRI, the architectural design and scalability of Kubernetes are applied to non-container applications, allowing non-container applications to easily cope with application scenarios of different scales and complexities.

[0145] 6. Although the number of existing non-container applications is huge, it is possible to smoothly incorporate the existing non-container applications into the Kubernetes cluster without modifying the existing non-container applications.

[0146] In addition, an embodiment of the present application also discloses a non-container application orchestration device based on a Kubernetes CRI plug-in, which is used to implement a non-container application orchestration method based on a Kubernetes CRI plug-in disclosed in the above embodiment.

[0147] Specifically, the non-container application orchestration device includes the following modules:

[0148] Definition module, used to define the description information of non-container applications, including:

[0149] Basic information definition unit, application.yaml: used to define the basic information of non-container applications, including application name, category, service discovery image, version sequence, etc.

[0150] Current version definition unit, ApplicationVersion.yaml: used to define the current version of non-container applications, record the CPU architecture of the current version and the media information applied to each version; media information includes container images, non-container application media, dependency libraries, patch media, media script files, etc. Media script files include installation scripts, start and stop scripts, upgrade scripts, backup scripts (can be used as recovery scripts), service discovery scripts, etc.;

[0151] Patch information definition unit, ApplicationPatch.yaml: used to define patch information with a specific number under a specific version of an application medium. Patch information includes: application version series, patch version number, module, upgrade path, conflicting patch list, upgrade prerequisites, whether uninstallation is supported, uninstallation prerequisites, shelf status, media list, etc.

[0152] The maintenance unit, in addition to the description information of the non-container application, also maintains the image files, non-container media, non-container patch media, non-container script files and other media used by the non-container application on the media server.

[0153] The container creation and startup module is used to create and start containers, including:

[0154] The download path unit of the media manifest is used to enable the server to host the media of each version defined in ApplicationVersion.yaml in the media warehouse. The media includes image media, common media, and script files. The server provides a media manifest for non-container images. The media manifest includes common media and script files. The download path of the media manifest meets the image naming rules and is configured as the Image name of the Pod. The name of the media manifest contains the fixed prefix "ncri-manifest".

[0155] Describes the media list unit, which is used for media manifest files of non-container images.

[0156] NcriManifest.yaml describes the media list included in the non-container image. For details, please refer to the example code provided in step S21;

[0157] Kubelet notifies CRI-O to create a container unit. After the Pod is scheduled to the Kubernetes node, Kubelet notifies CRI-O to create a container.

[0158] After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format.

[0159] The media list download unit, NCRI downloads the image media. When a non-container image is detected, the media list is downloaded first, and then the non-container media and scripts in the list are downloaded;

[0160] If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent;

[0161] The container creation and startup unit is used to create a container based on the pulled image or non-container media on the node by Kubelet;

[0162] After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it;

[0163] Container configuration module, used for container configuration, including:

[0164] The root directory unit is used when kubelet calls the CRI interface to create a container. NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volume in the root directory of the non-container application instance, and sets the container's root directory to the container's environment variable APPLICATION_INSTANCE_HOME.

[0165] Configuration file unit, used to form the configuration file of the container, record the required environment variables and cgroup, where the environment variables include: container root directory, container workingDir, media directory of the container corresponding image, script directory of the container corresponding image, and port information assigned to the current pod. ;

[0166] User unit, used to set users and grant permissions for containers;

[0167] The association unit is used to execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

[0168] Container patch management module, used for container patch management, including:

[0169] The patch information injection unit is used to inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod;

[0170] The patch installation unit is used for node-agent to detect the patch information that needs to be installed in the annotation under the Pod, and then check conflicts, download, and install patches in sequence, and determine the restart timing after installation according to the configuration. The restart timing after installation includes immediate restart after installation, delayed restart after installation, and manual restart after installation.

[0171] The patch uninstallation unit is used to control the uninstallation of patches in reverse order after the node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, and decides whether to restart the non-container application process according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. The restart timing after uninstallation includes immediate restart after uninstallation, delayed restart after uninstallation, and manual restart after uninstallation. If restart is not required, skip it.

[0172] An electronic device is also provided in an embodiment of the present application, and the electronic device includes: a processor and a memory. The processor and the memory are connected, such as through a bus. Optionally, the electronic device may also include a transceiver. It should be noted that in actual applications, the transceiver is not limited to one, and the structure of the electronic device does not constitute a limitation on the embodiment of the present application.

[0173] The processor may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0174] The bus may include a path to transmit information between the above components. The bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0175] The memory can be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it can be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this.

[0176] The memory is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor. The processor is used to execute the application code stored in the memory to implement the content shown in the embodiment of the non-container application orchestration method based on Kubernetes CRI plug-in disclosed above.

[0177] The electronic devices include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and fixed terminals such as digital TVs, desktop computers, etc. It can also be a server, etc.

[0178] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0179] The above is only a partial implementation method of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A non-container application orchestration method based on Kubernetes CRI plug-in, characterized in that: The following steps are involved: S1. Definition of description information of non-container applications; S11, application.yaml: defines the basic information of non-container applications; S12, ApplicationVersion.yaml: defines the current version of the non-container application, records the CPU architecture of the current version and the media information to which each version is applied; S2, container creation and startup; S21. The server hosts each version of the media defined in ApplicationVersion.yaml in the media warehouse, where the media include image media, common media, and script files. The server provides a media list for non-container images, which includes common media and script files. The download path of the media list must meet the image naming rules and be configured as the Pod's Image name. The name of the media list contains a fixed prefix "ncri-manifest". S22, the media manifest file NcriManifest.yaml of the non-container image describes the media list included in the non-container image; S23: The Pod is scheduled to the Kubernetes node, and Kubelet notifies CRI-O to create a container. After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format. S24: NCRI downloads the image media. When it detects that it is a non-container image, it first downloads the media list, and then downloads the non-container media and scripts in the list; If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent; S25: Kubelet creates a container on the node based on the pulled image or non-container media; After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it; S3, container configuration; S31. When kubelet calls the CRI interface to create a container, NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volumes in the root directory of the non-container application instance, and sets the root directory of the container to the container's environment variable APPLICATION_INSTANCE_HOME. S32. Create a configuration file for the container, recording the required environment variables and cgroup; S33. Set a user for the container and grant permissions; S34. Execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

2. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 1, characterized in that: The following steps are also included: S4. Container patch management; S41. Inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod; S42. After node-agent detects the patch information that needs to be installed in the annotation under the Pod, it checks conflicts, downloads, and installs the patches in sequence, and determines the restart timing after installation according to the configuration; S43. After node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, it controls the uninstallation of the patch in reverse order, and determines whether it is necessary to restart the non-container application process according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. If restart is not required, it is skipped.

3. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 1, characterized in that: The S1 further comprises the following steps: S13, ApplicationPatch.yaml: defines the patch information with a specific number under a specific version of the application medium. The patch information includes: application version series, patch version number, module, upgrade path, conflicting patch list, upgrade prerequisite, whether uninstallation is supported, uninstallation prerequisite, shelf status, and medium list; S14. Maintain image files, non-container media, non-container patch media, and non-container script files used by non-container applications.

4. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 1, characterized in that: The basic information in S11 includes application name, category, service discovery image, and version sequence.

5. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 1, characterized in that: The media information in S12 includes container images, non-container application media, dependency libraries, patch media, and media script files; The media script files include installation scripts, start and stop scripts, upgrade scripts, backup scripts, and service discovery scripts.

6. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 1, characterized in that: The environment variables in S32 include: container root directory, container workingDir, media directory of the container corresponding to the image, script directory of the container corresponding to the image, and port information assigned to the current pod.

7. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 2, characterized in that: The restart timing after installation in S42 includes immediate restart after installation, delayed restart after installation, and manual restart after installation.

8. The method for orchestrating non-container applications based on Kubernetes CRI plug-in according to claim 2, characterized in that: The restart timing after uninstallation in S43 includes immediate restart after uninstallation, delayed restart after uninstallation, and manual restart after uninstallation.

9. A non-container application orchestration device based on Kubernetes CRI plug-in, characterized in that: Includes the following modules: Definition module, used to define the description information of non-container applications, including: Basic information definition unit, application.yaml: used to define the basic information of non-container applications, including application, category, service discovery image, and version sequence; Current version definition unit, ApplicationVersion.yaml: used to define the current version of non-container applications, record the CPU architecture of the current version and the media information to which each version is applied; The container creation and startup module is used to create and start containers, including: The download path unit of the media manifest is used to enable the server to host the media of each version defined in ApplicationVersion.yaml in the media warehouse. The media includes image media, common media, and script files. The server provides a media manifest for non-container images. The media manifest includes common media and script files. The download path of the media manifest satisfies the image naming rules and is configured as the Image name of the Pod. The name of the media manifest contains the fixed prefix "ncri-manifest". Describes the media list unit, which is used for the media list file NcriManifest.yaml of the non-container image to describe the media list included in the non-container image; Kubelet notifies CRI-O to create a container unit. After the Pod is scheduled to the Kubernetes node, Kubelet notifies CRI-O to create a container. After the Pod of the non-container application instance is scheduled to the Kubernetes node, the Pod includes containers created based on Docker images and / or containers created based on non-container media. Then Kubelet notifies CRI-O to create containers. CRI-O downloads image media according to the image type. Image media includes Docker images, non-container images, and images in OCI format. The media list download unit, NCRI downloads the image media. When a non-container image is detected, the media list is downloaded first, and then the non-container media and scripts in the list are downloaded; If the non-container runtime NCRI detects an image with the prefix "ncri-manifest" in the Image name, the non-container runtime NCRI converts the Image name into the download path of the media manifest, downloads the media manifest and the media included in the manifest to the local computer, and verifies whether the Sha256 of the common media and the script file are consistent; The container creation and startup unit is used to create a container based on the pulled image or non-container media on the node by Kubelet; After the Docker image or non-container image is downloaded, kubelet creates a container based on the pulled image on the node and starts it; Container configuration module, used for container configuration, including: The root directory unit is used when kubelet calls the CRI interface to create a container. NCRI receives the container creation request, finds the path of the common media and script files corresponding to the container image, creates a root directory for the container, sets the root directory as a mount point and manages the data storage directory, mounts ConfigMap, Secret, and volume in the root directory of the non-container application instance, and sets the container's root directory to the container's environment variable APPLICATION_INSTANCE_HOME. The configuration file unit is used to form the configuration file of the container and record the required environment variables and cgroup; User unit, used to set users and grant permissions for containers; The association unit is used to execute the script corresponding to the container image. First, execute the install command to install the common media. After the installation is complete, execute the start command to start the application. NCRI rebuilds the cgroup of the container and associates all processes of the container with the corresponding cgroup.

10. The non-container application orchestration device based on Kubernetes CRI plug-in according to claim 9, characterized in that: Also includes the following modules: Container patch management module, used for container patch management, including: The patch information injection unit is used to inject the patch information of non-container applications into the annotations bes.com / patch.info and bes.com / patch.status of the Pod; The patch installation unit is used to check conflicts, download and install patches in order after the node-agent detects the patch information that needs to be installed in the annotation under the Pod, and determines the restart timing after installation according to the configuration; The patch uninstallation unit is used to control the uninstallation of patches in reverse order after the node-agent detects the patch information that needs to be uninstalled in the annotation under the Pod, and decides whether to restart the non-container application process according to the patch description information. If restart is required, the restart timing after uninstallation is determined according to the configuration. If restart is not required, it is skipped.

Images