Method for orchestrating container-based applications on terminal devices

Abstract

The invention relates to a method for orchestrating a computer-based application executed on a terminal device (20), wherein an orchestration slave unit (OSL) on the terminal device (20) receives implementation information from an orchestration master unit (OMA) via a communication connection (30), and the application is configured and / or controlled by the orchestration slave unit (OSL) based on the implementation information, wherein the received implementation information is additionally permanently stored on a memory unit (ME) in the terminal device, and if the communication connection (30) to the orchestration master unit (OMA) is interrupted, the last stored implementation information is called up by the orchestration slave unit (OSL) and the application is configured and / or controlled based on the last stored implementation information.

Description

Technical Field

[0001] The present invention relates to a method and system for orchestrating container-based applications executed on a terminal device. Background Art

[0002] Software applications, also referred to as applications below, are increasingly being implemented using containers on devices such as Internet of Things (IoT) devices or edge devices, which form entry points into service provider networks. In container-based application implementations, application software components, along with libraries and other necessary execution mechanisms, are bundled in one or more containers and executed within the device's native runtime environment. Containerization allows for the management and control of which device system resources are allocated to processes within the container.

[0003] These container-based applications are typically distributed and controlled by a central management system (e.g., an orchestration system like Kubernetes). This orchestration system orchestrates the running worker processes in containers, which run on nodes, such as physical or virtual machines, in a cluster. A cluster with its own nodes is controlled by a dedicated orchestration master (e.g., a Kubernetes master), which distributes and manages the containers across the nodes. To do this, the orchestration master communicates with orchestration slaves (e.g., Kubelet programs) on each individual node in a master-slave relationship known in information technology. These orchestration slaves are responsible for the node's status. They are controlled by a controller manager in the orchestration master and are responsible for starting and stopping containers. These orchestration slaves report their status to the orchestration master at short intervals. If a node fails or is unreachable, the orchestration master detects this by not reporting its status. The controller manager then typically restarts the container, but on another "available" node.

[0004] Therefore, a typical use case for container-based applications is an architecture where the device on which a container runs is irrelevant and containers can be run and scaled arbitrarily across a variety of devices. By assigning containers to individual devices using so-called node selectors, applications and their configuration on the containers can still be managed in a device-specific manner. A persistent connection between the orchestration master and orchestration slaves on the device is essential for the smooth operation of such container-based applications.

[0005] In particular, for mobile IoT devices installed in trains or cars, permanent connectivity between the device and the orchestration master cannot be guaranteed. This connection can also fail for extended periods of time. This interruption can be caused by a failure of the orchestration master or by an interruption and subsequent stop of the transport connection itself. If the transport connection itself is interrupted and thus stopped, the terminal device is completely isolated from the supporting network containing, for example, the server that communicates with the application, and is therefore unable to send data to the application's network-side interfaces (e.g., reporting systems). In the event of either type of interruption, a device restart results in a loss of information about which container-based components should be started on the terminal device. This is because the orchestration master retrieves information to restart the orchestration slave installed on the device when the device or the component itself starts up. This behavior is due to the fact that in typical application areas of container virtualization, such as cloud computing, the Kubernetes master outsources resources to other terminal devices when a terminal device becomes unavailable.

[0006] In the context of the Internet of Things, this outsourcing option is usually not available because most container entities only run on one device. As a result, safety-critical applications that must be highly available cannot be provided as container-based applications. Summary of the Invention

[0007] The object of the present invention is therefore to create an orchestration system or an orchestration method in which the provided services continue to be executed without interruption even when there is no connection between the orchestration host and the terminal device.

[0008] This object is achieved by the measures described in the independent claim. Advantageous developments of the invention are indicated in the dependent claims.

[0009] According to a first aspect, the present invention relates to a method for orchestrating a computer-based application to be executed on a terminal device, wherein implementation information is received from an orchestration master unit in an orchestration slave unit on the terminal device via a communication connection, and the application is configured and / or controlled by the orchestration slave unit based on the implementation information, wherein the received implementation information is additionally permanently stored on a storage unit in the terminal device, and if the communication connection with the orchestration unit is interrupted, the last stored implementation information is called by the orchestration slave unit, and the application is configured and / or controlled based on the last stored implementation information.

