Kubernetes-based multi-tenant resource dynamic isolation method

Abstract

The invention discloses a Kubernetes-based multi-tenant resource dynamic isolation method, which comprises the following steps of: constructing a CPU (Central Processing Unit) resource control group by utilizing cgropsv2, and realizing dynamic allocation of CPU resources in combination with a dynamic binding engine; constructing a physically isolated storage pool based on the Ceph distributed file system; the network namespace and eBPF flow control technology is utilized, and LWTunnel packaging is combined to realize tenant network complete isolation and QoS speed limitation; constructing an LSTM neural network prediction model to pre-judge a resource demand; a multi-level security system is constructed through AES-256 encryption, Seccomp / BPF container limitation and other technologies; and defining a dynamic strategy object by utilizing CRD to realize strategy management. Through dynamic adaptive resource scheduling, multi-level security protection and highly flexible customization capability, the cluster resource utilization rate can be improved, the CPU cross-NUMA access delay can be reduced, the malicious traffic interception rate can be improved, and the high-performance and high-security requirements of multi-industry and multi-tenant scenes such as finance and e-commerce can be met.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-tenant resource management technology, and in particular to a multi-tenant resource dynamic isolation method based on Kubernetes. Background Art

[0002] Against the backdrop of the rapid development of cloud computing and containerization technologies, Kubernetes, as the de facto standard in the field of container orchestration, has become the core infrastructure of multi-tenant cloud platforms.

[0003] However, existing Kubernetes multi-tenant resource management solutions face the following technical problems in practical applications. First, traditional multi-tenant architectures typically use static resource quotas to pre-allocate fixed CPU and memory shares to tenants. This approach cannot adapt to dynamic changes in tenant business. For example, in scenarios such as e-commerce promotions and financial transaction peaks, sudden traffic can lead to insufficient resources, while a large number of idle resources exist during regular periods. Data shows that the average cluster resource utilization rate in the static allocation mode is only 40%-60%, and CPU resource contention between tenants can cause key business response delays to fluctuate by more than 300%. In addition, traditional cgroupsv1 technology lacks the ability to fine-tune dynamic binding of CPU cores, and cannot avoid memory latency problems caused by cross-NUMA node access, seriously affecting the performance of compute-intensive businesses.

[0004] Secondly, although the existing Kubernetes network plug-in supports tenant network isolation, it mainly relies on VLAN or network policies to achieve logical isolation, and cannot prevent Layer 2 network threats such as ARP spoofing and DHCP attacks. When the number of tenants exceeds 50, cross-tenant broadcast storms will cause network bandwidth utilization to drop by more than 20%, and traditional ACL rules make it difficult to implement fine-grained control of encrypted traffic. At the same time, there is a lack of traffic anomaly detection mechanism, and real-time blocking cannot be achieved in the face of DDoS attacks or malicious traffic. Actual tests on a certain cloud platform show that the traditional solution takes more than 5 minutes to respond to sudden abnormal traffic, far exceeding the 30-second threshold tolerated by the business.

[0005] In addition, most multi-tenant storage solutions use a shared storage pool combined with logical volume isolation, and do not achieve physical storage media-level isolation, which poses the risk of IOPS competition and data leakage. For example, when multiple tenants share the same set of OSD nodes, the high IO load of big data analysis tenants will increase the IO delay of other tenants by more than 50%. In addition, existing solutions generally lack data integrity verification mechanisms, and the average detection time for data tampering incidents exceeds 24 hours. Snapshot technology mostly uses full backup, and the storage space occupied is 5-10 times that of incremental solutions, which cannot meet high-frequency backup needs.

[0006] Finally, traditional resource scheduling relies on rule-based heuristic algorithms and cannot predict the cyclical resource needs of tenants' businesses. For example, the evening traffic peak of media live broadcast tenants often leads to service degradation due to insufficient resource pre-allocation. In terms of security protection, existing solutions mostly stay at the network and storage layers, lacking in-depth protection during container runtime. The success rate of container escape attacks is as high as 15%, and data encryption mostly uses full-volume encryption, which cannot achieve field-level sensitive data protection, making it difficult to meet the compliance requirements of industries such as finance and healthcare. At the same time, cross-cluster policy management lacks consistency guarantees, and isolation policies are prone to failure when switching between primary and backup clusters, leading to the risk of business interruption.

