Non-cloud-native application orchestration method and system, electronic device, and storage medium

Abstract

The application relates to the technical field of cloud computing, in particular to a non-cloud-native application arrangement method and system, an electronic device and a storage medium. In the non-cloud-native application arrangement method, arrangement control instructions and application characteristic information are first obtained. Then, based on the application characteristic information, an adaptive middleware is configured in a Kubernetes cloud platform, and the arrangement control instructions are sent to the adaptive middleware. Further, the arrangement control instructions are processed through the adaptive middleware to generate target arrangement instructions that conform to the compatible adaptation characteristics of the non-cloud-native application. Finally, the non-cloud-native application is deployed and arranged based on the target arrangement instructions. In the non-cloud-native application arrangement method, the arrangement control instructions are processed through the adaptive middleware, so that the target arrangement instructions that conform to the compatible adaptation characteristics of the non-cloud-native application are generated, and the compatible adaptation problem between the Kubernetes cloud platform and the non-cloud-native application is solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a non-cloud-native application orchestration method and system, electronic device, and storage medium. Background Technology

[0002] The software-defined nature of IT infrastructure has become an industry consensus. In practice, this concept corresponds to cloud-native infrastructure, which gives IT infrastructure a high degree of abstraction, shields underlying details, and unifies its characteristics. Cloud-native can be divided into two parts: cloud and native. The cloud is the opposite of on-premises. Traditional applications mostly run on local servers, while nowadays, most popular applications run in the cloud.

[0003] Kubernetes (K8S) is a portable container orchestration and management technology designed for container services. Building upon Docker, Kubernetes provides a range of functionalities for containerized applications, including deployment, resource scheduling, service discovery, and dynamic scaling. According to relevant technologies, migrating non-cloud-native applications to cloud-native environments and orchestrating these applications using Kubernetes often encounters compatibility issues; that is, non-cloud-native applications are not adapted to Kubernetes' orchestration of cloud-native infrastructure resources. Therefore, resolving the compatibility issues of non-cloud-native applications in cloud-native environments has become a pressing challenge in the industry. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a non-cloud-native application orchestration method and system, electronic device, and storage medium, which can solve the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments.

[0005] The non-cloud-native application orchestration method according to the first aspect of this application includes:

[0006] Obtain orchestration control instructions and application characteristic information. The orchestration control instructions are generated by the Kubernetes cloud platform, and the application characteristic information is used to identify the compatibility and adaptation characteristics of non-cloud-native applications.

[0007] Based on the application characteristic information, an adaptation middleware is configured in the Kubernetes cloud platform, and the orchestration control instructions are delivered to the adaptation middleware;

[0008] The orchestration control instructions are processed by the adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application.

[0009] The non-cloud-native application is deployed and orchestrated based on the target orchestration instructions.

[0010] According to some embodiments of this application, configuring the adaptation middleware in the Kubernetes cloud platform based on the application characteristic information includes:

[0011] Recall the functional script program that matches the application characteristic information from the preset database;

[0012] Hook functions are set in the adaptation middleware, and the functional script program is introduced into the adaptation middleware based on the hook functions.

[0013] According to some embodiments of this application, before calling the function script program that matches the application characteristic information from the preset database, the method further includes:

[0014] Obtain preset script programs and multiple types of preset adaptation information, wherein the multiple types of preset adaptation information are used to identify various types of compatibility and adaptation features;

[0015] Based on the preset script programs and various preset adaptation information, various preset script programs are formed;

[0016] Based on the mapping relationship between the preset script programs and the preset adaptation information, various preset script programs are entered into the preset database.

[0017] According to some embodiments of this application, the step of calling a function script program that matches the application characteristic information from a preset database includes:

[0018] Obtain the preset adaptation information that matches the application characteristic information;

[0019] Based on the preset adaptation information that matches the application characteristic information, the functional script program is obtained by filtering in the preset database. The functional script program is the preset script program that conforms to the compatibility and adaptation characteristics of the non-cloud native application.

[0020] According to some embodiments of this application, the step of setting a hook function in the adaptation middleware and introducing the functional script program into the adaptation middleware based on the hook function includes:

[0021] The hook function is declared in the adaptation middleware;

[0022] After the hook function is declared, the functional script program is introduced into the adapter middleware via the command in the hook function.

[0023] According to some embodiments of this application, the step of processing the orchestration control instructions via the adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application includes:

[0024] Based on the aforementioned functional script program, the functional instruction type of the orchestration control instruction is identified;

[0025] When the type of the function instruction matches the preset instruction type, the target code in the function script program is executed to generate the target orchestration instruction.

[0026] According to some embodiments of this application, the preset instruction type is an exit instruction, and the deployment and orchestration of the non-cloud-native application based on the target orchestration instruction includes:

[0027] Based on the target orchestration instructions, a shutdown warning message is sent to the non-cloud-native application, which is used to cause the non-cloud-native application to perform a data saving operation.

[0028] Once the data saving operation is completed, control the non-cloud-native application to perform an exit operation.

[0029] A non-cloud-native application orchestration system according to a second aspect of this application includes: a Kubernetes cloud platform, an adaptation middleware, and a non-cloud-native application;

[0030] The Kubernetes cloud platform is used to generate orchestration control instructions and obtain application characteristic information, and to configure the adaptation middleware in the Kubernetes cloud platform based on the application characteristic information. The application characteristic information is used to identify the compatibility and adaptation characteristics of non-cloud native applications.

[0031] The adaptation middleware is used to process the orchestration control instructions and generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application. The target orchestration instructions are used to deploy and orchestrate the non-cloud-native application.

