Multi-tenant network isolation method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention discloses a multi-tenant network isolation method and device, equipment, a storage medium and a program product, and the method comprises the steps: determining a sub-cluster corresponding to a first tenant in a plurality of tenants in a kubernetes cluster; allocating an address field of a VLAN (Virtual Local Area Network) subnet to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant is in network isolation with a shared cluster in the kubernetes cluster and other sub-clusters in the kubernetes cluster; wherein the address fields corresponding to the plurality of tenants are different address fields.

Description

Technical Field

[0001] This application belongs to the field of cloud computing and relates to, but is not limited to, a multi-tenant network isolation method, apparatus, device, storage medium, and program product. Background Technology

[0002] In related technologies, mainstream intelligent computing clusters typically use Kubernetes clusters as their foundation, managing Graphics Processing Unit (GPU) resources and Remote Direct Memory Access (RDMA) networks. In public cloud scenarios, a shared Kubernetes cluster often needs resource isolation and is sold to multiple tenants as a dedicated cluster. However, current multi-tenant network isolation solutions for Kubernetes clusters only achieve isolation at the container service level, meaning their isolation performance is relatively low. Summary of the Invention

[0003] This application provides a multi-tenant network isolation method, apparatus, device, storage medium, and program product.

[0004] This application provides a multi-tenant network isolation method, the method comprising: In a Kubernetes cluster, determine the sub-cluster corresponding to the first tenant among multiple tenants; Assign a Virtual Local Area Network (VLAN) subnet address range to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant is isolated from the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein the address ranges corresponding to the multiple tenants are different address ranges.

[0005] This application also proposes a multi-tenant network isolation device, the device comprising: The determination module is used to determine the sub-cluster corresponding to the first tenant among multiple tenants in a Kubernetes cluster. The processing module is used to allocate VLAN subnet address ranges to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant can achieve network isolation from the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein the address ranges corresponding to the multiple tenants are different address ranges.

[0006] This application also provides an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor; wherein the processor is used to run the computer program to perform any of the above-described multi-tenant network isolation methods.

[0007] This application also provides a computer storage medium storing a computer program that, when executed by a processor, implements any of the above-described multi-tenant network isolation methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described multi-tenant network isolation methods.

[0009] As can be seen, this application embodiment can allocate VLAN subnet address ranges to the sub-cluster corresponding to the first tenant. In this way, the sub-cluster corresponding to the first tenant can access the network through the allocated address range. Since the address ranges corresponding to multiple tenants are different, network isolation can be achieved between the sub-cluster corresponding to the first tenant and the shared cluster in the Kubernetes cluster, as well as the sub-clusters corresponding to other tenants in the Kubernetes cluster. That is, the multi-tenant network isolation scheme of this application embodiment can achieve network-level isolation for the sub-cluster corresponding to the first tenant, the shared cluster in the Kubernetes cluster, and other sub-clusters in the Kubernetes cluster, improving isolation performance and security. For example, for different tenants using the parameter plane network, the address ranges used by the sub-clusters corresponding to different tenants when accessing the parameter plane network are different. Therefore, parameter plane network isolation can be achieved for the sub-clusters corresponding to different tenants. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the architecture for implementing multi-tenant network isolation in the embodiments of this application; Figure 2 This is a flowchart of a multi-tenant network isolation method according to an embodiment of this application; Figure 3 This is a first schematic diagram of multi-tenant network isolation information according to an embodiment of this application; Figure 4 A flowchart for creating a node in a sub-cluster provided in an embodiment of this application; Figure 5 This is a second schematic diagram of multi-tenant network isolation information according to an embodiment of this application; Figure 6 This is a third schematic diagram illustrating multi-tenant network isolation information in an embodiment of this application; Figure 7 A flowchart for removing a node from a sub-cluster provided in this application embodiment; Figure 8 This is a fourth schematic diagram illustrating multi-tenant network isolation information in an embodiment of this application; Figure 9 This is the fifth schematic diagram of multi-tenant network isolation information in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a multi-tenant network isolation device according to an embodiment of this application; Figure 11 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] In related technologies, multi-tenant network isolation schemes for Kubernetes clusters mainly include isolation schemes based on namespaces, virtual clusters, and network policies. For example, in the first technical solution of related technologies, the Kubernetes namespace can be used as a tenant representation, with each tenant allocated an independent namespace. Network isolation policies within the namespace are used to restrict network connectivity between different tenants, achieving isolation. However, this isolation scheme relies solely on the Container Network Interface (CNI) plugin to distribute isolation policies and can only isolate container networks. In contrast, the parameter plane network in an intelligent computing cluster is managed by an independent parameter plane network card access switch and is not controlled by the CNI plugin. Therefore, the first technical solution of related technologies cannot achieve isolation for multi-tenant parameter plane networks. Here, the parameter plane network can be used to implement parameter exchange between compute nodes.