[0007] Therefore, how to provide a multi-tenant resource dynamic isolation method based on Kubernetes is an urgent problem that technicians in this field need to solve. Summary of the Invention

[0008] One purpose of the present invention is to propose a multi-tenant resource dynamic isolation method based on Kubernetes. The present invention can realize dynamic adaptive allocation and multi-level security isolation of computing, storage and network resources through technologies such as cgroupsv2 dynamic adjustment of CPU core binding, Ceph physical isolation storage and eBPF flow control, so as to solve the problems of low resource utilization, cross-tenant interference and insufficient security protection caused by traditional static quotas, improve cluster resource utilization, and ensure tenant business flexibility and data security.

[0009] A multi-tenant resource dynamic isolation method based on Kubernetes according to an embodiment of the present invention includes the following steps: S1. Build a CPU resource control group using cgroupsv2 technology, use the CPU.weight parameter to achieve proportional allocation of CPU shares between tenants, and deploy a CPU core dynamic binding engine. This engine uses the Kubelet component to collect container CPU usage data in real time. When it detects that the CPU utilization of a tenant's application exceeds the preset threshold for three consecutive sampling periods, it automatically triggers the CPU core rebinding mechanism. By modifying the cpuset.cpus parameter of cgroupsv2, the idle CPU cores in the node are dynamically bound to the target container, and the CPU.weight value is adjusted simultaneously to expand the resource share. During the binding process, kernel-level CPU affinity configuration is implemented through the sched_setaffinity system call. S2. Build a storage pool based on the Ceph distributed file system. Create an independent Provisioner controller for each tenant. This controller dynamically generates PersistentVolumeClaims through StorageClass definitions. Each PVC is associated with a dedicated RBD block device. Combined with Ceph's RBD snapshot technology, incremental snapshots are created for tenant data volumes according to preset policies. Snapshot data is stored in an independent OSD node cluster. Ceph's CRUSH rules forcibly assign different tenants' data volumes to physically isolated storage node groups to achieve storage media-level isolation. Access control lists at the FUSE file system layer are used to restrict cross-tenant data access. S3. Use the Kubernetes network plug-in to create an independent network namespace for each tenant, configure a dedicated IP address range and routing table, implement ARP suppression by setting the net.ipv4.conf.all.arp_ignore=2 and net.ipv4.conf.all.arp_announce=2 parameters, limit the broadcast domain to the tenant's VPC, and load the eBPF-based traffic control program. This program uses the ingress / egress hook functions of the TrafficControl subsystem to limit the rate of tenant egress traffic according to QoS level. It also encapsulates tenant traffic using LWTunnel technology to achieve complete isolation of data packets between tenants in the underlying network. S4. Build a resource prediction model based on an LSTM neural network. This model collects tenant resource usage data from the past seven days, performs sliding average processing on a 15-minute time window, and trains model parameters using the Adam optimizer. The model automatically updates every hour and predicts resource demand trends for the next four hours. When it is predicted that a tenant's resource utilization will exceed the threshold, the Kubernetes HorizontalPodAutoscaler mechanism is triggered to expand capacity in advance, and the Prebind scheduling plug-in is used to reserve host resources for the new Pod. At the same time, the Prometheus collection node and the Grafana visualization platform are integrated to build a tenant-level monitoring dashboard, which displays more than 20 indicators such as resource water level, IOPS, and network latency in real time. When the indicator fluctuation exceeds twice the standard deviation, a multi-level alarm is triggered.

[0010] Furthermore, in step S1, when the CPU core dynamic binding engine triggers the rebinding mechanism, it also synchronously binds the corresponding memory node through the Linux cpuset.mems parameter to reduce cross-NUMA access latency, and adopts a progressive resource adjustment strategy, adjusting no more than 2 CPU cores at a time, with an adjustment interval of 500ms.

[0011] Furthermore, in step S2, the Ceph distributed file system generates a SHA-256 hash value for each data block through the RADOS gateway and stores it in an independent metadata server. The hash value is automatically verified each time data is read or written. When tampering is detected, the data is restored from the most recent snapshot and an audit log is recorded.

