KR20220064785A - Apparatus and method for neural network group connection - Google Patents

Abstract

Disclosed are a device and method for generating a container profile. The device for generating a container profile according to one embodiment of the present invention comprises: a profile setting part that defines a container profile considering the characteristics of a service in a Kubernetes environment, and generates the profile information in which a priority of the container profile is set; a profile generating part that receives the profile information and generates the container profile for the service; a collection part that collects an indicator on a system corresponding to the Kubernetes environment; and a processing part that outputs a result of operating the container profile based on the indicator. Therefore, the present invention is capable of providing an efficient initial allocation placement of the container.

Description

Apparatus and method for creating container profile {APPARATUS AND METHOD FOR NEURAL NETWORK GROUP CONNECTION}

The present invention relates to a technology for creating a container profile, and more particularly, to a technology for creating a container profile in a Kubernetes environment.

Microservices are seen as a new software architecture for building highly modular applications deployed in the cloud. An application developed based on a microservices architecture consists of different small services that can each be deployed independently.

Microservices are often packaged in containers with lightweight virtualization compared to virtual machines (VMs). This is because there is no need to start or stop the operating system, which can take a significant amount of time. Because of their lightweight nature, they can be instantiated, terminated, and managed very dynamically, and leveraging this lightweight container-based virtualization can improve autoscaling in both application response times and resource utilization, both faster and more efficiently than using VMs. Various open source container management platforms such as Kubernetes are currently available for deploying scalable microservices. Today, almost every engineering position, from software engineer to site reliability engineer, uses Kubernetes. Site reliability engineers develop automated solutions for operational aspects such as performance and capacity planning, as well as responding to quality of service (QoS) degradation at runtime. Container management platforms like Kubernetes provide reactive autoscaling methods based on a set of static rules to operate on workloads that change over time. A common practice is primarily to use fixed infrastructure-level CPU-based autoscaling rules to increase or decrease the number of container instances allocated to a particular service based on demand. This traditional post-auto-scaling method using fixed rules may be suitable for some basic scenarios of cloud-based applications, but may lead to undesirable QoS or low resource utilization in environments with certain dynamic workload scenarios.

The existing Kubernetes scheduler applies the same algorithm policy to all Pods. However, as the microservice architecture evolves, users want to be able to receive seamless support of various services from one or multiple applications (containers). The existing Kubernetes scheduler does not define an independent priority for containers for each service and applies a batch deployment policy, so it has the disadvantage of not being able to respond flexibly in situations where the requirements of Pods for each service are different. In order to solve these problems, a container profile creation system and method that define selective priorities before creating containers in a Kubernetes environment are needed.

Meanwhile, Korean Patent Registration No. 10-2114339 “Operation method of a Kubernetes system supporting active/standby model” checks the error state of a plurality of pods in a monitoring processor, and checks the error status of a plurality of pods in the monitoring processor It is determined whether an active pod exists, and when the active pod does not exist among the plurality of pods in the monitoring processor, as a result of checking the error state, any one pod that does not have an error among the plurality of pods Disclosed is a method of operating a Kubernetes system that supports the active/standby model that requests the Kubernetes server to change the configuration of the pod to the active pod.

An object of the present invention is to define a profile for a service required by a user in a Kubernetes environment, and to provide effective initial allocation of containers based on the defined profile.

Another object of the present invention is to ensure QoS for application programs and provide efficient distribution of computing resources through effective initial allocation and placement of containers.

In order to achieve the above object, an apparatus for generating a container profile according to an embodiment of the present invention defines a container profile in consideration of service characteristics in a Kubernetes environment, and generates profile information in which the priority of the container profile is set. Profile setting unit; a profile generator configured to receive the profile information and generate a container profile for the service; and a collection unit that collects an indicator on a system corresponding to the Kubernetes environment, and a processing unit that outputs a result of calculating the container profile based on the indicator.

In addition, the container profile creation method according to an embodiment of the present invention for achieving the above object defines a container profile in consideration of service characteristics in a Kubernetes environment, and collects profile information that sets the priority of the container profile. generating; receiving the profile information and generating a container profile for the service; collecting an index on a system corresponding to the Kubernetes environment; and outputting a result of calculating the container profile based on the index.

