CONTAINER-BASED CLUSTER UPDATE CONTROL METHOD, CONTAINER-BASED CLUSTER UPDATE SYSTEM, UPDATE CONTROL DEVICE, AND UPDATE CONTROL PROGRAM

Abstract

An update control device (10) of a container base cluster update system (1) constructs a master node (30) in a new container base cluster (100a) and provides the minimum number of worker nodes (40) necessary to execute an application to be migrated. The update control device (10) deletes the application to be migrated in the container base cluster (100a) in an initial state, deletes a worker node (40) on which the application is not loaded, and then adds worker nodes (40) to a new container base cluster (100b), and sequentially migrates the application to be migrated to perform an update.

Description

[Technical field]

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

[0002] A container-based cluster has been proposed, which consists of worker nodes for running containerized applications and a master node for managing the worker nodes. Kubernetes is becoming popular as orchestration software for the integrated management of this container-based cluster.

[0003] Traditionally, the rolling update method and the blue-green method have been used to update the container-based cluster itself, which is composed of master nodes and worker nodes, and the applications on the containers. The rolling update method is a method in which the system is updated one by one while it is running (see Non-Patent Document 1). The blue-green method is a method in which a container-based cluster is built as a new production environment separately from the existing container-based cluster, and the update is performed by switching between them using a load balancer (see Non-Patent Document 2). [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] “Performing a rolling update”, [online], kubernetes, June 5, 2020, [Retrieved June 21, 2021], Internet<https: / / kubernetes.io / ja / docs / tutorials / kubernetes-basics / update / update-intro / > [Non-Patent Document 2] “What is Blue-Green Deployment?”, [online], Red Hat, [Retrieved June 21, 2021], Internet<https: / / www.redhat.com / ja / topics / devops / what-is-blue-green-deployment> Summary of the Invention [Problem to be solved by the invention]

[0005] However, when updating a container-based cluster using the rolling update method, if a problem occurs during the update, it is not possible to revert to the state before the update. In other words, the rolling update method involves an irreversible execution process. For example, a master node managed by Kubernetes cannot be reverted to the original version once an update is performed.

[0006] On the other hand, the blue-green method does not have the irreversible process described above, but during the update process, twice as many resources (servers, etc.) are required as during operation, which increases the cost of the update process.

[0007] The present invention was made in consideration of these points, and its objective is to enable a container-based cluster to be restored to the state before the problem occurred even if a problem occurs during an update, and to enable updates to be performed using fewer resources than the blue-green method. [Means for solving the problem]

[0008] The update control method for a container-based cluster according to the present invention is a method for controlling an update of a container-based cluster by a container-based cluster update system including a container-based cluster, an update control device for controlling an update of the container-based cluster, and a load balancer, the container-based cluster being configured with a plurality of worker nodes that execute application processing using virtualized containers, and a master node that manages the worker nodes, one or more of the applications are made redundant on the plurality of worker nodes, and the redundant applications are respectively installed on different worker nodes, and the update control device includes 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 the update, and a load balancer step of selecting one or more of the applications installed on the plurality of worker nodes of the container-based cluster in the initial state, the master node construction step of selecting an application to be sequentially migrated to the new container-based cluster, the application being selected from the one or more applications installed on the plurality of worker nodes of the container-based cluster in the initial state, the load balancer step of selecting an application to be sequentially migrated to the new container-based cluster ... a worker node construction step of constructing in the new container-based cluster the minimum number of worker nodes required for the application to be migrated to execute processing for the application to be migrated, an application installation step of installing the application to be migrated on the minimum number of worker nodes thus constructed, a communication connection step of connecting the worker nodes installing the application to be migrated to the load balancer, an application deletion step of deleting the application to be migrated in the container-based cluster in the initial state, a worker node deletion step of deleting in the container-based cluster in the initial state the worker node on which the application is no longer installed due to the deletion of the application to be migrated, and a worker node addition step of adding to the new container-based cluster the number of worker nodes deleted in the container-based cluster in the initial state, and sequentially selecting the application to be migrated in the container-based cluster in the initial state,The container-based cluster update control method includes: loading the application to be migrated onto a worker node constructed in the new container-based cluster; repeatedly deleting the application to be migrated from the container-based cluster in the initial state and deleting the worker node on which the application is not loaded, thereby migrating all applications; deleting the master node of the container-based cluster in the initial state, and updating the container-based cluster in the initial state to the new container-based cluster; and, in each of the steps, checking whether 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, if any step has not been executed normally, returning the process to just before the step, and executing the step again. Effect of the Invention

