KR20240085328A - Failure node eliminator and control method thereof - Google Patents

Abstract

The present invention relates to a failed node removal device that can handle the node failure in the cluster itself without user intervention when a compute node failure occurs. More specifically, the present invention monitors the current state of at least one node, stores a node CR (Custom Resource), which is the ideal state (desire status) of the node, and based on the monitoring result and the node CR, the at least one node It relates to a technology for identifying a faulty node among nodes and performing processing on the identified faulty node.

Description

FAILURE NODE ELIMINATOR AND CONTROL METHOD THEREOF}

The present invention relates to hypervisor resource operation of an IaaS service provided by a cloud service provider using a controller pattern used in a container orchestration service. More specifically, when a compute node failure occurs, the cluster itself operates the node without user intervention. It's about technology that can handle obstacles.

In terms of managing cloud infrastructure, IT resources (computing/networking/storage) can be virtualized and managed efficiently. For example, computing resources mainly use virtualization using virtual machines (VMs).

OpenStack is an open source that allows companies to build cloud services internally for private purposes in order to provide IaaS services.

Recently, as most applications have transitioned from a monolithic architecture to a microservices architecture, using agile containers instead of virtual machines has become a trend.

Containerization refers to a virtualization method based on operating system-level virtualization. Containers are characterized as lightweight, portable execution elements for applications that are isolated from each other or from the host.

In line with this trend, cloud-native computing is emerging, which microservices all service elements under container orchestration and manages them as containers.

Accordingly, research to build cloud services based on cloud-native computing is required.

The problem that the present invention aims to solve is to provide a node removal device that can declaratively manage the status of resources by utilizing the controller pattern in managing IT resources of cloud services such as OpenStack open source. will be.

Another problem to be solved by the present invention is to provide a node removal device that can effectively manage and eliminate node failures while minimizing administrator involvement.

Another problem that the present invention aims to solve is to provide a system that can utilize cloud services on a container orchestration platform.

Another problem that the present invention aims to solve is to provide a system that stably transfers customer resources to a normal node with minimal downtime.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

According to one aspect of the present invention to solve the above or other problems, there is provided a monitoring unit that monitors the current state of at least one node; A node CR storage unit that stores a node CR (Custom Resource), which is the ideal status (desire status) of the node; and a node removal controller that identifies a failed node among the at least one node based on the monitoring result and the node CR, and performs processing on the identified failed node.

The faulty node may be a node whose monitored current state is different from the stored ideal state.

The node removal controller may perform processing on the identified failed node in a declarative manner.

The node removal controller may perform reconciliation and remove the identified faulty node.

It may further include an access permission storage unit that stores access permission information for accessing the at least one node.

The monitoring unit may obtain a client for the at least one node using the stored access authority information.

It may further include an AZ (Availability Zone) cluster controller that defines a node CR for the at least one node.

The node CR stored in the node CR storage unit may be a node CR defined by the AZ cluster controller.

It may further include a label input unit that receives a label change input from a user, and the monitoring unit may identify a node whose label has been changed as a faulty node based on the label change input.

According to another aspect of the present invention to solve the above or other problems, a monitoring unit monitors the current state of at least one node; A node CR storage unit storing a node CR (Custom Resource), which is the ideal state (desire status) of the node; and a node removal controller identifying a faulty node among the at least one node as a result of the monitoring, and performing processing on the identified faulty node.

The faulty node may be a node whose monitored current state is different from the stored ideal state.

The node removal controller may perform processing on the identified failed node in a declarative manner.

The step of performing the processing may be to perform reconciliation and remove the identified faulty node.

The access authority storage unit may further include storing access authority information for accessing the at least one node.

In the monitoring step, a client for the at least one node may be obtained using the stored access authority information.

The AZ cluster controller may further include defining a node CR for the at least one node.

The node CR stored in the node CR storage unit may be a node CR defined by the AZ cluster controller.

The label input unit may further include receiving a label change input from the user, and the monitoring step may identify a node whose label has been changed as a faulty node based on the label change input.

The effects of the faulty node removal device and its control method according to the present invention will be described as follows.

