A cloud desktop management system and deployment method, storage medium

Abstract

The embodiment of the application discloses a cloud desktop management system and method, and a storage medium, the system comprises: a container arrangement tool K8S control node and a working load node; the working load node is provided with a container engine; the K8S control node is used for allocating a K8S namespace for a first tenant system, and using the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein the multiple cloud desktops in the first tenant system run in one K8S namespace; the working load node is used for containerizing deployment of the cloud desktops corresponding to the first tenant system based on the allocated resources and the set access permissions by using the container engine, and running the cloud desktops completing the containerizing deployment in the K8S namespace.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a cloud desktop management system and deployment method, and storage medium. Background Technology

[0002] Cloud desktop is a desktop service based on cloud computing and virtualization technology. It is a new model that replaces traditional physical computer hosts. Cloud desktop provides virtual desktop environments and computing resources through cloud platforms, and has advantages such as low cost and high resource utilization.

[0003] In existing technologies, traditional virtual cloud desktops mainly adopt Virtual Desktop Infrastructure (VDI). This architecture centralizes all client data processing on the server side, which has high requirements for server performance, complex deployment steps, slow desktop release time, insufficient flexibility, and a lot of redundant software. Virtual machine software (VMware) centrally manages multiple desktops of a single tenant by developing tenant management software. However, as the scenario changes, user permission settings become more complex, and as the number of cloud desktops increases, the cluster system management and maintenance efficiency of cloud desktops of multiple tenants is low. Summary of the Invention

[0004] In view of this, the embodiments of this application aim to provide a cloud desktop management system and deployment method, as well as a storage medium, which can improve the management and maintenance efficiency of cloud desktops for multiple tenants.

[0005] To achieve the above objectives, the technical solution of this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a cloud desktop management system, which includes: a Kubernetes (K8S) container orchestration tool control node and workload nodes; a container engine is installed in the workload nodes;

[0007] The K8S control node is used to allocate a K8S namespace to the first tenant system, and to use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; multiple cloud desktops in the first tenant system run in one K8S namespace.

[0008] Workload nodes are used to deploy the containerized cloud desktops corresponding to the first tenant system using the container engine, based on allocated resources and access permissions, and to run the containerized cloud desktops in the K8S namespace.

[0009] Secondly, embodiments of this application provide a cloud desktop management system deployment method, applied to a K8S control node of the cloud desktop management system, the method comprising:

[0010] Allocate a K8S namespace for the first tenant system, and use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; run multiple cloud desktops of the first tenant system in a K8S namespace.

[0011] Thirdly, embodiments of this application provide a cloud desktop management system deployment method, applied to the workload nodes of the cloud desktop management system, the method comprising:

[0012] Based on the resources allocated and access permissions set by the K8S control node, the container engine is used to deploy the cloud desktop corresponding to the first tenant system in a containerized manner; and the containerized cloud desktop is run in the K8S namespace.

[0013] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described cloud desktop management system deployment method.

[0014] This application provides a cloud desktop management system, deployment method, and storage medium. The cloud desktop management system includes: a Kubernetes (K8S) control node and workload nodes; a container engine is installed on the workload nodes; the K8S control node is used to allocate a K8S namespace to a first tenant system, and to allocate resources and set access permissions for multiple cloud desktops in the first tenant system using the K8S namespace; wherein multiple cloud desktops in the first tenant system run in a K8S namespace; the workload nodes are used to perform containerized deployment of the cloud desktops corresponding to the first tenant system using the container engine based on the allocated resources and set access permissions, and to run the containerized cloud desktops in the K8S namespace. By adopting the above-mentioned cloud desktop management system implementation scheme, during the cloud desktop management process, by setting corresponding namespaces for tenant systems in the control node, multiple cloud desktops in different tenant systems are isolated in different namespaces. The set namespaces enable access control and resource allocation management for multiple cloud desktops of multiple tenants. Furthermore, Docker containers are used to deploy cloud desktops in the namespace corresponding to each tenant system on the workload nodes. Containerization deployment technology enables the rapid creation and deletion of cloud desktop containers. The cloud desktop management system deployed based on Kubernetes technology uses namespaces to isolate different tenants, manage permissions, and allocate resources for different tenants. By running cloud desktops through containerization technology, the management and maintenance efficiency of the cluster system of cloud desktops of multiple tenants can be improved. Attached Figure Description

[0015] Figure 1 A schematic diagram of a cloud desktop management system provided in this application embodiment. Figure 1 ;

[0016] Figure 2 A schematic diagram of a cloud desktop management system provided in this application embodiment. Figure 2 ;

[0017] Figure 3 A cloud desktop management system deployment method flow provided in this application embodiment Figure 1 ;

[0018] Figure 4 A cloud desktop management system deployment method flow provided in this application embodiment Figure 2 . Detailed Implementation

[0019] To gain a more detailed understanding of the features and technical content of the embodiments of this application, the technical solution of this application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The accompanying drawings are for reference only and are not intended to limit the embodiments of this application.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to be limiting of this application.

[0021] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. It should also be noted that the terms "first / second / third" used in the embodiments of this application are merely for distinguishing similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0022] This application provides a cloud desktop management system 1, such as... Figure 1 As shown, the cloud desktop management system 1 includes:

[0023] The container orchestration tool Kubernetes controls node 10 and workload node 11; the container engine is installed on workload node 11.

[0024] K8S control node 10 is used to allocate a K8S namespace to the first tenant system, and to use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein, multiple cloud desktops in the first tenant system run in one K8S namespace.

[0025] Workload node 11 is used to deploy the containerized cloud desktop corresponding to the first tenant system using the container engine based on the allocated resources and the access permissions set, and to run the containerized cloud desktop in the K8S namespace.

[0026] In this application embodiment, Kubernetes, also known as K8S, is an open-source container cluster management system used to manage containerized applications on multiple hosts in a cloud platform. The goal of K8S is to make the deployment of containerized applications simple and efficient. As a production-grade container orchestration system, K8S is suitable for various production environments and provides functions such as resource scheduling, application deployment, service discovery, monitoring, updating, and maintenance.

[0027] In this embodiment, the cloud desktop management system mainly consists of a K8S control node 10 and a workload node 11. The K8S control node is mainly responsible for the management of the entire cloud desktop management system, while the workload node is mainly responsible for running the cloud desktop business system.

