Data transmission method, device and system based on kubernetes cluster

Abstract

The invention relates to the technical field of kubernetes cluster networks, and discloses a data transmission method, device and system based on a kubernetes cluster. Transmitting data to a destination address in response to a service Pod of a tenant identifier corresponding to a custom gateway policy definition, and if a data identifier exists in a custom routing policy of the service Pod, associating the data and the data identifier; and controlling the data associated with the data identifier to be transmitted to a main gateway Pod according to a routing path indicated by a user-defined routing policy, so that the main gateway Pod transmits the data to a destination address according to an exit bandwidth upper limit corresponding to the configured data identifier. The routing path indicates that the data associated with the data identifier is transmitted to the main gateway Pod through a first virtual tunnel interface in the service Pod and a second virtual tunnel interface in the main gateway Pod; the tenant-level exit bandwidth limitation can be realized, the cluster operation and maintenance complexity is reduced, and the cluster resource utilization rate and the tenant service quality are improved.

Description

Technical Field

[0001] This disclosure relates to the field of Kubernetes cluster network technology, and in particular to a data transmission method, apparatus and system based on Kubernetes cluster. Background Technology

[0002] Kubernetes (K8s) is an open-source container orchestration platform used to automatically deploy, scale, and manage containerized (Pod) applications across nodes. In a Kubernetes cluster, hundreds or thousands of microservice instances running as Pods need to frequently interact with external networks (such as the internet, enterprise data centers, or other cloud services). To improve interaction security and ensure service quality, exit control of the cluster becomes crucial.

[0003] Currently, methods for controlling outbound traffic to a cluster include: relying on the Container Network Interface (CNI) plugin in the Kubernetes cluster to centrally manage all container traffic accessing the external network, implementing policy-based routing and fixed Internet Protocol (IP) management. For example, CNI plugins such as Cilium utilize Extended Berkeley Packet Filter (eBPF) technology to force outbound traffic to a designated gateway node, ensuring that the source IP address perceived by external services is fixed, thereby simplifying firewall rule configuration and enhancing traceability. Furthermore, service mesh frameworks such as Istio's Egress Gateway can combine mTLS encryption and circuit breaking mechanisms to implement dynamic policy control on outbound traffic, preventing unauthorized access and traffic overload. In addition, in Internet Protocol version 6 (IPv6) networks, cloud vendors also use egress-only internet gateways to achieve unidirectional outbound traffic isolation, allowing only cluster-initiated access to the external network while prohibiting external initiation of connections, thereby enhancing security.

[0004] However, current cluster network egress control methods mainly rely on node or device-level bandwidth management, such as Quality of Service (QoS) policies or hardware rate limiting. This not only makes Kubernetes cluster operation and maintenance complex, but also, when multiple tenants share the same node or device, node-level or device-level bandwidth limitations can easily lead to resource contention, poor resource utilization, and an inability to guarantee the overall service quality of tenants in the cluster. Summary of the Invention

[0005] In view of this, this disclosure proposes a data transmission method, apparatus and system based on a Kubernetes cluster, which can realize fine-grained egress bandwidth limiting at the tenant level, reduce the operation and maintenance complexity of the Kubernetes cluster, improve the resource utilization of the Kubernetes cluster, and ensure the overall service quality of tenants in the Kubernetes cluster from both performance and security perspectives.

[0006] According to one aspect of this disclosure, a data transmission method based on a Kubernetes cluster is provided, applied to business Pods, the method comprising:

[0007] In response to a service Pod corresponding to a tenant identifier defined by a custom gateway policy transmitting data to a destination address, if a data identifier exists in the custom routing policy of the service Pod, the data and the data identifier are associated.

[0008] The data after the associated data identifier is transmitted to the main gateway Pod according to the routing path indicated by the custom routing policy, so that the main gateway Pod transmits the data to the destination address according to the configured egress bandwidth limit corresponding to the data identifier. The routing path indicated by the custom routing policy indicates that the data after the associated data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod.

[0009] The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

[0010] In one possible implementation, the custom gateway policy further configures the target network segment for which the tenant needs to limit egress bandwidth, so as to configure the correspondence between the target network segment and the data identifier in the custom routing policy and the correspondence between the data identifier and the egress bandwidth limit in the main gateway Pod. Associating the data and the data identifier includes:

[0011] If a data identifier corresponding to the target network segment exists in the custom routing policy of the service Pod and the destination address belongs to the target network segment, then associate the data with the data identifier.

[0012] In one possible implementation, the method further includes:

[0013] If there is no correspondence between the target network segment and the data identifier in the custom routing policy of the service Pod, or if the destination address does not belong to the target network segment, the data is transmitted to the destination address based on the routing path indicated by the default routing policy. The routing path indicated by the default routing policy means that the data is transmitted to the main gateway Pod through the first virtual Ethernet interface and the second virtual Ethernet interface in the service Pod, but not through the first virtual tunnel interface and the second virtual tunnel interface.

[0014] In one possible implementation, the method further includes:

[0015] Obtain the Maximum Segment Size (MSS) value of the service Pod and the Final Maximum Transmission Unit (MTU) value of the second virtual tunnel interface in the service Pod; wherein, the final MTU value is determined based on the minimum of the first MTU value of the first virtual tunnel interface in the service Pod and the second MTU value of the second virtual tunnel interface in the main gateway Pod; the first MTU value is configured based on the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod and the number of bytes of the encapsulated packet header corresponding to the first virtual tunnel interface, the first MTU value is negatively correlated with the number of bytes of the encapsulated packet header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface; the second MTU value is configured based on the MTU value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the main gateway Pod and the number of bytes of the encapsulated packet header corresponding to the second virtual tunnel interface, the second MTU value is negatively correlated with the number of bytes of the encapsulated packet header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface; the MSS value is configured based on the final MTU value, the number of bytes of the IP header, and the number of bytes of the TCP header;

[0016] The association of the data and the data identifier includes: when the data volume is greater than the MSS value, segmenting and encapsulating the data according to the MSS value to obtain segmented and encapsulated data; setting the data identifier for the segmented and encapsulated data to obtain the data associated with the data identifier;

[0017] And / or,

[0018] The transmission of the data after the control association data identifier to the main gateway Pod according to the routing path indicated by the custom routing policy includes: when the data volume of the data after the association data identifier is greater than the final MTU value of the service Pod, the data after the association data identifier is segmented and encapsulated according to the final MTU value and then transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface.

[0019] According to another aspect of this disclosure, a data transmission method based on a Kubernetes cluster is provided, applied to a main gateway Pod, the method comprising:

[0020] In response to receiving data with associated data identifier transmitted from a service Pod with a tenant identifier corresponding to a custom gateway policy definition via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod, the data is transmitted to the destination address according to the egress bandwidth limit corresponding to the data identifier pre-configured in the main gateway Pod;

[0021] The data after the associated data identifier is obtained by the service Pod in response to transmitting data to the destination address, by associating the data with the data identifier in the service Pod's custom routing policy;

[0022] The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

[0023] In one possible implementation, the custom gateway policy is further configured with the target network segment for which the tenant needs to limit the outbound bandwidth, so as to configure the correspondence between the target network segment and the data identifier in the custom routing policy and configure the correspondence between the data identifier, the target network segment and the outbound bandwidth limit in the main gateway Pod, wherein the destination address belongs to the target network segment.

[0024] According to another aspect of this disclosure, a data transfer method for a Kubernetes cluster is provided, executed by a node controller, the method comprising:

[0025] Obtain the custom gateway policy configured in the Kubernetes cluster. The custom gateway policy includes: the tenant identifier of the tenant whose outbound bandwidth needs to be restricted, the outbound bandwidth limit corresponding to the tenant identifier, and the relevant information of the gateway Pod, wherein the gateway Pod includes at least the main gateway Pod.

[0026] Configure the first virtual tunnel interface in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy;

[0027] Configure a second virtual tunnel interface in the gateway Pod according to the relevant information of the gateway Pod indicated by the custom gateway policy;

[0028] According to the custom gateway policy, a custom routing policy is configured in the service Pod, including: generating a data identifier for the service Pod, associating the data identifier with data transmitted by the service Pod to a destination address, and generating a routing path to indicate that the data associated with the data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface;

