Update control method of container infrastructure cluster, update system of container infrastructure cluster, update control device, and update control program

[0001] This application is a National Stage application under 35 U.S.C. § 371 of International Application No. PCT/JP2021/024331, having an International Filing Date of Jun. 28, 2021, the disclosure of which is considered part of the disclosure of this application, and is incorporated by reference in its entirety into this application.

[0002] The present invention relates to a container-based cluster update control method using a virtualization technology, a container-based cluster, an update control device, and an update control program.

[0003] A container-based cluster including a worker node for executing a containerized application and a master node that manages the worker node has been proposed. As orchestration software for integrally managing the container-based cluster, Kubernetes has been widely used.

[0004] Conventionally, as a method of updating a container-based cluster including a master node and a worker node or an application on a container, a rolling update method and a blue-green method are used.

[0005] The rolling update method is a method of sequentially updating one by one while operating a system (refer to Non Patent Literature 1). The blue-green method is a method in which a container-based cluster is constructed as a new actual environment separately from an existing container-based cluster, and is updated by being switched by a load balancer (refer to Non Patent Literature 2).

• • [0006] Non Patent Literature 1: “Performing a Rolling Update”, [online], kubernetes, Jun. 5, 2020, [retrieved on Jun. 21, 2021], Internet <https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/update/update-intro/>
  • [0007] Non Patent Literature 2: “What is blue green deployment?”, [online], Red Hat, [retrieved on Jun. 21, 2021], Internet <https://www.redhat.com/ja/topics/devops/what-is-blue-green-deployment>

[0008] However, when update of a container-based cluster is executed according to the rolling update method, it is not possible to return to a state before the update in a case where a problem occurs during the update. That is, there is an irreversible execution process in the rolling update method. For example, a master node managed by Kubernetes cannot return to an original version after the update is executed.

[0009] On the other hand, in the blue-green method, there is no irreversible process as described above, but twice the resources (a server and the like) during an operation are required during update work, and the cost at the time of the update work increases.

[0010] The present invention has been made in view of such circumstances, and an object of the present invention is to make it possible to return to a state before the occurrence of a problem even if a problem occurs during update in a container-based cluster, and to make it possible to execute update with less resources than the blue-green method.

[0011] According to the present invention, there is provided an update control method for a container-based cluster using a container-based cluster update system including a container-based cluster, an update control device that controls update of the container-based cluster, and a load balancer, in which the container-based cluster includes a plurality of worker nodes that cause a virtualized container to execute processing of an application and a master node that manages the worker nodes, one or more of the applications being made redundant in the plurality of worker nodes, and the redundant applications being installed in different worker nodes, the update control method including causing the update control device to execute; a master node construction step of constructing a new master node in a new container-based cluster different from the container-based cluster in an initial state before update; a worker node construction step of constructing, in the new container-based cluster, a minimum number of the worker nodes required for a migration target application to execute processing, the migration target application being selected from among the one or more applications installed in the plurality of worker nodes of the container-based cluster in the initial state and indicating an application that is a target to be sequentially migrated to the new container-based cluster; an application installation step of installing the migration target application in the minimum required number of the constructed worker nodes; a communication connection step of communicatively connecting the worker node in which the migration target application is installed and the load balancer; an application deletion step of deleting the migration target application from the container-based cluster in the initial state; a worker node deletion step of deleting a worker node in which the application is no longer installed due to the deletion of the migration target application from the container-based cluster in the initial state; and a worker node addition step of adding the number of worker nodes deleted from the container-based cluster in the initial state to the new container-based cluster, in which the update control device sequentially selects the migration target application in the container-based cluster in the initial state to install the migration target application in a worker node constructed in the new container-based cluster, repeats deletion of the migration target application from the container-based cluster in the initial state and deletion of a worker node in which the application is not installed to migrate all applications, and deletes the master node of the container-based cluster in the initial state to update the container-based cluster in the initial state to the new container-based cluster, and, in each of the steps, checks whether or not each of the steps has been executed normally by inquiring the master node of the container-based cluster in the initial state or the new container-based cluster, and in a case where there is a step that has not been executed normally, returns processing to immediately before the step, and executes the step again.

