Policy-based K8s NodePort service exposure control method

Abstract

The invention provides a strategy-based K8s NodePort service exposure control method, which comprises the following steps of: grouping nodes in a cluster according to a preset node label strategy, and configuring a port range allowed to be used and a corresponding namespace for each node group; when a NodePort service is created in a specified namespace, determining a node set and a port range which should be exposed by the service based on a binding relationship between the namespace and a node group and the node group selected by a tenant; according to the determined node set and port range, dynamically configuring and opening a NodePort port on the corresponding node to realize policy-based exposure of the service; and monitoring changes of node group configuration, a port range or a namespace binding relationship in real time, and dynamically updating the exposed node and port configuration of the created NodePort service when the changes are detected. According to the method, the attack surface exposed by the service can be effectively reduced, and the port resource utilization rate and the isolation control capability in a multi-tenant environment are enhanced through node grouping and a port range multiplexing mechanism.

Description

Technical Field

[0001] This invention relates to the field of Kubernetes service exposure policy management technology, and in particular to a policy-based K8s NodePort service exposure control method. Background Technology

[0002] Kubernetes (K8s), as a core technology of container orchestration systems, is widely used in enterprise-level cloud-native architectures for the automated deployment, scaling, and management of containerized applications. Among its related technologies, a flexible service discovery and access mechanism is built through the collaborative work of Services, Pods, and Labels. Specifically, this system covers the entire process from service definition and node scheduling to network exposure, including key aspects such as Label Selectors, Service Types, and port mapping strategies. NodePort Service, as a typical way for K8s to expose services, provides an access point for external clients by opening static ports on cluster nodes, and is an important means of achieving hybrid cloud and multi-tenant service integration. With the continuous expansion of container cluster scale, the traditional NodePort service exposure method has gradually revealed systemic defects in terms of security, resource utilization, and tenant isolation, urgently requiring optimization and reconstruction using new technologies.

[0003] However, existing NodePort service exposure methods directly employ a global port exposure mechanism without effective control over the exposed nodes, significantly expanding the attack surface and posing a risk of malicious exploitation. Specifically, traditional methods force the same port to be open on all nodes, allowing attackers to initiate access from any node, potentially leading to service interruptions or data breaches. Furthermore, NodePort's default port range is limited (30000-32767), making it prone to port resource exhaustion or conflicts in large-scale clusters, impacting normal service deployment and expansion. Simultaneously, existing technologies lack fine-grained control over tenants or namespaces, potentially causing interference between services from different tenants due to chaotic port allocation, failing to meet the resource isolation and security compliance requirements of enterprise-level multi-tenant environments. These issues are particularly prominent in highly security-sensitive sectors such as finance and government, severely restricting the application performance of Kubernetes in complex business scenarios. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a policy-based method for controlling the exposure of K8s NodePort services.

[0006] The second objective of this invention is to provide a policy-based K8s NodePort service exposure control device.

[0007] The third objective of this invention is to provide an electronic device.

[0008] The fourth objective of this invention is to provide a computer-readable storage medium.

[0009] The fifth objective of this invention is to provide a computer program product.

[0010] To achieve the above objectives, a first aspect of the present invention proposes a policy-based K8sNodePort service exposure control method, comprising: S1, grouping nodes in the cluster according to a preset node label policy, and configuring the allowed port range and corresponding namespace for each node group; S2, when a NodePort service is created in a specified namespace, determining the set of nodes and port range to be exposed for the service based on the binding relationship between the namespace and the node group and the node group selected by the tenant; S3, dynamically configuring and opening NodePort ports on the corresponding nodes according to the determined set of nodes and port range, thereby achieving policy-based exposure of the service; S4, monitoring changes in node group configuration, port range, or namespace binding relationship in real time, and dynamically updating the exposed node and port configuration of the created NodePort service when changes are detected.

[0011] In one embodiment of the present invention, the step of grouping nodes in the cluster according to a preset node label strategy and configuring the allowed port range and corresponding namespace for each node group further includes: S11, dividing nodes with the same label into a node group by adding a node-group label to the nodes, and configuring an independent port range for each node group, wherein the port range may overlap with the port range of other node groups; S12, configuring a list of allowed namespaces for each node group, wherein the namespace list is used to restrict the node group to only provide port exposure support for the NodePort service in the specified namespace.

[0012] In one embodiment of the present invention, when creating a NodePort service in a specified namespace, determining the set of nodes and port range to be exposed for the service based on the binding relationship between the namespace and the node group and the node group selected by the tenant further includes: S21, if the tenant does not specify a node group when creating the NodePort service, the default node group bound to the namespace is automatically used for service exposure; S22, if the tenant specifies a node group when creating the NodePort service, the configuration of the specified node group is used first, and it is verified whether the node group is allowed to be used in the current namespace. If it is not allowed, the service exposure request is rejected.

