JP2022135765A - Device and method for determining pod, terminal apparatus, edge server, server, container system, and program - Google Patents

Abstract

To allow the arrangement of a pod with network situations and resource situations taken in consideration.SOLUTION: A first local MANO(43) determines whether a first pod (81) is to be arranged in a first worker node (52) of a first MEC server (5) on the basis of a network situation regarding a first base and a resource situation of the first MEC server (5) stored in a first local data store (44) and a requirement item for a network required by the first pod (81) and a requirement item for a resource.SELECTED DRAWING: Figure 1

Description

The present invention relates to a pod placement determination device, a pod placement determination method, a terminal device, an edge server, a server, a container system, and a program.

When an application is executed on various terminal devices such as personal computers and mobile phones, it is possible to efficiently execute the application by having the cloud server existing in the network execute the modules that make up the application and have a large load. It could work well. This form of execution is called offloading. However, the communication delay between the terminal device and the cloud server is generally large, so there is a possibility that the response time of the application will be long. Therefore, conventionally, by placing an MEC (Multi-access Edge Computing) server near the network connection point (edge) of the terminal device, the communication delay between the terminal device and the MEC server can be reduced, and the application can be delivered to the MEC server. It has been proposed to reduce application response time by offloading some functions.

In addition, an application (client-server type application) in which an application (client) operating on a terminal device and an application (server application) operating on a cloud server communicate with each other is also widely used. Even in such an application, communication delay can be reduced when the client communicates with the MEC server rather than with the cloud server.

There are two types of virtualization technology for physical computers: hypervisor type and container type. Container-type virtualization technology is lighter than hypervisor-type virtualization technology because the kernel of the operating system is shared between containers. Furthermore, it has become common to realize various modules that constitute an application as containers, respectively, and configure the application as an aggregation of multiple containers.

A system that automatically creates, arranges, scales, and monitors the status of containers is generally called a container orchestration system. Non-Patent Document 1 discloses Kubernetes known as a typical container orchestration system. In a container orchestration system, a pod containing one or more containers is often the smallest managed object. In a container orchestration system, a master node and worker nodes are arranged as virtual machines on a computer cluster such as a data center, and one master node and one or more worker nodes constitute a container orchestration cluster. Considering high availability and load balancing within a container orchestration cluster, a pod cluster is configured by a master node placing pods on worker nodes.

"Kubernetes (K8s)", [online], [searched on February 25, 2021], Internet <https://kubernetes.io/ja/>

A typical container orchestration system considers the load of worker nodes when determining container placement. However, since network conditions are not taken into consideration, there is a risk that each pod will be placed on each worker node under bad network conditions (such as large communication delays). Also, since the resource status of worker nodes is not taken into account, there is a possibility that pod installation on worker nodes will fail.

The present invention has been made to solve the above-mentioned problems, and its object is to enable pod placement in consideration of both network conditions and worker node resource conditions.

In order to solve the above-described problems, a pod placement determination apparatus according to an aspect of the present invention provides a first edge server having a first worker node, a first edge server having a first worker node, and a first edge server having a first worker node. a measuring unit for measuring a network status during communication to a second base where two edge servers are arranged; a first receiving unit for receiving the resource status of the first worker node measured by the first edge server; a storage unit for storing received network conditions and received resource conditions; a request for a network requested by a first pod constituting an application as a container orchestration cluster and a request for a resource requested by the first pod; the first pod based on the stored network and resource conditions and the received network and resource requirements; and a decision unit for deciding whether to place it in the worker node.

According to one aspect of the present invention, it is possible to arrange pods in consideration of both network conditions and worker node resource conditions.

1 is a diagram illustrating a configuration example of a container system according to a first embodiment; FIG. FIG. 4 is a sequence diagram showing the flow of a series of processes executed by the container system when the container system measures network conditions and resource conditions; FIG. 10 is a diagram showing an example of a network status notification message; FIG. FIG. 10 is a diagram showing an example of a resource status notification message; FIG. FIG. 10 is a diagram showing an example of a site status notification message; FIG. FIG. 4 is a sequence diagram showing the flow of a series of processes executed by the container system when the terminal device activates the application; FIG. 10 is a diagram showing an example of an application activation request message; FIG. FIG. 10 is a diagram showing an example of an application configuration information request message; FIG. FIG. 10 is a diagram showing an example of an application configuration information response message; FIG. 10 is a diagram showing an example of a pod placement determination request message; FIG. 10 is a diagram showing an example of a pod placement determination request message; FIG. 10 is a diagram showing an example of a pod placement determination response message; FIG. 10 is a diagram showing an example of a pod placement determination response message; FIG. 10 is a diagram showing an example of a pod placement request message; FIG. 10 is a diagram showing an example of a pod placement request message; FIG. 10 is a diagram showing an example of a pod placement response message; FIG. 10 is a diagram showing an example of a pod placement request message; FIG. 10 is a diagram showing an example of a pod placement response message; FIG. 10 is a diagram showing an example of a pod placement request message; FIG. 10 is a diagram showing an example of a pod placement response message; FIG. 10 is a diagram showing an example of a pod placement response message; It is a figure which shows an example of an application starting response message. FIG. 4 is a sequence diagram showing a series of processes executed when the container system stops an application; It is a figure which shows an example of an application stop request message. FIG. 10 is a diagram showing an example of a pod stop request message; FIG. 10 is a diagram showing an example of a pod stop response message; It is a figure which shows an example of an application stop response message. FIG. 10 is a diagram showing an example of a measurement request message; FIG. FIG. 10 is a diagram showing an example of a measurement request message; FIG. FIG. 10 is a diagram showing an example of a measurement request message; FIG. FIG. 10 is a diagram showing an example of a measurement request message; FIG. FIG. 10 is a diagram showing an example of a measurement request message; FIG. FIG. 11 is a block diagram showing the configuration of a container system according to a second embodiment; FIG. FIG. 4 is a sequence diagram showing the flow of a series of processes executed by the container system when the terminal device activates the client App; It is a figure which shows an example of an application request message. FIG. 10 is a diagram showing an example of a pod placement request message; FIG. 10 is a diagram showing an example of a pod placement response message; It is a figure which shows an example of an application response message. FIG. 10 is a sequence diagram showing the flow of a series of processes executed by the container system when stopping the server application;

[Embodiment 1]
(System configuration)
FIG. 1 is a diagram showing a configuration example of a container system 1 according to the first embodiment. As shown in this figure, the container system 1 includes a terminal device 2, a cloud server 3 (server), a first base device 4 (pod placement determination device), a plurality of first MEC (Multi-access Edge Computing) servers 5 (second 1 edge server), a second base device 6 (second pod placement determination device), and a plurality of second MEC servers 7 (second edge servers). These devices are communicably connected to each other via a network. A so-called cloud is arranged in the network. The cloud server 3 is arranged in the cloud. Two different first and second sites are illustrated in FIG. A site is a physical location located near a connection point where the terminal device 2 connects to the network by wire or wirelessly. In FIG. 1, the terminal device 2 is located closer to the first site than to the second site. Assume that the identifiers of the first site and the second site are BaseID1 and BaseID2, respectively.

The terminal device 2 includes a preference repository 21, an image repository 22, and a startup App 23 (startup module). The terminal device 2 also functions as a third worker node.

The cloud server 3 includes a global MANO (Management and Orchestration) 31 (first server reception unit, second server reception unit, second determination unit), a global data store 32 (server information storage unit), and an origin image repository 33. ing.

A first base device 4 and n (n is an integer equal to or greater than 1) first MEC servers 5 are arranged at the first base. The first base device 4 includes a first master node 41, a first network monitor 42 (measuring unit, first network status measuring unit), a first local MANO 43 (second receiving unit, determining unit), a first local data store 44 (first receiver, storage, first transmitter), first local image repository 45 (image storage), and first App API 46 . Let the identifiers of these modules be MnID1, NmonID1, LManoID1, LdsID1, LirID1, and AppApiID1, respectively. Each first MEC server 5 includes a first resource monitor 51 (measuring unit, resource status measuring unit, first resource status measuring unit, first resource status transmitting unit), first worker node 52, and fourth worker node 53. . Let the identifiers of these modules be RmonID1, WnID1, and WnID4, respectively.

A second base device 6 and m (m is an integer equal to or greater than 1) second MEC servers 7 are arranged at the second base. The second base device 6 includes a second master node 61, a second network monitor 62 (second network status measurement unit), a second local MANO 63, a second local data store 64 (second reception unit, storage unit, second transmission department), a second local image repository 65 and a second App API 66 . Let the identifiers of these modules be MnID2, NmonID2, LManoID2, LdsID2, LirID2, and AppApiID2, respectively. Each second MEC server 7 comprises a second resource monitor 71 (second resource status measuring section, second resource status transmitting section), a second worker node 72 and a fifth worker node 73 . Let the identifiers of these modules be RmonID2, WnID2, and WnID5, respectively.

In this embodiment, the first base device 4 is one independent physical machine. A first master node 41 as a virtual machine is set in the first base device 4 . Not limited to this, the first master node 41 may operate as an individual physical machine. Also, each first MEC server 5 is an independent physical machine. A first worker node 52 and a fourth worker node 53 as virtual machines are arranged in each first MEC server 5 . Not limited to this, the first worker node 52 and the fourth worker node 53 may operate as individual physical machines.

In this embodiment, the second base device 6 is one independent physical machine. A second master node 61 as a virtual machine is set in the second base device 6 . Not limited to this, the second master node 61 may operate as an individual physical machine. Also, each second MEC server 7 is an independent physical machine. A second worker node 72 and a fifth worker node 73 as virtual machines are arranged in each second MEC server 7 . Not limited to this, the second worker node 72 and the fifth worker node 73 may operate as separate physical machines.

Each master node and each worker node described above constitute one container orchestration cluster as needed. In the example of FIG. 1, the first master node 41, the third worker node (terminal device 2), the first worker node 52, and the second worker node 72 constitute one container orchestration cluster. Also, although not shown, the second master node 61, the first worker node 52, and the fifth worker node 73 constitute another container orchestration cluster. Thus, the first worker node 52 belongs to two different container orchestration clusters.