[0009] According to the present invention, even if a problem occurs during an update in a container-based cluster, it is possible to restore the state before the problem occurred, and it is possible to perform the update using fewer resources than the blue-green method. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating an overall configuration of a container-based cluster update system including an update control device according to an embodiment of the present invention. [Diagram 2] This is a diagram to explain the first step of constructing a container management section of a new container-based cluster. [Diagram 3] This is a diagram to explain the second step of building the container compute section of a new container-based cluster. [Figure 4] This is a diagram to explain the third step of building an application on the container compute section of a new container-based cluster. [Diagram 5]This figure explains the fourth step of configuring communication settings for an application built in the container compute section of a new container-based cluster. [Figure 6] This figure explains the fifth step of reducing the number of replicas of an application in the container compute section of a container-based cluster in its initial state. [Figure 7] This figure explains the sixth step of reducing the number of worker nodes in the container compute section of the initial container-based cluster. [Figure 8] This diagram explains Step 7, which is to add worker nodes to the container compute section of a new container-based cluster. [Figure 9] This diagram explains Step 8 of adding an application to the container compute section of a new container-based cluster. [Figure 10] This figure explains the 9th step, in which applications and communication paths are deleted from the container compute section of the container-based cluster in its initial state. [Figure 11] This figure explains the 10th step of deleting the container compute unit and the container management unit in an initial state container-based cluster. [Figure 12] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of the update control device according to the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Next, an embodiment of the present invention (hereinafter, referred to as "the present embodiment") will be described. Fig. 1 is a diagram showing the overall configuration of a container-based cluster update system 1 including an update control device 10 according to this embodiment. Fig. 1 shows the configuration during normal operation before an update is performed (hereinafter referred to as the "initial state"). 1, the container-based cluster 100 (100a) is composed of a worker node 40 (referred to as "Worker" in each figure) on which containerized applications are deployed, and a master node 30 (referred to as "Master" in each figure) that manages the multiple worker nodes 40. Note that the container-based cluster 100 before an update is executed (initial state) is indicated by the symbol 100a, and the functional parts of the container-based cluster 100a are denoted by the symbol "a."

[0012] The container-based cluster 100 (100a) includes a container management unit 110 (110a) and a container compute unit 120 (120a). One or more worker nodes 40 are arranged in the container compute unit 120 (120a), and services are executed by containerized applications set on each worker node 40. When Kubernetes is adopted as the orchestration software for managing the container-based cluster 100, the worker node 40 performs processing in units of pods, each of which is made up of one or more containers that run an application (for example, APL-A, which will be described later). Furthermore, one or more master nodes 30 that manage (configure, monitor status, etc.) each worker node 40 are arranged in the container management unit 110 (110a). Note that, for redundancy, multiple master nodes 30 (usually three in a commercial cluster) are provided, but the number is not limited to three as shown in Fig. 1 and may be one or more. Synchronization processing is performed for the multiple redundant master nodes 30 by orchestration software (e.g., Kubernetes).

[0013] The container-based cluster update system 1 of this embodiment is composed of a container-based cluster 100a before an update is executed (initial state), a load balancer 5 that distributes processing requests to applications, an update control device 10, and a container-based cluster 100b (see Figures 2 to 11) that is newly constructed under the control of the update control device 10. The container-based cluster update system 1 is characterized in that it uses a blue-green method for the container-based cluster 100a and updates applications using a rolling update method across the container-based clusters 100 (100a, 100b).

[0014] Specifically, the update control device 10 constructs a container management unit 110 (110b) in the new container-based cluster 100b, and then constructs a container compute unit 120 (120b) equipped with the minimum required number of worker nodes 40. Then, the load balancer 5 switches the communication path to the new container-based cluster 100b, thereby completing the update. The following provides a detailed description of the functions and processing of the container-based cluster update system 1. Note that the functions of the container-based cluster 100 and the load balancer 5 are conventional technologies, and therefore descriptions thereof will be omitted.

[0015] <Update control device> The update control device 10 performs control to update (upgrade) the container-based cluster 100a before the update (initial state) and transition to a new container-based cluster 100b after the update. The update control device 10 is connected for communication with each master node 30 and each worker node 40 in the container-based cluster 100 (100a, 100b) and the load balancer 5. The update control device 10 is realized by a computer including a control unit, an input / output unit, and a storage unit (all of which are not shown) (see FIG. 12, which will be described later for details).

[0016] The input / output unit inputs and outputs information between each master node 30 and each worker node 40 in the container-based cluster 100 (100a, 100b), the load balancer 5, and other external devices. This input / output unit includes a communication interface that transmits and receives information via a communication line. The storage unit stores information about the container-based cluster 100 (100a, 100b), such as information about each master node 30, each worker node 20, and containerized applications.