[0029] Configure the correspondence between the data identifier and the egress bandwidth limit in the gateway Pod to instruct the gateway Pod to transmit the data associated with the data identifier to the destination address according to the egress bandwidth limit.

[0030] In one possible implementation, the custom gateway policy further includes: the tenant needs to restrict the target network segment for outbound bandwidth;

[0031] Configuring a custom routing policy in the service Pod also includes:

[0032] Configure the mapping relationship between the target network segment and the data identifier in the service Pod, so as to associate the data and the data identifier when the destination address of the data belongs to the target network segment.

[0033] In one possible implementation, the gateway Pod further includes a backup gateway Pod other than the primary gateway Pod, and the relevant information of the gateway Pod includes primary gateway indication information; the primary gateway indication information is used to indicate the current primary gateway Pod in the gateway Pod.

[0034] The method further includes:

[0035] When the gateway status of the primary gateway Pod indicates that the primary gateway Pod is in an unavailable state, a primary gateway change instruction is sent to the gateway controller. The primary gateway change instruction is used to trigger the gateway controller to switch the standby gateway Pod, which is in an available state, to the new primary gateway Pod, and update the primary gateway indication information so that the primary gateway indication information indicates that the new primary gateway Pod is the current primary gateway Pod.

[0036] In response to the update of the main gateway indication information, the second virtual tunnel interface indicated by the routing path in the service Pod is updated to the second virtual tunnel interface in the new main gateway Pod.

[0037] In one possible implementation, after sending a gateway change indication to the gateway controller when the gateway state of the primary gateway Pod indicates that the primary gateway Pod is unavailable, the method further includes:

[0038] If the gateway controller reports that all backup gateway Pods are unavailable, the data identifier in the custom routing policy of the service Pod is deleted, so that the service Pod transmits the data to the destination address based on the routing path indicated by the default routing policy. The routing path indicated by the default routing policy means that the data is transmitted to the main gateway Pod through the first virtual Ethernet interface in the service Pod and the second virtual Ethernet interface in the main gateway Pod, but not through the first virtual tunnel interface and the second virtual tunnel interface.

[0039] In one possible implementation, the method further includes:

[0040] Obtain the maximum transmission unit (MTU) value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the gateway Pod;

[0041] Based on the MTU value of the second virtual Ethernet interface and the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface, configure the second MTU value of the second virtual tunnel interface in the gateway Pod, wherein the second MTU value is negatively correlated with the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface;

[0042] Obtain the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod;

[0043] Based on the MTU value of the first virtual Ethernet interface and the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface, the first MTU value of the first virtual tunnel interface in the service Pod is determined, wherein the first MTU value is negatively correlated with the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface.

[0044] Based on the minimum of the first MTU value and the second MTU value, configure the final MTU value of the second virtual tunnel interface in the service Pod. If the final MTU value is less than the data volume of the data after the associated data identifier, the data after the associated data identifier is segmented and encapsulated according to the final MTU value and then transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface.

[0045] Based on the final MTU value, IP header byte count, and TCP header byte count of the second virtual tunnel interface in the service Pod, configure the maximum segment size (MSS) value of the service Pod. If the MSS value is less than the data volume, the data is segmented and encapsulated according to the MSS value to obtain segmented and encapsulated data. The data identifier is set for the segmented and encapsulated data to obtain the data with the associated data identifier.

[0046] According to another aspect of this disclosure, a data transmission apparatus based on a Kubernetes cluster is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described method.

[0047] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described method.

[0048] According to another aspect of this disclosure, a computer program product is provided, including a computer program or a non-volatile computer-readable storage medium carrying the computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described method.

[0049] According to another aspect of this disclosure, a data transmission system based on a Kubernetes cluster is provided, the system comprising:

[0050] The business Pod is configured to execute the data transfer methods described above applied to the business Pod; and

[0051] The gateway Pod is configured to execute the data transfer methods described above for the main gateway Pod.

[0052] By configuring custom routing policies in the service Pods corresponding to the tenant identifiers indicated by custom gateway policies, data with data identifiers can be transmitted between these service Pods and the gateway Pod via a virtual tunnel interface. The gateway Pod is configured with a mapping between data identifiers and egress bandwidth limits, allowing it to rate-limit data according to the egress bandwidth limit corresponding to the data identifier. This enables tenant-level egress bandwidth limiting, reducing the operational complexity of the Kubernetes cluster, improving resource utilization, and enhancing the overall service quality for tenants within the Kubernetes cluster. Furthermore, since different tenants' service Pods have different data identifiers, traffic isolation can be ensured within the virtual tunnel established on the virtual tunnel interface when service Pods from different tenants send data to the gateway Pod, overcoming the limitation on the number of tenants and reducing network complexity.

[0053] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0054] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0055] Figure 1 A structural diagram of a data transmission system based on a Kubernetes cluster according to an embodiment of the present disclosure is shown.

[0056] Figure 2 A flowchart illustrating a data transmission method based on a Kubernetes cluster according to an embodiment of the present disclosure is shown.

[0057] Figure 3 A flowchart illustrating a data transmission method based on a Kubernetes cluster according to another embodiment of the present disclosure is shown.

[0058] Figure 4 A flowchart illustrating a data transmission method based on a Kubernetes cluster according to another embodiment of the present disclosure is shown.

[0059] Figure 5 A structural diagram of a data transmission system based on a Kubernetes cluster according to another embodiment of the present disclosure is shown.

[0060] Figure 6 A flowchart illustrating a data transmission method based on a Kubernetes cluster according to another embodiment of the present disclosure is shown.

[0061] Figure 7A schematic diagram illustrating a data transmission process based on a Kubernetes cluster according to an embodiment of the present disclosure is shown.

[0062] Figure 8 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to an embodiment of the present disclosure is shown.

[0063] Figure 9 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to another embodiment of the present disclosure is shown;

[0064] Figure 10 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to another embodiment of the present disclosure is shown;

[0065] Figure 11 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to another embodiment of the present disclosure is shown. Detailed Implementation

[0066] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0067] As used herein, the terms “comprising,” “including,” “having,” or variations thereof are open-ended and include one or more of the stated features, integrals, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integrals, elements, steps, components, functions, or groups thereof.

[0068] When an element is referred to as “connected,” “coupled,” “responding,” or a variation thereof relative to another element, it may be directly connected, coupled, or responding to another element, or there may be an intermediate element present.

[0069] Although the terms first, second, third, etc., may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are used only to distinguish one element / operation from another. Therefore, without departing from the teachings of this disclosure, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments.

[0070] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0071] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0072] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0073] Figure 1 This diagram illustrates a structural diagram of a data transmission system based on a Kubernetes cluster according to an embodiment of this disclosure. Exemplarily, the Kubernetes cluster is a Kubernetes cluster in a multi-tenant scenario. A multi-tenant scenario refers to a scenario where a Kubernetes cluster or a portion thereof is shared by at least two tenants. Each tenant can be a single user or a group of multiple users, such as a team, department, or organization. This disclosure does not limit the implementation method of the tenants.

[0074] To implement tenant-level egress control, the Kubernetes cluster disclosed herein is pre-configured with a custom gateway policy, which includes at least the tenant identifier of the tenant whose egress bandwidth needs to be restricted, the upper limit of egress bandwidth, and relevant information about the gateway Pod.

[0075] Optionally, the tenant identifier is used to distinguish different tenants. The tenant identifier can be the namespace name of the tenant, a label used to identify resource objects in the Kubernetes cluster, or a service account, etc. This embodiment does not limit the implementation method of the tenant identifier.

[0076] The outbound bandwidth limit refers to the maximum allowed rate at which a tenant whose outbound bandwidth needs to be limited can send data to an external network outside the Kubernetes cluster.

[0077] The gateway Pod information is used to configure gateway Pods in a Kubernetes cluster. A gateway Pod is a Pod running in the Kubernetes cluster that acts as a network egress point and can be used to perform egress bandwidth limiting operations. For example, the gateway Pod information includes information about the primary gateway Pod, which indicates the node on which the primary gateway Pod runs. The primary gateway Pod is the gateway Pod currently performing egress bandwidth limiting operations. Optionally, the gateway Pod information may also include information about backup gateway Pods, such as the number of backup gateway Pods. Backup gateway Pods are gateway Pods that are not currently performing egress bandwidth limiting operations but will perform them if the primary gateway Pod is unavailable. This allows the Kubernetes cluster to use backup gateway Pods for egress bandwidth limiting when the primary gateway Pod is unavailable, improving the service reliability of the Kubernetes cluster.