FIG. 1 shows the arrangement of pods when the user of the terminal device 2 activates a predetermined application near the first site. In this example, an application as a container orchestration cluster consists of four pods including a first pod 81, a second pod 82, a third pod 83, and a relay pod (not shown). A relay pod is a pod that relays communication inside and outside the container orchestration cluster.

Assume that the identifier of the user of the terminal device 2 is UsrID1. Let CredUsr1 be the information for user authentication and authorization. Information for authentication and authorization includes passwords, electronic certificates, and the like. Assume that the application identifier is AppID1. Let PodID1, PodID2, PodID3, and RelayPodID1 be the identifiers of the four pods that make up the application, respectively.

Each pod has a different role in the application. The first pod 81 and the second pod 82 are pods that perform relatively complicated processing among the plurality of pods that constitute the application. The third pod 83 is a pod responsible for the user interface of the application among the plurality of pods forming the application. A pod serving as a user interface must be placed on the terminal device 2 . Therefore, the third pod 83 is a pod that should always be arranged on the terminal device 2 .

When connected to the network, the terminal device 2 registers the third worker node, which is its own node, in the container orchestration cluster configured at the nearest site. In the example of FIG. 1, the terminal device 2 connects to the network near the first site. As a result, the terminal device 2 registers the third worker node as its own node in the container orchestration cluster to which the first master node 41 belongs. As a result, the terminal device 2 similarly belongs as a third worker node to the container orchestration cluster to which the first master node 41 belongs.

(Understanding of network status and resource status)
FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system 1 when the container system 1 measures network conditions and resource conditions. In step S1, the first network monitor 42 of the first base communicates with the second network monitor 62 of the second base to obtain a network status (first network status) during communication from the first base to the second base. to measure. The network status is, for example, the communication delay time from the first network monitor 42 to the second network monitor 62 . Alternatively, the network status is the communication band available for communication from first network monitor 42 to second network monitor 62 . Here, the first network monitor 42 measures both delay time and communication bandwidth as network conditions.

FIG. 3 is a diagram showing an example of a network status notification message. At step S2, the first network monitor 42 generates a network status notification message as shown in FIG. As shown in FIG. 3, the network status notification message contains several different fields. Specifically, the network status notification message includes at least Type field, Source ID field, and No of Destinations field. The Type field indicates the type of message containing this field. In FIG. 3, the Type field is included in the network status notification message, so the value of the Type field is "Network Status Notification" to indicate the network status notification message. The Source ID field indicates the identifier of the network status measurement source. In FIG. 3, the value of the Source ID field is NmonID1. The No of Destinations field indicates the number of network status measurement partners. In FIG. 3, the No of Destinations field has a value of one.

The network status notification message further includes a triple field of the corresponding Destination ID field, Delay field and Available Bandwidth field for each network status measurement partner. In FIG. 3, there is one measurement partner (the second network monitor 62), so the network status notification message contains one triplet field. The Destination ID field represents the identifier of the network status measurement partner. In FIG. 3, the value of the network status notification message is the identifier of the second network monitor 62, namely NmonID2. The Delay field indicates the communication delay time from the source of measurement (here, the first network monitor 42) indicated by the Source ID field to the destination of measurement (here, the second network monitor 62) indicated by the Destination ID. The Available Bandwidth field indicates a communication band that can be used during communication from the measurement source (here, the first network monitor 42) indicated by the Source ID field to the measurement partner (here, the second network monitor 62) indicated by the Destination ID field.

In step S<b>3 , the first resource monitor 51 of the first MEC server 5 measures the resource status of the first MEC server 5 . A resource is a computational resource available in the first MEC server 5 . Here, the number of virtual CPUs, the memory capacity, the storage capacity, the number of GPUs, and the memory capacity of the GPUs possessed by the first MEC server 5 are measured as the resource status. Furthermore, as the resource status, the number of virtual CPUs being used by the first MEC server 5, the memory capacity, the storage capacity, the number of GPUs, and the memory capacity of the GPUs are also measured.

FIG. 4 is a diagram showing an example of a resource status notification message. At step S4, the first resource monitor 51 generates a resource status notification message as shown in FIG. A network status notification message contains several different fields. In the example of FIG. 4, the resource status notification message includes at least Type field, Source ID field, and No of Nodes field. The value of the Type field is "resource status notification" indicating the message type of the resource status notification message. The Source ID field indicates the identifier of the resource status measurement source. In this example, the value of the Source ID field is the identifier of the first resource monitor 51, namely RmonID1. The No of Nodes field indicates the number of worker nodes arranged on the first MEC server 5 . Since two worker nodes are allocated to the first MEC server 5, the value of the No of Nodes field is 2 in this example.

The resource status notification message further includes Node ID field, CPUs field, Memory field, Storage field, GPUs field, GPU Memory field, In Use CPUs field, In Use Memory field, In Use Storage field, In Use GPUs field for each worker node. and 11 sets of fields, including the In Use GPU Memory field. A Node ID field indicates the identifier of the worker node. The CPUs field indicates the number of virtual CPUs assigned to the worker node. A Memory field indicates the memory capacity allocated to the worker node. The Storage field indicates the storage capacity assigned to the worker node. A GPUs field indicates the number of GPUs assigned to the worker node. A GPU Memory field indicates the GPU memory capacity allocated to the worker node. The In Use CPUs field indicates the number of virtual CPUs that the worker node is using. The In Use Memory field indicates the memory capacity in use by the worker node. The In Use Storage field indicates the storage capacity in use by the worker node. The In Use GPUs field indicates the number of GPUs in use by the worker node. The In Use GPU Memory field indicates the GPU memory capacity in use by the worker node.

In the example of FIG. 4, the resource status notification message contains two 11-tuple fields corresponding to the first worker node 52 and the fourth worker node 53 . In the first 11-tuple field, the value of the Node ID field is WnID1. The value of the CPUs field indicates the number of virtual CPUs assigned to the first worker node 52 . A Memory field indicates the memory capacity allocated to the first worker node 52 . A Storage field indicates the storage capacity allocated to the first worker node 52 . A GPUs field indicates the number of GPUs assigned to the first worker node 52 . A GPU Memory field indicates the GPU memory capacity allocated to the first worker node 52 . In Use CPUs indicates the number of virtual CPUs currently in use by the first worker node 52 . The In Use Memory field indicates the memory capacity being used by the first worker node 52 . The In Use Storage field indicates the storage capacity being used by the first worker node 52 . The In Use GPUs field indicates the number of GPUs being used by the first worker node 52 . The In Use GPU Memory field indicates the amount of GPU memory being used by the first worker node 52 .

In the second 11-tuple field, the value of the Node ID field is WnID4. The values of the remaining 10 fields, such as the CPUs field, indicate values for the fourth worker node 53, similar to the first 11-tuple field.

The first resource monitor 51 provided in another first MEC server 5 in the first base operates similarly to generate a resource status notification message and notify the first local data store 44 of it. In step S5, the first local data store 44 receives the resource status and network status notified from other first resource monitors 51 in the first site. In step S6, the first local data store 44 generates a site status notification message as shown in FIG. 5 by aggregating resource status and network status information of all first MEC servers 5 at the first site. At this time, the first local data store 44 saves the aggregated network status and each resource status in its own storage space.

FIG. 5 is a diagram showing an example of a site status notification message. In step S7, the first local data store 44 notifies the global data store 32 of the site status notification message. In the example of FIG. 5, the site status notification message includes Type field, Base ID field, No of Destinations field, and No of Resource Stats field. The value of the Type field is "base status notification" indicating the message type of the base status notification message. A Base ID field indicates the identifier of the base. In the example of FIG. 4, the value of the Base ID field is BaseID1.

The No of Destinations field indicates the number of network status measurement partners. In FIG. 5, the value of the No of Destinations field is one. The site status notification message includes a triplet field of a Destination ID field, a Delay field, and an Available Bandwidth field corresponding to each measurement partner. The values of these fields are identical to the values of the triplet field shown in FIG.

The No of Resource Stats field indicates the number of reported resource statuses. In this example, the resource status of n first MEC servers 5 is notified, so the value of the No of Resource Stats field is n. The site status notification message further includes two field groups (11×2 fields in total) below each Node ID field in FIG. 4, as many as the No of Resource Stats field values. In this example, the site status notification message includes n field groups.

The global data store 32 receives the network status of the first base and the resource status of the first worker node 52 and the fourth worker node 53 (first resource situation) in its own storage space. Thereafter, a series of processes of steps S1 to S7 are repeatedly executed periodically.

Although detailed description is omitted, the same processing as steps S1 to S7 described above is also executed at the second site. As a result, the global data store 32 receives the network status of the second site (second network status) and the second worker node 72 and the fifth worker node 72 in each of the second MEC servers 7 of the second site, which are included in the notified site status notification message. It also saves the resource status (second resource status) of the worker node 73 in its own storage space.

(application startup processing)
FIG. 6 is a sequence diagram showing the flow of a series of processes executed by the container system 1 when the terminal device 2 activates the application. A user operates the terminal device 2 and inputs an operation to the terminal device 2 for activating a predetermined application. In step S11, when the terminal device 2 detects this operation, the terminal device 2 executes the activation App23 for activating the application. The activation App 23 is stored in advance in the image repository 22 within the terminal device 2 . Launch App 23 is a module used to launch and terminate applications. By executing the launch App 23, the first pod 81, the second pod 82, and the third pod 83 that constitute the application can be arranged in the container orchestration cluster. However, unlike the first pod 81, the second pod 82, and the third pod 83, the launch App 23 does not belong to the container orchestration cluster.

The executed startup App 23 accesses the preference repository 21 of the terminal device 2 and refers to preferences associated with the application. A preference is a group of parameters that are referenced when starting an application. The contents of the preferences are specified in advance by the user. For example, the preferences specify whether a part of the application is desired to be offloaded to the first MEC Server 5 or the second MEC Server 7 . In this example, it is assumed that the user has specified in their preferences that they want to offload. Note that the contents of the preferences may be specified in advance by the cloud server 3 instead of by the user.

