Computing device, packet forwarding method, and computer program

The XDP program in the network driver redirects packets to ingress containers for compliance and load balancing, addressing inefficiencies in existing methods by bypassing the host's network stack and enhancing security and resource efficiency in container virtualization environments.

JP2025100370AActive Publication Date: 2025-07-03MONITORAPP
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
JP2024200268
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-12-21
Filing Date
2024-11-18
Publication Date
2025-07-03
Estimated Expiration
2044-11-18

AI Technical Summary

Technical Problem

Existing packet transfer methods in container virtualization environments, such as those used in cloud-based security services, suffer from increased delays and resource inefficiencies due to the need to pass through multiple network stacks and complex routing paths, especially when using IP Virtual Server (IPVS) or DNAT rules.

Method used

Implementing an XDP program in the network driver to redirect packets directly to ingress containers based on service IP addresses, which perform compliance checks and load balancing before transferring them through overlay networks to service containers, bypassing the host's kernel network stack.

Benefits of technology

This approach enhances packet transfer efficiency by avoiding the host's network stack, reduces resource usage, and improves security through load balancing and compliance checks, while maintaining intuitive communication paths between ingress and service containers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025100370000001_ABST
    Figure 2025100370000001_ABST
Patent Text Reader

Abstract

To provide an efficient packet forwarding method utilizing eBPF (XDP) and a computing technique for realizing the same.SOLUTION: A method according to the present invention includes: a step in which, when a packet arrives at a network driver, an XDP program executed by the network driver checks a destination IP address of a packet; a step in which, when the destination IP address of the packet is a service IP address, the packet is redirected to an ingress container corresponding to the service IP address; a step in which the packet is forwarded through an overlay network to a service container determined according to a load balancing rule, after the ingress container that has received the packet performs a preset compatibility test on the packet.SELECTED DRAWING: Figure 3
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to an efficient packet transfer method using eBPF (XDP) in a container virtualization environment and a computing device for realizing the same.

Background Art

[0002] Cloud-based security services (SECaaS) are a model that provides various security functions desired by customers in a subscription-based manner. It is possible to provide security services such as a Web Application Firewall and Secure Internet Access in the form of a VM (Virtual Machine) or a container and provide them as a SECaaS (Security as a Service) service.

[0003] The packet transfer methods frequently used when providing services in the form of containers are as follows.

[0004] FIG. 1 and FIG. 2 are diagrams exemplarily showing packet transfer methods frequently used when providing services in the form of conventional containers.

[0005] As shown in FIG. 1, when a packet arriving at a host conforms to a DNAT rule, there is a method of transmitting the packet to the corresponding security service container, or as shown in FIG. 2, an Ingress Network is arranged before the packet reaches the security service container, and IPVS (IP Virtual Server) transfers it to an appropriate security service container.

[0006] However, there are some problems with services in the above forms.

[0007] In the method shown in FIG. 1, first, it is necessary to always pass through the host's network stack and process the container's network stack when entering each container. Also, when there is no ingress network, appropriate rules are added using the host's iptables, but inspection is required for each packet, and the delay increases as the number of rules increases. On the other hand, in the method shown in FIG. 2, when there is an ingress network, the path to reach the security service container becomes complex.

Summary of the Invention

Problems to be Solved by the Invention

[0008] The technical problem to be solved by the present invention is to provide an efficient packet transfer method utilizing eBPF (XDP) in a container virtualization environment and a computing device for realizing the same.

Means for Solving the Problems

[0009] The computing device according to the present invention for solving the above-described technical problems includes a plurality of Docker services, a plurality of ingress containers, and an XDP program loaded and executed in a network driver. The plurality of Docker services include a plurality of service containers providing the same service. Different service IP addresses are assigned to the plurality of ingress containers, and the different service IP addresses are predetermined for each type of service provided by the plurality of Docker services. The XDP program checks the destination IP address of a packet arriving at the network driver, transfers the packet from among the plurality of ingress containers to the ingress container to which the service IP address corresponding to the destination IP address is assigned, and the ingress container to which the packet is transferred transfers the packet through an overlay network to a service container determined according to a predetermined load balancing rule.

[0010] The ingress container that received the packet transfers the packet through the overlay network to a service container determined according to a predetermined load balancing rule.