The present invention can define a profile for a service required by a user in a Kubernetes environment, and provide effective initial allocation of containers based on the defined profile.

In addition, the present invention can guarantee QoS for application programs and provide efficient distribution of computing resources through effective initial allocation of containers.

1 is a block diagram illustrating a Kubernetes system environment according to an embodiment of the present invention.
2 is a block diagram illustrating an apparatus for generating a container profile according to an embodiment of the present invention.
3 is an operation flowchart illustrating a method for generating a container profile according to an embodiment of the present invention.
4 is a sequence diagram illustrating a task execution operation of a Kubernetes system according to an embodiment of the present invention.
5 is a diagram illustrating a computer system according to an embodiment of the present invention.

The present invention will be described in detail with reference to the accompanying drawings as follows. Here, repeated descriptions, well-known functions that may unnecessarily obscure the gist of the present invention, and detailed descriptions of configurations will be omitted. The embodiments of the present invention are provided in order to more completely explain the present invention to those of ordinary skill in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clearer description.

Throughout the specification, when a part "includes" a certain element, it means that other elements may be further included, rather than excluding other elements, unless otherwise stated.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a Kubernetes system environment according to an embodiment of the present invention.

Referring to FIG. 1 , a Kubernetes system according to an embodiment of the present invention includes a Kubernetes master 100 and a plurality of Kubernetes nodes 200 .

The Kubernetes master 100 may store the Kubernetes configuration environment and manage the entire cluster.

The Kubernetes master 100 includes an API server 110 , a scheduler 120 , a controller manager 130 , and an ETCD 140 .

The API server 110 may provide all functions of Kubernetes through the REST API and process commands therefor.

The scheduler 120 may allocate each resource, such as a pod (POD) and a service, to an appropriate node.

The controller manager 130 may create a controller (replica controller, service controller, volume controller, node controller, etc.), distribute the controller to each node, and manage the controller.

The ETCD 140 serves as a database of the Kubernetes cluster and may store cluster state or configuration information.

The Kubernetes node 200 may host a workload running on Kubernetes like a Pod, which is a single container or a set of multiple containers.

A Kubernetes node 200 includes a KUBELET 210 and a POD.

KUBELET (210) is an agent distributed to the node. While communicating with the API server 110 of the Kubernetes master 100, the KUBELET 210 receives and executes commands to be performed by the node. can be collected through

The POD may include a single container or a set of a plurality of containers.

At this time, the container profile generating apparatus 220 according to an embodiment of the present invention may be included in one pod and driven.

2 is a block diagram illustrating an apparatus for generating a container profile according to an embodiment of the present invention.

Referring to FIG. 2 , the container profile generating apparatus 220 according to an embodiment of the present invention includes a profile setting unit 221 , a profile generating unit 222 , a collecting unit 223 , and a processing unit 224 .

The profile setting unit 221 may define a container profile in consideration of the characteristics of a service or application in the Kubernetes environment, and generate profile information in which the priority of the container profile is set. For example, the priority may be set to 1-4. In this case, the user may define a container profile through the user terminal device 10 .

The container profile may include a Bandwidth Critical Profile, an Energy-Efficiency Profile, a Memory-Intensive Profile, a Compute-Intensive Profile, a Persistence Critical Profile, and a Data-Intensive Profile.

Bandwidth Critical Profile may set Network Utilization as the highest priority among the components of the profile setting unit 221 .

Energy-Efficiency Profile may set CPU Utilization as the highest priority among the components of the profile setting unit 221 and may set Downscaling Threshold of CPU Util. as a target value (eg, Upscaling Threshold: 80%, Downscaling Threshold: 30) %)).

In the Memory Intensive Profile, among the components of the profile setting unit 221, Memory Util. is set as the highest priority, and Mem. Util's Upscaling Threshold can be set as Target Value (eg Upscaling Threshold: 80%, Downscaling Threshold: 30%).