[0032] The non-cloud-native application is used to receive and execute the target orchestration instructions.

[0033] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the non-cloud-native application orchestration method as described in any one of the embodiments of the first aspect of this application.

[0034] Fourthly, embodiments of this application provide a computer-readable storage medium storing a program that is executed by a processor to implement the non-cloud-native application orchestration method as described in any one of the embodiments of the first aspect of this application.

[0035] The non-cloud-native application orchestration method, system, electronic device, and storage medium according to the embodiments of this application have at least the following beneficial effects:

[0036] In this non-cloud-native application orchestration method, orchestration control instructions and application characteristic information are first obtained. The orchestration control instructions are generated by the Kubernetes cloud platform, and the application characteristic information is used to identify the compatibility and adaptation characteristics of the non-cloud-native application. Then, based on the application characteristic information, an adaptation middleware is configured in the Kubernetes cloud platform, and the orchestration control instructions are sent to the adaptation middleware. Further, the adaptation middleware processes the orchestration control instructions to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application. Finally, the non-cloud-native application is deployed and orchestrated based on the target orchestration instructions. This non-cloud-native application orchestration method uses an adaptation middleware to process the orchestration control instructions, thereby generating target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application, thus resolving the compatibility and adaptation issues between the Kubernetes cloud platform and non-cloud-native applications.

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

[0038] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0039] Figure 1 This is a schematic diagram of the non-cloud-native application orchestration method provided in the embodiments of this application;

[0040] Figure 2 This is a schematic diagram of a functional script program code snippet provided in an embodiment of this application;

[0041] Figure 3 This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0042] Figure 4 This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0043] Figure 5 This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0044] Figure 6 This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0045] Figure 7This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0046] Figure 8 This is another flowchart illustrating the non-cloud-native application orchestration method provided in the embodiments of this application;

[0047] Figure 9 This is a schematic diagram of a non-cloud-native application orchestration system module provided in an embodiment of this application;

[0048] Figure 10 A schematic diagram of an electronic device for implementing the non-cloud-native application orchestration method provided in the embodiments of this application. Detailed Implementation

[0049] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0050] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0051] In the description of this application, it should be understood that the orientation descriptions, such as up, down, left, right, front, and back, are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0052] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0053] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setting," "installation," and "connection" should be interpreted broadly. Those skilled in the art can reasonably determine the specific meaning of the above terms in this application based on the specific content of the technical solution. Furthermore, the identification of specific steps in the following text does not imply a limitation on the order of steps or execution logic. The execution order and logic between each step should be understood and inferred from the content described in the embodiments.

[0054] The software-defined nature of IT infrastructure has become an industry consensus. In practice, this concept corresponds to cloud-native infrastructure, which gives IT infrastructure a high degree of abstraction, shields underlying details, and unifies its characteristics. Cloud-native can be divided into two parts: cloud and native. The cloud is the opposite of on-premises. Traditional applications mostly run on local servers, while nowadays, most popular applications run in the cloud.

[0055] Kubernetes (K8S) is a portable container orchestration and management tool designed for container services. Building upon Docker technology, Kubernetes provides a range of functions for containerized applications, including deployment, resource scheduling, service discovery, and dynamic scaling, improving the convenience and high availability of large-scale container cluster management. According to relevant technologies, migrating non-cloud-native applications to cloud-native environments and orchestrating these applications using Kubernetes often encounters compatibility issues; that is, non-cloud-native applications are not adapted to Kubernetes' orchestration of cloud-native infrastructure resources. Therefore, resolving the compatibility issues of non-cloud-native applications in cloud-native environments has become a pressing problem in the industry.

[0056] It's important to note that Kubernetes is a container cluster management system that provides a container-centric infrastructure, making the deployment of containerized applications simple and efficient. Kubernetes supports automated deployment, large-scale scalability, and containerized application management. When deploying an application in a production environment, multiple instances of the application are typically deployed to load balance application requests. In Kubernetes, we can create multiple containers, each running an application instance, and then manage, discover, and access this group of application instances through built-in load balancing strategies—all without requiring complex manual configuration and handling by operations personnel. Kubernetes offers advantages such as portability, scalability, and automation. Portability refers to its support for public, private, hybrid, and multi-cloud environments; scalability refers to its modularity, pluggability, mountability, and composability; and automation refers to its support for automatic deployment, automatic restart, automatic replication, and automatic scaling / expansion. Kubernetes provides mechanisms for application deployment, planning, updating, and maintenance. It should be understood that traditional application deployment methods install applications via plugins or scripts. The drawback is that the application's operation, configuration, management, and entire lifecycle are tied to the current operating system. This hinders application upgrades, updates, and rollbacks. While some functionality can be achieved by creating virtual machines, virtual machines are very heavy and not conducive to portability. The Kubernetes cloud platform, on the other hand, uses containers to orchestrate application deployment. Each container is isolated from the others, has its own file system, and processes within containers do not interfere with each other, allowing for the differentiation of computing resources. Compared to virtual machines, containers can be deployed quickly. Because containers are decoupled from the underlying infrastructure and machine file system, they can be migrated between different clouds and different operating system versions.