[0012] In the second technical solution related to this technology, multi-tenant isolation of container clusters can be achieved through dedicated nodes. The management platform isolates independent nodes by tagging and tainting them, builds sub-clusters based on these isolated nodes, and assigns different sub-clusters to different tenants. This solution can effectively isolate computing resources, such as ensuring multi-tenant allocation of GPU resources in intelligent computing clusters. However, for parametric plane networks such as RDMA networks, multiple tenants still share the underlying physical network of the cluster, making effective isolation at the network level difficult. Furthermore, as the number of tenants increases, the management cost rises, making it difficult to achieve automated scaling and network isolation of configuration parameters in large-scale scenarios.

[0013] As can be seen from the foregoing, for container clusters in current intelligent computing scenarios, the multi-tenant network isolation solutions of relevant technologies have at least the following problems: 1) Insufficient parameter network isolation. The relevant solutions can only achieve isolation at the container service level, but for high-performance RDMA parameter network scenarios, they cannot achieve sufficient isolation, especially when multiple tenants share the network, both security and performance are affected. 2) Scalability issues. Although isolation solutions based on virtual clusters and multi-clusters can isolate multi-tenant scenarios at the resource level and provide dedicated cluster delivery, they cannot isolate multi-tenants at the network level. At the same time, with the increase in management costs, it is difficult to achieve automated expansion and configuration parameter network isolation in large-scale scenarios.

[0014] In view of the technical problems existing in related technologies, this application proposes technical solutions based on its embodiments.

[0015] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0016] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0017] The multi-tenant network isolation method provided in this application includes a series of steps, but the multi-tenant network isolation method provided in this application is not limited to the steps described. Similarly, the multi-tenant network isolation device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, but may also include modules that need to be set up for obtaining relevant information or processing based on information.

[0018] The multi-tenant network isolation method in this application embodiment can achieve multi-tenant network isolation for Kubernetes clusters, refer to... Figure 1A smart computing cluster can include a spine switch, leaf switches, and multiple smart computing servers. A Kubernetes cluster built upon these smart computing servers can be managed through a multi-cluster controller and a multi-tenant isolation controller. The multi-cluster controller can generate a dedicated sub-cluster for each tenant. For example, dedicated sub-cluster 1 to dedicated sub-cluster N represent sub-clusters created for different tenants, where N is an integer greater than 1. The parameter network switch controller can manage the spine switches and leaf switches.

[0019] Figure 2 This is a flowchart of a multi-tenant network isolation method according to an embodiment of this application, such as... Figure 2 As shown, the process includes: Step 201: In the Kubernetes cluster, determine the sub-cluster corresponding to the first tenant among multiple tenants.

[0020] Here, the first tenant can be any one of multiple tenants. The sub-cluster corresponding to the first tenant can include one or more nodes, and the nodes in the sub-cluster can be compute nodes, etc. If the sub-cluster corresponding to the first tenant does not exist, it can be created in the Kubernetes cluster. For example, multiple sub-clusters can be created for each of the multiple tenants, and the sub-clusters corresponding to different tenants are different sub-clusters. After creating the sub-clusters corresponding to the multiple tenants, the sub-cluster corresponding to the first tenant can be determined from the sub-clusters corresponding to the multiple tenants.

[0021] Step 202: Assign an address range of a VLAN subnet to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant is isolated from the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein, the address ranges corresponding to multiple tenants are different address ranges.

[0022] The address range of a VLAN subnet can be an Internet Protocol (IP) address range. In this embodiment, after allocating the VLAN subnet address range to the sub-cluster corresponding to the first tenant, the sub-cluster corresponding to the first tenant can access the parameter plane network or other networks through the corresponding address range. In practical applications, the parameter network switch controller can allocate the VLAN subnet address range to the sub-cluster corresponding to the first tenant.

[0023] A shared cluster in a Kubernetes cluster can be shared by multiple tenants. For example, if no sub-clusters are created in the Kubernetes cluster, then only the shared cluster exists in the Kubernetes cluster. Other sub-clusters in the Kubernetes cluster can be sub-clusters corresponding to other tenants, which are tenants other than the first tenant.

[0024] In practical applications, steps 201 to 202 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0025] As can be seen, this application embodiment can allocate VLAN subnet address ranges to the sub-cluster corresponding to the first tenant. In this way, the sub-cluster corresponding to the first tenant can access the network through the allocated address range. Since the address ranges corresponding to multiple tenants are different, network isolation can be achieved between the sub-cluster corresponding to the first tenant and the shared cluster in the Kubernetes cluster, as well as the sub-clusters corresponding to other tenants in the Kubernetes cluster. That is, the multi-tenant network isolation scheme of this application embodiment can achieve network-level isolation for the sub-cluster corresponding to the first tenant, the shared cluster in the Kubernetes cluster, and other sub-clusters in the Kubernetes cluster, improving isolation performance and security. For example, for different tenants using the parameter plane network, the address ranges used by the sub-clusters corresponding to different tenants when accessing the parameter plane network are different. Therefore, parameter plane network isolation can be achieved for the sub-clusters corresponding to different tenants.

[0026] In some embodiments, for allocating the address range of the VLAN subnet to the sub-cluster corresponding to the first tenant, a target VLAN identifier can be allocated for the sub-cluster corresponding to the first tenant; then, the address range of the VLAN subnet can be determined based on the target VLAN identifier.

[0027] Among these, different tenants have different VLAN identifiers, and different VLAN identifiers correspond to different address ranges.