Compute Intensive Profile sets CPU Util. as the highest priority among the components of the profile setting unit 221, and CPU. Util's Upscaling Threshold can be set as Target Value (eg Upscaling Threshold: 80%, Downscaling Threshold: 30%). At this time, the profile setting unit 221 additionally sets the CPU Util. and the accelerator Util. as a priority together in a situation in which parallel processing can be performed together with the hardware accelerator (GPU, FPGA), and the CPU Util and the accelerator Util. Upscaling Threshold of can be set as Target Value.

In the Persistence Critical Profile, none of the components of the profile setting unit 221 may set priority. However, by setting “Adaptive value.” in each component to 0~10%, the purpose of the created Pod is to reduce the number of terminations as much as possible when the Kubernetes Autoscaling policy is applied.

In the Data-Intensive Profile, Disk Util. among the components of the profile setting unit 221 may be set as the highest priority.

Adaptation value can set a threshold in the range of 0 to 10% to reduce overhead caused by container creation/termination due to frequent autoscaling. Adaptation value can be added as much as adaptation value from utilization value of resource prioritized in each profile.

The profile generating unit 222 may receive the profile information set by the profile setting unit 221 and generate a container profile for the service or application.

In this case, the profile generator 222 may generate a profile specialized for a specific service or a profile suitable for application characteristics based on the combination of the received components.

In this case, the profile generator 222 may include Network, CPU, Memory, Disk, and Adaptation Interval.

The collection unit 223 may collect indicators on the system corresponding to the Kubernetes environment.

That is, the collection unit 223 collects indicators (metrics) on various systems such as Kubernetes nodes (masters, workers) 200, containers, and resources of the host computer, apiServer 110 and open-source monitoring tools such as Prometheus. System monitoring collected through

In this case, the collection unit 223 may include a Node metric module, a Container metric module, an Application metric module, a Kubernetes metric module, and a Profile metric module.

In this case, the collection unit 223 may perform system monitoring through the five modules.

The Node metric module can monitor metrics for hardware hosts (nodes) running Kubernetes containers.

At this time, the node metric module can collect information about the node's CPU, memory, disk, and network usage, as well as the node OS and kernel.

The container metric module can collect information about each container started in a node.

At this time, the container metric module can collect CPU, memory, disk, and network usage of the container.

Application metric module can collect metrics of individual applications running in containers. In this case, the application metric module may collect application response time, error frequency, and the like.

The Kubernetes metric module can collect Kubernetes' own resources, such as services, pods, and account information.

Profile metric module can collect profile information created through the profile generator. In this case, the profile information may be one of the profile list.

The processing unit 224 may output a result of calculating the container profile based on the index collected by the collection unit 223 .

In this case, the processing unit 224 may process an operation for deriving an optimal profile based on the collected index.

In this case, the processing unit 224 may include a proactive operation unit that performs a proactive operation and a reactive operation unit that performs a reactive operation.

The proactive operation unit can predict in advance the amount of resources required to apply the set profile.

At this time, the Proactive operation unit outputs reactive operation as input, node resource usage through node metric, container resource usage through container metric, application execution time and response time through application metric, service and Pod information and Profile Metric values can be input.

At this time, the Proactive operation unit is a module that predicts the resources of containers to be created in the future, and performs operations based on historical data. Basically, a learning algorithm such as reinforcement learning or a neural network is used. . in the process of calculation

At this time, the Proactive operation unit may output the priority resource defined in the profile, the targetAverageUtilization value of the defined resource, and app name = Profile name as outputs.

At this time, the Proactive operation unit may transmit the output of the operation to the HPA 20 to refer to defining the pod template.

The reactive operation unit may perform an operation on containers for which a specific profile is not set.

At this time, since the reactive operation unit does not predict the future resource usage of the newly created container, it can process the calculation based on the current CPU usage.

At this time, the reactive operation unit can define the number of pods as the output as the result of [sum of CPU usage of pods in the cluster / target CPU usage] as output.

3 is an operation flowchart illustrating a method for generating a container profile according to an embodiment of the present invention.

Referring to FIG. 3 , in the method for generating a container profile according to an embodiment of the present invention, a container profile may be set first ( S310 ).

That is, in step S310, a container profile may be defined in consideration of the characteristics of a service or application in the Kubernetes environment, and profile information in which the priority of the container profile is set may be generated. For example, the priority may be set to 1-4. In this case, the user may define a container profile through the user terminal device 10 .