[0057] According to some embodiments provided in this application, after hosting basic resources to a cloud-native platform, it is necessary to migrate the original non-cloud-native applications to the cloud-native environment. Due to the non-cloud-native nature of these applications, they do not call the Kubernetes cloud platform's service interfaces, nor do they provide management interfaces to the Kubernetes cloud platform. Therefore, non-cloud-native applications cannot fully utilize the core orchestration and management capabilities of the Kubernetes cloud platform, inevitably leading to compatibility and adaptation issues in the cloud-native environment—that is, the applications are not adapted to the cloud-native basic resource management approach. For example, the automatic service restart and repair, and automatic reconstruction after resource anomalies provided by the closed-loop control at the core of the Kubernetes cloud platform cannot be implemented for non-cloud-native applications that directly face front-end users. This means that non-cloud-native applications will frequently crash during use, thus affecting user experience. To achieve compatibility and adaptation with the cloud-native environment, it is generally necessary to modify non-cloud-native applications. However, modifying the diverse range of non-cloud-native applications will generate a very heavy workload. In addition, the reconstruction costs for modifying earlier versions of non-cloud-native applications are also very high.

[0058] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a non-cloud-native application orchestration method and system, electronic device, and storage medium, which can solve the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments.

[0059] The following explanation is based on the accompanying drawings.

[0060] Reference Figure 1 The non-cloud-native application orchestration method according to the first aspect of this application includes:

[0061] Step S101: Obtain orchestration control instructions and application characteristic information. The orchestration control instructions are generated by the Kubernetes cloud platform, and the application characteristic information is used to identify the compatibility and adaptation characteristics of non-cloud native applications.

[0062] It should be noted that orchestration control instructions refer to the control instructions generated by the Kubernetes cloud platform for orchestrating and deploying non-cloud-native applications. Application characteristic information refers to information used to identify the compatibility and adaptation characteristics of non-cloud-native applications. It should be understood that based on differences in component types, component versions, etc., of non-cloud-native applications, the corresponding application characteristic information will also differ. For example, Nginx (engine x) is an HTTP and reverse proxy web server, and Spring Boot is a framework used to simplify the initial setup and development process of Spring applications. Nginx and Spring Boot versions 2.3 and later support graceful exit, while Spring Boot versions prior to 2.3 do not. Therefore, their corresponding application characteristic information also differs. It should be clarified that graceful exit refers to an exit mode that uses a pre-notification mechanism to clean up resources, save necessary intermediate states, and persist memory data before the application shuts down. It should be understood that compatibility and adaptation of graceful exit modes is only one type of compatibility and adaptation problem faced by non-cloud-native applications in cloud-native environments. Therefore, the types of orchestration control instructions and application characteristic information can include, but are not limited to, the specific embodiments mentioned above.

[0063] Step S102: Configure the adaptation middleware in the Kubernetes cloud platform based on application characteristic information, and deliver orchestration control instructions to the adaptation middleware;

[0064] It should be noted that middleware refers to a type of software that sits between application systems and system software. It uses the basic services (functions) provided by the system software to connect various parts of application systems or different applications on a network, achieving resource and function sharing. Middleware is a major category of basic software and belongs to the category of reusable software. It should be understood that middleware sits above the operating system, network, and database, below the application software. Its overall role is to provide a runtime and development environment for the application software above it, helping users to flexibly and efficiently develop and integrate complex application software. Among the many definitions of middleware, the most widely accepted is that of the Internet Data Center (IDC): Middleware is an independent system software or service program that allows distributed application software to share resources across different technologies. Middleware resides above the client server's operating system, managing computing resources and network communication. With the rapid development of computer technology, more and more application software is required to operate on many different network protocols, different hardware manufacturers, and different network platforms and environments. This leads software developers to face challenges such as data dispersion, operational difficulties, low system compatibility, and the need to develop multiple applications to achieve operational goals. Therefore, the emergence of middleware technology has greatly reduced the burden on developers and made network operations more efficient.

[0065] According to some embodiments provided in this application, in order to solve the compatibility and adaptation problem of non-cloud-native applications in a cloud-native environment, it is necessary to configure an adaptation middleware in the Kubernetes cloud platform based on application characteristic information and deliver orchestration control instructions to the adaptation middleware. Since application characteristic information refers to information used to identify the compatibility and adaptation characteristics of non-cloud-native applications, the adaptation middleware can be configured in the Kubernetes cloud platform based on the application characteristic information, thereby making the adaptation middleware an information interaction hub for solving compatibility and adaptation problems. Furthermore, the orchestration control instructions are delivered to the adaptation middleware so that the adaptation middleware processes the orchestration control instructions and generates target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications.

[0066] Step S103: The orchestration control instructions are processed through the adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud native applications.

[0067] According to some embodiments provided in this application, since the adaptation middleware is configured in the Kubernetes cloud platform based on application characteristic information, using the adaptation middleware to process orchestration control instructions can convert the orchestration control instructions into target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications. This allows for further deployment and orchestration of non-cloud-native applications using the target orchestration instructions. It should be noted that due to differences in component types, component versions, etc., of non-cloud-native applications, the corresponding application characteristic information will also differ. Therefore, the type of adaptation middleware configured in the Kubernetes cloud platform based on the application characteristic information will also differ. For example, both Nginx and Spring Boot versions 2.3 and later support graceful exit. Therefore, the adaptation middleware configured in the Kubernetes cloud platform based on application characteristic information can directly translate orchestration control instructions into graceful exit execution statements that Nginx or Spring Boot versions 2.3 and later can recognize, generating target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications, thus solving the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments. Conversely, if Spring Boot versions prior to 2.3 do not support graceful exit, then the adaptation middleware configured in the Kubernetes cloud platform based on application characteristic information needs to embed a piece of graceful exit execution code that Spring Boot versions prior to 2.3 can recognize, thereby generating target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications, thus solving the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments. It should be understood that graceful exit mode compatibility is just one type of compatibility problem faced by non-cloud-native applications in cloud-native environments. Therefore, the process of orchestration control instructions through adaptation middleware to generate target orchestration instructions that conform to the compatibility characteristics of non-cloud-native applications may include, but is not limited to, the specific embodiments mentioned above.