[0028] In this embodiment, the target VLAN identifier can be an Identity Document (ID) or other types of identifiers. In practical applications, a unique identifier belonging to the first tenant can be generated for the sub-cluster corresponding to the first tenant; that is, the VLAN identifiers corresponding to other tenants are different from the target VLAN identifier.

[0029] For example, after assigning the target VLAN identifier, the address Add_Sub of the VLAN subnet can be calculated by combining the base address and the subnet size using a preset calculation method. Then, the address range of the VLAN subnet can be determined based on the address Add_Sub of the VLAN subnet. The address range of the VLAN subnet can be a / 24 subnet.

[0030] For example, the address of a VLAN subnet can be calculated using formula (1).

[0031] Add_Sub=B_A+(S_I*S_S)(1) Where B_A represents the base address, S_I is the VLAN ID, and S_S is the subnet size. In one example, the VLAN ID is 5, so an address range needs to be allocated to the fifth VLAN subnet; the base address B_A is 192.168.0.0, and the subnet size is 256. Therefore, the address of the fifth VLAN subnet, Add_Sub = 192.168.0.0 + (5 × 256) = 192.168.5.0. The address range of the fifth VLAN subnet is 192.168.5.0 / 24.

[0032] As can be seen, the embodiments of this application can assign different VLAN identifiers to sub-clusters corresponding to different tenants, and can also determine different address ranges for different VLAN identifiers. Therefore, it is possible to assign different address ranges to sub-clusters corresponding to different tenants, thereby enabling network isolation between the sub-cluster corresponding to the first tenant and other sub-clusters in the Kubernetes cluster, and enhancing the network isolation performance of multi-tenants.

[0033] In this embodiment, multi-tenant network isolation information can be determined according to a predefined parameter network isolation protocol, thereby achieving multi-tenant network isolation based on the multi-tenant network isolation information.

[0034] Reference Figure 3In multi-tenant network isolation information, the version field represents the protocol version number, facilitating future implementation of parameters for network isolation protocols. The isolation type field indicates the type of isolation action, which can be a cluster-level isolation type or a node-level isolation type. The isolation action field indicates the isolation action taken. For example, isolation actions can include creation, update, deletion, and recycling. For instance, for cluster-level isolation, the isolation action could be creating or deleting a sub-cluster, or recycling VLAN identifiers and VLAN subnet address ranges. When the isolation action is creating a sub-cluster, it indicates that the multi-cluster controller needs to allocate a new sub-cluster for tenant network isolation. For node-level isolation, the isolation action could be creating a node in a sub-cluster or removing a node from a sub-cluster. When the isolation action is creating a node in a sub-cluster, it indicates that nodes in the shared cluster need to be assigned to a specific sub-cluster. The timestamp indicates the creation or execution time of this isolation action.

[0035] Reference Figure 3 In multi-tenant network isolation information, the outer tenant ID represents a unique ID generated for a newly created tenant-specific sub-cluster. The outer tenant ID identifies the tenant and can serve as a label for the corresponding tenant's sub-cluster. When a sub-cluster is deleted, the corresponding outer tenant ID must also be deleted. The shared tenant ID represents the default shared ID of the shared cluster. Initially, all nodes in the Kubernetes cluster belong to the shared cluster, and tenants can use nodes within the shared cluster through the shared tenant ID. The VLAN ID can be an independent ID assigned by the multi-tenant isolation controller to each tenant-specific sub-cluster. Each VLAN ID is a unique identifier belonging to a tenant. When a tenant no longer uses the sub-cluster, it can delete the sub-cluster and reclaim the corresponding VLAN ID. The subnet address range can represent the address range assigned to each sub-cluster or the parameter network address assigned to nodes within the sub-cluster. Reserved fields reserve space for future feature expansions, facilitating protocol evolution in subsequent versions.

[0036] In multi-tenant sales scenarios, considering the conflict and performance issues when multiple users order concurrently, a VLAN ID uniqueness guarantee mechanism and a dynamic recycling mechanism can be designed for the parameter network isolation protocol, which can efficiently allocate a unique VLAN subnet address range to each tenant.

[0037] For example, the VLAN ID uniqueness guarantee mechanism can be implemented based on the VLAN ID status manager, the verification policy during tenant registration, and the prefix allocation policy.

[0038] In this embodiment, a centralized VLAN ID status manager can be created to maintain a mapping relationship between an available VLAN ID list and allocated VLAN IDs. Each time a VLAN ID is allocated, a VLAN ID is retrieved from the available VLAN ID list and marked as allocated. The mapping relationship of allocated VLAN IDs can represent the mapping relationship between VLAN IDs and tenant identifiers (e.g., outer tenant IDs).

[0039] When a tenant registers, the multi-tenant isolation controller first queries the VLAN ID status manager to determine whether the VLAN ID requested by the tenant conflicts with an existing tenant. If a conflict exists, it can automatically search for the next available VLAN ID in the list of available VLAN IDs.

[0040] When assigning VLAN IDs to each tenant, VLAN IDs can be assigned based on a prefix allocation policy. For example, different VLAN ID prefixes can be reserved for different types of tenants (such as large customers, small customers, etc.) to further reduce the possibility of VLAN ID conflicts; for example, large customers can use VLAN IDs with prefixes of 1000-2000, while small customers can use VLAN IDs with prefixes of 2001-3000.