According to at least one of the embodiments of the present invention, in performing management of IT resources of cloud services such as OpenStack open source, a node removal device that can declaratively manage the status of resources using a controller pattern is provided. There is an advantage to being able to do this.

In addition, according to at least one of the embodiments of the present invention, there is an advantage of providing a node removal device that can effectively manage and eliminate node failures while minimizing administrator involvement.

Additionally, according to at least one of the embodiments of the present invention, there is an advantage of providing a system that a cloud service provider can utilize on a container orchestration platform.

In addition, according to at least one of the embodiments of the present invention, when a failure occurs in the hypervisor that constitutes the IaaS service provided by the cloud service provider, it is quickly detected and the customer's resources are stably transferred to a normal node with minimal downtime. It has the advantage of being able to increase the service level aggregation (SLA) of the service.

Further scope of applicability of the invention will become apparent from the detailed description that follows. However, since various changes and modifications within the spirit and scope of the present invention may be clearly understood by those skilled in the art, the detailed description and specific embodiments such as preferred embodiments of the present invention should be understood as being given only as examples.

FIG. 1 is a block diagram of an apparatus 100 for removing a faulty node according to an embodiment of the present invention.
Figure 2 is a block diagram of a failed node removal pod 116 according to an embodiment of the present invention.
Figure 3 is a diagram showing a node removal procedure using OpenStack open source according to an embodiment of the present invention.
FIG. 4 is a diagram illustrating a control flowchart defining CR of the AZ cluster controller 202 according to an embodiment of the present invention.
FIG. 5 is a diagram illustrating a node removal flowchart of the node removal pod 116 according to an embodiment of the present invention.
FIG. 6 is a conceptual diagram showing how the node removal pod 116 removes a node according to an embodiment of the present invention.
FIG. 7 is a diagram illustrating the configuration of a faulty node removal device 100 according to an embodiment.

Hereinafter, embodiments disclosed in the present specification will be described in detail with reference to the attached drawings. However, identical or similar components will be assigned the same reference numbers regardless of reference numerals, and duplicate descriptions thereof will be omitted. The suffixes “module” and “part” for components used in the following description are given or used interchangeably only for the ease of preparing the specification, and do not have distinct meanings or roles in themselves.

Additionally, in describing the embodiments disclosed in this specification, if it is determined that detailed descriptions of related known technologies may obscure the gist of the embodiments disclosed in this specification, the detailed descriptions will be omitted. In addition, the attached drawings are only for easy understanding of the embodiments disclosed in this specification, and the technical idea disclosed in this specification is not limited by the attached drawings, and all changes included in the spirit and technical scope of the present invention are not limited. , should be understood to include equivalents or substitutes.

Terms containing ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The above terms are used only for the purpose of distinguishing one component from another.

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between.

Singular expressions include plural expressions unless the context clearly dictates otherwise.

In this application, terms such as “comprise” or “have” are intended to designate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

To pursue simple and cost-effective operation in a complex IT environment, the Kubernetes (k8s) platform, which declaratively manages services, is a representative example of a container orchestration service.

In container orchestration architecture, a cluster refers to a set of nodes in a physical/virtual environment that hosts container-type applications. That is, in a data center environment based on container orchestration, resources configured in the host environment are abstracted and managed on a cluster basis. Within one cluster, there is a master node that acts as a control plane to control internal elements of the cluster, and the administrator follows the configuration of controlling the entire cluster through this master node.

Below, the case of Kubernetes is cited as a representative example of a container orchestration platform, but it is not necessarily limited thereto, and various types of container orchestration platforms may be applied to the present invention.

In addition, hereinafter, widely used terms used in Kubernetes will be used, but the use of these terms will not limit the present invention to a container orchestration platform called Kubernetes.

Containerization refers to a virtualization method based on operating system-level virtualization. Containers are characterized as lightweight, portable execution elements for applications that are isolated from each other or from the host.

Because containers are not tightly coupled to the host hardware computing environment, applications can be attached to a container image and run as a single lightweight package on any host or virtual host that supports the native container architecture. Because of these characteristics, containers can solve many problems that can arise when running software in different computing environments.