[0012] According to the present invention, in the container-based cluster, even if a problem occurs during the update, it is possible to return to a state before the occurrence of the problem, and it is possible to execute the update with less resources than in the blue-green method.

[0025] Next, a mode for carrying out the present invention (hereinafter, referred to as the “present embodiment”) will be described.

[0026] FIG. 1 is a diagram illustrating an overall configuration of a container-based cluster update system 1 including an update control device 10 according to the present embodiment. FIG. 1 illustrates a configuration during a normal operation before update is performed (hereinafter, referred to as an “initial state”).

[0027] As illustrated in FIG. 1, a container-based cluster 100 (100a) includes a worker node 40 (in each drawing, denoted by “Worker”) in which a containerized application is provided and a master node 30 (in each drawing, denoted by “Master”) that manages a plurality of worker nodes 40. The container-based cluster 100 before the update is executed (initial state) is denoted by the reference sign 100a, and functional units of the container-based cluster 100a have the reference sign “a” added thereto.

[0028] The container-based cluster 100 (100a) includes a container management unit 110 (110a) and a container compute unit 120 (120a). In the container compute unit 120 (120a), one or more worker nodes 40 are disposed, and a service is executed by a containerized application set on each worker node 40. In a case where Kubernetes is employed as orchestration software that manages the container-based cluster 100, the worker node 40 performs processing in units of Pod including one or more containers that operate an application (for example, APL-A that will be described later).

[0029] One or more master nodes 30 that manage (setting, state monitoring, and the like) each worker node 40 are disposed in the container management unit 110 (110a). A plurality of master nodes 30 (usually three in a commercial cluster) is provided for redundancy, but the number of master nodes is not limited to three as illustrated in FIG. 1, and one or more master nodes may be provided. The plurality of redundant master nodes 30 are subjected to a synchronization process by orchestration software (for example, Kubernetes).

[0030] The container-based cluster update system 1 according to the present embodiment includes the container-based cluster 100a before update execution (initial state), a load balancer 5 that allocates a processing request to applications, an update control device 10, and a new container-based cluster 100b (refer to FIGS. 2 to 11) constructed under the control of the update control device 10.

[0031] The container-based cluster update system 1 is characterized by updating the application with respect to the container-based cluster 100a according to the rolling update method over the container-based cluster 100 (100a, 100b) while employing the blue-green method.

[0032] Specifically, the update control device 10 constructs the container management unit 110 (110b) in the new container-based cluster 100b, and then constructs the container compute unit 120 (120b) including the minimum required number of worker nodes 40. The load balancer 5 completes the update by switching a communication path to the new container-based cluster 100b.

[0033] Hereinafter, functions and processes of the container-based cluster update system 1 will be described in detail. The functions of the container-based cluster 100 and the load balancer 5 are conventional technologies, and thus descriptions thereof will be omitted.

[0034] The update control device 10 performs control for updating (upgrading) the container-based cluster 100a before update execution (initial state) and performing migration to the new container-based cluster 100b after update. The update control device 10 is communicatively connected to each master node 30 and each worker node 40 in the container-based cluster 100 (100a, 100b) or the load balancer 5.

[0035] The update control device 10 is implemented by a computer including a control unit, an input/output unit, and a storage unit (not illustrated) (refer to FIG. 12 that will be described later in detail).

[0036] The input/output unit inputs and outputs information to and from each master node 30 and each worker node 40 in the container-based cluster 100 (100a, 100b), the load balancer 5, other external devices, and the like. The input/output unit includes a communication interface that transmits and receives information via a communication line.

[0037] The storage unit stores information regarding each master node 30, each worker node 20, a containerized application, and the like, which is information regarding the container-based cluster 100 (100a, 100b).

[0038] As illustrated in FIG. 1, the control unit of the update control device 10 includes a load balancer control unit 101, a master node control unit 102, a worker node control unit 103, an application management unit 104, and a state acquisition unit 105.

[0039] The load balancer control unit 101 instructs the load balancer 5 to set communication for the application set in the worker node 40 of the constructed new container-based cluster 100b and to check that setting of a communication path has been appropriately performed (refer to FIG. 5).

