WO2021234885A1 - コンテナリソース設計装置、コンテナリソース設計方法およびプログラム - Google Patents

コンテナリソース設計装置、コンテナリソース設計方法およびプログラム Download PDF

Info

Publication number
WO2021234885A1
WO2021234885A1 PCT/JP2020/020042 JP2020020042W WO2021234885A1 WO 2021234885 A1 WO2021234885 A1 WO 2021234885A1 JP 2020020042 W JP2020020042 W JP 2020020042W WO 2021234885 A1 WO2021234885 A1 WO 2021234885A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
resource
worker
worker nodes
node
Prior art date
Application number
PCT/JP2020/020042
Other languages
English (en)
French (fr)
Inventor
正純 太田
信 浜田
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US17/926,936 priority Critical patent/US20230195497A1/en
Priority to PCT/JP2020/020042 priority patent/WO2021234885A1/ja
Priority to JP2022524782A priority patent/JP7533576B2/ja
Publication of WO2021234885A1 publication Critical patent/WO2021234885A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • the present invention relates to a container resource design device, a container resource design method, and a program for designing resources of a container system in virtualization technology.
  • the container orchestration engine (container control mechanism) has a function to perform orchestration of a container across multiple hosts, and multiple worker nodes that provide execution hosts for the container and their respective. Configure a cluster with the master node that manages the worker nodes.
  • the number of replica sets can be specified in order to maintain a declarative state in which self-repair is possible.
  • the "replica set” is a function in which the container control mechanism creates replicas of a plurality of Pods. Pod is a set of one or more containers.
  • the container control mechanism automatically starts the pod by another node and maintains the number of replicas.
  • the condition of the worker node that can be arranged can be specified by the affinity rule as the arrangement condition required for the container (see, for example, Non-Patent Document 1).
  • a pod having a replica set number of “3” by a master node 10A (the master node is referred to as “Master” in each figure) (here, 1 pod is 1 container).
  • the master node is referred to as “Master” in each figure)
  • 1 pod is 1 container.
  • Is arranged in three worker nodes 20 (worker nodes are referred to as "Workers” in each figure), and a failure occurs in one of the three worker nodes (reference numeral in FIG. 6).
  • the number of replica sets is "3" and the affinity rule is set to "Do not place replicas of the same container (Pod) in the same worker node" (same Worker node placement: not possible) (Fig.).
  • the present invention has been made in view of such a point, and it is an object of the present invention to eliminate the need for manual resource design in a container system and to improve service continuity in the event of a failure.
  • the container resource design device is a container resource design device that designs resources of a virtualized container system, and the container system includes a plurality of worker nodes that provide services by arranging containers.
  • the container resource design device that creates and operates the worker node, and the container resource design device is the number of redundancy of the pod in a pod unit that is a set of one or more containers.
  • the number of replica sets indicating the number of replica sets, the affinity rule indicating the conditions for starting the container, and the allowable number of failures indicating the number of the worker nodes to which a failure can occur in order to maintain a self-repairable state.
  • the container setting reception unit that acquires the definition information including the above, the replica set number, the affinity rule, and the failure tolerance are extracted from the definition information, and even if a failure of the failure tolerance or less occurs in the worker node.
  • the required number of worker nodes indicating the minimum number of the required worker nodes is calculated after satisfying the number of replica sets and the conditions specified by the affinity rule, and the calculated required worker.
  • a resource calculation unit that causes the worker nodes of the required number of worker nodes to be paid out as resources by transmitting resource payout instruction information, which is instruction information of resource payout including the number of nodes, to the resource management mechanism, and payout.
  • the worker node is determined to arrange the pods in the number indicated by the number of replica sets, and the worker node that is determined to arrange the pods is instructed to set the container constituting the pod. It is characterized by including a container setting unit for transmission.
  • the present embodiment an embodiment for carrying out the present invention (hereinafter, referred to as "the present embodiment") will be described.
  • FIG. 1 is a diagram showing an overall configuration of a container resource design system 1000 including a container resource design device (master node 10) according to the present embodiment.
  • the container resource design system 1000 includes a master node 10 (Master) and a plurality of worker nodes 20 (Workers) set by a container orchestration engine (container control mechanism), and a virtualized network function VNF (Virtual Network). It is configured to include a VNFM (VNF Manager) 300 that manages a function) and a VIM (Virtualized Infrastructure Manager) 400 that manages a physical resource and a virtual resource set on the physical resource.
  • the container orchestration engine is, for example, "Kubernetes" (registered trademark) described in Non-Patent Document 1, but is not limited thereto.
  • the master node 10 corresponds to the container resource design device according to the claim.
  • the VNFM 300 and VIM 400 constitute the resource management mechanism according to claim.
  • the master node 10 manages each worker node 20 and Pod2 arranged in each worker node 20.
  • the master node 10 acquires definition information (manufacture file) related to container settings (deployment) from a container system management device or the like.
  • definition information manifest file
  • affinity rule indicating the number of replica sets and the conditions for starting the container
  • the master node 10 calculates the number of worker nodes 20 for arranging the pods that are the units for creating the container based on the acquired definition information based on a predetermined logic using the number of replica sets, the affinity rule, and the number of fault tolerances. do.
  • the master node 10 sets (distributes as a resource) the calculated number of worker nodes 20 via the VNFM300 and the VIM400 (resource management mechanism).
  • VNFM300 and the VIM400 resource management mechanism
  • VNFM300 is a standard regulation of ETSI (European Telecommunications Standards Institute) NFV (Network Functions Virtualization) (“ETSI GS NFV-SOL 002 V2.6.1,” ETSI, 2019-04, Internet ⁇ URL: https: // www. It has a function to manage the life cycle (generation, deletion, scaling) of VNF in .etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.06.01_60/gs_NFV-SOL002v020601p.pdf>).
  • ETSI European Telecommunications Standards Institute
  • NFV Network Functions Virtualization
  • the VIM 400 has a function of performing operation management of physical resources and virtual resources in the standard regulation of ETSI VNF, and pays out a worker node 20 composed of a VM (Virtual Machine).
  • the master node 10 (container resource management device) pays out the worker node 20 using virtual resources via the VNFM 300 and the VIM 400.
  • the master node 10 performs a process of managing each worker node 20 and Pod2 arranged in each worker node 20, which is a conventional function. Further, as a process peculiar to the present embodiment, the master node 10 uses Pod2, which is a unit for creating a container, by a predetermined logic based on the number of replica sets, the affinity rule indicating the conditions for starting the container, and the allowable number of failures. Calculate the number of worker nodes 20 to be arranged.
  • the master node 10 is characterized in that the worker node 20 is paid out and the container arrangement is controlled.
  • the master node 10 and the worker node 20 constituting the cluster set by the container orchestration engine may be a physical device or a VM, but will be described as being a VM unless otherwise specified below. ..
  • the node (physical device) is transmitted by transmitting the request information about the setting (payout) of the worker node 20 to the management device of the container system or the like. Pay out (set).
  • the master node 10 includes a control unit, an input / output unit, and a storage unit (all not shown).
  • the input / output unit inputs / outputs information to / from each worker node 20, VNFM300, other external devices, and the like.
  • This input / output unit includes a communication interface for transmitting / receiving information via a communication line.
  • the storage unit stores information about the cluster, such as worker nodes 20, pods, and configuration information between the nodes.
  • control unit includes a container setting reception unit 11, a resource calculation unit 12, and a container setting unit 13.
  • the container setting reception unit 11 acquires definition information (manifest file) related to the container from the management device of the container system or the like.
  • the definition information acquired by the container setting receiving unit 11 is characterized in that it includes a failure tolerance number in addition to the conventionally described affinity rule indicating the number of replica sets and the conditions for starting the container.
  • the container setting reception unit 11 may receive definition information regarding a plurality of replica sets set at the same time.
  • This fault tolerance sets the number of M (preliminary system) worker nodes 20 with respect to the number of N (active system) worker nodes 20 corresponding to the number of replica sets in the N + M redundant configuration.
  • the failure tolerance is the number of worker nodes 20 that are allowed to maintain a declarative state (self-healing state) after satisfying the replica set number and affinity rules, that is, the worker node 20 has failed.
  • the number of worker nodes 20 to be paid out in advance is shown in order to maintain the declarative state even if the above occurs.
  • the "failure" assumed by the allowable number of failures corresponds not only to the failure that occurs in the worker node 20, but also to the failure when the traffic amount of each worker node 20, the CPU usage rate, etc. exceeds a predetermined threshold value.
  • the master node 10 pays out the (preliminary system) worker node 20 in advance in consideration of the allowable number of failures. Then, the master node 10 arranges a pod on the (preliminary) worker node 20 that has been paid out in advance so that the traffic amount, CPU usage rate, etc. of the worker node 20 do not exceed a predetermined threshold value, thereby performing an affinity rule. To meet.
  • the resource calculation unit 12 extracts information on the number of replica sets, the affinity rule indicating the conditions for starting the container, and the allowable number of failures from the acquired definition information (manifest file). Then, the resource calculation unit 12 uses the number of replica sets, the affinity rule, and the fault tolerance to maintain the minimum number of worker nodes 20 (VM resources) required to maintain the declarative state (hereinafter, “necessary worker”). The required number of worker nodes is calculated based on the logic (predetermined logic) of calculating (referred to as "the number of nodes").
  • the resource calculation unit 12 when the resource calculation unit 12 receives the definition information (manufacture file) of a plurality of replica sets (each different node) requesting the start of the container at the same time, the resource calculation unit 12 satisfies all of the plurality of definition information. In addition, the minimum number of worker nodes 20 (required number of worker nodes) required as a whole to maintain the declarative state is calculated. By doing so, when the definition information of a plurality of replica sets requesting the start of the container is received, the master node 10 is the minimum necessary worker node as a whole to maintain the declarative state. The number can be calculated. Therefore, it is possible to eliminate the need for manual resource design. In addition, resources can be operated more efficiently.
  • the resource calculation unit 12 determines the label type and calculates the “required number of label nodes”. If the label type is, for example, "GPU (Graphics Processing Unit)", the resource calculation unit 12 calculates "the number of required GPU label nodes". As the label type, in addition to "GPU", for example, a storage or a network device may be specified as a label so that it can be identified. By doing so, the master node 10 can specify the resource type in consideration of the label type and calculate the resource of the required number of label nodes (for example, "the number of required GPU label nodes"). Therefore, even when the definition information in which the labeled affinity rule is described is acquired, it is possible to eliminate the need for manual resource design.
  • the label type is, for example, "GPU (Graphics Processing Unit)
  • the resource calculation unit 12 calculates "the number of required GPU label nodes”.
  • the resource calculation unit 12 dispenses the worker nodes 20 having the required number of label nodes as resources (hereinafter referred to as “resource payout instruction information”). As a), it is transmitted to the VNFM300. As a result, the VIM 400 acquires the instruction information from the VNFM 300, and the worker node 20 composed of the VM is paid out. The worker node 20 paid out by the VIM 400 is registered in the master node 10.
  • the container setting unit 13 determines the arrangement of the number of pods indicated by the number of replica sets on the paid out worker node 20, and instructs the worker node 20 which has determined the arrangement of the pod 2 to set the pod 2 (container setting). Information) is sent.
  • the worker node 20 receives this container setting information and creates a pod. Further, the container setting unit 13 monitors the worker node 20, and when a failure occurs in the worker node 20, the container setting unit 13 includes the worker node 20 which has been dispensed as a resource in advance so as to maintain the number of replica sets. Then, the placement destination of the new node 2 is determined. Then, the container setting unit 13 transmits the container setting information to the worker node 20 determined as the placement destination of the new pod 2. By doing so, the master node 10 can maintain a self-healing declarative state in the worker node 20.
  • FIG. 2 shows a container resource design process when the master node 10 acquires one definition information (manifest file) regarding the container settings.
  • FIG. 3 shows a container resource design process when the master node 10 acquires a plurality of (three) definition information (manifest files) related to the container settings.
  • FIG. 2 is a diagram showing a first embodiment of the container resource design process of the container resource design system 1000 including the container resource design device (master node 10) according to the present embodiment.
  • the master node 10 acquires definition information (manifest file) related to container settings (of one replica set) from the management device of the container system or the like.
  • definition information manifest file
  • the number of replica sets is "3"
  • affinity rule indicating the conditions for starting the container, "replicas of the same container (Pod) are not placed in the same worker node” (same Worker node placement: not possible). )
  • the allowable number of failures "1" is described (reference numeral ⁇ 1 in FIG. 2).
  • the resource calculation unit 12 of the master node 10 extracts information on the number of replica sets, affinity rules, and the number of fault tolerances from the acquired definition information (manifest file). Then, the resource calculation unit 12 calculates the minimum number of worker nodes 20 (VM resources) (number of required worker nodes) required to maintain the declarative state.
  • VM resources number of required worker nodes
  • the resource calculation unit 12 cannot arrange replicas of the same container (Pod) on the same worker node 20 due to the affinity rule, and since the failure tolerance is “1”, the number of replica sets is “3”.
  • the worker node 20 is added by "1", and "4" is calculated as the required number of worker nodes.
  • the resource calculation unit 12 of the master node 10 transmits the resource payout instruction information with the information of the required number of worker nodes “4” to the VNFM 300 (reference numeral ⁇ 2 in FIG. 2). Then, the VNFM 300 transmits the resource payout instruction information to the VIM400, so that the four worker nodes 20 (Worker “1", “2", “3”, "4") are paid out.
  • the container setting unit 13 of the master node 10 determines the arrangement of the pod 2 of the number "3" indicated by the number of replica sets from the paid out worker nodes 20 (here, the worker "1””” 2 ”“ 3 ”), the container setting information instructing the setting of Pod2 is transmitted to the worker node 20 that has determined the arrangement of Pod2.
  • the worker node 20 (Worker "1""2""3") that has received the container setting information sets Pod2.
  • the worker node "4" is paid out as a resource in advance, but Pod2 is not set.
  • the master node 10 (container setting unit 13) transmits the container setting information to the worker node "4" that has been paid out in advance.
  • the worker node "4" sets Pod2 (2n) (reference numeral e in FIG. 2).
  • the resources have been paid out in consideration of the affinity rule, it is possible to deal with the failure without interrupting the service. That is, service continuity can be improved.
  • FIG. 3 is a diagram showing a second embodiment of the container resource design process of the container resource design system 1000 including the container resource design device (master node 10) according to the present embodiment.
  • the master node 10 acquires definition information (manifest file) of a plurality of (three replica sets) related to the container setting from the management device of the container system or the like.
  • definition information manifest file
  • replica set In the definition information of A replica set, the number of replica sets is "4", and as an affinity rule indicating the conditions for starting the container, "Do not place replicas of the same container (Pod) on the same worker node” (same Worker node). Arrangement: Impossible), and it is assumed that the allowable number of failures "2" is described (reference numeral ⁇ 1-A in FIG. 2).
  • the number of replica sets is "3", and as an affinity rule indicating the conditions for starting the container, "Do not place replicas of the same container (Pod) on the same worker node” (same Worker node). Arrangement: Impossible), and it is assumed that the allowable number of failures "1" is described (reference numeral ⁇ 1-B in FIG. 2).
  • the definition information of the C replica set includes the number of replica sets "1", the label "GPU” as an affinity rule indicating the condition for starting the container, and the allowable number of failures "1" (FIG. 2).
  • Reference numeral ⁇ 1-C Reference numeral ⁇ 1-C).
  • the resource calculation unit 12 of the master node 10 extracts information on the number of replica sets, affinity rules, and the number of fault tolerances from the three acquired definition information (manifest file). Then, the resource calculation unit 12 calculates the minimum number of worker nodes 20 (VM resources) (number of required worker nodes) required to maintain the declarative state. Further, since the resource calculation unit 12 has "GPU" set as the label type in the C replica set, the minimum number of nodes required to set the worker node 20 in the GPU as a resource (the number of required GPU label nodes). ) Is calculated.
  • the resource calculation unit 12 first compares the definition information of the A replica set and the B replica set. Due to the affinity rule of the A replica set, replicas of the same container (Pod) cannot be placed on the same worker node 20, and since the number of failures is "2", the worker node 20 is set to "4" for the number of replica sets. 2 ”is added, and“ 6 ”is calculated as the required number of worker nodes in the A replica set. On the other hand, due to the affinity rule of the B replica set, replicas of the same container (Pod) cannot be placed on the same worker node 20, and since the failure tolerance is "1", the worker node 20 is set on the replica set number "3". Is added by "1", and "4" is calculated as the required number of worker nodes in the B replica set. Therefore, the minimum required number of nodes (required number of worker nodes) is "6" between the A replica set and the B replica set.
  • the number of worker nodes to be arranged on the GPU (the number of required GPU label nodes) is "2" because the allowable number of failures is "1" in the arrangement of the worker nodes on the GPU. Become.
  • the resource calculation unit 12 sets the required number of worker nodes "4" and the required GPU label as the minimum required number of nodes as a whole when three replica sets A, B, and C are set at the same time. Calculate the number of nodes "2".
  • the required number of worker nodes between the A replica set and the B replica set was "6", but among them, the worker node 20 using the GPU as a resource was assigned to the required number of GPU label nodes "2".
  • the setting is duplicated in the node 20. Therefore, the total number of worker nodes 20 to be paid out as resources remains "6".
  • the resource calculation unit 12 of the master node 10 transmits the resource payout instruction information with the information of the required number of worker nodes “4” and the required GPU label node “2” to the VNFM 300 (reference numeral ⁇ 2 in FIG. 3). Then, the VNFM 300 transmits the resource payout instruction information to the VIM 400, so that the four worker nodes 20 (Worker “1" “2” “3” "4") and the two worker nodes 20 that provide the GPU as resources are provided. (Worker "5" "6") is paid out.
  • the container setting unit 13 of the master node 10 determines the arrangement of Pod2 from the paid out worker nodes 20 according to the number indicated by the number of replica sets in the definition information of each replica set, and determines the arrangement of Pod2.
  • the container setting information instructing the setting of the Pod 2 is transmitted to the worker node 20 that has decided the arrangement. Then, each worker node 20 that has received the container setting information sets Pod2.
  • the four pods of the A replica set are set to the worker nodes "1", “2", “4", and "5".
  • the three pods of the B replica set are set to the worker nodes "1", “3”, and "4".
  • one Pod of the C replica set is set to the worker node "5" that provides the GPU as a resource.
  • the worker node "6" is paid out as a resource in advance, but the pod is not set.
  • the master node 10 (container setting unit 13) arranges the Pod of the A replica set on, for example, the worker nodes “3” and “6”, and transmits the container setting information.
  • the Pod of the B replica set is placed on the worker node "2", for example, and the container setting information is transmitted.
  • the Pod of the C replica set is arranged on the worker node "6", and the container setting information is transmitted.
  • the worker node "2" sets the Pod of the B replica set (reference numeral h in FIG. 3).
  • the worker node “3” sets the Pod of the A replica set (reference numeral i in FIG. 3).
  • the worker node “6” sets the Pod of the A replica set and the Pod of the C replica set (reference numerals j and k in FIG. 3).
  • the setting of the worker node 20 can be suppressed to the minimum required number of nodes, and resources can be operated efficiently.
  • FIG. 4 is a flowchart showing a flow of processing executed by the container resource design device (master node 10) according to the present embodiment.
  • the container setting reception unit 11 of the master node 10 acquires definition information (manifest file) related to the container from the management device of the container system or the like (step S1).
  • This definition information includes the number of replica sets, the affinity rule indicating the conditions for starting the container, and the number of fault tolerances. Further, the container setting receiving unit 11 may receive definition information about a plurality of replica sets.
  • the resource calculation unit 12 of the master node 10 extracts information on the number of replica sets, the affinity rule indicating the conditions for starting the container, and the number of fault tolerances from the acquired definition information (manifest file) (Ste S2).
  • the resource calculation unit 12 calculates the minimum number of worker nodes 20 (required number of worker nodes) required to maintain the declarative state based on the number of replica sets, the affinity rule, and the number of fault tolerances (the number of required worker nodes). Step S3). At this time, when the resource calculation unit 12 receives the definition information for a plurality of replica sets, the resource calculation unit 12 satisfies the conditions of the number of replica sets, the affinity rule, and the fault tolerance shown in each definition information, and is a worker node. Calculate the required number of worker nodes so that the number is the lowest overall.
  • the affinity rule includes information on a label that identifies the resource type, consider the label type and satisfy the number of resources of the type indicated by the label, and the required number of label nodes (for example). , If the label is "GPU", “the number of required GPU label nodes") is included in the calculation.
  • the resource calculation unit 12 provides resource payout instruction information including the required number of worker nodes and, if the required number of label nodes (required GPU label nodes) is calculated, the worker nodes 20 having the required number of label nodes. , VNFM 300 (step S4).
  • the VIM 400 acquires the instruction information from the VNFM 300, and the worker node 20 is paid out.
  • the worker node 20 paid out by the VIM 400 is registered in the master node 10.
  • the container setting unit 13 of the master node 10 determines the arrangement of the number of Pod2 indicated by the number of replica sets on the paid-out worker node 20, and sets the Pod2 on the worker node 20 that has determined the arrangement of the Pod2.
  • the container setting information to be instructed is transmitted (step S5).
  • the worker node 20 receives this container setting information and creates a pod.
  • the master node 10 (container resource design device) can maintain the declarative state after satisfying the conditions of the number of replica sets and the affinity rule. Therefore, it is possible to eliminate the need for manual resource design and improve service continuity in the event of a failure.
  • the container resource design device (master node 10) is realized by, for example, a computer 900 which is a physical device having a configuration as shown in FIG.
  • FIG. 5 is a hardware configuration diagram showing an example of a computer 900 that realizes the function of the container resource design device (master node 10) according to the present embodiment.
  • the computer 900 has a CPU 901, a ROM (Read Only Memory) 902, a RAM 903, an HDD (Hard Disk Drive) 904, an input / output I / F (Interface) 905, a communication I / F 906, and a media I / F 907.
  • the CPU 901 operates based on the program stored in the ROM 902 or the HDD 904, and is operated by the control unit (container setting reception unit 11, resource calculation unit 12, container setting unit 13) of the container resource design device (master node 10) shown in FIG. Take control.
  • the ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, a program related to the hardware of the computer 900, and the like.
  • the CPU 901 controls an input device 910 such as a mouse and a keyboard and an output device 911 such as a display via the input / output I / F 905.
  • the CPU 901 acquires data from the input device 910 and outputs the generated data to the output device 911 via the input / output I / F 905.
  • a GPU or the like may be used together with the CPU 901 as the processor.
  • the HDD 904 stores a program executed by the CPU 901, data used by the program, and the like.
  • the communication I / F906 receives data from another device via a communication network (for example, NW (Network) 920) and outputs the data to the CPU 901, and the communication I / F 906 transfers the data generated by the CPU 901 to another device via the communication network. Send to the device.
  • NW Network
  • the media I / F907 reads the program or data stored in the recording medium 912 and outputs the program or data to the CPU 901 via the RAM 903.
  • the CPU 901 loads the program related to the target processing from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program.
  • the recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase change rewritable Disk), a magneto-optical recording medium such as MO (Magneto Optical disk), a magnetic recording medium, a conductor memory tape medium, a semiconductor memory, or the like. Is.
  • the CPU 901 of the computer 900 executes the program loaded on the RAM 903 to execute the container resource design device (master node 10). ) Functions. Further, the data in the RAM 903 is stored in the HDD 904. The CPU 901 reads the program related to the target processing from the recording medium 912 and executes it. In addition, the CPU 901 may read a program related to the target processing from another device via the communication network (NW920).
  • NW920 communication network
  • the container resource design device is a container resource design device (master node 10) that designs resources of a virtualized container system, and the container system provides a plurality of services by arranging containers. Worker node 20 and a container resource design device (master node 10) that creates and operates the worker node 20.
  • the container resource design device (master node 10) is a set of one or more containers. The number of replica sets indicating the number of redundancy of the node 2 per node, the affinity rule indicating the conditions for starting the container, and the occurrence of a failure are allowed to maintain the self-repairable state.
  • the container setting reception unit 11 that acquires definition information including the failure tolerance indicating the number of worker nodes 20 and the number of replica sets, affinity rules, and failure tolerance are extracted from the definition information, and failures that are less than or equal to the failure tolerance are found. Even if it occurs in the worker node 20, the required number of worker nodes indicating the minimum required number of worker nodes is calculated and the required number of worker nodes is calculated after satisfying the number of replica sets and the conditions specified by the affinity rule.
  • Resource calculation unit that causes the worker node 20 of the required number of worker nodes to be paid out as a resource by transmitting the resource withdrawal instruction information, which is the instruction information of resource withdrawal including the calculated required number of worker nodes, to the resource management mechanism.
  • a container setting that determines the placement of the number of Pod2s indicated by the number of replica sets on the worker node 20 that has been paid out, and instructs the worker node 20 that has decided the placement of the Pod2 to set the containers that make up the Pod2. It is characterized by including a container setting unit 13 for transmitting information.
  • the container resource design device (master node 10) according to the present invention can maintain the declarative state after satisfying the conditions of the number of replica sets and the affinity rule.
  • a redundant design that takes into account the allowable number of failures can be automatically performed. Therefore, it is possible to eliminate the need for manual resource design and improve service continuity in the event of a failure.
  • the container setting receiving unit 11 acquires a plurality of definition information regarding different pods 2, and the resource calculation unit 12 indicates each pod 2 as a plurality of definition information.
  • the resource calculation unit 12 determines the type of the resource indicated by the label.
  • the required number of label nodes indicating the minimum number of required worker nodes 20 in the determined resource is calculated, included in the resource payout instruction information, and transmitted to the resource management mechanism.
  • the VNFM 300 is provided with all or a part of each function (container setting reception unit 11, resource calculation unit 12, container setting unit 13) which is a characteristic configuration of the container resource design device (master node 10) according to the present embodiment. You may let it. Even in this case, the master node 10 and the VNFM 300 can cooperate with each other to realize the processing of the present embodiment.
  • Container resource design system (master node) 11 Container setting reception unit 12 Resource calculation unit 13 Container setting unit 20 Worker node 300 VNFM (Resource management mechanism) 400 VIM (Resource Management Organization) 1000 Container resource design system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