[0013] In one embodiment of the present invention, the step of dynamically configuring and opening NodePort ports on the corresponding nodes according to the determined set of nodes and port range to realize the policy-based exposure of services further includes: S31, using a tag matching mechanism to filter out nodes belonging to the target node group from the cluster, and performing port opening operations on these nodes; S32, using a port allocation algorithm to allocate unoccupied ports for services within the configured port range, and ensuring the uniqueness of ports within the same node group.

[0014] In one embodiment of the present invention, it further includes: S5, when a port allocation failure is detected, a port conflict detection mechanism is triggered, and port resources are dynamically scheduled and reallocated among multiple node groups according to a preset port allocation strategy.

[0015] To achieve the above objectives, a second aspect of the present invention provides a policy-based K8sNodePort service exposure control device, comprising: a node grouping and policy configuration module, used to group nodes in the cluster according to a preset node label policy, and configure the allowed port range and corresponding namespace for each node group; a service exposure node and port determination module, used to determine the set of nodes and port range to be exposed for the service based on the binding relationship between the namespace and the node group and the node group selected by the tenant when a NodePort service is created in a specified namespace; a port dynamic configuration module, used to dynamically configure and open NodePort ports on the corresponding nodes according to the determined set of nodes and port range, thereby realizing policy-based service exposure; and a configuration monitoring and update module, used to monitor changes in node group configuration, port range, or namespace binding relationship in real time, and dynamically update the exposed node and port configuration of the created NodePort service when a change is detected.

[0016] In one embodiment of the present invention, the node grouping and policy configuration module is further configured to: divide nodes with the same label into a node group by adding a node-group label to the nodes, and configure an independent port range for each node group, wherein the port range may overlap with the port range of other node groups; configure a list of allowed namespaces for each node group, wherein the namespace list is used to restrict the node group to provide port exposure support only for NodePort services in the specified namespace.

[0017] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0018] The memory stores computer-executed instructions;

[0019] The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0020] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0021] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects.

[0022] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: they can effectively reduce the attack surface of exposed services, improve security, and enhance port resource utilization and isolation control capabilities in a multi-tenant environment through node grouping and port range reuse mechanisms.

[0023] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0024] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of a policy-based K8s NodePort service exposure control method according to an embodiment of the present invention;

[0026] Figure 2 This is a schematic diagram of the structure of a policy-based K8s NodePort service exposure control device according to an embodiment of the present invention. Detailed Implementation

[0027] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0028] Figure 1 This is a flowchart of a policy-based K8s NodePort service exposure control method according to an embodiment of the present invention.

[0029] like Figure 1 As shown, the policy-based Kubernetes NodePort service exposure control method includes the following steps:

[0030] S1 groups the nodes in the cluster according to the preset node labeling policy and configures the allowed port range and corresponding namespace for each node group.

[0031] Specifically, the step of "grouping nodes in the cluster according to a preset node labeling policy and configuring the allowed port range and corresponding namespace for each node group" is one of the core components of this invention for achieving fine-grained exposure control of NodePort services. Its technical implementation principle is based on Kubernetes (K8s)'s label mechanism and custom policy configuration. By dividing nodes into multiple logical groups and binding specific port ranges and namespaces to each group, it achieves selective service exposure points, flexible allocation of port resources, and tenant-level resource isolation.

[0032] Furthermore, S1 includes:

[0033] S11, by adding a node-group label to the nodes, nodes with the same label are divided into a node group, and an independent port range is configured for each node group. The port range may overlap with the port range of other node groups.

[0034] Specifically, this step involves adding node-group labels to Kubernetes nodes, grouping nodes with the same label into a node group, configuring an independent NodePort port range for each node group, and allowing duplicate port ranges between different node groups. This technology combines Kubernetes' label mechanism with service exposure policies, aiming to improve the security, resource utilization, and management flexibility of NodePort services in multi-tenant, large-scale cluster environments.

[0035] At the technical implementation level, administrators add custom tags to nodes using the Kubernetes API or the kubectl tool, such as `node-group=nodeport-svc-group1` or `node-group=nodeport-svc-group2`. Tag addition must follow the Kubernetes tag naming convention (Key=Value format, where the Key is typically `node-group` and the Value is the node group identifier). Subsequently, the system identifies and aggregates nodes with the same `node-group` tag through the policy configuration module, forming logical node groups. Each node group can be configured with an independent NodePort range, such as 30000-30500, 30500-31000, etc. These port ranges are defined through custom configuration files or CRDs and stored in Kubernetes ConfigMaps or custom resources.