And since containers are an environment in which the operating system is virtualized, they are relatively lighter than virtual machines, so they can support more container instances than existing virtual machines under the same environment or conditions, and can be created and deleted quickly.

A hypervisor, also known as a virtual machine monitor, is a process that creates and runs a virtual machine (VM). A hypervisor virtually shares the resources of a single host computer, such as memory and processing, allowing the host computer to support multiple guest virtual machines.

Containers, which often have short lifetimes, can be created and moved more efficiently than virtual machines. And it is possible to manage containers as groups of logically related elements. For example, in some orchestration platforms, such as Kubernetes, these elements are called “Pods,” and the group of nodes providing these Pods is called a “Cluster.”

Hereinafter, the terms pod and cluster will be used in the present invention, but these are only terms to refer to elements and their groups, and the present invention will not be limited to the Kubernetes platform.

In container orchestration architecture, a cluster refers to a set of nodes in a physical/virtual environment that hosts container-type applications. That is, in a data center environment based on container orchestration, resources configured in the host environment are abstracted and managed on a cluster basis.

Within one cluster, there is a master node that acts as a control plane to control internal elements of the cluster, and the administrator follows the configuration of controlling the entire cluster through this master node. The control plane role refers to distributing and controlling major components such as workload resources across the cluster.

Below, OpenStack is described as a representative example as a service for providing cloud services, but the present invention is not limited to OpenStack.

When the nodes for configuring a cloud service are divided based on their roles, they can include three types: controller node, compute node, and network node, as shown below.

Controller node: Services to manage the entire cloud service are installed. RESTful API server including authentication service (e.g. keystone in OpenStack), image service (e.g. glance in OpenStack), and compute service (e.g. nova in OpenStack) management service. is installed.

Compute node: A node used to run an instance of a compute service (Nova-based). These compute nodes are divided into AZ (Availability Zones) and managed by a hypervisor for HA (High Availability).

Dynamic Host Configuration Protocol (DHCP) node: Automatically hosts IP addresses and provides other relevant configuration information such as subnet mask and default gateway.

The present invention described below proposes using a declarative method rather than a procedural method when expanding IT resources or managing the state of resources based on a container orchestration system.

IT resources are components used to provide IT services and solutions, such as hardware, software, and networking, and are of very diverse types.

By unifying various IT resources such as PM (Physical Machine), VM (Virtual Machine), DB (Database), network, k8s (Kubernetes), IaaS (Infrastructure as a service), and PaaS (Platform as a service) in the same way, If you can manage it, convenience will increase significantly.

The declarative method according to an embodiment of the present invention defines the desired state (hereinafter referred to as the ideal state in the present invention, desire state) of the target IT resource, and repeats the process so that the current state of the IT resource becomes the same as the desired state. It refers to a method of performing a task (loop process).

The declarative method can be performed through the internal controller pattern provided in Kubernetes open source. In this Kubernetes open source, an event is generated every time the state of a resource changes, and an attempt is made to compare it to the state (ideal state) of the requested IT resource and repeat the task until it becomes the same as the ideal state. This repetitive task is called reconciliation.

In one embodiment of the present invention, a configuration that extends IT resources using a controller pattern and declaratively manages the state of the IT resources is called an operator.

Customizing and defining IT resources subject to management is called “CR (Custom Resource) definition,” and the ideal state defined in this way is called CR. This is explained in more detail below.

FIG. 1 is a block diagram of an apparatus 100 for removing a faulty node according to an embodiment of the present invention.

The failed node removal device 100 includes AZ Cluster (Available Zone Cluster, 111), Controller Cluster (112), Undercloud Cluster (113), Shared Cluster (114), and Ring 0 Cluster. It may be configured to include (Ring 0 Cluster, 115).

The components shown in FIG. 1 are not essential for implementing the device 100 for removing a faulty node, so the device 100 for removing a faulty node described herein has more or fewer components than the components listed above. It can have elements.