[0040] In a case where setting of an application is performed normally in the constructed new container-based cluster 100b, the load balancer control unit 101 deletes set communication with the application of the container-based cluster 100a (refer to FIG. 10).

[0041] The master node control unit 102 constructs a container management unit 110b of the constructed new container-based cluster 100b (refer to FIG. 2). Specifically, the master node control unit 102 constructs one or more master nodes 30 in the container-based cluster 100b as the container management unit 110b.

[0042] In a case where migration to the container-based cluster 100b has been completed normally, the master node control unit 102 deletes the container management unit 110a of the container-based cluster 100a, specifically, each constructed master node 30 (refer to FIGS. 7 and 11).

[0043] The worker node control unit 103 constructs a container compute unit 120b in the new container-based cluster 100b (refer to FIG. 3). Specifically, the worker node control unit 103 constructs the minimum required number of worker nodes 40 in the container-based cluster 100b as the container compute unit 120b.

[0044] As the minimum required number of worker nodes 40, the worker node control unit 103 constructs the number of applications (here, APL-A, APL-B, and APL-C) that can be added one by one. That is, the worker node control unit 103 constructs, in the new container-based cluster 100b, the minimum number of worker nodes 40 required for a migration target application to execute processing, the application (migration target application) to be sequentially migrated to the new container-based cluster 100b being selected from among one or more applications installed in a plurality of worker nodes of the container-based cluster 100a in an initial state.

[0045] In the present embodiment, it is assumed that two worker nodes 40 are necessary to operate three applications (APL-A, APL-B, and APL-C) as selected migration target applications. The minimum required number may be set in advance according to a processing load of each application and stored in, for example, a storage unit (not illustrated) of the update control device 10. Alternatively, the worker node control unit 103 may first add one worker node, and if the worker node cannot be set normally, may further add one worker node at a time to check that the worker node can be set normally.

[0046] When the setting of addition of each application is performed normally in the new container-based cluster 100b, the worker node control unit 103 selects and deletes the worker node 40 in which no application is installed in the container-based cluster 100a (refer to FIG. 7).

[0047] In a case where there is no worker node 40 in which no application is installed, the worker node control unit 103 moves an application to another worker node 40 under the control of the application management unit 104, and thus generates the worker node 40 in which no application is installed and deletes the worker node 40.

[0048] Here, in a case where Kubernetes is employed as orchestration software that manages the container-based cluster 100, the application management unit 104 may instruct the master node 30 to move an application to another worker node 40 by using, for example, “kubectl drain <NODE name>” that is a Pod evacuation command from a server.

[0049] In a case where the worker node 40 is constructed in the constructed new container-based cluster 100b, the application management unit 104 sets a containerized application (migration target application) on the worker node 40 (refer to FIGS. 4 and 9).

[0050] In a case where setting of a new application has been completed normally in the container-based cluster 100b, the application management unit 104 deletes a corresponding application (migration target application) in the container-based cluster 100a (refer to FIGS. 6 and 10).

[0051] The state acquisition unit 105 checks that each process of the load balancer control unit 101, the master node control unit 102, the worker node control unit 103, and the application management unit 104 has been performed normally by inquiring the master nodes 30 of the container-based clusters 100a and 100b. In a case where it is checked that the process has not been performed normally, the state acquisition unit 105 notifies a functional unit that has performed the process to return to the state before the process, and instructs to execute the process again.

[0052] In a case where Kubernetes is employed as orchestration software that manages the container-based cluster 100, the state acquisition unit 105 can check the normality of each worker node 40 by giving an instruction to the master node 30 by using, for example, “kubectl get nodes” which is a normality check command for each worker node 40.

[0053] Next, an update control process for the container-based cluster 100 performed by the container-based cluster update system 1 according to the present embodiment will be described with reference to FIGS. 1 to 11.