[0017] As shown 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 status acquisition unit 105.

[0018] The load balancer control unit 101 instructs the load balancer 5 to configure communication settings for the application set up on the worker node 40 of the newly constructed container-based cluster 100b, and also instructs the load balancer 5 to confirm that the communication path has been set up appropriately (see Figure 5). Furthermore, in the newly constructed container-based cluster 100b, when the application settings are normally performed, the load balancer control unit 101 deletes the communication settings between the application in the container-based cluster 100a (see FIG. 10).

[0019] The master node control unit 102 constructs a container management unit 110b of a newly constructed container-based cluster 100b (see FIG. 2). Specifically, the master node control unit 102 constructs one or more master nodes 30 as the container management unit 110b in the container-based cluster 100b. In addition, when the migration to the container-based cluster 100b is completed successfully, the master node control unit 102 deletes the container management unit 110a of the container-based cluster 100a, specifically, each of the master nodes 30 that had been constructed (see Figures 7 and 11).

[0020] The worker node control unit 103 constructs a container compute unit 120b in the new container-based cluster 100b (see FIG. 3). Specifically, the worker node control unit 103 constructs a minimum required number of worker nodes 40 as the container compute unit 120b in the container-based cluster 100b. The worker node control unit 103 constructs a number of worker nodes 40 that is sufficient to add one each of the applications (here, APL-A, APL-B, and APL-C) as the minimum required number of worker nodes 40. In other words, for an application (migration target application) that is to be sequentially migrated to the new container-based cluster 100b, selected from one or more applications installed in the multiple worker nodes of the container-based cluster 100a in the initial state, the worker node control unit 103 constructs in the new container-based cluster 100b the minimum number of worker nodes 40 required for the migration target application to execute processing. In this embodiment, it is assumed that two worker nodes 40 are required to operate three applications (APL-A, APL-B, and APL-C) as the selected migration target applications. The minimum required number of nodes may be set in advance according to the processing load of each application, and may be stored, for example, in a storage unit (not shown) of the update control device 10. Alternatively, the worker node control unit 103 may first add one node, and if the setting cannot be properly performed, add another node at a time and confirm that the setting can be properly performed.

[0021] In addition, when the settings for expanding each application are successfully performed in the new container-based cluster 100b, the worker node control unit 103 selects and deletes a worker node 40 in the container-based cluster 100a that does not have an application installed (see Figure 7). In addition, if there is no worker node 40 that does not have the application installed, the worker node control unit 103, under the control of the application management unit 104, moves the application to another worker node 40, thereby generating a worker node 40 that does not have the application installed, and then deletes that worker node 40. Here, when adopting Kubernetes as the orchestration software for managing the container infrastructure cluster 100, the application management unit 104 can move the application to other worker nodes 40 by instructing the master node 30, for example, using the "kubectl drain <NODE name>" command, which is a Pod eviction command from the server.

[0022] When worker nodes 40 are built on the newly built container infrastructure cluster 100b, the application management unit 104 sets the containerized application (the application to be migrated) on the worker node 40 (see FIGS. 4 and 9). In addition, when the setting of a new application is successfully completed in the container infrastructure cluster 100b, the application management unit 104 deletes the corresponding application (the application to be migrated) in the container infrastructure cluster 100a (see FIGS. 6 and 10).

[0023] The status acquisition unit 105 confirms that each process by 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 querying the master nodes 30 of the container infrastructure clusters 100a and 100b. If it is confirmed that the process has not been performed normally, the status acquisition unit 105 notifies the functional unit that performed the process to return to the state before the process and issues an instruction to execute the process again. When adopting Kubernetes as the orchestration software for managing the container infrastructure cluster 100, the status acquisition unit 105 can confirm the normality of each worker node 40 by instructing the master node 30, for example, using the "kubectl get nodes" command, which is a normality confirmation command for each worker node 40.

[0024] <Update Control Process> Next, an update control process for the container-based cluster 100 performed by the container-based cluster update system 1 according to this embodiment will be described with reference to FIGS. The container-based cluster 100 is assumed to be in an operational state (initial state) as shown in FIG. 1. As shown in FIG. 1, one or more master nodes 30 (three master nodes 30 in this case) are arranged in the container-based cluster 100a. Also, one or more applications (three applications, APL-A, APL-B, and APL-C in this case) are installed and operated on a plurality of worker nodes 40 (three worker nodes 40 in this case) as applications for implementing services. Also, each application is made redundant to maintain the availability of the service even in the operational state, and two applications each are operated on the container, such as APL-A-1, APL-A-2, APL-B-1, APL-B-2, APL-C-1, and APL-C-2.