[0011] The plurality of ingress containers can include a first ingress container and a second ingress container, and the first ingress container and the second ingress container can communicate with corresponding service containers via independently configured overlay networks.

[0012] When there are multiple Docker services corresponding to the ingress container, the ingress container can transfer the packet to the Docker service corresponding to the domain name included in the packet.

[0013] The computing device can further include a container management daemon and an XDP management daemon that are executed in the host default namespace of the computing device.

[0014] The XDP management daemon can set a packet transfer rule in which the service IP address corresponding to each of the plurality of ingress containers is mapped to the XDP program and load it into the network driver of the computing device.

[0015] The container management daemon can generate and manage a plurality of service containers in the form of Docker services.

[0016] The packet transfer method applied to the computing device according to the present invention for solving the above technical problem includes: when a packet reaches a network driver, a step of the XDP program executed by the network driver to check the destination IP address of the packet; when the destination IP address of the packet is a service IP address, a step of redirecting the packet to an ingress container corresponding to the service IP address; and after the ingress container that receives the packet performs a pre-determined conformity check on the packet, a step of transferring the packet through an overlay network to a service container determined according to a load balancing rule.

[0017] The computer program stored in the computer-readable recording medium according to the present invention for solving the above technical problem is for causing at least one processor to execute the above method.

[0018] The computing device according to the present invention for solving the above technical problem includes a processor and a memory for storing instructions or programs executable by the processor, and when the instructions or programs are executed by the processor, the above method is executed.

Effect of the Invention

[0019] According to the present invention, an XDP program executed by a network driver transfers service packets directly to a service container through an ingress container without passing through the host's kernel network stack, which is fast and resource-efficient. By referring to the IP of the packet for redirection by the XDP program, even if the service IP is used or hacked, there is no impact on the host. In addition, since the ingress container performs load balancing after performing a packet compliance check, unnecessary resources are not used in the service container. Due to the configuration of the overlay network, the communication between the ingress container and the service container is intuitive and the security is improved. Furthermore, since the container is generated in the Docker service format, it is easy to expand the security service container.

Brief Description of the Drawings

[0020]

Figure 1

Figure 2

Figure 3

Figure 4

Embodiments for Carrying Out the Invention

[0021] Next, with reference to the accompanying drawings, embodiments of the present invention will be described in detail so that those having ordinary knowledge in the technical field to which the present invention pertains can easily implement them.

[0022] The terms used in this specification are for the purpose of explaining the embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless otherwise specifically stated in the text. The terms "comprises" and / or "comprising" used in the specification do not exclude the presence or addition of one or more other components in addition to the recited components. Throughout the specification, the same reference numerals refer to the same components, and "and / or" includes each and all combinations of the recited components. Although terms such as "first", "second", etc. are used to describe various components, it goes without saying that these components are not limited by these terms. These terms are merely used to distinguish one component from another. Thus, it is of course possible that the first component referred to below may also be the second component within the technical idea of the present invention.

[0023] In this specification, the "computing device" includes all various devices that can perform arithmetic processing and provide results to the user. For example, the computing device includes not only desktop PCs, notebook computers, server computers, but also smart phones, tablet PCs, cellular phones, PCS phones (Personal Communication Service phones), synchronous / asynchronous IMT-2000 (International Mobile Telecommunication-2000) mobile terminals, Palm Personal Computers, personal digital assistants (PDAs), and the like.

[0024] Figure 3 is a diagram for explaining the configuration of a computing device according to an embodiment of the present invention.

[0025] Referring to FIG. 3, a computing device 100 according to an embodiment of the present invention is an edge (node) computing device that constitutes a cloud system.

[0026] The computing device 100 may include a container management daemon 110, an XDP management daemon 120, an XDP program 130 (eBPF (XDP) 130), a plurality of ingress containers 141, 142, and a plurality of docker services 151, 152, 153.

[0027] The container management daemon 110 and the XDP management daemon 120 can be executed in the host default namespace 170 of the computing device 100.

[0028] The XDP management daemon 120 serves to load and manage the XDP (eXpress Data Path) program 130 into the network driver of the computing device 100.

[0029] The XDP program 130 is implemented as a program type executable by the Linux (registered trademark) network driver using eBPF (extended Berkeley Packet Filter) technology, and the native mode is used in this embodiment. In the native mode, it is executable by the network driver of the computing device 100 and can process packets before the allocation of sk_buff, so that packets can be processed prior to the Linux kernel stack.