(application launch request)
FIG. 7 is a diagram showing an example of an application activation request message. In step S12, the activation App 23 generates an application activation request message as shown in FIG. 7 and transmits it to the first AppAPI 46 in the first base. The application activation request message is a message for requesting activation of an application. In the example of FIG. 7, the application activation request message includes Type field, User ID field, Credential field, App ID field, and Preference field. The value of the Type field is "application activation request" indicating the message type of the application activation request message. A User ID field indicates the identifier of the user of the terminal device 2 . In the example of FIG. 8, the value of the User ID field is UsrID1. The Credential field indicates authentication authorization information of the user of the terminal device 2 . In the example of FIG. 8, the value of the Credential field is CredUsr1. The App ID field indicates the identifier of the application to be executed. In the example of FIG. 8, the value of the App ID field is AppID1. The Preference field indicates information read from the preference repository 21 by the launch App 23 .

When the terminal device 2 connects to the network, the terminal device 2 acquires the address and the like of the first AppAPI 46 located at the first site closest to the terminal device 2 . In step S13, the first AppAPI 46 authenticates and authorizes the user of the terminal device 2 based on the received application activation request message. At that time, the first AppAPI 46 may access a control plane such as a mobile phone network.

(Application configuration information request)
FIG. 8 is a diagram showing an example of an application configuration information request message. In step S14, the first AppAPI 46 generates an application configuration information request message as shown in FIG. 8 and transmits it to the first local image repository 45. FIG. The application configuration information request message is a message for requesting pod configuration information of an application. In the example of FIG. 8, the application configuration information request message includes a Type field and an App ID field. The value of the Type field is "application configuration information request" indicating the message type of the application configuration information request message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1.

The first local image repository 45 can temporarily hold images of a first pod 81, a second pod 82, and a third pod 83 that constitute an application. At the time of receiving the application configuration information request message, the first local image repository 45 does not yet hold the pod image of the application indicated by the received application configuration information request message. Therefore, the first local image repository 45 transmits the received application configuration information request message to the origin image repository 33 in step S15. The configuration and content of the application configuration information request message transmitted here are the same as the configuration and content of the application configuration information request message shown in FIG.

(App configuration information response)
FIG. 9 is a diagram showing an example of an application configuration information response message. All pod images of all applications executable by the container system 1 are stored in advance in the storage space of the origin image repository 33 . Upon receiving the application configuration information request message, the origin image repository 33 stores the images of the first pod 81, the second pod 82, and the third pod 83, which constitute the application indicated by the application configuration information request message, in its own storage space. read from At step S16, the origin image repository 33 generates an application configuration information response message as shown in FIG.

The application configuration information response message is a message for responding with application pod configuration information. In the example of FIG. 9, the application configuration information response message includes Type field, App ID field, and No of Pods field. The value of the Type field is "application configuration information response" indicating the message type of the application configuration information response message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1. The No of Pods field indicates the number of pods that compose the application. In the example of FIG. 9, the value of the No of Pods field is 3.

The App Configuration Information Response message further includes, for one Pod, a 7-tuple field that includes a Pod ID field, a No of CPUs field, a Memory field, a Storage field, a No of GPUs field, a GPU Memory field, and a Net Req field. A Pod ID field indicates the identifier of the pod. The No of CPUs field indicates the number of virtual CPUs required by the pod. The Memory field indicates the memory capacity required by the pod. The Storage field indicates the storage capacity required by the pod. The No of GPUs field indicates the number of GPUs required by the Pod. The GPU Memory field indicates the amount of GPU memory required by the pod. The Net Req field indicates the network requirements that the pod needs.

In the example shown in FIG. 9, the Pod ID field included in the first septetary field is PodID1. The No of CPUs field indicates the number of virtual CPUs required by the first pod 81 . A Memory field indicates the memory capacity required by the first pod 81 . A Storage field indicates the storage capacity required by the first pod 81 . A No of GPUs field indicates the number of GPUs required by the first pod 81 . A GPU Memory field indicates the GPU memory capacity required by the first pod 81 .

The app configuration information response message further includes a septetary field for the second pod 82 and a septetary field for the third pod 83 .

Upon receiving the application configuration information response message, the first local image repository 45 temporarily holds the application configuration information included in the received application configuration information response message in the storage space of the first local image repository 45 . When the first local image repository 45 runs out of storage space, it secures storage space according to an LRU (Least Recently Used) algorithm or the like. In step S<b>17 , the first local image repository 45 transmits the received application configuration information response message to the first AppAPI 46 . The configuration and content of the application configuration information response message transmitted at this time are the same as the configuration and content of the application configuration information response message shown in FIG.

(Pod Placement Decision Request)
FIG. 10 is a diagram showing an example of a pod placement determination request message. In step S18, the first AppAPI 46 generates a pod placement determination request message as shown in FIG. 10 based on the received application configuration information response message, and transmits it to the first local MANO 43. The pod placement determination request is a message for requesting placement determination of the first pod 81 and the second pod 82 that constitute the application. In the example of FIG. 10, the pod placement determination request message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod placement determination request" indicating the message type of the pod placement determination request message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1. The No of Pods field indicates the number of pods that compose the application. An application consists of three pods, one of which is placed in the terminal device 2 . Therefore, in the example of FIG. 11, the value of the No of Pods field is 2.

The Pod Placement Decision Request message further includes, for each Pod, a 7-tuple field that includes a Pod ID field, a No of CPUs field, a Memory field, a Storage field, a No of GPUs field, a GPU Memory field, and a Net Req field. In the example of FIG. 10, the pod placement decision request message contains two septuple fields. A Pod ID field indicates the identifier of the pod. The No of CPUs field indicates the number of virtual CPUs required by the pod. The Memory field indicates the memory capacity required by the pod. The Storage field indicates the storage capacity required by the pod. The No of GPUs field indicates the number of GPUs required by the Pod. The GPU Memory field indicates the amount of GPU memory required by the pod. The Net Req field indicates the network requirements that the pod needs.

In the example of FIG. 10 , the Pod ID field included in the first septetary field indicates the identifier of the first pod 81 . Therefore, the value of the Pod ID field is PodID1. The No of CPUs field indicates the number of virtual CPUs required by the first pod 81 . A Memory field indicates the memory capacity required by the first pod 81 . A Storage field indicates the storage capacity required by the first pod 81 . A No of GPUs field indicates the number of GPUs required by the first pod 81 . A GPU Memory field indicates the GPU memory capacity required by the first pod 81 . The Net Req field indicates requirements for the network required by the first pod 81 . The remaining six fields, such as the No of CPUs field, indicate the resource requirements that the first pod 81 needs.

In the example of FIG. 10 , the Pod ID field included in the second septetary field indicates the identifier of the second pod 82 . Therefore, the value of the Pod ID field is PodID2. Values such as the No of CPUs field contained in the second septuple field are values for the second pod 82, similar to the first septetary field. Therefore, the Net Req field indicates the network requirements (second requirements) required by the second pod 82 . The remaining six fields, such as the No of CPUs field, indicate the resource requirements that the second pod 82 needs.

(Arrangement determination of the first pod 81)
Upon receiving the pod placement determination request message, the first local MANO 43 can place all of the first pod 81 and the second pod 82 indicated by the received pod placement determination request message on any worker node within the first site. Determine whether or not At that time, the first local MANO 43 stores the network status of the first site and the resource status of each first MEC server 5 stored in the first local data store 44 and the first pod included in the received pod placement determination request message. Based on the network requirements and resource requirements for 81 , it decides whether to place the first pod 81 on the first worker node 52 . Specifically, it is first determined whether or not the network status regarding the first base satisfies the request information for the network regarding the first pod 81 included in the pod placement determination request message. If it is determined that it satisfies the requirements, then the resource status of any of the first MEC servers 5 within the first base stored in the first local data store 44 is the first pod included in the pod placement determination request message. Determine whether the resource status requirements for 81 are met.

Here, the network status of the first site satisfies the requirements for the network status regarding the first pod 81, and the resource status of the first worker node 52 of the first MEC server 5 is the resource regarding the first pod 81. shall meet the requirements of In these cases, the first local MANO 43 decides to place the first pod 81 on the first worker node 52 of the first MEC server 5 within the first location.

Also, here, the network status of the first site satisfies the network status requirement for the second pod 82, but the resource status of the first worker nodes 52 and the fourth worker nodes 53 of all the first MEC servers 5 is Assume that the resource status request information regarding the second pod 82 is not satisfied. As a result, the first local MANO 43 determines that the second pod 82 cannot be placed in the first worker nodes 52 or the fourth worker nodes 53 of all the first MEC servers 5 within the first site.

FIG. 11 is a diagram showing an example of a pod placement determination request message. In step S19, if the second pod 82 cannot be placed at the first site, the first local MANO 43 sends a pod placement determination request as shown in FIG. 11 to place the second pod 82 at the second site. Create a message and send it to the global MANO 31 . The pod placement determination request message transmitted here is a message for requesting placement determination of the second pod 82 .

(Arrangement determination of the second pod 82)
In step S20, upon receiving the pod placement determination request message, the global MANO 31 determines whether or not the second pod 82 can be placed in the second MEC server 7 at the second site. At that time, the global MANO 31 stores the network status of the second site (second network status) and the resource status of each second MEC server 7 stored in the global data store 32, and the second network status included in the received pod placement determination request message. Based on the network requirements and resource requirements for the second pod 82 , a decision is made whether to place the second pod 82 on the second worker node 72 . Specifically, it is first determined whether or not the network status regarding the second site satisfies the request information for the network regarding the second pod 82 included in the pod placement determination request message. If it is determined that it satisfies the requirements, then the resource status of any of the second MEC servers 7 in the second site stored in the global data store 32 is related to the second pod 82 included in the pod placement determination request message. Determine whether resource status requirements are met.

Here, the network status of the second site satisfies the requirements for the network regarding the second pod 82, and the resource status of the second worker node 72 of the second MEC server 5 indicates that the resource status of the second pod 82 is not available. It shall meet the requirements. In these cases, the global MANO 31 decides to place the second pod 82 on the second worker node 72 of the second MEC server 7 within the second site.