[0036] At the parameter level, the NodePort range must conform to the standard TCP / UDP port range (1-65535) and avoid conflicts with system reserved ports (such as 0-1023). In large-scale clusters, each node group can be configured with multiple port ranges, such as 30000-30500 and 31000-31500, to improve port utilization. Furthermore, the system supports multiple node groups configuring the same port range; for example, two node groups can both be configured with 30000-30500. Since the service is only exposed on nodes within the group, port conflicts will not affect the normal operation of the service.

[0037] At the application level, this step is applicable to scenarios such as multi-tenant Kubernetes clusters, hybrid cloud deployments, and edge computing nodes. For example, in an enterprise private cloud, different business units can be assigned to different node groups, with each node group configured with an independent NodePort range to achieve business isolation and resource control. In edge node deployments, NodePort services are exposed only on nodes with public IP addresses, improving service reachability and security.

[0038] The technical advantage of this step lies in its ability to logically group nodes through a tagging mechanism, combined with independent port range configuration, effectively controlling the range of nodes exposed to the service, reducing the attack surface, and simultaneously improving port resource utilization and management flexibility. This method breaks through the traditional limitation that NodePort services must be exposed on all nodes, providing a new implementation path for fine-grained management of Kubernetes clusters.

[0039] S12, Configure a list of allowed namespaces for each node group. The list of namespaces is used to restrict the node group to provide port exposure support only for the NodePort service in the specified namespace.

[0040] Specifically, configuring a list of allowed namespaces for each node group is one of the core steps in this invention to achieve multi-tenant resource isolation and service exposure control. This step introduces a namespace binding mechanism in the Kubernetes (K8s) cluster to bind the exposure permissions of the NodePort service to a specific namespace, thereby achieving fine-grained control over the scope of service exposure.

[0041] At the implementation level, this step relies on Kubernetes' label mechanism and the extensibility of custom resource definitions (CRDs) or custom controllers. Specifically, the system defines a namespace whitelist for each node group through a policy configuration module. This whitelist is stored as a list and is typically managed through custom resource objects (such as NodePortPolicy). For example, an administrator can configure the allowed namespace list for the node group node-group-name=test1 as ["ns-a","ns-b","ns-c"], indicating that this node group can only provide port exposure support for NodePort services in these three namespaces. When a service is created, the system checks whether the namespace where the service resides is in the whitelist of the corresponding node group. If not, it refuses to expose the service port on the nodes of that node group.

[0042] At the parameter level, the configuration of the namespace list typically follows the standard Kubernetes tag format, such as `kubernetes.io / metadata.namespace` or a custom tag `nodeport.namespace=ns-a`. Furthermore, the length of the namespace list, its update frequency, and matching strategy (such as exact matching or wildcard matching) can all be parameterized through policy configuration. For example, the maximum number of namespaces allowed to be bound can be set to 100 to prevent overly complex policies from degrading scheduling efficiency. Simultaneously, the binding relationship between namespaces and node groups supports dynamic updates; the system synchronizes the policy in real time by listening to APIServer events (such as Add / Update / Delete Namespace or NodePortPolicy).

[0043] At the application level, this step is widely applicable to Kubernetes cluster environments requiring resource isolation and security control, such as multi-tenant, hybrid cloud, and edge computing. For example, on enterprise-grade Kubernetes platforms, different business units or customers are assigned to different namespaces. By configuring a corresponding namespace list for each node group, it can be ensured that the NodePort service is exposed only on authorized nodes, thereby preventing cross-tenant port conflicts and unauthorized access. Furthermore, in security-sensitive environments, such as finance and government, this mechanism can effectively limit the range of nodes where services are exposed, improving the overall system security.

[0044] From a technical perspective, this step achieves namespace-level control over NodePort service exposure, resolving the decoupling issue between namespaces and node exposure strategies in traditional methods. By binding namespaces to node groups, the system can automatically identify the namespace a service belongs to when it is created and select the appropriate node group for service exposure based on preset policies, thereby improving system security, resource utilization, and management efficiency. This mechanism not only enhances Kubernetes' service exposure capabilities but also provides crucial technical support for building highly secure, highly isolated multi-tenant container platforms.

[0045] S2, When a NodePort service is created in a specified namespace, the set of nodes and port range that the service should expose are determined based on the binding relationship between the namespace and the node group, as well as the node group selected by the tenant.