[0025] Here, the 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, APL-C) as shown in the APL information 300a in Fig. 1. In other words, the version of each application is "1", and two copies (redundancy) of each application are running.

[0026] The following describes the update control process of the container-based cluster update system 1. This update control process starts when the update control device 10 receives an instruction to start updating the container-based cluster 100a from an external device (not shown) that manages the container-based cluster update system 1, for example.

[0027] [1st process] 2 is a diagram for explaining the first step of constructing a container management unit 110b of a new container-based cluster 100b. Note that the first step corresponds to a master node construction step recited in the claims. For example, when the update control device 10 receives an update start instruction, in [Step 1], the master node control unit 102 (FIG. 1) constructs a container management unit 110b of a newly constructed container-based cluster 100b. Specifically, the master node control unit 102 constructs three master nodes 30 as the container management unit 110b in the container-based cluster 100b, as shown in FIG. 2, similar to the container management unit 110a of the container-based cluster 100a.

[0028] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each master node 30 of the container management unit 110b of the container base cluster 100b has been constructed normally by inquiring of the master node 30 of the container management unit 110b. Then, the status acquisition unit 105 notifies the master node control unit 102 of the confirmation result. Here, if the master node control unit 102 receives a notice that the construction has not been normal, it returns the process to just before [Step 1] and executes [Step 1] again.

[0029] [Second process] 3 is a diagram for explaining the second step of constructing a container compute unit 120b of a new container-based cluster 100b. The second step corresponds to a worker node construction step in the claims. In [Step 2], the worker node control unit 103 (FIG. 1) of the update control device 10 constructs a container compute unit 120b of the container-based cluster 100b as shown 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 selected from one or more applications installed in the multiple worker nodes 40 of the container-based cluster 100a in the initial state to execute processing for the migration target application. In this embodiment, as described above, two worker nodes 40 are required as a minimum to run three applications (APL-A, APL-B, and APL-C). Therefore, the worker node control unit 103 constructs two worker nodes 40 (here, Worker “1” and “2”).

[0030] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each worker node 40 (here, two Workers "1" and "2") of the container compute unit 120b of the container base cluster 100b has been constructed normally by inquiring of the master node 30 of the container management unit 110b. Then, the status acquisition unit 105 notifies the worker node control unit 103 of the confirmation result. Here, if the worker node control unit 103 receives a notification that the construction has not been successful, it returns the processing to just before [Step 2] and executes [Step 2] again.

[0031] [3rd step] 4 is a diagram for explaining the third step of constructing an application in the container compute unit 120b of the new container-based cluster 100b. The third step corresponds to the application installation step described in the claims. In the third step, the application management unit 104 (Figure 1) of the update control device 10 builds the applications (APL-A, APL-B, APL-C) to be migrated in the container compute unit 120b of the container-based cluster 100b, as shown in Figure 4. Here, APL-A-1, APL-B-1, and APL-C-1 are constructed under the control of the application management unit 104. This application shows an example of an upgraded version compared to the application in the container-based cluster 100a in the initial state, as indicated by version "2" in the APL information 300b in Fig. 4. In this embodiment, an example will be described in which the container-based cluster 100 itself and the application are updated at the same time. However, it is also possible to update only the container-based cluster 100 without upgrading the application.

[0032] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each application (APL-A-1, APL-B-1, APL-C-1) has been normally constructed in the container compute unit 120b of the container base cluster 100b by inquiring of the master node 30 of the container management unit 110b. Then, the status acquisition unit 105 notifies the application management unit 104 of the confirmation result. Here, if the application management unit 104 receives a notice that the application has not been normally constructed, it returns the process to just before [Step 3] and executes [Step 3] again.

[0033] [4th step] 5 is a diagram for explaining the fourth step of setting up communication for an application built in the container compute unit 120b of the new container infrastructure cluster 100b. The fourth step corresponds to the communication connection step described in the claims. In the fourth step, the load balancer control unit 101 (FIG. 1) and the application management unit 104 (FIG. 1) of the update control device 10 set up a communication path so as to enable communication between the load balancer 5 and each application (APL-A-1, APL-B-1, APL-C-1) constructed in the container-based cluster 100b, as shown in FIG. 5.

[0034] After the communication paths are set, the status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether the communication paths for each application (APL-A-1, APL-B-1, APL-C-1) have been successfully established by inquiring of the master node 30 of the container management unit 110b. The status acquisition unit 105 also checks the status of the load balancer 5, and confirms that communication settings with each application (APL-A-1, APL-B-1, APL-C-1) of the container-based cluster 100b have been successfully performed. Then, the status acquisition unit 105 notifies the result of the confirmation to the application management unit 104 and the load balancer control unit 101. Here, when the application management unit 104 and the load balancer control unit 101 receive a notification that the setting has not been properly performed, they return the process to just before [Step 4] and execute [Step 4] again.