(Pod placement decision response)
FIG. 12 is a diagram showing an example of a pod placement decision response message. In step S20, the global MANO 31 generates a pod placement determination response message as shown in FIG. 12 and transmits it to the first local MANO 43. The pod placement determination response message is a message for responding that the placement of the second pod 82 has been determined. In the example of FIG. 12, the pod placement determination response message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod placement determination response" indicating the message type of the pod placement determination response message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1. The No of Pods field indicates the number of pods. In the example of FIG. 12, the value of the No of Pods field is 1.

The Pod Placement Decision Response message further includes, for each Pod, a triplet field that includes a Pod ID field, a Base ID field, and a Node ID field. Since there is one pod here, the pod placement decision response message further includes one triplet field. A Pod ID field indicates the identifier of the pod. In the example of FIG. 12, the value of the Pod ID field is PodID2. The Base ID field indicates the identifier of the base where the pod is placed. In the example of FIG. 12, the value of the Base ID field is BaseID2 because the second pod 82 is located at the second base. A Node ID field indicates the identifier of the worker node where the pod is placed. In the example of FIG. 12, the Node ID field is WnID2 because the second pod 82 is placed on the second worker node 72 of the second MEC server 7 at the second site.

FIG. 13 is a diagram showing an example of a pod placement decision response message. In step S21, when the first local MANO 43 receives the pod placement determination response message regarding the second pod 82, it generates a pod placement determination response message as shown in FIG. The configuration of the pod placement determination response message shown in FIG. 13 is obtained by adding an item regarding the first pod 81 to the configuration of the pod placement determination response message shown in FIG. Therefore, detailed description of the pod placement determination response message shown in FIG. 13 is omitted.

(pod placement request)
FIG. 14 is a diagram showing an example of a pod placement request message. In step S22, upon receiving the pod placement decision response message, the first AppAPI 46 generates a pod placement request message as shown in FIG. The pod placement request message is a message for requesting placement of the first pod 81 , the second pod 82 and the third pod 83 . In the example of FIG. 14, the pod placement request message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod placement request" indicating the message type of the pod placement request message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1. The No of Pods field indicates the number of pods. In the example of FIG. 14, the No of Pods field has a value of 3 because the pod placement request message requests placement of three pods, the first pod 81, the second pod 82, and the third pod 83. In the example of FIG.

The Pod Deployment Request message further includes, for each Pod, a quadruple field: Pod ID field, Base ID field, Node ID field, and Repository ID field. In the example of FIG. 14, placement of three first pods 81, second pods 82, and third pods 83 is requested, so the pod placement request message further includes three quadruple fields. A Pod ID field indicates the identifier of the pod. The Base ID field indicates the identifier of the base where the pod is placed. A Node ID field indicates the identifier of the worker node where the pod is placed. The Repository ID field indicates the identifier of the image repository 22 from which the pod image should be obtained.

In the example of FIG. 14, the value of the Pod ID field in the first quadruple field is the identifier of the first pod 81, ie PodID1. The value of the Base ID field is the identifier of the first base where the first pod 81 is located, ie, BaseID1. The value of the Node ID field is the identifier of the first worker node 52 where the first pod 81 is located, namely WnID1. The value of the Repository ID field is LirID1. The value of the Pod ID field in the second quadruple field is the identifier of the second pod 82, PodID2. The value of the Base ID field is the identifier of the second base where the second pod 82 is located, ie BaseID2. The value of the Node ID field is the identifier of the second worker node 72 where the second pod 82 is located, namely WnID2. The value of the Repository ID field is LirID2. The value of the Pod ID field in the third quartet field is the identifier of the third pod 83, PodID3. The value of the Base ID field is the identifier of the first site where the third pod 83 is located, ie, BaseID1. The value of the Node ID field is the identifier of the third worker node where the third pod 83 is located, ie WnID3. The value of the Repository ID field is LirID1.

(Arrangement of first pod 81)
FIG. 15 is a diagram showing an example of a pod arrangement request message. In step S23, upon receiving the pod placement request message, the first master node 41 generates a pod placement request message as shown in FIG. 15 based on the received pod placement request message, and transmits it to the first worker node 52. . The pod placement request message generated here is a message for requesting placement of the first pod 81 . The configuration of the pod arrangement request message shown in FIG. 15 is obtained by removing the items of the second pod 82 and the third pod 83 from the configuration of the pod arrangement request message shown in FIG. In the example shown in FIG. 15, the value of the No of Pods field included in the pod placement request message is 1. The value of the Pod ID field is PodID1. The value of the Base ID field is BaseID1. The value of the Node ID field is WnID1. The value of the Repository ID field is LirID1.

FIG. 16 is a diagram showing an example of a pod placement response message. In step S24, the first worker node 52 places the first pod 81 on the first worker node 52 based on the received pod placement request message. In step S<b>25 , the first worker node 52 generates a pod placement response message and transmits it to the first master node 41 after completing placement of the first pod 81 . The pod placement response message is a message for responding that the placement of the first pod 81 has been completed. The pod placement response message shown in FIG. 16 includes a Type field and an App ID field. The value of the Type field is "pod deployment response", which indicates the message type of the pod deployment response message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1.

The Pod Deployment Response message further includes, for one Pod, a 2-tuple field consisting of a Pod ID field and a Status field. A Pod ID field indicates the identifier of the pod. In the example of FIG. 16, the value of the Pod ID field is PodID1. The Status field indicates the end status of pod arrangement processing. In the example of FIG. 16, the value of the Status field is "OK" indicating normal termination of placement of the first pod 81. In the example of FIG.

(Arrangement of third pod 83)
FIG. 17 is a diagram showing an example of a pod placement request message. In step S25, the first master node 41 generates a pod placement request message as shown in FIG. 17 and transmits it to the third worker node. The configuration of the pod placement request message shown in FIG. 17 is the same as the configuration of the pod placement request message shown in FIG. In the example of FIG. 17, the pod placement request message includes various information regarding the placement of the third pod 83 . Upon receiving the pod placement request message, the third worker node places the third pod 83 on the third worker node based on the received pod placement request message.

FIG. 18 is a diagram showing an example of a pod placement response message. In step S26, the third worker node generates a pod placement response message as shown in FIG. The configuration of the pod placement response message shown in FIG. 18 is the same as the configuration of the pod placement response message shown in FIG. In the example of FIG. 18, the pod placement response message includes various pieces of information regarding completion of placement of the third pod 83 .

(Arrangement of second pod 82)
FIG. 19 is a diagram showing an example of a pod placement request message. In step S27, the first master node 41 generates a pod placement request message as shown in FIG. 19 and transmits it to the fourth worker node 53. The configuration of the pod placement request message shown in FIG. 19 is the same as the configuration of the pod placement request message shown in FIG. In the example of FIG. 19, the pod placement request message contains various information regarding the placement of the second pod 82 . Upon receiving the pod placement request message, the fourth worker node 53 places the second pod 82 on the second worker node 72 based on the received pod placement request message.

FIG. 20 is a diagram showing an example of a pod placement response message. In step S28, the second worker node 72, after completing the placement of the second pod 82, generates a pod placement response message as shown in FIG. The configuration of the pod placement response message shown in FIG. 20 is the same as the configuration of the pod placement response message shown in FIG. In the example of FIG. 20, the pod placement response message contains various information regarding the completion of placement of the second pod 82 .

The application is started by normally arranging the first pod 81, the second pod 82, and the third pod 83 as described above. The arrangement order of the first pod 81, the second pod 82, and the third pod 83 is not limited to the order shown in FIG. 6, and can be changed arbitrarily. For example, the third pod 83 may be placed first, the first pod 81 next, and the second pod 82 last.

(pod placement response)
FIG. 21 is a diagram showing an example of a pod arrangement response message. In step S29, the first master node 41 generates a pod placement response message as shown in FIG. 21 and transmits it to the first AppAPI 46. The configuration of the pod placement response message shown in FIG. 21 is a configuration that integrates the pod placement response messages shown in FIGS. 16, 18, and 20, respectively. That is, the pod placement response message shown in FIG. 21 includes information regarding the completion of placement of each of the first pod 81, the second pod 82, and the third pod 83. FIG.

FIG. 22 is a diagram showing an example of an application activation response message. In step S30, upon receiving the pod placement response message, the first AppAPI 46 generates an application activation response message as shown in FIG. 22 and transmits it to the activation App23. The application activation response message is a message for responding that the application has been activated. The application launch response message shown in FIG. 22 includes a Type field, an App ID field, and a Status field. The value of the Type field is "application activation response" indicating the message type of the application activation response message. The value of the App ID field is the identifier of the application to be executed, specifically AppID1. The Status field indicates the end status of placement processing. In the example of FIG. 22, it is "OK" indicating normal termination of the placement process.

The application started as described above continues to run as the first pod 81, the second pod 82, and the third pod 83 cooperate to operate. By starting the application, the resources available in the first MEC server 5, the second MEC server 7, and the network are reduced by the resources consumed by the application. As shown in FIG. 2, the container system 1 maintains the status of the network between the first base and other bases, the resource status of each first MEC server 5, the second base and the other bases, even after starting the application. and the resource status of each second MEC server 7 are periodically measured. This periodically updates the network and resource conditions stored in the first local data store 44 , the second local data store 64 and the global data store 32 . Accordingly, the information stored in each of the first local data store 44, the second local data store 64, and the global data store 32 can be kept up-to-date.

(Stop application)
FIG. 23 is a sequence diagram showing a series of processes executed when the container system 1 stops an application. A user operates the terminal device 2 and inputs an operation to the terminal device 2 to stop a predetermined application. When the terminal device 2 detects this operation, it instructs the startup App 23 to stop the application.