[0054] It is assumed that the container-based cluster 100 is in an actual operation state (initial state) as illustrated in FIG. 1. As illustrated in FIG. 1, it is assumed that one or more master nodes 30 (here, three master nodes 30) are disposed in the container-based cluster 100a. It is assumed that one or more applications (here, three applications such as APL-A, APL-B, and APL-C) are installed and operated as applications for realizing services in the plurality of worker nodes 40 (here, three worker nodes 40). Each application is made redundant to maintain the availability of the service even in the actual operation state, and two applications each operate on the container, such as APL-A-1, APL-A-2, APL-B-1, APL-B-2, APL-C-1, and APL-C-2.

[0055] Here, application information (referred to as “APL information 300”) set in the container compute unit 120a is “version: 1, replica: 2” for each application (APL-A, APL-B, and APL-C) as indicated by the APL information 300a in FIG. 1. That is, this indicates that a version of each application is “1”, and each application operates in two (redundant).

[0056] Hereinafter, an update control process of the container-based cluster update system 1 will be described. This update control process is started, for example, when the update control device 10 receives an update start instruction for the container-based cluster 100a from an external apparatus (not illustrated) that manages the container-based cluster update system 1.

[First Step]

[0057] FIG. 2 is a diagram for describing a [first step] of constructing the container management unit 110b of the new container-based cluster 100b. The [first step] corresponds to a master node construction step described in the claims.

[0058] For example, when the update control device 10 receives an update start instruction, the master node control unit 102 (FIG. 1) constructs the container management unit 110b of the constructed new container-based cluster 100b as the [first step]. Specifically, the master node control unit 102 constructs three master nodes 30 in the container-based cluster 100b as the container management unit 110b as illustrated in FIG. 2, similarly to the container management unit 110a of the container-based cluster 100a.

[0059] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not each master node 30 of the container management unit 110b of the container-based cluster 100b is constructed normally by inquiring the master node 30 of the container management unit 110b. The state acquisition unit 105 notifies the master node control unit 102 of a check result. Here, in a case where a notification indicating that the construction has not been performed normally is received, the master node control unit 102 returns the process to immediately before the [first step] and executes the [first step] again.

[Second Step]

[0060] FIG. 3 is a diagram for describing a [second step] of constructing the container compute unit 120b of the new container-based cluster 100b. The [second step] corresponds to a worker node construction step described in the claims.

[0061] As the [second step], the worker node control unit 103 (FIG. 1) of the update control device 10 constructs the container compute unit 120b of the container-based cluster 100b as illustrated in FIG. 3. Specifically, the worker node control unit 103 constructs, as the container compute unit 120b, the minimum number of worker nodes 40 required for a migration target application to execute processing, the migration target application being selected from among one or more applications installed in the plurality of worker nodes 40 of the container-based cluster 100a in an initial state.

[0062] In the present embodiment, it is assumed that two worker nodes 40 are required at a minimum as described above in order to operate three applications (APL-A, APL-B, and APL-C). Therefore, the worker node control unit 103 constructs two worker nodes 40 (here, Workers “1” and “2”).

[0063] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not each worker node 40 (here, two Workers “1” and “2”) of the container compute unit 120b of the container-based cluster 100b has been constructed normally by inquiring the master node 30 of the container management unit 110b. The state acquisition unit 105 notifies the worker node control unit 103 of the check result. Here, in a case where a notification indicating that the construction has not been performed normally is received, the worker node control unit 103 returns the process to immediately before the [second step] and executes the [second step] again.

[Third Step]

[0064] FIG. 4 is a diagram for describing a [third step] of constructing an application in the container compute unit 120b of the new container-based cluster 100b. The [third step] corresponds to an application installation step described in the claims.

[0065] As the [third step], the application management unit 104 (FIG. 1) of the update control device 10 constructs applications (APL-A, APL-B, and APL-C) that are migration target applications in the container compute unit 120b of the container-based cluster 100b as illustrated in FIG. 4.

[0066] Here, APL-A-1, APL-B-1, and APL-C-1 are constructed under the control of the application management unit 104. As indicated by the version “2” of the APL information 300b in FIG. 4, these applications show an example in which the version is higher than that of the applications of the container-based cluster 100a in the initial state.