[0010] An end device is a dedicated device on which applications execute, such as an Internet of Things (IoT) device or edge device. This is distinguished from a device or system composed of multiple components that can execute applications on any one or more of these components. An orchestration master, such as a Kubernetes master, is located in a unit physically separate from the end device, such as a component of a control network. Container-based applications communicate with application-specific units in the control network, for example, to exchange application data. To orchestrate these container-based applications, the orchestration master communicates with orchestration slaves via a communication connection. If the communication connection to the orchestration master is interrupted, this could be due to, for example, the orchestration master being unavailable or the communication connection itself failing. There are two possible reasons for interrupting the communication connection. Implementation information, also known as deployment information, is actively transmitted from the orchestration master to the orchestration slaves. This implementation information is only changed when an administrator makes changes related to the application on the orchestration master. The implementation information is then transmitted from the orchestration master to the orchestration slaves.

[0011] Because the received implementation information is persistently, i.e., non-volatilely, stored in the storage unit of the terminal device, the information can be retrieved locally by the orchestration slave unit on the terminal device, and the application can be reactivated or maintained even if the connection with the orchestration master unit is lost. This ensures the continuous availability of the application. Thus, safety-critical services that must be available on the terminal device with a high degree of fail-safety can also be provided on a container-based basis. If the communication connection is intact, the orchestration slave unit can retrieve the implementation information from the orchestration master unit in the event of an application failure on the terminal device.

[0012] In an advantageous embodiment, if the communication connection with the orchestration master unit is interrupted and at least one container entity on the terminal device fails, the orchestration slave unit restarts the at least one container entity based on the latest stored implementation information.

[0013] Typically, orchestration slaves restart container entities based on received messages only after feedback from the orchestration master. By persistently storing implementation information on the storage unit, orchestration slaves can now independently and promptly restart corresponding container entities. A container entity is a specific container execution environment with a corresponding application. This specific container execution environment is described by the implementation information based on a container image (also called a container image).

[0014] In an advantageous embodiment, if the communication connection with the orchestration master unit is interrupted and the terminal device is restarted, the orchestration slave unit starts the application based on the most recently stored implementation information.

[0015] This makes it possible to reactivate the application on a terminal device even when the terminal device is restarted, not just when the application fails while it is running. Thus, the terminal device can be started from a switched-off state without being connected to the orchestration master unit and reconfigured and started again by the orchestration slave unit based on the stored implementation information. In the conventional operating mode between orchestration master and orchestration slave units, the application would not be started on the terminal device because the implementation information would also be deleted when the terminal device is switched off, and due to the lack of a communication connection, no new implementation information would be received from the orchestration master unit in the orchestration slave unit. This modified behavior can be implemented, for example, via a dedicated orchestration slave "plug-in" in the terminal device.

[0016] In an advantageous embodiment, the prioritized container entity is identified as "prioritized" by the orchestration master when creating the implementation information.

[0017] This makes it possible, for example, to identify a security-related container entity as a prioritized container entity. During application runtime, the prioritized container is identified and preferentially re-instantiated and restarted by the orchestration slave unit, particularly temporarily and temporally relative to other containers. For example, such a prioritized container entity can be identified by a tag in the implementation information. This also allows for the implementation of high-availability applications, such as security-related applications, in a container-based manner.

[0018] In an advantageous embodiment, at least one emergency container image is stored in the storage unit, which performs at least one function, which is executed by an application interface connected to the terminal device via the communication connection when a communication connection exists.

[0019] Thus, all data and / or messages sent from container-based applications in the terminal device to an application interface located locally separately from the terminal device while a communication connection exists are stored. This allows processing in a form familiar to the application, for example, in a backend system or distributed server system, or even in a control network, after the communication connection with the application interface is reestablished. Messages or information sent from the orchestration slave unit to the orchestration master unit can also be stored in the emergency container entity and transmitted to the orchestration master unit when the communication connection with the orchestration master unit is reconnected and active. This makes it possible to subsequently check whether components have been frequently restarted locally and whether emergency mode has been activated.

[0020] In an advantageous embodiment, the orchestration slave unit changes the configuration and / or control of the application according to emergency guidelines received from the orchestration master unit.