[0028] It should be noted that cloud desktop is a desktop service based on cloud computing and virtualization technology. It is a new model to replace traditional computers. After adopting cloud desktop, users no longer need to purchase computer hosts. The CPU, memory, hard disk and other components contained in the host are all virtualized in the back-end server. A single high-performance server can virtualize 1 to 50 virtual hosts.

[0029] In this embodiment of the application, in order to isolate the cloud desktops of different tenant systems and to implement different resource allocation and permission management for different tenant systems and their corresponding cloud desktops, a K8S namespace is allocated to each tenant system through the K8S control node. Multiple cloud desktops corresponding to a single tenant can run in a K8S namespace.

[0030] In this application embodiment, a K8S namespace is a virtualized cluster in a K8S cluster. A K8S cluster can have multiple namespaces, which are logically isolated from each other. A K8S cluster resource is shared within a namespace. A namespace is a set of logical clusters that can achieve isolation of computing, network, storage, user permissions, etc.

[0031] For example, team A creates a namespace ta, and team A's projects are deployed and run in ta. Team B creates a namespace tb, and team B's projects are deployed and run in tb. This ensures that the projects of team A and team B are isolated from each other and do not affect each other. Furthermore, it allows specifying which users can access and which users cannot access a particular namespace.

[0032] In this embodiment, when the first tenant system needs to create a cloud desktop, the control node receives the request from the first tenant system to create a cloud desktop. The control node allocates a corresponding K8S namespace to the first tenant system through the namespace, and creates the cloud desktop corresponding to the first tenant system in the K8S namespace corresponding to the first tenant system. The allocated K8S namespace can be used to set up a multi-tenant environment. Through the created tenant isolation policy, one or more cloud desktops created by the first tenant system can be logically isolated, so that each tenant's cloud desktop runs in its own namespace.

[0033] In this embodiment of the application, by creating an independent namespace for each different tenant, different tenants are separated into their own namespaces. The namespaces are used to ensure that the cloud desktops of different tenants do not interfere with each other, and the cloud desktops within a tenant can be managed in a unified manner.

[0034] It should be noted that Kubernetes namespaces can isolate different tenant systems in different namespaces. Each tenant system in a namespace is a logical cluster. Namespaces can be used to achieve isolation between resource computing, network, storage, and user permissions.

[0035] In this embodiment of the application, after dividing the cloud desktops corresponding to multiple tenant systems into different namespaces, the cloud desktops between each tenant do not interfere with each other, while the cloud desktops within a tenant can be managed uniformly.

[0036] In this embodiment of the application, after the namespace allocation is completed, it is necessary to allocate resources for cloud desktops in different tenants in different namespaces and set access permissions for tenants. By using role-based access control (RBAC) in the K8S control node to set different user roles, user roles and permissions are associated, and corresponding permissions are set for each user role. Access control is achieved by setting the association between users and permissions, and resources can be allocated according to the number of cloud desktops in a namespace.

[0037] It's important to note that Role-Based Access Control (RBAC) establishes a set of roles between the user set and the permission set. Each role corresponds to a set of permissions. Once a user is assigned an appropriate role, that user possesses all the operational permissions for that role. The advantage of this approach is that it eliminates the need to assign permissions every time a user is created; only the corresponding role needs to be assigned. Furthermore, role permission changes are far less frequent than user permission changes, thus simplifying user permission management and reducing system overhead.

[0038] In this embodiment of the application, the control node can set cluster user roles to manage the corresponding cloud desktops of different tenants.

[0039] It should be noted that the cluster user role can be a cluster administrator, a namespace administrator, or a tenant administrator. Specifically, the role can be selected according to the actual situation, and no specific limitation is made in this application.

[0040] In this embodiment of the application, the cluster administrator can manage all tenant administrators and all namespace administrators throughout the cluster. The cluster administrator can also create, read, update, and delete any policy pairs.

[0041] For example, a cluster administrator can perform operations such as deleting or updating tenant administrators; they can also perform operations such as deleting or updating namespace administrators.

[0042] It should be noted that the policy pair can be a role-policy pair or a network-policy pair. No specific limitation is made in this application, and the choice can be made according to the actual situation.

[0043] In this embodiment of the application, the cluster administrator can also create namespaces and assign the created namespaces to namespace administrators.

[0044] In this embodiment, the namespace administrator is applicable to a specific single-tenant administrator. The namespace administrator can manage the tenants in its namespace and the cloud desktops corresponding to the tenants.

[0045] In this embodiment of the application, the tenant administrator can manage one or more cloud desktops corresponding to it.

[0046] In this embodiment of the application, by setting user roles and setting corresponding permissions for different user roles, it is possible to set access permissions for cloud desktops in different namespaces and set resource quotas according to the number of cloud desktops in the namespace.

[0047] For example, suppose tenant 1 is in namespace 1 and tenant 2 is in namespace 2. Namespace administrator 1 has management permissions for namespace 1. Therefore, the namespace administrator can only manage tenant 1 and the cloud desktop corresponding to tenant 1 in namespace 1. Similarly, if namespace administrator 2 only has management permissions for namespace 2, then the namespace administrator 2 can only manage tenant 2 and the cloud desktop corresponding to tenant 2 in namespace 2.

[0048] In this embodiment of the application, after a namespace is set up, multiple cloud desktops of a tenant are running in a namespace, and the corresponding administrator can allocate resources and set access permissions for the multiple cloud desktops corresponding to the tenant in a namespace.

[0049] In this embodiment of the application, after allocating corresponding permissions and resources to multiple cloud desktops of different tenant systems through different namespaces on the K8S control node, the containerized deployment of the cloud desktops corresponding to the tenant system can be carried out on the workload node based on the allocated resources and the set access permissions.

[0050] In this embodiment of the application, when deploying cloud desktops, the workload nodes are deployed on Windows hosts, and the workload nodes deployed on Windows hosts are the nodes that actually run the cloud desktop services.

[0051] In this embodiment of the application, since K8S technology orchestrates container clusters, in order to add a Windows host to the K8S cluster system as a workload node, a container engine needs to be installed and deployed on all hosts running cloud desktop containers in the cluster. Here, the container engine can be the Docker container engine.

[0052] It should be noted that Docker, the container engine, is currently the only container runtime tool that supports Windows systems and can manage the entire lifecycle of cloud desktop containers, including creation, operation, and deletion.

[0053] It should be noted that, due to the special nature of Windows and the immaturity of Windows virtualization technology, the command to add a Windows host as a workload node with one click using the Kubernetes automated deployment tool kubeadm is no longer applicable when using a Windows host as a workload node to run multiple cloud desktop containers.