[0030] The XDP management daemon 120 can set packet transfer rules and load the XDP program 130 into the network driver. Here, the packet transfer rules are implemented in the MAP format, and the corresponding ingress containers 141, 142 are mapped for each service IP address, and the management IP address can correspond to the host.

[0031] A plurality of ingress containers 141 and 142 are each assigned a different service IP address. In FIG. 3, it is illustrated that "Service IP A" is assigned to the ingress container 141 and "Service IP B" is assigned to the ingress container 142.

[0032] The service IP address may be set in advance based on the type of service provided by the containers (container A, container B). For example, when the service provided by container A is A and the service provided by container B is B, "Service IP A" and "Service IP B" can be set respectively, and "Service IP A" and "Service IP B" can be assigned to the corresponding ingress containers 141 and 142.

[0033] The XDP program 130 checks the destination IP address of the packet that has reached the network driver, and if the destination IP address is the service IP address, it can redirect the packet to the ingress containers 141 and 142 having the corresponding service IP address. Also, if the destination IP address is the management IP address, the packet can be passed through to the host.

[0034] The container management daemon 110 functions to manage the Docker services 151, 152, and 153. The container management daemon 110 functions to generate and manage containers on the computing device 100 in the form of Docker services.

[0035] Here, the Docker service is a group of containers including a plurality of containers generated from the same image. Containers belonging to the same Docker service provide the same service. Hereinafter, in order to distinguish from the ingress container, the containers belonging to the Docker service are called service containers.

[0036] As shown in FIG. 3, a plurality of Docker services 151 and 152 that provide the same service may be generated. For example, when providing the same service to different customers, a Docker service can be generated for each customer.

[0037] The container management daemon 110 can cooperate with the Docker daemon (dockerd, Docker daemon) to generate or delete a Docker service, manage the number of service containers of the Docker service, and monitor the status of the service containers.

[0038] Specifically, when the container management daemon 110 receives data (such as customer information, edge (node) information, etc.) necessary for the generation and communication of service containers from the center 200, it can create a Docker service ID by combining the corresponding customer information and edge information, and generate a Docker service. When the service container provides a security service that detects attack traffic, the container management daemon 110 can load the policy set by the customer who provides the security service through the service container into the memory when the corresponding service container is generated, and prepare for the service.

[0039] When the service containers (container A, container B) are security service containers, these service containers can act as a proxy while inspecting packets and leaving logs according to a predetermined policy.

[0040] The customer information here can include a customer ID, a customer domain name, etc. In addition, the customer information can include information about the type of service used by the corresponding customer (for example, information for identifying security service A or security service B).

[0041] Edge information can include the country where the corresponding edge 100 is located, region information, edge number, etc. The customer information and edge information presented here are merely examples, and any information that can uniquely generate a Docker service ID generated by the computing device 100 according to the types of customers and services is sufficient.

[0042] When the ingress containers 141 and 142 receive data necessary for container generation and communication from the center 200, similar to the container management daemon 110, they query the dockerd with a Docker Service ID (Docker service ID) created by combining the corresponding customer information and edge information, receive an IP list of the containers generated corresponding to the Docker Service ID, and can cache it in memory.

[0043] The ingress containers 141 and 142 can start a health check of the containers belonging to the corresponding Docker service using the IP list of the containers and can interrupt the health check when the Docker service is deleted.

[0044] When the ingress containers 141 and 142 receive a service packet with the service IP address set as the destination from the XDP program 130, after performing a minimum set of predefined compliance checks, they can forward the packet to the corresponding Docker service through the overlay networks 161 and 162. For example, the ingress containers 141 and 142 can inspect the Host name of the HTTP header or the SNI field of the Client Hello packet used in HTTPS.

[0045] For example, when multiple Docker services 151 and 152 correspond to the ingress container 141, the ingress container 141 can check the domain name included in the service packet and transfer the packet to the Docker service with the corresponding Docker Service ID. For example, when the service packet is an HTTP packet, the domain name can be checked from the HTTP header, and the packet can be transferred to the Docker service with the Docker Service ID corresponding to the domain name. For this purpose, a MAP in which the domain name and the Docker Service ID are mapped can be prepared in advance in the memory. Also, the ingress containers 141 and 142 can transfer packets to the defined service containers according to the predefined load balancing rules. At this time, the ingress containers 141 and 142 exclude the service containers with abnormal health check results from the target of packet transfer.