[0046] Specifically, when a NodePort service is created in a specified namespace, determining the set of nodes and port range to be exposed by the service based on the binding relationship between the namespace and the node group, as well as the node group selected by the tenant, is one of the core steps in this invention for implementing service exposure policy control. This step, by introducing a namespace binding mechanism and a node group labeling strategy, achieves dynamic and fine-grained control over the range of nodes and ports exposed by the NodePort service, thereby effectively improving cluster security, resource utilization, and multi-tenant isolation capabilities.

[0047] Furthermore, S2 includes:

[0048] S21. If the tenant does not specify a node group when creating the NodePort service, the default node group bound to the namespace will be used automatically for service exposure.

[0049] Specifically, in Kubernetes (K8s) systems, the exposure mechanism of NodePort services typically relies on the global configuration of cluster nodes, meaning the service port is open on all nodes. This poses significant security risks and resource management issues in multi-tenant and large-scale cluster scenarios. This invention proposes a policy-based NodePort service exposure method. If a tenant does not specify a node group when creating a NodePort service, the system will automatically use the default node group bound to that namespace for service exposure. This step is crucial for achieving tenant-level resource isolation and fine-grained port management.

[0050] At the technical implementation level, this step relies on the binding mechanism between namespaces and node groups. Specifically, the system defines a default node group for each namespace through the policy configuration module. This node group consists of a set of nodes with specific tags (e.g., node-group = nodeport-svc-group1). When a tenant creates a NodePort service under this namespace, if the nodeGroup field is not explicitly specified in the Service's YAML configuration, the system will automatically read the namespace's binding policy, extract its associated default node group, and expose the service port only on nodes within that group. This process is implemented through Kubernetes custom resource definitions or custom controllers. The controller listens for Service resource creation events and performs node group matching and port allocation based on the namespace's binding policy.

[0051] At the parameter level, this step involves several key configuration parameters. For example, the label format for namespace-bound node groups can be defined as namespace-node-group-binding= <group-name>The tag format for a node group is node-group= <group-name>In terms of port allocation, each node group can be configured with an independent port range, such as nodeport-range = 30000-30500. When allocating ports, the system will preferentially select available ports from the port pool of the binding node group in the namespace, ensuring the isolation and controllability of port resources. In addition, the system supports repeated configuration of node group port ranges, for example, multiple node groups can be configured with 30000-30500. Through the uniqueness of node labels, logical isolation is achieved, thereby improving the utilization of port resources.

[0052] At the application scenario level, this step is widely applicable to multi-tenant Kubernetes cluster environments. For example, in enterprise-level cloud platforms, services of different tenants are deployed in different namespaces, and each namespace is bound to one or more node groups with explicit security policies. When a tenant does not specify a node group, the system automatically uses the default node group bound to its namespace for service exposure, ensuring that the service only runs on authorized nodes and avoiding port conflicts and security risks across tenants. In addition, in hybrid cloud or edge computing scenarios, this mechanism can restrict NodePort services to nodes in specific regions or with specific hardware configurations, enabling more flexible service deployment strategies.

[0053] The technical effect of this step is that by introducing the binding mechanism of namespaces and node groups, it realizes tenant-level service exposure control, effectively improving the security, resource utilization, and management flexibility of the cluster. In the case where no node group is specified, the system can intelligently select the default node group, avoiding service exposure on unintended nodes, thereby reducing the attack surface and enhancing the controllability of services. Further, this mechanism works in coordination with the policy listening module, and when the node group configuration changes, the system can dynamically adjust the service exposure strategy, ensuring the high availability and elastic expansion capability of services.

[0054] S22, if the tenant specifies a node group when creating the NodePort service, the configuration of the specified node group is used preferentially, and it is verified whether the node group is allowed to be used in the current namespace. If not allowed, the service exposure request is rejected.

[0055] Specifically, when creating a NodePort Service, if the tenant specifies a specific node group (Node Group), the system will preferentially use the configuration of the node group and verify whether the node group is allowed to be used in the current namespace. If the verification fails, the service exposure request is rejected. This step is one of the core mechanisms for implementing multi-tenant resource isolation and security control in the present application, and its technical implementation is based on the label (Label) mechanism of Kubernetes, the namespace binding policy, and the admission control logic when creating a service.

[0056] In terms of technical implementation, when creating a NodePort Service, the tenant can specify the target node group in the YAML configuration of the Service through the nodeGroup field. After receiving the service creation request, the system first calls the policy application module to extract the configuration information related to the node group from the cluster's policy configuration, including the allowed port range (such as 30000-32767, 35000-36000, etc.) and the allowed namespace list. Then, the system compares the namespace of the current request with the namespace whitelist of the node group to determine whether it has the right to use. This verification process is usually implemented through Kubernetes' Admission Controller or Operator mode, combined with custom resource definition (CRD) or ConfigMap policy configuration for logical judgment.