[0041] As can be seen from the foregoing description, the embodiments of this application can remove nodes from sub-clusters. In some embodiments, when no node exists in the sub-cluster, the target VLAN identifier allocated to the sub-cluster corresponding to the first tenant can be reclaimed, allowing the target VLAN identifier to be allocated to other sub-clusters in the Kubernetes cluster.

[0042] As can be seen, if the sub-cluster corresponding to the first tenant does not have any nodes, it can be assumed that the first tenant does not have a need to use nodes in the Kubernetes cluster. In this case, the effective utilization of the target VLAN tag can be achieved by reclaiming the target VLAN tag allocated to the sub-cluster corresponding to the first tenant.

[0043] Regarding the implementation of reclaiming target VLAN identifiers, in some embodiments, the target VLAN identifier is reclaimed in response to the absence of resources and data flows associated with the sub-cluster; or, the target VLAN identifier is added to the list to be reclaimed, the VLAN identifiers in the list to be reclaimed are checked periodically, and the target VLAN identifier is reclaimed when the target VLAN identifier in the list to be reclaimed is not used by any tenant's corresponding sub-cluster.

[0044] In practical applications, when a tenant deletes the sub-cluster corresponding to the first tenant, the target VLAN can be added to the list to be reclaimed, and the supply of resources related to the sub-cluster and the transmission of data streams related to the sub-cluster can be stopped. When there are no resources and data streams related to the sub-cluster, the target VLAN identifier can be reclaimed.

[0045] When adding a target VLAN tag to the list to be reclaimed, it is possible to periodically check at preset time intervals whether the VLAN tag in the list is being used by any tenant's sub-cluster. If the VLAN tag in the list is being used by any tenant's sub-cluster, then the corresponding VLAN tag will not be reclaimed; if the VLAN tag in the list is not being used by any tenant's sub-cluster, then the corresponding VLAN tag can be reclaimed.

[0046] As can be seen, the embodiments of this application can reclaim the target VLAN identifier when it is determined that there are no resources and data flows related to the sub-cluster, which helps to avoid potential resource contention and conflicts. When the target VLAN identifier in the list to be reclaimed is not used by any tenant's corresponding sub-cluster, it can be considered that the target VLAN identifier cannot provide any value to any tenant. At this time, the reliable reclamation of the target VLAN identifier can be achieved.

[0047] In this embodiment, the multi-tenant isolation controller can obtain a request to allocate a VLAN identifier, and select a VLAN identifier to be allocated based on the request, thereby realizing the allocation of the VLAN identifier. In some embodiments, if no node exists in the sub-cluster, the target VLAN identifier can be added to the list to be reclaimed; in response to receiving a request to allocate a VLAN identifier within a set time period, a VLAN identifier to be allocated is selected from the list to be reclaimed.

[0048] Here, the set duration can be a preset short delay time, for example, a set duration of 20 seconds, 30 seconds or 40 seconds.

[0049] As can be seen, after adding the target VLAN identifier to the list to be reclaimed, if a request to allocate a VLAN identifier is received within a set time period, the VLAN identifier to be allocated can be selected from the list to be reclaimed first. Since the VLAN identifiers in the list to be reclaimed are already allocated VLAN identifiers, this embodiment of the application can effectively improve the utilization rate of already allocated VLAN identifiers and avoid frequently generating new VLAN identifiers to a certain extent.

[0050] For example, a dynamic recycling mechanism can be implemented based on a recycling tagging mechanism, a delayed recycling strategy, and an automated review strategy.

[0051] The following explains the recycling marking mechanism. Taking the target VLAN identifier as the first VLAN ID as an example, when the first tenant deletes the sub-cluster corresponding to the first tenant, the first VLAN ID can first be marked as recyclable, instead of being deleted immediately. The multi-tenant isolation controller can add the first VLAN ID to the list to be recycled. After confirming that there are no resources and data flows related to the sub-cluster corresponding to the first tenant, the first VLAN ID will be recycled. This can avoid potential resource contention and conflicts to a certain extent.

[0052] The delayed VLAN ID recycling strategy is explained below. When a tenant deletes a sub-cluster, if a request to allocate a VLAN ID is received within a set time period, the VLAN ID in the recycling list will be used first. This can effectively improve the utilization rate of the allocated VLAN IDs and avoid the frequent generation of new VLAN IDs to a certain extent.

[0053] The automated auditing strategy is explained below. By periodically checking the list of VLAN IDs to be reclaimed, it is ensured that no tenant is using the VLAN ID before reclaiming it.

[0054] As described above, this application proposes a general parameter network isolation protocol for intelligent computing clusters at the parameter network layer. This protocol allows for the design of key fields in multi-tenant scenarios for intelligent computing clusters, such as outer tenant ID, shared tenant ID, isolation type, isolation action, VLAN ID, and subnet address range. This application also includes a VLAN ID uniqueness guarantee mechanism and a dynamic recycling mechanism.