[0078] Optionally, the custom gateway policy may also include target network segments that require egress bandwidth restrictions. Different target network segments may correspond to different egress bandwidth limits, such as target network segment 1 corresponding to egress bandwidth limit 1, and target network segment 2 corresponding to egress bandwidth limit 2; and / or, different target network segments may correspond to the same egress bandwidth limit, such as target network segment 3 corresponding to egress bandwidth limit 2, which is the same as the egress bandwidth limit 2 of target network segment 2.

[0079] For example, custom gateway policies are configured based on Custom Resource Definitions (CRDs). A CRD is a mechanism that extends the Kubernetes API, allowing users to define new resource types. These custom resources can be created, updated, and deleted just like built-in Kubernetes resources such as Pods, Services, Deployments, etc. CRDs provide a flexible way to extend Kubernetes functionality, enabling it to adapt to various specific application scenarios. In this disclosure, a custom gateway policy, `EgressGatewayPolicy`, can be defined using a CRD to create a primary gateway Pod in a Kubernetes cluster. This Pod limits the outbound bandwidth of tenants transmitting data to external networks according to the specified outbound bandwidth limit. This enables tenant-level, fine-grained bandwidth control, reduces the operational complexity of the Kubernetes cluster, improves resource utilization, and enhances the overall service quality for tenants within the Kubernetes cluster.

[0080] Optionally, the custom gateway policy can be an extension of the CiliumEgressGatewayPolicy in the CNI plugin cilium; or it can be an extension of the Global NetworkPolicy in the CNI plugin calico; or it can be a separately configured policy. This embodiment does not limit the implementation method of the custom gateway policy.

[0081] For example, a typical custom gateway policy is as follows:

[0082] apiVersion: networking.infini-ai.com / v1alpha1

[0083] kind: EgressGatewayPolicy

[0084] metadata:

[0085] name: tenant-a-policy

[0086] spec:

[0087] selectors:

[0088] - podSelector: { matchLabels: { app: dev-machine}}

[0089] destinationCIDRs: [ "0.0.0.0 / 0" ]

[0090] egressGateway:

[0091] nodeSelector: { node-role: egress}

[0092] replicas: 2

[0093] bandwidth: { rate: "10Mbit"}.

[0094] In the above exemplary custom gateway policy, "apiVersion" represents the version of the custom resource API, specifically "networking.infini-ai.com / v1alpha1"; "kind" represents the type of the custom resource, specifically the custom gateway policy "EgressGatewayPolicy"; "metadata:name" represents the name of the custom gateway policy, specifically "tenant-a-policy"; "spec" represents the details of the policy rule; "selectors" represents selectors, "podSelector" represents a node selector used to select service Pods with a specific label "matchLabels" (i.e., tenant identifier), specifically "app: dev-machine"; "destinationCIDRs" represents the target network segment that needs to be bandwidth limited, specifically "0.0.0.0 / 0", indicating that all IPv4 addresses need to be bandwidth limited; "egressGateway" represents the relevant information of the gateway Pod, where "nodeSelector" represents a node selector used to select nodes with the identifier "node-role: The node running "egress" is the gateway Pod; "replicas" indicates the number of backup gateway Pods, which is 2; "bandwidth" indicates the maximum outbound bandwidth, which is 10Mbps.

[0095] Optionally, a custom gateway policy can be manually defined in the Kubernetes cluster, and this custom gateway policy can be changed and deleted.

[0096] like Figure 1 As shown, the data transmission system based on the Kubernetes cluster includes: node controller 110 and gateway controller 120.

[0097] Gateway controller 120 (Egress-gateway-controller) is used to deploy gateway Pods in the Kubernetes cluster. For example, gateway controller 120 can obtain custom gateway policies configured in the Kubernetes cluster, and then create gateway Pods based on the information of the gateway Pods indicated by the custom gateway policies. Both gateway controller 120 and custom gateway policies deploy or store the control plane of the Kubernetes cluster.

[0098] For example, creating a gateway Pod based on the relevant information of the gateway Pod indicated by the custom gateway policy includes creating a primary gateway Pod in the node indicated by the relevant information of the gateway Pod. For instance, referring to the custom gateway policy in the example above, after the gateway controller 120 obtains the custom gateway policy, it creates a primary gateway Pod in the node identified as "node-role: egress" according to the instruction of "nodeSelector".

[0099] Optionally, if the custom gateway policy also defines the number of backup gateways, and this number is not zero, then the gateway controller 120 is further configured to: create backup gateway Pods according to the relevant information of the gateway Pods indicated by the custom gateway policy. In this case, while creating the primary gateway Pod in the node indicated by the relevant information of the gateway Pod, the gateway controller 120 can also create at least one backup gateway Pod.

[0100] For example, referring to the custom gateway policy in the example above, after the gateway controller 120 obtains the custom gateway policy, it creates a primary gateway Pod and two backup gateway Pods on the node with the node identifier "node-role: egress" according to the instructions of "nodeSelector" and "replicas".

[0101] Node controller 110 can obtain custom gateway policies configured in the Kubernetes cluster and configure the gateway Pods defined in the custom gateway policies, as well as the service Pods corresponding to tenants whose outbound bandwidth needs to be limited, according to the custom gateway policies. A service Pod refers to the Pod corresponding to a tenant in the Kubernetes cluster, that is, the Pod that initiates the data transmission request.

[0102] Node controller 110 runs on each node in the Kubernetes cluster. When a new node joins the cluster, node controller 110 is automatically created on the new node. This allows the controller to configure the business pods running on the node if it detects that a business pod corresponding to a tenant identifier defined in the custom gateway policy is running on that node. For example, node controller 110 might be a daemon pod created by daemonset in the Kubernetes cluster.

[0103] In this embodiment, reference Figure 2 The node controller configures the gateway Pod and the service Pod, including the following steps:

[0104] Step 201: Obtain the custom gateway policy configured in the Kubernetes cluster.

[0105] As mentioned above, a custom gateway policy should include at least the tenant identifier of the tenant whose outbound bandwidth needs to be limited, the upper limit of the outbound bandwidth corresponding to the tenant identifier, and relevant information about the gateway Pod.

[0106] Step 202: Configure the first virtual tunnel interface in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy.

[0107] The node controller running on each node determines whether the tenant identifier indicated by the custom gateway policy is consistent with the tenant identifier corresponding to the service Pod running on this node; if they are consistent, the first virtual tunnel interface is configured for the service Pod; if they are inconsistent, the custom gateway policy continues to be monitored.

[0108] In one example, configuring a first virtual tunnel interface in a business Pod includes: creating a first virtual tunnel interface in the business Pod; and determining the first address information of the first virtual tunnel interface from a custom address pool, wherein the first address information is an unused address in the custom address pool.

[0109] For example, the first virtual tunnel interface can be a Virtual Extensible LAN (VXLAN) interface or a Generic Network Virtualization Encapsulation (Geneve) interface. The following embodiment uses the VXLAN interface as an example for illustration. In actual implementation, this embodiment does not limit the type of the first virtual tunnel interface.

[0110] A custom address pool is a pre-configured, independent IP address pool within the Kubernetes cluster, separate from the Kubernetes cluster's CNI plugin. For example, the custom address pool might be an IPAMPool obtained through IP Address Management (IPAM) CRD configuration. Correspondingly, exemplarily, determining the first address information of the first virtual tunnel interface from the custom address pool includes: calling the IP Address Management Plugin (IPAM Plugin) to request the first address information (i.e., an IP address, such as 172.16.0.101) from the custom address pool. The IPAM Plugin is used for automated allocation, tracking, and management of IP address resources in the custom address pool. In this embodiment, by setting up a custom address pool independent of the CNI plugin and requesting the first address information from this custom address pool via the IPAM Plugin, the need for code adaptation for different versions of the CNI plugin in the Kubernetes cluster, which leads to low configuration efficiency for business Pods, can be avoided, thus improving the configuration efficiency of business Pods.