[0057] In terms of parameter index, the configuration of the node group usually includes label key-value pairs (such as node-group=nodeport-svc-group1), port range (Port Range), and namespace binding list (Namespace Bindings). The setting of the port range needs to follow the standard port allocation specification of Kubernetes, i.e., the port number needs to be within 30000-32767 or a user-defined legal range. In addition, the system supports multiple node groups configuring the same port range, achieving logical isolation of ports through the uniqueness of node labels, thereby improving the utilization of port resources.

[0058] In terms of application scenarios, this step is widely applicable to multi-tenant Kubernetes cluster environments. For example, in an enterprise cloud platform, different business departments (tenants) may be assigned to different namespaces and each have their own exclusive node group for deploying and exposing services. Through this mechanism, tenants can only create NodePort services on the node groups they are authorized to use, avoiding port conflicts and illegal exposure across tenants, and improving the security and resource utilization of the cluster.

[0059] The technical effect of this step is to achieve fine-grained control of NodePort service exposure, ensuring that services are only exposed on authorized node groups, and effectively preventing unauthorized namespaces from using port resources of specific node groups. By introducing the binding verification mechanism between node groups and namespaces, the system performs policy interception during the service creation phase, avoiding subsequent resource waste or security vulnerabilities caused by configuration errors, thereby improving the management efficiency and security of Kubernetes clusters in multi-tenant scenarios.

[0060] S3, dynamically configuring and opening NodePort ports on the corresponding nodes according to the determined node set and port range, to achieve the policy-based exposure of the service.

[0061] Specifically, in some implementations, dynamically configuring and opening NodePort ports on the corresponding nodes according to the determined node set and port range is one of the core steps of the present application to achieve the policy-based exposure of the service. This step realizes the fine control and dynamic deployment of the NodePort service by combining the label mechanism (Label) of Kubernetes (K8s), the node group policy (Node Group Policy), and the configuration logic of the Service.

[0062] Further, S3 includes:

[0063] S31, filtering out nodes belonging to the target node group from the cluster using a label matching mechanism, and performing a port opening operation on these nodes.

[0064] Specifically, in the present application, the step of "filtering out nodes belonging to the target node group from the cluster using a label matching mechanism, and performing a port opening operation on these nodes" is one of the core steps of the policy-based NodePort service exposure. This step realizes the accurate control of the NodePort service exposure nodes by combining the node label of Kubernetes and the service configuration through the label selector mechanism, thereby improving the security, resource utilization, and multi-tenant isolation capability of the system.

[0065] In terms of technical implementation, this step first relies on the exclusive labels set for the nodes in the policy configuration module, such as node-group=nodeport-svc-node or node-group-name=test1. The administrator adds these labels to the nodes through the Kubernetes API or cluster management tools to form logical node groups (Node Group). When creating the NodePort Service, the system reads the node group label matching rules in the service definition through the policy application module, and calls the label selector mechanism of Kubernetes to filter out the node set that meets the label conditions from the cluster node list. This process is usually implemented through the kubectl command or custom controller (Controller), which relies on the ListAndWatch mechanism of Kubernetes to query and filter the Node resources in real time.

[0066] At the parameter index level, the label matching mechanism supports multiple matching strategies, including exact matching (node-group=nodeport-svc-node), wildcard matching (node-group=nodeport-*) and multi-label combination matching (node-group=nodeport-svc-node, region=cn-beijing). The port opening operation configures iptables or IPVS rules on the target node through the kube-proxy component to map the specified port (such as 30000-32767) to the ClusterIP and port of the Service. In the present application, each node group can be configured with an independent port range, such as --nodeport-range=30000-32767, and the port range is allowed to be repeated between multiple node groups, thereby improving the utilization and flexibility of port resources.

[0067] At the application scenario level, this step is widely applicable to multi-tenant Kubernetes cluster environments. For example, in an enterprise-level cloud-native platform, different business departments or tenants can be assigned to different namespaces (Namespaces) and bound to specific node groups. When a tenant creates a NodePort Service in a namespace, the system automatically filters out the target node group according to the binding relationship and opens the port on the nodes in the group to achieve targeted exposure of the service. In addition, in hybrid cloud or edge computing scenarios, this mechanism can be used to expose services only on nodes with specific network conditions or security policies to meet compliance and performance requirements.