[0012] Furthermore, in step S3, the eBPF traffic control program maintains the tenant traffic feature library through the map data structure, calculates the traffic quintuple entropy value in real time, and triggers TCPRST blocking and writes it to the kernel blacklist when the entropy value exceeds 3 times the historical average. The blocking period is 5 minutes.

[0013] Furthermore, in step S4, the machine learning model aligns the tenant business logs with the resource usage data time series, identifies the association weights between business indicators and resource consumption through the attention mechanism, and performs resource prediction based on the business indicators.

[0014] Furthermore, the method further includes the following steps: S5. Use the AES-256 algorithm to perform field-level encryption on sensitive fields in the data storage layer, enable TDE transparent encryption for data volumes, and use Seccomp / BPF technology to generate a whitelist system call set when the container is running, allowing only necessary calls such as read, write, and mmap, blocking dangerous operations such as chroot and mount, and limiting the container's access to the host file system through AppArmor.

[0015] Furthermore, the method further includes the following steps: S6. Define tenant policy resource objects containing resource quota rules, network policy rules, and security policy rules through Kubernetes' CRD. Policy configuration takes effect in real time through the Webhook controller. When modified, it automatically triggers configuration updates of resource allocation, network isolation, and security modules. The update delay does not exceed 10 seconds.

[0016] Furthermore, the method further includes the following steps: S7: When the tenant resource utilization rate is lower than the preset threshold for one consecutive hour, the idle resources are marked as recyclable through the Downward API and reallocated by the scheduler. During the recycle, the preheat start strategy is adopted for the Pod, first allocating 25% of the resources and gradually increasing to 100% within 5 minutes.

[0017] Furthermore, in the container runtime security protection, the system call sequence of the container process is monitored through the eBPF probe. When an abnormal call chain is detected, the container restart is triggered and reported to the security management center to update the Seccomp / BPF whitelist rules.

[0018] Furthermore, the method further includes the following steps: S8. Use the Kubernetes Federation component to synchronize isolation policies to multiple clusters. Deploy resource allocation, network isolation, and intelligent scheduling modules independently in each cluster. Use the Raft algorithm to ensure cross-cluster policy consistency. When the primary cluster fails, it automatically switches to the backup cluster and maintains isolation.

[0019] The beneficial effects of the present invention are: 1. In the present invention, through the collaborative work of cgroupsv2 technology and the CPU core dynamic binding engine, the system can perceive changes in tenant application load in real time. When it detects that the CPU utilization exceeds the preset threshold for 15 consecutive seconds, it automatically triggers the idle core rebinding mechanism, and adjusts the policy incrementally by no more than 2 cores each time. The 500ms interval ensures system stability, thereby being able to perceive changes in the resource requirements of tenant applications in real time, respond quickly, and automatically adjust resource allocation to ensure that resources are always efficiently utilized while guaranteeing the stable operation of tenant applications.

[0020] 2. The data storage layer of the present invention adopts AES-256 field-level encryption and TDE transparent encryption. Sensitive data cannot be decrypted even if it is physically stolen. In addition, the system calls are restricted through the Seccomp / BPF whitelist during container runtime, and only 12 necessary operations such as read / write are allowed, blocking dangerous calls such as chroot / mount. The interception rate of container escape attacks is greatly improved. Therefore, a comprehensive and multi-level security protection system can be built from the computing, storage, network to the application layer. It not only realizes the physical isolation of resources, but also ensures the security and integrity of tenant data through various encryption technologies, access control mechanisms and anti-escape technologies.

[0021] 3. The present invention defines tenant policy resource objects through Kubernetes CRD, supports customized configuration of resource quotas, network policies, and security policies, realizes cross-cluster policy synchronization through Kubernetes Federation combined with Raft algorithm, and takes over within 30 seconds when the main cluster fails to ensure policy consistency. It allows tenants to flexibly customize resource allocation policies, network policies, and security policies according to their own business characteristics and needs. Tenants can independently define resource usage priorities, resource quotas, network access rules, etc. to meet the diverse needs of different industries and business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings: Figure 1This is a flowchart of a Kubernetes-based multi-tenant resource dynamic isolation method proposed by the present invention. DETAILED DESCRIPTION