AZ Cluster (Available Zone Cluster, 111) is also called a compute cluster, and in the case of OpenStack services, it is mapped to an availability zone. A plurality of AZ clusters 111 may be mapped per controller cluster 112 described below. In the case of OpenStack service, the AZ cluster 111 runs Nova-based VMs through the OpenStack hypervisor.

The AZ cluster 111 can be divided into first to third cells (110-1 to 110-3) by region, and each cell (110-1 to 110-3) has at least one node. It can be.

The controller cluster (112) provides services for managing cloud services. For example, in the case of open source services, an API server to manage the authentication service (keystone), image service (glance), and compute service (nova) are installed and run.

Undercloud Cluster (113) manages metadata (network, subnet, port, etc.) of the undercloud network. The undercloud cluster 113 according to an embodiment of the present invention is proposed to be equipped with a node elimination pod (116).

The node removal pod 116 is a pod for monitoring at least one node included in the AZ cluster 111 and removing the failed node when a failed node occurs.

The internal configuration of the node removal pod 116 will be described in more detail below with reference to the drawings.

Shared Cluster (114) is a cluster that manages common resources for each region.

Ring 0 Cluster (115) is a cluster that provisions other clusters (111, 112, 113, and 114). Manages resources and overall metadata that exist in IDC, such as undercloud and overcloud clusters. Ring 0 cluster 115 stores access authority information (AZ node kubeconfig) for at least one node included in AZ cluster 111. In other words, because the Ring 0 cluster 115 has provisioned the AZ cluster 111, access authority information for it is also stored.

Hereinafter, with reference to FIG. 2, the specific configuration of the node removal pod 116 will be described.

Figure 2 is a block diagram of a failed node removal pod 116 according to an embodiment of the present invention.

The node removal pod 116 includes a node removal controller 201, an AZ cluster controller 202, a node CR storage unit 203, a cluster CR storage unit 204, an access authority information storage unit 205, and a monitoring unit ( 206).

The components shown in FIG. 2 are not essential for implementing the node removal pod 116, so the node removal pod 116 described herein may include more or less components than those listed above. You can have it.

The AZ cluster controller 202 collects information about the cluster(s) to be managed, and defines an ideal state (desire state) for the cluster(s) to be managed based on the collected information. An ideal state may mean a desirable state in which a specific object (cluster, node, etc.) can operate normally, and if it deviates from the ideal state, the specific object may be judged to be a failure.

The ideal state defined in this way is called a Custom Resource (CR), and CR can be divided into a cluster CR for at least one cluster and a node CR for at least one node.

That is, the AZ cluster controller 202 is a controller defined by the Custom Resource Definition (CRD) of the AZ cluster and is responsible for creating and managing CR.