[0068] Step S104: Deploy and orchestrate non-cloud-native applications based on target orchestration instructions.

[0069] According to some embodiments provided in this application, since orchestration control instructions refer to control instructions generated by the Kubernetes cloud platform for orchestrating and deploying cloud-native applications, and target orchestration instructions are converted from orchestration control instructions, and target orchestration instructions conform to the compatibility and adaptation characteristics of non-cloud-native applications, deploying and orchestrating non-cloud-native applications based on target orchestration instructions can solve the compatibility and adaptation problem of non-cloud-native applications in the cloud-native environment.

[0070] In this non-cloud-native application orchestration method, orchestration control instructions and application characteristic information are first obtained. The orchestration control instructions are generated by the Kubernetes cloud platform, and the application characteristic information is used to identify the compatibility and adaptation characteristics of the non-cloud-native application. Then, based on the application characteristic information, an adaptation middleware is configured in the Kubernetes cloud platform, and the orchestration control instructions are sent to the adaptation middleware. Further, the adaptation middleware processes the orchestration control instructions to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application. Finally, the non-cloud-native application is deployed and orchestrated based on the target orchestration instructions. This non-cloud-native application orchestration method uses an adaptation middleware to process the orchestration control instructions, thereby generating target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application, thus resolving the compatibility and adaptation issues between the Kubernetes cloud platform and non-cloud-native applications.

[0071] Reference Figure 2 According to some embodiments of this application, configuring adaptation middleware in a Kubernetes cloud platform based on application characteristic information includes:

[0072] Step S201: Call the function script program that matches the application characteristic information from the preset database;

[0073] According to some embodiments provided in this application, the preset database refers to a pre-set database used to store various preset adaptation information. The preset adaptation information is used to identify various types of compatibility and adaptation features. It should be understood that, based on differences in component types, component versions, etc., of non-cloud-native applications, the corresponding preset adaptation information will also differ, and therefore the preset script programs corresponding to the preset adaptation information will also differ. It should be noted that, considering the differences between various types of preset adaptation information, the internal code of the preset script program can be pre-set according to the compatibility and adaptation requirements under various application scenarios. For example, to enable graceful shutdown of non-cloud-native applications that support semaphore control, a semaphore can be sent to instruct the application to wait for a period before performing the shutdown operation. Another example is for non-cloud-native applications that support HTTP control, using tools like curl and wget to implement command-line request middleware services. In this scenario, curl and wget tools need to be pre-packaged in the application container, or the Kubernetes cloud platform's Pod unit initialization (initContainer) can be used to embed curl and wget tools into the application container at startup. Yet another example is for non-cloud-native applications that do not support the above control methods, modifications can be made in, but are not limited to, the following two ways: First, by using the sidecar pattern of the Pod unit, a sidecar container can be added to the application container, using Nginx or Evony to proxy the application container's requests. Pre-defined scripts can be embedded in the sidecar container to leverage the proxy gateway's capabilities. Second, a suitable readiness probe can be constructed. The first approach, using a script to change the state of a ready probe, allows the instance to be taken offline from the Service resource. The Kubernetes cloud platform's Pod unit periodically checks the status of the custom ready probe; if it returns a failure, the new resource will not be distributed to that instance. It's worth noting that the first approach has the advantage of strong applicability, a unified modification scheme, and convenient subsequent maintenance, but the disadvantage is the need to add a sidecar container, increasing computational costs. The second approach, on the other hand, has the advantage of not requiring additional computing power, but the disadvantage is the need for careful design of the ready probe implementation so that the hook function can change its probe state. This requires independent design for each specific application, and the aforementioned preset script settings can be flexibly selected based on the application scenario.

[0074] It should be understood that the preset script program settings may include, but are not limited to, the specific embodiments described above.

[0075] It should be noted that a function script program refers to a program used to solve compatibility and adaptation issues between the Kubernetes cloud platform and non-cloud-native applications. It should be understood that a function script program can process orchestration control instructions to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications. In some embodiments of this application, it is necessary to pre-call a preset script program that matches the application characteristic information from a preset database based on the application characteristic information, and then further determine the preset script program that matches the application characteristic information as the function script program. It should be understood that the function script program can be a Shell script program, a Python script program, or other types of script programs.

[0076] Step S202: Set hook functions in the adaptation middleware, and import the functional script program into the adaptation middleware based on the hook functions.

[0077] According to some embodiments provided in this application, a Pod Hook is a function that can sense events in the container's lifecycle and execute user-specified program code when the corresponding time arrives. It should be noted that the Pod Hook is initiated by the Kubelet component and runs after the process in the container starts or before the process in the container terminates. The Kubelet component is the main service component on the worker node, used to periodically receive new or modified Pod specifications from the Kube-API Server component and ensure that the Pod unit and its container run under the expected specifications. Simultaneously, the Kubelet component acts as a monitoring component for the worker node, reporting the host's operational status to the Kube-API Server. In some embodiments of this application, Kubernetes provides two types of Pod Hooks: First, the PostStart Pod Hook, which executes immediately after the container is created, but it cannot be guaranteed that the hook will run before the container's entry point because no parameters are passed to the handler. It is mainly used for resource deployment, environment preparation, etc. However, it should be noted that if the hook takes too long to run or hangs, the container will not reach a running state. Secondly, the PreStop hook function is called immediately before the container terminates. It must be completed before the call to delete the container is issued. It is mainly used for gracefully shutting down the application, notifying other systems, etc. If the PreStop hook function is suspended during execution, the Pod unit will remain in the running state and will not reach the running failure state.