[0023] The present invention will now be described in further detail with reference to the accompanying drawings, which are simplified schematic diagrams that illustrate the basic structure of the present invention in a schematic manner.

[0024] See also Figure 1 , a multi-tenant resource dynamic isolation method based on Kubernetes, including the following steps: S1. Use cgroupsv2 technology to build CPU resource control groups. cgroupsv2 provides more refined resource control capabilities, creating independent control groups for each tenant. In the control group configuration, set the CPU.weight parameter to achieve proportional CPU allocation between tenants.

[0025] For example, if the CPU.weight of tenant A is set to 200 and the CPU.weight of tenant B is set to 100, when there is competition for CPU resources, tenant A can obtain approximately 2 / 3 of the CPU resources and tenant B can obtain approximately 1 / 3 of the CPU resources, thereby achieving proportional allocation of CPU resources and meeting the differentiated CPU resource requirements of different tenants.

[0026] Specifically, the CPU core dynamic binding engine uses the Kubelet component to collect real-time container CPU usage data. Kubelet, the component responsible for managing containers on nodes in Kubernetes, is configured to periodically obtain CPU usage data for each container every five seconds. If a tenant application's CPU utilization exceeds a preset threshold for three consecutive sampling periods (i.e., 15 consecutive seconds), the CPU core rebinding mechanism is automatically triggered.

[0027] The preset threshold can be configured according to the tenant's business type and performance requirements. For example, for computing-intensive business, the preset threshold can be set to 80%.

[0028] After the rebinding mechanism is triggered, the engine first queries the CPU core usage status within the node to identify idle CPU cores with utilization below 20%. It then dynamically binds these idle CPU cores to the target container by modifying the cpuset.cpus parameter in cgroupsv2. For example, if a node has eight CPU cores numbered 0-7, and cores 5 and 6 are currently detected as idle, and the target container is originally bound to cores 0 and 1, the cpuset.cpus parameter is modified to "0,1,5,6" to bind idle cores 5 and 6 to the target container. Simultaneously, to increase the target tenant's resource share, the CPU.weight value is adjusted proportionally to the number of newly added CPU cores. For example, if the original CPU.weight was 200 and two cores were added, the CPU.weight would be adjusted to 300 to reflect the increased available resource share.

[0029] During the binding process, kernel-level CPU affinity configuration is implemented through the sched_setaffinity system call. The sched_setaffinity system call sets the set of CPU cores on which a process is allowed to run, ensuring that the target container's processes can only run on bound CPU cores. This avoids the performance overhead of process migration between different cores and improves CPU resource utilization.

[0030] To reduce cross-NUMA access latency, the CPU core dynamic binding engine also synchronizes the binding of the corresponding memory node through the Linux cpuset.mems parameter when triggering the rebinding mechanism. Each CPU core usually corresponds to the memory of one or more NUMA nodes. Binding the CPU core to the corresponding memory node allows the container to access memory from the local NUMA node as much as possible, reducing the latency of cross-node access. At the same time, a progressive resource adjustment strategy is adopted, with no more than 2 CPU cores adjusted at a time, and an adjustment interval of 500ms. This can avoid sudden changes in system load caused by allocating too many resources at one time, and ensure the stability of the system and the smoothness of resource allocation. For example, when it is necessary to add 4 CPU cores to the target container, the adjustment is divided into two times, adding 2 cores each time, with an interval of 500ms, to gradually increase the CPU resources of the container.

[0031] S2: Build a storage pool based on the Ceph distributed file system. Ceph offers high reliability, scalability, and performance, making it a suitable storage solution for multi-tenant environments. Create a separate Provisioner controller for each tenant, which manages storage resource allocation.

[0032] PersistentVolumeClaims (PVCs) are dynamically generated through StorageClass definitions. StorageClass is an object used in Kubernetes to describe storage classes and defines storage configuration parameters such as storage type and redundancy policy. Each tenant's Provisioner controller creates a dedicated PVC for that tenant based on its corresponding StorageClass. Each PVC is associated with a dedicated RADOSBlockDevice (RBD), a block storage interface provided by Ceph that provides block-level storage services for containers.