[0054] It should be noted that kubeadm is a quick installation tool for setting up Kubernetes (K8S). It provides the initialization command `kubeadm init` and the addition command `kubeadm join` to quickly create a K8S cluster.

[0055] In this embodiment, a Windows host is used as a workload node to run multiple cloud desktop containers. After installing and deploying Docker on the container that needs to run the cloud desktop, a Windows version sandbox image, pause, is created on the Windows host after Docker is installed, based on the principle of strong consistency between the container's base image version and the host operating system version. The created pause image is used as the base image of the cloud desktop container and the startup process init to start the system.

[0056] In this embodiment, after the base image is created, an installation directory is prepared for the Windows nodes that need to be added to the cluster. The binary command-line component Kubectl, the node agent Kubelet, the network agent Kube-proxy, the startup script for joining the cluster, and the relevant installation configuration files are placed in the installation directory. Based on this installation directory, the installation script is run, and a Windows host that can run cloud desktop services can be added to the cluster.

[0057] In this embodiment of the application, in order to facilitate the management of workload nodes, it is also necessary to change the K8S component from the Windows process state to the Windows service state.

[0058] In this embodiment, after adding a workload node to the cluster to deploy the cloud desktop container, the cloud desktop system and related service software are packaged into an image file, the cloud desktop service is started using a Docker container, and the cloud desktop service container deployed on the Windows host is run through the Pod management object tool in the K8S workload node, thus completing the containerized deployment of the cloud desktop.

[0059] It should be noted that the relevant service software can be software that runs cloud desktop containers. Specifically, it can be selected according to the actual situation, and no specific limitation is made in this application.

[0060] It should be noted that the access permissions set on the namespace in the K8S control node can control whether tenants have permission to operate other cloud desktops. Resource allocation can specify which load node to deploy the cloud desktop container on and how much resource to allocate to that cloud desktop.

[0061] It should be noted that the Kubernetes-based multi-tenant cloud desktop management system solves the problems of difficult permission management, low resource utilization, and slow desktop deployment caused by a large number of tenants and desktops in cloud desktop services. The cloud desktop management system in this application allows multiple projects on a cloud desktop to run independently yet be managed uniformly, using the same set of resources without conflicts, making the management of permissions, resource configuration, and unified software deployment of multi-tenant cloud desktop systems easier.

[0062] Optionally, the system presets a system communication whitelist; the workload node is also used to obtain the cloud desktop address information of the first cloud desktop and transmit the cloud desktop address information to the K8S control node; the K8S control node is also used to add the cloud desktop address information to the storage location corresponding to the first tenant system in the system communication whitelist, and realize cloud desktop communication between the first tenant system and other tenant systems based on the system communication whitelist.

[0063] In this embodiment of the application, before adding the obtained address information of the cloud desktop to the storage location corresponding to the first tenant system in the system communication whitelist, the K8S control node also pre-sets a system communication whitelist, allowing the cloud desktops corresponding to the tenants in the system communication whitelist to communicate with each other.

[0064] In this embodiment, cloud desktops corresponding to different tenants are deployed on the workload node. The cloud desktops of different tenants run on their respective namespaces. Network communication between cloud desktops of a tenant isolated in a namespace is unrestricted. However, when different tenants in different namespaces need to achieve communication between cloud desktops, the workload node also needs to obtain the cloud desktop address information of the first cloud desktop on the workload node and send the obtained address information of the first cloud desktop to the K8S control node. The control node adds the obtained address information of the cloud desktop to the storage location corresponding to the first tenant system in the system communication whitelist, which can realize cross-tenant cloud desktop communication.

[0065] In this embodiment, to achieve communication between cloud desktops across tenants, the control node first creates a NetworkPolicy object. The NetworkPolicy object contains a whitelist of entry rules. The IP addresses and ports of the cloud desktops that need to communicate are added to the entry whitelist. Based on the IP addresses and port numbers of the cloud desktops that need to communicate, the network plugin Flannel is used to realize communication between the cloud desktops that need to communicate and are whitelisted in the created NetworkPolicy object.

[0066] In this application embodiment, the NetworkPolicy resource object is a specification of the communication rules allowed between Pods and with other network endpoints. The NetworkPolicy resource uses tags to select Pods and defines the communication rules allowed for the selected Pods.

[0067] In this embodiment, the network component Flannel can allocate different subnets to different workload nodes to enable cross-host communication between containers, thereby enabling communication across the entire K8S hierarchy.

[0068] It should be noted that the Flannel component runs on the workload node, and its dependent components are the storage component Etcd and the container engine Docker.

[0069] Optionally, the workload node is generated after the container engine is installed on the host, based on the K8S tools and preset settings information; the workload node is also used to package the cloud desktop system information and service software into an image file, and run the image file based on the scheduling unit Pod management object tool contained in the container engine and the K8S workload node to realize the containerized deployment of the cloud desktop.

[0070] In this embodiment, the workload nodes are deployed on a Windows host, and the workload nodes deployed on the Windows host are used to run the corresponding cloud desktop services.

[0071] In this embodiment of the application, since K8S technology orchestrates container clusters, in order to add a Windows host to the K8S cluster system as a workload node, a container engine needs to be installed and deployed on all hosts running cloud desktop containers in the cluster. Here, the container engine can be the container engine Docker.

[0072] It should be noted that Docker is currently the only container runtime tool that supports Windows systems and can manage the entire lifecycle of cloud desktop containers, including creation, operation, and deletion.

[0073] It should be noted that, due to the special nature of Windows and the immaturity of Windows virtualization technology, the command to add a Windows host as a workload node with one click using the Kubernetes automated deployment tool kubeadm is no longer applicable when using a Windows host as a workload node to run multiple cloud desktop containers.

[0074] It should be noted that Kubeadm is a quick installation tool for setting up Kubernetes (K8S). It provides the commands kubeadm init and kubeadm join to quickly create a K8S cluster.

[0075] In this embodiment, a Windows host is used as a workload node to run multiple cloud desktop containers. After installing and deploying Docker on the container that needs to run the cloud desktop, a Windows version of the pause image is created on the Windows host with Docker installed, based on the principle of strong consistency between the container's base image version and the host operating system version. The created pause image is used as the base image of the cloud desktop container and the init process to start the system.