[0078] Reference Figure 3The illustrated code snippet, according to some specific embodiments of this application, sets hook functions in the adaptation middleware and introduces functional script programs into the adaptation middleware based on the hook functions. For example, example-grace.yaml can be first introduced into the adaptation middleware, where "example-grace" is the name of the yaml file. yaml is a language specifically used for writing configuration files, and configuration files written in yaml are called yaml files. Furthermore, "Lifecycle" refers to the lifecycle of the container and is used in conjunction with the PreStop hook function, while "exec:command:[...]" is the exec instruction, meaning that the "command:[...]" command is executed once within the container. Therefore, through... Figure 3 The code snippet shown demonstrates how example-grace.yaml can be used to set a PreStop hook function in the adaptation middleware, and how the functional script can be imported into the adaptation middleware in command:[...] based on the PreStop hook function. It should be understood that setting hook functions in the adaptation middleware and importing functional scripts into the adaptation middleware based on the hook functions can be implemented in various ways, including, but not limited to, the specific embodiments described above.

[0079] Reference Figure 4 According to some embodiments of this application, before calling a function script program that matches application characteristic information from a preset database, the method further includes:

[0080] Step S401: Obtain the preset script program and multiple types of preset adaptation information. The multiple types of preset adaptation information are used to identify various types of compatibility and adaptation features.

[0081] According to some embodiments provided in this application, the preset database refers to a pre-set database used to store various preset adaptation information. Multiple types of preset adaptation information are used to identify various types of compatibility and adaptation features. It should be understood that, based on differences in component types, component versions, etc., of non-cloud-native applications, the corresponding preset adaptation information will also differ, and therefore the preset script programs corresponding to the preset adaptation information will also differ. It needs to be clarified that the preset script program refers to a script program pre-set with reference to multiple types of preset adaptation information and various possible application scenarios.

[0082] Step S402: Based on the preset script program and various preset adaptation information, various preset script programs are generated;

[0083] According to some embodiments provided in this application, considering the differences between various types of preset adaptation information, the internal code of the preset script program can be pre-configured according to the compatibility and adaptation requirements of various application scenarios. For example, both Nginx and Spring Boot versions 2.3 and later support graceful exit. Therefore, the various preset script programs corresponding to the preset adaptation information can directly translate the user's input control commands into graceful exit execution statements that Nginx or Spring Boot versions 2.3 and later can recognize, thus solving the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments. Alternatively, if Spring Boot versions prior to 2.3 do not support graceful exit, then the various preset script programs corresponding to the preset adaptation information can inject a piece of graceful exit execution code that Spring Boot versions prior to 2.3 can recognize into the adaptation middleware according to the user's input control commands, thereby solving the compatibility and adaptation problem of non-cloud-native applications in cloud-native environments. According to some specific embodiments of this application, for Spring Boot versions 2.3 and later, although graceful restart is supported, compatibility issues of non-cloud-native applications in cloud-native environments can be resolved by embedding graceful exit execution code that Spring Boot can recognize through functional scripts. This avoids exposing the Acuator service endpoint and prevents data security risks. The reason for this is that resolving compatibility issues through functional scripts allows for custom configuration by restricting service endpoints, enabling non-native applications to accept only local requests and avoid external security threats.

[0084] According to some embodiments provided in this application, the process of custom configuration in the preset script program can refer to the compatibility and adaptation requirements of various application scenarios. For example, for non-cloud-native applications that support semaphore control, if it is desired to enable graceful exit, a semaphore can be sent to make the non-cloud-native application wait for a period of time before performing the shutdown operation; another example is for non-cloud-native applications that support HTTP control, using tools such as curl and wget to implement command-line request middleware services. In this scenario, tools such as curl and wget need to be packaged in the application container in advance, or the Kubernetes cloud platform's Pod unit initialization container (initContainer) can be used to inject curl and wget tools into the application container at startup; yet another example is for non-cloud-native applications that do not support the above control methods, they can be modified in, but not limited to, the following two ways: First, by using the sidecar mode of the Pod unit, a sidecar container is added to the application container, using Nginx or Evony to proxy the application container's requests, and a preset script program is injected into the sidecar container to leverage the proxy gateway's capabilities; second, a suitable readiness probe is constructed. The first approach, using a script to change the state of a ready probe, allows the instance to be taken offline from the Service resource. The Kubernetes cloud platform's Pod unit periodically checks the status of the custom ready probe; if it returns a failure, the new resource will not be distributed to that instance. It's worth noting that the first approach has the advantage of strong applicability, a unified modification scheme, and convenient subsequent maintenance, but the disadvantage is the need to add a sidecar container, increasing computational costs. The second approach, on the other hand, has the advantage of not requiring additional computing power, but the disadvantage is the need for careful design of the ready probe implementation so that the hook function can change its probe state. This requires independent design for each specific application, and the aforementioned preset script program settings can be flexibly selected based on the application scenario. It should be understood that various preset script programs, formed based on preset script programs and various preset adaptation information, can include, but are not limited to, the specific embodiments mentioned above.

[0085] Step S403: Based on the mapping relationship between preset script programs and preset adaptation information, various preset script programs are entered into the preset database.