[0035] [5th ​​step] 6 is a diagram for explaining the fifth step of reducing the number of replicas of the applications (APL-A, APL-B, and APL-C) 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. In the fifth step, the application management unit 104 (FIG. 1) of the update control device 10 reduces the number of replicas of the applications (APL-A, APL-B, APL-C) that are the migration target applications of the container compute unit 120a of the container-based cluster 100a. Here, as shown in FIG. 6, the application management unit 104 reduces each application (APL-A-1, APL-B-1, APL-C-1). As a result, as shown in FIG. 6, the number of replicas of each application becomes "1" in the APL information 300a of the container-based cluster 100a in the initial state.

[0036] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each application (APL-A-1, APL-B-1, APL-C-1) has been normally deleted by inquiring of the master node 30 of the container management unit 110a. Then, the status acquisition unit 105 notifies the application management unit 104 of the confirmation result. Here, if the application management unit 104 receives a notification that the deletion has not been successful, it returns the process to just before [Step 5] and executes [Step 5] again.

[0037] [6th step] 7 is a diagram for explaining the sixth step of reducing the number of worker nodes 40 included in the container compute unit 120a of the container-based cluster 100a in the initial state. The sixth step corresponds to a worker node deleting step as claimed in the claims. In the sixth step, 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 that does not have an application installed, as shown in FIG 7. In FIG 7, the deleted worker node 40 (Worker "1") is indicated by a dashed line. If there is no worker node 40 on which an application is not installed, the worker node control unit 103 notifies the application management unit 104 of that fact. Then, under the control of the application management unit 104, any application is moved to another worker node 40, thereby generating a worker node 40 on which an application is not installed. Then, the worker node control unit 103 deletes that worker node 40.

[0038] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether the worker node 40 (Worker "1") on which no application is installed has been successfully deleted by inquiring of the master node 30 of the container management unit 110a. Then, the status acquisition unit 105 notifies the worker node control unit 103 of the confirmation result. Here, if the worker node control unit 103 receives a notification that the deletion has not been successful, it returns the process to just before [Step 6] and executes [Step 6] again.

[0039] [7th step] 8 is a diagram for explaining the seventh step of adding a worker node 40 to the container compute unit 120b of the new container base cluster 100b. The seventh step corresponds to the worker node adding step described in the claims. In [Step 7], the worker node control unit 103 (FIG. 1) of the update control device 10 adds new worker nodes 40 in the container compute unit 120b of the container-based cluster 100b, as shown in FIG. 8. The number of these new worker nodes 40 to be added is the same as the number of nodes deleted in [Step 6]. FIG. 8 shows an example in which one worker node 40 (Worker "3") is constructed by the worker node control unit 103.

[0040] The status acquisition unit 105 (Figure 1) of the update control device 10 checks whether a worker node 40 (here, one Worker "3") has been successfully constructed in the container compute unit 120b of the container-based cluster 100b by inquiring of the master node 30 of the container management unit 110b. Then, the status acquisition unit 105 notifies the worker node control unit 103 of the confirmation result. If the worker node control unit 103 receives a notification that the construction has not been successful, the process returns to the point immediately before [Step 7] and executes [Step 7] again.

[0041] [8th process] FIG. 9 is a diagram for explaining the eighth step of adding an application to the container compute unit 120b of the new container base cluster 100b. In [Step 8], the application management unit 104 (Figure 1) of the update control device 10 adds applications (APL-A, APL-B, APL-C) as the next selected applications to be migrated to the container compute unit 120b of the container-based cluster 100b, as shown in Figure 9. Here, APL-A-2, APL-B-2, and APL-C-2 are added under the control of application management unit 104. With this addition of applications, the number of replicas of each application (APL-A, APL-B, and APL-C) of version "2" becomes "2", as shown in APL information 300b in FIG.

[0042] The status acquisition unit 105 (FIG. 1) of the update control device 10 checks whether each application (APL-A-2, APL-B-2, APL-C-2) has been successfully added to the container compute unit 120b of the container base cluster 100b by inquiring of the master node 30 of the container management unit 110b. Then, the status acquisition unit 105 notifies the application management unit 104 of the confirmation result. Here, if the application management unit 104 receives a notice that the application has not been successfully constructed, it returns the process to just before [Step 8] and executes [Step 8] again.