[0068] The technical effect of this step is to achieve precise control of service exposure nodes through the label matching mechanism, effectively reducing the attack surface and improving cluster security; at the same time, through the dynamic port allocation strategy, port resource conflicts are avoided and resource utilization is improved. Further, this mechanism supports namespace binding in a multi-tenant environment, enabling fine-grained management of service exposure and enhancing the scalability and isolation of the system. It is a key technical support for the present application to achieve secure, flexible and controllable service exposure.

[0069] S32, using a port allocation algorithm to allocate an unoccupied port to the service within the configured port range and ensuring the uniqueness of the port within the same node group.

[0070] Specifically, in the present application, "using a port allocation algorithm to allocate an unoccupied port to the service within the configured port range and ensuring the uniqueness of the port within the same node group" is one of the core steps for implementing policy-based NodePort service exposure. This step introduces a dynamic port allocation mechanism, combines node group label strategies and namespace binding logic, and achieves efficient management and conflict avoidance of port resources.

[0071] At the technical implementation level, this step relies on a custom port allocation algorithm module that runs on the Kubernetes control plane, typically integrated into a custom controller or Operator. When a user creates a Service of type NodePort, the system first resolves the Namespace to which the Service belongs and determines the NodeGroup to which it should belong according to the preset Namespace binding strategy. Subsequently, the system calls the port allocation algorithm module to find an unoccupied port from the configured port range (such as 30000-31000, 31000-32000, etc.) of the NodeGroup. The port occupation state is recorded by maintaining a global Port Allocation Table, which stores the mapping between allocated ports and corresponding Services in each NodeGroup and supports concurrent access and atomic update operations to ensure data consistency.

[0072] At the parameter index level, the port allocation algorithm supports multiple configuration parameters, including PortRangeStart, PortRangeEnd, port allocation strategies (such as sequential allocation, random allocation, optimal matching, etc.), and port conflict detection mechanisms (such as etcd-based locking or Informer-based resource listening). In some implementations, the system can set the PortGranularity, such as incrementing by 10, to avoid frequent port allocation failures. In addition, the system can also configure the ReservedPorts policy to reserve some ports for critical services to prevent normal services from preempting high-priority ports.

[0073] At the application scenario level, this step is widely applicable to multi-tenant, large-scale Kubernetes cluster environments. For example, in an enterprise-level cloud-native platform, different business departments (tenants) can be assigned to different Namespaces and bound to their own dedicated NodeGroups. When creating a NodePort service, the system automatically allocates an unoccupied port from the NodeGroup's port range corresponding to the tenant, ensuring the isolation and efficient reuse of port resources. When the NodeGroup dynamically expands, the strategy listening module updates the port allocation table in real time to ensure that the new nodes can correctly expose service ports, thereby improving the system's flexibility and availability.

[0074] The technical effect of this step is that by introducing the port allocation algorithm and the node group binding mechanism, the problems of traditional NodePort service in port resource conflict, large security exposure surface and lack of fine-grained control are effectively solved. The innovation lies in the deep combination of port allocation and node group strategy, realizing the dynamic management and tenant-level isolation of port resources, and significantly improving the security, scalability and resource utilization of Kubernetes cluster in large-scale deployment scenarios.

[0075] S4, real-time monitoring of changes in node group configuration, port range or namespace binding relationship, and dynamically updating the exposed nodes and port configuration of the created NodePort service when detecting the changes.

[0076] Specifically, the step of "real-time monitoring of changes in node group configuration, port range or namespace binding relationship, and dynamically updating the exposed nodes and port configuration of the created NodePort service when detecting the changes" in the present application is a key link in the implementation of the policy-based NodePort service exposure mechanism. The technical implementation is based on the API Watch mechanism and controller mode of Kubernetes (K8s), which continuously monitors the configuration changes related to NodePort policy in the cluster to realize dynamic adjustment of service exposure configuration.

[0077] In terms of technical implementation, this step listens to the change events of resource objects (such as Node, ConfigMap, CustomResourceDefinition, etc.) related to node labels, node group configuration (NodeGroup Config), and namespace binding in the Kubernetes API Server by deploying a custom controller or using the Operator mode. Specifically, the system subscribes to the label changes of Node objects, the port range configuration updates in ConfigMap or custom resources, and the binding relationship changes between Namespace and node groups through the Watch interface. When any of the above configuration items changes, the controller triggers the re-evaluation and update process of service configuration.