コンテナリソース設計装置であるマスターノード（１０）は、Ｐｏｄ（２）の冗長化の数を示すレプリカセット数、コンテナを起動させるための条件を示すアフィニティルールおよび障害許容数を含む定義情報を取得するコンテナ設定受付部（１１）と、障害許容数以下の障害がワーカーノード（２０）に発生した場合でも、レプリカセット数を満たし、かつ、アフィニティルールで規定される条件を満たした上で、必要ワーカーノード数を算出し、リソース払出指示情報をリソース管理機構に送信するリソース算出部（１２）と、払い出されたワーカーノード（２０）にＰｏｄ（２）の配置を決定し、コンテナ設定情報を送信するコンテナ設定部（１３）と備える。

Description

コンテナリソース設計装置、コンテナリソース設計方法およびプログラム
　本発明は、仮想化技術におけるコンテナシステムのリソース設計を行う、コンテナリソース設計装置、コンテナリソース設計方法およびプログラムに関する。
　仮想化技術を適用したコンテナシステムにおいて、コンテナオーケストレーションエンジン（コンテナ制御機構）は、複数のホストにわたるコンテナのオーケストレーションを実行する機能を備え、コンテナの実行ホストを提供する複数のワーカーノードと、そのワーカーノードを管理するマスターノードとでクラスタを構成する。このコンテナ制御機構では、自己修復が可能となる宣言的な状態を維持するため、レプリカセット数を規定できる。ここで「レプリカセット」とは、コンテナ制御機構が複数のＰｏｄのレプリカを作成する機能である。Ｐｏｄは、１または複数のコンテナの集合である。例えば、ノード障害などでＰｏｄが減少した場合には、コンテナ制御機構が別のノードにより自動的にＰｏｄを起動し、レプリカ数を維持する。また、コンテナ制御機構では、コンテナに必要な配置条件としてアフィニティルールにより、配置できるワーカーノードの条件を指定できる（例えば、非特許文献１参照）。
西島 直、「KubernetesのマニュフェストをMagnumで実行する」、［online］、impress、2016年2月12日、［令和2年5月12日検索］，インターネット＜ＵＲＬ：https://thinkit.co.jp/article/9378＞
　しかしながら、レプリカセット数と配置するワーカーノードについてのアフィニティルールとの関連については、従来、リソース設計時に、システム管理者（設計者）が人手により考慮した上で、ワーカーノードとなるリソースを予め準備もしくは設定しておかなければならなかった。
　例えば、図６に示すように、マスターノード１０Ａ（各図においてマスターノードを「Master」と記載する。）により、レプリカセット数「３」としたＰｏｄ（ここでは、１Ｐｏｄが１コンテナとする。）がワーカーノード２０（各図においてワーカーノードを「Worker」と記載する。）３台に配置されているときにおいて、このワーカーノード３台のうちの１台に障害が発生した場合（図６の符号ａ）を想定する。このとき、レプリカセット数「３」とともに、アフィニティルールとして、「同一ワーカーノードには、同一コンテナ（Ｐｏｄ）のレプリカを配置しない」（同一Workerノード配置：不可）という設定がされているとき（図６の符号ｂ）には、障害が発生したワーカーノード「３」以外のワーカーノード「１」「２」には、アフィニティルールにより、同一コンテナ（Ｐｏｄ）を配置することができない（図６の符号ｃ）。よって、レプリカセット数「３」を保てないため、宣言的な状態を維持できないものとなる。
　このように、コンテナのレプリカセット数と、コンテナを起動させるための条件を示すアフィニティルールとが競合した場合に、コンテナを起動できずサービス停止に至るケースがある。
　このような点に鑑みて本発明がなされたのであり、本発明は、コンテナシステムにおいて、人手によるリソース設計を不要とし、障害発生時のサービス継続性を向上させることを課題とする。
　本発明に係るコンテナリソース設計装置は、仮想化されたコンテナシステムのリソース設計を行うコンテナリソース設計装置であって、前記コンテナシステムは、コンテナが配置されることによりサービスを提供する複数のワーカーノードと、当該ワーカーノードの生成および運用を行う前記コンテナリソース設計装置とにより構成されており、前記コンテナリソース設計装置が、１つ以上の前記コンテナの集合であるＰｏｄ単位での当該Ｐｏｄの冗長化の数を示すレプリカセット数、前記コンテナを起動させるための条件を示すアフィニティルール、および、自己修復が可能な状態を維持するために障害の発生が許容される前記ワーカーノードの数を示す障害許容数、を含む定義情報を取得するコンテナ設定受付部と、前記レプリカセット数、前記アフィニティルールおよび前記障害許容数を前記定義情報から抽出し、前記障害許容数以下の障害が前記ワーカーノードに発生した場合でも、前記レプリカセット数を満たし、かつ、前記アフィニティルールで規定される条件を満たした上で、最低限必要な前記ワーカーノードの数を示す必要ワーカーノード数を算出するとともに、算出された前記必要ワーカーノード数を含む、リソースの払い出しの指示情報であるリソース払出指示情報を、リソース管理機構に送信することにより、前記必要ワーカーノード数の前記ワーカーノードをリソースとして払い出させるリソース算出部と、払い出された前記ワーカーノードに、前記レプリカセット数で示される数の前記Ｐｏｄの配置を決定し、前記Ｐｏｄの配置を決定したワーカーノードに、前記Ｐｏｄを構成するコンテナの設定を指示するコンテナ設定情報を送信するコンテナ設定部と、を備えることを特徴とする。
　本発明によれば、コンテナシステムにおいて、人手によるリソース設計を不要とし、障害発生時のサービス継続性を向上させることができる。
本実施形態に係るコンテナリソース設計装置（マスターノード）を含むコンテナリソース設計システムの全体構成を示す図である。 本実施形態に係るコンテナリソース設計装置（マスターノード）を含むコンテナリソース設計システムのコンテナリソース設計処理の第１実施例を示す図である。 本実施形態に係るコンテナリソース設計装置（マスターノード）を含むコンテナリソース設計システムのコンテナリソース設計処理の第２実施例を示す図である。 本実施形態に係るコンテナリソース設計装置（マスターノード）が実行する処理の流れを示すフローチャートである。 本実施形態に係るコンテナリソース設計装置（マスターノード）の機能を実現するコンピュータの一例を示すハードウェア構成図である。 従来のコンテナ制御機構における課題を説明するための図である。
　次に、本発明を実施するための形態（以下、「本実施形態」と称する。）について説明する。
　図１は、本実施形態に係るコンテナリソース設計装置（マスターノード１０）を含むコンテナリソース設計システム１０００の全体構成を示す図である。
　コンテナリソース設計システム１０００は、コンテナオーケストレーションエンジン（コンテナ制御機構）により設定される、マスターノード１０（Master）および複数のワーカーノード２０（Worker）と、仮想化されたネットワーク機能であるＶＮＦ（Virtual Network Function）を管理するＶＮＦＭ（VNF Manager）３００と、物理リソースおよび物理リソース上に設定される仮想リソースを管理するＶＩＭ（Virtualized Infrastructure Manager）４００とを含んで構成される。
　なお、コンテナオーケストレーションエンジンは、例えば、非特許文献１に記載の「Kubernetes」（登録商標）であるが、これに限定されない。また、マスターノード１０は、請求項に記載のコンテナリソース設計装置に相当する。ＶＮＦＭ３００およびＶＩＭ４００とで、請求項に記載のリソース管理機構を構成する。
　ここで、マスターノード１０は、各ワーカーノード２０および各ワーカーノード２０に配置されるＰｏｄ２を管理する。
　本実施形態に係るマスターノード１０（コンテナリソース設計装置）は、コンテナシステムの管理装置等から、コンテナの設定（デプロイ）に関する定義情報（マニュフェストファイル）を取得する。この定義情報（マニュフェストファイル）には、レプリカセット数およびコンテナを起動させるための条件を示すアフィニティルールに加えて、本実施形態において特有な情報である「障害許容数」（詳細は後記）が記載される。そして、マスターノード１０は、取得した定義情報に基づき、コンテナ作成の単位となるＰｏｄを配置するワーカーノード２０の数を、レプリカセット数、アフィニティルールおよび障害許容数を用いた所定のロジックに基づき算出する。マスターノード１０は、算出した数のワーカーノード２０を、ＶＮＦＭ３００およびＶＩＭ４００（リソース管理機構）を介して設定する（リソースとして払い出す）。続いて、マスターノード１０により、Ｐｏｄがワーカーノード２０に割り当てられると、ワーカーノード２０においてコンテナが設定される。そして、コンテナにより実際にサービス提供のタスク処理がなされる。
　ここで、ＶＮＦＭ３００は、ＥＴＳＩ（European Telecommunications Standards Institute） ＮＦＶ（Network Functions Virtualization）の標準規定（“ETSI GS NFV-SOL 002 V2.6.1,”ＥＴＳＩ，2019-04，インターネット＜ＵＲＬ：https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.06.01_60/gs_NFV-SOL002v020601p.pdf＞）における、ＶＮＦのライフサイクル（生成、削除、スケーリング）管理を行う機能を備える。
　また、ＶＩＭ４００は、ＥＴＳＩ ＶＮＦの標準規定における、物理リソースおよび仮想リソースの運用管理を行う機能を備え、ＶＭ（Virtual Machine）で構成されるワーカーノード２０の払い出しを行う。
　マスターノード１０（コンテナリソース管理装置）は、ＶＮＦＭ３００およびＶＩＭ４００を介して、仮想リソースを用いたワーカーノード２０の払い出しを行う。
＜マスターノード（コンテナリソース管理装置）＞
　以下、本実施形態に係るマスターノード１０（コンテナリソース管理装置）について、図１を参照して詳細に説明する。
　マスターノード１０は、従来の機能である、各ワーカーノード２０および各ワーカーノード２０に配置されるＰｏｄ２を管理する処理を行う。さらに、マスターノード１０は、本実施形態における特有な処理として、レプリカセット数、コンテナを起動させるための条件を示すアフィニティルールおよび障害許容数に基づく所定のロジックにより、コンテナ作成の単位となるＰｏｄ２を配置するワーカーノード２０の数を算出する。そして、マスターノード１０は、ワーカーノード２０の払い出しおよびコンテナ配置の制御を行うことを特徴とする。
　なお、コンテナオーケストレーションエンジン（コンテナ制御機構）により設定されるクラスタを構成する、マスターノード１０およびワーカーノード２０は、物理装置でもＶＭでもよいが、以下特に記載しない限りにおいてＶＭであるものとして説明する。また、マスターノード１０およびワーカーノード２０が物理装置である場合には、そのワーカーノード２０の設定（払い出し）についての要求情報を、コンテナシステムの管理装置等に送信することにより、ノード（物理装置）の払い出し（設定）を行う。
　このマスターノード１０は、制御部、入出力部、記憶部（いずれも図示省略）を備える。
　入出力部は、各ワーカーノード２０や、ＶＮＦＭ３００、その他の外部装置等との間の情報について入出力を行う。この入出力部は、通信回線を介して情報の送受信を行う通信インタフェースを備える。
　記憶部は、クラスタに関する情報である、各ワーカーノード２０、Ｐｏｄ、ノード間の構成情報などを記憶する。
　制御部は、図１に示すように、コンテナ設定受付部１１と、リソース算出部１２と、コンテナ設定部１３とを含んで構成される。
　コンテナ設定受付部１１は、コンテナシステムの管理装置等から、コンテナに関する定義情報（マニュフェストファイル）を取得する。
　このコンテナ設定受付部１１が取得する定義情報には、従来より記載される、レプリカセット数およびコンテナを起動させるための条件を示すアフィニティルールに加えて、障害許容数を含むことを特徴とする。
　なお、後記するように、コンテナ設定受付部１１は、同時期に設定する複数のレプリカセットに関する定義情報を受信してもよい。
　この障害許容数は、Ｎ＋Ｍ冗長構成において、レプリカセット数に対応するＮ（現用系）のワーカーノード２０の数に対して、Ｍ（予備系）のワーカーノード２０の数を設定するものである。障害許容数は、レプリカセット数およびアフィニティルールを満たした上で、宣言的な状態（自己修復が可能な状態）を維持するのに許容されるワーカーノード２０の数、つまり、ワーカーノード２０に障害が発生しても宣言的な状態を維持するために、予め払い出しておくワーカーノード２０の数を示している。
　この障害許容数で想定される「障害」は、ワーカーノード２０において発生する故障だけでなく、各ワーカーノード２０のトラヒック量やＣＰＵ使用率等において、所定の閾値を超えた場合も障害に該当するものとする。マスターノード１０は、障害許容数を考慮して、予め（予備系の）ワーカーノード２０を払い出しておく。そしてマスターノード１０は、ワーカーノード２０のトラヒック量やＣＰＵ使用率等が所定の閾値を超えないように、予め払い出しておいた（予備系の）ワーカーノード２０にＰｏｄを配置することにより、アフィニティルールを満たすようにする。
　リソース算出部１２は、取得した定義情報（マニュフェストファイル）から、レプリカセット数、コンテナを起動するための条件を示すアフィニティルール、および、障害許容数の情報を抽出する。そして、リソース算出部１２は、レプリカセット数、アフィニティルールおよび障害許容数を用いて、宣言的な状態を維持するために最低限必要なワーカーノード２０（ＶＭリソース）の数（以下、「必要ワーカーノード数」と称する。）を算出するというロジック（所定のロジック）に基づき、必要ワーカーノード数を算出する。
　また、リソース算出部１２は、コンテナの起動を要求する複数のレプリカセット（各々異なる複数のＰｏｄ）の定義情報（マニュフェストファイル）を同時期に受け取った場合には、複数の定義情報のすべてを満たし、かつ、宣言的な状態を維持するのに、全体として最低限必要なワーカーノード２０の数（必要ワーカーノード数）を算出する。
　このようにすることで、コンテナの起動を要求する複数のレプリカセットの定義情報を受け付けた場合に、マスターノード１０が、宣言的な状態を維持するのに、全体として最低限必要な必要ワーカーノード数を算出することができる。よって、人手によるリソース設計を不要とすることができる。また、より効率的にリソースを運用することができる。
　さらに、リソース算出部１２は、リソースの種別を識別するラベルを付したアフィニティルールが記載された定義情報を取得した場合には、ラベル種別を判別し、「必要ラベルノード数」を算出する。リソース算出部１２は、ラベル種別が例えば「ＧＰＵ（Graphics Processing Unit）」であれば、「必要ＧＰＵラベルノード数」を算出する。ラベル種別は、「ＧＰＵ」の他、例えば、ストレージや、ネットワーク機器をラベルとして指定し、判別できるようにしてもよい。
　このようにすることで、マスターノード１０は、ラベル種別を考慮して、リソースの種別を指定し、必要ラベルノード数（例えば、「必要ＧＰＵラベルノード数」）のリソースを算出することができる。よって、ラベルを付したアフィニティルールが記載された定義情報を取得した場合においても、人手によるリソース設計を不要とすることができる。
　リソース算出部１２は、必要ワーカーノード数、また必要ラベルノード数が算出されていれば、その必要ラベルノード数のワーカーノード２０を、リソースとして払い出す指示情報（以下、「リソース払出指示情報」と称する。）として、ＶＮＦＭ３００に送信する。これにより、ＶＩＭ４００がその指示情報をＶＮＦＭ３００から取得し、ＶＭで構成されるワーカーノード２０の払い出しが行われる。なお、ＶＩＭ４００が払い出したワーカーノード２０は、マスターノード１０に登録される。
　コンテナ設定部１３は、払い出されたワーカーノード２０に、レプリカセット数で示される数のＰｏｄ２の配置を決定し、Ｐｏｄ２の配置を決定したワーカーノード２０にＰｏｄ２の設定を指示する情報（コンテナ設定情報）を送信する。ワーカーノード２０は、このコンテナ設定情報を受信して、Ｐｏｄを作成する。
　また、コンテナ設定部１３は、ワーカーノード２０を監視しており、ワーカーノード２０に障害が発生した場合には、レプリカセット数を維持するように、リソースとして予め払い出しておいたワーカーノード２０を含めて、新たなＰｏｄ２の配置先を決定する。そして、コンテナ設定部１３は、新たなＰｏｄ２の配置先として決定したワーカーノード２０に、コンテナ設定情報を送信する。このようにすることで、マスターノード１０は、自己修復が可能な宣言的な状態をワーカーノード２０において維持することができる。
　次に、マスターノード１０を含むコンテナリソース設計システム１０００によるコンテナリソース設計処理の実施例を説明する。図２は、コンテナの設定に関する１つの定義情報（マニュフェストファイル）を、マスターノード１０が取得した場合のコンテナリソース設計処理を示す。図３は、コンテナ設定に関する複数（３つ）の定義情報（マニュフェストファイル）を、マスターノード１０が取得した場合のコンテナリソース設計処理を示す。
＜第１実施例＞
　図２は、本実施形態に係るコンテナリソース設計装置（マスターノード１０）を含むコンテナリソース設計システム１０００のコンテナリソース設計処理の第１実施例を示す図である。
　マスターノード１０（コンテナ設定受付部１１）は、コンテナシステムの管理装置等から、コンテナの設定に関する（１つのレプリカセットの）定義情報（マニュフェストファイル）を取得する。
　この定義情報には、レプリカセット数「３」、コンテナを起動させるための条件を示すアフィニティルールとして「同一ワーカーノードには、同一コンテナ（Ｐｏｄ）のレプリカを配置しない」（同一Workerノード配置：不可）、障害許容数「１」が記載されているものとする（図２の符号α１）。
　マスターノード１０のリソース算出部１２は、取得した定義情報（マニュフェストファイル）から、レプリカセット数、アフィニティルール、および、障害許容数の情報を抽出する。そして、リソース算出部１２は、宣言的な状態を維持するために最低限必要なワーカーノード２０（ＶＭリソース）の数（必要ワーカーノード数）を算出する。
　ここで、リソース算出部１２は、アフィニティルールにより、同一ワーカーノード２０に同一コンテナ（Ｐｏｄ）のレプリカを配置できないこと、および、障害許容数「１」であることから、レプリカセット数「３」にワーカーノード２０を「１」加えた、「４」を必要ワーカーノード数として算出する。
　マスターノード１０のリソース算出部１２は、必要ワーカーノード数「４」の情報を付したリソース払出指示情報を、ＶＮＦＭ３００に送信する（図２に符号α２）。そして、ＶＮＦＭ３００がそのリソース払出指示情報をＶＩＭ４００に送信することにより、４つのワーカーノード２０（Worker「１」「２」「３」「４」）の払い出しが行われる。
　続いて、マスターノード１０のコンテナ設定部１３は、払い出されたワーカーノード２０の中から、レプリカセット数で示される数「３」のＰｏｄ２の配置を決定し（ここでは、Worker「１」「２」「３」）、Ｐｏｄ２の配置を決定したワーカーノード２０にＰｏｄ２の設定を指示するコンテナ設定情報を送信する。コンテナ設定情報を受信したワーカーノード２０（Worker「１」「２」「３」）は、Ｐｏｄ２を設定する。
　なお、ワーカーノード「４」は、予めリソースとして払い出されているが、Ｐｏｄ２が設定されていない状態となる。
　ここで、例えば、ワーカーノード「３」に障害が発生したとする（図２の符号ｄ）。この場合、このままでは、レプリカセット数「３」を維持できないため、マスターノード１０（コンテナ設定部１３）は、予め払い出されているワーカーノード「４」に対し、コンテナ設定情報を送信する。これにより、ワーカーノード「４」は、Ｐｏｄ２（２ｎ）を設定する（図２の符号ｅ）。この際、アフィニティルールを考慮したうえで、リソースの払い出しが済んでいるため、サービスを中断することなく障害対応を行うことができる。つまり、サービス継続性を向上させることができる。
＜第２実施例＞
　図３は、本実施形態に係るコンテナリソース設計装置（マスターノード１０）を含むコンテナリソース設計システム１０００のコンテナリソース設計処理の第２実施例を示す図である。
　マスターノード１０（コンテナ設定受付部１１）は、コンテナシステムの管理装置等から、コンテナの設定に関する複数（３つのレプリカセット）の定義情報（マニュフェストファイル）を取得する。
　ここでは、Ａレプリカセット、Ｂレプリカセット、Ｃレプリカセットにおけるコンテナ（Ｐｏｄ）の設定を要求する３つの定義情報を取得したものとする。
　Ａレプリカセットの定義情報には、レプリカセット数「４」、コンテナを起動させるための条件を示すアフィニティルールとして「同一ワーカーノードには、同一コンテナ（Ｐｏｄ）のレプリカを配置しない」（同一Workerノード配置：不可）、障害許容数「２」が記載されているものとする（図２の符号β１－Ａ）。
　Ｂレプリカセットの定義情報には、レプリカセット数「３」、コンテナを起動させるための条件を示すアフィニティルールとして「同一ワーカーノードには、同一コンテナ（Ｐｏｄ）のレプリカを配置しない」（同一Workerノード配置：不可）、障害許容数「１」が記載されているものとする（図２の符号β１－Ｂ）。
　Ｃレプリカセットの定義情報には、レプリカセット数「１」、コンテナを起動させるための条件を示すアフィニティルールとしてラベル「ＧＰＵ」、障害許容数「１」が記載されているものとする（図２の符号β１－Ｃ）。
　マスターノード１０のリソース算出部１２は、取得した３つの定義情報（マニュフェストファイル）から、レプリカセット数、アフィニティルール、および、障害許容数の情報を抽出する。そして、リソース算出部１２は、宣言的な状態を維持するために最低限必要なワーカーノード２０（ＶＭリソース）の数（必要ワーカーノード数）を算出する。また、リソース算出部１２は、Ｃレプリカセットにおいて、ラベル種別に「ＧＰＵ」が設定されていることから、リソースとしてのＧＰＵにワーカーノード２０を設定する最低限必要なノード数（必要ＧＰＵラベルノード数）を算出する。
　リソース算出部１２は、まず、ＡレプリカセットとＢレプリカセットの定義情報を比較する。Ａレプリカセットのアフィニティルールにより、同一ワーカーノード２０に同一コンテナ（Ｐｏｄ）のレプリカを配置できないこと、および、障害許容数「２」であることから、レプリカセット数「４」にワーカーノード２０を「２」加えた、「６」をＡレプリカセットの必要ワーカーノード数として算出する。一方、Ｂレプリカセットのアフィニティルールにより、同一ワーカーノード２０に同一コンテナ（Ｐｏｄ）のレプリカを配置できないこと、および、障害許容数「１」であることから、レプリカセット数「３」にワーカーノード２０を「１」加えた、「４」をＢレプリカセットの必要ワーカーノード数として算出する。よって、ＡレプリカセットとＢレプリカセットとの間では、最低限必要なノード数（必要ワーカーノード数）は「６」となる。
　一方、Ｃレプリカセットの定義情報により、ＧＰＵへのワーカーノードの配置において、障害許容数「１」であることから、ＧＰＵに配置するワーカーノード数（必要ＧＰＵラベルノード数）は、「２」となる。
　リソース算出部１２は、以上に基づき、Ａ，Ｂ，Ｃの３つのレプリカセットを同時期に設定する場合において、全体として最低限必要なノード数として、必要ワーカーノード数「４」、必要ＧＰＵラベルノード数「２」を算出する。なお、ＡレプリカセットとＢレプリカセットとの間で必要ワーカーノード数は「６」であったが、そのうち、ＧＰＵをリソースとして用いるワーカーノード２０を、必要ＧＰＵラベルノード数「２」に振り分けたワーカーノード２０に重複させて設定を行う。よって、リソースとしてワーカーノード２０を払い出す総数は「６」のままとなる。
　マスターノード１０のリソース算出部１２は、必要ワーカーノード数「４」および必要ＧＰＵラベルノード数「２」の情報を付したリソース払出指示情報を、ＶＮＦＭ３００に送信する（図３に符号β２）。そして、ＶＮＦＭ３００がそのリソース払出指示情報をＶＩＭ４００に送信することにより、４つのワーカーノード２０（Worker「１」「２」「３」「４」）と、リソースとしてＧＰＵを提供する２つのワーカーノード２０（Worker「５」「６」）との払い出しが行われる。
　続いて、マスターノード１０のコンテナ設定部１３は、払い出されたワーカーノード２０の中から、各レプリカセットの定義情報のレプリカセット数で示される数に応じてＰｏｄ２の配置を決定し、Ｐｏｄ２の配置を決定したワーカーノード２０にそのＰｏｄ２の設定を指示するコンテナ設定情報を送信する。そして、コンテナ設定情報を受信した各ワーカーノード２０は、Ｐｏｄ２を設定する。
　ここでは、Ａレプリカセットの４つのＰｏｄが、ワーカーノード「１」「２」「４」「５」に設定される。Ｂレプリカセットの３つのＰｏｄが、ワーカーノード「１」「３」「４」に設定される。また、Ｃレプリカセットの１つのＰｏｄが、ＧＰＵをリソースとして提供するワーカーノード「５」に設定される。
　なお、ワーカーノード「６」は、予めリソースとして払い出されているが、Ｐｏｄが設定されていない状態となる。
　ここで、例えば、ワーカーノード「４」「５」に障害が発生したとする（図３の符号ｆ，ｇ）。この場合、このままでは、Ａ，Ｂ，Ｃの３つのレプリカセットにおいて各レプリカセット数を維持できない。そのため、マスターノード１０（コンテナ設定部１３）は、ＡレプリカセットのＰｏｄを、例えばワーカーノード「３」「６」に配置するようにし、コンテナ設定情報を送信する。ＢレプリカセットのＰｏｄを、例えばワーカーノード「２」に配置するようにし、コンテナ設定情報を送信する。また、ＣレプリカセットのＰｏｄを、ワーカーノード「６」に配置するようにし、コンテナ設定情報を送信する。
　これにより、ワーカーノード「２」は、ＢレプリカセットのＰｏｄを設定する（図３の符号ｈ）。ワーカーノード「３」は、ＡレプリカセットのＰｏｄを設定する（図３の符号ｉ）。また、ワーカーノード「６」は、ＡレプリカセットのＰｏｄとＣレプリカセットのＰｏｄとを設定する（図３の符号ｊ，ｋ）。
　このようにすることで、人手によるリソース設計を不要とし、障害発生時のサービス継続性を向上させることができる。また、最低限必要なノード数にワーカーノード２０の設定を抑えることが可能となり、効率的にリソースを運用することができる。
≪処理の流れ≫
　次に、マスターノード１０が実行する処理の流れについて説明する。
　図４は、本実施形態に係るコンテナリソース設計装置（マスターノード１０）が実行する処理の流れを示すフローチャートである。
　まず、マスターノード１０のコンテナ設定受付部１１は、コンテナシステムの管理装置等から、コンテナに関する定義情報（マニュフェストファイル）を取得する（ステップＳ１）。
　この定義情報には、レプリカセット数、コンテナを起動させるための条件を示すアフィニティルールおよび障害許容数が記載されている。
　また、コンテナ設定受付部１１は、複数のレプリカセットについての定義情報を受信してもよい。
　次に、マスターノード１０のリソース算出部１２は、取得した定義情報（マニュフェストファイル）から、レプリカセット数、コンテナを起動するための条件を示すアフィニティルール、および、障害許容数の情報を抽出する（ステップＳ２）。
　続いて、リソース算出部１２は、レプリカセット数、アフィニティルールおよび障害許容数に基づき、宣言的な状態を維持するために最低限必要なワーカーノード２０の数（必要ワーカーノード数）を算出する（ステップＳ３）。
　この際、リソース算出部１２は、複数のレプリカセットについての定義情報を受け取った場合には、各定義情報で示される、レプリカセット数、アフィニティルールおよび障害許容数の条件を満たし、かつ、ワーカーノード数が全体として最低となるように、必要ワーカーノード数を算出する。また、アフィニティルールにおいてリソースの種別を識別するラベルの情報が付されていた場合には、ラベル種別を考慮し、ラベルで示される種類のリソースの数を満たすようにして、必要ラベルノード数（例えば、ラベルが「ＧＰＵ」であれば「必要ＧＰＵラベルノード数」）を含めて算出する。
　次に、リソース算出部１２は、必要ワーカーノード数、また必要ラベルノード数（必要ＧＰＵラベルノード数）が算出されていれば、その必要ラベルノード数のワーカーノード２０を含む、リソース払出指示情報を、ＶＮＦＭ３００に送信する（ステップＳ４）。これにより、ＶＩＭ４００がその指示情報をＶＮＦＭ３００から取得し、ワーカーノード２０の払い出しが行われる。これにより、ＶＩＭ４００が払い出したワーカーノード２０が、マスターノード１０に登録される。
　そして、マスターノード１０のコンテナ設定部１３は、払い出されたワーカーノード２０に、レプリカセット数で示される数のＰｏｄ２の配置を決定し、Ｐｏｄ２の配置を決定したワーカーノード２０にＰｏｄ２の設定を指示するコンテナ設定情報を送信する（ステップＳ５）。ワーカーノード２０は、このコンテナ設定情報を受信して、Ｐｏｄを作成する。
　これにより、マスターノード１０（コンテナリソース設計装置）は、レプリカセット数およびアフィニティルールの条件を満たした上で、宣言的な状態を維持することができる。よって、人手によるリソース設計を不要とし、障害発生時のサービス継続性を向上させることができる。
＜ハードウェア構成＞
　本実施形態に係るコンテナリソース設計装置（マスターノード１０）は、例えば図５に示すような構成の物理装置であるコンピュータ９００によって実現される。
　図５は、本実施形態に係るコンテナリソース設計装置（マスターノード１０）の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ（Read Only Memory）９０２、ＲＡＭ９０３、ＨＤＤ（Hard Disk Drive）９０４、入出力Ｉ／Ｆ（Interface）９０５、通信Ｉ／Ｆ９０６およびメディアＩ／Ｆ９０７を有する。
　ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に記憶されたプログラムに基づき作動し、図１に示すコンテナリソース設計装置（マスターノード１０）の制御部（コンテナ設定受付部１１、リソース算出部１２、コンテナ設定部１３）による制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１により実行されるブートプログラムや、コンピュータ９００のハードウェアに係るプログラム等を記憶する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ等を用いても良い。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
　例えば、コンピュータ９００が本実施形態に係るコンテナリソース設計装置（マスターノード１０）として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりコンテナリソース設計装置（マスターノード１０）の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
＜効果＞
　以下、本発明に係るコンテナリソース設計装置（マスターノード１０）等の効果について説明する。
　本発明に係るコンテナリソース設計装置は、仮想化されたコンテナシステムのリソース設計を行うコンテナリソース設計装置（マスターノード１０）であって、コンテナシステムは、コンテナが配置されることによりサービスを提供する複数のワーカーノード２０と、当該ワーカーノード２０の生成および運用を行うコンテナリソース設計装置（マスターノード１０）とにより構成されており、コンテナリソース設計装置（マスターノード１０）が、１つ以上のコンテナの集合であるＰｏｄ２単位での当該Ｐｏｄ２の冗長化の数を示すレプリカセット数、コンテナを起動させるための条件を示すアフィニティルール、および、自己修復が可能な状態を維持するために障害の発生が許容されるワーカーノード２０の数を示す障害許容数、を含む定義情報を取得するコンテナ設定受付部１１と、レプリカセット数、アフィニティルールおよび障害許容数を定義情報から抽出し、障害許容数以下の障害がワーカーノード２０に発生した場合でも、レプリカセット数を満たし、かつ、アフィニティルールで規定される条件を満たした上で、最低限必要なワーカーノード２０の数を示す必要ワーカーノード数を算出するとともに、算出された必要ワーカーノード数を含む、リソースの払い出しの指示情報であるリソース払出指示情報を、リソース管理機構に送信することにより、必要ワーカーノード数のワーカーノード２０をリソースとして払い出させるリソース算出部１２と、払い出されたワーカーノード２０に、レプリカセット数で示される数のＰｏｄ２の配置を決定し、Ｐｏｄ２の配置を決定したワーカーノード２０に、Ｐｏｄ２を構成するコンテナの設定を指示するコンテナ設定情報を送信するコンテナ設定部１３と、を備えることを特徴とする。
　このようにすることで、本発明に係るコンテナリソース設計装置（マスターノード１０）は、レプリカセット数およびアフィニティルールの条件を満たした上で、宣言的な状態を維持することができる。また、障害許容数を加味した冗長設計を自動で行うことができる。よって、人手によるリソース設計を不要とし、障害発生時のサービス継続性を向上させることができる。
　また、コンテナリソース設計装置（マスターノード１０）において、コンテナ設定受付部１１は、各々異なるＰｏｄ２に関する複数の定義情報を取得し、リソース算出部１２は、各々のＰｏｄ２が複数の定義情報それぞれで示される、障害許容数以下の障害がワーカーノード２０に発生した場合でも、レプリカセット数を満たし、かつ、アフィニティルールで規定される条件を満たした上で、全体として最低限必要な必要ワーカーノード数を算出することを特徴とする。
　このようにすることで、同時期に異なるＰｏｄの定義情報に基づき、複数のコンテナを設定（デプロイ）する場合でも、全体として最低限必要なワーカーノード数を算出することができる。よって、より効率的にリソースを運用することができる。
　また、コンテナリソース設計装置（マスターノード１０）において、アフィニティルールに、コンテナを起動させるリソースの種別を示すラベルが付されている場合に、リソース算出部１２は、ラベルで示されるリソースの種別を判別し、判別した種別のリソースにおいて、最低限必要なワーカーノード２０の数を示す必要ラベルノード数を算出し、リソース払出指示情報に含めてリソース管理機構に送信することを特徴とする。
　このようにすることで、リソースの種別を考慮して最低限必要なワーカーノード数を算出することができる。よって、より効率的にリソースを運用することができる。
　なお、本発明は、以上説明した実施形態に限定されるものではなく、多くの変形が本発明の技術的思想内で当分野において通常の知識を有する者により可能である。
　例えば、本実施形態に係るコンテナリソース設計装置（マスターノード１０）の特徴構成となる各機能（コンテナ設定受付部１１、リソース算出部１２、コンテナ設定部１３）の全部または一部を、ＶＮＦＭ３００に備えさせるようにしてもよい。この場合であっても、マスターノード１０とＶＮＦＭ３００が連携して本実施形態の処理を実現することができる。
　２　　　Ｐｏｄ
　１０　　コンテナリソース設計装置（マスターノード）
　１１　　コンテナ設定受付部
　１２　　リソース算出部
　１３　　コンテナ設定部
　２０　　ワーカーノード
　３００　ＶＮＦＭ（リソース管理機構）
　４００　ＶＩＭ（リソース管理機構）
　１０００　コンテナリソース設計システム