[0043] [9th step] FIG. 10 is a diagram for explaining the 9th step of deleting applications (APL-A, APL-B, APL-C) and communication paths provided in the container compute unit 120a of the container base cluster 100a in the initial state. In [Step 9], the load balancer control unit 101 (FIG. 1) of the update control device 10 deletes the communication paths between the load balancer 5 and each application (APL-A-2, APL-B-2, APL-C-2) of the container-based cluster 100a, as shown in FIG. 10. Then, the application management unit 104 deletes each application (APL-A-2, APL-B-2, APL-C-2) of the container-based cluster 100a.

[0044] After the communication paths and each application (APL-A-2, APL-B-2, APL-C-2) are deleted, the status acquisition unit 105 (FIG. 1) of the update control device 10 checks the status of the load balancer 5 and confirms that the communication paths to each application (APL-A-2, APL-B-2, APL-C-2) of the container-based cluster 100a have been successfully deleted. The status acquisition unit 105 also checks whether each application (APL-A-2, APL-B-2, APL-C-2) has been successfully deleted by inquiring of the master node 30 of the container management unit 110a. Then, the status acquisition unit 105 notifies the result of the confirmation to the application management unit 104 and the load balancer control unit 101. Here, when the application management unit 104 and the load balancer control unit 101 receive a notification that the communication paths and the applications (APL-A-2, APL-B-2, APL-C-2) have not been successfully deleted, they return the process to just before [Step 9] and execute [Step 9] again.

[0045] [10th process] FIG. 11 is a diagram for explaining the tenth step of deleting the container compute unit 120a and the container management unit 110a in the container base cluster 100a in the initial state. In [Step 10], the worker node control unit 103 (FIG. 1) of the update control device 10 deletes each worker node 40 (Worker "2" and "3" in this case) of the container compute unit 120a of the container-based cluster 100a as shown in FIG. 11. Then, the master node control unit 102 (FIG. 1) deletes each master node 30 of the container management unit 110a.

[0046] Thus, according to the container-based cluster update system 1 according to this embodiment, a total of six worker nodes 40 are required to execute an update in the conventional blue-green method, but the update can be performed with five worker nodes 40. Therefore, the number of servers required for an update can be reduced compared to the blue-green method. Furthermore, according to the container-based cluster update system 1 of this embodiment, if any step in the update cannot be normally executed, the update control device 10 controls the system to return to the previous step. This makes it possible to reliably execute the update of the container-based cluster 100.

[0047] The present invention is not limited to the above-described embodiment, and many modifications can be made by those having ordinary skill in the art within the technical scope of the present invention. In this embodiment, the applications (APL-A, APL-B, APL-C) installed in the container-based cluster 100a in the initial state are treated as one set, and first, APL-A-1, APL-B-1, and APL-C-1 (applications to be migrated) are added to a new container-based cluster 100b or deleted from the container-based cluster 100a in the initial state, and then APL-A-2, APL-B-2, and APL-C-2 (next application to be migrated) are added or deleted, thereby realizing an update. However, the process is not limited to the process using each application set, and the process of addition and deletion may be performed in the order of APL-A, APL-B, and APL-C, for example, APL-A-1, APL-B-1, APL-C-1, APL-A-2, APL-B-2, and APL-C-2, which are applications to be migrated one by one. In this case, for example, when APL-C-1 is moved to a new container-based cluster 100b, a process is required to move APL-A-2, which is another application on the original worker node 40 on which APL-C-1 was installed, to another worker node 40, and generate a worker node 40 on which no application is installed. However, if applications are processed one by one, the minimum number of servers required can be reduced to one. Therefore, the number of servers required for updates can be further reduced.

[0048] <Hardware configuration of update control device> The update control device 10 according to this embodiment is realized by a computer 900 having a configuration as shown in FIG. 12 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the update control device 10 according to this embodiment. The computer 900 has a CPU (Central Processing Unit) 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.

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

[0050] 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 an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0051] The HDD 904 stores programs executed by the CPU 901 and data used by the programs, etc. The communication I / F 906 receives data from other devices via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0052] The media I / F 907 reads a program (update control program) or data stored in the recording medium 912, and outputs it 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 DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a semiconductor memory, or the like.

[0053] For example, when the computer 900 functions as the update control device 10 of the present invention, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize each function of the update control device 10. Furthermore, the HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program relating to a target process from a recording medium 912. Additionally, the CPU 901 may read a program relating to a target process from another device via a communication network (NW 920).