[0076] In this embodiment, after the base image is created, an installation directory is prepared for the Windows nodes that need to be added to the cluster. The binary files Kubectl, Kubelet, and Kube-proxy, as well as the startup script for adding to the cluster and related installation configuration files are placed in the installation directory. Based on this installation directory, the installation script is run, and a Windows host that can run cloud desktop services can be added to the cluster.

[0077] In this embodiment of the application, in order to facilitate the management of workload nodes, it is also necessary to change the K8S component from the Windows process state to the Windows service state.

[0078] In this embodiment, after adding a workload node for deploying a cloud desktop container to the cluster, the cloud desktop system and related service software are packaged into an image file, the cloud desktop service is started using a Docker container, and the cloud desktop service container deployed on the Windows host is run through the Pod management object tool contained in the K8S workload node, thus completing the containerized deployment of the cloud desktop.

[0079] It should be noted that the relevant service software can be software that runs cloud desktop containers. Specifically, it can be selected according to the actual situation, and no specific limitation is made in this application.

[0080] It should be noted that containerized deployment of cloud desktops enables Kubernetes to support Windows nodes, providing an easy-to-use and stable cloud desktop containerized deployment platform. This allows for more flexible resource sharing, improves resource utilization efficiency, simplifies the cloud desktop deployment process, and enables the rapid deployment of cloud desktop instances with the same template for a large number of users.

[0081] Optionally, the workload node is also used to obtain the second cloud desktop address information of the target cloud desktop from the system communication whitelist when communicating with the target cloud desktop in other tenant systems, generate a routing information between the first cloud desktop address information and the second cloud desktop address information using the network plugin Flannel, and use the routing information to realize communication with the target cloud desktop.

[0082] In this embodiment of the application, after the cloud desktop management system is created, it is also necessary to realize cloud desktop communication between different tenants.

[0083] In this embodiment, multiple cloud desktop containers are deployed on the Windows workload nodes. Different cloud desktop containers run in different namespaces. To enable communication with target cloud desktop containers in other tenant systems, network interoperability at multiple levels, including cloud desktop containers, minimum scheduling units (Pods), services, and nodes, needs to be achieved in the cluster.

[0084] In this embodiment, communication between cloud desktops between different tenants can be achieved based on a system communication whitelist. If the second cloud desktop address information of the target cloud desktop can be found in the whitelist, it indicates that the cloud desktops of the two tenants have communication permissions. Under the condition that the two cloud desktops have communication permissions, the workload node uses the Flannel network plugin and the Host-gw mode of the Flannel network plugin to use the Windows host for communication as a gateway. A route is added on the Windows host based on the first cloud desktop address information and the second cloud desktop address information. The added route can realize communication between cloud desktop containers on the Windows host.

[0085] It should be noted that the target cloud desktop can be the actual cloud desktop that the tenant wants to communicate with. For example, when tenant A wants to communicate with the cloud desktops corresponding to tenant B, where tenant B corresponds to cloud desktops a, b, and c, and tenant A wants to communicate with cloud desktop c corresponding to tenant B, then cloud desktop c corresponding to tenant B is the target cloud desktop.

[0086] It should be noted that the Host-gw mode uses routing to achieve network communication. It achieves cross-host communication by adding routing information. Instead of encapsulating and unpacking data, it treats the host machine as a gateway to achieve communication. In the Host-gw network mode, the workload nodes on the cluster will automatically add a routing information, so that all addresses sent to the target cloud desktop container are placed on the workload node where the container is located.

[0087] It should be noted that in the multi-tenant cloud desktop system cluster of this application, the Host-gw network mode of Flannel is used to realize network interconnection at multiple levels of the system, which not only meets the communication of desktops within the same tenant, but also has the ability to access the network of control nodes across nodes.

[0088] Optionally, the Kubernetes control node is generated by deploying the Kubernetes application service port component Kubernetes API server, the control management component Controller-manager, the scheduler component Schedule, and the data storage component Etcd. The Kubernetes application service port component is used for communication with the workload nodes to distribute resource allocation results and access permission settings. The control management component is used to monitor and manage the cloud desktops deployed on the workload nodes. The scheduler component is used to schedule the workload nodes to execute the containerized deployment of cloud desktops. The data storage component is used to store data generated in the cloud desktop management system.

[0089] In this embodiment, the K8S control node is the main node that manages the entire cluster system. By deploying Kubernetes API server, Controller-manager, Schedule, and Etcd components, it can achieve functions such as communication, object control, container scheduling, and resource object storage.

[0090] In this embodiment, the Kubernetes API server component mainly handles communication within the entire cloud desktop management system. It can facilitate communication between the control node and the workload nodes, and can accept HTTP requests such as those for creating cloud desktops.

[0091] In this embodiment, the Controller-manager can monitor and manage the cloud desktop containers running on the workload nodes. It can monitor the running status of the cloud desktop containers, including functions such as deleting, updating, and adding cloud desktop containers. When a workload node unexpectedly crashes, the Controller Manager will promptly detect and execute an automated repair process to ensure that the cluster is always in the expected working state.

[0092] It should be noted that the Controller-manager component is the management and control center within the cluster, and it can also be responsible for managing workload nodes, Pod replicas, service endpoints, and namespace resource quotas within the cluster.

[0093] In this embodiment, the Schedule component is responsible for scheduling workload nodes to perform containerized deployment of cloud desktops, and can deploy cloud desktop containers on the corresponding workload nodes according to actual needs.

[0094] In this embodiment of the application, the Etcd component is used to store the data generated in the entire cloud desktop management system, including data generated from the management of user permissions and data generated from the management of network communication.

[0095] It should be noted that the data stored in the Etcd component is not limited to the two types of data mentioned above. The specific data can be selected according to the actual situation, and no specific limitation is made in this application.

[0096] Based on the above embodiments, the cloud desktop management system in this application has the following advantages:

[0097] (1) The multi-tenant cloud desktop system based on K8S uses namespace to divide multiple tenants, realizes the management of access permissions and resource allocation for multiple tenants and multiple cloud desktop systems, and can reasonably access resources according to the organization's business needs and priorities, solving the problems of improper permission control and insufficient resource allocation flexibility that are easily caused by different projects being deployed in a shared cluster.

[0098] (2) Compared with VDI virtual desktop infrastructure, containerized deployment of cloud desktop systems simplifies multi-tenant cloud desktop deployment and improves the efficiency of cloud desktop release by deploying multiple cloud desktop applications on a single host and using kernel and container runtime to start each cloud desktop container.