Cluster CRD defines the unique information and desired state information of the AZ cluster 111 as a cluster specification, and information representing the current state of the AZ cluster 111 and information used in reconciliation are defined as state information ( means defined as status information.

The cluster specification may include at least one of ring 0 cluster 115 access information, AZ cluster 111 access information, and control plane (ControlPlane) unique information.

Cluster status information may include at least one of the Cluster Ready status, the total number of hypervisors, and deleted hypervisor information.

Cluster CR is information that defines the ideal state that a specific cluster should have, and can be configured to contain the actual information of each cluster through the CRD predefined above.

A cluster CR may be provided to correspond to each of at least one cluster. That is, N cluster CRs can be defined for N clusters.

Node CR is information that defines the ideal state that a specific node should have, and may be provided to correspond to each of at least one node. That is, N node CRs can be defined for N nodes.

The readjustment operation according to an embodiment of the present invention can be performed in these CR units.

The node removal controller 201 is configured to remove a failed node from among the nodes included in the AZ cluster 111.

The node removal controller 201 according to an embodiment of the present invention applies the Kubernetes controller pattern to an Openstack hypervisor cluster.

The node removal controller 201 according to an embodiment of the present invention proposes to define the node subject to management as a CR (Custom Resource). And when a failure occurs in the relevant resource and needs to be removed (desired state set by the user: nodeHealthy → actual state: nodeError), the operator is used to remove resources (VM, IP, storage and network, etc.) to another normal node in the cluster. And the node removal controller 201 can automatically remove the failed node after migration is completed.

In other words, the node removal controller 201 detects a node failure using the controller pattern and the contents defined in the CR, transfers the virtualization resources (VM, IP, STORAGE, etc.) using the node to another node in the cluster, and , Plays the role of removing nodes.

The node removal controller 201 according to an embodiment of the present invention has the advantage of being able to increase SLA (Service-Level Agreement) by minimizing downtime when transferring virtual resources.

In general, when using OpenStack open source, a procedural method is used to remove nodes.

Referring to the flow chart in FIG. 3, this procedural method will be described in more detail.

Figure 3 is a diagram showing a node removal procedure using OpenStack open source according to an embodiment of the present invention.

Unlike the declarative method described above, this procedural method is performed by the user (administrator) by passing script-based commands (via API, etc.) to each of the various types of microservices provided in OpenStack. In other words, there is a disadvantage that not only does the user have to input commands manually, but also a multi-step command input procedure must be performed in order. Additionally, if the procedure fails in the middle, it is difficult to determine how to rollback or re-perform the procedure.

First, the user prepares access authority information for the failed node (S301). At this time, access authority information may be obtained from the ring 0 cluster 115 described above.

Access the compute node where the corresponding faulty node occurred (S302).

Unschedule is performed (S303) so that the VM (Virtual Machine) and port of the failed node are no longer added.

Next, the migration procedure for the VM and port is performed (S304), and the Kubernetes label for the failed node is removed (S305).

You can remove the OpenStack compute service and network agent (S306), drain the pods (S307), and finally remove the failed node (S308).

If the order of the above procedural methods is changed or any order is omitted, the faulty node may not be completely removed, or even if it is removed, problems such as other types of errors may occur.

In addition, since issues such as errors always have to be handled by humans, a lot of resources are needed, and essential administrators must understand the entire process above. Since it is handled by the user, there are various problems such as difficulty in patterning failures and difficulty in automating and declarative management of the entire failure process.

To solve this problem, the node removal pod 116 according to an embodiment of the present invention is equipped with a node removal controller 201, enabling automation and declarative management of OpenStack hypervisors.

According to this automation and declarative management, the administrator's management can be simplified to the following procedures.

(1) Deploying node removal pods (116) into shared clusters (114)

(2) Change the label of the failed node

(3) Automatically remove nodes from the operator

That is, according to one embodiment of the present invention, cloud-native management is possible by applying an operator to the OpenStack hypervisor. And it becomes possible to pattern the issue of node failure. Additionally, it is possible to collect and respond to various error issues.

Hypervisors to which an embodiment of the present invention can respond include not only the above-described compute nodes but also various targets such as DHCP nodes.

Referring again to FIG. 2, the cluster CR storage unit 204 stores at least one cluster CR defined by the AZ cluster controller 202.

The node CR storage unit 203 stores at least one node CR defined by the AZ cluster controller 202.

The access authority information storage unit 205 requests the ring 0 cluster 115 for access authority information (AZ node kubeconfig) for at least one node included in the AZ cluster 111, and provides the access authority information (AZ node kubeconfig) received in response to the request. Save permission information. At this time, considering the security of the undercloud cluster 113, the access permission information storage unit 205 can store the access permission information in a higher security manner. An example of a higher security method is the "Sealed-secret" method in Kubernetes open source.

If access information is not encrypted using the "Sealed-secret" method, when access rights information is leaked due to an external intrusion, direct access to the cluster may be possible based on the access rights information leaked from the outside.

However, when access authority information is encrypted in the above-described manner, the information cannot be decrypted without the key information used during encryption. Accordingly, even if access rights are leaked due to an external intrusion, direct access to the cluster using this is impossible.

Accordingly, even if authority information is leaked due to an external intrusion, there is an effect of preventing access from other clusters.

The monitoring unit 206 continuously monitors the IT resources of the AZ cluster 111.

FIG. 4 is a diagram illustrating a control flowchart defining CR of the AZ cluster controller 202 according to an embodiment of the present invention.

First, the AZ cluster controller 202 acquires a cluster CR based on a predefined Custom Resource Definition (CRD) (S401). Then, the above-described reconciliation is performed based on the obtained cluster CR (S402).

The AZ cluster controller 202 obtains access authority information from the ring 0 cluster 115 (S403) and stores it (S404). At this time, the storage method can be performed using the “Sealed-secret” method in Kubernetes open source described above.

Next, the AZ cluster controller 202 acquires at least one node information (S405), and generates and stores a node CR based on the obtained node information (S406).

In step S407, the AZ cluster controller 202 monitors at least one node and determines whether an event occurs (S408). If the event does not occur, step S407 may be performed repeatedly.

An event may refer to an event in which a new node is introduced or deleted. In particular, an event according to an embodiment of the present invention is an event that can be defined in Kubernetes open source, and various types of operations can be performed depending on whether the event is triggered.

If it is determined that an event has occurred, the process proceeds to step S409 and readjustment is performed.

CR (node CR and cluster CR) can be updated (S410) to reflect changes made by the readjustment operation. In this case, updating may include creating a new CR for a newly introduced node, removing the CR of a deleted node, or reflecting changed cluster information in the cluster CR.

Below, FIG. 5 describes the specific order in which a node is removed by the node removal pod 116.

FIG. 5 is a diagram illustrating a node removal flowchart of the node removal pod 116 according to an embodiment of the present invention.

FIG. 6 is a conceptual diagram showing how the node removal pod 116 removes a node according to an embodiment of the present invention.

Hereinafter, the description will be made with reference to FIGS. 5 and 6 together.

As described above, the node removal controller 201 is a controller for controlling the resources of the node CRD (or node removal CRD) created by the AZ cluster controller, and transfers OpenStack-based IT resources without interruption and prevents failures. It serves to remove nodes.

The node CRD according to an embodiment of the present invention may be configured to include node removal specifications and node removal status information.

The node removal specification may be configured to include at least one of the name of the cluster that holds the node, information on access rights to OpenStack Nova and Neutron, and information about the node itself (UID, InternalIP).

Node removal status information includes at least the elimination operation phase (EliminatePhase), error information that occurred during operation, removed VM (Virtual Machine) and Port, Pod information, and changeable node information (Node Label, Annotation, Conditions, Ready). It can be configured to include one.

Node CR can be generated as many CRs as the number of nodes based on the node CRD described above.

First, in step S501, the node removal controller 201 obtains the node CR stored in the node CR storage unit 203. Then, the readjustment described above is performed using the obtained node CR (S502). If the AZ cluster controller 202 has not yet created the node CR, requeue can be performed until the node CR is created.

Next, the node removal controller 201 obtains the access authority information stored in the access authority storage unit 205 (S503).

Using the obtained access authority information, the monitoring unit 206 acquires a client of the AZ cluster 111 and then monitors the label of the node (S504, tracking). Here, the client may mean authority to handle resources within the AZ cluster 111. Monitoring according to an embodiment of the present invention can use the Kubernetes open source informer.

If the label of the monitored node is "node-eliminate=enabled", it can be determined (S505), and if it changes, an operation to remove the node can be performed (S506). If a node's label exists as shown above, it is judged to be a failed node. The determination in step S505 according to an embodiment of the present invention may be performed depending on whether the label is changed to “node-eliminate=enabled”.

Meanwhile, the monitoring unit 206 according to an embodiment of the present invention is proposed to further include a node problem detector for determining node failure at the log stage. The node failure detector may be provided in open source form, and by determining failures based on log information, it is possible to quickly and accurately identify failed nodes without requiring user involvement.

Such label change may be performed by an administrator (user)'s label change input through a label input unit (not shown), but the node removal device 100 may automatically detect a failure and change the label. will be. The present invention will not be limited to the way the label is changed.

At this time, the failed node removal device 100 according to an embodiment of the present invention will be able to move the OpenStack resources existing in the failed node to another safe node. In other words, the role of the failed node can be transferred to another safe node and the service can be provided continuously.

Removal of the compute node may be performed according to the flowchart of FIG. 3 described above, but for other types of nodes (e.g., the DHCP node described above, etc.), the removal order or procedure may be different.

When removal is completed, the current status reflecting the removed failed node can be updated in the node CR (S507).

FIG. 7 is a diagram illustrating the configuration of a faulty node removal device 100 according to an embodiment.

Referring to FIG. 7, the apparatus 100 for removing a faulty node includes a processor 701 and a memory 702. Memory 702 stores one or more instructions executable by processor 701. Processor 701 executes one or more instructions stored in memory 702.

Processor 701 may perform one or more operations described above with respect to FIGS. 1-6 by executing instructions. Additionally, the configuration of the present invention described above with reference to FIG. 1 may be implemented by instructions executed by the processor 701.

Above, an embodiment of the faulty node removal device 100 according to the present invention has been described, but this is explained as at least one embodiment, and the technical idea, configuration, and operation of the present invention are not limited thereby. The scope of the technical idea of the present invention is not limited/limited by the drawings or the description referring to the drawings.

In addition, the concept and embodiments of the invention presented in the present invention can be used by those skilled in the art as a basis for modifying or designing other structures to achieve the same purpose of the present invention. , Equivalent structures modified or changed by those skilled in the art to which the present invention pertains are bound to the technical scope of the present invention described in the claims, and do not depart from the spirit or scope of the invention described in the claims. Various changes, substitutions, and changes are possible within limits.

Claims (18)

a monitoring unit that monitors the current status of at least one node;
A node CR storage unit that stores a node CR (Custom Resource), which is the ideal status (desire status) of the node; and
Comprising a node removal controller that identifies a failed node among the at least one node based on the monitoring result and the node CR, and performs processing on the identified failed node,
Node removal device.
According to claim 1,
The faulty node is a node whose monitored current state is different from the stored ideal state,
Node removal device.
The method of claim 1, wherein the node removal controller,
Performing processing on the identified faulty node in a declarative manner,
Node removal device.
The method of claim 3, wherein the node removal controller,
Performing reconciliation and removing the identified faulty node,
Node removal device.
According to claim 1,
Further comprising an access permission storage unit that stores access permission information for accessing the at least one node,
Node removal device.
The method of claim 5, wherein the monitoring unit,
Obtaining a client for the at least one node using the stored access authority information,
Node removal device.
According to claim 1,
Further comprising an Availability Zone (AZ) cluster controller defining a node CR for the at least one node,
Node removal device.
The method of claim 7, wherein the node CR stored in the node CR storage unit is
A node CR defined by the AZ cluster controller,
Node removal device.
According to claim 1,
Further comprising a label input unit that receives a label change input from the user,
The monitoring unit identifies a node whose label has changed as a faulty node based on the label change input.
Node removal device.
monitoring the current state of at least one node;
Storing a node CR (Custom Resource), which is the ideal status (desire status) of the node; and
Comprising the step of identifying a failed node among the at least one node based on the monitoring result and the node CR, and performing processing on the identified failed node.
Control method of node removal device.
According to claim 10,
The faulty node is a node whose monitored current state is different from the stored ideal state,
Control method of node removal device.
The method of claim 10, wherein the node removal controller,
Performing processing on the identified faulty node in a declarative manner,
Control method of node removal device.
13. The method of claim 12, wherein performing the processing comprises:
Performing reconciliation and removing the identified faulty node,
Control method of node removal device.
According to claim 10,
Further comprising the step of the access authority storage unit storing access authority information for accessing the at least one node,
Control method of node removal device.
The method of claim 14, wherein the monitoring step includes:
Obtaining a client for the at least one node using the stored access authority information,
Control method of node removal device.
According to claim 10,
Further comprising the step of defining, by an Availability Zone (AZ) cluster controller, a node CR for the at least one node.
Control method of node removal device.
The method of claim 16, wherein the node CR stored in the node CR storage unit is
A node CR defined by the AZ cluster controller,
Control method of node removal device.
According to claim 10,
The label input unit further includes receiving a label change input from the user,
The monitoring step includes identifying a node whose label has changed as a faulty node based on the label change input.
Control method of node removal device.