The container profile may include a Bandwidth Critical Profile, an Energy-Efficiency Profile, a Memory-Intensive Profile, a Compute-Intensive Profile, a Persistence Critical Profile, and a Data-Intensive Profile.

Bandwidth Critical Profile may set Network Utilization as the highest priority among the components of the profile setting unit 221 .

Energy-Efficiency Profile may set CPU Utilization as the highest priority among the components of the profile setting unit 221 and may set Downscaling Threshold of CPU Util. as a target value (eg, Upscaling Threshold: 80%, Downscaling Threshold: 30) %)).

In the Memory Intensive Profile, among the components of the profile setting unit 221, Memory Util. is set as the highest priority, and Mem. Util's Upscaling Threshold can be set as Target Value (eg Upscaling Threshold: 80%, Downscaling Threshold: 30%).

Compute Intensive Profile sets CPU Util. as the highest priority among the components of the profile setting unit 221, and CPU. Util's Upscaling Threshold can be set as Target Value (eg Upscaling Threshold: 80%, Downscaling Threshold: 30%). At this time, the profile setting unit 221 additionally sets the CPU Util. and the accelerator Util. as a priority together in a situation in which parallel processing can be performed together with the hardware accelerator (GPU, FPGA), and the CPU Util and the accelerator Util. Upscaling Threshold of can be set as Target Value.

In the Persistence Critical Profile, none of the components of the profile setting unit 221 may set priority. However, by setting “Adaptive value.” in each component to 0~10%, the purpose of the created Pod is to reduce the number of terminations as much as possible when the Kubernetes Autoscaling policy is applied.

In the Data-Intensive Profile, Disk Util. among the components of the profile setting unit 221 may be set as the highest priority.

Adaptation value can set a threshold in the range of 0 to 10% to reduce overhead caused by container creation/termination due to frequent autoscaling. Adaptation value can be added as much as adaptation value from utilization value of resource prioritized in each profile.

In addition, the method for generating a container profile according to an embodiment of the present invention may generate a container profile ( S320 ).

That is, in step S320, a container profile for the service or application may be generated by receiving the profile information set in step S310.

In this case, in step S320, a profile specialized for a specific service or a profile suitable for application characteristics may be created based on the combination of the received components.

In this case, step S320 may include Network, CPU, Memory, Disk, and Adaptation Interval.

In addition, the method for generating a container profile according to an embodiment of the present invention may collect indicators ( S330 ).

That is, step S330 may collect indicators on the system corresponding to the Kubernetes environment.

At this time, in step S330, metrics (metrics) on various systems such as Kubernetes nodes (master, worker) 200, containers, and resources of the host computer, apiServer 110 and open source monitoring tools such as Prometheus System monitoring collected through

In this case, step S330 may include a Node metric module, a Container metric module, an Application metric module, a Kubernetes metric module, and a Profile metric module.

In this case, in step S330, system monitoring may be performed through the five modules.

The Node metric module can monitor metrics for hardware hosts (nodes) running Kubernetes containers.

At this time, the node metric module can collect information about the node's CPU, memory, disk, and network usage, as well as the node OS and kernel.

The container metric module can collect information about each container started in a node.

At this time, the container metric module can collect CPU, memory, disk, and network usage of the container.

Application metric module can collect metrics of individual applications running in containers. In this case, the application metric module may collect application response time, error frequency, and the like.

The Kubernetes metric module can collect Kubernetes' own resources, such as services, pods, and account information.

Profile metric module can collect profile information created through the profile generator. In this case, the profile information may be one of the profile list.

Also, the method for generating a container profile according to an embodiment of the present invention may process an index-based operation (S340).

That is, step S340 may output the result of calculating the container profile based on the index collected in step S330 .

In this case, in step S340, an operation for deriving an optimal profile may be processed based on the collected index.

In this case, step S340 may include a proactive operation unit that performs a proactive operation and a reactive operation unit that performs a reactive operation.

The proactive operation unit can predict in advance the amount of resources required to apply the set profile.

