Application arrangement system and application arrangement method
Patent Information
- Application Number
- PCT/JP2025/010030
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-03-14
- Publication Date
- 2026-09-17
Smart Images
Figure JP2025010030_17092026_PF_FP_ABST
Abstract
Description
Application placement system and application placement method
[0001] The present invention relates to an application placement system and an application placement method.
[0002] Against the backdrop of advances in virtualization technology based on NFV (Network Functions Virtualization), systems are being constructed and operated for individual services. Furthermore, in the form of constructing a system for each of the above services, service functions are divided into reusable module units and operated on independent virtual machine (VM: Virtual Machine, container, or the like) environments, thereby enabling use as components as needed to improve operability. Such a form called SFC (Service Function Chaining) is becoming mainstream.
[0003] In recent application systems, it is common to use container-based virtualization. Containers package only an application and the components necessary for its execution, thereby realizing a lightweight and portable execution environment that does not depend on an OS. Unlike virtual machines (VMs), containers virtualize the OS on a server, not at the hardware level. Since applications are managed for each container, there are advantages such as low resource consumption and fast startup. To allocate containers to appropriate servers, a container infrastructure orchestrator such as Kubernetes is used. In container infrastructure orchestrators, CPU / Memory (in the following description, " / " represents "or") information is generally used to select a server on which to run a container.
[0004] In order to ensure HA (High-availability) and support distributed data centers, containers belonging to the same application may be started across geographically separated bases. In such cases, network conditions such as communication delay between bases and bandwidth utilization greatly affect the performance of the application.
[0005] This document describes the operation of applications using Kubernetes. Kubernetes is designed for managing containers, and it runs in a cluster. A cluster consists of two components: the control plane (Master Node) and the nodes (Worker Nodes). The Master Node is responsible for monitoring the status of the entire cluster, checking whether there are any discrepancies between the manifest file declared by the developer and the current configuration, and if the configurations differ, it instructs each Worker Node to deploy the Pods according to the manifest file. On the other hand, the Worker Node is responsible for managing the Pods, deploying them according to the instructions of the Master Node.
[0006] Figure 17 is a diagram illustrating the operation of an application using Kubernetes. The network system 1 shown in Figure 17 includes Kubernetes 12, which manages containers 13 built on the container infrastructure 14 based on application information 11b from the application administrator 11, the container infrastructure 14, the OS 15, the hardware 16, and the server (Worker Node) 17 on which the containers 13 are deployed.
[0007] The application administrator's terminal 11 packages the application (application information 11b) as a container 13 and sends its deployment information to Kubernetes 12. Based on the deployment information, Kubernetes 12 automatically places the container on each server (Worker Node) 17, manages it continuously, and restarts or relocates the container 13 in the event of a container / node failure (in the following explanation, " / " represents "and").
[0008] Prior methods exist that utilize network information for server selection. Non-patent document 1 describes a Pod placement method that uses network information obtained by a Service Mesh.
[0009] L. Wojciechowski et al., “NetMARKS: Network Metrics-AwaRe Kubernetes Scheduler Powered by Service Mesh,” in IEEE INFOCOM 2021- IEEE Conference on Computer Communications, 2021, pp. 1-9.
[0010] The technology described in Non-Patent Document 1 cannot deploy containers while considering the overall state of the physical network / server infrastructure. As a result, from the perspective of the actual physical network / server infrastructure, Pods are unnecessarily placed in distant locations, leading to increased communication latency between application components and a resulting degradation of application performance.
[0011] Figure 18 illustrates an example of an optimal deployment from the perspective of the physical network / server infrastructure. The same reference numerals are used for components identical to those in Figure 17. As shown in Figure 18, multiple application administrators 11 (application administrator N, application administrator M) each utilize a container infrastructure orchestrator to allocate containers to appropriate servers. The container infrastructure orchestrator collects metric data on the container infrastructure 14 using its own metric collection mechanism 14a for its application and determines the container deployment destination (reference numeral 14b in Figure 18).
[0012] In the physical network / server infrastructure shown in the lower part of Figure 18, Worker Nodes place Pods 18 on Server 17 according to instructions from the Master Node. Server 17, where Pods 18 are placed, exchanges information with other Server 17 (Pods 18) on the network via Router 19 (arrows 21 and 22 in Figure 18). Application administrator N and application administrator M each use the container infrastructure orchestrator independently. The container infrastructure orchestrator collects metric information about application administrator N's containers and places Pods 18 optimally for application administrator N (bold arrow 21 in Figure 18). Similarly, the container infrastructure orchestrator collects metric information about application administrator M's containers and places Pods 18 optimally for application administrator M (arrow 22 in Figure 18). The technology in Non-Patent Literature 1 does not utilize information from the entire physical network / server infrastructure for placement.
[0013] (Problem 1) The technology described in Non-Patent Document 1 cannot place containers considering the overall situation of the physical network / server infrastructure. As a result, from the perspective of the actual physical network / server infrastructure, Pods are placed in unnecessarily distant locations, leading to increased communication latency between application components and a degradation of application performance.
[0014] (Problem 2) Figure 19 illustrates an example of an inoptimal placement from the perspective of the physical network / server infrastructure. Figure 19 is a diagram to explain (Problem 2), which is related to (Problem 1) described in Figure 18. The same reference numerals are used for the same components as in Figure 18. The information necessary for the optimal placement of Pods can only be obtained as information confined to a single container infrastructure. Therefore, even if an optimal placement is achieved for the container infrastructure as shown in Figure 18, there are patterns in which the placement is not optimal from the perspective of the actual physical network / server infrastructure. As shown by the numeral cc in Figure 19, because the placement is inoptimal from the perspective of the physical network / server infrastructure, traffic is actually concentrated on a part of the network (hereinafter abbreviated as NW as appropriate). The application administrator 11 also sees it in a similar way, and the application administrator 11 cannot grasp this traffic concentration (the numeral aa in Figure 19).
[0015] In light of this background, the present invention was made, and its objective is to optimize application placement by considering the overall real-time network status of the physical network / server infrastructure, thereby avoiding communication delays and performance degradation of applications.
[0016] To solve the aforementioned problems, an application deployment system was provided that determines the execution location of containers on a container cluster, comprising: a network information collection unit that aggregates information on the physical network or server infrastructure and passes it to each container infrastructure; and an application deployment determination unit that determines the deployment location of applications based on the information from the network information collection unit.
[0017] According to the present invention, application placement can be optimized by considering the overall real-time network status of the physical network / server infrastructure, thereby avoiding communication delays and performance degradation of applications.
[0018] This is a diagram illustrating the configuration of a network system according to an embodiment of the present invention. This is a detailed configuration diagram of an application deployment system according to an embodiment of the present invention. This is a diagram illustrating the periodic execution for network information collection by the network information collection unit of the network system according to an embodiment of the present invention. This is a diagram illustrating the application deployment process by the application deployment determination unit of the application deployment system according to an embodiment of the present invention. This is a diagram illustrating the application re-deployment by the application deployment determination unit of the application deployment system according to an embodiment of the present invention. This is a diagram illustrating examples of data stored in each functional unit of the network system according to an embodiment of the present invention. This is a diagram illustrating a method used for periodic execution for network information collection by the network system according to an embodiment of the present invention. This is a diagram showing the network status used for periodic execution by the network system according to an embodiment of the present invention. This is a diagram illustrating a method used for application re-deployment by the application deployment system according to an embodiment of the present invention. This is a diagram illustrating the network status used for application re-deployment by the application deployment system according to an embodiment of the present invention. This is a diagram illustrating a method for utilizing network information by the application deployment system according to an embodiment of the present invention. This is a diagram illustrating a specific algorithm for achieving initial Pod deployment based on acquired NW metrics by the application deployment system according to an embodiment of the present invention. This is a diagram illustrating a specific algorithm for achieving initial Pod deployment based on acquired NW metrics by the application deployment system according to an embodiment of the present invention. This is a diagram illustrating an example of a specific algorithm for achieving Pod re-deployment based on acquired NW metrics by the application deployment system according to an embodiment of the present invention. This figure shows an embodiment of the present invention in which the application deployment determination unit of the application deployment system uses Kubernetes standard functions. This is a modification 1 of the embodiment shown in Figure 14A.This figure shows an example of setting application information and network information for an application deployment system according to an embodiment of the present invention. This is a modification 2 of this embodiment shown in Figure 15A. This figure shows an example of topology information for an application deployment system according to an embodiment of the present invention. This is a modification 3 of this embodiment shown in Figure 16A. This figure illustrates the operation of an application using Kubernetes. This figure illustrates an optimal deployment example from the perspective of the physical network / server infrastructure. This figure illustrates a non-optimal deployment example from the perspective of the physical network / server infrastructure.
[0019] The following describes an application deployment system, etc., in an embodiment of the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. [Overview] Figure 1 is a configuration diagram of a network system according to an embodiment of the present invention. This embodiment is an example applied to a system that utilizes real-time metrics of a network device. The same reference numerals are used for the same components as in Figure 17.
[0020] <Prerequisites> The network system has the following prerequisites: (1) The network system operates on a container infrastructure (e.g., a Kubernetes cluster).
[0021] (2) The container infrastructure is built on top of the physical network / server infrastructure. The container infrastructure is built on multiple servers and network devices.
[0022] (3) Application requirements are defined by the application administrator. The application administrator is a user of the container infrastructure and manages and operates service applications individually. The application administrator deploys any application to the container infrastructure.
[0023] As shown in Figure 1, the network system 1000 includes multiple container infrastructures 14 used by each application administrator 11, Pods 30 built on the container infrastructures 14, a physical network / server infrastructure 50, and an application deployment system 100 that determines the execution location of containers on the container cluster. Pod 30 corresponds to Pod 18 in Figures 18 and 19.
[0024] The container infrastructure 14 is built on multiple servers and network devices. The application administrator 11 is a user of the container infrastructure 14 and manages and operates service applications individually. The application administrator 11 deploys any application to the container infrastructure 14.
[0025] [Application Deployment System 100] The application deployment system 100 includes a network information collection unit 110 located on the physical network / server infrastructure 50, and an application deployment determination unit 120 located on each container infrastructure 14, which determines the server on which to run containers in each container infrastructure 14.
[0026] <Network Information Collection Unit 110> The network information collection unit 110 aggregates information from the physical network / server infrastructure 50 and passes it on to each container infrastructure 14. The network information collection unit 110 periodically collects network information (such as latency and bandwidth information between network devices) from the physical network / server infrastructure 50. The network information collection unit 110 constantly collects and records information from the physical network / server infrastructure 50 in preparation for requests from the application placement determination unit 120.
[0027] The network information collection unit 110 collects and records the overall real-time network status of the physical network / server infrastructure 50, enabling the deployment of applications that take into account the overall real-time network status of the physical network / server infrastructure 50.
[0028] <Application Placement Determination Unit 120> The application placement determination unit 120 refers to or receives information from the network information collection unit 110 and determines the placement location of the application (the destination of the container). By utilizing information from the physical network / server infrastructure 50, the application placement determination unit 120 eliminates the need for the application administrator 11 to independently build a function for metric collection.
[0029] The application placement determination unit 120 matches the defined application information and network requirements information collected from the network information collection unit 110 with the topology information of the physical network / server infrastructure 50 and executes a placement algorithm to determine the destination server for the container. The placement algorithm is the "Algorithm for realizing the initial placement of Pods" described later in Figures 10 to 12, and specifically, in Figures 10 to 12<Podのキューイング> , <Filter out unsuitable Pods> and<Podのスコアリング> These are the respective algorithms.
[0030] The application placement determination unit 120 executes the placement algorithm to place containers, stops containers that do not meet the requirements, and relocates new containers to servers that do meet the requirements.
[0031] Figure 2 is a detailed configuration diagram of an application deployment system 100 according to an embodiment of the present invention. As shown in Figure 2, the application deployment system 100 comprises a network information collection unit 110 located on a physical network / server infrastructure 50 and an application deployment determination unit 120 located on each container infrastructure 14.
[0032] <Details of the Network Information Collection Unit 110> The network information collection unit 110 comprises a collection server 111 and a network information recording unit 112. The collection server 111 collects metrics from the physical network / server infrastructure 50 and records them in the network information recording unit 112. In the case of an implementation example using OSS (Open Source Software), the collection server 111 is, for example, an Exporter server. The Exporter server acquires network device information using Netflow / sFlow / snmp, etc.
[0033] The network information recording unit 112 records metrics of the physical network / server infrastructure 50. The network information recording unit 112 stores time-series data of the physical network / server infrastructure 50.
[0034] <Details of the Application Placement Determination Unit 120> The Application Placement Determination Unit 120 comprises a processing reception unit 121, an application information recording unit 122, a container scheduler 123, a topology information recording unit 124, and an NW requirements monitoring unit 125.
[0035] The processing reception unit 121 receives application information defined by the application administrator 11 and commands for determining the container's location.
[0036] The application information recording unit 122 records the application information and network requirements entered by the application administrator 11. The application information recording unit 122 detects and records the difference between the application information already recorded and the newly entered application information (hereinafter referred to as "difference from application information").
[0037] The container scheduler 123 receives a command from the processing reception unit 121 to determine the container's placement location. The container scheduler 123 utilizes the information recorded in the network information recording unit 112. The container scheduler 123 utilizes the information recorded in the topology information recording unit 124. The container scheduler 123 processes / collects metrics data, executes the placement algorithm, and determines the container's placement location.
[0038] The topology information recording unit 124 records topology information of the physical network / server infrastructure 50.
[0039] The NW requirements monitoring unit 125 periodically monitors the physical network / server infrastructure 50 and detects and stops containers that do not meet the requirements defined by the application administrator 11.
[0040] The operation of the application deployment system 100 will be described below. [Periodic execution for network information collection] The periodic execution for network information collection by the network information collection unit 110 will be described below. Figure 3 is a diagram illustrating the periodic execution for network information collection by the network information collection unit 110. The same reference numerals are used for the same components as in Figure 2.
[0041] The network information collection unit 110 can be equipped with additional functions to acquire desired information from the physical network / server infrastructure 50. For example, the network information collection unit 110 can record delay information in addition to the information obtained from protocols such as sFlow / SNMP. Specifically, the network information collection unit 110 acquires delay information by deploying a measurement container 51 on the server 17 and adding a collection server 111. In this case, the container scheduler 123 can acquire the newly added information in the same way as the existing information.
[0042] In Figure 3, the physical network / server infrastructure 50 includes a measurement container 51 for measuring the delay of the server 17 or the physical network / server infrastructure 50. The network information collection unit 110 also includes multiple collection servers 111 (collection server #1, collection server #2) for collecting multiple types of metrics of the physical network / server infrastructure 50.
[0043] The network information collection unit 110 constantly collects information from the physical network / server infrastructure 50 and records it in the network information recording unit 112 in preparation for requests from the application placement determination unit 120 (Figure 2). In Figure 3, the collection server 111 (collection server #1) of the network information collection unit 110 collects metrics from the physical network / server infrastructure 50 via the router 19 (arrow a in Figure 3), and the collection server 111 (collection server #2) collects delay information from the server 17 or the physical network / server infrastructure 50 measured by the measurement container 51 (arrow b in Figure 3). The measurement container 51 measures the delay information from the server 17 or the physical network / server infrastructure 50 (arrow c in Figure 3). The periodic execution for network information collection has been explained above.
[0044] [When application deployment is performed by the application placement determining unit 120] Description will be given of when application deployment is performed by the application placement determining unit 120. FIG. 4 is a diagram for explaining when application deployment is performed by the application placement determining unit 120. Constituent components that are the same as those in FIG. 2 and FIG. 3 are assigned the same reference numerals. The network information collecting unit 110 shown in FIG. 4 acquires metrics from the physical network / server infrastructure 50 via the collection server 111, and records the metrics in the network information recording unit 112. The information recorded in the network information recording unit 112 is referenced by the container scheduler 123.
[0045] The topology information recording unit 124 shown in FIG. 4 records topology information of the physical network / server infrastructure 50.
[0046] The application administrator 11 shown in FIG. 4 transmits a file 11a defining application information and NW requirement information to the process receiving unit 121.
[0047] The container scheduler 123 starts the following processes (1) to (3) triggered by a deployment instruction from the application administrator 11. (1) The container scheduler 123 acquires information from the network information collecting unit 110 (<Processing / Referencing of metrics data>). (2) The container scheduler 123 processes the information acquired from the network information collecting unit 110 (<Execution of placement algorithm>). (3) The container scheduler 123 executes an application placement algorithm based on the processed information, and determines a container placement destination for the container 52 on the server 17 (<Determination of container placement destination>) (arrow d in FIG. 4). The above is a description of when application deployment is performed by the application placement determining unit 120.
[0048] [Relocation of Applications by Application Placement Determination Unit 120] The relocation of applications by the application placement determination unit 120 will be described. FIG. 5 is a diagram illustrating the relocation of applications by the application placement determination unit 120. The same components as those in FIG. 4 are denoted by the same reference numerals. The network information collection unit 110 illustrated in FIG. 5 acquires metrics from the physical network / server infrastructure 50 via the collection server 111, and records the metrics in the network information recording unit 112. The information recorded in the network information recording unit 112 is referred to by the container scheduler 123.
[0049] The topology information recording unit 124 illustrated in FIG. 5 records topology information of the physical network / server infrastructure 50.
[0050] <Stopping Containers that Do Not Satisfy Requirements> The NW requirement monitoring unit 125 detects containers that do not satisfy requirements predefined by the application administrator 11. Specifically, the NW requirement monitoring unit 125 detects containers that do not satisfy requirements based on a "difference from application information" recorded by the application information recording unit 122 and information recorded in the network information recording unit 112.
[0051] The NW requirement monitoring unit 125 stops containers that do not satisfy requirements. In FIG. 5, the container 52 on server #1 that does not satisfy the delay requirement is killed (evicted) (arrow f in FIG. 5).
[0052] <Container Relocation> The process reception unit 121 illustrated in FIG. 5 receives, from the application administrator 11, a file 11a defining application information and NW requirement information, and requests the container scheduler 123 to perform container relocation. The process reception unit 121 recognizes the defined file 11a and changes to the actual environment, and requests the container scheduler 123 for placement.
[0053] The container scheduler 123 determines the placement location of the container again based on the placement request from the processing reception unit 121. The container scheduler 123 starts the following processes (1)-(3) upon receiving the placement request from the processing reception unit 121. (1) The container scheduler 123 acquires information from the network information collection unit 110 (<processing / referencing metrics data>). (2) The container scheduler 123 processes the information acquired from the network information collection unit 110 (<execution of placement algorithm>).
[0054] (3) The container scheduler 123 executes the application placement algorithm based on the processed information and determines the container placement destination for container 52 on server 17 (<determination of container relocation destination>) (arrow e in Figure 5). In Figure 5, the container scheduler 123 relocates the container from container 52 on server #1 (arrow d in Figure 4) to container 52 on server #2 (arrow e in Figure 5). The application relocation by the application placement determination unit 120 has been explained above.
[0055] [Examples of data stored in each functional unit] Examples of data stored in each functional unit are described below. Figure 6 is a diagram illustrating examples of data stored in each functional unit. The topology information recording unit 124 shown in Figure 6 records topology information of the physical network / server infrastructure 50. Example 201 of topology information in Figure 6 describes the links between NW devices / servers and the characteristics of NW devices / servers (bandwidth, etc.) (code g in Figure 6).
[0056] The application information recording unit 122 shown in Figure 6 records application information, network requirements, and the status of the container infrastructure 204 entered by the application administrator 11. In the network requirements setting example 202 in Figure 6, the containers that will communicate with a given container, the required bandwidth and maximum delay requirements, etc. are described (code h in Figure 6).
[0057] In the application information configuration example 203 in Figure 6, information about the application to be deployed is described, for example, in the Kubernetes specification format (symbol i in Figure 6). For details on the Kubernetes specification format, see, for example, (Kubernetes, [online], [searched February 5, 2025], Internet <URL: https: / / kubernetes.io / ja / docs / concepts / workloads / controllers / deployment / >).
[0058] The network information recording unit 112 in Figure 6 records time-series data (an example of metrics) of the physical network / server infrastructure 50. Example 205 of the returned network information in Figure 6 describes the returned network information using sFlow for network information collection and Prometheus for recording (code j in Figure 6). Example 205 of the returned network information also describes the ICMP request time [s] (code k in Figure 6).
[0059] [Method for periodic execution to collect network information] Next, a method for periodic execution to collect network information (Figure 3) will be explained. Figures 7A and 7B illustrate the method for periodic execution to collect network information (Figure 3). Figure 7A is a detailed configuration diagram of the application deployment system 100. Figure 7B is a diagram showing the network conditions used by the application deployment system 100 in Figure 7A for periodic execution. The same reference numerals are used for the same components as in Figure 6. The container scheduler 123 shown in Figure 7A selects information to query the network information recording unit 112 by referring to the topology information in the topology information recording unit 124. Then, the container scheduler 123 executes the deployment of containers based on the information returned from the network information recording unit 112.
[0060] Let's take the case shown in Figure 7B where Server #1 and Server #2 can communicate with each other as an example. The container scheduler 123 identifies the path between Server #1 and Server #2 from the topology information above. The container scheduler 123 queries the network information recording unit 112 for network information of the path from Server #1 to Server #2.
[0061] The network information recording unit 112 returns the latest time-series data regarding the route queried by the container scheduler 123 to the container scheduler 123. The container scheduler 123 then executes the placement of containers based on the returned data.
[0062] [Method for Application Relocation] Next, we will explain how to use this method for application relocation (Figure 5). Figures 8A and 8B illustrate the method for application relocation (Figure 5). Figure 8A is a detailed configuration diagram of the application deployment system 100. Figure 8B is a diagram showing the network conditions used by the application deployment system 100 in Figure 8A for application relocation. The same reference numerals are used for the same components as in Figure 6. The NW requirement monitoring unit 125 shown in Figure 8A selects information to query the network information recording unit 112 by referring to the topology information in the topology information recording unit 124. The NW requirement monitoring unit 125 then compares the information returned from the network information recording unit 112 with the NW requirements and detects containers that do not meet the NW requirements.
[0063] Let's take the case shown in Figure 8B where container #1 on server #1 and container #2 on server #2 can communicate with each other. The network requirements monitoring unit 125 shown in Figure 8A identifies from the status of the container infrastructure 14 and application information that containers #1 and #2 can communicate with each other and that containers #1 and #2 are located on server #1 and server #2, respectively.
[0064] The NW requirements monitoring unit 125 identifies the path between server #1 and server #2 from the topology information in the topology information recording unit 124 (indicated by symbol l in Figure 6). The NW requirements monitoring unit 125 queries the network information recording unit 112 for network information of the path from server #1 to server #2. The network information recording unit 112 returns the latest time-series data regarding the path queried from the container scheduler 123. The NW requirements monitoring unit 125 compares the returned data with the NW requirements and determines whether the communication between containers satisfies the NW requirements.
[0065] [Method for using network information] Next, we will explain how to use network information. Figure 9 is a diagram illustrating how to use network information. The same components as in Figure 6 are denoted by the same reference numerals.
[0066] The application information recording unit 122 shown in Figure 9 records network requirements. In the network requirement setting example 205 in Figure 9, the maximum delay requirement, etc., are described (enclosed in the box in the network requirement setting example 205 in Figure 9).
[0067] The network information recording unit 112 in Figure 9 records time-series data (an example of metrics) of the physical network / server infrastructure 50. The example of the returned NW information 206 in Figure 9 describes the actual delay based on the ICMP request time [s] (boxed n in the example of the returned NW information 206 in Figure 9).
[0068] The NW requirement monitoring unit 125 compares the delay defined for NW delay (the boxed area in the NW requirement setting example 205 in Figure 9) with the actual delay (the boxed area n in the example of NW information to be returned in Figure 9) (the bidirectional arrow m in Figure 9).
[0069] [Example 1] The following describes a specific algorithm for achieving initial Pod placement based on acquired network metrics. The algorithm shown utilizes a feature that is standard in Kubernetes, the de facto standard for container orchestrators.
[0070] In order to utilize network information, it is necessary to identify the server where the reference container is deployed as the communication destination. For this reason, the application deployment system 100 prioritizes determining the deployment location of Pods that need to be fixed to a specific server (such as those with specified Affinity attributes or belonging to a StatefulSet) based on the application information.
[0071] <Podのキューイング> Figure 10 is a diagram illustrating a specific algorithm (placement algorithm) for achieving initial Pod placement based on acquired NW metrics. The left diagram of Figure 10 illustrates the functional unit 301 that operates the Pod queuing algorithm (when the function of functional unit 301 is active, it is indicated with a thick border). Functional unit 301 is specifically the application placement determination unit 120. The application placement determination unit 120 executes the placement algorithm and determines the Pod placement destination. Specifically, in step S11, the application placement determination unit 120 queues the Pods (indicated with a thick border because it is a function added in this embodiment; the same notation applies hereafter). In step S12, unsuitable Pods are filtered out, and in step S13, the application placement determination unit 120 scores the Pods and terminates the processing of this flow.
[0072] The middle diagram in Figure 10 shows the detailed flow of "Pod queuing" in step S11 of the left diagram in Figure 10, and is repeated for each target Pod. In step S21, the application placement determination unit 120 refers to the application information. In step S22, the application placement determination unit 120 determines whether the Pod needs to be fixed to a specific server. If the Pod needs to be fixed to a specific server (S22: Yes), in step S23 it is placed at the beginning of the queue and the processing of this flow is terminated. If the Pod does not need to be fixed to a specific server (S22: No), in step S23 it is placed at the end of the queue and the processing of this flow is terminated.
[0073] The right diagram of Figure 10 shows the scheduling queue realized by the flow shown in the middle diagram of Figure 10. In the right diagram of Figure 10, in the [initial state], Pods that are Node-Affinity wait for placement to be determined. The scheduling queue shown in the right diagram of Figure 10 is realized by executing the flow shown in the middle diagram of Figure 10 (white arrow o in Figure 10). That is, as shown in the right diagram of Figure 10, in the case of a Pod that needs to be fixed to a specific server (S22: Yes in the middle diagram of Figure 10), the Pod that is Node-Affinity as shown in the right diagram of Figure 10 is placed and fixed first, and then the Pods are placed after the queue in the following order, thereby determining the scheduling queue in the scheduling order (white arrow p in Figure 10).
[0074] Thus, in order to utilize network information, it is necessary to identify the server where the reference container is deployed as the communication destination. For this reason, based on the application information, the location of Pods that need to be fixed to a specific server (such as those with specified Affinity attributes or belonging to a StatefulSet) is prioritized.
[0075] <Filtering out unsuitable Pods> Figure 11 is a diagram illustrating a specific algorithm (placement algorithm) for achieving initial Pod placement based on acquired NW metrics. The left diagram of Figure 11 illustrates the functional unit 301 that operates the algorithm for filtering out unsuitable Pods. Specifically, the functional unit 301 is the application placement determination unit 120. The application placement determination unit 120 executes the placement algorithm and determines the Pod placement destination. Specifically, in step S11, the application placement determination unit 120 queues the Pods. In step S12, it filters out unsuitable Pods, and in step S13, the application placement determination unit 120 scores the Pods and terminates the processing of this flow.
[0076] The right diagram in Figure 11 shows the detailed flow of "filtering out unsuitable Pods" in step S12 of the left diagram in Figure 11, and is repeated for each target server. In step S31, the application placement determination unit 120 determines whether the server meets the CPU / Memory criteria. If the server does not meet the CPU / Memory criteria (S31: No in the right diagram of Figure 11), the process proceeds to step S36. If the server meets the CPU / Memory criteria (S31: Yes in the right diagram of Figure 11), in step S32, the application placement determination unit 120 refers to information processed from the information obtained from the network information collection unit 110. In step S33, the application placement determination unit 120 determines whether the communication destination Pod has already been deployed. If the communication destination Pod has not already been deployed (S34: No in the right diagram of Figure 11), the process proceeds to step S35.
[0077] If the target Pod is already deployed (S33 in Figure 11, right diagram: Yes), in step S34 the application deployment determination unit 120 determines whether the communication path to the target Pod meets the delay requirements. If the communication path to the target Pod meets the delay requirements (S34 in Figure 11, right diagram: Yes), the process proceeds to step S35. If the communication path to the target Pod does not meet the delay requirements (S34 in Figure 11, right diagram: No), the process proceeds to step S36.
[0078] The processes described in steps S32 to S34 (outlined by the dashed line in Figure 11, right) are functions that are newly added in this embodiment to the functions that are standard in Kubernetes.
[0079] In step S35, the application deployment determination unit 120 records the Pod as a server that can be used and terminates the processing of this flow.
[0080] In step S36, the application placement determination unit 120 removes the Pod from the list of available servers and terminates the processing of this flow.
[0081] <Podのスコアリング>Figure 12 illustrates a specific algorithm (placement algorithm) for achieving initial Pod placement based on acquired network metrics. The left side of Figure 12 illustrates a functional unit 301 that operates the Pod scoring algorithm. Specifically, the functional unit 301 is the application placement determination unit 120. The application placement determination unit 120 executes the placement algorithm and determines the Pod placement destination. Specifically, in step S11, the application placement determination unit 120 queues the Pods. In step S12, it filters out unsuitable Pods, and in step S13, the application placement determination unit 120 scores the Pods and terminates the processing of this flow.
[0082] The right diagram in Figure 12 shows the detailed flow of "Pod scoring" in step S13 of the left diagram in Figure 12, and is repeated for each target server. In step S41, the application placement determination unit 120 performs scoring based on CPU / Memory. In step S42, the application placement determination unit 120 performs additional scoring. This additional scoring is for the use of power-saving servers. In step S43, the application placement determination unit 120 refers to information processed from the information acquired from the network information collection unit 110. In step S44, the application placement determination unit 120 determines whether the target Pod has already been deployed. If the target Pod has not already been deployed (S44: No in the right diagram of Figure 12), the processing of this flow is terminated.
[0083] If the destination Pod is already deployed (S44: Yes in Figure 12, right diagram), in step S45, the application deployment determination unit 120 scores the destination based on the communication requirements and terminates the processing of this flow. Examples of network information used for scoring are as follows: • Maximum bandwidth utilization rate on the path to the server where the destination Pod is located • Latency time to the server where the destination Pod is located
[0084] The processes described in steps S42 to S45 (outlined by the dashed line in Figure 12, right) are functions that have been added in this embodiment to the functions that are standard in Kubernetes.
[0085] An example of calculating the score for the Pod deployment server is described below. (Final score) = l × (Score based on CPU / Memory: Step S41) + m × (Additional score: Step S42) + n × (Score based on communication requirements to the communication destination: Step S45) where l, m, and n are weight coefficients.
[0086] The above explains specific algorithms for achieving the initial placement of Pods, as shown in Figures 10 to 12.
[0087] [Example 2] Next, we will describe an example of a specific algorithm for reallocating Pods based on acquired network metrics. The algorithm will be an example that utilizes a function that is standard in Kubernetes, the de facto standard for container orchestrators.
[0088] Figure 13 illustrates an example of a specific algorithm for reallocating Pods based on acquired network metrics. The left side of Figure 13 illustrates the functional unit that operates the Pod reallocation. It comprises the functional unit 302 shown in the left side of Figure 13 and the open-source Descheduler 303. The functional unit 302 periodically monitors the information recorded in the network information collection unit 110 for the Descheduler 303. The Descheduler 303 monitors for the presence of Pods that do not meet the requirements. If there are Pods that do not meet the requirements, the Descheduler 303 kills (evicts) those Pods. As a result, the Descheduler 303 reallocates the Pods.
[0089] The right diagram in Figure 13 shows the detailed flow of the Descheduler 303 in the left diagram in Figure 13, which is executed periodically. In step S51, the Descheduler 303 refers to information processed from the information acquired from the network information collection unit 110 (Figure 2). In step S52, the Descheduler 303 determines whether or not there are any Pods that do not meet the network requirements. If there are no Pods that do not meet the network requirements (S52 in the right diagram of Figure 13: No), the process returns to step S51. If there are Pods that do not meet the network requirements (S52 in the right diagram of Figure 13: Yes), in step S52, the Descheduler 303 kills (evicts) the Pods and terminates the processing of this flow. The processing in steps S51 to S53 above (enclosed by the dashed line in the right diagram of Figure 13) is a function newly added in this embodiment to the functions that are standard in Kubernetes.
[0090] [Modified Versions] Modified versions of this embodiment will now be described.
[0091] <Modification 1> Figures 14A and 14B illustrate Modification 1 of this embodiment. Figure 14A is a diagram of this embodiment in which the application placement determination unit 120 (Figure 2) uses Kubernetes standard functions. Figure 14B is Modification 1 of this embodiment of Figure 14A.
[0092] The standard Kubernetes features are listed below: • Store data in key-value format. This can be done via Kubernetes, [online], [searched February 5, 2025], or the internet (URL: https: / / kubernetes.io / ja / docs / concepts / configuration / configmap / ).
[0093] - This involves assigning Nodes (servers) to run Pods (containers). This can be done via Kubernetes, [online], [searched February 5, 2025], or the Internet (URL: https: / / kubernetes.io / ja / docs / concepts / scheduling-eviction / kube-scheduler / ).
[0094] The processing reception unit 401 in Figure 14A corresponds to the processing reception unit 121 of the application placement determination unit 120 shown in Figure 2, the application information recording unit 403 in Figure 14A corresponds to the application information recording unit 122 shown in Figure 2, and the scheduler 402 in Figure 14A corresponds to the container scheduler 123 shown in Figure 2. The Prometheus 405 in Figure 14A corresponds to the network information recording unit 112 of the network information collection unit 110 shown in Figure 2. The Prometheus 405 collects and stores metrics as time-series data.
[0095] As shown in Figure 14A, in this embodiment, the application deployment system has a processing reception unit 401 that receives application information and network requirements information and sends a "1. Deployment request" to the scheduler 402. Meanwhile, the application information recording unit 403 stores the topology information of the physical network / server infrastructure.
[0096] The scheduler 402 performs "2. Referencing topology information" of the application information recording unit 403. The Prometheus 405 requests the scheduler 402 to "3. Limit query information based on topology information". The scheduler 402 requests the Prometheus 405 to "4. Query network information". In response, the Prometheus 405 requests the scheduler 402 to "5. Return network information".
[0097] Scheduler 402 performs "6. Execution of the placement algorithm" and "7. Determination of Pod placement destinations".
[0098] Thus, in this embodiment, the scheduler 402 refers to topology information and collects only the relevant information from the network information collection unit 110 (Figure 2).
[0099] In contrast, in the modified example 1 shown in Figure 14B, the scheduler 402 performs "2. Inquiry about NW information" to the Prometheus 405. In response, the Prometheus 405 performs "3. Return of NW information" to the scheduler 402. The scheduler 402 performs "4. Matching with NW information" of the application information recording unit 403.
[0100] Scheduler 402 performs "5. Execution of the placement algorithm" and "6. Determination of the Pod placement destination".
[0101] Thus, in the modified example 1, the scheduler 402 refers to the result of matching the NW information and topology information collected from the network information collection unit 110.
[0102] <Modification 2> Figures 15A and 15B illustrate modification 2 of this embodiment. Figure 15A shows an example of setting application information 203 (Figure 6) and an example of setting network requirements 202 (Figure 6). Figure 15B is modification 2 of this embodiment shown in Figure 15A. In the application information setting example 203 shown in Figure 15A, the information of the application to be deployed is described in the format specified by Kubernetes. In the network requirements setting example 202 shown in Figure 15A, the container that will be the communication partner of a certain container, the required bandwidth and maximum latency requirements, etc. are described (code h in Figure 6). Thus, in this embodiment, the application administrator defines the user "application information" and "network requirements" in separate files.
[0103] In the example application information setting 203A of the modified example 2 shown in Figure 15B, "Application Information" and "Network Requirements Information" are defined in the same file. In other words, as in the example application information setting 203A of the modified example 2, "Application Information" and "Network Requirements Information" may be defined in the same file.
[0104] <Modification 3> Figures 16A and 16B illustrate modification 3 of this embodiment. Figure 16A shows example 201 of topology information (Figure 6). Figure 16B is modification 3 of this embodiment shown in Figure 16A. In example 201 of topology information shown in Figure 16A, the topology information recording unit 124 describes the links between NW devices / servers and the characteristics of NW devices / servers (bandwidth, etc.) together (code q in Figure 16A).
[0105] In the example topology information 201A of modified example 3 shown in Figure 16B, the link between the NW device / server and the characteristics of the NW device / server (bandwidth, etc.) are described separately (indicated as r in Figure 16A).
[0106] [Effects] As described above, the application deployment system 100 (Figure 1) determines the execution location of containers on a container cluster and comprises a network information collection unit 110 (Figure 2) that aggregates information of the physical network or server infrastructure (physical network / server infrastructure 50) (Figure 1) and passes it to each container infrastructure, and an application deployment determination unit 120 (Figure 2) that determines the deployment location of applications based on the information from the network information collection unit.
[0107] As described in the problem to be solved, in the conventional example shown in Figure 19, the information necessary for the optimal placement of Pods can only be obtained as information confined to a single container infrastructure. Therefore, even if the optimal placement is achieved from the container infrastructure's perspective, patterns occur where the optimal placement is not achieved from the perspective of the actual physical network / server infrastructure 50, resulting in increased communication latency between application components and a degradation of application performance.
[0108] In this embodiment, the network information collection unit 110 (Figure 2) collects and records the overall real-time network status of the physical network / server infrastructure 50, enabling application deployment that takes into account the overall real-time network status of the physical network / server infrastructure 50. As a result, the application deployment system 100 (Figure 1) can utilize the real-time network information collected from network devices in the physical network / server infrastructure 50 from applications on multiple container infrastructures. Consequently, it becomes possible to deploy applications that take into account the overall real-time network status of the physical network / server infrastructure 50.
[0109] Furthermore, the application placement determination unit 120 (Figure 2) utilizes information from the physical network / server infrastructure 50, eliminating the need for the application administrator 11 to independently build a function for metric collection. As a result, the application placement system 100 (Figure 1) can determine a Pod placement destination optimized for the network even if the application administrator does not deploy any special functions.
[0110] Therefore, the application deployment system 100 (Figure 1) can optimize application deployment by considering the overall real-time network status of the physical network / server infrastructure, thereby avoiding communication delays and performance degradation of applications.
[0111] The application deployment system 100 (Figure 1) includes an application deployment determination unit 120 that matches defined application information and network (NW) requirements information with the topology of the physical network or server infrastructure to execute a deployment algorithm that determines the destination server for the container.
[0112] By doing so, the application placement determination unit 120 (Figure 2) utilizes information from the physical network / server infrastructure 50, eliminating the need for the application administrator 11 to independently build a function for metric collection. As a result, the application placement system 100 (Figure 1) can determine a Pod placement destination optimized for the network even if the application administrator does not deploy any special functions.
[0113] In the application deployment system 100 (Figure 1), the application deployment determination unit 120 executes a deployment algorithm to deploy containers, stops containers that do not meet the requirements, and redeploys new containers to servers that do meet the requirements.
[0114] In this way, the application deployment system 100 can deploy containers based on a deployment algorithm that utilizes network metrics and requirements. For example, by adding functionality to the Descheduler 303 (Figure 13) of Kubernetes, which is the de facto standard for container orchestrators, the application deployment system 100 (Figure 1) can redeploy Pods.
[0115] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified. Moreover, each component of each illustrated device is a functional concept and does not necessarily have to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.
[0116] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software that allows the processor to interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, an SD (Secure Digital) card, or an optical disc.
[0117] 11 Application Administrator (Terminal) 13 Container 14 Container Infrastructure 50 Physical Network / Server Infrastructure 100 Application Deployment System 110 Network Information Collection Unit 111 Collection Server 112 Network Information Recording Unit 120 Application Deployment Decision Unit 121, 401 Processing Reception Unit 122, 403 Application Information Recording Unit 123 Container Scheduler 124 Topology Information Recording Unit 125 NW Requirements Monitoring Unit 402 Scheduler (Container Scheduler) 405 Prometheus (Network Information Recording Unit) 1000 Network System
Claims
1. An application deployment system for determining the execution location of containers on a container cluster, comprising: a network information collection unit that aggregates information on the physical network or server infrastructure and passes it to each container infrastructure; and an application deployment determination unit that determines the deployment location of applications based on the information from the network information collection unit.
2. The application placement system according to claim 1, characterized in that the application placement determination unit matches defined application information and network requirements information with the topology of the physical network or server infrastructure and executes a placement algorithm to determine the destination server for the container.
3. The application placement system according to claim 2, characterized in that the application placement determination unit executes the placement algorithm to place containers, stops containers that do not meet the requirements, and re-places new containers on servers that meet the requirements.
4. An application deployment method for determining the execution location of a container on a container cluster, characterized by performing the steps of: aggregating information on the physical network or server infrastructure and passing it to each container infrastructure; and determining the deployment location of the application based on the aggregated information on the physical network or server infrastructure.