[0111] For example, to ensure that the first address information is an unoccupied address in the custom address pool, IPAMPlugin requests the first address information from the custom address pool, including: allocating the first address information to the business Pod from the custom address pool based on an optimistic locking mechanism.

[0112] For example, a custom address pool includes a list of available IPs (i.e., an unassigned IP list) and a list of assigned IPs. The Kubernetes cluster stores the version number A of the custom address pool at the time of its most recent update. If at least two node controllers simultaneously need to allocate the first address information for their own business Pods, each node controller will obtain version number A and IP addresses from the list of available IPs. If at least two node controllers select the same IP address from the list of available IPs, the node controller A that first requests the IPAM Plugin submits a request for that IP address, along with the obtained version number A. The IPAM Plugin determines that version number A is consistent with the version number A at the time of the most recent update, then assigns that IP address to the business Pod in node controller A, and updates the list of available IPs, the list of assigned IPs, and the version number B of the custom address pool at the time of the most recent update. Node controller B, which then requests the IPAM Plugin, submits a request for that IP address, along with the obtained version number A. If the plugin determines that version number A is inconsistent with version number B from the most recent update, it sends a conflict indication to node controller B. Node controller B responds to the conflict indication by rereading the list of available IPs, the list of allocated IPs, and version number B from the most recent update, and then sends another request to the IPAM plugin until an IP address is obtained. In this way, multiple node controllers that simultaneously request the first address information can obtain unused address information for their own business Pods, ensuring the uniqueness of IP address allocation.

[0113] In addition, when a service Pod is deleted, the node controller will actively release the first address information of the service Pod, so that the first address information can be used as unoccupied address information for other service Pods.

[0114] Step 203: Configure the second virtual tunnel interface in the gateway Pod according to the relevant information of the gateway Pod indicated by the custom gateway policy.

[0115] A gateway Pod includes at least the primary gateway Pod. If the relevant information of the gateway Pod also indicates that the number of standby gateway Pods is not zero, the gateway Pod also includes standby gateway Pods.

[0116] In one example, configuring a second virtual tunnel interface in a gateway Pod includes: creating a second virtual tunnel interface in a business Pod; and determining the second address information of the second virtual tunnel interface from a custom address pool, wherein the second address information is an unused address in the custom address pool.

[0117] The interface type of the second virtual tunnel interface is the same as that of the first virtual tunnel interface, for example, both are VXLAN interfaces. For a detailed description of determining the second address information from the custom address pool, please refer to step 202. Simply replace the first address information with the second address information; this embodiment will not elaborate further.

[0118] If the main gateway Pod terminates due to an error or other reason (i.e., becomes unavailable), the gateway controller scans IPAMPool and reclaims the second address information corresponding to the main gateway Pod that has not been released after the timeout, so that the second address information can be used as unoccupied address information for other gateway Pods.

[0119] Optionally, step 203 can be executed after step 202, or before step 202, or it can be executed synchronously with step 202. This embodiment does not limit the execution order between steps 202 and 203.

[0120] Step 204: Configure a custom routing policy in the business Pod according to the custom gateway policy.

[0121] Configure custom routing strategies in business Pods, including generating data identifiers and routing paths for business Pods.

[0122] The data identifier of a service Pod can indicate the tenant that requires bandwidth limiting and is used to associate data transmitted by the service Pod to a destination address. The data identifier can be a VXLAN Network Identifier (VNI), and this embodiment does not limit the implementation of the data identifier.

[0123] Optionally, the custom gateway policy also includes configuring a custom routing policy in the service Pod when the tenant needs to limit the target network segment for outbound bandwidth. This further includes configuring the mapping between target network segments and data identifiers in the service Pod, so that when the destination address of the data in the service Pod belongs to the target network segment, the data is associated with the data identifier corresponding to that target network segment. In this case, a service Pod can have multiple data identifiers to indicate different outbound bandwidth limits for different target network segments, thereby achieving more granular outbound bandwidth limiting, further reducing the complexity of Kubernetes cluster operation and maintenance, further improving Kubernetes cluster resource utilization, and further improving the overall service quality for tenants in the Kubernetes cluster.

[0124] The routing path indicates how data, after being associated with the data identifier, is transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface. Specifically, the routing path includes at least the first address information of the first virtual tunnel interface and the second address information of the second virtual tunnel interface.

[0125] For example, the first virtual tunnel interface and custom routing strategy can be configured as follows: obtain the process identifier of the business Pod; determine the process structure of the business Pod based on the process identifier, and obtain the namespace file in the process structure; generate a symbolic link to the namespace file; access the namespace of the business Pod through the symbolic link, and configure the first virtual tunnel interface and custom routing strategy in the namespace.

[0126] In this embodiment, the custom routing strategy of the business Pod is configured by accessing the namespace of the business Pod through a symbolic link. This eliminates the need for the node controller to create an additional Pod in the business Pod to configure the custom routing strategy, enabling non-intrusive configuration, improving configuration efficiency, and reducing configuration complexity.

[0127] Step 205: Configure the correspondence between data identifiers and egress bandwidth limits in the gateway Pod to instruct the gateway Pod to transmit data with the associated data identifier to the destination address according to the egress bandwidth limit.

[0128] In this embodiment, by configuring a custom routing policy in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy, the service Pod and the gateway Pod transmit data with data identifiers via a virtual tunnel interface. The gateway Pod is configured with a correspondence between the data identifier and the upper limit of the egress bandwidth, allowing the gateway Pod to rate-limit data according to the upper limit of the egress bandwidth corresponding to the data identifier. This enables fine-grained egress bandwidth limiting at the tenant level, reducing the operational complexity of the Kubernetes cluster, improving the resource utilization of the Kubernetes cluster, and enhancing the overall service quality for tenants within the Kubernetes cluster. Furthermore, since the data identifiers corresponding to the service Pods of different tenants are different, it ensures that traffic isolation is achieved within the virtual tunnel established by the virtual tunnel interface when service Pods of different tenants send data to the gateway Pod, overcoming the limitation on the number of tenants and reducing network complexity.

[0129] Furthermore, by configuring the mapping between target network segments and data identifiers in the service Pods corresponding to the tenant identifiers indicated by the custom gateway policy, rate limiting can be applied according to the upper limit of the outbound bandwidth corresponding to the data identifier of the target network segment when the destination address of the data in the service Pod belongs to the target network segment. On the basis of tenant-level outbound bandwidth limiting, target network segment-level outbound bandwidth limiting is further implemented, which further refines the granularity of outbound bandwidth limiting, further reduces the complexity of Kubernetes cluster operation and maintenance, further improves the resource utilization of Kubernetes cluster, and further improves the overall service quality of tenants in Kubernetes cluster.

[0130] Furthermore, by setting up a custom address pool independent of the CNI plugin, and requesting the first address information from this custom address pool via the IPAM Plugin, the issue of low configuration efficiency for business Pods due to the need for code adaptation for different versions of the CNI plugin in the Kubernetes cluster can be avoided. This improves the configuration efficiency of business Pods and reduces the coupling between components. Allocating the first address information to business Pods from the custom address pool based on an optimistic locking mechanism ensures the uniqueness of IP address allocation. Automatically reclaiming expired IP addresses enables dynamic IP address reclamation, saving IP address resources and improving IP address resource utilization.

[0131] In addition, by accessing the namespace of a business Pod through a symbolic link to configure the custom routing strategy for that business Pod, the node controller does not need to create an additional Pod in the business Pod to configure the custom routing strategy. This enables non-intrusive configuration and improves configuration efficiency.

[0132] Optionally, to ensure effective outbound bandwidth limiting, the node controller also monitors the primary gateway Pod to determine its availability. If the primary gateway Pod is unavailable, the node controller is triggered to activate a backup gateway Pod as the primary gateway Pod for outbound bandwidth limiting. In this case, the custom gateway policy also defines relevant information about the backup gateway Pod and primary gateway indication information, which indicates the current primary gateway Pod in each gateway Pod. Correspondingly, after step 205, some embodiments of the data transmission method disclosed herein further include, for example... Figure 3 Steps 301 to 340 are shown.

[0133] Step 301: When the gateway status of the primary gateway Pod indicates that the primary gateway Pod is unavailable, the node controller sends a primary gateway change instruction to the gateway controller.