[0021] The emergency instructions are a component of the implementation information and are permanently stored in the storage unit together with the implementation information. The emergency instructions are an additional component of the implementation information. For example, the emergency instructions define when to activate various emergency measures. For example, a time interval after a network failure can be defined, from which the emergency action can be initiated.

[0022] In an advantageous embodiment, the orchestration slave unit starts the at least one emergency container entity and / or stops the at least one working container entity of the application according to emergency guidelines.

[0023] The emergency container entity can, for example, temporarily store or process the determined sensor data. This is performed by an application interface connected to the terminal device while a communication connection is active. By stopping the operating container, resources can be freed up and, for example, allocated to the emergency container entity. This allows container-based applications to run as uninterrupted as possible and in a manner consistent with normal execution.

[0024] In an advantageous embodiment, the emergency guidelines comprise different level guidelines and, depending on the determined emergency level, the level guide assigned to the emergency level is activated by the orchestration slave unit.

[0025] For example, the level guides can be identified by means of different identifiers (so-called tags). This enables the terminal to react in a manner that is adapted to the respective situation and is therefore very flexible, and enables the application to be designed flexibly in emergency situations.

[0026] In an advantageous embodiment, the emergency level is determined as a function of the duration and / or the type of failure of the communication connection and / or the master orchestration unit.

[0027] This allows for the definition of multiple escalation levels depending on the duration and type of failure, and for the introduction of corresponding measures.

[0028] In an advantageous embodiment, further emergency container entities are activated according to the assigned level guidelines and / or different amounts of resources are allocated to the at least one emergency container entity for the duration of the determined emergency level.

[0029] By adapting the resources, the application can be kept running at a normal level even if the communication connection or the orchestration master unit fails for a long time.

[0030] In an advantageous embodiment, existing container entities that are not necessary for emergency operation are stopped, paused or their resource distribution is changed according to the assigned level guidelines, and thus the resources that have become free are allocated to the emergency container entity.

[0031] This allows the application to run flexibly and adaptably in emergency situations. The corresponding container image in the implementation information can be changed, for example, the allocated CPU quota can be reduced.

[0032] In an advantageous embodiment, after the communication connection has been re-established, the data collected in the emergency container entity are transmitted to an application interface connected to the terminal device via the communication connection.

[0033] Thus, data, information, or messages generated or collected during emergency operation or during a failure of the communication connection with the orchestration master unit are not lost and can be analyzed or processed in the application interface, for example, in a backend cloud environment or in a control node of the control network. For example, measures can be derived from the transmitted data and executed.

[0034] In an advantageous embodiment, after the communication connection is reestablished, the orchestration slave unit receives a normal operation instruction from the orchestration master unit and the terminal device switches to a normal state, thereby allowing container-based applications on the terminal device to switch to a common execution environment and execution type.

[0035] A second aspect of the present invention relates to a system for orchestrating container-based applications executed on a terminal device, the system comprising a terminal device including an orchestration slave unit, and an orchestration master unit connected to the terminal device via a communication connection, the system being configured to:

[0036] - receiving, in the orchestration slave unit, implementation information from the orchestration master unit via the communication connection,

[0037] - configuring and / or controlling the application by the orchestration slave unit based on the implementation information, wherein

[0038] - the received implementation information is additionally permanently stored on a storage unit of the terminal device, and

[0039] - If the communication connection is interrupted, the orchestration slave unit calls up the last stored implementation information and configures and / or controls the application based on the last stored implementation information.

[0040] Such a system allows container-based applications, in particular those that perform safety-critical or operationally reliable functions, to be implemented on specific, permanently predefined end devices, since even if the communication link fails, the application's operation can continue and thus be guaranteed. This can be achieved, for example, via a "plug-in" that is directly programmed in the end device.

[0041] A third aspect of the invention relates to a computer program product comprising a non-volatile computer-readable medium directly loadable into a memory of a digital computer, said computer program product comprising program code portions adapted to perform the steps of the method.

[0042] The corresponding units (e.g., the orchestration master unit, the orchestration slave unit, or also the storage unit) can be implemented in hardware and / or software. In the case of hardware implementation, the corresponding unit can be configured as a device or part of a device, such as a computer or microprocessor or a vehicle control computer or part of a control computer. In the case of software implementation, the corresponding unit can be configured as a computer program product, a function, a routine, a part of a program code, or an executable object. In the context of the present invention, the storage unit can be, for example, a hard disk or other storage medium capable of permanently storing data.