Claims (5)

  1. 　仮想化されたコンテナシステムのリソース設計を行うコンテナリソース設計装置であって、
    　前記コンテナシステムは、コンテナが配置されることによりサービスを提供する複数のワーカーノードと、当該ワーカーノードの生成および運用を行う前記コンテナリソース設計装置とにより構成されており、
    　前記コンテナリソース設計装置は、
    　１つ以上の前記コンテナの集合であるＰｏｄ単位での当該Ｐｏｄの冗長化の数を示すレプリカセット数、前記コンテナを起動させるための条件を示すアフィニティルール、および、自己修復が可能な状態を維持するために障害の発生が許容される前記ワーカーノードの数を示す障害許容数、を含む定義情報を取得するコンテナ設定受付部と、
    　前記レプリカセット数、前記アフィニティルールおよび前記障害許容数を前記定義情報から抽出し、前記障害許容数以下の障害が前記ワーカーノードに発生した場合でも、前記レプリカセット数を満たし、かつ、前記アフィニティルールで規定される条件を満たした上で、最低限必要な前記ワーカーノードの数を示す必要ワーカーノード数を算出するとともに、
    　算出された前記必要ワーカーノード数を含む、リソースの払い出しの指示情報であるリソース払出指示情報を、リソース管理機構に送信することにより、前記必要ワーカーノード数の前記ワーカーノードをリソースとして払い出させるリソース算出部と、
    　払い出された前記ワーカーノードに、前記レプリカセット数で示される数の前記Ｐｏｄの配置を決定し、前記Ｐｏｄの配置を決定したワーカーノードに、前記Ｐｏｄを構成するコンテナの設定を指示するコンテナ設定情報を送信するコンテナ設定部と、
    　を備えることを特徴とするコンテナリソース設計装置。
  2. 　前記コンテナ設定受付部は、各々異なるＰｏｄに関する複数の前記定義情報を取得し、
    　前記リソース算出部は、各々のＰｏｄが複数の前記定義情報それぞれで示される、前記障害許容数以下の障害が前記ワーカーノードに発生した場合でも、前記レプリカセット数を満たし、かつ、前記アフィニティルールで規定される条件を満たした上で、全体として最低限必要な前記必要ワーカーノード数を算出すること
    　を特徴とする請求項１に記載のコンテナリソース設計装置。
  3. 　前記アフィニティルールに、前記コンテナを起動させるリソースの種別を示すラベルが付されている場合に、
    　前記リソース算出部は、前記ラベルで示されるリソースの種別を判別し、判別した種別のリソースにおいて、最低限必要な前記ワーカーノードの数を示す必要ラベルノード数を算出し、前記リソース払出指示情報に含めて前記リソース管理機構に送信すること
    　を特徴とする請求項１に記載のコンテナリソース設計装置。
  4. 　仮想化されたコンテナシステムのリソース設計を行うコンテナリソース設計装置のコンテナリソース設計方法であって、
    　前記コンテナシステムは、コンテナが配置されることによりサービスを提供する複数のワーカーノードと、当該ワーカーノードの生成および運用を行う前記コンテナリソース設計装置とにより構成されており、
    　前記コンテナリソース設計装置は、
    　１つ以上の前記コンテナの集合であるＰｏｄ単位での当該Ｐｏｄの冗長化の数を示すレプリカセット数、前記コンテナを起動させるための条件を示すアフィニティルール、および、自己修復が可能な状態を維持するために障害の発生が許容される前記ワーカーノードの数を示す障害許容数、を含む定義情報を取得するステップと、
    　前記レプリカセット数、前記アフィニティルールおよび前記障害許容数を前記定義情報から抽出し、前記障害許容数以下の障害が前記ワーカーノードに発生した場合でも、前記レプリカセット数を満たし、かつ、前記アフィニティルールで規定される条件を満たした上で、最低限必要な前記ワーカーノードの数を示す必要ワーカーノード数を算出するステップと、
    　算出された前記必要ワーカーノード数を含む、リソースの払い出しの指示情報であるリソース払出指示情報を、リソース管理機構に送信することにより、前記必要ワーカーノード数の前記ワーカーノードをリソースとして払い出させるステップと、
    　払い出された前記ワーカーノードに、前記レプリカセット数で示される数の前記Ｐｏｄの配置を決定し、前記Ｐｏｄの配置を決定したワーカーノードに、前記Ｐｏｄを構成するコンテナの設定を指示するコンテナ設定情報を送信するステップと、
    　を実行することを特徴とするコンテナリソース設計方法。
  5. 　コンピュータを、請求項１乃至請求項３のいずれか一項に記載のコンテナリソース設計装置として機能させるためのプログラム。