[0055] This application embodiment can realize the creation of sub-clusters. In some embodiments, after marking the first node as a node dedicated to the first tenant, in response to the absence of other nodes dedicated to the first tenant in the Kubernetes cluster, a sub-cluster corresponding to the first tenant can be created. After creating the sub-cluster corresponding to the first tenant, an identifier for the first tenant can be created and used as the label of the sub-cluster; wherein, the identifiers of different tenants among multiple tenants are different identifiers.

[0056] The first node can be a node in a Kubernetes cluster; for example, the first node is a node in a shared cluster. In practical applications, the first node can be marked as a node dedicated to the first tenant by tagging or other methods.

[0057] If there are other nodes in the Kubernetes cluster that are dedicated to the first tenant, it means that the sub-cluster corresponding to the first tenant has already been created. If there are no other nodes in the Kubernetes cluster that are dedicated to the first tenant, it means that the sub-cluster corresponding to the first tenant has not yet been created. In this case, the sub-cluster corresponding to the first tenant can be created. The sub-cluster corresponding to the first tenant is different from the shared cluster in the Kubernetes cluster. It is a tenant-exclusive sub-cluster of the first tenant and can only be used by the first tenant.

[0058] Here, the identifier of the first tenant can be an ID or other type of identifier. For example, the identifier of the first tenant is the outer tenant ID described above. The identifier of the first tenant is a unique identifier belonging to the first tenant; that is, different tenants will not use the same identifier.

[0059] As can be seen, if there are no other nodes in the Kubernetes cluster dedicated to the first tenant, creating a sub-cluster corresponding to the first tenant among multiple tenants facilitates the subsequent addition of the first node to the sub-cluster corresponding to the first tenant. Furthermore, by using the first tenant's identifier as the label of the sub-cluster, an association can be established between the first tenant and the sub-cluster, which is beneficial for the effective management of the nodes in the sub-cluster corresponding to the first tenant based on the first tenant's identifier.

[0060] Of course, in other embodiments, other methods can be used to establish the label of the sub-cluster corresponding to the first tenant. The embodiments of this application do not limit the method of establishing the label of the sub-cluster.

[0061] In some embodiments, after marking the first node as a node belonging exclusively to the first tenant, in response to the existence of other nodes belonging exclusively to the first tenant in the Kubernetes cluster, the first node can be added to the sub-cluster corresponding to the first tenant, the address range corresponding to the first tenant can be determined according to the identifier of the first tenant, and a subnet address can be allocated to the first node in the address range corresponding to the first tenant.

[0062] In practice, when the first node is a node in a shared cluster, if there are other nodes in the Kubernetes cluster that belong exclusively to the first tenant, the first node can be migrated from the shared cluster to the sub-cluster corresponding to the first tenant.

[0063] Here, the address range corresponding to the first tenant can be: the address range of the VLAN subnet allocated to the sub-cluster corresponding to the first tenant; in practical applications, an unallocated subnet address can be selected from the address range corresponding to the first tenant, and the selected address can be used as the subnet address allocated to the first node.

[0064] As can be seen, by adding a first node to the sub-cluster corresponding to the first tenant, the sub-cluster corresponding to the first tenant can be expanded, which is beneficial to improving the data processing capability of the sub-cluster corresponding to the first tenant. By assigning a subnet address to the first node in the address range corresponding to the first tenant, the first node can access the network based on the subnet address, and different nodes in the same sub-cluster can maintain communication through the same address range.

[0065] This application embodiment can also realize the removal of nodes from a sub-cluster. In some embodiments, after determining the second node to be removed from the sub-cluster, the second node is migrated from the sub-cluster to the shared cluster of the Kubernetes cluster, and the subnet address allocated to the second node is modified to the network address used by the shared cluster.

[0066] For example, after determining the second node to be removed from the sub-cluster, the network address information (e.g., IP address) of the second node can be reconfigured. For instance, the network address of the second node can be reconfigured to the network address initially set by the second node in the shared cluster, so that the second node can achieve network communication with other clusters in the shared cluster.

[0067] In practical applications, the second node can be marked as a node to be moved out of the sub-cluster corresponding to the first tenant by tagging or other methods.

[0068] As can be seen, by migrating the second node from the aforementioned sub-cluster to the shared cluster of the Kubernetes cluster, the sub-cluster corresponding to the first tenant can be scaled down, which is beneficial to improving the data processing capabilities of the shared cluster.

[0069] In this embodiment, multi-tenant network isolation can be achieved by creating nodes in a sub-cluster or removing nodes from a sub-cluster. The following description, in conjunction with the accompanying drawings, illustrates the processes for creating nodes in a sub-cluster and removing nodes from a sub-cluster.

[0070] Figure 4 The flowchart for creating a node in a sub-cluster provided in the embodiments of this application is as follows: Figure 4 As shown, the process includes: Step 41: Mark the first node as a node belonging exclusively to the first tenant.

[0071] In practical applications, administrators can mark the first node in the default shared cluster as a node belonging exclusively to the first tenant by tagging or other methods.

[0072] Step 42: Determine if there are other nodes in the Kubernetes cluster that belong exclusively to the first tenant. If not, proceed to step 43; if yes, proceed to step 44.