FIG. 24 is a diagram showing an example of an application stop request message. In step S31, upon receiving an application stop instruction from the terminal device 2, the startup App 23 generates an application stop request message as shown in FIG. The application stop request message includes Type field, User ID field, Credential field, and App ID field. The value of the Type field is "application stop request" indicating the message type of the application stop request message. A User ID field indicates the identifier of the user of the terminal device 2 . In the example of FIG. 24, the value of the User ID field is UsrID1. The Credential field contains the user's authentication authorization information. In the example of FIG. 24, the value of the Credential field is CredUsr1. The value of the App ID field is the identifier of the application to be stopped, specifically AppID1.

In step S<b>32 , the first AppAPI 46 performs authentication and authorization of the user of the terminal device 2 . At that time, the first AppAPI 46 may access a control plane such as a mobile phone network. In step S<b>33 , the first AppAPI 46 transmits the received application stop request message to the first master node 41 when the user authentication and authorization are successful.

FIG. 25 is a diagram showing an example of a pod stop request message. In step S34, upon receiving the application stop request message, the first master node 41 generates a pod stop request message as shown in FIG. 25 and transmits it to the first worker node 52. FIG. The pod stop request message shown in FIG. 25 is a message for requesting stop of the first pod 81 . In the example of FIG. 25, the pod stop request message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod stop request" indicating the message type of the pod stop request message. The value of the App ID field is the identifier of the application to be stopped, specifically AppID1. The No of Pods field indicates the number of pods to be stopped. In the example of FIG. 25, the value of the No of Pods field is 1.

The Pod Stop Request message further includes, for one Pod, a triple field consisting of a Pod ID field, a Base ID field, and a Node ID field. A Pod ID field indicates the identifier of the pod. In the example of FIG. 25, the value of the Pod ID field is PodID1. The Base ID field indicates the identifier of the base where the pod is located. In the example of FIG. 25, the value of the Base ID field is the identifier of the first site where the first pod 81 is located, ie, BaseID1. A Node ID field indicates the identifier of the worker node where the pod is located. In the example of FIG. 25, the value of the Node ID field is the identifier of the first worker node 52 where the first pod 81 is located, namely WnID1.

FIG. 26 is a diagram showing an example of a pod stop response message. The first worker node 52 stops the first pod 81 upon receiving the pod stop request message. In step S35, when the first pod 81 is successfully stopped, the first worker node 52 generates a pod stop response message as shown in FIG. The pod stop response message shown in FIG. 26 is a message for responding that the first pod 81 has been successfully stopped. In the example of FIG. 26, the pod stop response message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod stop response" indicating the message type. The value of the App ID field is the identifier of the application to be stopped, specifically AppID1. The No of Pods field indicates the number of pods. 1 in this example.

The Pod Stop Response message further includes, for one Pod, a 2-tuple field consisting of a Pod ID field and a Status field. A Pod ID field indicates the identifier of the pod. In the example of FIG. 26, the value of the Pod ID field is the identifier of the first pod 81 to be stopped, namely PodID1. The Status field indicates the end status of processing. In the example of FIG. 26, it is "OK" indicating normal termination.

In step S36, the first master node 41 generates a pod stop request message for stopping the third pod 83 and transmits it to the third worker node. The third worker node stops the third pod 83 upon receiving the pod stop request message. In step S<b>37 , the third worker node generates a pod stop response message for responding that the third pod 83 has been stopped, and transmits it to the first master node 41 . The procedure of each process when the third pod 83 is stopped is the same as the procedure of each process when the first pod 81 is stopped, so detailed description thereof will be omitted.

In step S<b>38 , the second master node 61 generates a pod stop request message for stopping the second pod 82 and transmits it to the second worker node 72 . The second worker node 72 stops the second pod 82 upon receiving the pod stop request message. In step S<b>39 , the second worker node 72 generates a pod stop response message for responding that the second pod 82 has been stopped, and transmits it to the first master node 41 . The procedure of each process when the second pod 82 is stopped is the same as the procedure of each process when the first pod 81 is stopped, so detailed description thereof will be omitted.

FIG. 27 is a diagram illustrating an example of an application stop response message; In step S<b>40 , the first master node 41 generates an application stop response message and transmits it to the first AppAPI 46 . The application stop response message is a message for responding that the application has been stopped. In the example of FIG. 27, the application stop response message includes a Type field, an App ID field, and a Status field. The value of the Type field is "application stop response" indicating the message type of the application stop response message. The value of the App ID field is the identifier of the application to be stopped, specifically AppID1. The Status field indicates the end status of processing. In the example of FIG. 2, the value of the Status field is "OK" indicating normal termination of application stop.

In step S<b>41 , when the first AppAPI 46 receives the application stop response message, it transmits the received application stop response message to the startup App 23 . In step S42, when the startup App 23 receives the application stop response message, it ends. This completes the termination of the application.

FIG. 28 is a diagram showing an example of a measurement request message. In step S43, the first AppAPI 46 generates a measurement request message as shown in FIG. 28 and transmits it to the first network monitor 42. FIG. The measurement request message shown in FIG. 28 is a message for requesting network status measurement. A measurement request message includes a Type field and a No of Targets field. The value of the Type field is "measurement request" indicating the message type of the measurement request message. The No of Targets field indicates the number of measurement request targets. In the example of FIG. 28, the value of the No of Targets field is 1. The measurement request message further includes one Target ID field for one measurement request target. The Target ID field indicates the identifier of the module requesting measurement. In the example of FIG. 28, the value of the Target ID field is the identifier of the first network monitor 42, namely NmonID1.

FIG. 29 is a diagram showing an example of a measurement request message. In step S44, the first AppAPI 46 generates a measurement request message as shown in FIG. 29 and transmits it to the first resource monitor 51. FIG. The measurement request message shown in FIG. 29 is a message for requesting resource status measurement. A measurement request message includes a Type field and a No of Targets field. The value of the Type field is "measurement request" indicating the message type of the measurement request message. The No of Targets field indicates the number of measurement request targets. In the example of FIG. 29, the value of the No of Targets field is 1. The measurement request message further includes one Target ID field for one measurement request target. The Target ID field indicates the identifier of the module requesting measurement. In the example of FIG. 29, the value of the Target ID field is the identifier of the first resource monitor 51, namely RmonID1.

FIG. 30 is a diagram showing an example of a measurement request message. In step S45, the first AppAPI 46 generates a measurement request message as shown in FIG. 30 and transmits it to the second AppAPI 66. FIG. The measurement request message shown in FIG. 30 is a message for requesting measurement of network status and resource status. A measurement request message includes a Type field and a No of Targets field. The value of the Type field is "measurement request" indicating the message type of the measurement request message. The No of Targets field indicates the number of measurement request targets. In the example of FIG. 30, the value of the No of Targets field is 2. The measurement request message further includes one Target ID field for one measurement request target. In the example of FIG. 30, the measurement request message further includes two Target ID fields. The Target ID field indicates the identifier of the module requesting measurement. In the example of FIG. 30, the value of the first Target ID field is the identifier of the second network monitor 62, namely NmonID2. The value of the second Target ID field is the identifier of the second resource monitor 71, namely RmonID2.

FIG. 31 is a diagram showing an example of a measurement request message. In step S46, the second AppAPI 66 generates a measurement request message as shown in FIG. 31 and transmits it to the second network monitor 62. FIG. The measurement request message shown in FIG. 31 is a message for requesting network status measurement. A measurement request message includes a Type field and a No of Targets field. The value of the Type field is "measurement request" indicating the message type of the measurement request message. The No of Targets field indicates the number of measurement request targets. In the example of FIG. 31, the value of the No of Targets field is 1. The measurement request message further includes one Target ID field for one measurement request target. The Target ID field indicates the identifier of the module requesting measurement. In the example of FIG. 31, the value of the Target ID field is the identifier of the second network monitor 62, namely NmonID2.

FIG. 32 is a diagram showing an example of a measurement request message. In step S47, the second AppAPI 66 generates a measurement request message as shown in FIG. 32 and transmits it to the second resource monitor 71. FIG. The measurement request message shown in FIG. 32 is a message for requesting resource status measurement. A measurement request message includes a Type field and a No of Targets field. The value of the Type field is "measurement request" indicating the message type of the measurement request message. The No of Targets field indicates the number of measurement request targets. In the example of FIG. 32, the value of the No of Targets field is 1. The measurement request message further includes one Target ID field for one measurement request target. The Target ID field indicates the identifier of the module requesting measurement. In the example of FIG. 32, the value of the Target ID field is the identifier of the second resource monitor 71, namely RmonID2.

Based on steps S43 to S47, the first network monitor 42, the first resource monitor 51, the second network monitor 62, and the second resource monitor 71 execute the series of processing procedures shown in FIG. As a result, the latest network status and resource status after termination of the application are reflected in the first local data store 44, the second local data store 64, and the global data store 32. FIG.

(Main effects of this embodiment)
The first MEC server 5 measures the resource status of the first worker node 52 using the first resource monitor 51 and transmits the result to the first base device 4 . The first base device 4 uses the first network monitor 42 to measure the network status (communication delay, etc.) during communication from the first base to the second base. These network conditions and resource conditions are stored in the first local data store 44 . The first local MANO 43 determines whether or not to place the first pod 81 on the first MEC server 5 based on the network conditions and resource conditions stored in the first local data store 44 . As a result, it is possible to arrange the first pod 81 in consideration of the network conditions and resource conditions, so that the first pod 81 can be arranged in the optimum first worker node 52 .

Based on the network and resource conditions stored in the first local data store 44, the first local MANO 43 directs the first MEC server 5 to meet the network and resource requirements of the first pod 81. A decision is made to place the first pod 81 . Thereby, the first pod 81 can be reliably arranged.

The second MEC server 7 measures the resource status of the second worker node 72 using the second resource monitor 71 and transmits the result to the second base device 6 . The second base device 6 uses the second network monitor 62 to measure the network status (communication delay, etc.) during communication from the second base to the first base, and stores it in the second local data store 64 . . These network conditions and resource conditions are also stored in the global data store 32 . The global MANO 31 decides whether to place the second pod 82 on the second worker node 72 of the second MEC server 7 by considering the network conditions and resource conditions for the second location stored in the global data store 32. . As a result, it is possible to arrange pods in consideration of network conditions, so that each pod can be arranged in each worker node in good network conditions such as little communication delay. Furthermore, it is possible to optimally arrange pods among widely distributed bases via a network.