[0046] The multiple ingress containers 141 and 142 can communicate with the Docker services 151, 152, and 153 that provide services corresponding to the service IP addresses assigned to them via the overlay network. That is, an overlay network 161 for communication can be independently configured between the ingress container 141 and the containers (Container A) of the Docker services 151 and 152, and an overlay network 162 for communication between the ingress container 142 and the containers (Container B) of the Docker service 153.

[0047] The center 200 manages the services provided by the cloud system. Although one center 200 is shown in FIG. 3, centers 200 may be provided for each type of service provided by the cloud system.

[0048] For example, assuming that an A security service and a B security service are provided in a cloud system, a center 200 for managing the A security service and a center 200 for managing the B security service may be provided respectively. Of course, depending on the embodiment, it is also possible to implement managing a plurality of services with one center 200.

[0049] The center 200 can provide data necessary for the generation and communication of service containers to the container management daemon 110 and the ingress containers 141, 142 of the computing device 100. For example, when the center 200 generates a service container for the A security service, it can provide data necessary for the generation and communication of the service container to the container management daemon 110 and the ingress container 141 corresponding to the A security service. Similarly, when generating a service container for the B security service, it can provide data necessary for service container generation to the container management daemon 110 and the ingress container 142 corresponding to the B security service.

[0050] FIG. 4 is a flowchart showing the order of packet processing in a computing device according to an embodiment of the present invention.

[0051] Referring to FIG. 4, first, when a packet arrives at the network driver (S410), the XDP program 130 checks the destination IP address of the packet. If the destination IP address is the service IP address (Y in S420), the packet can be redirected to the ingress containers 141, 142 assigned with the corresponding service IP address (S430).

[0052] On the other hand, if the destination IP address of the packet is the management IP address (N in S420), the XDP program 130 can pass the packet to the host (S440).

[0053] After step S430, the ingress containers 141 and 142 that have received the service packet from the XDP program 130 perform a compliance check on the packet (S450), and can transfer the packet via the overlay networks 161 and 162 to the service containers (Container A, Container B) determined according to the load balancing rules (S460). In step S460, when there are multiple Docker services corresponding to the ingress containers 141 and 142, the domain name included in the packet can be checked, and the packet can be transferred to the containers (Container A, Container B) of the corresponding Docker service.

[0054] Finally, the service containers (Container A, Container B) can process the packets transferred from the ingress containers 141 and 142 (S470). For example, in the case of a security service container, according to the pre-set policy, it can perform a proxy function while inspecting the packet and leaving a log.

[0055] The embodiments described above can be implemented as hardware components, software components, and / or combinations of hardware components and software components. For example, the devices, methods, and components described in the embodiments can be implemented using one or more general-purpose computers or special-purpose computers, such as, for example, a processor, a controller, an ALU (arithmetic logic unit), a digital signal processor, a microcomputer, an FPGA (field programmable gate array), a PLU (programmable logic unit), a microprocessor, or other predetermined devices capable of executing and responding to instructions. The processing device can execute an operating system (OS) and one or more software applications running on the operating system. Further, the processing device can also access, store, manipulate, process, and generate data in response to the execution of the software. For the sake of convenience of understanding, although the processing device may be described as being one, those skilled in the art will understand that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing device can include multiple processors or one processor and one controller. Also, other processing configurations, such as a parallel processor, are possible.

[0056] Software can include a computer program, code, instruction, or a combination of one or more of these, and can configure a processing device to operate as desired or can instruct the processing device independently or collectively. Software and / or data can be permanently or temporarily embodied in a certain type of machine, component, physical device, virtual equipment, computer storage medium or device, or signal wave being transmitted, in order to be interpreted by the processing device or to provide instructions or data to the processing device. Software can be distributed on a computer system connected by a network and stored or executed in a distributed manner. Software and data can be stored in one or more computer-readable recording media.