[0067] In the present embodiment, an example in which the container-based cluster 100 itself and the applications are simultaneously updated will be described. However, only the container-based cluster 100 may be updated without upgrading the version of the applications.

[0068] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not each application (APL-A-1, APL-B-1, and APL-C-1) has been constructed normally in the container compute unit 120b of the container-based cluster 100b by inquiring the master node 30 of the container management unit 110b. The state acquisition unit 105 notifies the application management unit 104 of the check result. Here, in a case where a notification indicating that the application has not been constructed normally is received, the application management unit 104 returns the process to immediately before the [third step] and executes the [third step] again.

[Fourth Step]

[0069] FIG. 5 is a diagram for describing a [fourth step] of setting communication of the application constructed in the container compute unit 120b of the new container-based cluster 100b. The [fourth step] corresponds to a communication connection step described in the claims.

[0070] As the [fourth step], as illustrated in FIG. 5, the load balancer control unit 101 (FIG. 1) and the application management unit 104 (FIG. 1) of the update control device 10 set a communication path such that communication can be performed between the load balancer 5 and each application (APL-A-1, APL-B-1, and APL-C-1) constructed in the container-based cluster 100b.

[0071] After setting the communication path, the state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not the communication path of each application (APL-A-1, APL-B-1, and APL-C-1) has been constructed normally by inquiring the master node 30 of the container management unit 110b. The state acquisition unit 105 checks a state of the load balancer 5, and checks that communication with each application (APL-A-1, APL-B-1, and APL-C-1) of the container-based cluster 100b is set normally.

[0072] The state acquisition unit 105 notifies the application management unit 104 and the load balancer control unit 101 of the check result. Here, in a case where a notification indicating that the setting has not been performed normally is received, the application management unit 104 and the load balancer control unit 101 return the process to immediately before [fourth step] and execute [fourth step] again.

[Fifth Step]

[0073] FIG. 6 is a diagram for describing a [fifth step] of reducing the number of replicas of the application (APL-A, APL-B, and APL-C) provided in the container compute unit 120a of the container-based cluster 100a in the initial state. The [fifth step] corresponds to an application deletion step described in the claims.

[0074] As the [fifth step], the application management unit 104 (FIG. 1) of the update control device 10 reduces the number of replicas of an application (APL-A, APL-B, and APL-C) that is a migration target application of the container compute unit 120a of the container-based cluster 100a. Here, as illustrated in FIG. 6, the application management unit 104 deletes each application (APL-A-1, APL-B-1, and APL-C-1). Consequently, as illustrated in FIG. 6, the number of replicas of each application becomes “one” in the APL information 300a of the container-based cluster 100a in the initial state.

[0075] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each application (APL-A-1, APL-B-1, and APL-C-1) has been deleted normally by inquiring the master node 30 of the container management unit 110a. The state acquisition unit 105 notifies the application management unit 104 of the check result. Here, in a case where a notification indicating that deletion has not been performed normally is received, the application management unit 104 returns the process to immediately before the [fifth step] and executes the [fifth step] again.

[Sixth Step]

[0076] FIG. 7 is a diagram for describing a [sixth step] of reducing the number of worker nodes 40 provided in the container compute unit 120a of the container-based cluster 100a in the initial state. The [sixth step] corresponds to a worker node deletion step described in the claims.

[0077] As the [sixth step], as illustrated in FIG. 7, the worker node control unit 103 (FIG. 1) of the update control device 10 checks each worker node 40 of the container compute unit 120a of the container-based cluster 100a, and deletes the worker node 40 in which no application is installed. In FIG. 7, the deleted worker node 40 (Worker “1”) is indicated by a dashed line.

[0078] In a case where there is no worker node 40 in which no application is installed, the worker node control unit 103 notifies the application management unit 104 of the fact. Under the control of the application management unit 104, any one of the applications is moved to another worker node 40 to generate the worker node 40 in which no application is installed. The worker node control unit 103 deletes the worker node 40.

[0079] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not the worker node 40 (Worker “1”) in which no application is installed has been deleted normally by inquiring the master node 30 of the container management unit 110a. The state acquisition unit 105 notifies the worker node control unit 103 of the check result. Here, in a case where a notification indicating that deletion has not been performed normally is received, the worker node control unit 103 returns the process to immediately before [sixth step] and executes [sixth step] again.