[0033] Secondly, combined with Ceph's RBD snapshot technology, incremental snapshots are created for tenant data volumes according to preset policies, such as creating incremental snapshots every hour. Incremental snapshots only record the data blocks that have changed since the last snapshot of the data volume, saving storage space and snapshot creation time. Snapshot data is stored in an independent OSD node cluster, which is specifically used to store snapshot data and is separated from the OSD node cluster where the tenant's main data is stored to achieve physical isolation. Through Ceph's CRUSH rules, the data volumes of different tenants are forcibly assigned to physically isolated storage node groups. CRUSH rules define the data distribution strategy on OSD nodes. By configuring specific CRUSH rules for each tenant, it ensures that its data volumes can only be stored in the specified storage node group, and there is no overlap between the storage node groups of different tenants, achieving isolation at the storage media level.

[0034] In addition, the access control list (ACL) at the FUSE file system layer is used to restrict cross-tenant data access. ACL can precisely control the access rights of different users and groups to files and directories, and set independent ACL rules for each tenant to ensure that other tenants cannot access their data. At the same time, the Ceph distributed file system generates a SHA-256 hash value for each data block through the RADOS gateway and stores it on an independent metadata server. Every time data is read or written, the system automatically verifies the hash value, compares the hash value of the read data block with the stored hash value, and if there is any inconsistency, it is detected that the data has been tampered with. When tampering is detected, the system restores the data from the most recent snapshot and records an audit log. The audit log includes information such as the time the tampering occurred, the data blocks involved, the source of the operation, etc., to facilitate subsequent security audits and problem troubleshooting.

[0035] S3. Use the Kubernetes network plugin to create an independent network namespace for each tenant. A network namespace provides an independent network stack, including IP address space, routing table, and network devices. Each tenant is assigned a dedicated IP address range, such as 10.0.0.0 / 24 for Tenant A and 10.1.0.0 / 24 for Tenant B, to ensure that IP address spaces do not overlap. Each network namespace is also configured with a dedicated routing table containing routing rules to the tenant's internal and external networks, enabling independent management of tenant networks.

[0036] ARP suppression is achieved by setting the net.ipv4.conf.all.arp_ignore=2 and net.ipv4.conf.all.arp_announce=2 parameters.

[0037] arp_ignore=2 means that when the host has multiple network interfaces, it will only respond to ARP requests on the network interface corresponding to the target IP address, avoiding sending ARP replies to other network interfaces; arp_announce=2 limits the sending of ARP announcements to only those that match the IP address on the local interface.

[0038] By setting these two parameters, the broadcast domain is limited to the tenant VPC, reducing cross-tenant broadcast storms and improving network security and stability.

[0039] Secondly, the eBPF-based traffic control program is loaded. This program uses the ingress / egress hook functions of the TrafficControl subsystem to limit the rate of tenant egress traffic according to QoS levels. eBPF is an efficient kernel-level programming technology that can dynamically load programs without modifying the kernel code, achieving fine-grained control over network traffic. Different QoS levels are set for tenants based on their business needs and payment levels, such as a 1Gbps rate limit for gold tenants and a 500Mbps rate limit for silver tenants. The queue management and traffic shaping functions of the TrafficControl subsystem are used to implement rate limiting control over tenant egress traffic. At the same time, tenant traffic is encapsulated through LWTunnel technology. LWTunnel is a lightweight tunneling technology that can create an independent tunnel for each tenant in the underlying network, encapsulate the tenant's data packets in the tunnel for transmission, and achieve complete isolation of data packets between tenants, preventing other tenants from stealing or tampering with data.

[0040] In addition, the eBPF traffic control program maintains a tenant traffic signature library using a map data structure. A map is an efficient data structure used in eBPF to store key-value pairs. The traffic signature library records the five-tuple information of normal tenant traffic and the corresponding entropy statistics. The entropy value of the traffic five-tuple is calculated in real time, reflecting the randomness and complexity of the traffic. When the entropy value exceeds three times the historical average, the traffic is identified as abnormal, triggering a TCP RST blocking event. An RST packet is sent to both communicating parties, the TCP connection is reset, and the source IP address of the traffic is added to the kernel blacklist for a blocking period of five minutes. During this blocking period, the system rejects all connection requests from the source IP address, effectively preventing network attacks and malicious traffic from entering the tenant network.