[0043] The computer program product (eg computer program means) can be provided or delivered, for example, as a memory card, USB memory stick, CD-ROM, DVD or also in the form of a file that can be downloaded from a server in a network. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Exemplary embodiments of the method according to the invention and the system according to the invention are shown by way of example in the drawings and are explained in more detail based on the following description.

[0045] Figure 1 An example of a known architecture for managing container-based applications provided to service users by one or more servers is schematically shown;

[0046] Figure 2 An example of a container-based application executed on a predetermined terminal device is shown schematically;

[0047] Figure 3 A first embodiment of the method according to the present invention is shown in the form of a flow chart;

[0048] Figure 4 An embodiment of a system according to the present invention is shown in a block diagram; and

[0049] Figure 5A second embodiment of the method according to the present invention is shown in the form of a message flow.

[0050] In all the figures, components that correspond to one another are provided with the same reference numerals. DETAILED DESCRIPTION

[0051] Figure 1 This diagram shows a typical architecture for managing a computer-implemented application from a server 1, which is provided to its users by one or more nodes 2 and 3. The application is executed by program components provided in one or more containers. Containers, or container virtualization, are a method for running multiple instances of an operating system isolated from one another on a host system. For management or container management, orchestration programs such as Kubernetes are often used. These orchestration programs control the automated distribution, scaling, and maintenance of containers across distributed host systems (the so-called nodes 2 and 3).

[0052] Figure 1 An orchestration master OMA is shown, which distributes and manages containers to the various nodes 2, 3. The orchestration master OMA decides which of the nodes 2, 3 to start which container on, based on the available resources. The orchestration master OMA manages the containers arranged on the nodes 2, 3 and monitors the load of these containers. To this end, the orchestration master OMA provides implementation information to the various nodes 2, 3, which the corresponding orchestration slave units OSL receive in the nodes 2, 3 and forward to the runtime environment for executing the containers. In addition to the scheduler contained in the orchestration master OMA, messages are distributed from the orchestration master OMA to the different nodes 2, 3 via the load distributor 4. The orchestration master is, for example, arranged in the control unit of the backend system 1. For such a service or such an architecture, what is important is not on which node 2, 3 the container runs, but rather that these containers are arbitrarily distributed to the various nodes and can be scaled.

[0053] Nevertheless, by fixedly assigning a container to a node using a so-called node selection identifier (also called a node selector), container-based applications can be managed in a device-specific manner. Figure 2 An application scenario is shown in which a service is executed on an end device (here, for example, installed in a vehicle 6 ). To this end, the end device (here, for example, vehicle 6 ) includes an orchestration slave unit OSL, which receives control information for individual containers from an orchestration master unit OMA via a communication connection 7 . The orchestration master unit OMA is, for example, located in a control unit in a backend server 5 of a service provider. The described application can be implemented in particular in an IoT device that communicates autonomously with the orchestration master unit OMA via the communication connection 7 .

[0054] In particular, when a terminal device is connected to the backend system 5 via a radio interface, a permanent connection to the orchestration master OMA cannot be assumed; rather, this connection may fail for extended periods of time. This interruption in connection may be caused by a failure of the orchestration master OMA or by a failure of the communication connection 7. This is particularly the case in the case of a terminal device due to an insufficient or missing radio connection. As a result, the terminal device 6 is completely isolated from the backend server 5 and cannot send data to existing reporting systems. For both types of connection interruption, restarting the terminal device or the application results in a loss of information about which container-based application components should be started on the terminal device.

[0055] The method and system described below allow computer-based applications to continue executing even when both types of connections are interrupted. To this end, the orchestration slave OSL, which runs on the terminal device for orchestration, persistently stores the last known implementation information obtained from the orchestration master OMA on the terminal device. When the terminal device restarts, if the connection to the orchestration master OMA is lost, the last known implementation information is activated.