[0073] In practical applications, the multi-tenant isolation controller can monitor the status of nodes in the shared cluster through a list-watch mechanism. When a new node is detected and tagged, it can determine whether there are other nodes in the Kubernetes cluster that belong exclusively to the first tenant. If there are no other nodes in the Kubernetes cluster that belong exclusively to the first tenant, it is considered that a sub-cluster corresponding to the first tenant needs to be created, and a new parameter plane VLAN subnet needs to be reallocated to the first node. In this case, step 43 can be executed. If there are other nodes in the Kubernetes cluster that belong exclusively to the first tenant, it is considered that the first node needs to be expanded into the first sub-cluster, and there is no need to reallocate a new parameter plane VLAN subnet to the first node. In this case, step 44 can be executed.

[0074] Step 43: Create the identifier for the first tenant and the first sub-cluster, then proceed to step 45.

[0075] The identifier for the first tenant can be a VLAN ID, and the first sub-cluster is the sub-cluster corresponding to the first tenant. In practical applications, the controller can sequentially assign a unique VLAN ID to each tenant from a local preset address pool, and allocate a / 24 subnet segment corresponding to the unique VLAN ID from the local preset address pool; then, it can be based on... Figure 5 The fields shown create the first sub-cluster.

[0076] Step 44: Expand the first node to the first sub-cluster, and then execute step 45.

[0077] In practical applications, a parameter network address for the first node can be directly assigned sequentially from the VLAN subnet corresponding to the first sub-cluster. For example, you can refer to... Figure 6 Assign a competition network address to the first node and add the first node to the first sub-cluster.

[0078] Step 45: Execute the isolation configuration task for the parameter network, and then end the process.

[0079] In practical applications, the multi-tenant isolation controller, by default, starts a background asynchronous process to monitor the isolation configuration tasks for parameter networks in the task queue. After the subnet allocation and node address allocation for the sub-cluster are completed, the task configuration center starts the isolation configuration task for the parameter network. First, it calls the command-line tool on the cluster node to modify and refresh the address information of the parameter network card according to the subnet address assigned to the node. Then, it calls the northbound interface of the parameter network switch controller to send subnet configuration information, node configuration information, access control list (ACL) isolation policies, etc., to the switch. At the same time, it calls the configuration agent node on the shared cluster node to configure the new address of the node's parameter network card to the node's parameter network card through command-line configuration. For example, the subnet configuration information can be subnet address, the node configuration information can be the node's media access control (MAC) address, node identifier, etc., and the ACL isolation policy can be the network isolation policy adopted by the switch.

[0080] After executing the parameter network isolation configuration task, the parameter network configuration information of the nodes in the tenant sub-cluster and the configuration information of the parameter plane switch are consistent. The parameter network of this sub-cluster and the parameter network of the shared cluster are isolated. At the same time, the parameter networks of the nodes within the sub-cluster are in the same VLAN subnet and maintain communication.

[0081] Figure 7 The flowchart for removing a node from a sub-cluster provided in this application embodiment is as follows: Figure 7 As shown, the process includes: Step 71: Determine the second node to be removed from the first sub-cluster.

[0082] The second node can be any node in the first sub-cluster. In practice, administrators can mark the second node in the first sub-cluster as a node that needs to be migrated to the shared cluster by tagging or other methods.

[0083] Step 72: Migrate the second node to the shared cluster.

[0084] In practical applications, multi-tenant isolation controllers can use a list-watch mechanism to monitor the status of nodes in the first sub-cluster. When a new node (such as a second node) is detected that needs to be removed from the first sub-cluster, it can refer to... Figure 8 The fields shown indicate that the second node will be migrated to the shared cluster.

[0085] Step 73: Configure the parameter plane network card address of the second node.

[0086] Here, the multi-tenant isolation controller can allocate new parameter plane address information from the shared cluster parameter plane subnet, call the northbound interface of the parameter network switch controller, and issue node configuration information and ACL isolation policies; at the same time, it calls the node command line configuration to configure the parameter network address of the node in the shared cluster to the parameter plane network card of the second node.

[0087] After steps 72 and 73, the parameter plane network corresponding to the second node is reassigned to the default parameter plane subnet, and the node network information and switch configuration information are made consistent again. The second node communicates with the parameter network of the shared cluster and maintains network isolation from other sub-clusters.

[0088] Step 74: Determine if there are any nodes in the first sub-cluster. If not, proceed to step 75; if yes, proceed to step 76.

[0089] In practical applications, if no node exists in the first sub-cluster, it means that the first sub-cluster is no longer providing services to the tenant. In this case, step 75 can be executed. If other nodes still exist in the first sub-cluster, the subnet address corresponding to the second node needs to be reclaimed. In this case, step 76 can be executed.

[0090] Step 75: Delete the first sub-cluster and reclaim the corresponding VLAN ID and subnet address range, then end the process.

[0091] In practical applications, you can refer to Figure 9 The fields shown indicate the VLAN ID and subnet address range to be recycled.

[0092] Step 76: Reclaim the subnet address corresponding to the second node, and then end the process.