[0041] S4. Build a resource prediction model based on an LSTM neural network. This model collects tenant resource usage data from the past seven days, including metrics such as CPU usage, memory usage, storage IOPS, and network bandwidth. It then performs a sliding average over a 15-minute window to smooth data fluctuations and extract long-term trends and cyclical characteristics. Model parameters are trained using the Adam optimizer, an efficient adaptive learning rate optimization algorithm that automatically adjusts the learning rate to improve model training efficiency and accuracy. The model is automatically updated every hour, retraining using the latest seven days of data to ensure that it can adapt to changes in tenant business operations and evolving resource usage patterns, and to predict resource demand trends over the next four hours.

[0042] When the model predicts that a tenant's resource utilization will exceed a threshold, such as CPU utilization exceeding 80% or memory utilization exceeding 90%, Kubernetes' HorizontalPodAutoscaler mechanism, referred to as HPA, is triggered to implement early capacity expansion. HPA automatically adjusts the number of pods based on resource utilization to meet business needs. Furthermore, the Prebind scheduling plug-in reserves host resources for new pods. Before scheduling a new pod, the Prebind plug-in allocates the required CPU, memory, storage, and other resources to the pod, ensuring that the pod can start and run quickly and reducing scheduling delays.

[0043] Secondly, we integrate Prometheus collection nodes and the Grafana visualization platform to build a tenant-level monitoring dashboard. Prometheus is a powerful monitoring data collection and storage tool that can collect various node and container metrics in real time, including over 20 indicators such as resource levels, IOPS, network latency, and error rates. Grafana is used to display the collected data in the form of visual charts, allowing administrators to monitor tenants' resource usage and business performance in real time. When a metric fluctuates by more than twice the standard deviation, it is considered an abnormality and triggers multiple levels of alerts, including email alerts, SMS alerts, and platform alerts, notifying administrators to take timely action to prevent resource shortages or performance anomalies from impacting tenants' business.

[0044] Furthermore, the machine learning model aligns tenant business logs with resource usage data in time series. Business logs contain information such as the time, type, and parameters of business operations, which correspond one-to-one with resource usage data in terms of time. An attention mechanism identifies the correlation weights between business metrics and resource consumption. This allows the model to focus on business metrics that have a significant impact on resource consumption, such as user request volume and transaction processing volume. Resource forecasting based on business metrics not only considers historical resource usage data but also incorporates actual business operations, improving the accuracy and specificity of resource forecasts and ensuring that resource allocation is more aligned with tenant business needs.

[0045] S5. Sensitive fields are encrypted at the data storage layer using the AES-256 algorithm at the field level. AES-256 is a high-strength symmetric encryption algorithm that effectively protects the security of sensitive data. Transparent encryption (TDE) is enabled for data volumes. TDE automatically encrypts data when it is written to the storage media and decrypts it when it is read. This encryption is transparent to applications and does not affect normal business operations. It ensures that data stored on disk is encrypted to prevent data leaks.

[0046] During container runtime, a whitelist of system calls is generated using Seccomp / BPF technology. Seccomp / BPF is a security mechanism that restricts the system calls that container processes can execute. Only essential system calls, such as read, write, and mmap, are allowed, blocking dangerous operations like chroot and mount. Chroot changes the process's root directory, while mount mounts a file system, which can be exploited by malicious actors to gain system privileges or tamper with the file system. Furthermore, AppArmor is used to restrict container access to the host's file system. AppArmor is a mandatory access control mechanism that defines strict access policies for containers, such as prohibiting containers from accessing critical host system files and directories, preventing malicious processes within the container from causing damage to the host. Furthermore, the system call sequence of container processes is monitored using eBPF probes, which can monitor process behavior in real time at the kernel level. Detecting an abnormal call chain, such as multiple consecutive dangerous system calls, triggers a container restart and reports it to the security management center to update the Seccomp / BPF whitelist rules. The security management center analyzes the reported anomalies and generates new security rules, which are automatically updated to the relevant containers, improving container runtime security and protection capabilities.