PCT/JP2020/020042 2020-05-21 2020-05-21 コンテナリソース設計装置、コンテナリソース設計方法およびプログラム WO2021234885A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/926,936 US20230195497A1 (en) 2020-05-21 2020-05-21 Container resource designing device, container resource designing method, and program
PCT/JP2020/020042 WO2021234885A1 (ja) 2020-05-21 2020-05-21 コンテナリソース設計装置、コンテナリソース設計方法およびプログラム
JP2022524782A JP7533576B2 (ja) 2020-05-21 2020-05-21 コンテナリソース設計システムおよびコンテナリソース設計方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/020042 WO2021234885A1 (ja) 2020-05-21 2020-05-21 コンテナリソース設計装置、コンテナリソース設計方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2021234885A1 true WO2021234885A1 (ja) 2021-11-25

Family

ID=78708277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/020042 WO2021234885A1 (ja) 2020-05-21 2020-05-21 コンテナリソース設計装置、コンテナリソース設計方法およびプログラム

Country Status (3)

Country Link
US (1) US20230195497A1 (ja)
JP (1) JP7533576B2 (ja)
WO (1) WO2021234885A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11809276B2 (en) * 2021-02-26 2023-11-07 EMC IP Holding Company LLC Container-based stateful application resilience to node failure
US20230169168A1 (en) * 2021-11-29 2023-06-01 Microsoft Technology Licensing, Llc. Detect anomalous container deployment at a container orchestration service

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Manifest Nginx", KUBERNETES, 16 April 2019 (2019-04-16), pages 1 - 3, XP055874158, Retrieved from the Internet <URL:https://noumenon-th.net/programming/2019/04/16/manifest01> [retrieved on 20211217] *
KUBERNETES MAGNUM: "Run Kubernetes manifest in Magnum", THINK IT, 12 June 2016 (2016-06-12), pages 1 - 17, XP055874156, Retrieved from the Internet <URL:https://thinkit.co.jp/article/9378> [retrieved on 20211217] *