[0093] This application proposes a general parameter network isolation protocol to define the configuration and actions of parameter network isolation in multi-tenant clusters. Through a mechanism of dynamically allocating and reclaiming tenant subnets, the uniqueness of multi-tenant parameter network subnets is guaranteed. Based on this protocol, a specific implementation method for multi-tenant parameter network isolation in intelligent computing clusters is designed and implemented. Specifically, the multi-cluster controller, using nodes as the dimension, completes the creation, deletion, scaling, and resizing operations of tenant-specific sub-clusters. Furthermore, the tenant isolation controller can dynamically allocate, reclaim, and configure the parameter networks of tenant-specific sub-clusters, thereby solving the two technical problems mentioned above in related technologies.

[0094] Based on the aforementioned parameter network isolation protocol, this application proposes a specific implementation method for achieving multi-tenant network isolation in a Kubernetes intelligent computing cluster. This application embodiment can implement operations such as creating, scaling up, and removing tenant-specific sub-clusters, and dynamically allocates, reclaims, and configures the parameter network of the tenant-specific sub-clusters.

[0095] In summary, this application proposes a parameter network isolation protocol for intelligent computing clusters in multi-tenant scenarios. This protocol achieves true parameter network isolation and provides a mechanism for unique allocation and dynamic recycling of tenant parameter networks, effectively ensuring the isolation and high performance of multi-tenant parameter networks. Furthermore, based on the parameter network isolation protocol and using the Kubernetes controller model, the creation and deletion of dedicated multi-tenant sub-clusters can be automatically controlled. Moreover, the dynamic allocation, recycling, and configuration of sub-cluster parameter networks can be automatically performed, significantly reducing the need for manual operation and configuration by administrators and effectively improving scalability.

[0096] For intelligent computing platforms deployed in public clouds, the technical solutions of this application embodiment can be adopted, thus, this application embodiment has high commercial value. Firstly, the technical solutions of this application embodiment have the advantage of cost reduction and efficiency improvement. In multi-tenant sales scenarios, it is not necessary to obtain a dedicated intelligent computing cluster by independently ordering a complete cluster. Instead, a dedicated sub-cluster with parameter network isolation is dynamically created within a shared Kubernetes cluster, and the dedicated sub-cluster is delivered to the user. This saves control plane computing resource costs and effectively improves cluster delivery efficiency compared to independently ordering clusters. Secondly, the technical solutions of this application embodiment have the advantage of wide applicability. The parameter network isolation scheme proposed in this application embodiment is a general implementation scheme. It can not only interface with other open-source multi-cluster tools, such as multi-cluster management through integration with Kosmos and other cluster tools, but also interface with parameter plane configuration logic from different vendors. The parameter plane configuration logic can be the configuration logic of a parameter plane RDMA network.

[0097] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0098] Figure 10 This is a schematic diagram of the structure of a multi-tenant network isolation device according to an embodiment of this application, as shown below. Figure 10 As shown, the device includes: Module 1001 is used to determine the sub-cluster corresponding to the first tenant among multiple tenants in a Kubernetes cluster. The processing module 1002 is used to allocate a virtual local area network (VLAN) subnet address range to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant can achieve network isolation with the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein the address ranges corresponding to the multiple tenants are different address ranges.

[0099] In some embodiments, the processing module 1002 is specifically used to allocate a target VLAN identifier for the sub-cluster corresponding to the first tenant; and determine the address range of the VLAN subnet based on the target VLAN identifier; wherein, the VLAN identifiers corresponding to different tenants among the multiple tenants are different identifiers, and the address ranges corresponding to different VLAN identifiers are different address ranges.

[0100] In some embodiments, the processing module 1002 is further configured to, after marking the first node as a node belonging exclusively to the first tenant, in response to the absence of other nodes belonging exclusively to the first tenant in the Kubernetes cluster, create a sub-cluster corresponding to the first tenant and an identifier of the first tenant, and use the identifier of the first tenant as a label for the sub-cluster; wherein, the identifiers of different tenants among the plurality of tenants are different identifiers.

[0101] In some embodiments, the processing module 1002 is further configured to, after marking the first node as a node belonging exclusively to the first tenant, add the first node to the sub-cluster corresponding to the first tenant in response to the existence of other nodes belonging exclusively to the first tenant in the Kubernetes cluster, determine the address range corresponding to the first tenant based on the identifier of the first tenant, and allocate a subnet address to the first node in the address range corresponding to the first tenant.

[0102] In some embodiments, the processing module 1002 is further configured to, after determining the second node to be removed from the sub-cluster, migrate the second node from the sub-cluster to the shared cluster of the Kubernetes cluster, and modify the subnet address allocated to the second node to the network address used by the shared cluster.

[0103] In some embodiments, the processing module 1002 is further configured to reclaim the target VLAN identifier allocated to the sub-cluster corresponding to the first tenant when no node exists in the sub-cluster, so that the target VLAN identifier can be allocated to other sub-clusters in the Kubernetes cluster.

[0104] In some embodiments, the processing module 1002 is specifically configured to reclaim the target VLAN identifier in response to the absence of resources and data flows associated with the sub-cluster; or, add the target VLAN identifier to a list to be reclaimed, periodically detect the VLAN identifiers in the list to be reclaimed, and reclaim the target VLAN identifier when the target VLAN identifier in the list to be reclaimed is not used by any sub-cluster corresponding to any tenant.