[Seventh Step]

[0080] FIG. 8 is a diagram for describing [seventh step] of adding the worker node 40 to the container compute unit 120b of the new container-based cluster 100b. The [seventh step] corresponds to a worker node addition step described in the claims.

[0081] As the [seventh step], as illustrated in FIG. 8, the worker node control unit 103 (FIG. 1) of the update control device 10 adds a new worker node 40 in the container compute unit 120b of the container-based cluster 100b. The number of new worker nodes 40 to be added is the same as the number of worker nodes deleted in the [sixth step]. FIG. 8 illustrates an example in which one worker node 40 (Worker “3”) is constructed by the worker node control unit 103.

[0082] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not the worker node 40 (here, one Worker “3”) has been constructed normally in the container compute unit 120b of the container-based cluster 100b by inquiring the master node 30 of the container management unit 110b.

[0083] The state acquisition unit 105 notifies the worker node control unit 103 of the check result. Here, in a case where a notification indicating that the construction has not been performed normally is received, the worker node control unit 103 returns the process to immediately before [seventh step] and executes [seventh step] again.

[Eighth Step]

[0084] FIG. 9 is a diagram for describing an [eighth step] of adding an application to the container compute unit 120b of the new container-based cluster 100b.

[0085] As the [eighth step], as illustrated in FIG. 9, the application management unit 104 (FIG. 1) of the update control device 10 adds applications (APL-A, APL-B, and APL-C) to the container compute unit 120b of the container-based cluster 100b as the next selected migration target applications.

[0086] Here, APL-A-2, APL-B-2, and APL-C-2 are added under the control of the application management unit 104. Due to the addition of the applications, as indicated by the APL information 300b in FIG. 9, the number of replicas of each application (APL-A, APL-B, and APL-C) of the version “2” becomes “two”.

[0087] The state acquisition unit 105 (FIG. 1) of the update control device 10 checks whether or not each application (APL-A-2, APL-B-2, APL-C-2) has been added normally to the container compute unit 120b of the container-based cluster 100b by inquiring the master node 30 of the container management unit 110b. The state acquisition unit 105 notifies the application management unit 104 of the check result. Here, in a case where a notification indicating that the application has not been constructed normally is received, the application management unit 104 returns the process to immediately before [eighth step] and executes [eighth step] again.

[Ninth Step]

[0088] FIG. 10 is a diagram for describing a [ninth step] of deleting applications (APL-A, APL-B, and APL-C) and deleting a communication path provided in the container compute unit 120a of the container-based cluster 100a in the initial state.

[0089] As the [ninth step], the load balancer control unit 101 (FIG. 1) of the update control device 10 deletes a communication path between the load balancer 5 and each application (APL-A-2, APL-B-2, APL-C-2) of the container-based cluster 100a as illustrated in FIG. 10. The application management unit 104 deletes each application (APL-A-2, APL-B-2, APL-C-2) in the container-based cluster 100a.

[0090] After deletion of the communication path and each application (APL-A-2, APL-B-2, APL-C-2), the state acquisition unit 105 (FIG. 1) of the update control device 10 checks a state of the load balancer 5 and checks that the communication path with each application (APL-A-2, APL-B-2, APL-C-2) of the container-based cluster 100a has been deleted normally. The state acquisition unit 105 checks whether each application (APL-A-2, APL-B-2, APL-C-2) has been deleted normally by inquiring the master node 30 of the container management unit 110a.

[0091] The state acquisition unit 105 notifies the application management unit 104 and the load balancer control unit 101 of the check result. Here, in a case where a notification indicating that the communication path and each application (APL-A-2, APL-B-2, APL-C-2) have not been deleted normally is received, the application management unit 104 and the load balancer control unit 101 return the process to immediately before the [ninth step] and execute the [ninth step] again.

[Tenth Step]

[0092] FIG. 11 is a diagram for describing a [tenth step] of deleting the container compute unit 120a and the container management unit 110a of the container-based cluster 100a in the initial state.

