KR20260052572A - Method and computing apparatus for automatically accessing applications on nodes in a kubernetes cluster environment - Google Patents

Abstract

A method for automatically accessing an application on a node in a Kubernetes cluster is disclosed. The method comprises the steps of: an IngressMapper installed on the master node searching for a target application running on one of the nodes in the Kubernetes cluster in response to a user's service request; the IngressMapper checking whether there exists a NodePort service that exposes the target application to the outside; if the NodePort service exists, the IngressMapper automatically generating normalized access information that can access the target application; and the IngressMapper creating an Ingress resource based on the normalized access information and then applying the Ingress resource to the Kubernetes cluster.

Description

Method and Computing Apparatus for Automatically Accessing Applications on Nodes in a Kubernetes Cluster

The present invention relates to a technology for generating and managing service access paths in a Kubernetes cluster environment, and more specifically, to a technology for automatically generating and managing rules for access paths for applications running on each node of a hybrid Kubernetes cluster combining cloud and edge computing environments.

Conventional Kubernetes distributes requests for applications from the outside across multiple instances using load balancing. However, when performing scheduling tasks to utilize the accelerator resources of a specific node later, or when factors such as the physical distance between nodes and other elements have an impact, such as in a cloud-edge hybrid environment, the general service configuration and traffic distribution via load balancing provided by Kubernetes are not suitable.

In such an environment, if direct access to an application on a specific node is required, the administrator must manually set and manage individual access paths for each application on the node, which causes inconvenience to users and increases the complexity of management.

Therefore, there is a need for a method to provide a path (e.g., Uniform Resource Locator: URL) for accessing services deployed on each node by combining information obtainable from Kubernetes without administrator intervention, thereby enabling users to access the desired services more easily.

The objective of the present invention, which aims to solve the aforementioned problems, is to provide an apparatus and method for automatically generating and managing access paths for applications on each node in a cloud-edge hybrid Kubernetes cluster. By achieving this objective, users can easily access services on specific nodes, and administrators can efficiently manage service access paths.

A method for automatically accessing an application on a node in a Kubernetes cluster according to one aspect of the present invention for achieving the above-described purpose comprises: a step in which an IngressMapper installed on the master node searches for a target application running on one of the nodes in the Kubernetes cluster in response to a user's service request; a step in which the IngressMapper checks whether there is a NodePort Service that exposes the target application to the outside; a step in which, if there is a NodePort Service, the IngressMapper automatically generates normalized access information that can access the target application; and a step in which the IngressMapper creates an Ingress resource based on the normalized access information and then applies the Ingress resource to the Kubernetes cluster.

In an embodiment, the method further includes the step of, if the nodeport service does not exist, the ingress mapper creating a nodeport service capable of exposing the target application to the outside, and then automatically generating the normalized access information.

In an embodiment, the normalized access information includes an IP address (Internet Protocol Address), a node name, and a service name.

In the example, the format of the URL is http://IP/[Node name]/[Service name].

In an embodiment, the step of applying the ingress resource to the Kubernetes cluster includes the step of creating a YAML file that defines the ingress resource, and the YAML file includes an IP address, a node name, a service name, and a service port number.

In an embodiment, the step of applying the ingress resource to the Kubernetes cluster includes the step of deploying an ingress controller to the Kubernetes cluster (node(s) included in the Kubernetes cluster) to operate the ingress resource.

A computing device for automatically accessing an application on a node in a Kubernetes cluster according to another aspect of the present invention comprises: a processor; a storage unit for storing an IngressMapper executed by the processor; a memory for storing instructions required for the execution of the IngressMapper; and a communication device for supporting communication with nodes included in the Kubernetes cluster. The IngressMapper searches for a target application running on one of the nodes in response to a user's service request, checks whether there is a Nodeport Service that exposes the target application to the outside, and if the Nodeport Service exists, automatically generates normalized access information that can access the target application, creates an Ingress resource based on the normalized access information, and then applies the Ingress resource to the Kubernetes cluster.

According to the present invention, by automatically generating and managing access paths for specific image-based Kubernetes workloads (kubernetes workload: applications running on Kubernetes), users can easily access applications on specific nodes, and administrators can reduce the complexity of management through the automated generation and management of application access paths.