[0099] (3) This application implements support for Windows nodes in Kubernetes clusters and achieves network interconnection, realizes consistent Windows container experience, and enables Windows type applications to apply the convenience brought by containerization.

[0100] It is understood that the cloud desktop management system provided in this application, during the cloud desktop management process, isolates multiple cloud desktops in different tenant systems into different namespaces by setting corresponding namespaces for tenant systems in the control node. The set namespaces enable access control and resource allocation management for multiple cloud desktops of multiple tenants. Furthermore, Docker containers are used to deploy cloud desktops in the namespaces corresponding to each tenant system on the workload nodes. Containerization deployment technology enables the rapid creation and deletion of cloud desktop containers. The cloud desktop management system based on Kubernetes technology uses namespaces to isolate different tenants, manage permissions, allocate resources for different tenants, and run cloud desktops through containerization technology, thereby improving the management and maintenance efficiency of a cluster system of cloud desktops for multiple tenants.

[0101] Based on the above embodiments, a cloud desktop management system is provided in this application, such as... Figure 2 As shown, the cloud desktop management system includes: a control node and workload nodes; the control node is configured with a cluster administrator, tenant administrator, namespace, and tenant; the workload nodes are configured with a container engine, network plugin, storage plugin, kubelet, kubelet-proxy, and cloud desktops in Pods.

[0102] A control node is used to allocate a K8S namespace to the first tenant system and to use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein, multiple cloud desktops in the first tenant system run in one K8S namespace.

[0103] Workload nodes are used to deploy the containerized cloud desktops corresponding to the first tenant system using the container engine, based on allocated resources and access permissions, and to run the containerized cloud desktops in the K8S namespace.

[0104] Cluster administrators are administrators who manage all tenants across the entire cluster and can create, read, update, and delete any policy pairs and create namespaces.

[0105] Tenant administrators are responsible for managing the tenants within the entire cluster.

[0106] Namespaces are used to isolate different tenants and the cloud desktops corresponding to different tenants, and to run one or more cloud desktops corresponding to different tenants in their respective namespaces. Multiple cloud desktops corresponding to a process run in a Pod.

[0107] The container engine is used for cloud desktop virtualization at the current operating system level, running cloud desktop containers in a multi-tenant cluster, and flexibly enabling the creation, deletion and other operations of cloud desktop containers.

[0108] A network plugin for enabling network communication between cloud desktops of different tenants.

[0109] Kubelet can be understood as a "workload node agent," running on each workload node. In a Kubernetes cluster, each node starts a Kubelet process to ensure that the cloud desktop containers are running and functioning well. At the same time, Kubelet can also monitor the cloud desktop containers and work services on the workload nodes and periodically report the current health status and resource usage of the workload nodes to the control node.

[0110] kubelet-proxy is used to maintain load balancing for the entire cloud desktop management system.

[0111] It should be noted that the cloud desktop management system built using the aforementioned K8S control node and workload node shares a set of computing resources, storage resources, and network resources. The cloud desktop management system can be used to manage the computing resources, storage resources, and network resources within the entire cloud desktop management system.

[0112] It should be noted that there can be one or more workload nodes. Specifically, the choice can be made according to the actual situation, and no specific limitation is made in this application.

[0113] This application provides a method for deploying a cloud desktop management system, applied to the K8S control node of the cloud desktop management system, such as... Figure 3 As shown, the method includes:

[0114] S101. Allocate a K8S namespace for the first tenant system, and use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein, multiple cloud desktops in the first tenant system run in one K8S namespace.

[0115] In this embodiment of the application, in order to isolate the cloud desktops of different tenant systems and to implement different resource allocation and permission management for different tenant systems and their corresponding cloud desktops, a K8S namespace is allocated to each tenant system through the K8S control node. Multiple cloud desktops corresponding to a single tenant can run in a K8S namespace.

[0116] In this embodiment, a K8S namespace is a virtualized cluster within a K8S cluster. A K8S cluster can have multiple namespaces, which are logically isolated from each other. A K8S cluster resource is shared within a namespace. A namespace is a set of logical clusters that can achieve isolation of computing, networking, storage, user permissions, etc.

[0117] For example, team A creates a namespace ta, and team A's projects are deployed and run in ta. Team B creates a namespace tb, and team B's projects are deployed and run in tb. This ensures that the projects of team A and team B are isolated from each other and do not affect each other. Furthermore, it allows specifying which users can access and which users cannot access a particular namespace.

[0118] In this embodiment, when the first tenant system needs to create a cloud desktop, the control node receives the request from the first tenant system to create a cloud desktop. The control node allocates a corresponding K8S namespace to the first tenant system through the namespace, and creates the cloud desktop corresponding to the first tenant system in the K8S namespace corresponding to the first tenant system. By utilizing the allocated K8S namespace, a multi-tenant environment can be set up. Through the created tenant isolation policy, one or more cloud desktops created by the first tenant system can be logically isolated, so that each tenant's cloud desktop runs in its own namespace.

[0119] In this embodiment of the application, by creating an independent namespace for each different tenant, different tenants are separated into their own namespaces. The namespace is used to ensure that the cloud desktops of different tenants do not interfere with each other, and the cloud desktops within a tenant can be managed in a unified manner.

[0120] It should be noted that Kubernetes namespaces can isolate different tenant systems in different namespaces. Each tenant system in a namespace is a logical cluster. Namespaces can be used to achieve isolation between resource computing, network, storage, and user permissions.

[0121] In this embodiment of the application, after dividing the cloud desktops corresponding to multiple tenant systems into different namespaces, the cloud desktops between each tenant do not interfere with each other, while the cloud desktops within a tenant can be managed uniformly.

[0122] In this embodiment of the application, after the namespace allocation is completed, it is necessary to allocate resources for cloud desktops in different tenants in different namespaces and set access permissions for tenants. By using role-based access control (RBAC) in the K8S control node to set different user roles, user roles and permissions are associated, and corresponding permissions are set for each user role. Access control is achieved by setting the association between users and permissions, and resources can be allocated according to the number of cloud desktops in a namespace.

[0123] It's important to note that Role-Based Access Control (RBAC) establishes a set of roles between the user set and the permission set. Each role corresponds to a set of permissions. Once a user is assigned an appropriate role, that user possesses all the operational permissions for that role. The advantage of this approach is that it eliminates the need to assign permissions every time a user is created; only the corresponding role needs to be assigned. Furthermore, role permission changes are far less frequent than user permission changes, thus simplifying user permission management and reducing system overhead.