Also Published As

Publication number Publication date
JP7533576B2 (ja) 2024-08-14
US20230195497A1 (en) 2023-06-22
JPWO2021234885A1 (ja) 2021-11-25

Similar Documents

Publication Publication Date Title
US11425194B1 (en) Dynamically modifying a cluster of computing nodes used for distributed execution of a program
US8321558B1 (en) Dynamically monitoring and modifying distributed execution of programs
US11263084B2 (en) Saving program execution state
US9280390B2 (en) Dynamic scaling of a cluster of computing nodes
US8260840B1 (en) Dynamic scaling of a cluster of computing nodes used for distributed execution of a program
US20200073655A1 (en) Non-disruptive software update system based on container cluster
US8442958B2 (en) Server change management
US20190288914A1 (en) Allocating VNFC Instances with Anti Affinity Rule to Hosts
CN102981929B (zh) 磁盘镜像的管理方法和系统
US8966025B2 (en) Instance configuration on remote platforms
JP5526784B2 (ja) 縮退構成設計システムおよび方法
US20140310703A1 (en) Multi-machine deployment and configuration of multi-tiered applications
CN113886089B (zh) 一种任务处理方法、装置、系统、设备及介质
WO2021234885A1 (ja) コンテナリソース設計装置、コンテナリソース設計方法およびプログラム
AU2014209611A1 (en) Instance host configuration
CN111427675A (zh) 一种数据处理方法、装置以及计算机可读存储介质
US20230034835A1 (en) Parallel Processing in Cloud
JP2017091330A (ja) 計算機システム及び計算機システムのタスク実行方法
CN117573291A (zh) 跨数据中心的多集群管理方法、装置、设备及存储介质
JP6098167B2 (ja) 仮想マシン管理プログラム及びその方法
EP4158874B1 (en) Staging configuration changes with deployment freeze options
Hernández et al. Using cloud-based resources to improve availability and reliability in a scientific workflow execution framework
JP6696947B2 (ja) 仮想マシンエミュレートシステム、仮想マシンエミュレート方法およびコンピュータプログラム
US20240281242A1 (en) Update control method of container infrastructure cluster, update system of container infrastructure cluster, update control device, and update control program
CN117742797A (zh) 一种GitLab流水线发布方法、系统、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20937110

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022524782

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20937110

Country of ref document: EP

Kind code of ref document: A1