[0047] S6. Define tenant policy resource objects that include resource quota rules, network policy rules, and security policy rules through Kubernetes CRDs.

[0048] Among them, CRD allows you to define custom resource types in Kubernetes to meet specific business needs.

[0049] Specifically, the tenant policy resource object details the tenant's resource quotas, network policies, and security policies. Policy configurations take effect in real time via the Webhook controller, a callback mechanism in Kubernetes. When a tenant policy resource object changes, the Webhook controller immediately detects and triggers the corresponding processing logic, applying the policy configuration to the relevant resource allocation, network isolation, and security modules.

[0050] When the policy is modified, the configuration update of resource allocation, network isolation and security modules is automatically triggered, and the update delay does not exceed 10 seconds, ensuring the real-time and effectiveness of the policy, so that the tenant's resource usage and security configuration can be adjusted according to the policy in a timely manner.

[0051] S7: When the tenant resource utilization is lower than the preset threshold for one consecutive hour, such as CPU utilization lower than 20% and memory utilization lower than 30%, the idle resources are marked as recyclable through the Downward API.

[0052] The Downward API is used to inject cluster resource information into containers. Here, it transmits idle resource status information to the scheduler. The scheduler then reallocates these idle resources to improve overall resource utilization. During pod recycling, a warm-up start strategy is applied to pods, initially allocating 25% of resources to the new pod and gradually increasing that to 100% over 5 minutes. This warm-up start strategy prevents system load fluctuations caused by new pods suddenly occupying a large amount of resources. It enables the system to smoothly adapt to changes in resource allocation, ensuring business stability and continuity.

[0053] S8. Synchronize isolation policies to multiple clusters through the Kubernetes Federation component. Kubernetes Federation is a multi-cloud and multi-cluster management tool for Kubernetes that supports unified management of resources and policies across multiple clusters.

[0054] Resource allocation, network isolation, and intelligent scheduling modules are independently deployed in each cluster. These modules perform specific resource management and isolation operations in the local cluster based on synchronized isolation policies. Cross-cluster policy consistency is ensured through the Raft algorithm, a distributed consensus algorithm that ensures consistent policy copies across multiple clusters, avoiding policy conflicts. If the primary cluster fails, the system automatically switches to the backup cluster and maintains isolation. The backup cluster takes over the primary cluster's responsibilities and continues to provide services to tenants, ensuring high service availability and continuity while maintaining resource isolation for each tenant.

[0055] The above description is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with the technical field, within the technical scope disclosed by the present invention, who makes equivalent replacements or changes based on the technical solution and inventive concept of the present invention, should be covered by the scope of protection of the present invention.

Claims

1. A multi-tenant resource dynamic isolation method based on Kubernetes, characterized in that: The following steps are involved: S1. Build a CPU resource control group using cgroupsv2 technology, use the CPU.weight parameter to achieve proportional allocation of CPU shares between tenants, and deploy a CPU core dynamic binding engine. This engine uses the Kubelet component to collect container CPU usage data in real time. When it detects that the CPU utilization of a tenant's application exceeds the preset threshold for three consecutive sampling periods, it automatically triggers the CPU core rebinding mechanism. By modifying the cpuset.cpus parameter of cgroupsv2, the idle CPU cores in the node are dynamically bound to the target container, and the CPU.weight value is adjusted simultaneously to expand the resource share. During the binding process, kernel-level CPU affinity configuration is implemented through the sched_setaffinity system call. S2. Build a storage pool based on the Ceph distributed file system. Create an independent Provisioner controller for each tenant. This controller dynamically generates PersistentVolumeClaims through StorageClass definitions. Each PVC is associated with a dedicated RBD block device. Combined with Ceph's RBD snapshot technology, incremental snapshots are created for tenant data volumes according to preset policies. Snapshot data is stored in an independent OSD node cluster. Ceph's CRUSH rules forcibly assign different tenants' data volumes to physically isolated storage node groups to achieve storage media-level isolation. Access control lists at the FUSE file system layer are used to restrict cross-tenant data access. S3. Use the Kubernetes network plug-in to create an independent network namespace for each tenant, configure a dedicated IP address range and routing table, implement ARP suppression by setting the net.ipv4.conf.all.arp_ignore=2 and net.ipv4.conf.all.arp_announce=2 parameters, limit the broadcast domain to the tenant's VPC, and load the eBPF-based traffic control program. This program uses the ingress / egress hook functions of the TrafficControl subsystem to limit the rate of tenant egress traffic according to QoS level. It also encapsulates tenant traffic using LWTunnel technology to achieve complete isolation of data packets between tenants in the underlying network. S4. Build a resource prediction model based on an LSTM neural network. This model collects tenant resource usage data from the past seven days, performs sliding average processing on a 15-minute time window, and trains model parameters using the Adam optimizer. The model automatically updates every hour and predicts resource demand trends for the next four hours. When it is predicted that a tenant's resource utilization will exceed the threshold, the Kubernetes HorizontalPodAutoscaler mechanism is triggered to expand capacity in advance, and the Prebind scheduling plug-in is used to reserve host resources for the new Pod. At the same time, the Prometheus collection node and the Grafana visualization platform are integrated to build a tenant-level monitoring dashboard, which displays more than 20 indicators such as resource water level, IOPS, and network latency in real time. When the indicator fluctuation exceeds twice the standard deviation, a multi-level alarm is triggered.

2. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: In step S1, when the CPU core dynamic binding engine triggers the rebinding mechanism, it also synchronously binds the corresponding memory node through the Linux cpuset.mems parameter to reduce cross-NUMA access latency, and adopts a progressive resource adjustment strategy, with no more than 2 CPU cores adjusted each time, and the adjustment interval is 500ms.

3. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that In step S2, the Ceph distributed file system generates a SHA-256 hash value for each data block through the RADOS gateway and stores it in an independent metadata server. The hash value is automatically verified each time data is read or written. When tampering is detected, the data is restored from the most recent snapshot and an audit log is recorded.

4. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: In step S3, the eBPF traffic control program maintains the tenant traffic feature library through the map data structure, calculates the traffic quintuple entropy value in real time, and triggers TCPRST blocking and writes it to the kernel blacklist when the entropy value exceeds 3 times the historical average. The blocking period is 5 minutes.

5. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: In step S4, the machine learning model aligns the tenant business logs with the resource usage data time series, identifies the association weights between business indicators and resource consumption through the attention mechanism, and performs resource prediction based on the business indicators.

6. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: The following steps are also included: S5. Use the AES-256 algorithm to perform field-level encryption on sensitive fields in the data storage layer, enable TDE transparent encryption for data volumes, and use Seccomp / BPF technology to generate a whitelist system call set when the container is running, allowing only necessary calls such as read, write, and mmap, blocking dangerous operations such as chroot and mount, and limiting the container's access to the host file system through AppArmor.

7. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: The following steps are also included: S6. Define tenant policy resource objects containing resource quota rules, network policy rules, and security policy rules through Kubernetes' CRD. Policy configuration takes effect in real time through the Webhook controller. When modified, it automatically triggers configuration updates of resource allocation, network isolation, and security modules. The update delay does not exceed 10 seconds.

8. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: The following steps are also included: S7: When the tenant resource utilization rate is lower than the preset threshold for one hour in a row, the idle resources are marked as recyclable through the Downward API and reallocated by the scheduler. During the recycling, the preheat start strategy is adopted for the Pod, first allocating 25% of the resources and gradually increasing to 100% within 5 minutes.

9. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 6, characterized in that: In the container runtime security protection, the system call sequence of the container process is monitored by the eBPF probe. When an abnormal call chain is detected, the container is restarted and reported to the security management center to update the Seccomp / BPF whitelist rules.

10. A multi-tenant resource dynamic isolation method based on Kubernetes according to claim 1, characterized in that: The following steps are also included: S8. Use the Kubernetes Federation component to synchronize isolation policies to multiple clusters. Deploy resource allocation, network isolation, and intelligent scheduling modules independently in each cluster. Use the Raft algorithm to ensure cross-cluster policy consistency. When the primary cluster fails, it automatically switches to the backup cluster and maintains isolation.

Images