JP7399427B2 - Server and container systems - Google Patents

Description

The present invention relates to a pod placement determining device, a pod placement determining 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 a personal computer and a mobile phone, the execution of the application can be made more efficient by having a cloud server located in the network execute the module that has a heavy load among the modules that make up the application. It may work well. This form of execution is called offloading. However, since the communication delay between the terminal device and the cloud server is generally large, the response time of the application may become longer. 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 sent to the MEC server. It has been proposed to reduce application response time by offloading some functionality.

Furthermore, applications in which an application (client) running on a terminal device and an application (server application) running on a cloud server communicate with each other (client-server type applications) are also often used. Even in such an application, communication delay can be reduced if the client communicates with the MEC server rather than with the cloud server.

Further, virtualization technology for physical computers includes hypervisor type and container type. Container-based virtualization technology is lighter in weight than hypervisor-based virtualization technology because the operating system kernel is shared between containers. Furthermore, it has become common to implement various modules that make up an application as containers, and to configure an application as a collection of multiple containers.

A system that automatically creates, deploys, scales, and monitors the status of containers is generally called a container orchestration system. Kubernetes, which is known as a typical container orchestration system, is disclosed in Non-Patent Document 1. In container orchestration systems, the minimum management target is often a pod containing one or more containers. 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. In a container orchestration cluster, a master node configures a pod cluster by placing pods on worker nodes, taking into account high availability and load balancing.

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

Typical container orchestration systems consider the load on worker nodes when determining container placement. However, since it does not take network conditions into consideration, there is a risk that each pod may be placed on each worker node with poor network conditions (such as large communication delays). Additionally, since the resource status of worker nodes is not taken into account, there is a possibility that installation of pods on worker nodes will fail.

The present invention has been made to solve the above problems, and its purpose is to enable pod placement that takes into account both the network situation and the resource situation of worker nodes.

In order to solve the above-mentioned problem, a pod placement determining device according to an aspect of the present invention provides a pod placement determination device that connects a first edge server including a first worker node to a first edge server including a second worker node. a measuring unit that measures a network status during communication to a second base where two edge servers are arranged; a first receiving unit that receives the resource status of the first worker node measured by the first edge server; a storage unit that stores the received network status and the received resource status; network requirements requested by a first pod that constitutes an application as a container orchestration cluster; and resource requests requested by the first pod; a second receiving unit that receives information about the first pod, the stored network status and resource status, and the received requirements for the network and the received requirements for the resource; and a determining unit that determines whether or not to place the computer in a worker node.

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

FIG. 1 is a diagram illustrating a configuration example of a container system according to a first embodiment. FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system when the container system measures network status and resource status. FIG. 3 is a diagram illustrating an example of a network status notification message. FIG. 3 is a diagram illustrating an example of a resource status notification message. It is a figure which shows an example of a base status notification message. FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system when a terminal device starts an application. FIG. 3 is a diagram illustrating an example of an application startup request message. FIG. 3 is a diagram illustrating an example of an application configuration information request message. It is a figure which shows an example of an application configuration information response message. FIG. 3 is a diagram illustrating an example of a pod placement determination request message. FIG. 3 is a diagram illustrating an example of a pod placement determination request message. FIG. 7 is a diagram illustrating an example of a pod placement determination response message. FIG. 7 is a diagram illustrating an example of a pod placement determination response message. FIG. 3 is a diagram showing an example of a pod placement request message. FIG. 3 is a diagram showing an example of a pod placement request message. FIG. 6 is a diagram illustrating an example of a pod placement response message. FIG. 3 is a diagram showing an example of a pod placement request message. FIG. 6 is a diagram illustrating an example of a pod placement response message. FIG. 3 is a diagram showing an example of a pod placement request message. FIG. 6 is a diagram illustrating an example of a pod placement response message. FIG. 6 is a diagram illustrating an example of a pod placement response message. FIG. 3 is a diagram illustrating an example of an application activation response message. FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system when stopping an application. It is a figure which shows an example of an application stop request message. FIG. 3 is a diagram illustrating an example of a pod stop request message. It is a figure which shows an example of a pod stop response message. It is a figure which shows an example of an application stop response message. FIG. 3 is a diagram showing an example of a measurement request message. FIG. 3 is a diagram showing an example of a measurement request message. FIG. 3 is a diagram showing an example of a measurement request message. FIG. 3 is a diagram showing an example of a measurement request message. FIG. 3 is a diagram showing an example of a measurement request message. FIG. 2 is a block diagram showing the configuration of a container system according to a second embodiment. FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system when a terminal device starts a client App. FIG. 3 is a diagram illustrating an example of an application request message. FIG. 3 is a diagram showing an example of a pod placement request message. FIG. 6 is a diagram illustrating an example of a pod placement response message. It is a figure which shows an example of an application response message. FIG. 2 is a sequence diagram showing the flow of a series of processes executed by the container system when stopping a 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 determining device), and a plurality of first MEC (Multi-access Edge Computing) servers 5 (first base device). 1 edge server), a second base device 6 (second pod placement determining 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 located in the cloud. In FIG. 1, two different first and second locations are illustrated. A base 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 base than the second base. Let the identifiers of the first base and second base be 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 receiving unit, second server receiving unit, second determining 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 greater than or equal to 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), and a first local data store 44. (a first receiving unit, a storage unit, a first transmission unit), a first local image repository 45 (image storage unit), and a 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), a first worker node 52, and a fourth worker node 53. . Let the identifiers of these modules be RmonID1, WnID1, and WnID4, respectively.

A second base device 6 and m second MEC servers 7 (m is an integer of 1 or more) 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 ), 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 includes a second resource monitor 71 (second resource status measuring unit, second resource status transmitting unit), 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 within the first base device 4. However, the first master node 41 may operate as an individual physical machine. Further, each first MEC server 5 is one independent physical machine. In each first MEC server 5, a first worker node 52 and a fourth worker node 53 as virtual machines are arranged. However, the present invention is not limited to this, and the first worker node 52 and the fourth worker node 53 may operate as separate 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 within the second base device 6. However, the second master node 61 may operate as an individual physical machine. Furthermore, each second MEC server 7 is one independent physical machine. In each second MEC server 7, a second worker node 72 and a fifth worker node 73 as virtual machines are arranged. However, the present invention is not limited to this, and 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 configure one container orchestration cluster as necessary. 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. Although not particularly shown, the second master node 61, first worker node 52, and 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 each pod when the user of the terminal device 2 starts a predetermined application near the first base. In this example, the application as a container orchestration cluster is configured by 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 within and outside the container orchestration cluster.

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

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