[0124] In this embodiment of the application, the control node can set cluster user roles to manage the corresponding cloud desktops of different tenants.

[0125] It should be noted that the cluster user role can be a cluster administrator, a namespace administrator, or a tenant administrator. Specifically, the role can be selected according to the actual situation, and no specific limitation is made in this application.

[0126] In this embodiment of the application, the cluster administrator can manage all tenant administrators and all namespace administrators throughout the cluster. The cluster administrator can also create, read, update, and delete any policy pairs.

[0127] For example, a cluster administrator can perform operations such as deleting or updating tenant administrators; they can also perform operations such as deleting or updating namespace administrators.

[0128] It should be noted that the policy pair can be a role-policy pair or a network-policy pair. No specific limitation is made in this application, and the choice can be made according to the actual situation.

[0129] In this embodiment of the application, the cluster administrator can also create namespaces and assign the created namespaces to namespace administrators.

[0130] In this embodiment, the namespace administrator is applicable to a specific single-tenant administrator. The namespace administrator can manage the tenants in its namespace and the cloud desktops corresponding to the tenants.

[0131] In this embodiment of the application, the tenant administrator can manage one or more cloud desktops corresponding to it.

[0132] In this embodiment of the application, by setting user roles and setting corresponding permissions for different user roles, it is possible to set access permissions for cloud desktops in different namespaces and set resource quotas according to the number of cloud desktops in the namespace.

[0133] In this embodiment of the application, after a namespace is set up, multiple cloud desktops of a tenant are running in a namespace, and the corresponding administrator can allocate resources and set access permissions for the multiple cloud desktops corresponding to the tenant in a namespace.

[0134] Optionally, a cloud desktop management system deployment method is applied to the K8S control node of the cloud desktop management system. The method further includes: pre-setting a system communication whitelist in the system; after receiving the first cloud desktop address information sent by the workload node, adding the first cloud desktop address information to the storage location corresponding to the first tenant system in the system communication whitelist; and realizing cloud desktop communication between the first tenant system and other tenant systems based on the system communication whitelist.

[0135] In this embodiment of the application, before adding the obtained address information of the cloud desktop to the storage location corresponding to the first tenant system in the system communication whitelist, the K8S control node also pre-sets a system communication whitelist, allowing the cloud desktops corresponding to the tenants in the system communication whitelist to communicate with each other.

[0136] In this embodiment of the application, when communication is carried out between the first cloud desktop and the second cloud desktop between different tenants, when a communication request is received, the workload node needs to obtain the cloud desktop address information of the first cloud desktop and send the obtained address information of the first cloud desktop to the K8S control node.

[0137] In this embodiment, after obtaining the address information of the first cloud desktop, the control node first creates a NetworkPolicy object. The NetworkPolicy object contains a whitelist of entry rules. The IP addresses and ports of the cloud desktops that need to communicate are added to the storage location corresponding to the first tenant system in the entry whitelist. Based on the addition of the IP addresses and port numbers of the cloud desktops that need to communicate, the communication between the cloud desktops that need to communicate and those added to the whitelist in the created NetworkPolicy object is realized through the network plugin Flannel.

[0138] In this application embodiment, the NetworkPolicy resource object is a specification of the communication rules allowed between Pods and with other network endpoints. The NetworkPolicy resource uses tags to select Pods and defines the communication rules allowed for the selected Pods.

[0139] In this embodiment, Flannel is a network component that can allocate different subnets to different workload nodes to enable cross-host communication between containers, thereby enabling communication across the entire K8S hierarchy.

[0140] It should be noted that the Flannel component runs on the workload node and depends on Etcd and docker.

[0141] This application provides a method for deploying a cloud desktop management system, applied to the workload nodes of the cloud desktop management system, such as... Figure 4 As shown, the method includes:

[0142] S201. Based on the resources allocated and access permissions set by the K8S control node, the container engine is used to deploy the cloud desktop corresponding to the first tenant system in a containerized manner, and the containerized cloud desktop is run in the K8S namespace.

[0143] In this embodiment of the application, after allocating corresponding permissions and resources to multiple cloud desktops of different tenant systems through different namespaces on the K8S control node, the containerized deployment of the cloud desktops corresponding to the tenant system can be carried out on the workload node based on the allocated resources and the set access permissions.

[0144] In this embodiment of the application, when deploying cloud desktops, the workload nodes are deployed on Windows hosts, and the workload nodes deployed on Windows hosts are the nodes that actually run the cloud desktop services.

[0145] In this embodiment of the application, since K8S technology orchestrates container clusters, in order to add a Windows host to the K8S cluster system as a workload node, a container engine needs to be installed and deployed on all hosts running cloud desktop containers in the cluster. Here, the container engine can be the Docker container engine.

[0146] It should be noted that Docker, the container engine, is currently the only container runtime tool that supports Windows systems and can manage the entire lifecycle of cloud desktop containers, including creation, operation, and deletion.

[0147] It should be noted that, due to the special nature of Windows and the immaturity of Windows virtualization technology, the command to add a Windows host as a workload node with one click using the Kubernetes automated deployment tool kubeadm is no longer applicable when using a Windows host as a workload node to run multiple cloud desktop containers.

[0148] It should be noted that kubeadm is a quick installation tool for setting up Kubernetes (K8S). It provides the commands kubeadm init and kubeadm join to quickly create a K8S cluster.

[0149] In this embodiment, a Windows host is used as a workload node to run multiple cloud desktop containers. After installing and deploying Docker on the container that needs to run the cloud desktop, a Windows version of the Pause image is created on the Windows host with Docker installed, based on the principle of strong consistency between the base image version of the container and the host operating system version. The created Pause image is used as the base image of the cloud desktop container and the init process to start the system.

[0150] In this embodiment, after the base image is created, an installation directory is prepared for the Windows nodes that need to be added to the cluster. The binary command-line component Kubectl, the node agent Kubelet, the network agent Kube-proxy, the startup script for adding to the cluster, and the relevant installation configuration files are placed in the installation directory. Based on this installation directory, the installation script is run, and a Windows host that can run cloud desktop services can be added to the cluster.

[0151] In this embodiment of the application, in order to facilitate the management of workload nodes, it is also necessary to change the K8S component from the Windows process state to the Windows service state.