[0056] Now based on Figure 3 The method is explained in more detail. In a first method step S1, implementation information is received in the orchestration slave unit OSL from the orchestration master unit OMA via a communication connection. In a method step S2, the application is configured and / or controlled by the orchestration slave unit OSL based on the implementation information. In a subsequent step S3, the received implementation information is additionally stored permanently on a storage unit in the terminal device, i.e. permanently and continuously available on a storage unit in the terminal device even when the terminal device is switched off. If the terminal device determines in step S4 that the communication connection with the orchestration master unit OMA is interrupted, the orchestration slave unit OSL calls up the last stored implementation information from the storage unit, see S5. The application is configured and / or controlled based on the last stored implementation information, see S6. If it is determined in the terminal device that a communication connection with the orchestration master unit OMA is present, see Figure 3 As shown in the arrow n, the orchestration slave unit OSL continues to receive control information from the orchestration master unit OMA and executes the control information accordingly.

[0057] Application-specific information or data collected by the application is also transmitted to the orchestration master OMA or an application-specific interface via the existing communication connection. If the application in the terminal device crashes or terminates, the orchestration master OMA can retransmit the implementation information to the orchestration slave OSL while the communication connection is still available, and restart the application in the terminal device. The received implementation information is then processed again according to method steps S1-S3, and the new implementation information is permanently stored in the storage unit. As a result, the storage unit of the terminal device always contains the latest, current implementation information.

[0058] The implementation information particularly includes a container image, which includes the operations and files of the application components that the container should execute. When necessary, the orchestration slave unit OSL starts one or more container entities that are configured and executed according to the container image. If the container entity on the terminal device fails and the communication connection with the orchestration master unit OMA is interrupted, the container entity is started based on the last stored implementation information. There is no need to wait for feedback from the orchestration master unit OMA, or only wait for a specific maximum duration. For example, this changed behavior can be implemented by a plug-in in the orchestration slave unit OSL.

[0059] To ensure uninterrupted provisioning of safety-critical container entities, including safety-critical application modules, these entities are identified by a special identifier (e.g., a tag) during creation on the orchestration master. These prioritized container entities can then be prioritized by the orchestration slave unit OSL in the event of a connection interruption. To this end, at least one emergency container image is stored in the storage unit. This emergency container image performs at least one function that, when a communication connection is established, is executed via an application interface connected to the terminal device via the communication connection.

[0060] Furthermore, the orchestration slave OSL changes the configuration and transition control of the application based on the emergency guidelines received from the orchestration master OMA. The emergency guidelines are preferably included in the implementation information and can therefore also be changed with each implementation information. The emergency guidelines are thus also permanently stored in the storage unit and are therefore available on the terminal device in the event of a failure of the communication link with the orchestration master OMA.

[0061] The orchestration slave unit OSL can then start at least one emergency container entity and / or stop at least one working container entity of the application according to the emergency guidelines. For example, the emergency guidelines can stop individual, in particular non-critical working container entities and start the first or other emergency container entities according to the time elapsed since the failure of the communication connection.

[0062] The emergency guidelines can include different level guidelines. The level guidelines thus form a hierarchy of guidelines that are activated by the orchestration slave unit OSL depending on the type and duration of the emergency, which in turn is assigned to a specific emergency level. In addition to the duration of the failure of the communication connection, the emergency level can also be determined based on the type of failure of the communication connection and / or the type of failure of the orchestration master unit OMA. For example, different emergency levels can exist or be assigned in the event of a failure of the communication connection itself, while another emergency level can exist or be assigned in the event of a failure of the orchestration master unit OMA. Depending on the duration or combination of failures, further different emergency levels can be assigned. One or more emergency levels can in turn be assigned to one or more level guidelines. Based on the level guidelines, further emergency container entities can be activated, or different amounts of resources can be allocated to already existing emergency container entities for the duration of the determined emergency level.

[0063] After the communication connection itself is re-established or the orchestration master OMA is re-established or available, the data collected in the at least one emergency container entity is transmitted to the application interface. Thus, the data collected in the emergency container entity during the failure period is not lost and can be received and analyzed or forwarded by the back-end application interface. After the communication connection is re-established, the normal operation guide is received from the orchestration master OMA in the orchestration slave unit OSL, and the terminal device switches to a normal state. However, the at least one emergency guide remains available in the storage unit, allowing the terminal device to continue to run the application independently if the connection to the orchestration master OMA is interrupted again.