By using the first resource monitor 51, the first MEC server 5 can measure the correct resource status of the first worker node 52 even if the first worker node 52 belongs to multiple container orchestration clusters. As a result, it is possible to determine whether or not to deploy the first pod 81 to the first worker node 52 based on the correct resource status of the first worker node 52, thereby reducing the possibility of failing to deploy the first pod 81. can be made

Similarly, the second MEC server 7 can measure the correct resource status of the second worker node 72 by using the second resource monitor 71 even if the second worker node 72 belongs to multiple container orchestration clusters. can be done. Therefore, the cloud server 3 saves the resource status of each first MEC server 5 received from the first base device 4 and the resource status of each second MEC server 7 received from the second base device 6 in the global data store 32. , the resource status of all worker nodes can be correctly grasped.

After starting the application executed as the container orchestration cluster, the first pod 81 constituting the application executed as the container orchestration cluster is arranged in the first MEC server 5 in the network to which the terminal device 2 is connected. . Also, the second pod 82 is arranged in the second MEC server 7 in the network to which the terminal device 2 is connected. Furthermore, the third pod 83 is arranged in the terminal device 2 . On the other hand, the launch App23 for launching the application does not belong to the container orchestration cluster. Therefore, during execution of the application, the starting App 23 and any one of the first pod 81, the second pod 82, and the third pod 83 do not communicate via the relay pod. Furthermore, communication via relay pods is not performed among the first pod 81, the second pod 82, and the third pod 83 that configure the application. By doing so, it is possible to prevent communication paths between pods from becoming redundant at the time of application startup and at the time of execution after startup.

When the container system 1 is newly introduced into an existing container orchestration system, it is not necessary to change parts of the existing container orchestration system. Therefore, the container system 1 can be easily introduced into an existing container orchestration system in operation.

A part of the application executed in the terminal equipment 2 can be efficiently offloaded to the first MEC server 5 and the second MEC server 7 .

(Modification)
In the container system 1, the first worker node 52 may belong to multiple different container orchestration clusters, and the second worker node 72 may belong to multiple different container orchestration clusters. Also in this case, the first MEC server 5 accurately measures the resource status of the first worker node 52 and the fourth worker node 53 by using the first resource monitor 51 . The measured resource status of each first MEC server 5 is aggregated in the first base device 4 and transmitted to the cloud server 3 . Similarly, the measured resource status of each second MEC server 7 is aggregated in the second base device 6 and transmitted to the cloud server 3 . The cloud server 3 stores the received status of each resource in the global data store 32 . Therefore, the cloud server 3 can correctly grasp the resource status of all worker nodes.

Furthermore, in the container system 1 , the cloud server 3 may determine the arrangement of the first pods 81 instead of the first base device 4 . In this example, the first AppAPI 46 notifies the global MANO 31 instead of the first local MANO 43 of the pod placement determination request message shown in FIG. When the global MANO 31 receives the pod placement determination request message, the global MANO 31 determines at which of the first base and the second base all of the first pods 81 and the second pods 82 indicated by the received pod placement determination request message are to be placed. to decide.

Specifically, the global MANO 31 stores the network status of the first site, the resource status of each first MEC server 5, the network status of the second site, and the resource status of each second MEC server 7 stored in the global data store 32. and the network requirements and resource requirements for the first pod 81 included in the received pod placement determination request message, the first pod 81 is assigned to either the first worker node 52 or the second worker node 72. Decide whether to install it on a worker node. For example, if the network status of the first site and the resource status of the first worker node 52 of the first MEC server 5 satisfy the network requirements and resource requirements for the first pod 81, the global MANO 31 to the first worker node 52 of the first MEC server 5 . Alternatively, if the network status of the second site and the resource status of the second worker node 72 of the second MEC server 7 satisfy the network requirements and resource requirements for the first pod 81, the global MANO 31 to the second worker node 72 of the second MEC server 5 . In this way, the global MANO 31 can select the optimum MEC server (worker node) on which the first pod 81 should be placed, considering the network conditions of each base and the network conditions of each worker node.

When the first local image repository 45 receives the application configuration information request message, the first local image repository 45 stores the first pod 81, the second pod 82, and the third pod 83 constituting the application indicated by the received application configuration information request message. Images may be stored in advance. In this case, the first local image repository 45 does not send the received application configuration information request message to the origin image repository 33, and the first pod 81 and the second pod 82 configuring the application indicated by the application configuration information request message. , and the image of the third pod 83 from its own storage space. The first local image repository 45 generates an application configuration information response message as shown in FIG. 9 based on each read pod image, and transmits it to the first AppAPI 46 . In this example, there is no need to send an application configuration information request message to the origin image repository 33 or receive an application configuration information response message from the origin image repository 33, so communication delay can be reduced. Furthermore, communication traffic between the cloud and each base can also be reduced.

[Embodiment 2]
(Configuration of container system 1A)
FIG. 33 is a block diagram showing the configuration of a container system 1A according to the second embodiment. The terminal device 2A is running the client App24. The client App 24 is a client application in a client-server type application. The cloud server 3A is running the server App34. The server App 34 is a server application in a client-server type application.

In this embodiment, the container orchestration cluster is composed of a first master node 41, a first worker node 52, a fourth worker node 53, and relay pods (not shown). 33, the server application corresponding to the server App 34 operates as a container orchestration cluster composed of a first pod 81 operating on the first worker node 52 and a second pod 82 operating on the second worker node 72. example. The identifier of each module shown in FIG. 34 is the same as each identifier described in the first embodiment. However, in the first embodiment, AppID1, which is the identifier of the application started on the terminal device 2, is treated as the identifier of the server application corresponding to the server App 34 in the present embodiment.

FIG. 34 is a sequence diagram showing the flow of a series of processes executed by the container system 1A when the terminal device 2 activates the client App24. The user operates the terminal device 2 and inputs an operation to the terminal device 2 for activating the client App 24 . In step S51, the terminal device 2A activates the client App 24 upon detecting this operation.

FIG. 35 is a diagram showing an example of an application request message. In step S52, the launched client App 24 sends an application request message to the server App 34. FIG. An application request message is a message for sending a request to the server App34. The app request message may be an HTTP Request message. It should be noted that the server App 34 can know from the address of the terminal device 2A that the base closest to the terminal device 2A is the first base.

The App Request message includes Type field, User ID field, Credential field, App ID field, and Request field. The value of the Type field is "application request" indicating the message type of the application request message. A User ID field indicates the identifier of the user of the terminal device 2 . In the example of FIG. 35, the value of the User ID field is UsrID1. The Credential field contains the user's authentication authorization information. In the example of FIG. 35, the value of the Credential field is CredUsr1. The value of the App ID field is the identifier of the server application corresponding to the server App 34, specifically AppID1. A Request field indicates the request content of the client App 24 . In step S53, the server App 34 authenticates and authorizes the user of the terminal device 2 based on the received application request message.

In step S54, when the server App 34 successfully authenticates and authorizes the user, it generates a pod placement determination request message and transmits it to the first local MANO 43 in the first site. The pod placement determination request message is a message for requesting placement determination of the first pod 81 and the second pod 82 that constitute the server application corresponding to the server App 34 . This pod placement determination request message is the same as the pod placement determination request message shown in FIG.

(Arrangement determination of the first pod 81)
Upon receiving the pod placement determination request message, the first local MANO 43 determines whether all of the first pods 81 and second pods 82 indicated by the received pod placement determination request message can be placed in each worker node within the first site. determine whether The details of the determination method are the same as those of the first embodiment, so detailed description is omitted. Here, it is assumed that the first local MANO 43 decides to place the first pod 81 on the first worker node 52 of the first MEC server 5 within the first site. Also, the first local MANO 43 further determines that the second pod 82 cannot be placed on the first worker node 52 or the fourth worker node 53 of any other first MEC server 5 within the first site. Accordingly, in step S55, the first local MANO 43 generates a pod placement determination request message and transmits it to the global MANO 31. FIG. The pod placement determination request message transmitted here is a message for requesting placement determination of the second pod 82 . Also, its configuration and content are the same as those of the pod placement determination request message shown in FIG.

(Arrangement determination of the second pod 82)
When the global MANO 31 receives the pod placement determination request message, the global MANO 31 determines whether or not to place the second pod 82 on the second MEC server 7 at the second site. Since the details of the determination method are the same as those of the first embodiment, detailed description will be omitted. Here, it is assumed that the global MANO 31 decides to place the second pod 82 on the second worker node 72 of the second MEC server 7 . As a result, in step S56, the global MANO 31 generates a pod placement decision response message for responding to the placement decision of the first pod 81, and transmits it to the first local MANO 43. FIG. The configuration and content of the pod placement determination response message transmitted here are the same as the configuration and content of the pod placement determination response message shown in FIG.

In step S57, the first local MANO 43 generates a pod placement determination response message for responding to the placement determination of the first pod 81 and the second pod 82, and transmits it to the server App34. The configuration and content of the pod placement determination response message transmitted here are the same as the configuration and content of the pod placement determination response message shown in FIG.

FIG. 36 is a diagram showing an example of a pod placement request message. In step S58, upon receiving the pod placement determination response message, the server App 34 generates a pod placement request message as shown in FIG. The pod placement request message is a message for requesting placement of the first pod 81 and the second pod 82 . In the example of FIG. 36, the pod placement request message includes Type field, App ID field, and No of Pods field. The value of the Type field is "pod placement request" indicating the message type of the pod placement request message. The value of the App ID field is the identifier of the server application corresponding to the server App 34, specifically AppID1. The No of Pods field indicates the number of pods. In the example of FIG. 36, the value of the No of Pods field is 2 because the pod placement request message requests placement of three first pods 81 and three second pods 82 .