[0152] In this embodiment, after adding a workload node to the cluster to deploy the cloud desktop container, the cloud desktop system and related service software are packaged into an image file, the cloud desktop service is started using a Docker container, and the cloud desktop service container deployed on the Windows host is run through the Kubernetes Pod management object tool, thus completing the containerized deployment of the cloud desktop.

[0153] It should be noted that the relevant service software can be software that runs cloud desktop containers. Specifically, it can be selected according to the actual situation, and no specific limitation is made in this application.

[0154] Optionally, a method for deploying a cloud desktop management system is applied to the workload nodes of the cloud desktop management system. After containerizing the cloud desktop corresponding to the first tenant system using a container engine and running the containerized cloud desktop in the K8S namespace, the method further includes obtaining the cloud desktop address information of the first cloud desktop and transmitting the cloud desktop address information to the K8S control node. The K8S control node then adds the cloud desktop address information to the storage location corresponding to the first tenant system in the system communication whitelist. Based on the system communication whitelist, cloud desktop communication between the first tenant system and other tenant systems is realized.

[0155] In this embodiment of the application, cloud desktops corresponding to different tenants are deployed on the workload nodes. The cloud desktops of different tenants run on their respective namespaces. Network communication between cloud desktops corresponding to a tenant that are isolated in a namespace is unrestricted, while cloud desktops of different tenants in different namespaces are subject to access restrictions.

[0156] In this embodiment of the application, when communication is carried out between the first cloud desktop and the second cloud desktop between different tenants, when a communication request is received, the workload node needs to obtain the cloud desktop address information of the first cloud desktop and send the obtained address information of the first cloud desktop to the K8S control node.

[0157] In this embodiment, after sending the obtained address information of the first cloud desktop to the K8S control node, the K8S control node adds the address information of the first cloud desktop to the storage location corresponding to the first tenant system in the system communication whitelist; and based on the system communication whitelist, cloud desktop communication between the first tenant system and other tenant systems is realized.

[0158] In this embodiment, after obtaining the address information of the first cloud desktop, the control node first creates a NetworkPolicy object. The NetworkPolicy object contains a whitelist of entry rules. The IP addresses and ports of the cloud desktops that need to communicate are added to the storage location corresponding to the first tenant system in the entry whitelist. Based on the addition of the IP addresses and port numbers of the cloud desktops that need to communicate, the communication between the cloud desktops that need to communicate and those added to the whitelist in the created NetworkPolicy object is realized through the network plugin Flannel.

[0159] In this application embodiment, the NetworkPolicy resource object is a specification of the communication rules allowed between Pods and with other network endpoints. The NetworkPolicy resource uses tags to select Pods and defines the communication rules allowed for the selected Pods.

[0160] In this embodiment, Flannel is a network component that can allocate different subnets to different workload nodes to enable cross-host communication between containers, thereby enabling communication across the entire K8S hierarchy.

[0161] It should be noted that the Flannel component runs on the workload node and depends on Etcd and docker.

[0162] Optionally, a method for deploying a cloud desktop management system is applied to the workload nodes of the cloud desktop management system. When deploying cloud desktops in a containerized manner, the cloud desktop system information and service software are packaged into an image file, and the image file is run based on the container engine and the scheduling unit Pod management object tool contained in the K8S workload node to achieve containerized deployment of the cloud desktop.

[0163] It should be noted that the workload nodes are generated after installing Docker containers on the host machine, based on Kubernetes tools and preset settings.

[0164] In this embodiment, the workload nodes are deployed on a Windows host, and the workload nodes deployed on the Windows host are the nodes that actually run the cloud desktop service.

[0165] In this embodiment of the application, since K8S technology orchestrates container clusters, in order to add a Windows host to the K8S cluster system as a workload node, Docker needs to be installed and deployed on all hosts running cloud desktop containers in the cluster.

[0166] It should be noted that Docker is currently the only container runtime tool that supports Windows systems and can manage the entire lifecycle of cloud desktop containers, including creation, operation, and deletion.

[0167] It should be noted that, due to the special nature of Windows and the immaturity of Windows virtualization technology, the command to add a Windows host as a workload node with one click using the Kubernetes automated deployment tool kubeadm is no longer applicable when using a Windows host as a workload node to run multiple cloud desktop containers.

[0168] It should be noted that kubeadm is a quick installation tool for setting up Kubernetes (K8S). It provides the commands kubeadm init and kubeadm join to quickly create a K8S cluster.

[0169] In this embodiment, a Windows host is used as a workload node to run multiple cloud desktop containers. After installing and deploying Docker on the container that needs to run the cloud desktop, a Windows version of the Pause image is created on the Windows host with Docker installed, based on the principle of strong consistency between the base image version of the container and the host operating system version. The created Pause image is used as the base image of the cloud desktop container and the init process to start the system.

[0170] In this embodiment, after the base image is created, an installation directory is prepared for the Windows nodes that need to be added to the cluster. The binary files Kubectl, Kubelet, and Kube-proxy, as well as the startup script for adding to the cluster and related installation configuration files, are placed in the installation directory. Based on this installation directory, the installation script is run, and a Windows host that can run cloud desktop services can be added to the cluster.

[0171] In this embodiment of the application, in order to facilitate the management of workload nodes, it is also necessary to change the K8S component from the Windows process state to the Windows service state.

[0172] In this embodiment, after adding a workload node to the cluster to deploy the cloud desktop container, the cloud desktop system and related service software are packaged into an image file, the cloud desktop service is started using a Docker container, and the cloud desktop service container deployed on the Windows host is run through the Kubernetes Pod management object tool, thus completing the containerized deployment of the cloud desktop.

[0173] It should be noted that the relevant service software can be software that runs cloud desktop containers. Specifically, it can be selected according to the actual situation, and no specific limitation is made in this application.

[0174] Optionally, a method for deploying a cloud desktop management system is applied to the workload nodes of the cloud desktop management system. When communicating with target cloud desktops in other tenant systems, the method obtains the second cloud desktop address information of the target cloud desktop from the system communication whitelist, uses the network plugin Flannel to generate a routing information between the first cloud desktop address information and the second cloud desktop address information, and uses the routing information to realize communication with the target cloud desktop.

[0175] In this embodiment of the application, after the cloud desktop management system is set up, it is also necessary to enable communication between cloud desktops of different tenants.

[0176] In this embodiment, multiple cloud desktop containers are deployed on the Windows workload nodes. Different cloud desktop containers run in different namespaces. To enable communication with target cloud desktop containers in other tenant systems, network interoperability at multiple levels, including cloud desktop containers, Pods, Services, and nodes, needs to be achieved in the cluster.