[0134] The primary gateway change indication is used to trigger the gateway controller to switch the standby gateway Pod that is in an available state to the new primary gateway Pod, and update the primary gateway indication information so that the primary gateway indication information indicates that the new primary gateway Pod is the current primary gateway Pod.

[0135] For example, the node controller determines in real time whether the configuration information of the main gateway Pod matches the relevant information of the gateway Pod in the custom gateway policy; if they match, it means that the main gateway Pod is available and the gateway status is set to available; if they do not match, it means that the main gateway Pod is unavailable and the gateway status is set to unavailable.

[0136] For example, determining whether the configuration information of the main gateway Pod matches the relevant information of the gateway Pod in the custom gateway policy includes: determining whether the main gateway Pod is the gateway Pod indicated by the main gateway indication information and whether the node on which the main gateway Pod runs is the node indicated by the custom gateway policy; if the main gateway Pod is the gateway Pod indicated by the main gateway indication information and the node on which the main gateway Pod runs is the node indicated by the custom gateway policy, then it is determined that the configuration information of the main gateway Pod matches the relevant information of the gateway Pod in the custom gateway policy.

[0137] In step 302, in response to receiving the gateway change instruction sent by the node controller, the gateway controller switches the standby gateway Pod, which is in an available state, to the new primary gateway Pod.

[0138] For example, the gateway controller determines the gateway Pod that matches the relevant information of the gateway Pod in the standby gateway Pods and uses it as the new primary gateway Pod.

[0139] Optionally, if the gateway controller determines that all backup gateway Pods are unavailable, it sends an indication to the node controller that all backup gateway Pods are unavailable. Correspondingly, if the gateway controller reports that all backup gateway Pods are unavailable, the node controller deletes the data identifier from the custom routing policy in the service Pod. Without a data identifier, the service Pod transmits data to the destination address based on the routing path indicated by the default routing policy. The routing path indicated by the default routing policy means that the data transmission to the primary gateway Pod passes through the first virtual Ethernet interface (e.g., eth0) in the service Pod and the second virtual Ethernet interface (e.g., eth0) in the primary gateway Pod, but does not pass through the first or second virtual tunnel interface.

[0140] For example, the default routing policy includes the eth0 address of the business Pod / "0.0.0.0 / 0" and the eth0 address of the main gateway Pod / "0.0.0.0 / 0".

[0141] Step 303: The gateway controller updates the primary gateway indication information so that the primary gateway indication information indicates that the new primary gateway Pod is the current primary gateway Pod; the update of the primary gateway indication information triggers the node controller to update the second virtual tunnel interface of the routing path indication in the service Pod to the second virtual tunnel interface in the new primary gateway Pod.

[0142] In step 304, in response to the update of the main gateway indication information, the node controller updates the second virtual tunnel interface of the routing path indication in the service Pod to the new second virtual tunnel interface in the main gateway Pod.

[0143] For example, the custom routing policy originally configured in the business Pod includes the second address information of the second virtual tunnel interface of gateway Pod1; in response to the update of the main gateway indication information, the node controller modifies the configuration in the custom routing policy of the business Pod to the second address information of the second virtual tunnel interface of gateway Pod2 according to the main gateway indication information. Gateway Pod2 is the main gateway Pod indicated by the main gateway indication information.

[0144] In this embodiment, by setting up multiple backup gateway Pods, the system can automatically switch to backup gateway Pods for outbound bandwidth limitation when the primary gateway Pod is unavailable. The gateway controller also automatically updates the primary gateway indication information, so that the node controller responds to the update of the primary gateway indication information and quickly updates the second virtual tunnel interface indicated by the routing path to the second virtual tunnel interface in the new primary gateway Pod. This ensures efficient path switching when the gateway Pod fails.

[0145] Since the service Pod corresponding to the tenant identifier indicated by the custom gateway policy in this disclosure communicates with the main gateway Pod via a virtual tunnel interface (VXLAN interface), in order to control the data transmitted on the transmission path to not exceed the maximum data volume allowed by the virtual tunnel interface and reduce data loss, in one example, when configuring the first virtual tunnel interface, the final maximum transmission unit (MTU) value and maximum segment size (MSS) value of the first virtual tunnel interface are also configured. Specifically, refer to... Figure 4 The process shown involves configuring the MTU and MSS values ​​of the first virtual tunnel interface on the node controller. This process includes the following steps:

[0146] Step 401: Obtain the MTU value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the gateway Pod.

[0147] In this step, the gateway Pod includes at least the primary gateway Pod; if the custom gateway policy also instructs the configuration of a backup gateway Pod, then the gateway Pod also includes each backup gateway Pod.

[0148] The node controller obtains the MTU value of the second virtual Ethernet interface by: using a first command (such as the ip linkshow command) to obtain the device index number of the second virtual Ethernet interface eth0 of the gateway Pod; determining the filter for the default route based on the device index number and the route path 0.0.0.0 / 0 indicated by the default route policy; using a second command (such as the ip rout list command) to obtain the routing table, filtering out the default route from the routing table using the filter, and extracting the MTU value of the second virtual Ethernet interface from the default route.

[0149] For example, the default route filtered by the filter is: default via 10.0.0.1 dev eth0 protostatic mtu 1500, where "mtu 1500" means that the MTU value of the second virtual Ethernet interface is 1500.

[0150] Step 402: Configure the second MTU value of the second virtual tunnel interface in the gateway Pod based on the MTU value of the second virtual Ethernet interface and the number of bytes of the encapsulated packet header corresponding to the second virtual tunnel interface.

[0151] The second MTU value is negatively correlated with the number of bytes in the encapsulated header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface.

[0152] For example, the second MTU value is determined based on the difference between the MTU value of the second virtual Ethernet interface and the number of bytes in the encapsulated header corresponding to the second virtual tunnel interface.

[0153] For example: if the MTU value of the second virtual Ethernet interface is 1500 bytes and the number of bytes in the encapsulated header of the second virtual tunnel interface is 50 bytes, then the MTU value of the second virtual tunnel interface can be 1500-50=1450 bytes.

[0154] After obtaining the second MTU value, the node controller updates the second MTU value to the description information annotation of the gateway Pod, and obtains the second MTU value of the gateway Pod by reading the description information annotation, and updates the second MTU value to the custom gateway policy.

[0155] Step 403: Obtain the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod.

[0156] The node controller obtains the MTU value of the first virtual Ethernet interface by: using a first command (such as the ip linkshow command) to obtain the device index number of the first virtual Ethernet interface eth0 of the service Pod; determining the filter for the default route based on the device index number and the route path 0.0.0.0 / 0 indicated by the default route policy; using a second command (such as the ip rout list command) to obtain the routing table, filtering out the default route from the routing table using the filter, and extracting the MTU value of the first virtual Ethernet interface from the default route.

[0157] Step 404: Determine the first MTU value of the first virtual tunnel interface in the service Pod based on the MTU value of the first virtual Ethernet interface and the number of bytes of the encapsulated packet header corresponding to the first virtual tunnel interface.

[0158] The first MTU value is negatively correlated with the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface.

[0159] For example, the first MTU value is determined based on the difference between the MTU value of the first virtual Ethernet interface and the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface.

[0160] For example: if the MTU value of the first virtual Ethernet interface is 1400B, and the number of bytes of the encapsulated header corresponding to the first virtual tunnel interface is equal to the number of bytes of the encapsulated header corresponding to the second virtual tunnel interface is 50B, then the first MTU value can be 1400-50=1350B.

[0161] Optionally, steps 403 and 404 may be executed after steps 401 and 402, or before steps 401 and 402, or simultaneously with steps 401 and 402. This embodiment does not limit the execution order of steps 403 and 404, or between steps 401 and 402.

[0162] Step 405: Configure the final MTU value of the second virtual tunnel interface in the service Pod based on the minimum value between the first MTU value and the second MTU value.

[0163] If the final MTU value is less than the amount of data after the associated data identifier, the data after the associated data identifier is segmented and encapsulated according to the final MTU value and then transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface.

[0164] Step 406: Configure the MSS value of the business Pod based on the final MTU value, IP header bytes, and TCP header bytes of the second virtual tunnel interface in the business Pod.

[0165] Specifically, when the MSS value is less than the data volume of the business Pod, the data is segmented and encapsulated according to the MSS value to obtain segmented and encapsulated data. Data identifiers are then set for the segmented and encapsulated data to obtain data with associated data identifiers.