[0093] As the [tenth step], as illustrated in FIG. 11, the worker node control unit 103 (FIG. 1) of the update control device 10 deletes each worker node 40 (here, Workers “2” and “3”) of the container compute unit 120a of the container-based cluster 100a. The master node control unit 102 (FIG. 1) deletes each master node 30 of the container management unit 110a.

[0094] As described above, according to the container-based cluster update system 1 of the present embodiment, a total of six worker nodes 40 are required to execute update in the case of the conventional blue-green method, but update can be performed by the five worker nodes 40. Therefore, the number of servers required for update can be reduced compared with the blue-green method.

[0095] According to the container-based cluster update system 1 of the present embodiment, under the control of the update control device 10, in a case where the processing cannot be executed normally in any step in the update, it is possible to return to the previous step. Therefore, it is possible to reliably update the container-based cluster 100.

[0096] The present invention is not limited to the above-described embodiment, and many modifications can be made by those skilled in the art within the technical idea of the present invention.

[0097] In the present embodiment, with the application (APL-A, APL-B, and APL-C) installed in the container-based cluster 100a in an initial state as one set, first, APL-A-1, APL-B-1, and APL-C-1 (migration target applications) are added to the new container-based cluster 100b and deleted from the container-based cluster 100a in an initial state, and then APL-A-2, APL-B-2, and APL-C-2 (next migration target applications) are added or deleted, so that update is realized. However, the present invention is not limited to the processing by the set of applications, and an addition or deletion process may be performed with one application as a migration target application in the order of APL-A, APL-B, and APL-C, for example, in the order of APL-A-1, APL-B-1, APL-C-1, APL-A-2, APL-B-2, and APL-C-2. In this case, for example, when APL-C-1 is moved to the new container-based cluster 100b, for example, a process of moving APL-A-2 that is another application in the original worker node 40 in which APL-C-1 is installed to another worker node 40 to generate a worker node 40 in which no application is installed is required. However, if the applications are processed one by one, the minimum required number of work nodes can be reduced to one. Therefore, the number of servers required at the time of update can be further reduced.

[0098] The update control device 10 according to the present embodiment is implemented by, for example, a computer 900 having a configuration as illustrated in FIG. 12.

[0099] FIG. 12 is a hardware configuration diagram illustrating an example of the computer 900 that realizes the functions of the update control device 10 according to the present embodiment. The computer 900 includes a central processing unit (CPU) 901, a read only memory (ROM) 902, a RAM 903, a hard disk drive (HDD) 904, an input/output interface (I/F) 905, a communication I/F 906, and a media I/F 907.

[0100] The CPU 901 operates on the basis of a program (update control program) stored in the ROM 902 or the HDD 904, and performs control based on control units (the load balancer control unit 101, the master node control unit 102, the worker node control unit 103, the application management unit 104, and the state acquisition unit 105). The ROM 902 stores a boot program to be executed by the CPU 901 when the computer 900 is started, a program related to hardware of the computer 900, and the like.

[0101] The CPU 901 controls an input device 910 such as a mouse or a keyboard and an output device 911 such as a display or a printer via the input/output I/F 905. The CPU 901 acquires data from the input device 910 and outputs generated data to the output device 911 via the input/output I/F 905. A graphics processing unit (GPU) or the like may be used as a processor together with the CPU 901.

[0102] The HDD 904 stores a program to be executed by the CPU 901, data to be used by the program, and the like. The communication I/F 906 receives data from another device via a communication network (for example, a network (NW) 920), outputs the data to the CPU 901, and transmits data generated by the CPU 901 to another device via a communication network.

[0103] The media I/F 907 reads a program (update control program) or data stored in a recording medium 912, and outputs the read program or data to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process 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 digital versatile disc (DVD) or a phase change rewritable disk (PD), a magneto-optical recording medium such as a magneto optical disk (MO), a magnetic recording medium, a semiconductor memory, or the like.