At this time, the Proactive operation unit outputs reactive operation as input, node resource usage through node metric, container resource usage through container metric, application execution time and response time through application metric, service and Pod information and Profile Metric values can be input.

At this time, the Proactive operation unit is a module that predicts the resources of containers to be created in the future, and performs operations based on historical data. Basically, a learning algorithm such as reinforcement learning or a neural network is used. . in the process of calculation

In this case, the Proactive operation unit may output the priority resource defined in the profile, the targetAverageUtilization value of the defined resource, and app name = Profile name as outputs.

At this time, the Proactive operation unit may transmit the output of the operation to the HPA 20 to refer to defining the pod template.

The reactive operation unit may perform an operation on containers for which a specific profile is not set.

At this time, since the reactive operation unit does not predict the future resource usage of the newly created container, it can process the calculation based on the current CPU usage.

At this time, the reactive operation unit can define the number of pods as output as the output of the [sum of CPU usage of pods in the cluster / Target CPU usage] as output.

4 is a sequence diagram illustrating a task execution operation of a Kubernetes system according to an embodiment of the present invention.

Referring to FIG. 4 , the API Server 110 may create a Default ReplicaSet ( S401 ).

The container profile generating apparatus 220 may deliver container profile information to the Horizontal Pod Autoscaler (HPA) 30 (S402)

The HPA 30 can always monitor the metric information from the apiServer 110 (S403). Here, the HPA 30 may define a pod template based on the received profile information and Kubernetes resource information. Pod template is a template in which basic information (resource definition, app name, disk volume definition, etc.) of a pod to be newly created is defined.

ReplicaSet Controller 130 may monitor ReplicaSet changes from apiServer 110 (S404). When the number of replicas is changed by the HPA 30, a pod creation or termination request can be sent according to the changed number (S405).

Scheduler 120 may monitor Pods waiting to be allocated to Node from apiServer 110 (S406).

Scheduler 120 may request allocation of Pod to apiServer when Node is ready (S407)

The Kubelet 210 can monitor whether the Pod is properly assigned to the Node from the apiServer 110 (S408)

The Kubelet 210 may request the Docker Runtime Engine 40 to run the container (S409).

The Kubelet 210 can update the Pod state in the apiServer 110 because the Pod state is updated when the container is created (S410).

5 is a diagram illustrating a computer system according to an embodiment of the present invention.

Referring to FIG. 5 , the Kubernetes master 100 , the Kubernetes node 200 , and the container profile generating apparatus 220 according to an embodiment of the present invention include a computer system such as a computer-readable recording medium ( 1100) can be implemented. As shown in FIG. 5 , the computer system 1100 includes one or more processors 1110 , a memory 1130 , a user interface input device 1140 , and a user interface output device 1150 that communicate with each other via a bus 1120 . and storage 1160 . In addition, the computer system 1100 may further include a network interface 1170 coupled to the network 1180 . The processor 1110 may be a central processing unit or a semiconductor device that executes processing instructions stored in the memory 1130 or the storage 1160 . The memory 1130 and the storage 1160 may be various types of volatile or non-volatile storage media. For example, the memory may include a ROM 1131 or a RAM 1132 .

As described above, in the apparatus and method for generating a container profile according to an embodiment of the present invention, the configuration and method of the described embodiments are not limitedly applicable, but the embodiments are provided so that various modifications can be made. All or part of each embodiment may be selectively combined and configured.

100: Kubernetes Master 110: API Server
120: scheduler 130: controller manager
140: ETCD
200: Kubernetes Node 210: KUBELET
220: container profile generating device
221: profile setting unit 222: profile generating unit
223: collection unit 224: processing unit
1100: computer system 1110: processor
1120: bus 1130: memory
1131: rom 1132: ram
1140: user interface input device
1150: user interface output device
1160: storage 1170: network interface
1180: network

Claims (1)

a profile setting unit that defines a container profile in consideration of service characteristics in a Kubernetes environment and generates profile information that sets the priority of the container profile;
a profile generator configured to receive the profile information and generate a container profile for the service;
a collection unit for collecting indicators on a system corresponding to the Kubernetes environment; and
a processing unit for outputting a result of calculating the container profile based on the index;
Container profile generating device comprising a.

Images