[0166] MSS value is positively correlated with the final MTU value and negatively correlated with the number of bytes in the IP header and the number of bytes in the TCP header.

[0167] For example, the MSS value = final MTU value - number of bytes in the IP header - number of bytes in the TCP header.

[0168] For example: the final MTU value = min(1450, 1350) B = 1350 B, the number of bytes in the IP header = 20 B, the number of bytes in the TCP header = 20 B, then the MSS value = 1350 - 20 - 20 = 950 B.

[0169] In summary, in this embodiment, by determining the final MTU value of the second virtual tunnel interface in the service Pod based on the minimum of the first MTU value and the second MTU value in the gateway Pod and the service Pod, and determining the MSS value based on the final MTU value, it can be ensured that the amount of data transmitted during data transmission does not exceed the maximum transmission capacity of the virtual tunnel interface, thus ensuring the reliability of data transmission.

[0170] It should be noted that the steps executed by the gateway controller can be implemented as a separate method embodiment of the gateway controller, and the steps executed by the node controller can be implemented as a separate method embodiment of the gateway controller. The relevant embodiments will not be elaborated here.

[0171] After the node controller completes the configuration of the service Pod and gateway Pod for the tenant identifier defined by the custom gateway policy, the service Pod can transmit data through the gateway Pod, allowing bandwidth limiting to be implemented via the gateway Pod. Specifically, for example... Figure 5 As shown, the data transmission system based on the Kubernetes cluster includes: business Pod 510 and gateway Pod 520.

[0172] Business Pod 510 refers to a business Pod with a tenant identifier defined by a custom gateway policy in a Kubernetes cluster.

[0173] Gateway Pod 520 includes at least the primary gateway Pod. If a custom gateway policy also instructs that at least one standby gateway Pod be configured, then gateway Pod 520 also includes the standby gateway Pod.

[0174] Figure 6 A flowchart illustrating a data transmission method according to an embodiment of the present disclosure is shown. Figure 6 As shown, the method includes:

[0175] Step 601: In response to a service Pod corresponding to a tenant identifier defined in a custom gateway policy transmitting data to a destination address, if the service Pod has a data identifier in the custom routing policy, associate the data with the data identifier.

[0176] As described above, the custom gateway policy in the Kubernetes cluster defines the tenant identifier for tenants whose outbound bandwidth needs to be limited. The node controller then configures the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to that tenant identifier. When the service Pod corresponding to the tenant identifier transmits data to a destination address, it will associate the data with the data identifier based on the data identifier in the custom routing policy pre-configured by the node controller.

[0177] Optionally, if the custom gateway policy also specifies the target network segment for which tenants need to limit outbound bandwidth, the node controller will also configure the mapping between the target network segment and the data identifier in the custom routing policy. Accordingly, the associated data and data identifier will include:

[0178] If a data identifier corresponding to the target network segment exists in the custom routing policy of a business Pod and the destination address belongs to the target network segment, associate the data with the data identifier corresponding to the target network segment.

[0179] Accordingly, if there is no correspondence between the target network segment and the data identifier in the custom routing policy of the business Pod, or if the destination address does not belong to the target network segment, the business Pod will transmit data to the destination address based on the routing path indicated by the default routing policy.

[0180] The default routing policy indicates that the route path for data transmission to the main gateway Pod passes through the first virtual Ethernet interface in the service Pod and the second virtual Ethernet interface in the main gateway Pod, but does not pass through the first virtual tunnel interface and the second virtual tunnel interface.

[0181] For example, the default routing policy includes the eth0 address of the service Pod / "0.0.0.0 / 0" and the eth0 address of the main gateway Pod / "0.0.0.0 / 0". If there is no correspondence between the destination network segment and the data identifier in the custom routing policy of the service Pod, or if the destination address does not belong to the destination network segment, the data of the service Pod will be transmitted to the destination address after passing through the eth0 address of the service Pod / "0.0.0.0 / 0" and the eth0 address of the main gateway Pod / "0.0.0.0 / 0".

[0182] To ensure the reliability of data transmission, the business Pod is also used to: obtain the MSS value of the business Pod and the final MTU value of the second virtual tunnel interface in the business Pod; accordingly, associate data and data identifiers, including: when the data volume is greater than the MSS value, segmenting and encapsulating the data according to the MSS value to obtain segmented and encapsulated data; associating data identifiers with the segmented and encapsulated data to obtain data with associated data identifiers.

[0183] The final MTU value is determined based on the minimum of the first MTU value of the first virtual tunnel interface in the service Pod and the second MTU value of the second virtual tunnel interface in the main gateway Pod. The first MTU value is configured based on the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod and the number of bytes in the encapsulated packet header corresponding to the first virtual tunnel interface. The first MTU value is negatively correlated with the number of bytes in the encapsulated packet header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface. The second MTU value is configured based on the MTU value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the main gateway Pod and the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface. The second MTU value is negatively correlated with the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface. The MSS value is configured based on the final MTU value, the number of bytes in the IP header, and the number of bytes in the TCP header. For details on the configuration process of the MSS value and the final MTU value, please refer to [link to configuration details]. Figure 4 The process shown in this embodiment will not be described again here.

[0184] Step 602: The business Pod controls the data associated with the data identifier and transmits it to the main gateway Pod according to the routing path indicated by the custom routing policy, so that the main gateway Pod can transmit the data to the destination address according to the upper limit of the egress bandwidth corresponding to the configured data identifier.

[0185] Specifically, the custom routing policy indicates that the data with associated data identification is transmitted to the main gateway Pod via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod. For example, the custom routing policy indicates that the routing path includes the first address information of the first virtual tunnel interface and the second address information of the second virtual tunnel interface. The data with associated data identification is encapsulated according to the first address information and the second address information and then sent to the main gateway Pod, thereby realizing the transmission of the data with associated data identification to the main gateway Pod.

[0186] In one example, controlling the transmission of data after the associated data identifier to the main gateway Pod according to the routing path indicated by the custom routing policy includes: if the data volume of the data after the associated data identifier is greater than the final MTU value of the service Pod, segmenting and encapsulating the data after the associated data identifier according to the final MTU value and transmitting it to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface.

[0187] Step 603: Upon receiving data with associated data identifier transmitted from the service Pod with the tenant identifier defined by the corresponding custom gateway policy via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod, the main gateway Pod transmits the data to the destination address according to the egress bandwidth limit corresponding to the data identifier pre-configured in the main gateway Pod.

[0188] The data after the associated data identifier is obtained by the business Pod responding to the transmission of data to the destination address, and the associated data and the data identifier in the business Pod's custom routing policy.

[0189] As mentioned above, the custom gateway policy also pre-configures relevant information for the main gateway Pod. This information indicates the mapping between the second virtual tunnel interface and the data identifier in the main gateway Pod, and the upper limit of the egress bandwidth. Therefore, after the node controller configures the second virtual tunnel interface and the mapping between the data identifier and the upper limit of the egress bandwidth in the main gateway Pod according to the relevant information of the main gateway Pod, the main gateway Pod can receive data with associated data identifier encapsulated based on the virtual tunnel protocol corresponding to the virtual tunnel interface through the second virtual tunnel interface. Accordingly, the main gateway Pod decapsulates the data with associated data identifier based on the virtual tunnel protocol corresponding to the virtual tunnel interface to obtain the data with associated data identifier; after reading the data identifier, it obtains the upper limit of the egress bandwidth corresponding to the data identifier according to the mapping between the data identifier and the upper limit of the egress bandwidth; and transmits the data to the destination address according to the upper limit of the egress bandwidth.

[0190] Optionally, the custom gateway policy also configures the target network segment for which tenants need to limit egress bandwidth. In this case, the node controller will also configure the correspondence between data identifier, target network segment, and egress bandwidth limit in the main gateway Pod, where the destination address belongs to the target network segment. Accordingly, based on the egress bandwidth limit corresponding to the data identifier pre-configured in the main gateway Pod, data is transmitted to the destination address, including: obtaining the egress bandwidth limit corresponding to the target network segment to which the data identifier and destination address belong, and transmitting data to the destination address according to the egress bandwidth limit.