[0078] At the parameter level, this monitoring mechanism supports various configuration parameters, including but not limited to: node group labels (e.g., node-group=nodeport-svc-node), port range configurations (e.g., port-range=30000-32767), and namespace binding configurations (e.g., namespace=nodeport-ns). The system can set the monitoring frequency (e.g., polling once per second by default or event-triggered) and supports version control for configuration changes (e.g., incremental updates via the ResourceVersion field) to improve system response efficiency and resource utilization. Furthermore, port allocation strategies can employ hash algorithms or round-robin mechanisms to ensure reasonable port distribution across multiple node groups and avoid conflicts.

[0079] At the application level, this step is widely applicable to multi-tenant, large-scale Kubernetes cluster environments. For example, in enterprise-grade cloud-native platforms, different business units or tenants can have independent namespaces and node group configurations. When a tenant adjusts its service exposure policy, the system can automatically identify and update the exposed nodes and ports of its NodePort service without manual intervention, thereby achieving automation and elasticity in service configuration.

[0080] The technical advantage of this step lies in its ability to dynamically adjust the exposure scope of NodePort services by responding to policy configuration changes in real time, effectively improving service security, resource utilization, and management flexibility. Its innovation lies in combining a policy-driven mechanism with Kubernetes' dynamic monitoring capabilities, achieving automation, fine-grained control, and scalability in service exposure configuration, providing solid technical support for service governance in multi-tenant environments.

[0081] The policy-based K8s NodePort service exposure control method of this invention achieves precise control over NodePort service exposure through node grouping, port range configuration, and namespace binding strategies, effectively improving cluster security, expanding port resource utilization, and supporting resource isolation and fine-grained management in multi-tenant environments.

[0082] Furthermore, in this embodiment of the invention, when a port allocation failure is detected, a port conflict detection mechanism is triggered, and port resources are dynamically scheduled and reallocated among multiple node groups according to a preset port allocation strategy.

[0083] Specifically, when a port allocation failure is detected, the system will trigger a port conflict detection mechanism and dynamically schedule and reallocate port resources among multiple node groups according to a preset port allocation strategy. This step is the core of the invention for achieving flexible port resource management and conflict avoidance, and its technical implementation is based on the dynamic response capabilities of Kubernetes (K8s) tagging mechanism, custom controllers, and service exposure strategies.

[0084] At the technical implementation level, when the Kubernetes API Server attempts to allocate a port for a NodePort Service, if no available port can be found within the preset port range of the current node group (e.g., the port is already in use or exceeds the configuration range), a port allocation failure event will be returned. At this point, the conflict detection mechanism is activated. The system listens for Service creation or update events through a custom controller and performs conflict analysis based on the predefined node group port range (e.g., node-group-port-range = 30000-30500) in the policy configuration module. Furthermore, the system dynamically schedules port resources across multiple node groups according to preset port allocation strategies (e.g., round-robin, priority, load balancing, etc.), attempting to find available ports in other node groups and rebinding the Service to a node in a node group with available ports.

[0085] At the parameter level, the port conflict detection mechanism relies on several key parameters, including but not limited to: node group label, port allocation strategy type, port range, and namespace binding relationship. For example, the system can be configured with multiple node groups, each supporting an independent port range (e.g., Group A: 30000-30500, Group B: 30500-31000), and allowing port ranges to be reused across different node groups. Furthermore, the system can set the retry count and retry interval for failed port allocation to optimize resource scheduling efficiency.

[0086] At the application level, this step is widely applicable to large-scale Kubernetes clusters and multi-tenant environments. For example, in enterprise-level Kubernetes platforms, different business units (tenants) may have their own namespaces and node groups. When a tenant's service cannot be allocated a port in the current node group, the system can automatically reroute it to other node groups, ensuring high availability and rapid deployment of the service. Simultaneously, this mechanism can work in conjunction with Kubernetes components such as Ingress and Service Mesh to implement more complex network exposure strategies.

[0087] From a technical perspective, this step effectively solves the problem of traditional NodePort services failing to automatically recover from port resource conflicts, improving the cluster's resource utilization and elastic scheduling capabilities. Through dynamic scheduling and policy-driven port allocation mechanisms, the system can reallocate port resources without interrupting services, thereby enhancing the stability and security of the Kubernetes cluster in high-concurrency, multi-tenant scenarios.

[0088] The policy-based K8s NodePort service exposure control method of this invention automatically triggers a port conflict detection and dynamic scheduling mechanism when port allocation failure is detected, realizing flexible reallocation of port resources across node groups, further improving port resource utilization and system fault tolerance, and ensuring high availability and stability of the service exposure process.

[0089] To implement the above embodiments, the present invention also proposes a policy-based K8s NodePort service exposure control device. For example... Figure 2 As shown, the device includes:

[0090] The node grouping and policy configuration module 100 is used to group the nodes in the cluster according to the preset node label policy, and configure the allowed port range and corresponding namespace for each node group.

[0091] The service exposure node and port determination module 200 is used to determine the set of nodes and port range that the service should expose when a NodePort service is created in a specified namespace, based on the binding relationship between the namespace and the node group and the node group selected by the tenant.

[0092] The port dynamic configuration module 300 is used to dynamically configure and open NodePort ports on the corresponding nodes based on a determined set of nodes and port range, so as to expose services according to policies.

[0093] The configuration monitoring and update module 400 is used to monitor changes in node group configuration, port range or namespace binding relationship in real time, and dynamically update the exposed node and port configuration of the created NodePort service when changes are detected.

[0094] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0095] To implement the above embodiments, the present invention also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0096] To implement the above embodiments, the present invention also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0097] To implement the above embodiments, the present invention also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0098] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0099] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0100] This invention is intended to provide implementation schemes for users to selectively prevent the use or access to personal information data. That is, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0101] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0102] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0103] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0104] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0105] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0107] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0108] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0109] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0110] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A policy-based method for controlling the exposure of Kubernetes NodePort services, characterized in that, include: S1, group the nodes in the cluster according to the preset node labeling policy, and configure the allowed port range and corresponding namespace for each node group; S2, When a NodePort service is created in a specified namespace, the set of nodes and port range that the service should expose are determined based on the binding relationship between the namespace and the node group and the node group selected by the tenant; S3 dynamically configures and opens NodePort ports on the corresponding nodes based on the determined set of nodes and port range, thereby enabling the service to be exposed according to the policy. S4 monitors changes in node group configuration, port range, or namespace binding relationships in real time, and dynamically updates the exposed node and port configuration of the created NodePort service when changes are detected.

2. The method as described in claim 1, characterized in that, The step of grouping nodes in the cluster according to a preset node labeling strategy and configuring the allowed port range and corresponding namespace for each node group also includes: S11, by adding a node-group label to the nodes, nodes with the same label are divided into a node group, and an independent port range is configured for each node group. The port range may overlap with the port range of other node groups. S12, Configure a list of allowed namespaces for each node group. The list of namespaces is used to restrict the node group to provide port exposure support only for the NodePort service in the specified namespace.

3. The method as described in claim 1, characterized in that, When creating a NodePort service in a specified namespace, determining the set of nodes and port range that the service should expose, based on the binding relationship between the namespace and the node group and the node group selected by the tenant, further includes: S21. If the tenant does not specify a node group when creating the NodePort service, the default node group bound to the namespace will be used automatically for service exposure. S22. If the tenant specifies a node group when creating the NodePort service, the configuration of the specified node group will be used first, and it will be verified whether the node group is allowed to be used in the current namespace. If it is not allowed, the service exposure request will be rejected.

4. The method as described in claim 1, characterized in that, The step of dynamically configuring and opening NodePort ports on corresponding nodes based on a determined set of nodes and port range to expose services according to a policy also includes: S31 uses a label matching mechanism to filter out nodes belonging to the target node group from the cluster, and performs port opening operations on these nodes; S32 uses a port allocation algorithm to allocate unused ports to services within the configured port range, and ensures the uniqueness of ports within the same node group.

5. The method as described in claim 1, characterized in that, Also includes: S5, when port allocation failure is detected, triggers the port conflict detection mechanism, and dynamically schedules and reallocates port resources among multiple node groups according to the preset port allocation strategy.

6. A policy-based K8s NodePort service exposure control device, characterized in that, include: The node grouping and policy configuration module is used to group nodes in the cluster according to the preset node label policy, and configure the allowed port range and corresponding namespace for each node group. The service exposure node and port determination module is used to determine the set of nodes and port range that the service should expose when a NodePort service is created in a specified namespace, based on the binding relationship between the namespace and the node group and the node group selected by the tenant. The dynamic port configuration module is used to dynamically configure and open NodePort ports on the corresponding nodes based on a defined set of nodes and port range, thereby enabling services to be exposed according to policies. The configuration monitoring and update module is used to monitor changes in node group configuration, port range, or namespace binding relationships in real time, and dynamically update the exposed node and port configuration of the created NodePort service when changes are detected.

7. The apparatus as claimed in claim 6, characterized in that, The node grouping and strategy configuration module is also used for: By adding a node-group label to nodes, nodes with the same label are grouped into a node group, and an independent port range is configured for each node group. The port range may overlap with the port range of other node groups. Configure a list of allowed namespaces for each node group. This list restricts the node group to providing port exposure support only for the NodePort service in the specified namespace.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-5.

Images