Figures 1 and 2 are diagrams illustrating the problems of a load balancing scenario based on application service requests, which is an existing technology related to the present invention.
FIG. 3 is a diagram illustrating a scenario according to an individual application service request according to an embodiment of the present invention.
FIG. 4 is a flowchart showing the operation process of an IngressMapper according to an embodiment of the present invention.
FIG. 5 is a configuration diagram of a master node with an IngressMapper installed according to an embodiment of the present invention.

The terms used in this specification are used merely to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, terms such as “comprising” or “having” are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

First, to aid in understanding the present invention, some terms that may be used in this specification will be briefly explained.

Kubernetes

Kubernetes is an open source platform that automates the deployment, scaling, and management of containerized applications. It manages applications as resources called Pods and runs them by deploying them across multiple nodes within a cluster. Additionally, it appropriately distributes external traffic through service discovery and load balancing, and provides various features such as storage orchestration, automated rollouts and rollbacks, and self-healing.

Kubernetes can expose containers using DNS names or their own IP addresses through service discovery. When there is a lot of traffic to containers, Kubernetes distributes network traffic through load balancing to ensure that the deployment remains stable.

Kubernetes can automatically mount storage systems, such as local storage and public cloud providers, through storage orchestration capabilities.

Kubernetes can automatically create new containers, remove existing containers, and apply all resources to new containers through automated rollouts and rollbacks.

Through self-healing capabilities, Kubernetes restarts containers that fail, replaces containers, kills containers that do not respond to user-defined health checks, and does not advertise them to clients until they are ready to serve.

Due to these features, Kubernetes minimizes administrator intervention through automated operations in cloud environments and supports efficient resource management by optimizing the resources of instances participating in the cluster; therefore, in special cases such as hybrid clusters, it is necessary to provide a separate service approach.

pod

A Pod is the smallest unit in Kubernetes where containers run. A single Pod can contain one or more containers. A Pod is an object that provides the execution environment for an application. A Pod includes an application, an application container, an IP address, and shared storage such as volumes.

Node

A node is a physical or virtual computing device in a Kubernetes cluster where pods run. Here, the computing device can be a server or a desktop. A Kubernetes cluster can have multiple nodes, and each node runs pods by providing CPU, memory, network, etc. Nodes are managed by the Kubernetes Control Plane.

Kubernetes service

Kubernetes Services provides the ability to expose pods running within a cluster as network services. This enables users inside or outside the cluster to access the pods. By default, Kubernetes Services provides various types of services, such as cluster IPs, NodePorts, LoadBalancers, and ExternalNames, to address diverse network scenarios.

In particular, the NodePort service assigns a fixed port to each node to allow external access to specific pods within the cluster, enabling users to access those pods through this port. However, this approach entails the inconvenience of requiring administrators to manually configure and manage NodePorts for each service, as well as users having to identify NodePort information themselves.

Ingress

An Ingress is a resource that defines HTTP and HTTPS routing rules configured to allow access to internal services from outside a Kubernetes cluster. Ingress controls access to services within the cluster and is primarily used to configure access paths for web applications.

Figures 1 and 2 are diagrams illustrating the problems of a load balancing scenario based on application service requests, which is an existing technology related to the present invention.

Referring to FIG. 1, as described above, the Kubernetes cluster (10) manages traffic by distributing requests coming into the application from the outside to multiple instances through load balancing.

The master node (11) may be a physical or virtual computing device that manages the Kubernetes cluster (10). The master node (11) is used in conjunction with a control plane that controls access to services.

A Nodeport Service is a Kubernetes resource that controls access to specific pods. A Nodeport Service allows external access to services within a specific pod through underlying Nodeport configurations. This is similar to the concept of port forwarding.

Node A (13), Node B (14) and Node C (15) are actual or virtual computing devices that make up the Kubernetes cluster (10).

AI (Artificial Intelligence) services (AI Service, 3 and 4) and data service (data Service, 5) refer to Pods or applications deployed on each node in a Kubernetes cluster (10). An AI service is a service that provides AI-related functions or applications. A data service is a service that provides a database.

When a user accesses the master node (11) in the Kubernetes cluster (10) and requests access to a specific pod or application, it operates as follows.