[0105] In some embodiments, the processing module 1002 is further configured to add the target VLAN identifier to the list to be reclaimed when no node exists in the sub-cluster, wherein the target VLAN identifier is a VLAN identifier assigned to the sub-cluster corresponding to the first tenant; and to select a VLAN identifier to be assigned from the list to be reclaimed in response to a request to be obtained within a set time period.

[0106] In practical applications, the determination module 1001 and the processing module 1002 can be implemented based on a processor.

[0107] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0108] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0109] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the multi-tenant network isolation methods provided in this application embodiment.

[0110] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the multi-tenant network isolation methods provided in the above embodiments.

[0111] This application also provides an electronic device. Figure 11 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 11 As shown, the electronic device 110 may include: Memory 1101 is used to store executable instructions; The processor 1102 is used to implement any of the above-described multi-tenant network isolation methods when executing executable instructions stored in the memory 1101.

[0112] The processor 1102 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0113] The aforementioned computer-readable storage medium and memory 1101 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it may also be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0114] In some embodiments, the functions or modules of the apparatus provided in this application 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.

[0115] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0116] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0117] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0118] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0119] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0120] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the scope of protection of this application. All of these forms are within the protection scope of this application.

Claims

1. A multi-tenant network isolation method, characterized in that, The method includes: In a Kubernetes cluster, determine the sub-cluster corresponding to the first tenant among multiple tenants; Assign a VLAN subnet address range to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant is isolated from the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein the address ranges corresponding to the multiple tenants are different address ranges.

2. The multi-tenant network isolation method according to claim 1, characterized in that, The step of allocating a VLAN subnet address range to the sub-cluster corresponding to the first tenant includes: Assign a target virtual local area network (VLAN) identifier to the sub-cluster corresponding to the first tenant; The address range of the VLAN subnet is determined based on the target VLAN identifier; Among these multiple tenants, the VLAN identifiers corresponding to different tenants are different identifiers, and the address ranges corresponding to different VLAN identifiers are different address ranges.

3. The multi-tenant network isolation method according to claim 1, characterized in that, The method further includes: After marking the first node as a node belonging exclusively to the first tenant, in response to the absence of other nodes belonging exclusively to the first tenant in the Kubernetes cluster, a sub-cluster corresponding to the first tenant and an identifier for the first tenant are created, and the identifier of the first tenant is used as the label of the sub-cluster; wherein, the identifiers of different tenants among the multiple tenants are different identifiers.

4. The multi-tenant network isolation method according to claim 3, characterized in that, The method further includes: After marking the first node as a node dedicated to the first tenant, in response to the existence of other nodes dedicated to the first tenant in the Kubernetes cluster, the first node is added to the sub-cluster corresponding to the first tenant. The address range corresponding to the first tenant is determined according to the identifier of the first tenant, and a subnet address is allocated to the first node in the address range corresponding to the first tenant.

5. The multi-tenant network isolation method according to claim 1, characterized in that, The method further includes: After identifying the second node to be removed from the sub-cluster, the second node is migrated from the sub-cluster to the shared cluster of the Kubernetes cluster, and the subnet address assigned to the second node is modified to the network address used by the shared cluster.

6. The multi-tenant network isolation method according to claim 1, characterized in that, The method further includes: If no node exists in the sub-cluster, the target VLAN ID allocated to the sub-cluster corresponding to the first tenant is reclaimed, so that the target VLAN ID can be allocated to other sub-clusters in the Kubernetes cluster.

7. The multi-tenant network isolation method according to claim 6, characterized in that, The reclaiming of the target VLAN identifier allocated to the sub-cluster corresponding to the first tenant includes: In response to the absence of resources and data flows associated with the sub-cluster, the target VLAN ID is reclaimed; or, the target VLAN ID is added to a list to be reclaimed, and the VLAN IDs in the list to be reclaimed are periodically checked. When the target VLAN ID in the list to be reclaimed is not used by any tenant's corresponding sub-cluster, the target VLAN ID is reclaimed.

8. The multi-tenant network isolation method according to claim 1, characterized in that, The method further includes: If no node exists in the sub-cluster, the target VLAN ID is added to the list to be reclaimed. The target VLAN ID is the VLAN ID assigned to the sub-cluster corresponding to the first tenant. In response to a request to obtain a virtual LAN VLAN identifier within a set time period, a virtual LAN VLAN identifier to be assigned is selected from the list to be reclaimed.

9. A multi-tenant network isolation device, characterized in that, The device includes: The determination module is used to determine the sub-cluster corresponding to the first tenant among multiple tenants in a Kubernetes cluster. The processing module is used to allocate a VLAN subnet address range to the sub-cluster corresponding to the first tenant, so that the sub-cluster corresponding to the first tenant can achieve network isolation from the shared cluster in the Kubernetes cluster and other sub-clusters in the Kubernetes cluster; wherein the address ranges corresponding to the multiple tenants are different address ranges.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the multi-tenant network isolation method according to any one of claims 1 to 8.

11. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the multi-tenant network isolation method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the multi-tenant network isolation method according to any one of claims 1 to 8.

Images