When the terminal device 2 connects to the network, it registers its own node, the third worker node, in a container orchestration cluster configured at the nearest base. In the example of FIG. 1, the terminal device 2 connects to the network near the first base. Thereby, 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 to the container orchestration cluster to which the first master node 41 belongs, as a third worker node.

(Understanding 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 the network status and resource status. In step S1, the first network monitor 42 at the first base communicates with the second network monitor 62 at the second base to determine the network status at the time of communication from the first base to the second base (first network status). Measure. The network status is, for example, a communication delay time from the first network monitor 42 to the second network monitor 62. Alternatively, the network status is a communication band that can be used when communicating from the first network monitor 42 to the second network monitor 62. Here, the first network monitor 42 measures both delay time and communication band as network conditions.

FIG. 3 is a diagram illustrating an example of a network status notification message. In step S2, the first network monitor 42 generates a network status notification message as shown in FIG. 3 to notify the measured network status, and sends it to the first local data store 44. As shown in FIG. 3, the network status notification message includes several different fields. Specifically, the network status notification message includes at least a Type field, a Source ID field, and a No of Destinations field. The Type field indicates the type of message that this field is included in. 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" indicating the network status notification message. The Source ID field indicates the identifier of the source from which the network status is measured. In FIG. 3, the value of the Source ID field is NmonID1. The No of Destinations field indicates the number of destinations for which the network status is being measured. In FIG. 3, the value of the No of Destinations field is 1.

The network status notification message further includes a corresponding triple field of a Destination ID field, a Delay field, and an Available Bandwidth field for each network status measurement target. In FIG. 3, since there is one measurement partner (second network monitor 62), the network status notification message includes one triple 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, ie, NmonID2. The Delay field indicates the delay time of communication from the measurement source (here, the first network monitor 42) indicated by the Source ID field to the measurement destination (here, the second network monitor 62) indicated by the Destination ID. The Available Bandwidth field indicates the 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 destination (here, the second network monitor 62) indicated by the Destination ID field.

In step S3, 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 that can be used in the first MEC server 5. Here, the number of virtual CPUs, memory capacity, storage capacity, number of GPUs, and memory capacity of the GPUs that the first MEC server 5 has are measured as the resource status. Furthermore, as the resource status, the number of virtual CPUs, memory capacity, storage capacity, number of GPUs, and memory capacity of GPUs that are being used by the first MEC server 5 are also measured.

FIG. 4 is a diagram illustrating an example of a resource status notification message. In step S4, the first resource monitor 51 generates a resource status notification message as shown in FIG. 4 to notify the measured resource status, and transmits it to the first local data store 44. A network status notification message includes several different fields. In the example of FIG. 4, the resource status notification message includes at least a Type field, a Source ID field, and a No of Nodes field. The value of the Type field is "resource status notification" which indicates 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, ie, RmonID1. The No of Nodes field indicates the number of worker nodes located in the first MEC server 5. Since two worker nodes are arranged in the first MEC server 5, the value of the No of Nodes field is 2 in this example.

Resource status notification messages further include, for each worker node, 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. It contains 11 sets of fields, including the In Use GPU Memory field and the In Use GPU Memory field. The Node ID field indicates the worker node identifier. The CPUs field indicates the number of virtual CPUs assigned to the worker node. The Memory field indicates the memory capacity allocated to the worker node. The Storage field indicates the storage capacity allocated to the worker node. The GPUs field indicates the number of GPUs assigned to the worker node. The GPU Memory field indicates the GPU memory capacity allocated to the worker node. The In Use CPUs field indicates the number of virtual CPUs in use by the worker node. The In Use Memory field indicates the amount of memory 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 includes two 11-set fields corresponding to the first worker node 52 and the fourth worker node 53. In the first set of 11 fields, 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. The Memory field indicates the memory capacity allocated to the first worker node 52. The Storage field indicates the storage capacity allocated to the first worker node 52. The GPUs field indicates the number of GPUs assigned to the first worker node 52. The GPU Memory field indicates the GPU memory capacity allocated to the first worker node 52. In Use CPUs indicates the number of virtual CPUs that the first worker node 52 is currently using. The In Use Memory field indicates the memory capacity that the first worker node 52 is using. The In Use Storage field indicates the storage capacity that the first worker node 52 is using. The In Use GPUs field indicates the number of GPUs that the first worker node 52 is using. The In Use GPU Memory field indicates the GPU memory capacity that the first worker node 52 is using.

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

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

FIG. 5 is a diagram illustrating an example of a base status notification message. In step S7, the first local data store 44 notifies the global data store 32 of a base status notification message. In the example of FIG. 5, the base status notification message includes a Type field, a Base ID field, a No of Destinations field, and a 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. The Base ID field indicates the base identifier. In the example of FIG. 4, the value of the Base ID field is BaseID1.

The No of Destinations field indicates the number of destinations for which the network status is being measured. In FIG. 5, the value of the No of Destinations field is 1. The site status notification message includes a triple field of a corresponding Destination ID field, Delay field, and Available Bandwidth field for each measurement target. Each value of these fields is the same as each value of the triplet field shown in FIG.

The No of Resource Stats field indicates the number of resource statuses to be notified. 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 base status notification message further includes two field groups (11×2 fields in total) following each Node ID field in FIG. 4, as many as the value of the No of Resource Stats field. In this example, the site status notification message includes n field groups.

The global data store 32 stores the network status of the first base and the resource status of the first worker node 52 and fourth worker node 53 in each first MEC server 5 of the first base (first resource situation) in its own storage space. From this point on, the series of processes from steps S1 to S7 are repeatedly executed periodically.

Although detailed explanation will be omitted, the same processing as steps S1 to S7 described above is executed at the second base as well. As a result, the global data store 32 stores the network status of the second base (second network status) included in the notified base status notification message, and the second worker node 72 and fifth worker node in each second MEC server 7 of the second base. The resource status of the worker node 73 (second resource status) is also saved in its own storage space.

(Application startup process)
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 starts an application. The user operates the terminal device 2 and inputs an operation to the terminal device 2 to start a predetermined application. In step S11, when the terminal device 2 detects this operation, it executes the startup App 23 for starting the application. The startup App 23 is stored in the image repository 22 in the terminal device 2 in advance. The startup App 23 is a module used to start and end an application. By executing the startup App 23, the first pod 81, the second pod 82, and the third pod 83 that constitute the application can be placed in the container orchestration cluster. However, unlike the first pod 81, the second pod 82, and the third pod 83, the startup 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 the preferences associated with the application. Preferences are 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 one wishes to offload part of the application to the first MEC server 5 or the second MEC server 7. In this example, it is assumed that the user has specified in his preferences that he desires offloading. Note that the contents of the preferences may be specified in advance by the cloud server 3 rather than by the user.

(Application launch request)
FIG. 7 is a diagram illustrating an example of an application startup request message. In step S12, the startup App 23 generates an application startup request message as shown in FIG. 7, and sends it to the first App API 46 in the first base. The application launch request message is a message for requesting the launch of an application. In the example of FIG. 7, the application launch request message includes a Type field, a User ID field, a Credential field, an App ID field, and a Preference field. The value of the Type field is "application launch request" indicating the message type of the application launch request message. The 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 and 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 being executed. In the example of FIG. 8, the value of the App ID field is AppID1. The Preference field indicates information that the startup App 23 reads from the preference repository 21.

When connecting to the network, the terminal device 2 acquires the address of the first AppAPI 46 located at the first base nearest to the terminal device 2 . In step S13, the first App API 46 authenticates and authorizes the user of the terminal device 2 based on the received application activation request message. At this time, the first App API 46 may access a control plane such as a mobile phone network.

(App configuration information request)
FIG. 8 is a diagram illustrating an example of an application configuration information request message. In step S14, the first App API 46 generates an application configuration information request message as shown in FIG. 8, and sends it to the first local image repository 45. 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 being executed, specifically AppID1.

The first local image repository 45 can temporarily hold images of the first pod 81, second pod 82, and third pod 83 that constitute the 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 structure and contents of the application configuration information request message transmitted here are the same as the structure and contents of the application configuration information request message shown in FIG.

(App configuration information response)
FIG. 9 is a diagram illustrating an example of an application configuration information response message. In the storage space of the origin image repository 33, all pod images of all applications executable by the container system 1 are stored in advance. Upon receiving the application configuration information request message, the origin image repository 33 stores the images of the first pod 81, second pod 82, and third pod 83 that constitute the application indicated by the application configuration information request message in its own storage space. Read from. In step S16, the origin image repository 33 generates an application configuration information response message as shown in FIG. 9 based on each read pod image, and sends it to the first local image repository 45.

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 a Type field, an App ID field, and a 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 being executed, specifically AppID1. The No of Pods field indicates the number of pods that make up the application. In the example of FIG. 9, the value of the No of Pods field is 3.

The application configuration information response message further includes, for one pod, septet fields including 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. The Pod ID field indicates the pod identifier. The No of CPUs field indicates the number of virtual CPUs the pod requires. The Memory field indicates how much memory the pod requires. The Storage field indicates how much storage the pod requires. The No of GPUs field indicates the number of GPUs the pod requires. The GPU Memory field indicates the GPU memory capacity required by the pod. The Net Req field indicates the network requirements required by the pod.

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

The application configuration information response message further includes a septet field regarding the second pod 82 and a septet field regarding the third pod 83.

When the first local image repository 45 receives the application configuration information response message, it 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, the first local image repository 45 secures storage space according to an LRU (Least Recently Used) algorithm or the like. In step S17, the first local image repository 45 transmits the received application configuration information response message to the first App API 46. The structure and contents of the application configuration information response message transmitted at this time are the same as the structure and contents of the application configuration information response message shown in FIG.

(Pod placement determination request)
FIG. 10 is a diagram illustrating an example of a pod placement determination request message. In step S18, the first App API 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 a Type field, an App ID field, and a No of Pods field. The value of the Type field is "Pod placement determination request" which indicates the message type of the Pod placement determination request message. The value of the App ID field is the identifier of the application being executed, specifically AppID1. The No of Pods field indicates the number of pods that make up the application. The application is composed of three pods, one of which is placed on 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, septet fields including 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 determination request message includes two septet fields. The Pod ID field indicates the pod identifier. The No of CPUs field indicates the number of virtual CPUs the pod requires. The Memory field indicates how much memory the pod requires. The Storage field indicates how much storage the pod requires. The No of GPUs field indicates the number of GPUs the pod requires. The GPU Memory field indicates the GPU memory capacity required by the pod. The Net Req field indicates the network requirements required by the pod.

In the example of FIG. 10, the Pod ID field included in the first septet 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. The Memory field indicates the memory capacity required by the first pod 81. The Storage field indicates the storage capacity required by the first pod 81. The No of GPUs field indicates the number of GPUs required by the first pod 81. The GPU Memory field indicates the GPU memory capacity required by the first pod 81. The Net Req field indicates the requirements for the network that the first pod 81 requires. The remaining six fields, such as the No of CPUs field, indicate the requirements for the resources that the first pod 81 requires.

In the example of FIG. 10, the Pod ID field included in the second septet field indicates the identifier of the second pod 82. Therefore, the value of the Pod ID field is PodID2. The values of the No of CPUs field and the like included in the second septet field are values related to the second pod 82, similar to the first septet 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 requirements for resources needed by the second pod 82.

(Determination of placement of 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 second pod 82 indicated by the received pod placement determination request message in any worker node within the first base. Determine whether or not. At this time, the first local MANO 43 stores the network status regarding the first base and the resource status regarding 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 regarding pod 81, it is determined whether to place the first pod 81 on the first worker node 52. Specifically, it is first determined whether the network status regarding the first base satisfies the request information to the network regarding the first pod 81 included in the pod placement determination request message. If it is determined that the resource status of any one of the first MEC servers 5 in the first base stored in the first local data store 44 is satisfied, the resource status of any one of the first MEC servers 5 in the first base stored in the first local data store 44 is determined to be the first pod included in the pod placement determination request message. 81 is satisfied.

Here, the network status of the first base 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 satisfies the requirements for the network status 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 in the first base.

Further, here, although the network status of the first base satisfies the network status requirements regarding the second pod 82, the resource status of each of the first worker node 52 and fourth worker node 53 of all the first MEC servers 5 is It is assumed 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 on the first worker nodes 52 or fourth worker nodes 53 of all the first MEC servers 5 in the first base.

FIG. 11 is a diagram illustrating an example of a pod placement determination request message. In step S19, if the second pod 82 cannot be placed at the first base, the first local MANO 43 issues a pod placement determination request as shown in FIG. 11 in order to place the second pod 82 at the second base. A message is generated and sent 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.

(Determination of placement of second pod 82)
In step S20, upon receiving the pod placement determination request message, the global MANO 31 determines whether the second pod 82 can be placed in the second MEC server 7 at the second base. At this time, the global MANO 31 stores the network status of the second base (second network status) and the resource status of each second MEC server 7 stored in the global data store 32, and the information contained in the received pod placement determination request message. Based on the network requirements and resource requirements regarding the two pods 82, it is determined whether or not to place the second pods 82 on the second worker nodes 72. Specifically, it is first determined whether the network status regarding the second base satisfies the request information to the network regarding the second pod 82 included in the pod placement determination request message. If it is determined that the resource status of any second MEC server 7 in the second base stored in the global data store 32 is satisfied, then the resource status of any second MEC server 7 in the second base 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 base 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 satisfies the requirements for the network regarding the second pod 82. The requirements shall be met. 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 in the second base.

(Pod placement decision response)
FIG. 12 is a diagram illustrating an example of a pod placement determination 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 decision response message is a message for responding that the placement of the second pod 82 has been decided. In the example of FIG. 12, the pod placement determination response message includes a Type field, an App ID field, and a No of Pods field. The value of the Type field is “pod placement decision response” which indicates the message type of the pod placement decision response message. The value of the App ID field is the identifier of the application being 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 triple field including a Pod ID field, a Base ID field, and a Node ID. Here, since there is one pod, the pod placement determination response message further includes one triplet field. The Pod ID field indicates the pod identifier. 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 located. In the example of FIG. 12, the second pod 82 is placed at the second base, so the value of the Base ID field is BaseID2. The Node ID field indicates the identifier of the worker node where the pod is placed. In the example of FIG. 12, the second pod 82 is placed in the second worker node 72 of the second MEC server 7 at the second base, so the Node ID field is WnID2.

FIG. 13 is a diagram illustrating an example of a pod placement determination response message. In step S21, upon receiving the pod placement determination response message regarding the second pod 82, the first local MANO 43 generates a pod placement determination response message as shown in FIG. 13 and transmits it to the first App API 46. The structure of the pod placement decision response message shown in FIG. 13 is the same as the structure of the pod placement decision response message shown in FIG. 12, with items related to the first pod 81 added. Therefore, a detailed explanation of the pod placement determination response message shown in FIG. 13 will be omitted.

(Pod placement request)
FIG. 14 is a diagram illustrating an example of a pod placement request message. In step S22, upon receiving the pod placement determination response message, the first App API 46 generates a pod placement request message as shown in FIG. 15 and transmits it to the first master node 41. 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 a Type field, an App ID field, and a 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 being executed, specifically AppID1. The No of Pods field indicates the number of pods. In the example of FIG. 14, the value of the No of Pods field is 3 because the pod placement request message requests placement of the three first pods 81, second pods 82, and third pods 83.

The pod placement request message further includes a quadruple field for each pod: a Pod ID field, a Base ID field, a Node ID field, and a Repository ID field. In the example of FIG. 14, the 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. The Pod ID field indicates the pod identifier. The Base ID field indicates the identifier of the base where the pod is located. The 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 is to 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 placed, ie, 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, ie, 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 placed, ie, WnID2. The value of the Repository ID field is LirID2. The value of the Pod ID field in the third quadruple field is the identifier of the third pod 83, ie, PodID3. The value of the Base ID field is the identifier of the first base 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 placed, ie, WnID3. The value of the Repository ID field is LirID1.

(Arrangement of first pod 81)
FIG. 15 is a diagram illustrating an example of a pod placement 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 placement request message shown in FIG. 15 is the same as the configuration of the pod placement request message shown in FIG. 14 except that the items for the second pod 82 and the third pod 83 are removed. 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 illustrating 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 S25, when the first worker node 52 finishes arranging the first pod 81, it generates a pod arrangement response message and transmits it to the first master node 41. The pod placement response message is a message for responding that 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 placement response" indicating the message type of the Pod placement response message. The value of the App ID field is the identifier of the application being executed, specifically AppID1.

The pod placement response message further includes, for one pod, a double field consisting of a Pod ID field and a Status field. The Pod ID field indicates the pod identifier. In the example of FIG. 16, the value of the Pod ID field is PodID1. The Status field indicates the completion status of the pod placement process. In the example of FIG. 16, the value of the Status field is "OK" indicating that the arrangement of the first pod 81 has been successfully completed.

(Arrangement of third pod 83)
FIG. 17 is a diagram illustrating 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 sends it to the third worker node. The structure of the pod placement request message shown in FIG. 17 is the same as the structure of the pod placement request message shown in FIG. 15. 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 illustrating an example of a pod placement response message. In step S26, when the third worker node finishes placing the third pod 83, it generates a pod placement response message as shown in FIG. 18 and sends it to the first master node 41. The structure of the pod placement response message shown in FIG. 18 is the same as the structure of the pod placement response message shown in FIG. 16. In the example of FIG. 18, the pod placement response message includes various information regarding completion of placement of the third pod 83.

(Arrangement of second pod 82)
FIG. 19 is a diagram illustrating 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 structure of the pod placement request message shown in FIG. 19 is the same as the structure of the pod placement request message shown in FIG. 15. In the example of FIG. 19, the pod placement request message includes 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 illustrating an example of a pod placement response message. In step S28, when the second worker node 72 finishes placing the second pod 82, it generates a pod placement response message as shown in FIG. 20 and sends it to the first master node 41. The structure of the pod placement response message shown in FIG. 20 is the same as the structure of the pod placement response message shown in FIG. 16. In the example of FIG. 20, the pod placement response message includes various information regarding completion of placement of the second pod 82.

As the first pod 81, second pod 82, and third pod 83 are properly arranged as described above, the application is started. Note that 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 arbitrarily changed. For example, the third pod 83 may be placed first, then the first pod 81, and finally the second pod 82.

(pod placement response)
FIG. 21 is a diagram illustrating an example of a pod placement response message. In step S29, the first master node 41 generates a pod placement response message as shown in FIG. 21 and sends it to the first App API 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 completion of placement of each of the first pod 81, second pod 82, and third pod 83.

FIG. 22 is a diagram illustrating an example of an application activation response message. In step S30, upon receiving the pod placement response message, the first App API 46 generates an application activation response message as shown in FIG. 22 and sends it to the activation App 23. The application activation response message is a message for responding that an application has been activated. The application activation 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 launch response" indicating the message type of the application launch response message. The value of the App ID field is the identifier of the application being executed, specifically AppID1. The Status field indicates the completion status of the placement process. In the example of FIG. 22, "OK" indicates that the placement process has ended normally.

The application started as described above continues to be executed by the first pod 81, the second pod 82, and the third pod 83 working together. By starting the application, the resources available in the first MEC server 5, the second MEC server 7, and the network decrease by the amount of resources consumed by the application. Even after the application is started, the container system 1 keeps track of the network status between the first base and other bases, the resource status of each first MEC server 5, and the second base and other bases, as shown in FIG. The network status between the second MEC server 7 and the resource status of each second MEC server 7 is periodically measured. Thereby, the network status and resource status stored in the first local data store 44, the second local data store 64, and the global data store 32 are updated regularly. Therefore, the information stored in the first local data store 44, the second local data store 64, and the global data store 32, respectively, can be kept up to date.

(Stopping the application)
FIG. 23 is a sequence diagram showing the flow of a series of processes executed by the container system 1 when stopping an application. The 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 illustrating an example of an application stop request message. In step S31, when the startup App 23 receives an application stop instruction from the terminal device 2, it generates an application stop request message as shown in FIG. 24, and sends it to the first App API 46. The application stop request message includes a Type field, a User ID field, a Credential field, and an App ID field. The value of the Type field is "application stop request" indicating the message type of the application stop request message. The 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 includes user authentication and 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 S32, the first App API 46 performs authentication and authorization of the user of the terminal device 2. At this time, the first App API 46 may access a control plane such as a mobile phone network. In step S33, if the first App API 46 succeeds in user authentication and authorization, it transmits the received application stop request message to the first master node 41.

FIG. 25 is a diagram illustrating 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 sends it to the first worker node 52. The pod stop request message shown in FIG. 25 is a message for requesting the first pod 81 to stop. In the example of FIG. 25, the pod stop request message includes a Type field, an App ID field, and a 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. The Pod ID field indicates the pod identifier. 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 base where the first pod 81 is located, ie, BaseID1. The 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 placed, ie, WnID1.

FIG. 26 is a diagram illustrating 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 worker node 52 successfully stops the first pod 81, it generates a pod stop response message as shown in FIG. 26 and sends it to the first master node 41. 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 a Type field, an App ID field, and a 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. In this example, it is 1.

The pod stop response message further includes, for one pod, a double field consisting of a Pod ID field and a Status field. The Pod ID field indicates the pod identifier. In the example of FIG. 26, the value of the Pod ID field is the identifier of the first pod 81 to be stopped, ie, PodID1. The Status field indicates the completion status of the process. In the example of FIG. 26, "OK" indicates normal termination.

In step S36, the first master node 41 generates a pod stop request message for stopping the third pod 83, and sends 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 sends 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 a detailed explanation will be omitted.

In step S38, 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 S39, the second worker node 72 generates a pod stop response message for responding to the fact that the second pod 82 has been stopped, and sends 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 a detailed explanation will be omitted.

FIG. 27 is a diagram illustrating an example of an application stop response message. In step S40, the first master node 41 generates an application stop response message and sends it to the first App API 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” which indicates 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 completion status of the process. In the example of FIG. 2, the value of the Status field is "OK" indicating normal termination of the application.

In step S<b>41 , upon receiving the application stop response message, the first App API 46 transmits the received application stop response message to the startup App 23 . In step S42, the startup App 23 ends upon receiving the application stop response message. 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 App API 46 generates a measurement request message as shown in FIG. 28 and sends it to the first network monitor 42. The measurement request message shown in FIG. 28 is a message for requesting measurement of network status. The 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, ie, NmonID1.

FIG. 29 is a diagram showing an example of a measurement request message. In step S44, the first App API 46 generates a measurement request message as shown in FIG. 29, and transmits it to the first resource monitor 51. The measurement request message shown in FIG. 29 is a message for requesting measurement of resource status. The 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, ie, RmonID1.

FIG. 30 is a diagram showing an example of a measurement request message. In step S45, the first App API 46 generates a measurement request message as shown in FIG. 30 and sends it to the second App API 66. The measurement request message shown in FIG. 30 is a message for requesting measurement of network status and resource status. The 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, ie, NmonID2. The value of the second Target ID field is the identifier of the second resource monitor 71, ie, RmonID2.

FIG. 31 is a diagram showing an example of a measurement request message. In step S46, the second App API 66 generates a measurement request message as shown in FIG. 31 and sends it to the second network monitor 62. The measurement request message shown in FIG. 31 is a message for requesting measurement of the network status. The 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, ie, NmonID2.

FIG. 32 is a diagram showing an example of a measurement request message. In step S47, the second App API 66 generates a measurement request message as shown in FIG. 32 and transmits it to the second resource monitor 71. The measurement request message shown in FIG. 32 is a message for requesting measurement of resource status. The 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, ie, RmonID2.

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

(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 it 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 to place the first pod 81 in the first MEC server 5 based on the network status and resource status stored in the first local data store 44 . This makes it possible to arrange the first pod 81 in consideration of the network situation and resource situation, so that the first pod 81 can be arranged on the optimal first worker node 52.

The first local MANO 43 sends the first MEC server 5 to the first MEC server 5 that satisfies the network requirements and resource requirements requested by the first pod 81 based on the network status and resource status stored in the first local data store 44. It is decided to place the first pod 81. Thereby, the first pod 81 can be reliably placed.

The second MEC server 7 measures the resource status of the second worker node 72 using the second resource monitor 71 and transmits it 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 determines whether to place the second pod 82 on the second worker node 72 of the second MEC server 7 by considering the network status and resource status regarding the second base stored in the global data store 32. . As a result, it is possible to arrange pods in consideration of network conditions, so each pod can be placed in each worker node in a good network condition with little communication delay. Furthermore, it is possible to optimally place pods between widely distributed locations via the network.

The first MEC server 5 can measure the correct resource status of the first worker node 52 by using the first resource monitor 51 even if the first worker node 52 belongs to multiple container orchestration clusters. This makes it possible to determine whether or not to place the first pod 81 on the first worker node 52 based on the correct resource status of the first worker node 52, thereby reducing the possibility of failure in placing the first pod 81. can be done.

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. I can do it. 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. , it is possible to accurately grasp the resource status of all worker nodes.

After starting the application to be executed as a container orchestration cluster, the first pod 81 configuring the application to be executed as a container orchestration cluster is placed in the first MEC server 5 in the network to which the terminal device 2 is connected. . Further, the second pod 82 is placed in the second MEC server 7 in the network to which the terminal device 2 is connected. Furthermore, the third pod 83 is placed in the terminal device 2. On the other hand, the startup App 23 for starting an application does not belong to the container orchestration cluster. Therefore, during execution of the application, the startup 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. Further, communication via the relay pod is not performed between the first pod 81, the second pod 82, and the third pod 83 that constitute the application. With these, it is possible to prevent communication paths between pods from becoming redundant when starting an application and when executing the application after starting.

When newly introducing the container system 1 into an existing container orchestration system, no changes are required to 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 on the terminal device 2 can be efficiently offloaded to the first MEC server 5 and the second MEC server 7.

(Modified example)
In the container system 1, the first worker node 52 may belong to a plurality of different container orchestration clusters, and the second worker node 72 may belong to a plurality of different container orchestration clusters. Also in this case, the first MEC server 5 uses the first resource monitor 51 to accurately measure the resource status of the first worker node 52 and the fourth worker node 53. 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 each received resource status 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 placement of the first pod 81 instead of the first base device 4. In this example, the first App API 46 notifies the global MANO 31 instead of the first local MANO 43 of the pod placement determination request message shown in FIG. Upon receiving the pod placement determination request message, the global MANO 31 determines which of the first base and the second base to place all of the first pod 81 and the second pod 82 indicated by the received pod placement determination request message. Determine.

Specifically, the global MANO 31 stores 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 resource status of each second MEC server 7, which are stored in the global data store 32. Based on the network requirements and resource requirements regarding 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 base and the resource status of the first worker node 52 of the first MEC server 5 satisfy the network requirements and resource requirements regarding the first pod 81, the global MANO 31 It is decided to allocate it to the first worker node 52 of the first MEC server 5. Alternatively, if the network status of the second base and the resource status of the second worker node 72 of the second MEC server 7 satisfy the network requirements and resource requirements regarding the first pod 81, the global MANO 31 It is decided to allocate it to the second worker node 72 of the second MEC server 5. In this way, the global MANO 31 can select the optimal MEC server (worker node) in which the first pod 81 should be placed, taking into consideration the network situation of each base and the network situation of each worker node.

At the time of receiving the application configuration information request message, the first local image repository 45 stores each of the first pod 81, second pod 82, and third pod 83 that constitute the application indicated by the received application configuration information request message. The image may be saved in advance. In this case, the first local image repository 45 does not transmit the received application configuration information request message to the origin image repository 33, but instead sends the first pod 81 and the second pod 82 that configure the application indicated by the application configuration information request message to the origin image repository 33. , 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 sends it to the first App API 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 delays can be reduced. Furthermore, communication traffic between the cloud and each location can 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 a 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 App34 is a server application in a client-server type application.

In this embodiment, the container orchestration cluster includes a first master node 41, a first worker node 52, a fourth worker node 53, and a relay pod (not shown). In FIG. 33, the server application corresponding to the server App34 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. An example is shown. The identifiers of each module shown in FIG. 34 are the same as those 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 App34 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 starts the client App 24. The user operates the terminal device 2 and inputs an operation to start the client App 24 into the terminal device 2 . In step S51, when the terminal device 2A detects this operation, it starts the client App24.

FIG. 35 is a diagram illustrating an example of an application request message. In step S52, the activated client App24 transmits an application request message to the server App34. The application request message is a message for transmitting a request to the server App34. The application request message may be an HTTPRequest message. It is assumed that the server App34 can learn 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 a Type field, a User ID field, a Credential field, an App ID field, and a Request field. The value of the Type field is "application request" indicating the message type of the application request message. The 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 includes user authentication and 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 App34, specifically AppID1. The Request field indicates the content of the request from the client App24. In step S53, the server App34 authenticates and authorizes the user of the terminal device 2 based on the received application request message.

In step S54, if the server App34 succeeds in user authentication and authorization, it generates a pod placement determination request message and transmits it to the first local MANO 43 in the first base. 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 App34. This pod placement determination request message is the same as the pod placement determination request message shown in FIG.

(Determination of placement of first pod 81)
Upon receiving the pod placement determination request message, the first local MANO 43 determines whether all of the first pod 81 and second pod 82 indicated by the received pod placement determination request message can be placed in each worker node within the first base. Decide whether The details of the determination method are the same as those of the first embodiment, so detailed explanation will be omitted. Here, it is assumed that the first local MANO 43 decides to place the first pod 81 in the first worker node 52 of the first MEC server 5 in the first base. Further, 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 all the other first MEC servers 5 in the first base. As a result, in step S55, the first local MANO 43 generates a pod placement determination request message and sends 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. Further, its structure and contents are the same as the structure and contents of the pod placement determination request message shown in FIG.

(Determination of placement of second pod 82)
Upon receiving the pod placement determination request message, the global MANO 31 determines whether or not to place the second pod 82 in the second MEC server 7 at the second base. The details of the determination method are the same as those in the first embodiment, so a detailed explanation 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 . Thereby, 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. The configuration and contents of the pod placement determination response message transmitted here are the same as the configuration and contents of the pod placement determination response message shown in FIG. 12.

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 contents of the pod placement determination response message transmitted here are the same as the configuration and contents of the pod placement determination response message shown in FIG. 13.

FIG. 36 is a diagram illustrating an example of a pod placement request message. In step S58, upon receiving the pod placement determination response message, the server App generates a pod placement request message as shown in FIG. 36 and transmits it to the first master node 41. 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 a Type field, an App ID field, and a 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 App34, 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 the three first pods 81 and the second pods 82.

The pod placement request message further includes a quadruple field for each pod: a Pod ID field, a Base ID field, a Node ID field, and a Repository ID field. In the example of FIG. 36, since placement of two first pods 81 and second pods 82 is requested, 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 Base ID1 of the first base where the first pod 81 is placed. The value of the Node ID field is the identifier of the first worker node 52 where the first pod 81 is placed, ie, 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, ie, 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 placed, ie, WnID2. The value of the Repository ID field is LirID2.

(Arrangement of first pod 81)
In step S59, 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 structure and contents of the pod placement request message transmitted here are the same as the structure and contents of the pod placement request message shown in FIG. 15. Upon receiving the pod placement request message, 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 S60, 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 structure and contents of the pod installation response message transmitted here are the same as the structure and contents of the pod installation response message shown in FIG.

(Arrangement of second pod 82)
In step S61, 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 structure and contents of the pod placement request message transmitted here are the same as the structure and contents 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 S62, 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 structure and contents of the pod installation response message transmitted here are the same as the structure and contents of the pod installation response message shown in FIG. 17.

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

FIG. 38 is a diagram illustrating an example of an application response message. In step S64, the server App34 generates an application response message as shown in FIG. 38 and sends it to the client App24. The application response message is a message for responding to the activation of the server application corresponding to the server App34. In the example of FIG. 38, the application response message includes a Type field, a Status field, a Redirect field, and a 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 completion status of the process. In this example, "OK" indicates normal termination of startup of the server application corresponding to the server App34. The Redirect field indicates the identifier of the destination module for subsequent application request messages. In the example of FIG. 38, this is the relay pod identifier, ie, RelayPodID1. The Response field indicates the response content.

The server application as a container orchestration cluster started as described above continues to be executed as the server App 34 by the first pod 81 and the second pod 82 working together. From now on, the communication partner of the client App24 is not the server App34 on the cloud server, but the server application as a container orchestration cluster built at the first base and the second site. Therefore, in step S65, the client App24 sends a new application request message not to the server App34 on the cloud server but to the first worker node 52 where the first pod 81 is placed. When the first worker node 52 receives the application request message, the first pod 81 operates in cooperation with the second pod 82 to execute the process requested by the application request message. In step 66, the first worker node 52 generates an application response message for responding to the processing by the server App34 as a container orchestration cluster, and sends it to the client App24.

In this embodiment, by starting the server application as a container orchestration cluster, each resource available in the first MEC server 5, the second MEC server 7, and the network is consumed by the server application corresponding to the server App34. Reduced by the amount of resources. Even after starting the server application corresponding to the server App34, the container system 1A keeps track of 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 resource status of each second MEC server 7 is periodically measured. Thereby, the network status and resource status stored in the first local data store 44, the second local data store 64, and the global data store 32 are updated regularly. Therefore, the information stored in the first local data store 44, the second local data store 64, and the global data store 32 can be kept up to date.

(Stopping the 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 into the terminal device 2A an operation for terminating the server application operating as the server App34. In step S71, when the terminal device 2A detects this operation, the client App24 generates an application termination request message for requesting termination of the server application, and transmits it to the server App34. The structure and contents of the application termination request message transmitted here are the same as the structure and contents of the application termination request message shown in FIG. 24.

The server App34 receives the application termination request message sent from the client App24. In step S72, the server App34 authenticates and authorizes the user of the terminal device 2 based on the received application termination request message. In step S73, if the server App34 succeeds in user authentication and authorization, it transmits the received application stop request message to the first master node 41.

The first master node 41 receives the application stop request message sent from the server App34. In step S74, the first master node 41 generates a pod stop request message for requesting to stop the first pod 81, and transmits it to the first worker node 52. The structure and contents of the pod stop request message transmitted here are the same as the structure and contents 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 S75, the first worker node 52 generates a pod stop response message for responding to the stop of the first pod 81, and sends it to the first master node 41. The structure and contents of the pod stop response message transmitted here are the same as the structure and contents of the pod stop response message shown in FIG. 26.

The first master node 41 receives the pod stop response message sent from the first worker node 52. In step S76, the first master node 41 generates a pod stop request message for requesting to stop the second pod 82, and sends it to the second worker node 72. The structure and contents of the pod stop request message transmitted here are the same as the structure and contents of the pod stop request message shown in FIG. 27. 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 both the first pod 81 and the second pod 82 being stopped, the server application corresponding to the server App34 is terminated.

In step S77, the second worker node 72 generates a pod stop response message for responding to the stop of the second pod 82, and sends it to the first master node 41. The structure and contents of the pod stop response message transmitted here are the same as the structure and contents of the pod stop response message shown in FIG. 27.

In step S78, the first master node 41 generates an application stop response message for responding to stop the server application, and sends it to the server App34. The configuration and contents of the application stop response message sent here are the same as the application stop response message shown in FIG. 27. In step S79, the server App34 generates the received application stop response message and sends it to the client App24. The client App24 terminates upon receiving the application stop response message.

In step S80, the server App34 transmits a measurement request message requesting measurement of the network status. 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. 28.

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. 28. In step S<b>82 , the server App 34 generates a measurement request message requesting measurement of the resource status, and transmits it to the first resource monitor 51 . 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. 29. In step S83, the server App34 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 the structure and contents of the measurement request message shown in FIG. 30. In step S84, the server App34 generates a measurement request message requesting measurement of the resource status, and transmits it to the second resource monitor 71. 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. 31.

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

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

〔summary〕
A pod placement determining device according to aspect 1 of the present invention is arranged to move from a first base where a first edge server including a first worker node is located to a second base where a second edge server including a second worker node is located. a measuring unit that measures a network status during communication to a base; a first receiving unit that receives a resource status of the first worker node measured by the first edge server; and a measured network status and received resources. a storage unit that stores a status; and a second receiving unit that receives network requirements requested by a first pod and resource requests requested by the first pod that constitute an application as a container orchestration cluster. , determining whether to place the first pod on the first worker node based on the saved network status and resource status and the received network requirements and resource requirements; The configuration includes a determining section to

In the pod placement determining device according to aspect 2 of the present invention, in the above aspect 1, the determining unit determines that the network status satisfies the requirements for the network, and that the resource status satisfies the requirements for the resource. If the conditions are met, the configuration may be such that it is determined to place the first pod on the first worker node.

In the pod placement determining device according to aspect 3 of the present invention, in the above aspect 1 or 2, the first worker node belongs to a plurality of different container orchestration clusters, and the first edge server The configuration may include a resource status measurement unit that measures the resource status of the resource status.

A pod placement determining device according to a fourth aspect of the present invention may be configured to further include an image storage unit that stores an image of the first pod in any of the above-mentioned aspects 1 to 3.

A pod placement determining method according to aspect 5 of the present invention is arranged to move from a first base where a first edge server having a first worker node is located to a second base where a second edge server having a second worker node is located. a measuring step of measuring a network condition at the time of communication to a base; a first receiving step of receiving a resource condition of the first worker node measured by the first edge server; and a measured network condition and the received resource. a storage unit that stores a status; a second receiving step that receives network requirements requested by a first pod constituting an application as a container orchestration cluster and resource requirements requested by the first pod; , determining whether to place the first pod on the first worker node based on the saved network status and resource status and the received network requirements and resource requirements; and a step of determining.

The edge server according to aspect 6 of the present invention includes worker nodes belonging to a plurality of different container orchestration clusters, a measuring unit that measures the resource status of the worker node, and a transmitter that transmits the measured resource status to a pod placement determination device. The configuration includes a section.

A server according to aspect 7 of the present invention is a server that is communicably connected to a pod placement determining device and a second pod placement determining device located at the second base, and is configured to transmit information from the pod placement determining device. the second network status and the resource status of the second worker node at the time of communication from the second base to the first base, which were transmitted from the second pod placement determining device; a first server receiving unit that receives the network status, the resource status, the second network status, and the second resource status that have been received; a server information storage unit that stores the received network status, the resource status, the second network status, and the second resource status; a second server receiving unit that receives a second request for a network requested by two pods and a second resource status for a resource requested by the second pod; and the second network status and second resource status are stored. and a second determining unit that determines whether to place the second pod on the second worker node based on the received second request for the network and second request for the resource. The configuration is equipped with the following.

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

A container system according to aspect 9 of the present invention is configured to include at least the pod placement determining device according to aspect 1 described above and the server according to aspect 7 described above.

A container system according to aspect 10 of the present invention includes a first edge server and a first base device located at a first base, a second edge server and a second base device located 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 that measures a first resource status of the first worker node; a first resource status transmitting unit that transmits the measured first resource status to the first base device, and the first base unit includes a first receiving unit that receives the first resource status. a first transmitting unit that transmits the received first resource status to the server; and the second edge server is configured to transmit the received first resource status to the server, and the second edge server is configured to transmit the received first resource status to the second worker node, and a second resource status measuring unit that measures the second resource status; and a second resource status transmitting unit that transmits the measured second resource status to the second base device; comprises a second receiving unit that receives the second resource status, and a second transmitting unit that transmits the received second resource status to the server, and the server is configured to receive the first resource status. and a first server reception unit that receives the second resource status, and a server information storage unit that stores the received first resource status and second resource status.

In the container system according to aspect 11 of the present invention, in the above aspect 10, the first base device performs a first network status measurement that measures a first network status during communication from the first base to the second base. The first transmitting unit transmits the measured first network status and the received first resource status to the server, and the second base device transmits the measured first network status and the received first resource status to the server. further comprising a second network situation measuring unit that measures a second network situation during communication from the station to the first base, and the second transmitting unit measures the second network situation measured and the received second network situation. 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 transmits the server information. The storage unit stores the received first network status, first resource status, second network status, and second resource status, and the server stores the first network status, the first resource status, the second network status, and the second resource status, and the server stores the first network status, the first resource status, the second network status, and the second resource status, and the server stores the first network status, the first resource status, the second network status, and the second resource status. a second server receiving unit that receives network requirements requested by one pod and resource requests requested by the first pod; Based on the second network status, the second resource status, and the received requirements for the network and the received requirements for the resource, which worker node among the first worker node and the second worker node is assigned the first A configuration may also be adopted in which it is determined whether to place one pod.

A program according to an aspect 12 of the present invention is a program for causing a computer to function as the pod placement determining device according to the above aspect 1, and includes the measuring section, the storage section, the first receiving section, and the second receiving section. The computer is configured to function as the determining section and the determining section.

[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 in an integrated circuit (IC chip) or the like. , may be realized by software.

In the latter case, the first base device 4 is equipped with a computer that executes instructions of a program that is software that implements each function. This computer includes, for example, one or more processors and a computer-readable recording medium storing the program. Then, 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, in addition to "non-temporary tangible media" such as ROM (Read Only Memory), tapes, disks, cards, semiconductor memories, programmable logic circuits, etc. can be used.

Further, the computer may further include a RAM (Random Access Memory) for expanding the program. Further, the program may be supplied to the computer via any transmission medium (communication network, broadcast wave, etc.) that can transmit the program. Note that one aspect of the present invention can also be realized 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 can be made 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. New technical features can also 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 App
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 (4)

(1) Measure the network status during communication from the first base where the first edge server equipped with the first worker node is located to the second base where the second edge server equipped with the second worker node is located (2) a first receiving unit that receives the resource status of the first worker node measured by the first edge server; (3) a storage unit that stores the measured network status and the received resource status. , (4) a second receiving unit that receives network requirements requested by a first pod constituting an application as a container orchestration cluster and resource requirements requested by the first pod; ) determining whether to place the first pod on the first worker node based on the saved network status and resource status and the received network requirements and received resource requirements; a server that is communicably connected to a second pod placement determining device located at the second base;
the network status and the resource status transmitted from the pod placement determining device; the second network status at the time of communication from the second base to the first base and the second network status transmitted from the second pod placement determining device; a first server receiving unit that receives a second resource status of the second worker node;
a server information storage unit that stores the received network status, the resource status, the second network status, and the second resource status;
a second server receiving unit that receives a second request to the network requested by a second pod constituting the application and a second resource status of the resource requested by the second pod;
the second pod to the second worker node based on the stored second network status and second resource status and the received second requirements for the network and second requirements for the resources; A second determining unit that determines whether to deploy the server. A container system comprising at least a pod placement determining device and a server,
The pod placement determining device includes:
A measurement unit that measures the network status during communication from a first base where a first edge server equipped with a first worker node is located to a second base where a second edge server equipped with a second worker node is located. and,
a first receiving unit that receives the resource status of the first worker node measured by the first edge server;
a storage unit for storing the measured network status and the received resource status;
a second receiving unit that receives network requirements requested by a first pod constituting an application as a container orchestration cluster and resource requirements requested by the first pod;
determining whether to place the first pod on the first worker node based on the saved network status and resource status and the received network requirements and resource requirements; It is equipped with a decision section,
The server is a server that is communicably connected to the pod placement determining device and the second pod placement determining device located at the second base, and
the network status and the resource status transmitted from the pod placement determining device; the second network status at the time of communication from the second base to the first base and the second network status transmitted from the second pod placement determining device; a first server receiving unit that receives a second resource status of the second worker node;
a server information storage unit that stores the received network status, the resource status, the second network status, and the second resource status;
a second server receiving unit that receives a second request to the network requested by a second pod constituting the application and a second resource status of the resource requested by the second pod;
the second pod to the second worker node based on the stored second network status and second resource status and the received second requirements for the network and second requirements for the resources; A container system comprising: a second determining unit that determines whether or not to place the container. A container system comprising a first edge server and a first base device located at a first base, a second edge server and second base device located at a second base, and a server,
The first edge server includes:
a first worker node belonging to a plurality of different container orchestration clusters;
a first resource status measurement unit that measures a first resource status of the first worker node;
a first resource status transmitter that transmits the measured first resource status to the first base device;
The first base device is
a first receiving unit that receives the first resource status;
a first transmitter that transmits the received first resource status to the server;
The second edge server includes:
a second worker node belonging to a plurality of different container orchestration clusters;
a second resource status measurement unit that measures a second resource status of the second worker node;
a second resource status transmitter that transmits the measured second resource status to the second base device,
The second base device is
a second receiving unit that receives the second resource status;
a second transmitting unit that transmits the received second resource status to the server,
The server is
a first server reception unit that receives the first resource status and the second resource status;
A container system comprising: a server information storage unit that stores the received first resource status and second resource status. The first base device further includes a first network status measurement unit that measures a first network status during communication from the first base to the second base,
the first transmitting unit transmits the measured first network status and the received first resource status to the server;
The second base device further includes a second network status measurement unit that measures a second network status during communication from the second base to the first base,
the second transmitting 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 reception unit that receives network requirements requested by a first pod constituting an application as a container orchestration cluster and resource requirements requested by the first pod;
Based on the stored first network status, first resource status, second network status, and second resource status, and the received requirements for the network and the received requirements for the resource, The container system according to claim 3 , wherein the container system determines which worker node to place the first pod among the first worker node and the second worker node.

Images