[0064] exist Figure 4 An embodiment of a system for orchestrating container-based applications is shown in FIG. The system comprises a terminal device 20 and an application interface 10 connected to the terminal device. The application interface 10 comprises an orchestration master unit OMA and an application-specific unit App-If, in which data determined by an application on the terminal device, for example, is received and further processed. The application interface 10 also comprises a send and receive interface TR, which receives data from the terminal device 20 or sends data to the terminal device 20. The communication interface is shown as a radio interface 30, for example. Logically, the communication between the application interface 10 and the terminal device 20 can be divided into the communication between the orchestration master unit OMA and the orchestration slave unit OSL of the container-based application, see connection 32, and the communication between, for example, a working container AC in the terminal device 20 and the application-specific unit App-If in the application interface 10, see 31.

[0065] The terminal device 20 includes an orchestration slave unit (OSL), which in turn forwards instructions to the runtime environment (CRE). The runtime environment (CRE) configures and starts a working container entity (AC) according to the instructions from the orchestration slave unit (OSL). If an emergency level exists and the corresponding emergency guidelines are active, the corresponding emergency container (NC) is configured and started.

[0066] The terminal device 20 also includes a storage unit ME, in which implementation information received by the orchestration slave unit OSL from the orchestration master unit OMA is persistently stored. The terminal device 20 can be, for example, a mobile terminal device, such as one installed or deployed in a vehicle or train. The terminal device 20 can also be a field device or other component in an automation facility, connected to a control device via a wired connection (particularly a wired data network), in which the application interface 10 is located. Typically, the communication interface can be a radio transmission link, a wired communication connection, an optical fiber connection, or the like.

[0067] Figure 5 The information flows exchanged between the orchestration master OMA and the terminal device 20 for controlling and configuring container-based applications are shown. The components of the terminal device 20 relevant to the management of container-based applications are the orchestration slave OSL, the runtime environment CRE, and the storage unit ME. Implementation information DI is transmitted from the orchestration master OMA to the orchestration slave OSL in the terminal device 20. In addition to information Anw required for the normal operation of the application, the implementation information DI also includes an emergency guide NR and an optional emergency container image NC. After being received in the terminal device 20, the implementation information DI is persistently, i.e., non-volatilely, stored in the storage unit ME (see 40).

[0068] If a failure of the communication connection or of the connection to the orchestration master OMA is detected in the terminal device 20, see 41, the orchestration slave OSL requests the stored implementation information DI and in particular the emergency guideline NR and the emergency container image NC, see 42. Furthermore, the necessary emergency container entities are executed based on the emergency guideline NR or configuration changes are performed in existing working container entities and emergency container entities via the runtime environment CRI.

[0069] The emergency guidelines NR can be configured to implement different emergency measures based on different emergency levels, which are assigned depending on the duration and type of the connection failure. In addition to launching a temporary emergency container entity, the emergency container entity can also be provided with increased resources, such as processor time or local memory, for the duration of the failure. Non-emergency-related and locally stored container images can be deleted after a time interval for providing resources to the emergency container entity has expired, or ongoing container entities can be stopped. These measures are also predetermined by the emergency guidelines or the corresponding level guidelines.

[0070] Once a communication connection with the network is established again, the data collected and temporarily stored, for example, in the emergency container entity, can be returned to the application interface. This frees up resources available for emergency operations. Finally, if necessary, updated emergency guidance is received from the orchestration master OMA in the orchestration slave OSL, and the terminal device 20 switches to the normal state, see 43.

[0071] The described solution does not require an orchestration master (OMA) located on the terminal device 20 itself. This allows resources in the terminal device 20 to be saved or used to run applications. The proposed emergency guidance NR allows emergency measures to be taken autonomously on the terminal device 20 based on the duration and type of the failure. For example, increased resources or alternative resources can be temporarily allocated to core components. Safety measures taken on the terminal device 20 can be reinforced in a time-controlled manner (e.g., as the duration of the failure progresses) using the emergency guidance. Central management and software provisioning mechanisms are retained.

[0072] Within the scope of the invention, all described and / or illustrated features can be advantageously combined with one another. The invention is not restricted to the exemplary embodiments described.

Claims