[0191] refer to Figure 7 The diagram shown illustrates data transmission. Figure 7 It can be seen that when a service Pod with a tenant identifier indicated by a custom gateway policy sends data to a target address, the data is segmented and encapsulated based on the MSS value and then associated with a data identifier. The data after associating the data identifier is segmented and encapsulated according to the final MTU value, and then transmitted through the first virtual tunnel interface (VXLAN0) 701 and the first virtual Ethernet interface (ETH0) 702 corresponding to the service Pod to the second virtual Ethernet interface (ETH0) 703 corresponding to the main gateway Pod. Then, it is transmitted from the second virtual Ethernet interface (ETH0) 703 to the second virtual tunnel interface (VXLAN0) 704 corresponding to the main gateway Pod. After receiving the data after associating the data identifier through the second virtual tunnel interface (VXLAN0) 704, the main gateway Pod decapsulates it to obtain the data identifier. According to the correspondence between the data identifier and the upper limit of the egress bandwidth indicated by the egress bandwidth, the data is transmitted to the destination address through the second virtual Ethernet interface (ETH0) 703.

[0192] In summary, the data transmission method provided in this embodiment configures a custom routing policy in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy. This allows the service Pod and the gateway Pod to transmit data with data identifiers via a virtual tunnel interface. The gateway Pod is configured with a correspondence between the data identifier and the upper limit of the egress bandwidth, enabling it to rate-limit data according to the upper limit of the egress bandwidth corresponding to the data identifier. This achieves fine-grained egress bandwidth limiting at the tenant level, reducing the operational complexity of the Kubernetes cluster, improving resource utilization, and enhancing the overall service quality for tenants within the Kubernetes cluster. Furthermore, since different tenants have different data identifiers for their service Pods, traffic isolation can be ensured within the virtual tunnel established by the virtual tunnel interface when service Pods from different tenants send data to the gateway Pod, overcoming the limitation on the number of tenants and reducing network complexity.

[0193] Furthermore, by configuring the mapping between target network segments and data identifiers in the service Pods corresponding to the tenant identifiers indicated by the custom gateway policy, rate limiting can be applied according to the upper limit of the outbound bandwidth corresponding to the data identifier of the target network segment when the destination address of the data in the service Pod belongs to the target network segment. On the basis of tenant-level outbound bandwidth limiting, target network segment-level outbound bandwidth limiting is further implemented, which further refines the granularity of outbound bandwidth limiting, further reduces the complexity of Kubernetes cluster operation and maintenance, further improves the resource utilization of Kubernetes cluster, and further improves the overall service quality of tenants in Kubernetes cluster.

[0194] It should be noted that steps 601 and 602 can be implemented as a method embodiment on the business Pod side, and step 603 can be implemented as a method embodiment on the business Pod side. The relevant embodiments will not be described again here.

[0195] Figure 8 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to an embodiment of the present disclosure is shown. This apparatus is used for service Pods, such as... Figure 8 As shown, the device includes a data association module 810 and a data transmission module 820.

[0196] The data association module 810 is used to associate the data with the data identifier when a service Pod corresponding to a tenant identifier defined by a custom gateway policy transmits data to a destination address, provided that a data identifier exists in the custom routing policy of the service Pod.

[0197] The data transmission module 820 is used to control the data after the associated data identifier to be transmitted to the main gateway Pod according to the routing path indicated by the custom routing policy, so that the main gateway Pod transmits the data to the destination address according to the configured egress bandwidth limit corresponding to the data identifier. The routing path indicated by the custom routing policy indicates that the data after the associated data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod.

[0198] The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

[0199] For relevant details, please refer to the above embodiments, which will not be repeated here.

[0200] Figure 9 A block diagram of a data transmission apparatus for a Kubernetes cluster according to an embodiment of the present disclosure is shown. This apparatus is used for a main gateway Pod, such as... Figure 9 As shown, the device includes: a data transmission module 910.

[0201] Data transmission module 910 is used to respond to data with associated data identifier received from a service Pod with a tenant identifier corresponding to a custom gateway policy definition via a first virtual tunnel interface in the service Pod and a second virtual tunnel interface in the main gateway Pod, and to transmit the data to a destination address according to the egress bandwidth limit corresponding to the data identifier pre-configured in the main gateway Pod;

[0202] The data after the associated data identifier is obtained by the service Pod in response to transmitting data to the destination address, by associating the data with the data identifier in the service Pod's custom routing policy;

[0203] The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

[0204] For details, please refer to the above embodiments.

[0205] Figure 10 A block diagram of a data transmission apparatus based on a Kubernetes cluster according to an embodiment of the present disclosure is shown. This apparatus is used for a node controller, such as... Figure 10 As shown, the device includes: a gateway policy acquisition module 1010, a first interface configuration module 1020, a second interface configuration module 1030, a routing policy configuration module 1040, and a bandwidth limit configuration module 1050.

[0206] The gateway policy acquisition module 1010 is used to acquire custom gateway policies configured in the Kubernetes cluster. The custom gateway policy includes: the tenant identifier of the tenant whose outbound bandwidth needs to be limited, the outbound bandwidth limit corresponding to the tenant identifier, and relevant information of the gateway Pod. The gateway Pod includes at least the main gateway Pod.

[0207] The first interface configuration module 1020 is used to configure a first virtual tunnel interface in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy.

[0208] The second interface configuration module 1030 is used to configure a second virtual tunnel interface in the gateway Pod according to the relevant information of the gateway Pod indicated by the custom gateway policy.

[0209] The routing policy configuration module 1040 is used to configure a custom routing policy in the service Pod according to the custom gateway policy, including: generating a data identifier for the service Pod, associating the data identifier with data transmitted by the service Pod to a destination address, and generating a routing path to indicate that the data associated with the data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface;

[0210] The bandwidth limit configuration module 1050 is used to configure the correspondence between the data identifier and the egress bandwidth limit in the gateway Pod, so as to instruct the gateway Pod to transmit the data associated with the data identifier to the destination address according to the egress bandwidth limit.

[0211] For details, please refer to the above embodiments.

[0212] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0213] This disclosure also provides a data transmission apparatus for a Kubernetes cluster, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0214] This disclosure also provides a non-volatile computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0215] This disclosure also provides a computer program product, including a computer program or a non-volatile computer-readable storage medium carrying the computer program, wherein the computer program, when executed by a processor, implements the steps of the above method.

[0216] Figure 11This is a block diagram illustrating a data transmission apparatus 1900 for a Kubernetes cluster according to an exemplary embodiment. For example, apparatus 1900 may be provided as a service pod, a master gateway pod, or a node controller. (Refer to...) Figure 11 The apparatus 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by the processing component 1922. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0217] Device 1900 may also include a power supply component 1926 configured to perform power management of device 1900, a wired or wireless network interface 1950 configured to connect device 1900 to a network, and an input / output interface 1958 (I / O interface). Device 1900 can operate on an operating system, such as Windows Server, stored in memory 1932. TM macOS X TM Unix TM Linux TM FreeBSD TM Or similar.

[0218] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by a processing component 1922 of the device 1900 to perform the above-described method.

[0219] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0220] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A data transmission method based on a Kubernetes cluster, characterized in that, Applied to business Pods, the method includes: In response to a service Pod corresponding to a tenant identifier defined by a custom gateway policy transmitting data to a destination address, if a data identifier exists in the custom routing policy of the service Pod, the data and the data identifier are associated. The data after the associated data identifier is transmitted to the main gateway Pod according to the routing path indicated by the custom routing policy, so that the main gateway Pod transmits the data to the destination address according to the configured egress bandwidth limit corresponding to the data identifier. The routing path indicated by the custom routing policy indicates that the data after the associated data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod. The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

2. The method according to claim 1, characterized in that, The custom gateway policy also configures the target network segment for which the tenant needs to limit outbound bandwidth, so as to configure the correspondence between the target network segment and the data identifier in the custom routing policy and configure the correspondence between the data identifier and the outbound bandwidth limit in the main gateway Pod. The association of the data and the data identifier includes: If a data identifier corresponding to the target network segment exists in the custom routing policy of the service Pod and the destination address belongs to the target network segment, then associate the data with the data identifier.