[0057] The method according to the embodiment can be realized in the form of program instructions that can be executed through various computer means and can be recorded on a computer-readable medium. The computer-readable medium can include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be those specially designed and configured for the embodiment or those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instructions such as ROMs, RAMs, and flash memories. Examples of program instructions include not only machine language codes such as those made by compilers but also high-level language codes that can be executed by a computer using an interpreter or the like. The above hardware device may be configured to operate as one or more software modules for performing the operations of the embodiment, and vice versa.

[0058] According to the above configuration, the XDP program 130 executed by the network driver transfers service packets directly to the service containers (Container A, Container B) through the ingress containers 141 and 142 without passing through the host's kernel network stack, so it is fast and resource-efficient. By referring to the IP of the packet for redirection by the XDP program 130, even if the service IP is used or hacked, there is no impact on the host. Also, since the ingress containers 141 and 142 perform load balancing after performing packet compliance checks, the service containers (Container A, Container B) do not use unnecessary resources. Due to the configuration of the overlay networks 161 and 162, the communication between the ingress containers 141 and 142 and the service containers (Container A, Container B) is intuitive and the security is improved. Furthermore, since the containers are generated in the Docker service format, it is easy to expand the security service containers.

[0059] As described above, the embodiments have been described with reference to the limited drawings. However, those with ordinary knowledge in the relevant technical field can apply various technical modifications and variations based on the above. For example, whether the described technology is performed in a procedure different from the described method, and / or whether the components such as the described system, structure, device, circuit, etc. are combined or combined in a form different from the described method, or replaced or substituted by other components or equivalents, appropriate results can still be achieved.

Claims

1. A computing device, including a plurality of Docker services, a plurality of ingress containers, and an XDP program loaded and executed on a network driver, wherein the plurality of Docker services include a plurality of service containers that provide the same service, wherein different service IP addresses are assigned to the plurality of ingress containers, and the different service IP addresses are predetermined for each type of service provided by the plurality of Docker services, wherein the XDP program checks a destination IP address of a packet arriving at the network driver, and transfers the packet to an ingress container to which a service IP address corresponding to the destination IP address is assigned among the plurality of ingress containers, and the ingress container to which the packet is transferred transfers the packet to a service container determined according to a predetermined load balancing rule via an overlay network. A computing device.

2. The plurality of ingress containers include a first ingress container and a second ingress container, wherein the first ingress container and the second ingress container communicate with corresponding service containers through independently configured overlay networks. The computing device according to claim 1.

3. The computing device according to claim 1, wherein when there are a plurality of Docker services corresponding to the ingress container, the packet is transferred to the Docker service corresponding to the domain name included in the packet.

4. further comprising a container management daemon and an XDP management daemon executed in a host default namespace of the computing device, wherein the XDP management daemon sets a packet transfer rule in which a service IP address corresponding to each of the plurality of ingress containers is mapped to the XDP program, and loads it into a network driver of the computing device, and the container management daemon generates and manages the plurality of service containers in the form of Docker services. The computing device according to claim 1.

5. A packet transfer method applied to a computing device, When a packet arrives at the network driver, the XDP program executed by the network driver checks the destination IP address of the packet; When the destination IP address of the packet is the service IP address, redirect the packet to the ingress container corresponding to the service IP address; After the ingress container that received the packet performs a pre-set compliance check on the packet, transfer the packet through the overlay network to the service container determined according to the load balancing rules; A packet transfer method, including the above steps.

6. In the step of redirecting the packet, If there are multiple Docker services corresponding to the ingress container, transfer the packet to the Docker service corresponding to the domain name included in the packet. The packet transfer method according to claim 5.

7. A computer program stored on a computer-readable recording medium, A computer program for causing at least one processor to execute the method according to any one of claims 5 and 6.

8. A processor; and A memory for storing instructions or programs executable by the processor; comprising When the instructions or programs are executed by the processor, the method according to any one of claims 5 and 6 is executed. A computing device.

Citation Information

Patent Citations

  • Data acquisition method, device and system based on eBPF technology

    CN114039875A

  • Multi-cluster load balancing method and device, electronic equipment and storage medium

    CN115987990A

  • Message processing method and device, electronic equipment and storage medium

    CN116781701A

  • Method for unblocking an external computer system in a computer network infrastructure, distributed computer network having such a computer network infrastructure, and computer program product

    JP2017521954A

  • Communication system, platform server, and program

    JP2019186658A