[0086] According to some embodiments provided in this application, in order to call functional script programs that match application characteristic information from a preset database, the preset database needs to pre-enter various types of preset adaptation information, various types of preset script programs, and the mapping relationship between preset adaptation information and preset script programs. It should be noted that, due to differences in component types, component versions, etc., of non-cloud-native applications, the corresponding preset adaptation information will also be different, and therefore the preset script programs corresponding to the preset adaptation information will also be different. It should also be noted that, considering the differences between various types of preset adaptation information, the internal code of the preset script programs can be pre-set according to various application scenarios. Therefore, the mapping relationship between various preset adaptation information and corresponding preset script programs can be obtained during the pre-setting process of the internal code of the preset script programs. Furthermore, by entering the preset script programs or preset adaptation information into the preset database, various types of preset adaptation information, various types of preset script programs, and the mapping relationship between preset adaptation information and preset script programs can be entered into the preset database by referring to the mapping relationship between various preset adaptation information and corresponding preset script programs. It should be understood that there are various ways to construct the preset database, including but not limited to the specific embodiments mentioned above.

[0087] Reference Figure 5 According to some embodiments of this application, calling a function script program that matches application characteristic information from a preset database includes:

[0088] Step S501: Obtain preset adaptation information that matches the application characteristic information;

[0089] According to some embodiments provided in this application, application characteristic information refers to information used to identify the compatibility and adaptation characteristics of non-cloud-native applications. It should be understood that the corresponding application characteristic information will differ based on differences in component types, component versions, etc., of non-cloud-native applications. Since the preset database pre-stores multiple types of preset adaptation information for identifying various types of compatibility and adaptation characteristics, the preset adaptation information matching the application characteristic information can be retrieved from the preset database by using the application characteristic information corresponding to the non-cloud-native application as a clue. Therefore, functional script programs can be filtered out from the preset database by utilizing the preset adaptation information matching the application characteristic information and the mapping relationship between preset script programs and preset adaptation information.

[0090] Step S502: Based on the preset adaptation information that matches the application characteristic information, the function script program is selected from the preset database. The function script program is a preset script program that meets the compatibility and adaptation characteristics of non-cloud native applications.

[0091] It is important to emphasize that due to differences in component types and versions among non-cloud-native applications, the corresponding preset adaptation information will also differ, and therefore the preset scripts corresponding to this preset adaptation information will also differ. It should be noted that, considering the differences between various types of preset adaptation information, the internal code of the preset scripts can be pre-configured according to various application scenarios. Therefore, the various preset scripts pre-stored in the preset database cover all possible application scenarios. Furthermore, since a mapping relationship exists between various preset scripts and various preset adaptation information, functional scripts can be filtered out from the preset database by utilizing preset adaptation information that matches application characteristic information and the mapping relationship between preset scripts and preset adaptation information. It should be understood that there are various ways to call functional scripts that match application characteristic information from the preset database, including, but not limited to, the specific embodiments mentioned above.

[0092] Reference Figure 3 , Figure 6 According to some embodiments of this application, hook functions are set in the adaptation middleware, and functional script programs are introduced into the adaptation middleware based on the hook functions, including:

[0093] Step S601: Declare the hook function in the adaptation middleware;

[0094] According to some embodiments provided in this application, a Pod Hook is a function that can sense events in the container's lifecycle and execute user-specified program code when the corresponding time arrives. It should be noted that the Pod Hook is initiated by the Kubelet component and runs after the process in the container starts or before the process in the container terminates. The Kubelet component is the main service component on the worker node, used to periodically receive new or modified Pod specifications from the Kube-API Server component and ensure that the Pod unit and its container run under the expected specifications. Simultaneously, the Kubelet component acts as a monitoring component of the worker node, reporting the host's operational status to the Kube-API Server. In some preferred embodiments of this application, the PreStop Pod Hook is selected as the Pod Hook function for introducing the functional script program into the adaptation middleware.

[0095] Reference Figure 3The code snippet shown illustrates that, according to some specific embodiments of this application, the declaration of the PreStop hook function in the adaptation middleware needs to be done in the YAML file. Therefore, code in the form of "example-grace.yaml:..." can be used as a fixed statement for declaring the PreStop hook function. Additionally, the fixed statement for declaring the PreStop hook function also includes "Lifecycle," which refers to the container's lifecycle. It should be noted that the PreStop hook function supports, but is not limited to, defining actions using the following three methods: the exec directive, which executes a command once within the container; tcpSocket, which attempts to access a specified socket in the current container; and httpGet, which initiates an HTTP request to a URL in the current container. In some embodiments of this application, the exec directive is combined with the PreStop hook function to form... Figure 3 The code snippet shown is an example. It should be understood that there are many ways to declare hook functions in an adaptation middleware, including, but not limited to, the specific embodiments given above.

[0096] Step S602: After declaring the hook function, the functional script program is introduced into the adapter middleware via the command in the hook function.

[0097] It should be noted that after declaring the hook function, the functional script program can be imported into the adaptation middleware via the command in the hook function, as follows: Figure 3 The code snippet shown first imports `example-grace.yaml` into the middleware, where "example-grace" is the name of the YAML file. Then, it uses "Lifecycle" as a fixed statement to declare the `PreStop` hook function, and uses it in conjunction with the `PreStop` hook function. "exec:command:[...]" is the `exec` instruction. The `exec` instruction combined with the `PreStop` hook function means that the `command:[...]` command is executed once before the container terminates. Therefore, through... Figure 3 The code snippet shown declares the hook function, and after the declaration, the functional script is imported into the adapter middleware via the command in the PreStop hook function. It should be understood that the “…” in “command:[…]” represents the functional script to be imported. It should be understood that importing the functional script into the adapter middleware can be achieved in various ways, including, but not limited to, the specific embodiments described above.

[0098] Reference Figure 7 According to some embodiments of this application, orchestration control instructions are processed via adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications, including:

