A lossless scaling method based on eBPF

Abstract

The present invention discloses a lossless capacity reduction method based on eBPF, which relates to the technical field of cloud computing of emerging information technology, and comprises the following steps: injecting a service into a container in a Sidecar manner to detect whether the container is in a busy state of processing user requests; when HPA needs to reduce capacity, the HPA controller first calls the Sidecar service in the container to determine whether the container is in an idle state, and if the container is in an idle state, puts the container into a deletable set; if the container is in a busy state, puts the container into a non-deletable set; the HPA controller traverses the deletable set, updates the deletionTimestamp field of the container in the deletable set, and updates the number of copies of the container, so as to realize the elegant deletion of the container. The present invention solves the problem that the HAP randomly offlines (or reduces capacity) containers in an inelegant manner during the reduction process, thereby causing business interruption.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology of emerging information technology, and in particular to a lossless scaling method based on eBPF. Background Art

[0002] As Kubernetes (hereinafter referred to as k8s) has become the de facto standard for container orchestration platforms and is recognized by CNCF and the industry as the ecological hub of the cloud native field. Building a stable and reliable edge computing platform around k8s is becoming more and more important. Although it is increasingly being applied to production, some problems with k8s standard components have also been found in practice. For example, k8s has a core elastic scaling capability embedded in it. This component is referred to as HPA (Horizontal Pod Autoscaler) in k8s, which can realize horizontal automatic expansion and contraction of containers. It can automatically increase and decrease the number of containers on demand according to the business operation status. For example, during a promotion, the user traffic is very large, resulting in an increase in business load. At this time, HPA can automatically increase the number of containers horizontally. After the promotion, the user traffic decreases, and the business load decreases. At this time, HPA will also automatically reduce the number of containers horizontally. This is a fully automated and elastic process. On the one hand, it solves the problem that enterprises need to deploy many containers under high traffic and high concurrency. On the other hand, it improves resource utilization, saves server costs, and realizes on-demand allocation, meeting the demands of enterprises to reduce costs and increase efficiency. Therefore, it has been unanimously loved by enterprises.

[0003] However, HPA also exposed some problems that need to be solved in practice. The most typical problem is that during the scaling-down process, HAP will randomly select several containers to be offline without considering whether there are any requests that have not been processed on the container. This inelegant and rough way of offline containers will cause business interruption and affect user experience. Therefore, in the HPA scaling-down scenario, a more elegant, refined and lossless way to offline containers is needed. Summary of the invention

[0004] The purpose of the present invention is to provide a lossless scaling method based on eBPF to solve the technical problem in the prior art that HAP in the scaling process randomly offlines (or scales down) containers in an inelegant manner, thereby causing service interruption.

[0005] The present invention provides a lossless capacity reduction method based on eBPF, comprising the following steps:

[0006] S100, inject a service into the container in the form of Sidecar to detect whether the container is busy processing user requests;

[0007] S200. When the HPA needs to be scaled down, the HPA controller first calls the Sidecar service in the container to determine whether the container is in an idle state. If the container is in an idle state, the container is placed in a deletable set; if the container is in a busy state, the container is placed in a non-deletable set.

[0008] S300. The HPA controller traverses the deletable set, updates the deletionTimestamp field of the container in the deletable set, and updates the number of replicas of the container, so as to achieve graceful deletion of the container.

[0009] Further, in S100, detecting whether the container is in a busy state of processing a user request specifically includes:

[0010] In Sidecar, the kernel object (struct__sk_buff*skb) is parsed in eBPF mode, and the three-layer IP information, four-layer TCP information, and seven-layer http information contained in the skb object are parsed. The parsed information is constructed into a hash table to record each request and response. The hash table is used to detect whether the container is busy processing user requests.

[0011] Furthermore, the core logic of parsing skb in eBPF mode is as follows:

[0012] Load a bpf program of type SOCKET_FILTER into the BPF virtual machine;

[0013] Attach a raw_socket to the bpf object and bind it to the eth0 port in the container.

[0014] Parse the skb (struct__sk_buff*skb) object in the Linux kernel and extract the three-layer IP information, the four-layer TCP information, and the seven-layer http information;

[0015] The parsed data is passed from kernel space to user space through the built-in map of BPF, the map is processed in user space, and an HTTP service is started for the HPA controller to call to obtain whether the container is busy.

[0016] Furthermore, the parsed information is constructed into a hash table, specifically including: using the IP address, protocol type, and port as the hash key, and using request and response as the hash value, to record the request information.

[0017] Furthermore, the hash table is used to detect whether the container is in a busy state of processing user requests. Specifically, when a request message is received, the value corresponding to the key is increased by 1, and when a corresponding response message is received, the value corresponding to the key is decreased by 1. At the same time, an http service is started and provided to the HPA controller for calling to obtain whether the container is in a busy state; if the value is 0, it means that the container is in an idle state, and if it is greater than 0, it means that the container is in a busy state.

[0018] Compared with the prior art, the beneficial effects of the present invention are:

[0019] (1) It is injected into the container in the form of Sidecar and exists transparently, making it invisible to users.

[0020] The Sidecar design pattern is one of the best practices in the cloud-native field. It is dynamically injected during the container operation process, is non-invasive, highly flexible, and exists in a transparent manner, which is not perceived by users.

[0021] (2) Implemented in Sidecar based on eBPF, with high efficiency and high speed;

[0022] In order to detect whether the container is busy, it is not implemented in user mode but in kernel mode.