[0054] <Effects> The effects of the update control method for a container-based cluster according to the present invention will be described below. The container-based cluster update control method according to the present invention is an update control method for a container-based cluster by a container-based cluster update system 1 including a container-based cluster 100, an update control device 10 that controls updates to the container-based cluster 100, and a load balancer 5, the container-based cluster 100 being configured with a plurality of worker nodes 40 that execute application processing using virtualized containers, and a master node 30 that manages the worker nodes 40, one or more applications are made redundant on the plurality of worker nodes 40, and the redundant applications are respectively installed on different worker nodes 40, and the update control device 10 includes a master node construction step of constructing a new master node 30 in a new container-based cluster 100b that is different from the container-based cluster 100a in an initial state before the update, and a process of sequentially transferring one or more applications installed on the plurality of worker nodes 40 of the container-based cluster 100a in the initial state to the new container-based cluster 100b. For a migration target application indicating an application to be migrated, the migration target application is configured to execute a process by executing a worker node construction step of constructing in a new container-based cluster 100b a minimum number of worker nodes 40 required for the migration target application to execute processing, an application installation step of installing the migration target application on the minimum number of worker nodes 40 thus constructed, a communication connection step of connecting the worker nodes 40 installed with the migration target application to a load balancer 5, an application deletion step of deleting the migration target application in the container-based cluster 100a in the initial state, a worker node deletion step of deleting in the container-based cluster 100a in the initial state the worker nodes 40 which no longer have an application installed due to the deletion of the migration target application, and a worker node addition step of adding to the new container-based cluster 100b the number of worker nodes 40 deleted in the container-based cluster 100a in the initial state, andThe application to be migrated is loaded onto the worker node 40 constructed in the new container-based cluster 100b, and the application to be migrated from the initial-state container-based cluster 100a and the worker node 40 on which the application is not loaded are repeatedly deleted to migrate all applications, the master node 30 of the initial-state container-based cluster 100a is deleted, and the initial-state container-based cluster 100a is updated to the new container-based cluster 100b, and at each step, the master node 30 of the initial-state container-based cluster 100a or the new container-based cluster 100b is inquired to confirm whether each step has been executed normally, and if there is a step that has not been executed normally, the process is returned to the step immediately before that step and that step is executed again.

[0055] In this way, according to the update control method for the container-based cluster 100 of the present invention, it is possible to perform an update with fewer worker nodes than the conventional blue-green method, which requires twice the number of worker nodes 40 to perform an update. Furthermore, if any step in the update cannot be normally executed, it is possible to return to the previous step by the control of the update control device 10. Therefore, it is possible to reliably execute the update of the container-based cluster 100.

[0056] In addition, in the worker node deletion process, if there is no worker node on which an application is no longer installed, the update control device 10 moves the application installed on any worker node to another worker node, thereby generating a worker node on which the application is no longer installed.

[0057] In this way, even if there is no worker node 40 on which the application is no longer installed in the worker node deletion step ([sixth step]), the update control device 10 can generate a worker node 40 on which the application is not installed by moving the application to another worker node 40. This makes it possible to reliably execute the update of the container-based cluster 100. [Explanation of symbols]

[0058] 1. Container-based cluster update system 5. Load Balancer 10 Update control device 30 Masternodes 40 worker nodes 100,100a,100b Container-based cluster 101 Load balancer control section 102 Master Node Control Unit 103 Worker node control section 104 Application Management Department 105 Status acquisition unit 110, 110a, 110b Container Management Department 120, 120a, 120b Container Compute Section 300,300a,300b APL information

Claims

1. 1. A method for controlling an update of a container-based cluster by a container-based cluster update system including a container-based cluster, an update control device that controls an update of the container-based cluster, and a load balancer, comprising: The container-based cluster includes a plurality of worker nodes that execute application processing using virtualized containers, and a master node that manages the worker nodes, and one or more of the applications are redundantly installed on the plurality of worker nodes, and the redundant applications are installed on different worker nodes, The update control device includes: A masternode construction process to build a new masternode in a new container-based cluster separate from the initial container-based cluster before the update; a worker node construction process for constructing, in the new container-based cluster, a minimum number of worker nodes required for a migration target application to execute processing, the migration target application being selected from one or more of the applications installed on the multiple worker nodes of the container-based cluster in the initial state, and indicating an application to be sequentially migrated to the new container-based cluster; an application installation process of installing the application to be migrated on the minimum required number of worker nodes that have been constructed; A communication connection step of communicating between a worker node having the application to be migrated and the load balancer; an application deletion step of deleting the application to be migrated from the container-based cluster in the initial state; a worker node deleting step of deleting a worker node in the container-based cluster in the initial state, the worker node being depleted of the application to be migrated due to the deletion of the application; a worker node addition step of adding worker nodes to the new container-based cluster by the number of worker nodes that were deleted from the container-based cluster in the initial state; In the container-based cluster in the initial state, the application to be migrated is sequentially selected, and the application to be migrated is loaded onto a worker node constructed in the new container-based cluster; the application to be migrated is repeatedly deleted from the container-based cluster in the initial state and the worker node on which the application is not loaded is deleted, thereby migrating all applications; the master node of the container-based cluster in the initial state is deleted, and the container-based cluster in the initial state is updated to the new container-based cluster; In each of the steps, by inquiring of the master node of the initial state container-based cluster or the new container-based cluster, it is confirmed whether or not each of the steps has been executed normally, and if any step has not been executed normally, the process is returned to the step immediately before the step and the step is executed again. The update control method for a container-based cluster is characterized by the above.