[0177] In this embodiment, based on the system communication whitelist, if the second cloud desktop address information of the target cloud desktop can be found in the whitelist, it indicates that the cloud desktops of the two tenants have communication permissions. Under the condition that the two cloud desktops have communication permissions, the workload node uses the Host-gw mode of the Flannel network plugin to make the communicating Windows host the gateway. A route is added on the Windows host based on the first cloud desktop address information and the second cloud desktop address information. The added route can realize communication between cloud desktop containers on the Windows host.

[0178] It should be noted that the Host-gw mode uses routing to achieve network communication. It achieves cross-host communication by adding routing information. Instead of encapsulating and unpacking data, it treats the host machine as a gateway to achieve communication. In the Host-gw network mode, the workload nodes on the cluster will automatically add a routing information, so that all addresses sent to the target cloud desktop container are placed on the workload node where the container is located.

[0179] It is understood that the cloud desktop management system deployment method provided in this application embodiment, during the cloud desktop management process, isolates multiple cloud desktops in different tenant systems in different namespaces by setting corresponding namespaces for tenant systems in the control node. The set namespaces enable access control and resource allocation management for multiple cloud desktops of multiple tenants. Furthermore, Docker containers are used to deploy cloud desktops in the namespaces corresponding to each tenant system on the workload nodes. Containerization deployment technology enables the rapid creation and deletion of cloud desktop containers. The cloud desktop management system deployed based on Kubernetes technology uses namespaces to isolate different tenants, manage permissions and allocate resources for different tenants, and run cloud desktops through containerization technology, thereby improving the management and maintenance efficiency of a cluster system of cloud desktops for multiple tenants.

[0180] This application provides a storage medium storing a computer program thereon. The computer-readable storage medium stores one or more programs, which can be executed by one or more processors and applied to a cloud desktop management system 1. The computer program implements the deployment method of the cloud desktop management system as described above.

[0181] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0182] 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 disclosure, in essence, or the part that contributes to the related technology, 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 an image display device (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 disclosure.

[0183] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cloud desktop management system, characterized in that, The system includes: a Kubernetes (K8S) container orchestration tool control node and workload nodes; a container engine is installed in the workload nodes. The K8S control node is used to allocate a K8S namespace to the first tenant system, and to use the K8S namespace to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein, multiple cloud desktops in the first tenant system run in one K8S namespace. The workload node is used to deploy the cloud desktop corresponding to the first tenant system in a containerized manner using the container engine based on the allocated resources and the set access permissions, and to run the containerized cloud desktop in the K8S namespace. The workload nodes are deployed on Windows hosts; the container engine is Docker. The workload nodes are generated as follows: After installing and deploying Docker on the container that needs to run the cloud desktop, based on the principle of strong consistency between the container's base image version and the host operating system version, a Windows sandbox image, pause, is created on the Windows host where Docker is installed. The created pause image is used as the base image of the cloud desktop container and the system startup process init. An installation directory is prepared for the Windows nodes that need to be added to the cluster. The binary command-line component Kubectl, the node agent Kubelet, the network agent Kube-proxy, the startup script for adding to the cluster, and the relevant installation configuration files are placed in the installation directory. Based on the installation directory, the installation script is run to add the Windows host running the cloud desktop service to the cluster. The workload node is also used to package cloud desktop system information and service software into an image file, and run the image file based on the container engine and the scheduling unit Pod management object tool contained in the workload node, so as to realize the containerized deployment of the cloud desktop.

2. The system of claim 1, wherein, The system has a preset system communication whitelist; The workload node is also used to obtain the first cloud desktop address information and transmit the first cloud desktop address information to the K8S control node. The K8S control node is also used to add the first cloud desktop address information to the storage location corresponding to the first tenant system in the system communication whitelist, and to realize cloud desktop communication between the first tenant system and other tenant systems based on the system communication whitelist.

3. The system according to claim 2, characterized in that, The workload node is also used to obtain the second cloud desktop address information of the target cloud desktop from the system communication whitelist when communicating with the target cloud desktop in the other tenant system, generate a routing information between the first cloud desktop address information and the second cloud desktop address information using the network plugin Flannel, and use the routing information to realize communication with the target cloud desktop.

4. The system according to claim 1, characterized in that, The Kubernetes control node is generated by deploying the Kubernetes application service port component Kubernetes API server, the control and management component Controller-manager, the scheduler component Schedule, and the data storage component Etcd; among them; The K8S application service port component is used for communication with the workload nodes to distribute resource allocation results and access permission settings. The control and management component is used to monitor and manage the cloud desktops deployed on the workload nodes. The scheduler component is used to schedule workload nodes to perform containerized deployment of cloud desktops; The data storage component is used to store the data generated in the cloud desktop management system.

5. A cloud desktop management system deployment method, characterized by, Applied to the K8S control node of the cloud desktop management system according to any one of claims 1-4, the method includes: A K8S namespace is allocated to the first tenant system, and the K8S namespace is used to allocate resources and set access permissions for multiple cloud desktops in the first tenant system; wherein, multiple cloud desktops in the first tenant system run in one K8S namespace.

6. The method of claim 5, wherein, The system presets a system communication whitelist; the method further includes: After receiving the first cloud desktop address information sent by the workload node, the first cloud desktop address information is added to the storage location corresponding to the first tenant system in the system communication whitelist, and cloud desktop communication between the first tenant system and other tenant systems is realized based on the system communication whitelist.

7. A method for deploying a cloud desktop management system, characterized in that, Applied to the workload nodes of the cloud desktop management system according to any one of claims 1-4, the method includes: Based on the resources allocated and access permissions set by the K8S control node, the container engine is used to deploy the cloud desktop corresponding to the first tenant system in a containerized manner, and the containerized cloud desktop is run in the K8S namespace.

8. The method according to claim 7, characterized in that, The system pre-defines a system communication whitelist; after deploying the containerized cloud desktop corresponding to the first tenant system using the container engine, and running the containerized cloud desktop in the K8S namespace, the method further includes: The system obtains the first cloud desktop address information and transmits it to the K8S control node. The K8S control node then adds the first cloud desktop address information to the storage location corresponding to the first tenant system in the system communication whitelist. Based on the system communication whitelist, the system enables cloud desktop communication between the first tenant system and other tenant systems.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method as described in any one of claims 5-8.

Images