[0099] Step S701: Based on the function script program, identify the function instruction type of the arrangement control instructions;

[0100] Step S702: When the function instruction type matches the preset instruction type, execute the target code in the function script program to generate the target orchestration instruction.

[0101] According to some embodiments provided in this application, a function script program refers to a program used to solve the compatibility and adaptation problem between the Kubernetes cloud platform and non-cloud-native applications. It should be understood that a function script program can process orchestration control instructions to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications. In some embodiments of this application, it is necessary to pre-call a preset script program matching the application characteristic information from a preset database based on the application characteristic information, and then further determine the preset script program matching the application characteristic information as a function script program. It should be noted that due to differences in component types, component versions, etc., of non-cloud-native applications, the corresponding preset adaptation information will also be different, and therefore the preset script program corresponding to the preset adaptation information will also be different. Therefore, the preset script program matched from the preset database based on the application characteristic information can convert orchestration control instructions into target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud-native applications. Therefore, the preset script program matched from the preset database is the function script program that can solve the compatibility and adaptation problem between non-cloud-native applications and the Kubernetes cloud platform. It should be clarified that the function instruction type of the orchestration control instructions refers to the category of the orchestration control instructions. For example, when an orchestration control instruction is a control instruction from the Kubernetes cloud platform to orchestrate and deploy non-cloud-native applications so that they can gracefully exit, the corresponding function instruction type is the graceful exit type. As another example, when an orchestration control instruction is a control instruction from the Kubernetes cloud platform to orchestrate and deploy non-cloud-native applications so that they can avoid exposing the acuator service endpoint, the corresponding function instruction type is the local request type. It should be understood that the identification and classification of function instruction types for orchestration control instructions are not limited to the specific embodiments given above.

[0102] It should be noted that the purpose of identifying the function instruction type of the orchestration control instructions is to find the corresponding preset script program from the preset database as the function script program based on the orchestration control instructions, and then further execute the target code in the function script program to generate target orchestration instructions that meet the compatibility and adaptation characteristics of non-cloud native applications.

[0103] Reference Figure 8 According to some embodiments of this application, the preset instruction type is an exit instruction, and the deployment and orchestration of non-cloud-native applications based on target orchestration instructions includes:

[0104] Step S801: Based on the target orchestration instructions, a shutdown warning message is sent to the non-cloud-native application. The shutdown warning message is used to cause the non-cloud-native application to perform data saving operations.

[0105] Step S802: After the data saving operation is completed, control the non-cloud-native application to perform an exit operation.

[0106] According to some embodiments provided in this application, graceful exit refers to an exit mode that cleans up resources, saves necessary intermediate states, and persists memory data before the application shuts down through a pre-notification mechanism. Specifically, in graceful exit mode, when the orchestration control command generated by the Kubernetes cloud platform is an exit command, the orchestration control command is delivered to the adaptation middleware. The adaptation middleware processes the orchestration control command through a functional script program configured according to the application characteristic information, thereby generating a target orchestration command. When a non-cloud-native application is deployed and orchestrated based on the target orchestration command, the non-cloud-native application first receives a shutdown warning message. This shutdown warning message is used to cause the non-cloud-native application to perform a data saving operation. After the data saving operation is completed, the non-cloud-native application is further controlled to perform an exit operation, thereby solving the compatibility and adaptation problem between non-cloud-native applications and the Kubernetes cloud platform regarding graceful exit mode. In some specific embodiments of this application, the condition for determining whether the data saving operation has been completed can be: a pre-set execution time, where the data saving operation is considered complete when the execution time expires; or a pre-set response mechanism in the function script program, where the middleware receives a response signal when the data saving operation is completed, and the receipt of the response signal is considered the completion of the data saving operation. It should be understood that there are multiple ways to determine whether the data saving operation has been completed, including but not limited to the specific embodiments described above.

[0107] Reference Figure 9 The non-cloud-native application orchestration system 900 according to the second aspect of this application includes: a Kubernetes cloud platform 901, an adaptation middleware 902, and a non-cloud-native application 903.

[0108] Kubernetes cloud platform 901 is used to generate orchestration control instructions and obtain application feature information. Based on the application feature information, the adaptation middleware 902 is configured in Kubernetes cloud platform 901. The application feature information is used to identify the compatibility and adaptation features of non-cloud native applications 903.

[0109] The adaptation middleware 902 is used to process orchestration control instructions and generate target orchestration instructions that conform to the compatibility and adaptation characteristics of non-cloud native applications 903. The target orchestration instructions are used to deploy and orchestrate non-cloud native applications 903.

[0110] Non-cloud-native application 903 is used to receive and execute target orchestration instructions.

[0111] Figure 10 An electronic device 1000 provided in an embodiment of this application is shown. The electronic device 1000 includes: a processor 1001, a memory 1002, and a computer program stored on the memory 1002 and executable on the processor 1001. When the computer program is executed, it is used to perform the above-described non-cloud-native application orchestration method.

[0112] The processor 1001 and the memory 1002 can be connected via a bus or other means.

[0113] The memory 1002, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs, such as the non-cloud-native application orchestration method described in the embodiments of this application. The processor 1001 implements the aforementioned non-cloud-native application orchestration method by running the non-transitory software programs and instructions stored in the memory 1002.