2. When there is no worker node on which the application is no longer installed, the update control device moves the application installed on any worker node to another worker node in the worker node deletion step, and generates a worker node on which the application is no longer installed. The update control method for a container-based cluster according to claim 1 .

3. A container-based cluster update system including a container-based cluster, an update control device that controls an update of the container-based cluster, and a load balancer, The container-based cluster includes a plurality of worker nodes that execute application processing using virtualized containers, and a master node that manages the worker nodes, and one or more of the applications are redundantly installed on the plurality of worker nodes, and the redundant applications are installed on different worker nodes, The update control device includes: A master node control unit that builds a new master node in a new container-based cluster that is different from the initial container-based cluster before the update; a worker node control unit that constructs, in the new container-based cluster, a minimum number of worker nodes required for a migration target application to execute processing, the migration target application being selected from one or more of the applications installed on the multiple worker nodes of the container-based cluster in the initial state, and that deletes, from the container-based cluster in the initial state, worker nodes on which the migration target application is no longer installed due to the deletion of the migration target application, and adds, to the new container-based cluster, the number of worker nodes that were deleted; an application management unit that installs the application to be migrated on the minimum required number of worker nodes that have been constructed, and deletes the application to be migrated in the container-based cluster in the initial state; A load balancer control unit that connects the worker node equipped with the application to be migrated and the load balancer in communication with each other; a status acquisition unit that performs normality check of each process related to the update by inquiring to the master node of the container-based cluster in the initial state or the new container-based cluster, In the container-based cluster in the initial state, the application to be migrated is selected in sequence, and an application management unit loads the application to be migrated onto a worker node of the new container-based cluster constructed by the worker node control unit; the application management unit deletes the application to be migrated from the container-based cluster in the initial state, and the worker node control unit deletes a worker node on which the application is not loaded, thereby migrating all applications; the master node control unit deletes the master node of the container-based cluster in the initial state, and updates the container-based cluster in the initial state to the new container-based cluster; When the state acquisition unit finds a process whose normality cannot be confirmed as a result of the normality check, the state acquisition unit returns to a state immediately before the process and executes the process again. A container-based cluster update system that features:

4. An update control device that controls an update of a container-based cluster, The container-based cluster includes a plurality of worker nodes that execute application processing using virtualized containers, and a master node that manages the worker nodes, and one or more of the applications are redundantly installed on the plurality of worker nodes, and the redundant applications are installed on different worker nodes, The update control device includes: A master node control unit that builds a new master node in a new container-based cluster that is different from the initial container-based cluster before the update; a worker node control unit that constructs, in the new container-based cluster, a minimum number of worker nodes required for a migration target application to execute processing, the migration target application being selected from one or more of the applications installed on the multiple worker nodes of the container-based cluster in the initial state, and that deletes, from the container-based cluster in the initial state, worker nodes on which the migration target application is no longer installed due to the deletion of the migration target application, and adds, to the new container-based cluster, the number of worker nodes that were deleted; an application management unit that installs the application to be migrated on the minimum required number of worker nodes that have been constructed, and deletes the application to be migrated in the container-based cluster in the initial state; A load balancer control unit that connects a worker node having the application to be migrated and a load balancer that distributes processing requests to each of the applications, a status acquisition unit that performs normality check of each process related to the update by inquiring to the master node of the container-based cluster in the initial state or the new container-based cluster, In the container-based cluster in the initial state, the application to be migrated is selected in sequence, and an application management unit loads the application to be migrated onto a worker node of the new container-based cluster constructed by the worker node control unit; the application management unit deletes the application to be migrated from the container-based cluster in the initial state, and the worker node control unit deletes a worker node on which the application is not loaded, thereby migrating all applications; the master node control unit deletes the master node of the container-based cluster in the initial state, and updates the container-based cluster in the initial state to the new container-based cluster; When the state acquisition unit finds a process whose normality cannot be confirmed as a result of the normality check, the state acquisition unit returns to a state immediately before the process and executes the process again. An update control device comprising:

5. An update control program for causing a computer to function as the update control device according to claim 4.

Images