The Pod Deployment Request message further includes, for each Pod, a quadruple field: Pod ID field, Base ID field, Node ID field, and Repository ID field. In the example of FIG. 36, placement of two first pods 81 and second pod 82 is requested, so the pod placement request message further includes three quadruple fields. In the example of FIG. 36, the value of the Pod ID field in the first quadruple field is the identifier of the first pod 81, ie PodID1. The value of the Base ID field is BaseID1 of the first base where the first pod 81 is arranged. The value of the Node ID field is the identifier of the first worker node 52 where the first pod 81 is located, namely WnID1. The value of the Repository ID field is LirID1. The value of the Pod ID field in the second quadruple field is the identifier of the second pod 82, PodID2. The value of the Base ID field is the identifier of the second base where the second pod 82 is located, ie BaseID2. The value of the Node ID field is the identifier of the second worker node 72 where the second pod 82 is located, namely WnID2. The value of the Repository ID field is LirID2.

(Arrangement of first pod 81)
In step S<b>59 , upon receiving the pod placement request message, the first master node 41 generates a pod placement request message for requesting placement of the first pod 81 and transmits it to the first worker node 52 . The configuration and content of the pod placement request message sent here are the same as the configuration and content of the pod placement request message shown in FIG. Upon receiving the pod placement request message, the first worker node 52 places the first pod 81 in the first worker node 52 based on the received pod placement request message. In step S<b>60 , the first worker node 52 generates a pod installation response message for responding to the placement of the first pod 81 and transmits it to the first master node 41 . The configuration and content of the pod installation response message transmitted here are the same as the configuration and content of the pod installation response message shown in FIG.

(Arrangement of second pod 82)
In step S<b>61 , the first master node 41 generates a pod placement request message for requesting placement of the second pod 82 and transmits it to the second worker node 72 . The configuration and content of the pod placement request message transmitted here are the same as the configuration and content of the pod placement request message shown in FIG. Upon receiving the pod placement request message, the second worker node 72 places the second pod 82 on the second worker node 72 based on the received pod placement request message. In step S<b>62 , the fourth worker node 53 generates a pod installation response message for responding to the placement of the second pod 82 and transmits it to the first master node 41 . The configuration and content of the pod installation response message transmitted here are the same as the configuration and content of the pod installation response message shown in FIG.

FIG. 37 is a diagram showing an example of a pod placement response message. In step S63, the first master node 41 generates a pod arrangement response message as shown in FIG. 37 and transmits it to the server App34. The configuration of the pod placement response message shown in FIG. 37 is a configuration in which the pod placement response messages shown in FIGS. 16 and 18 are integrated. That is, the pod placement response message shown in FIG. 21 includes information regarding the completion of placement of each of the first pod 81 and the second pod 82 .

FIG. 38 is a diagram showing an example of an application response message. In step S64, the server App34 generates an application response message as shown in FIG. 38 and transmits it to the client App24. The application response message is a message for responding to activation of the server application corresponding to the server App34. In the example of FIG. 38, the application response message includes Type field, Status field, Redirect field, and Response field. The value of the Type field is "application response" indicating the message type of the application response message. The Status field indicates the end status of processing. In this example, it is "OK" indicating normal termination of activation of the server application corresponding to the server App 34 . The Redirect field indicates the identifier of the destination module for subsequent application request messages. In the example of FIG. 38, it is the identifier of the relay pod, namely RelayPodID1. The Response field indicates the contents of the response.

The server application as the container orchestration cluster activated as described above continues to run as the server App 34 through the cooperative operation of the first pod 81 and the second pod 82 . From now on, the communication partner of the client App 24 is not the server App 34 on the cloud server, but the server application as the container orchestration cluster built in the first and second bases. Therefore, in step S65, the client App24 sends a new application request message to the first worker node 52 where the first pod 81 is located, instead of the server App34 on the cloud server. When the first worker node 52 receives the application request message, the first pod 81 cooperates with the second pod 82 to perform the process requested by the application request message. At step 66, the first worker node 52 generates and sends an App Response message to the Client App 24 to respond to processing by the Server App 34 as the container orchestration cluster.

In this embodiment, by starting the server application as the container orchestration cluster, the resources available in the first MEC server 5, the second MEC server 7, and the network are consumed by the server application corresponding to the server App 34. Decrease by resources. Even after the server application corresponding to the server App 34 is activated, the container system 1A can maintain the network status of the first base, the resource status of each first MEC server 5, the network status of the second base, and the The resource status of each second MEC server 7 is periodically measured. This periodically updates the network and resource conditions stored in the first local data store 44 , the second local data store 64 and the global data store 32 . Accordingly, the information stored in each of the first local data store 44, the second local data store 64, and the global data store 32 can be kept up-to-date.

(Stop server application)
FIG. 39 is a sequence diagram showing the flow of a series of processes executed by the container system 1A when stopping the server application. The user operates the terminal device 2 and inputs an operation to the terminal device 2A for terminating the server application that operates as the server App 34 . In step S<b>71 , when the terminal device 2</b>A detects this operation, the client App 24 generates an application termination request message for requesting termination of the server application, and transmits the message to the server App 34 . The configuration and content of the application termination request message transmitted here are the same as the configuration and content of the application termination request message shown in FIG.

The server App34 receives the application termination request message sent from the client App24. In step S72, the server App 34 authenticates and authorizes the user of the terminal device 2 based on the received application termination request message. In step S<b>73 , the server App 34 transmits the received application stop request message to the first master node 41 when the user authentication and authorization are successful.

The first master node 41 receives the application stop request message sent from the server App 34 . In step S<b>74 , the first master node 41 generates a pod stop request message for requesting stop of the first pod 81 and transmits it to the first worker node 52 . The configuration and content of the pod stop request message transmitted here are the same as the configuration and content of the pod stop request message shown in FIG.

The first worker node 52 receives the pod stop request message sent from the first master node 41 . The first worker node 52 stops the first pod 81 upon receiving the pod stop request message. In step S<b>75 , the first worker node 52 generates a pod stop response message for responding to the stop of the first pod 81 and transmits it to the first master node 41 . The configuration and content of the pod stop response message transmitted here are the same as the configuration and content of the pod stop response message shown in FIG.

The first master node 41 receives the pod stop response message sent from the first worker node 52 . In step S<b>76 , the first master node 41 generates a pod stop request message for requesting stop of the second pod 82 and transmits it to the second worker node 72 . The configuration and content of the pod termination request message transmitted here are the same as the configuration and content of the pod termination request message shown in FIG. The second worker node 72 receives the pod stop request message sent from the first master node 41 . As a result, the fourth worker node 53 stops the second pod 82 . As a result of stopping both the first pod 81 and the second pod 82, the server application corresponding to the server App 34 terminates.

In step S<b>77 , the second worker node 72 generates a pod stop response message for responding to the stop of the second pod 82 and transmits it to the first master node 41 . The configuration and content of the pod stop response message transmitted here are the same as the configuration and content of the pod stop response message shown in FIG.

In step S<b>78 , the first master node 41 generates an application termination response message for responding to termination of the server application, and transmits it to the server App 34 . The configuration and content of the application stop response message transmitted here are the same as the application stop response message shown in FIG. In step S<b>79 , the server App 34 generates the received application stop response message and transmits it to the client App 24 . Client App 24 terminates upon receiving the stop app response message.

In step S80, the server App 34 sends a measurement request message requesting measurement of network conditions. The structure and contents of the measurement request message transmitted here are the same as the structure and contents of the measurement request message shown in FIG.

In step S<b>81 , the server App 34 generates a measurement request message requesting measurement of the network status and transmits it to the first network monitor 42 . The structure and contents of the measurement request message transmitted here are the same as the structure and contents of the measurement request message shown in FIG. In step S<b>82 , the server App 34 generates a measurement request message requesting resource status measurement, and transmits the measurement request message to the first resource monitor 51 . The structure and contents of the measurement request message transmitted here are the same as those of the measurement request message shown in FIG. In step S<b>83 , the server App 34 generates a measurement request message requesting measurement of the network status and transmits it to the second network monitor 62 . The structure and contents of the measurement request message transmitted here are the same as those of the measurement request message shown in FIG. In step S<b>84 , the server App 34 generates a measurement request message requesting resource status measurement, and transmits it to the second resource monitor 71 . The structure and contents of the measurement request message transmitted here are the same as those of the measurement request message shown in FIG.

Based on steps S79-S84, the first network monitor 42, the first resource monitor 51, the second network monitor 62, and the second resource monitor 71 execute a series of processing procedures shown in FIG. As a result, the latest network status and resource status after termination of the application are reflected in the first local data store 44, the second local data store 64, and the global data store 32. FIG.

(Main effects of this embodiment)
Each effect produced by the container system 1 of the first embodiment can be similarly obtained in the present embodiment. Furthermore, in this embodiment, when executing a client-server type application, the server application can be efficiently arranged on the first MEC server 5 and the second MEC server 7 in the vicinity of the client application.

〔summary〕
A pod placement determination apparatus according to aspect 1 of the present invention provides a pod placement determination apparatus that moves from a first site where a first edge server having a first worker node is placed to a second edge server where a second edge server having a second worker node is placed. a measuring unit for measuring network conditions during communication to a site; a first receiving unit for receiving the resource conditions of the first worker node measured by the first edge server; the measured network conditions and the received resources; a storage unit that stores the status; and a second reception unit that receives network requirements and resource requirements requested by a first pod that constitutes an application as a container orchestration cluster. and determining whether to deploy the first pod on the first worker node based on the saved network and resource conditions and the received network and resource requirements. It is a configuration comprising a determination unit for determining.

In the pod placement determination apparatus according to aspect 2 of the present invention, in aspect 1 above, the determination unit determines that the network condition satisfies the requirements for the network and the resource condition satisfies the request for the resource. If the conditions are satisfied, it may be determined to place the first pod on the first worker node.

A pod placement determination apparatus according to aspect 3 of the present invention is, in aspect 1 or 2 above, wherein the first worker nodes belong to a plurality of different container orchestration clusters, and the first edge server includes the first worker node may be configured to include a resource status measuring unit that measures the resource status of each.

A pod arrangement determination apparatus according to aspect 4 of the present invention, in any one of aspects 1 to 3, may further include an image storage unit that stores an image of the first pod.