3. The method according to claim 2, characterized in that, Also includes: If there is no correspondence between the target network segment and the data identifier in the custom routing policy of the service Pod, or if the destination address does not belong to the target network segment, the data is transmitted to the destination address based on the routing path indicated by the default routing policy. The routing path indicated by the default routing policy indicates that the data is transmitted to the main gateway Pod through the first virtual Ethernet interface in the service Pod and the second virtual Ethernet interface in the main gateway Pod, but not through the first virtual tunnel interface and the second virtual tunnel interface.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Obtain the Maximum Segment Size (MSS) value of the service Pod and the Final Maximum Transmission Unit (MTU) value of the second virtual tunnel interface in the service Pod; wherein, the final MTU value is determined based on the minimum of the first MTU value of the first virtual tunnel interface in the service Pod and the second MTU value of the second virtual tunnel interface in the main gateway Pod; the first MTU value is configured based on the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod and the number of bytes of the encapsulated packet header corresponding to the first virtual tunnel interface, and the first MTU value is negatively correlated with the number of bytes of the encapsulated packet header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface; the second MTU value is configured based on the MTU value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the main gateway Pod and the number of bytes of the encapsulated packet header corresponding to the second virtual tunnel interface, and the second MTU value is negatively correlated with the number of bytes of the encapsulated packet header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface; the MSS value is configured based on the final MTU value, the number of bytes of the IP header, and the number of bytes of the TCP header; The association of the data and the data identifier includes: when the data volume is greater than the MSS value, segmenting and encapsulating the data according to the MSS value to obtain segmented and encapsulated data; setting the data identifier for the segmented and encapsulated data to obtain the data associated with the data identifier; And / or, The transmission of the data after the control association data identifier to the main gateway Pod according to the routing path indicated by the custom routing policy includes: when the data volume of the data after the association data identifier is greater than the final MTU value of the service Pod, the data after the association data identifier is segmented and encapsulated according to the final MTU value and then transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface.

5. A data transmission method based on a Kubernetes cluster, characterized in that, Applied to the main gateway Pod, the method includes: In response to receiving data with associated data identifier transmitted from a service Pod with a tenant identifier corresponding to a custom gateway policy definition via the first virtual tunnel interface in the service Pod and the second virtual tunnel interface in the main gateway Pod, the data is transmitted to the destination address according to the egress bandwidth limit corresponding to the data identifier pre-configured in the main gateway Pod; The data after the associated data identifier is obtained by the service Pod in response to transmitting data to the destination address, by associating the data with the data identifier in the service Pod's custom routing policy; The tenant identifier and the upper limit of the outbound bandwidth of the tenant that need to limit the outbound bandwidth are pre-configured in the custom gateway policy in the Kubernetes cluster. This is used to configure the first virtual tunnel interface, the data identifier in the custom routing policy, and the routing path in the service Pod corresponding to the tenant identifier. The custom gateway policy is also pre-configured with relevant information of the main gateway Pod, which is used to indicate the correspondence between the second virtual tunnel interface and the data identifier and the upper limit of the outbound bandwidth in the main gateway Pod.

6. The method according to claim 5, characterized in that, The custom gateway policy is also configured with the target network segment for which the tenant needs to limit the outbound bandwidth, so as to configure the correspondence between the target network segment and the data identifier in the custom routing policy and configure the correspondence between the data identifier, the target network segment and the outbound bandwidth limit in the main gateway Pod, wherein the destination address belongs to the target network segment.

7. A data transmission method for a Kubernetes cluster, characterized in that, The method, executed by the node controller, includes: Obtain the custom gateway policy configured in the Kubernetes cluster. The custom gateway policy includes: the tenant identifier of the tenant whose outbound bandwidth needs to be restricted, the outbound bandwidth limit corresponding to the tenant identifier, and the relevant information of the gateway Pod, wherein the gateway Pod includes at least the main gateway Pod. Configure the first virtual tunnel interface in the service Pod corresponding to the tenant identifier indicated by the custom gateway policy; Configure a second virtual tunnel interface in the gateway Pod according to the relevant information of the gateway Pod indicated by the custom gateway policy; According to the custom gateway policy, a custom routing policy is configured in the service Pod, including: generating a data identifier for the service Pod, associating the data identifier with data transmitted by the service Pod to a destination address, and generating a routing path to indicate that the data after associating the data identifier is transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface; Configure the correspondence between the data identifier and the egress bandwidth limit in the gateway Pod to instruct the gateway Pod to transmit the data associated with the data identifier to the destination address according to the egress bandwidth limit.

8. The method according to claim 7, characterized in that, The custom gateway policy also includes: the target network segment for which the tenant needs to restrict the outbound bandwidth; Configuring a custom routing policy in the service Pod also includes: Configure the mapping relationship between the target network segment and the data identifier in the service Pod, so as to associate the data and the data identifier when the destination address of the data belongs to the target network segment.

9. The method according to claim 7, characterized in that, The gateway Pod also includes backup gateway Pods other than the primary gateway Pod. The relevant information of the gateway Pod includes primary gateway indication information; the primary gateway indication information is used to indicate the current primary gateway Pod in the gateway Pod. The method further includes: When the gateway status of the primary gateway Pod indicates that the primary gateway Pod is in an unavailable state, a primary gateway change instruction is sent to the gateway controller. The primary gateway change instruction is used to trigger the gateway controller to switch the standby gateway Pod, which is in an available state, to the new primary gateway Pod, and update the primary gateway indication information so that the primary gateway indication information indicates that the new primary gateway Pod is the current primary gateway Pod. In response to the update of the main gateway indication information, the second virtual tunnel interface indicated by the routing path in the service Pod is updated to the second virtual tunnel interface in the new main gateway Pod.

10. The method according to claim 9, characterized in that, After sending a gateway change indication to the gateway controller when the gateway status of the primary gateway Pod indicates that the primary gateway Pod is unavailable, the method further includes: If the gateway controller reports that all backup gateway Pods are unavailable, the data identifier in the custom routing policy of the service Pod is deleted, so that the service Pod transmits the data to the destination address based on the routing path indicated by the default routing policy. The routing path indicated by the default routing policy means that the data is transmitted to the main gateway Pod through the first virtual Ethernet interface in the service Pod and the second virtual Ethernet interface in the main gateway Pod, but not through the first virtual tunnel interface and the second virtual tunnel interface.

11. The method according to any one of claims 7-10, characterized in that, The method further includes: Obtain the maximum transmission unit (MTU) value of the second virtual Ethernet interface in the routing path indicated by the default routing policy in the gateway Pod; Based on the MTU value of the second virtual Ethernet interface and the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface, configure the second MTU value of the second virtual tunnel interface in the gateway Pod, wherein the second MTU value is negatively correlated with the number of bytes in the encapsulated packet header corresponding to the second virtual tunnel interface and positively correlated with the MTU value of the second virtual Ethernet interface; Obtain the MTU value of the first virtual Ethernet interface in the routing path indicated by the default routing policy in the service Pod; Based on the MTU value of the first virtual Ethernet interface and the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface, the first MTU value of the first virtual tunnel interface in the service Pod is determined, wherein the first MTU value is negatively correlated with the number of bytes in the encapsulated header corresponding to the first virtual tunnel interface and positively correlated with the MTU value of the first virtual Ethernet interface. Based on the minimum of the first MTU value and the second MTU value, configure the final MTU value of the second virtual tunnel interface in the service Pod. If the final MTU value is less than the data volume of the data after the associated data identifier, the data after the associated data identifier is segmented and encapsulated according to the final MTU value and then transmitted to the main gateway Pod via the first virtual tunnel interface and the second virtual tunnel interface. Based on the final MTU value, IP header byte count, and TCP header byte count of the second virtual tunnel interface in the service Pod, configure the maximum segment size (MSS) value of the service Pod. If the MSS value is less than the data volume, the data is segmented and encapsulated according to the MSS value to obtain segmented and encapsulated data. The data identifier is set for the segmented and encapsulated data to obtain the data with the associated data identifier.

12. A data transmission device based on a Kubernetes cluster, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method of any one of claims 1 to 4; or, to implement the method of claim 5 or 6; or, to implement the method of any one of claims 7 to 11.

13. A data transmission system based on a Kubernetes cluster, characterized in that, include: The business Pod is configured to execute the data transfer method as described in any one of claims 1 to 4; and The gateway Pod is configured to perform the data transfer method as described in any one of claims 5 to 6.

Images