[0023] There are two advantages: first, the Sidecar service itself requires the lowest possible overhead and must not affect the main service; second, it must be as efficient and fast as possible. eBPF meets these two requirements. ebf processes objects in the kernel, reducing the switching overhead from kernel state to user state. At the same time, it directly processes skb objects, which is the most efficient.

[0024] (3) Solve the problem of business interruption caused by random container reduction during HAP scaling;

[0025] Before reducing (or shutting down) a container, it is first determined whether the container is in an idle state. That is, the container is shut down only when there are no requests to be processed on the container. This will definitely not affect the business, and an elegant shutdown of the container is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0027] Figure 1 A flow chart of reducing the capacity of an HPA controller provided in an embodiment of the present invention;

[0028] Figure 2 A flow chart of Sidecar detection provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments.

[0030] The components of the embodiments of the present invention generally described and shown in the drawings herein may be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention.

[0031] Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative work shall fall within the scope of protection of the present invention.

[0032] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0033] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0034] In the prior art, since the number of containers will be reduced when the HPA is scaled down, it is necessary to determine whether there are still clients communicating with the container before taking the container offline. If there are still clients communicating with it, the container cannot be taken offline immediately, otherwise, the container can be taken offline. Specifically, if each request in the container has a corresponding response, it means that there are no requests being processed in the container and it is in an idle state, then the container can be taken offline; anyway, if there is no correspondence, it means that the container has received the request but has not received a response, which means that the container is busy and is processing user requests. The container cannot be taken offline. If it is forced to go offline, it will cause user business interruption, request processing failure, and a bad user experience.

[0035] Based on the above problems, an embodiment of the present invention provides a lossless scaling method based on eBPF, which can solve the problem of service interruption during HPA scaling in a more elegant way.

[0036] Specifically, Figure 1 As shown in the figure, a service is injected into the container in the form of a sidecar to detect whether the container is in a busy state processing user requests. When the HPA needs to shrink, the HPA controller first calls the Sidecar service in the container to determine whether the container is in an idle state. If the container is in an idle state, the container is placed in a deletable set; otherwise, the container is placed in an undeletable set. Then the HPA controller traverses the deletable set, updates the deletionTimestamp field of the container in the deletable set, and updates the number of copies of the container, thereby achieving elegant deletion of the container. A key technical point here is how to detect whether the container is in a busy state? The solution is to parse the kernel object (struct__sk_buff*skb) in the Sidecar in the eBPF mode, parse the three-layer IP information, four-layer TCP information, and seven-layer http information contained in the skb object, and thus build a hash table to record each request and response.

[0037] Among them, Sidear means that when the user creates a container (yaml), the webhook module of the k8s apisever will intercept the object and then inject a new module called Sidear into the container.

[0038] The core logic of eBPF parsing skb is as follows:

[0039] First, load a bpf program of type SOCKET_FILTER into the BPF virtual machine.

[0040] Then, attach a raw_socket to the bpf object and bind it to the eth0 port in the container.

[0041] Then parse the skb (struct__sk_buff*skb) object in the Linux kernel and extract the three-layer IP information, the four-layer TCP information, and the seven-layer http information.

[0042] The parsed data is transferred from kernel space to user space through BPF's built-in map for further processing, statistics, and display.

[0043] Finally, the request information is recorded in the form of IP address, protocol type, and port as the hash key, and request and response as the hash value. When the request information is received, the value corresponding to the key is increased by 1, and when the corresponding response information is received, the value corresponding to the key is decreased by 1. At the same time, an HTTP service is started and provided to the hap controller to obtain whether the container is busy; if the value is 0, it means that the container is idle, and if it is greater than 0, it means that the container is busy.

[0044] Based on the above hash table, it is easy to detect whether each container is busy processing user requests, so that the HPA controller can put the container into the deletable set or the non-deletable set based on this information, so as to make the best choice and realize the graceful offline of the container.

[0045] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A lossless scaling method based on eBPF, characterized in that: The steps include: S100, inject a service into the container in the form of Sidecar to detect whether the container is busy processing user requests; S200. When the HPA needs to be scaled down, the HPA controller first calls the Sidecar service in the container to determine whether the container is in an idle state. If the container is in an idle state, the container is placed in a deletable set; if the container is in a busy state, the container is placed in a non-deletable set. S300, traversing the deletable set through the HPA controller, updating the deletionTimestamp field of the container in the deletable set and updating the number of copies of the container, so as to achieve graceful deletion of the container; In S100, detecting whether the container is in a busy state of processing a user request specifically includes: In Sidecar, the kernel object is parsed in eBPF mode. The three-layer IP information, four-layer TCP information, and seven-layer HTTP information contained in the skb object are parsed. The parsed information is constructed into a hash table to record each request and response. The hash table is used to detect whether the container is busy processing user requests. The core logic of parsing skb in eBPF mode includes: Load a bpf program of type SOCKET_FILTER into the BPF virtual machine; Attach a raw_socket to the bpf object and bind it to the eth0 port in the container; Parse the skb object in the Linux kernel and extract the three-layer IP information, the four-layer TCP information, and the seven-layer http information; The parsed data is transferred from the kernel space to the user space through the built-in map of BPF. The map is processed in the user space, and an HTTP service is started to provide it to the HPA controller for calling to obtain whether the container is in a busy state. Constructing the parsed information into a hash table specifically includes: using the IP address, protocol type, and port as the hash key, and using request and response as the hash value to record the request information; Detecting whether the container is in a busy state of processing user requests through a hash table specifically includes: when a request message is received, the value corresponding to the key is increased by 1, and when the corresponding response message is received, the value corresponding to the key is decreased by 1; if the value is 0, it means that the container is in an idle state, and if it is greater than 0, it means that the container is in a busy state.

Images