A pod placement determination method according to aspect 5 of the present invention provides a method for determining a pod placement from a first location where a first edge server comprising a first worker node is located to a second location where a second edge server comprising a second worker node is located. a measuring step of measuring a network condition during communication to a base; a first receiving step of receiving the resource condition of the first worker node measured by the first edge server; the measured network condition and the received resource; a storage unit for storing a state; and a second receiving step for receiving network requirements and resource requirements requested by a first pod that constitutes an application as a container orchestration cluster. and determining whether to deploy the first pod on the first worker node based on the saved network and resource conditions and the received network and resource requirements. a determining step of:

An edge server according to aspect 6 of the present invention includes worker nodes belonging to a plurality of different container orchestration clusters, a measurement unit that measures the resource status of the worker nodes, and a transmitter that transmits the measured resource status to a pod placement determination device. It is a configuration comprising a part.

A server according to aspect 7 of the present invention is a server communicably connected to a pod placement determination device and a second pod placement determination device placed at the second site, wherein the pod placement determination device transmits and the second network status and the second resource of the second worker node during communication from the second site to the first site, which are transmitted from the second pod placement determining device. a server information storage unit for storing the received network status, resource status, second network status, and second resource status; a second server receiver for receiving a second request to the network requested by two pods and a second resource status for the resource requested by the second pod; and storing the second network status and the second resource status. and a second decision unit that decides whether to deploy the second pod on the second worker node based on the received second request for the network and the second request for the resource. It is a configuration with

A terminal device according to aspect 8 of the present invention is a terminal device, wherein a first pod constituting an application as a container orchestration cluster is arranged in an edge server in a network to which the terminal device is connected, The configuration further comprises a launching module that does not belong to the container orchestration cluster for launching the application.

A container system according to aspect 9 of the present invention includes at least the pod arrangement determination device according to aspect 1 and the server according to aspect 7 above.

A container system according to aspect 10 of the present invention comprises a first edge server and a first base device arranged at a first base, a second edge server and a second base device arranged at a second base, and a server. a container system comprising: a first worker node belonging to a plurality of different container orchestration clusters; a first resource status measurement unit for measuring a first resource status of the first worker node; a first resource status transmission unit that transmits the measured first resource status to the first base device, and the first base device is a first reception unit that receives the first resource status. a first transmission unit configured to transmit the received first resource status to the server; and the second edge server includes second worker nodes belonging to a plurality of different container orchestration clusters; 2 a second resource status measurement unit that measures resource status; and a second resource status transmission part that transmits the measured second resource status to the second base device, wherein the second base device comprises a second receiver that receives the second resource status, and a second transmitter that transmits the received second resource status to the server, wherein the server receives the first resource status and a first server reception section for receiving the second resource status, and a server information storage section for storing the received first resource status and the second resource status.

In the container system according to aspect 11 of the present invention, in aspect 10 above, the first base device measures a first network status during communication from the first base to the second base. section, wherein the first transmission section transmits the measured first network status and the received first resource status to the server; a second network condition measuring unit for measuring a second network condition during communication from the to the first base, the second transmitting unit measures the measured second network condition and the received second network condition; 2 resource status to the server, the first server receiving unit receives the first network status, the first resource status, the second network status, and the second resource status, and the server information A storage unit stores the received first network status, first resource status, second network status, and second resource status, and the server configures an application as a container orchestration cluster. a second server receiving unit for receiving network requirements requested by one pod and resource requirements requested by the first pod; 2 network status, the second resource status, and the received request for the network and the received request for the resource, to which one of the first worker node and the second worker node the first worker node; It may be configured to determine whether to place one pod.

A program according to a twelfth aspect of the present invention is a program for causing a computer to function as the pod arrangement determination device according to the first aspect, comprising the measuring unit, the storage unit, the first receiving unit, and the second receiving unit. and a computer functioning as the determination unit.

[Example of implementation]
Each functional block of the first base device 4 (in particular, the first local MANO 43 and the first local data store 44) may be realized by a logic circuit (hardware) formed on an integrated circuit (IC chip) or the like. , may be implemented by software.

In the latter case, the first base device 4 is equipped with a computer that executes instructions of programs, which are software for realizing each function. This computer includes, for example, one or more processors, and a computer-readable recording medium storing the program. In the computer, the processor reads the program from the recording medium and executes it, thereby achieving the object of the present invention.

As the processor, for example, a CPU (Central Processing Unit) can be used. As the recording medium, a "non-temporary tangible medium" such as a ROM (Read Only Memory), a tape, a disk, a card, a semiconductor memory, a programmable logic circuit, or the like can be used.

Further, a RAM (Random Access Memory) for expanding the program may be further provided. Also, the program may be supplied to the computer via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. Note that one aspect of the present invention can also be implemented in the form of a data signal embedded in a carrier wave in which the program is embodied by electronic transmission.

The present invention is not limited to the embodiments described above, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining technical means disclosed in different embodiments are also included in the technical scope of the present invention. A new technical feature can be formed by combining the technical means disclosed in each embodiment.

1, 1A container system 2, 2A terminal device 3, 3A cloud server 4 first base device 5 cloud server 6 second base device 21 preference repository 22 image repository 23 startup App
24 client apps
31 Global MANO
32 Global Data Store 33 Origin Image Repository 34 Server App
41 first master node 42 first network monitor 43 first local MANO
44 First Local Data Store 45 First Local Image Repository 46 API
51 first resource monitor 52 first worker node 53 fourth worker node 61 second master node 62 second network monitor 63 second local MANO
64 second local data store 65 second local image repository 66 API
71 Second resource monitor 72 Second worker node 73 Fifth worker node 81 First pod 82 Second pod 83 Third pod

Claims (12)

A measurement unit that measures the network status during communication from a first location where a first edge server with a first worker node is located to a second location where a second edge server with a second worker node is located. When,
a first receiver that receives the resource status of the first worker node measured by the first edge server;
a storage unit for storing measured network conditions and received resource conditions;
a second receiver for receiving network requirements and resource requirements requested by the first pod, which constitutes an application as a container orchestration cluster;
determining whether to deploy the first pod on the first worker node based on the saved network and resource conditions and the received network and resource requirements; and a determining unit. The decision unit places the first pod on the first worker node when the network condition satisfies the requirements for the network and the resource condition satisfies the requirements for the resource. The pod placement determination device according to claim 1, wherein the pod placement determination device determines that: the first worker node belongs to a plurality of different container orchestration clusters;
3. The pod placement determination device according to claim 1, wherein said first edge server comprises a resource status measuring unit that measures resource status of said first worker node. The pod placement determination device according to any one of claims 1 to 3, further comprising an image storage unit that stores an image of said first pod. A measuring step of measuring network conditions during communication from a first site where a first edge server having a first worker node is located to a second site where a second edge server having a second worker node is located. When,
a first receiving step of receiving the resource status of the first worker node measured by the first edge server;
a storage unit for storing measured network conditions and received resource conditions;
a second receiving step of receiving a network requirement and a resource requirement requested by a first pod constituting an application as a container orchestration cluster;
determining whether to deploy the first pod on the first worker node based on the saved network and resource conditions and the received network and resource requirements; A pod placement determination method, comprising: a determining step; worker nodes belonging to different container orchestration clusters;
a measurement unit that measures the resource status of the worker node;
a transmitter that transmits the measured resource status to a pod placement determination device. A server communicatively connected to the pod placement determination device according to claim 1 and a second pod placement determination device placed at the second base,
The network status and the resource status transmitted from the pod placement determination device, and the second network status and the resource status during communication from the second base to the first base, transmitted from the second pod placement determination device. a first server receiver for receiving a second resource status of a second worker node;
a server information storage unit that stores the received network status, resource status, second network status, and second resource status;
a second server receiver for receiving a second request for the network requested by the second pod constituting the application and a second resource status for the resource requested by the second pod;
transferring the second pod to the second worker node based on the saved second network status and second resource status and the received second request to the network and second request to the resource; and a second decision unit that decides whether or not to arrange. a terminal device,
A first pod configuring an application as a container orchestration cluster is arranged in an edge server in a network to which the terminal device is connected,
A terminal device, further comprising a launch module that does not belong to the container orchestration cluster, for launching the application. A container system comprising at least the pod placement determination device according to claim 1 and the server according to claim 7. A container system comprising: a first edge server and a first base device arranged at a first base; a second edge server and a second base device arranged at a second base; and a server,
The first edge server
a first worker node belonging to a plurality of different container orchestration clusters;
a first resource status measuring unit that measures a first resource status of the first worker node;
a first resource status transmission unit that transmits the measured first resource status to the first base device;
The first base device is
a first receiver that receives the first resource status;
a first transmission unit that transmits the received first resource status to the server;
The second edge server,
a second worker node belonging to a plurality of different container orchestration clusters;
a second resource status measuring unit that measures a second resource status of the second worker node;
a second resource status transmission unit that transmits the measured second resource status to the second base device;
The second base device is
a second receiver that receives the second resource status;
a second transmission unit configured to transmit the received second resource status to the server;
The server is
a first server receiver that receives the first resource status and the second resource status;
a server information storage unit that stores the received first resource status and second resource status. The first base device further comprises a first network status measurement unit that measures a first network status during communication from the first base to the second base,
The first transmission unit transmits the measured first network status and the received first resource status to the server;
The second base device further comprises a second network status measuring unit that measures a second network status during communication from the second base to the first base,
the second transmission unit transmits the measured second network status and the received second resource status to the server;
the first server receiving unit receives the first network status, the first resource status, the second network status, and the second resource status;
the server information storage unit stores the received first network status, first resource status, second network status, and second resource status;
The server is
a second server receiver for receiving network requirements and resource requirements requested by the first pod, which constitutes an application as a container orchestration cluster;
Based on the saved first network condition, the first resource condition, the second network condition, and the second resource condition, and the received request to the network and the request to the resource; 11. The container system according to claim 10, wherein it is determined to which one of the first worker node and the second worker node the first pod is placed. A program for causing a computer to function as the pod arrangement determination device according to claim 1, wherein the computer functions as the measurement unit, the storage unit, the first reception unit, the second reception unit, and the determination unit. program to make

Images