First, a user (user's computing device) requests access to an AI service application from a master node (11) of a Kubernetes cluster (10) via, for example, a REST API call.

Next, the nodeport service (12) receives an access request for an AI service application, checks the resources and existing operations of each node, and then forwards the access request to nodes (13 and 14) capable of providing the AI service application. At this time, the nodeport service (12) distributes the load to node A (13) and node B (14) in a round-robin manner.

Next, Node A (13) or Node B (14) provides AI services to the user.

While this method can be very effective in a cloud-based environment, it has several problems in a cloud-edge hybrid environment. For example, if there is a need to use accelerator resources of a specific node or if there are real-time processing requirements due to the physical distance from that node, direct access to the service running on that specific node is required rather than traffic distribution through load balancing. For example, as shown in FIG. 2, when using a service that requires real-time processing, there may be a case where the service is used from Node C (15), which is physically far away, through Load Balancing (LB) (16).

In FIG. 2, the master node (11) is networked with the remaining nodes (13, 14 and 15) in the Kubernetes cluster (10), and the remaining nodes (13, 14 and 15) are devices that actually exist in the local environment.

When a user uses a service that requires real-time processing, they must use the service provided by Node B (14), which is physically closer, to minimize network latency. However, there may be cases where the service is provided by Node C (15) through load balancing (16). This case is less efficient than receiving the service from Node B (14).

To resolve the problem that occurs in a situation like Figure 2 in a Kubernetes cloud environment, direct access to each application is required, and for this, the following three procedures are necessary.

1. The administrator creates NodePort services mapped to applications on each node by individually configuring them to different ports.

2. The user requests the port information of the node they wish to access from the administrator (master node).

3. The user accesses an application running (or executing) on a specific node through the above port information

FIG. 3 is a diagram illustrating a scenario according to an individual application service request according to an embodiment of the present invention.

Referring to FIG. 3, a Kubernetes cluster (100) according to an embodiment of the present invention may be configured to include, for example, a master node (101) and three nodes (105, 106 and 107), but without limitation, the Kubernetes cluster (100) may be configured to include four or more nodes.

Between the master node (101) and the three nodes (105, 106, and 107), three different Nodeport services (102, 103, and 104) created (configured) by the master node (101) are provided. The three Nodeport services (102, 103, and 104) are connected one-to-one to applications (105', 106', and 107') running (providing) on the three nodes (105, 106, and 107). Here, the applications (105', 106', and 107') may be applications that provide AI services.

In the Kubernetes cluster (100) according to the present embodiment, three different nodeport services (102, 103, and 104) are connected one-to-one to applications (105', 106', and 107') running (provided) on three nodes (105, 106, and 107), thereby preventing the problem of a user device (300) accessing a node other than the desired node through the load balancing of FIGS. 1 and 2.

A user device (300) may explicitly request access to a specific node from the master node (101). However, in this case, there is a problem that the administrator device (200) must individually set access information (e.g., port information) for the nodes, and the user device must also know the access information (e.g., port information) for the nodes in advance.

For example, as illustrated in FIG. 3, to access an application (105') of node A (105), a user device (300) requests node port information (e.g., port 30010) for accessing the application (105') of node A (105) from a manager device (200), and can access the application (105') through the corresponding port information (e.g., port 30010) in response to the request.

In this access scenario, the administrator device (200) must manually create and manage a Nodeport Service for each application and provide it to the user device (300), which increases the complexity of management and the likelihood of errors. Additionally, the user device (300) must also directly find out the Nodeport information, which makes it difficult to use. These problems can occur even within a single cluster, and cause greater difficulties, especially in large-scale environments where multiple clusters must be managed.

This specification proposes a system called IngressMapper to solve the problems of a hybrid environment in a Kubernetes cluster.

IngressMapper is a system that automatically generates and manages access paths for Kubernetes workloads using specific container images, and may be software installed on the master node (101) of FIG. 3. IngressMapper may also be a tool that visualizes or manages the status, routing information, etc. of ingress resources.

IngressMapper creates a scenario configuration like Figure 3 in a way that minimizes manual intervention by administrators and simplifies access to services within the cluster, and enables access via a URL (Uniform Resource Locator).

The features of the IngressMapper technology according to the present embodiment are as follows.

First, it automatically creates an Ingress Resource that can access the services provided by the Pod (Application).

Second, whereas previously users and administrators separately created Ingress Resources and applied corresponding rules to the Ingress Resources, in this embodiment, the IngressMapper automatically generates a URL that allows access to the Ingress Resources for specific rules and applies it to the Ingress Resources.

The operation of the IngressMapper according to the present embodiment includes the following key steps.

A. Pod Information Verification Step

The IngressMapper first collects information about Pods (applications) deployed in the Kubernetes cluster. At this stage, it obtains a list of target Pods based on the container images that serve as the foundation for Pod operations. This information about the Pods refers, for example, to the node where the Pod is installed and the information about the Pod itself.

B. Service Creation and Verification Steps

Once Pod information is verified, the IngressMapper checks whether a service corresponding to each Pod exists and automatically creates a NodePort service if necessary. Here, the automatic creation of a NodePort service means either automatically generating a configuration file (e.g., a YAML file) containing a URL that allows access to an Ingress Resource created by the IngressMapper, or automatically creating an instance of an Ingress Resource containing NodePort information. These NodePort services enable network access to the Pods and assign different ports per node. For example, a NodePort A service is created (configured) for Pod A (Application A) running on Node A, and similarly, a NodePort B service is created (configured) for Pod B (Application B) on Node B.

C. IngressMapper YAML File Update and Ingress Creation Steps

Next, the IngressMapper generates and updates a YAML file defining Ingress resources based on the service information of each node. Here, the service information of each node refers to NodePort information, which includes the port number and the service name (application name). This YAML file includes information such as the IP address (Internet Protocol Address), node name, pod or service name, and service port number. Based on this known information, it generates a fully qualified URL that users can easily access, as shown in the following example. Here, the known information refers to information obtainable, for example, through the Kubernetes API, and includes, for instance, the node name, pod name, service name, and NodePort number.

URL example: http://IP/[Node name]/[Service name]

For example, the URL to access Pod A on Node A is http://IP/NodeA/ServiceA, and Pod B on Node B is http://IP/NodeB/ServiceB.

Table 1 below is an example of a YAML file for an Ingress resource generated by IngressMapper.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-mapper
spec:
rules:
- host: example.com
http:
paths:
- path: /NodeA/ServiceA
pathType: Prefix
backend:
service:
name: ServiceA
port:
number: 30010
- path: /NodeB/ServiceB
pathType: Prefix
backend:
service:
name: ServiceB
port:
number: 30020

D. Ingress Controller Deployment and Verification Steps

The IngressMapper deploys Ingress controllers to the Kubernetes cluster (node(s) included in the Kubernetes cluster) to ensure Ingress resources operate properly, and continuously monitors their operational status. An Ingress controller is a component within a Kubernetes cluster that routes external traffic to internal services. This controller enables users to easily access services on each node via defined URLs.

FIG. 4 is a flowchart showing the operation process of an IngressMapper according to an embodiment of the present invention.

Referring to FIG. 4, first, in step S110, an IngressMapper installed on the master node (101) discovers the target application in the Kubernetes cluster in response to a service request for the target application received from a user (user device (300)). Here, the method of discovering the target application can be identified through the container name. The container name can be identified through the Kubernetes API.

Next, in step S120, the IngressMapper checks whether there is a Nodeport service that exposes the target application to the outside in the Kubernetes cluster. That is, the IngressMapper checks whether there is a Nodeport service that can access the target application.

Next, in step S120, if a Nodeport service exists, the IngressMapper generates normalized access information (e.g., a URL) that allows access to the target application based on the information. Here, examples of access information such as the URL include an IP address (Internet Protocol Address), node name, pod name, service name, service port number, etc. If a Nodeport service does not exist, in step S130, the IngressMapper creates (configures) a Nodeport service that allows the target application to be exposed externally, and then generates the normalized access information (e.g., a URL).

Next, in step S140, the IngressMapper creates an Ingress resource based on the normalized access information (e.g., URL) generated in step S120 and applies it to the Kubernetes cluster.

The main features of the IngressMapper described above are summarized as follows.

Automated access path creation and management

In traditional Ingress systems, administrators must manually create and manage Ingress resources for each service. In particular, accessing individual nodes requires accurately identifying the service and port information of each node and configuring Ingress resources based on this information. This increases management complexity and raises the likelihood of errors.

On the other hand, the IngressMapper according to the present embodiment automates these manual tasks to automatically create a NodePort service for a pod using a specific image, create an Ingress resource based on it, and deploy it to a Kubenetes cluster. This frees administrators from complex configuration tasks and significantly improves the management efficiency of Ingress resources.

Provide normalized access paths

In traditional Ingress, access paths for individual nodes or pods can differ, and users must separately remember and use port or path information for each service. This approach can be inefficient in terms of management and accessibility, particularly in hybrid environments spanning multiple nodes.

In contrast, the IngressMapper according to the present embodiment provides a normalized access path for each node and pod, enabling users to easily access each service via URL using already known information.

Dynamic management based on Pod status

The existing approach does not dynamically manage resources in response to changes in Pod state. When a Pod is created or deleted, administrators must manually update Ingress resources, and there is a lack of mechanisms to automate this process.

In contrast, the IngressMapper according to the present embodiment continuously monitors the status of Pods based on specific container images and automatically updates Ingress resources when Pods are created, deleted, or modified. This dynamic management capability enhances the availability and efficiency of services within a Kubernetes cluster and supports the automatic optimization of infrastructure without administrator intervention.

Hybrid cluster support

While existing load balancing systems are effective in cloud-based environments, they fail to effectively support traffic routing based on physical distance or specific hardware resource requirements in cloud-edge hybrid environments. This makes them inefficient for services requiring real-time processing.

In contrast, the IngressMapper according to the present embodiment is designed with a hybrid cluster environment in mind and can route traffic in a way that optimizes the resources of a specific node or minimizes physical distance. As a result, it operates efficiently even in environments where real-time processing and the utilization of high-performance resources are critical.

FIG. 5 is a configuration diagram of a master node with an IngressMapper installed according to an embodiment of the present invention.

Referring to FIG. 5, the master node (101) may be a computing device or a sub-computing device included in the computing device. The computing device or sub-computing device includes, for example, a processor (50), a storage unit (60), memory (70), a communication device (80), and an input/output interface. The processor (50) controls and manages the overall operation of peripheral components (60 to 90). The processor (50) executes a specific operating system (OS) and an ingress mapper (62) that operates on the operating system. The processor (50) supports operations to perform the functions of the executed ingress mapper (62). The processor (50) includes at least one CPU and at least one GPU. The storage unit (60) is a non-volatile storage device that stores the operating system and the ingress mapper (62). Examples of non-volatile storage devices include a hard disk drive (HDD), a solid-state drive (SSD), and ROM/EEPROM (rewritable read-only memory). The memory (70) may be a volatile memory that stores instructions required for the execution of the ingress mapper (62). The memory (70) provides the instructions to the processor (50) upon the request of the processor (50). The communication device (80) is a device that supports communication (e.g., web communication) with the nodes (105-107) and user device (300) shown in FIG. 3, and may be an example of a network interface. The input interface (90) is a device that transmits user input to the processor (50), and, for example, transmits various user inputs required for the execution, operation, and configuration of the ingress mapper (62) to the processor (50).

In an embodiment, an ingress mapper (62) executed by a processor (50) performs the following functions: searching for a target application running on one of the nodes according to a user's service request; checking whether there is a Nodeport Service that exposes the target application to the outside; if there is a Nodeport Service, automatically generating normalized access information that can access the target application; and creating an Ingress resource based on the normalized access information and then applying the Ingress resource to the Kubernetes cluster.

In an embodiment, the ingress mapper (62) executed by the processor (50) performs the function of automatically generating the normalized access information after creating a node port service that can expose the target application to the outside when the node port service does not exist.

In an embodiment, the normalized access information may be a Uniform Resource Locator (URL) including an Internet Protocol Address (IP), a node name, and a service name.

In an example, the format of the URL may be http://IP/[Node name]/[Service name].

In an embodiment, an ingress mapper (62) executed by a processor (50) generates a YAML file defining the ingress resources, wherein the YAML file includes an IP address, a node name, a service name, and a service port number. YAML is a term derived from the name "YAML Ain't Markup Language" and is a language focused on expressing data structures rather than being a markup language.

In an embodiment, an ingress mapper (62) executed by a processor (50) deploys an ingress controller to the Kubernetes cluster to operate the ingress resource.

The embodiments disclosed in this specification should be considered for illustrative purposes rather than for limiting purposes. The scope of the invention is defined by the claims, not by the foregoing description, and all variations within the scope of the claims should be interpreted as being included in the invention.

Claims (12)

A method for automatically accessing applications on nodes in a Kubernetes cluster comprising a master node and nodes, wherein the master node is connected to the nodes through a Nodeport Service configured per node,
A step in which an IngressMapper installed on the master node searches for a target application running on one of the nodes in the Kubernetes cluster in response to a user's service request;
The above ingress mapper checks whether the nodeport service that exposes the target application to the outside exists;
If the above nodeport service exists, the ingress mapper automatically generates normalized access information that can access the target application; and
The above ingress mapper creates an ingress resource based on the normalized access information, and then deploys the ingress resource to the Kubernetes cluster.
A method for automatically accessing applications on nodes in a Kubernetes cluster that includes In paragraph 1,
If the above nodeport service does not exist, the ingress mapper creates a nodeport service capable of exposing the target application externally, and then automatically generates the normalized access information.
A method for automatically accessing applications on nodes in a Kubernetes cluster that includes more. In paragraph 1,
A method for automatically accessing an application on a node in a Kubernetes cluster, wherein the above-mentioned normalized access information is a Uniform Resource Locator (URL) containing an Internet Protocol Address (IP), a node name, and a service name. In Paragraph 3,
A method for automatically accessing an application on a node in a Kubernetes cluster, wherein the format of the above URL is http://IP/[Node name]/[Service name]. In paragraph 1,
The step of applying the above ingress resource to the above Kubernetes cluster is,
It includes the step of creating a YAML file that defines the above ingress resource, and
A method for automatically accessing an application on a node in a Kubernetes cluster, wherein the above YAML file includes an IP address, node name, service name, and service port number. In paragraph 1,
The step of applying the above ingress resource to the above Kubernetes cluster is,
A method for automatically accessing an application on a node in a Kubernetes cluster, comprising the step of deploying an Ingress controller to the Kubernetes cluster to operate the above Ingress resource. processor;
A storage unit for storing an IngressMapper executed by the above processor;
Memory for storing commands required for the execution of the above ingress mapper; and
It includes a communication device that supports communication with nodes included in a Kubernetes cluster, and
The above Ingress Mapper is,
Search for a target application running on one of the above nodes in accordance with the user's service request, and
Check whether a Nodeport Service exists that exposes the above target application externally, and
If the above NodePort service exists, normalized access information that can access the above target application is automatically generated, and
A computing device for automatically accessing applications on nodes in a Kubernetes cluster, characterized by creating an Ingress resource based on the normalized access information and then deploying the Ingress resource to the Kubernetes cluster. In Paragraph 7,
The above Ingress Mapper is,
A computing device for automatically accessing an application on a node in a Kubernetes cluster, wherein, if the above-mentioned nodeport service does not exist, a nodeport service capable of exposing the target application to the outside is created, and then the above-mentioned normalized access information is automatically generated. In Paragraph 7,
A computing device for automatically accessing applications on nodes in a Kubernetes cluster, wherein the above-mentioned normalized access information is a Uniform Resource Locator (URL) including an Internet Protocol Address (IP), a node name, and a service name. In Paragraph 9,
A computing device for automatically accessing applications on nodes in a Kubernetes cluster, wherein the format of the above URL is http://IP/[Node name]/[Service name]. In Paragraph 7,
The above Ingress Mapper is,
Create a YAML file defining the above ingress resource, and
A computing device for automatically accessing applications on nodes in a Kubernetes cluster, wherein the above YAML file includes an IP address, node name, service name, and service port number. In Paragraph 7,
The above Ingress Mapper is,
A computing device for automatically accessing applications on nodes in a Kubernetes cluster, which deploys an Ingress controller to the Kubernetes cluster to operate the above Ingress resources.