1. A method for orchestrating container-based applications for execution on a terminal device (20), wherein - receiving (S1) implementation information (DI) in the orchestration slave unit (OSL) on the terminal device from the orchestration master unit (OMA) via a communication connection (30), and - configuring and / or controlling (S2) the application by the orchestration slave unit (OSL) based on the implementation information (DI), wherein - the received implementation information (DI) is additionally permanently stored (S3) on a memory unit (ME) in said terminal device, and - if the communication connection (30) with the orchestration master unit (OMA) is interrupted (S4), calling (S6) the last stored implementation information (DI) by the orchestration slave unit (OSL) and configuring and / or controlling (S6) the application based on the last stored implementation information (DI), in, The orchestration slave unit (OSL) changes the configuration and / or control of the application according to the emergency guidelines received from the orchestration master unit (OMA), The orchestration slave unit (OSL) starts at least one emergency container entity (NC) and / or stops at least one working container entity (AC) of the application according to the emergency guideline, and The emergency guide (NR) includes different level guides, and according to the determined emergency level, the orchestration slave unit (OSL) activates the level guide assigned to the emergency level.

2. The method according to claim 1, wherein If the communication connection (30) with the orchestration master unit (OMA) is interrupted and at least one container entity on the terminal device (20) fails, the orchestration slave unit (OSL) restarts the at least one container entity based on the latest stored implementation information (DI).

3. A method according to any one of the preceding claims, wherein If the communication connection (30) with the orchestration master unit (OMA) is interrupted and the terminal device (20) is restarted, the application is started by the orchestration slave unit (OSL) based on the last stored implementation information (DI).

4. The method according to claim 1 or 2, wherein: The prioritized container entity is identified as "prioritized" by the orchestration master (OMA) when creating the implementation information (DI).

5. The method according to claim 1 or 2, wherein: At least one emergency container image is stored in the storage unit (ME), and the emergency container image (NC) performs at least one function, and when a communication connection (30) exists, the at least one function is performed by an application interface (10) connected to the terminal device (20) via the communication connection (30).

6. The method according to claim 1 or 2, wherein: The emergency level is determined based on the duration and / or the type of failure of the communication connection (30) and / or the master orchestration unit (OMA).

7. The method according to claim 1 or 2, wherein: At least one other emergency container entity (NC) is activated according to the assigned level guidelines and / or a different amount of resources is allocated to the at least one emergency container entity (NC) for the duration of the determined emergency level.

8. The method according to claim 1 or 2, wherein: According to the assigned level guideline, existing container entities (AC) unnecessary for emergency operation are stopped, paused, or their resource distribution is changed, and thus the resources that become free are allocated to the emergency container entity (NC).

9. The method according to claim 5, wherein: After the communication connection (30) is re-established, the data collected in the emergency container entity (NC) is transferred to the application interface (10).

10. The method according to claim 1 or 2, wherein: After the communication connection (30) is re-established, a normal operation instruction is received from the orchestration master (OMA) in the orchestration slave (OSL) and the terminal (20) switches to a normal state.

11. A system for orchestrating a container-based application executed on a terminal device (20), the system comprising a terminal device (20) comprising an orchestration slave unit (OSL) and an orchestration master unit (OMA) connected to the terminal device (20) via a communication connection (30), the terminal device (20) and the orchestration master unit (OMA) being configured to: - receiving, in said orchestration slave unit (OSL) via said communication connection (30), implementation information (DI) from said orchestration master unit (OMA), - configuring and / or controlling the application by the orchestration slave unit (OSL) based on the implementation information (DI), wherein - the received implementation information (DI) is additionally permanently stored on a storage unit (ME) in said terminal device (20), and - if the communication connection (30) is interrupted, calling up the last stored implementation information (DI) by the orchestration slave unit (OSL) and configuring and / or controlling the application based on the last stored implementation information (DI), in, The orchestration slave unit (OSL) changes the configuration and / or control of the application according to the emergency guidelines received from the orchestration master unit (OMA), The orchestration slave unit (OSL) starts at least one emergency container entity (NC) and / or stops at least one working container entity (AC) of the application according to the emergency guideline, and The emergency guide (NR) includes different level guides, and according to the determined emergency level, the orchestration slave unit (OSL) activates the level guide assigned to the emergency level.

12. Computer program product comprising a non-volatile computer-readable medium directly loadable into the memory of a digital computer, said computer program product comprising program code portions adapted to perform the steps of the method according to any one of claims 1 to 10.

Images