[0114] The memory 1002 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function. The data storage area may store non-cloud-native application orchestration methods described above. Furthermore, the memory 1002 may include high-speed random access memory (RAM) and non-transitory memory, such as at least one storage device, flash memory, or other non-transitory solid-state storage device. In some embodiments, the memory 1002 may optionally include remotely located memories 1002 relative to the processor 1001, which can be connected to the electronic device 1000 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0115] The non-transitory software programs and instructions required to implement the above-described non-cloud-native application orchestration method are stored in memory 1002. When executed by one or more processors 1001, the above-described non-cloud-native application orchestration method is executed, for example, executing... Figure 1 Method steps S101 to S104 in the above method Figure 2 Method steps S201 to S202, Figure 4 Method steps S401 to S403, Figure 5 Method steps S501 to S502, Figure 6 Method steps S601 to S602, Figure 7 Method steps S701 to S702, Figure 8 The method steps S801 to S802.

[0116] This application also provides a computer-readable storage medium storing computer-executable instructions for executing the above-described non-cloud-native application orchestration method.

[0117] In one embodiment, the computer-readable storage medium stores computer-executable instructions that are executed by one or more control processors, for example, executing... Figure 1 Method steps S101 to S104 in the above method Figure 2 Method steps S201 to S202, Figure 4 Method steps S401 to S403, Figure 5 Method steps S501 to S502, Figure 6 Method steps S601 to S602, Figure 7 Method steps S701 to S702, Figure 8 The method steps S801 to S802.

[0118] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Those skilled in the art will understand that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, storage device storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium. It should also be understood that the various implementation methods provided in this application can be arbitrarily combined to achieve different technical effects.

[0120] The above provides a detailed description of the preferred embodiments of this application. However, this application is not limited to the above-described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for orchestrating non-cloud-native applications, characterized in that, include: The system acquires orchestration control instructions and application characteristic information. The orchestration control instructions are generated by the Kubernetes cloud platform, and the application characteristic information is used to identify the compatibility and adaptation characteristics of non-cloud-native applications. Different component types or different component versions of non-cloud-native applications correspond to different compatibility and adaptation characteristics. Obtain preset script programs and multiple types of preset adaptation information, wherein the multiple types of preset adaptation information are used to identify various types of compatibility and adaptation features; Based on the preset script programs and various preset adaptation information, various preset script programs are formed; wherein, the internal code of the preset script programs is set according to various compatibility and adaptation requirements; Based on the mapping relationship between the preset script programs and the preset adaptation information, various preset script programs are entered into the preset database; Obtain the preset adaptation information that matches the application characteristic information; Based on the preset adaptation information that matches the application characteristic information, functional script programs are obtained by filtering in the preset database. The functional script programs are the preset script programs that conform to the compatibility and adaptation characteristics of the non-cloud native application. Hook functions are set in the adaptation middleware, and the functional script program is introduced into the adaptation middleware based on the hook functions, and the orchestration control instructions are delivered to the adaptation middleware; The orchestration control instructions are processed by the adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application. The non-cloud-native application is deployed and orchestrated based on the target orchestration instructions.

2. The method according to claim 1, characterized in that, The step of setting hook functions in the adaptation middleware and introducing the functional script program into the adaptation middleware based on the hook functions includes: The hook function is declared in the adaptation middleware; After the hook function is declared, the functional script program is introduced into the adapter middleware via the command in the hook function.

3. The method according to claim 1, characterized in that, The process of processing the orchestration control instructions via the adaptation middleware to generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application includes: Based on the aforementioned functional script program, the functional instruction type of the orchestration control instruction is identified; When the type of the function instruction matches the preset instruction type, the target code in the function script program is executed to generate the target orchestration instruction.

4. The method according to claim 3, characterized in that, The preset instruction type is an exit instruction, and the deployment and orchestration of the non-cloud-native application based on the target orchestration instruction includes: Based on the target orchestration instructions, a shutdown warning message is sent to the non-cloud-native application, which is used to cause the non-cloud-native application to perform a data saving operation. Once the data saving operation is completed, control the non-cloud-native application to perform an exit operation.

5. A non-cloud-native application orchestration system, characterized in that, include: Kubernetes cloud platform, middleware adaptation, non-cloud native applications; The Kubernetes cloud platform is used to generate orchestration control instructions and obtain application characteristic information, and to configure the adaptation middleware in the Kubernetes cloud platform based on the application characteristic information. The application characteristic information is used to identify the compatibility adaptation characteristics of non-cloud-native applications; wherein, non-cloud-native applications of different component types or different component versions correspond to different compatibility adaptation characteristics; preset script programs and multiple types of preset adaptation information are obtained, and the multiple types of preset adaptation information are used to identify various types of compatibility adaptation characteristics; various preset script programs are formed according to the preset script programs and the various types of preset adaptation information; wherein... The internal code of the preset script program is set according to various compatibility and adaptation requirements; based on the mapping relationship between the preset script program and the preset adaptation information, various preset script programs are entered into a preset database; the preset adaptation information that matches the application characteristic information is obtained; based on the preset adaptation information that matches the application characteristic information, functional script programs are selected from the preset database, and the functional script programs are the preset script programs that meet the compatibility and adaptation characteristics of the non-cloud native application; hook functions are set in the adaptation middleware, and the functional script programs are introduced into the adaptation middleware based on the hook functions; The adaptation middleware is used to process the orchestration control instructions and generate target orchestration instructions that conform to the compatibility and adaptation characteristics of the non-cloud-native application. The target orchestration instructions are used to deploy and orchestrate the non-cloud-native application. The non-cloud-native application is used to receive and execute the target orchestration instructions.

6. An electronic device, characterized in that, include: The system includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the non-cloud-native application orchestration method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The storage medium stores a program, which is executed by a processor to implement the non-cloud-native application orchestration method as described in any one of claims 1 to 4.

Images