Data transmission method and device based on service grid, and electronic device
By configured kernel extension procedures in the proxy border of the service grid, network traffic data is directly sent to the target business container, which solves the problem of longer and time -consuming in the service grid. The network link is simplified.
Patent Information
- Application Number
- CN202210635793.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-07
- Publication Date
- 2025-01-24
- Estimated Expiration
- 2042-06-07
AI Technical Summary
In the prior art, the service grid intercepts and forwards the traffic of the service container through network pre-order rules, resulting in a longer network link and an increase in time.
Using a service grid-based data transmission method, network traffic data is received and pushed to the agent sidecar. The agent sidecar is pre-configured with a kernel extension program, and the network traffic data is sent to the target container scheduling unit through the kernel extension program. in the managed target business container.
It greatly reduces system resource overhead and simplifies network links, thereby solving the problem of longer and more time-consuming network links in the service grid.
Smart Images

Figure CN115022408B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of cloud computing technology, and in particular to a data transmission method and device based on a service grid, and an electronic device. Background Art
[0002] With the popularity of distributed microservices, service mesh, as an emerging distributed service architecture, uses a proxy sidecar / proxy container sidecar in the container scheduling unit to proxy the business container network traffic, thereby decoupling the business from the infrastructure and accelerating the business iteration cycle, and is widely recognized.
[0003] However, in related technologies, the proxy sidecar in each container scheduling unit will occupy a part of the system resources. In a large cluster, the accumulated resource overhead will be large and should not be underestimated. At the same time, the sidecar proxy sidecar intercepts and forwards the traffic in and out of the business container through the existing iptables rules (conditions predefined by the network administrator), which also increases the original business network call link to a certain extent.
[0004] Figure 1 is a schematic diagram of an optional distributed service architecture in the prior art, such as Figure 1 As shown in the figure, the registration center is connected to the control platform. The information of multiple K8S groups is registered to the control platform through the registration center. The control platform issues rules to the container scheduling unit pod of each K8S group (all containers in the pod share network storage resources). The container scheduling unit includes: user consumer and proxy sidecar sidecar. At the same time, the K8S group also includes various API service modules, such as Figure 1 As shown in the figure, a proxy sidecar is used in the pod to proxy the business container network traffic, thereby decoupling the business from the infrastructure.
[0005] Figure 2 This is a schematic diagram of a traffic proxy of a proxy sidecar in an optional service mesh in the prior art, such as Figure 2 As shown in the figure, the proxy sidecar intercepts the input information through the network by using iptables rules, and then forwards the information to each APP. The information of each APP will also be intercepted by the proxy sidecar and output through the proxy sidecar. Figure 2The traffic proxy method shown in the figure, the sidecar proxy sidecar intercepts and forwards the traffic in and out of the business container, and forces the traffic in and out of the pod to be redirected to the sidecar, thereby decoupling the business from the infrastructure, that is, by proxying the communication traffic, grayscale routing, monitoring, security authentication and other capabilities are realized. However, this method causes the network link to become longer, which increases the original business network call link by a lot of time, and the iptables rules are not easy to maintain.
[0006] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention
[0007] The embodiments of the present invention provide a data transmission method and device based on a service grid, and an electronic device, so as to at least solve the technical problem in the prior art that the service grid intercepts and forwards the business container traffic through network preset rules, causing the network link to become longer and the time consumption to increase.
[0008] According to one aspect of an embodiment of the present invention, a service grid-based data transmission method is provided, including: receiving network traffic data; pushing the network traffic data to a proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar; and sending the network traffic data to a target business container managed by a target container scheduling unit through the kernel extension program.
[0009] Optionally, before receiving the network traffic data, it also includes: adopting a preset interface scheduling strategy to establish a link relationship with each business container managed by the container scheduling unit; based on the link relationship, scheduling the kernel extension interface of the container kernel of the business container; based on the kernel extension interface, writing the kernel extension program corresponding to the business container.
[0010] Optionally, before receiving the network traffic data, it also includes: obtaining a namespace of each container scheduling unit; based on the namespace, determining leasing information corresponding to each of the container scheduling units, wherein the leasing information provides scheduling information and link information of the container scheduling unit; based on the leasing information, respectively setting scheduling tenants corresponding to each of the container scheduling units in the kernel extension program.
[0011] Optionally, the step of sending the network traffic data to a target business container managed by a target container scheduling unit through the kernel extension program includes: extracting business lease information from the network traffic data; determining a target scheduling tenant corresponding to the target business container based on the business lease information; and sending the network traffic data to the target business container through the target scheduling tenant and the kernel extension program.
[0012] Optionally, the service grid-based data transmission method is applied to a virtual machine, wherein the virtual machine includes multiple container scheduling units, each of the container scheduling units correspondingly manages multiple business containers, and all the business containers share the proxy sidecar.
[0013] Optionally, the service containers on the multiple virtual machines are connected to a container cluster management system, and the container cluster management system manages the multiple service containers.
[0014] According to another aspect of an embodiment of the present invention, a service grid-based data transmission device is also provided, including: a receiving unit for receiving network traffic data; a pushing unit for pushing the network traffic data to a proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar; and a transmission unit for sending the network traffic data to a target business container managed by a target container scheduling unit through the kernel extension program.
[0015] Optionally, the service grid-based data transmission device also includes: an establishment unit, which is used to establish a link relationship with each business container managed by the container scheduling unit by adopting a preset interface scheduling strategy before receiving network traffic data; a scheduling unit, which is used to schedule the kernel extension interface of the container kernel of the business container based on the link relationship; and a writing unit, which is used to write the kernel extension program corresponding to the business container based on the kernel extension interface.
[0016] Optionally, the service grid-based data transmission device also includes: a first acquisition module, used to obtain the namespace of each container scheduling unit before receiving network traffic data; a first determination module, used to determine the lease information corresponding to each of the container scheduling units based on the namespace, wherein the lease information provides scheduling information and link information of the container scheduling unit; a first setting module, used to set the scheduling tenants corresponding to each of the container scheduling units in the kernel extension program respectively based on the lease information.
[0017] Optionally, the transmission unit includes: a first extraction module, used to extract business leasing information from the network traffic data; a second determination module, used to determine the target scheduling tenant corresponding to the target business container based on the business leasing information; and a first sending module, used to send the network traffic data to the target business container through the target scheduling tenant and the kernel extension program.
[0018] Optionally, the service grid-based data transmission method is applied to a virtual machine, wherein the virtual machine includes multiple container scheduling units, each of the container scheduling units correspondingly manages multiple business containers, and all the business containers share the proxy sidecar.
[0019] Optionally, the service containers on the multiple virtual machines are connected to a container cluster management system, and the container cluster management system manages the multiple service containers.
[0020] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium is used to store a computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned service grid-based data transmission methods.
[0021] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the service grid-based data transmission methods described above.
[0022] In the present invention, the network traffic data is received and pushed to the proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar, and the network traffic data is sent to the target business container managed by the target container scheduling unit through the kernel extension program. In this embodiment, the host kernel interface can be customized through the extension interface program, and all pod network traffic on the service grid can be proxy traffic by a common proxy sidecar proxy program, which greatly reduces the system resource overhead and simplifies the network link, thereby solving the technical problem in the prior art that the service grid intercepts and forwards the business container traffic through the network predetermined rules, causing the network link to become longer and the time consumption to increase. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:
[0024] Figure 1 It is a schematic diagram of an optional distributed service architecture in the prior art;
[0025] Figure 2 This is a schematic diagram of an optional traffic proxy of a proxy sidecar in a service mesh in the prior art;
[0026] Figure 3 is a flowchart of an optional service grid-based data transmission method according to an embodiment of the present invention;
[0027] Figure 4 It is an optional forwarding flow chart after receiving traffic from a virtual machine in the prior art;
[0028] Figure 5 is a schematic diagram of traffic forwarding using a kernel extension program optionally according to an embodiment of the present invention;
[0029] Figure 6 is a schematic diagram of an optional data transmission device based on a service grid according to an embodiment of the present invention;
[0030] Figure 7 The present invention is a hardware structure block diagram of an electronic device (or mobile device) for determining a seat allocation scheme according to an embodiment of the present invention. DETAILED DESCRIPTION
[0031] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0033] To facilitate those skilled in the art to understand the present invention, some terms or nouns involved in each embodiment of the present invention are explained below:
[0034] A container is essentially a process with isolated views and limited resources.
[0035] K8s cluster is the abbreviation of Kubernetes cluster, which includes multiple business types, such as long-running, batch, node-daemon and stateful application.
[0036] The container scheduling unit, Pod, is the smallest unit for running and deploying applications or services in a K8s cluster. Different Pods need to be deployed for different business types. It can support multiple containers and support multiple containers sharing network addresses and file systems in one Pod. Services can be combined in a simple and efficient way through inter-process communication and file sharing.
[0037] The proxy sidecar / proxy container, Sidecar, is deployed in each Pod in the existing technology. By deploying a container that connects to an external service cluster, the Pod can access an external system or external service.
[0038] Service Mesh is an infrastructure layer that specializes in handling service communications, and implements reliable request transmission under the complex topology of application services. The internal structure may include but is not limited to: a group of lightweight network proxies deployed together with application services, and transparent to application services. Among them, the service mesh is relatively simple in terms of overall architecture. It is composed of a bunch of user agents next to each service, plus a group of task management components. The management component is called the control platform or control plane, which is responsible for communicating with the agents in the control plane and issuing policies and configurations. The agent is called the data layer or data plane in the service mesh, which directly handles inbound and outbound data packets, forwarding, routing, health checks, load balancing, authentication, authorization, and generating monitoring data.
[0039] The above service grid can achieve the following functions: First, decoupling microservice governance from business logic. The service grid separates most of the capabilities in the software installation package SDK from the application, disassembles them into independent processes, and deploys them in the sidecar mode. The service grid completely decouples service communication and related control functions from business programs and sinks them to the infrastructure layer, allowing developers to focus more on the business itself. Second, unified governance of heterogeneous systems. With the development of new technologies and personnel changes, applications and services in different languages and frameworks often appear in the same company. In order to be able to uniformly control these services, the service governance capabilities of the subject are sunk to the infrastructure to achieve multi-language support operations.
[0040] It should be noted that the service grid-based data transmission method and device thereof in the present disclosure can be used in the field of cloud computing when data information is transmitted, and can also be used in any field other than the field of cloud computing when data information is transmitted. The present disclosure does not limit the application field of the service grid-based data transmission method and device thereof.
[0041] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set between this system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or organization.
[0042] The following embodiments of the present invention can be applied to distributed microservice scenarios, especially service grid scenarios, and can realize data transmission. In the service grid scenario, the function of tenant sharing proxy sidecar represented by multiple business containers is realized. For all container scheduling units pod indicated on a virtual machine node, a public proxy sidecar proxy program is used to proxy the traffic of all pod network traffic on the node through a custom extension interface program of the host kernel interface, which greatly reduces system resource overhead and simplifies network links.
[0043] The present invention is described in detail below in conjunction with various embodiments.
[0044] Embodiment 1
[0045] According to an embodiment of the present invention, an embodiment of a data transmission method based on a service grid is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0046] Figure 3 is a flowchart of an optional service grid-based data transmission method according to an embodiment of the present invention, such as Figure 3 As shown, the method comprises the following steps:
[0047] Step S301, receiving network traffic data;
[0048] Step S302, pushing the network traffic data to the proxy sidecar, wherein the proxy sidecar is pre-configured with a kernel extension program;
[0049] Step S303: Send the network traffic data to the target service container managed by the target container scheduling unit through the kernel extension program.
[0050] Through the above steps, network traffic data can be received and pushed to the proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar, and the network traffic data is sent to the target business container managed by the target container scheduling unit through the kernel extension program. In this embodiment, the host kernel interface can be customized through the extension interface program, and all pod network traffic on the service grid can be proxied by a common proxy sidecar proxy program, which greatly reduces the system resource overhead and simplifies the network link, thereby solving the technical problem in the prior art that the service grid intercepts and forwards the business container traffic through the network predetermined rules, causing the network link to become longer and the time consumption to increase.
[0051] To facilitate the description of the embodiments of the present invention and to conduct comparative analysis, the service traffic forwarding process in the prior art is first described.
[0052] Figure 4 It is an optional forwarding flow chart after receiving traffic from a virtual machine in the prior art, such as Figure 4 As shown in the figure, after the original service grid virtual machine Node receives the traffic, it will go through the virtual machine network rules (including Figure 4 The Ethernet interface on the left is mapped to the TCP / IP address, and then transmitted to the Pod of the application APP through the Ethernet interface and the virtual network card interface Veth), and then sent to the pod through veth (in the Pod, it will pass through the Ethernet interface, TCP / IP address mapping, and socket to reach the APP. After the APP runs, it will pass through the socket, TCP / IP address mapping, and Ethernet interface again, and finally through the software port, and then flow through the Ethernet interface, TCP / IP address mapping, and socket of the network layer to reach the proxy sidecar Sidecar).
[0053] It can be seen from the above-mentioned prior art records that the existing network iptables intercepts and forwards business container traffic. Traffic interception needs to go through multiple processes such as virtual network card interface veth, eth, tcp / ip, and redirect to Sidecar. Then, Sidecar sends it to App and it has to go through the above traffic again, which makes the network link complicated and time-consuming.
[0054] The network forwarding process of this embodiment is described below.
[0055] The embodiments of the present invention are described in detail below in combination with the above-mentioned implementation steps.
[0056] Optionally, a service mesh-based data transmission method is applied to a virtual machine node. The virtual machine includes multiple container scheduling units Pods. Each container scheduling unit manages multiple business containers. All business containers share a proxy sidecar Sidecar.
[0057] Optionally, the business containers on the multiple virtual machines are connected to a container cluster management system, and the container cluster management system manages the multiple business containers.
[0058] Optionally, before receiving network traffic data, it also includes: using a preset interface scheduling strategy to establish a link relationship with the business container managed by each container scheduling unit; based on the link relationship, scheduling the kernel extension interface of the container kernel of the business container; based on the kernel extension interface, writing a kernel extension program corresponding to the business container.
[0059] It should be noted that the kernel extension interface may include but is not limited to a BPF (Berkeley Packet Filter, BPF for short) interface. The bpf interface may refer to a Berkeley packet filter, which is a primitive interface of the data link layer on a Unix-like system, providing transmission and reception of primitive link layer packets.
[0060] In this embodiment, the kernel extension interface is used to write a program to expand the kernel capabilities. After the virtual machine node receives the network traffic, it flows through the sidecar program and is directly sent to the corresponding container of the business Pod through the kernel extension program, reducing the network steps.
[0061] Another optional method, before receiving the network traffic data, also includes: obtaining the namespace of each container scheduling unit; based on the namespace, determining the lease information corresponding to each container scheduling unit, wherein the lease information provides the scheduling information and link information of the container scheduling unit; based on the lease information, setting the scheduling tenant corresponding to each container scheduling unit in the kernel extension program respectively.
[0062] Since all business containers on the virtual machine share a sidecar agent, each tenant is set in the agent to correspond to each business program pod according to the namespace of the business pod to achieve sharing. That is, based on the lease information, the scheduling tenant corresponding to each container scheduling unit can be set in the kernel extension program, and then during use, the tenant information of the scheduling tenant can be used to share the use of the agent sidecar.
[0063] It should be noted that the leasing information is used to distinguish the various container scheduling units, Pods, because all Pods share a proxy sidecar Sidecar. At this time, if traffic is forwarded through the proxy sidecar Sidecar, it is necessary to distinguish the forwarded traffic. In this embodiment, tenants are distinguished through namespaces so that each business pod can share a sidecar program, thereby realizing multi-tenant sharing of the proxy sidecar Sidecar in the service grid scenario.
[0064] After completing the kernel extension program writing and tenant registration, the actual traffic forwarding process is described below.
[0065] Step S301, receiving network traffic data.
[0066] The network traffic data may refer to traffic data transmitted by an external service application and received by the virtual machine. The specific type of traffic data and the size of the transmission data are not specifically limited in this embodiment and are adjusted according to the data usage method used by each distributed storage cluster.
[0067] Step S302: Push the network traffic data to the proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar.
[0068] In this embodiment, the kernel capability can be dynamically expanded based on the operating system interface, and the traffic of all pods on the virtual machine node at the L3-L7 layer (mainly the network layer, including the virtual network card interface, Ethernet interface, TCP / IP address mapping, and socket) can be directly directed to the shared sidecar on the virtual machine node through the kernel capability, thereby greatly reducing system resource consumption and network links.
[0069] Step S303: Send the network traffic data to the target service container managed by the target container scheduling unit through the kernel extension program.
[0070] Optionally, the step of sending the network traffic data to the target business container managed by the target container scheduling unit through the kernel extension program includes: extracting the business lease information in the network traffic data; determining the target scheduling tenant corresponding to the target business container based on the business lease information; and sending the network traffic data to the target business container through the target scheduling tenant and the kernel extension program.
[0071] Figure 5 FIG. 1 is a schematic diagram of traffic forwarding using a kernel extension program according to an optional embodiment of the present invention. Figure 5As shown in the figure, after the virtual machine node receives the network traffic, it flows through the sidecar program, that is, after the socket is parsed by the kernel extension program, it is directly sent to the business Pod ( Figure 5 The app container (shown as APP Pod in the figure) is relative to Figure 4 The illustrated traffic transmission process greatly reduces the network steps and enables all pods on the virtual machine node to share a sidecar program, reducing system resource overhead.
[0072] like Figure 5 As shown in the figure, the traffic of all pods on the virtual machine node at the L3-L7 layer is directly directed to the shared sidecar on the virtual machine node through the kernel capability, thereby greatly reducing system resource consumption and network links.
[0073] Through the above embodiments, a solution for multiple pod tenants to share a proxy sidecar in a service grid scenario can be implemented, which solves the problem that each pod in the service grid needs to start a separate sidecar proxy, resulting in a waste of system resources and an increase in the complexity and time-consuming of network links. By expanding the kernel interface, the complexity of iptables redirection network links is reduced and the network time consumption is reduced.
[0074] The present invention is described below in conjunction with another optional embodiment.
[0075] Embodiment 2
[0076] An embodiment of the present invention provides a data transmission device based on a service grid, and each implementation unit included in the data transmission device corresponds to each implementation step in the above-mentioned embodiment one.
[0077] Figure 6 is a schematic diagram of an optional data transmission device based on a service grid according to an embodiment of the present invention, such as Figure 6 As shown, the data transmission device may include: a receiving unit 61, a pushing unit 62, and a transmission unit 63, wherein:
[0078] A receiving unit 61, configured to receive network traffic data;
[0079] A push unit 62, configured to push the network traffic data to the proxy sidecar, wherein the proxy sidecar is pre-configured with a kernel extension program;
[0080] The transmission unit 63 is used to send the network traffic data to the target service container managed by the target container scheduling unit through the kernel extension program.
[0081] In the above steps, the network traffic data can be received by the receiving unit 61, and the network traffic data can be pushed to the proxy sidecar by the pushing unit 62, wherein the proxy sidecar is pre-configured with a kernel extension program, and the network traffic data can be sent to the target business container managed by the target container scheduling unit through the kernel extension program by the transmission unit 63. In this embodiment, the host kernel interface can be customized through the extension interface program, and all pod network traffic on the service grid can be proxied by a common proxy sidecar proxy program, which greatly reduces the system resource overhead and simplifies the network link, thereby solving the technical problem in the prior art that the service grid intercepts and forwards the business container traffic through the network predetermined rules, causing the network link to become longer and the time consumption to increase.
[0082] Optionally, the service grid-based data transmission device also includes: an establishment unit, which is used to establish a link relationship with the business container managed by each container scheduling unit by adopting a preset interface scheduling strategy before receiving network traffic data; a scheduling unit, which is used to schedule the kernel extension interface of the container kernel of the business container based on the link relationship; and a writing unit, which is used to write a kernel extension program corresponding to the business container based on the kernel extension interface.
[0083] Optionally, the service grid-based data transmission device also includes: a first acquisition module, used to obtain the namespace of each container scheduling unit before receiving network traffic data; a first determination module, used to determine the lease information corresponding to each container scheduling unit based on the namespace, wherein the lease information provides scheduling information and link information of the container scheduling unit; a first setting module, used to set the scheduling tenants corresponding to each container scheduling unit in the kernel extension program respectively based on the lease information.
[0084] Optionally, the transmission unit includes: a first extraction module, used to extract business leasing information from network traffic data; a second determination module, used to determine the target scheduling tenant corresponding to the target business container based on the business leasing information; and a first sending module, used to send the network traffic data to the target business container through the target scheduling tenant and the kernel extension program.
[0085] Optionally, a service grid-based data transmission method is applied to a virtual machine, which includes multiple container scheduling units, each of which manages multiple business containers, and all business containers share a proxy sidecar.
[0086] Optionally, the business containers on the multiple virtual machines are connected to a container cluster management system, and the container cluster management system manages the multiple business containers.
[0087] The above-mentioned service grid-based data transmission device may also include a processor and a memory. The above-mentioned receiving unit 61, push unit 62, transmission unit 63, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to implement corresponding functions.
[0088] The processor includes a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be set, and the kernel parameters are adjusted to extend the kernel program to send network traffic data to the target service container managed by the target container scheduling unit.
[0089] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.
[0090] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, which is used to store a computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned service grid-based data transmission methods.
[0091] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement any one of the above-mentioned service grid-based data transmission methods.
[0092] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the following method steps: receiving network traffic data; pushing the network traffic data to a proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar; and sending the network traffic data to a target business container managed by a target container scheduling unit through the kernel extension program.
[0093] Figure 7 1 is a hardware structure block diagram of an electronic device (or mobile device) for determining a seat allocation scheme according to an embodiment of the present invention. Figure 7As shown, the electronic device may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 7 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 7 More or fewer components as shown, or with Figure 7 The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages and disadvantages of the embodiments.
[0094] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.
[0095] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0096] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0097] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0098] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0099] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.
[0100] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.
Claims
1. A data transmission method based on a service grid, characterized in that: Applied to a virtual machine, the virtual machine includes multiple container scheduling units, each of which manages multiple business containers, and all the business containers share a proxy sidecar, including: Obtain a namespace of each container scheduling unit; based on the namespace, determine leasing information corresponding to each container scheduling unit, wherein the leasing information provides scheduling information and link information of the container scheduling unit; based on the leasing information, respectively set scheduling tenants corresponding to each container scheduling unit in the kernel extension program; Receive network traffic data; Pushing the network traffic data to a proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar; The network traffic data is sent to a target business container managed by a target container scheduling unit through the kernel extension program, including: performing socket parsing through the kernel extension program to extract business lease information in the network traffic data; determining a target scheduling tenant corresponding to the target business container based on the business lease information; and sending the network traffic data to the target business container through the target scheduling tenant and the kernel extension program.
2. The data transmission method according to claim 1, characterized in that: Before receiving network traffic data, it also includes: Adopting the preset interface scheduling strategy, establishing a link relationship with the business container managed by each container scheduling unit; Based on the link relationship, scheduling a kernel extension interface of a container kernel of the service container; Based on the kernel extension interface, the kernel extension program corresponding to the business container is written.
3. The data transmission method according to claim 1, characterized in that: The service containers on the multiple virtual machines are connected to a container cluster management system, and the container cluster management system manages the multiple service containers.
4. A data transmission device based on a service grid, characterized in that: Applied to a virtual machine, the virtual machine includes multiple container scheduling units, each of which manages multiple business containers, and all the business containers share a proxy sidecar, including: A receiving unit, used for receiving network traffic data; A pushing unit, configured to push the network traffic data to a proxy sidecar, wherein a kernel extension program is pre-configured in the proxy sidecar; A transmission unit, used to send the network traffic data to a target business container managed by a target container scheduling unit through the kernel extension program, the transmission unit comprising: a first extraction module, used to perform socket parsing through the kernel extension program to extract business lease information from the network traffic data; a second determination module, used to determine a target scheduling tenant corresponding to the target business container based on the business lease information; a first sending module, used to send the network traffic data to the target business container through the target scheduling tenant and the kernel extension program; The service grid-based data transmission device also includes: a first acquisition module, used to obtain the namespace of each container scheduling unit before receiving network traffic data; a first determination module, used to determine the lease information corresponding to each of the container scheduling units based on the namespace, wherein the lease information provides the scheduling information and link information of the container scheduling unit; a first setting module, used to set the scheduling tenants corresponding to each of the container scheduling units in the kernel extension program respectively based on the lease information.
5. The data transmission device according to claim 4, characterized in that: Also includes: An establishing unit, used to establish a link relationship with each service container managed by the container scheduling unit by using a preset interface scheduling strategy before receiving the network traffic data; A scheduling unit, configured to schedule a kernel extension interface of a container kernel of the service container based on the link relationship; A writing unit is used to write the kernel extension program corresponding to the business container based on the kernel extension interface.
6. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the service grid-based data transmission method according to any one of claims 1 to 3.
7. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the service grid-based data transmission method as described in any one of claims 1 to 3.