[0104] For example, in a case where the computer 900 functions as the update control device 10 of the present invention, the CPU 901 of the computer 900 realizes each function of the update control device 10 by executing a program loaded on the RAM 903. Data in the RAM 903 is stored in the HDD 904. The CPU 901 reads a program related to a target process from the recording medium 912, and executes the program. Additionally, the CPU 901 may read the program related to the target process from another device via the communication network (NW 920).

[0105] Hereinafter, effects of the update control method for the container-based cluster according to the present invention will be described.

[0106] The update control method for the container-based cluster according to the present invention is a method of controlling update of the container-based cluster 100 by the container-based cluster update system 1 including the container-based cluster 100, the update control device 10 that controls update of the container-based cluster 100, and the load balancer 5, in which the container-based cluster 100 includes a plurality of worker nodes 40 that cause a virtualized container to executes processing of an application and the master node 30 that manages the worker nodes 40, one or more applications being made redundant in the plurality of worker nodes 40, and the redundant applications being installed in different worker nodes 40, the update control method including causing the update control device 10 to execute a master node construction step of constructing the new master node 30 in the new container-based cluster 100b different from the container-based cluster 100a in an initial state before update; a worker node construction step of constructing, in the new container-based cluster 100b, a minimum number of worker nodes 40 required for a migration target application to execute processing, the migration target application being selected from among the one or more applications installed in the plurality of worker nodes 40 of the container-based cluster 100a in the initial state and indicating an application that is a target to be sequentially migrated to the new container-based cluster 100b; an application installation step of installing the migration target application in the minimum required number of the constructed worker nodes 40; a communication connection step of communicatively connecting the worker node 40 in which the migration target application is installed and the load balancer 5; an application deletion step of deleting the migration target application from the container-based cluster 100a in the initial state; a worker node deletion step of deleting a worker node 40 in which the application is no longer installed due to the deletion of the migration target application from the container-based cluster 100a in the initial state; and a worker node addition step of adding the number of worker nodes 40 deleted from the container-based cluster 100a in the initial state to the new container-based cluster 100b, in which the update control device sequentially selects the migration target application in the container-based cluster 100a in the initial state to install the migration target application in a worker node 40 constructed in the new container-based cluster 100b, repeats deletion of the migration target application from the container-based cluster 100a in the initial state and deletion of a worker node 40 in which the application is not installed to migrate all applications, and deletes the master node 30 of the container-based cluster 100a in the initial state to update the container-based cluster 100a in the initial state to the new container-based cluster 100b, and, in each of the steps, checks whether or not each of the steps has been executed normally by inquiring the master node 30 of the container-based cluster 100a in the initial state or the new container-based cluster 100b, and in a case where there is a step that has not been executed normally, returns processing to immediately before the step, and executes the step again.

[0107] As described above, according to the update control method for the container-based cluster 100 of the present invention, in the case of the conventional blue-green method, two times the number of worker nodes 40 are required to execute update, but update can be performed with a smaller number than that.

[0108] Under the control of the update control device 10, in a case where processing cannot be executed normally in any step in the update, it is possible to return to the previous step. Therefore, it is possible to reliably update the container-based cluster 100.

[0109] In the worker node deletion step, in a case where there is no worker node in which an application is no longer installed, the update control device 10 moves an application installed in any of worker nodes to another worker node and generates a worker node in which an application is no longer installed.

[0110] As described above, in the worker node deletion step ([sixth step]), even in a case where there is no worker node 40 in which an application is no longer installed, the update control device 10 can generate the worker node 40 in which an application is not installed by moving the application to another worker node 40. Therefore, it is possible to reliably update the container-based cluster 100.

• • [0111] 1 Container-based cluster update system
  • [0112] 5 Load balancer
  • [0113] 10 Update control device
  • [0114] 30 Master node
  • [0115] 40 Worker node
  • [0116] 100, 100a, 100b Container-based cluster
  • [0117] 101 Load balancer control unit
  • [0118] 102 Master node control unit
  • [0119] 103 Worker node control unit
  • [0120] 104 Application management unit
  • [0121] 105 State acquisition unit
  • [0122] 110, 110a, 110b Container management unit
  • [0123] 120, 120a, 120b Container compute unit
  • [0124] 300, 300a, 300b APL Information