A method for realizing public network access of Kubernetes cluster service through a P2P network and a gateway

Abstract

The application provides a method for realizing public network access of Kubernetes cluster service through a P2P network and a gateway, characterized by being based on a Service Controller component, a gateway system, a P2P virtual network and a DNS system; comprising the following steps: S1: deploying the gateway system, configuring a domain name and a generic domain name certificate; S2: deploying a P2P system; S3: configuring a routing forwarding rule for a K8S cluster P2P node through a P2P server; S4: real-time monitoring of resource changes in the Kubernetes cluster; S5: gateway configuration; the application eliminates the single-point failure risk through the P2P virtual network and the point-to-point distributed architecture, prevents the credential leakage risk through end-to-end encryption and dynamic key negotiation, enhances the overall security of the system through the multi-level security mechanism, reduces the network forwarding level and reduces the service access delay.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method for enabling public network access to Kubernetes cluster services through a P2P network and gateway. Background Technology

[0002] With the rapid development of cloud computing and container technology, Kubernetes has become the standard platform for enterprises to build cloud-native applications. Through its powerful container orchestration capabilities, Kubernetes helps enterprises achieve automated deployment, scaling, and management of applications. However, as enterprise business scale expands and the complexity of distributed systems increases, how to achieve secure and efficient interconnection between multiple Kubernetes clusters and securely expose internal services to the public network has become an urgent problem to be solved.

[0003] The above problems are usually solved by three solutions: VPN, cloud service providers, and Service Mesh. These three solutions mainly have problems in terms of security and operation and maintenance. In terms of security, VPN has the risk of single point of failure and credential leakage, API gateways may become targets of attacks, and there is a lack of end-to-end encryption protection. In terms of operation and maintenance, complex network topology needs to be maintained, the configuration process is cumbersome and prone to errors, and the deployment of multiple components increases the difficulty of maintenance.

[0004] In addition, these solutions also face challenges in performance and scalability. The centralized architecture leads to performance bottlenecks and high latency for cross-regional access. At the same time, they are difficult to adapt to dynamic service changes, the scaling process requires a lot of manual operation, and support is limited in cross-cloud deployment scenarios, which seriously affects the efficiency of enterprises using Kubernetes in large-scale distributed environments. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method for enabling public network access to Kubernetes cluster services through a P2P network and gateway.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] A method for enabling public network access to Kubernetes cluster services via a P2P network and gateway, the method being based on a Service Controller component, a gateway system, a P2P virtual network, and a DNS system;

[0008] The Service Controller component is deployed inside the Kubernetes cluster and is used to monitor changes in resources in Kubernetes and dynamically update gateway routing rules.

[0009] The gateway system is used for the management and termination of SSL / TLS certificates, as well as for optimizing service performance through multi-level load balancing strategies.

[0010] The P2P virtual network is used to build a secure communication tunnel based on P2P, supporting end-to-end encrypted communication and dynamic node management;

[0011] The DNS system is used to manage service domain names, providing policy-based intelligent resolution and selection of the nearest access node, and has automatic failover functionality;

[0012] Includes the following sub-steps:

[0013] S1: Deploy the gateway system, configure domain names and wildcard domain certificates;

[0014] Includes the following sub-steps:

[0015] S11: Deploy the gateway system;

[0016] Includes the following sub-steps:

[0017] S111: Assess and prepare the basic environment;

[0018] Before deploying the gateway system, assess and prepare the basic environment, including hardware resource assessment, operating system configuration, and database preparation;

[0019] Specifically, a hardware resource assessment is conducted beforehand, including computing resources such as CPU, RAM, storage, and network bandwidth; to ensure that the hardware resources meet the minimum requirements of the gateway.

[0020] Choose a stable Linux distribution, such as CentOS, Ubuntu, or Debian, and ensure that the kernel version of the chosen operating system meets the gateway requirements, i.e., it supports Linux kernel 4.x or higher; and configure the network parameters, file descriptor limits, and kernel parameters of this operating system.

[0021] Deploy a highly available PostgreSQL database as the backend storage for the gateway and perform performance optimizations; these optimizations include index optimization, query optimization, and caching strategies.

[0022] S112: Deploy the gateway;

[0023] The API gateway is deployed using an architecture that separates the control plane and the data plane.

[0024] Specifically, the control plane node of the gateway is deployed, and the configuration management of the API gateway is performed through the control plane node. The configuration includes routing, authentication, traffic control, etc.; and the gateway Admin API is used for configuration management.

[0025] Deploy multiple gateway data plane nodes to process actual API requests. Each data plane node independently handles external API requests, including request forwarding, response return, API request load balancing, authentication, and authorization.

[0026] S12: Configure the domain name;

[0027] Includes the following sub-steps:

[0028] S121: Register the main domain name;

[0029] Choose a suitable domain registrar based on your actual needs and register a main domain that meets your business or personal requirements.

[0030] S122: Configure A records and wildcard DNS records;

[0031] Log in to the control panel of the selected domain registrar, and in the DNS management or domain name resolution settings of the domain management interface, add a new A record to point the registered main domain name to the public IP address of the gateway;

[0032] The A record is a DNS record type used to map a domain name to a corresponding IPv4 address; it includes the main domain name, type, value, TTL, etc.; the main domain name is the registered main domain name, the type is A record, the value is the public IP address of the gateway, and the TTL is usually 300 seconds.

[0033] In the DNS management section of the domain name management interface, add a wildcard DNS record and configure the A record for the wildcard DNS record so that the A record for the wildcard DNS record points to the same public IP address as the main domain name; the wildcard DNS record is a type of DNS record that makes all subdomains under the registered main domain name point to the same IP address, i.e., the public IP address;

[0034] S123: Verify domain name resolution;

[0035] After configuration, use the nslookup or dig tool in the command line terminal to verify that each main domain name and subdomain points to a public IP address;

[0036] S13: Configure wildcard domain certificate;

[0037] Apply for and distribute wildcard domain certificates;

[0038] Use automated tools such as Certbot to apply for wildcard domain certificates. After successfully obtaining the wildcard domain certificate, distribute the wildcard domain certificate to all gateway nodes that need to use it, ensuring that the wildcard domain certificate is consistent across all gateway nodes, so that the gateway can handle HTTPS requests.

[0039] At the same time, automated tools are used to manage wildcard domain certificates to ensure timely updates and security.

[0040] S2: Deploy a P2P system;

[0041] Includes the following sub-steps:

[0042] S21: Deploy the core components of the P2P server;

[0043] The core components of the P2P server include a P2P management server, a signaling server, and a user authentication management system.

[0044] The P2P management server is used to manage the entire P2P network, including functions such as node registration, connection, and routing; the signaling server is used for signal transmission between nodes; the user authentication management system is used to verify the identity of each node, ensuring that only authenticated nodes can join the P2P network.

[0045] Generate and configure the registration KEY required for P2P node registration. The registration KEY consists of a key pair, which contains a public key and a private key. The private key is kept by the node, and the public key is shared by other nodes.

[0046] Generate key pairs using OpenSSL, GPG, or other encryption tools, configure the generated registration KEY in the P2P management system, and verify the nodes to be added to the P2P network;

[0047] S22: Deploy P2P client nodes;

[0048] On the gateway node, the node is registered and verified using a Docker container and a registration key provided by the P2P server, and the P2P client is deployed.

[0049] In a Kubernetes cluster, multiple P2P client instances are deployed using the StatefulSet controller and the registration key provided by the P2P server.

[0050] S3: Configure routing and forwarding rules for the P2P nodes of the K8S cluster via the P2P server;

[0051] Log in to the P2P server management interface and create routing rules;

[0052] The routing rule includes the target network, next hop, priority, and description. Specifically, in the target network, the IP range of the Pods in the K8S cluster is entered, the P2P node in the K8S cluster is selected as the next hop, the priority of the routing rule is set, and the description information for this routing rule is added.

[0053] After creation, the routing rules are saved to the P2P server. The P2P server then distributes these routing rules to all relevant P2P nodes, enabling the P2P nodes to perform routing forwarding according to these rules.

[0054] The P2P nodes within the K8S cluster periodically synchronize routing rules from the P2P server. When a P2P node receives a new routing rule, it updates its routing table according to the rule.

[0055] On the gateway node, attempt to access the IP addresses of Pods and Services within the Kubernetes cluster. If the routing rules are configured correctly, the gateway node will successfully access the Pods and Services within the Kubernetes cluster, enabling direct communication.

[0056] S4: Real-time monitoring of resource changes in the Kubernetes cluster;

[0057] Includes the following sub-steps:

[0058] S41: Monitoring service resource changes;

[0059] The Service Controller component, deployed in the Kubernetes cluster, monitors changes to service resources in the Kubernetes cluster in real time.

[0060] S42: Initiate the automatic configuration process and collect metadata information;

[0061] When a service is detected to be created, updated, or deleted, the Service Controller component initiates an auto-configuration process and collects the service's metadata information.

[0062] The automatic configuration process includes the automated configuration of network settings, logs, monitoring, authorization, and other aspects of this service;

[0063] The metadata information includes the service's port, protocol, selector, path, load balancing configuration, etc.

[0064] S5: Configure the gateway;

[0065] Includes the following sub-steps:

[0066] S51: Generate gateway routing rules based on service information;

[0067] Based on the service's metadata information, the gateway generates gateway routing rules according to the new service's port, protocol, and path.

[0068] Configure path mapping for the service according to its specific requirements, and configure the corresponding security policies accordingly;

[0069] S52: Automated certificate management and HTTPS configuration;

[0070] Generate SSL / TLS certificates for the service by integrating a certificate management tool or a certificate management tool in Kubernetes; and configure HTTPS routing for the service to achieve encrypted request transmission;

[0071] S53: Implement the load balancing strategy for requests;

[0072] The gateway configures load balancing strategies for services, including round-robin, least connections, weighted load balancing, health checks, and failover.

[0073] Enable public network access for Kubernetes cluster services.

[0074] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0075] This invention eliminates the risk of single point of failure in VPN solutions through P2P virtual networks and peer-to-peer distributed architecture, prevents the risk of credential leakage in VPN solutions through end-to-end encryption and dynamic key negotiation, and enhances the overall security of the system through multi-layered security mechanisms, including HTTPS, P2P encryption and network isolation.

[0076] By using P2P direct connection, network forwarding layers are reduced, lowering service access latency; distributed architecture and efficient data transmission mechanisms improve system throughput; automatic service registration and discovery by Service Controller simplify the discovery process of Kubernetes services; dynamic updating of gateway routing rules automates gateway service route registration; and unified gateway management reduces configuration complexity and improves operational efficiency. Attached Figure Description

[0077] Figure 1 This is a flowchart illustrating the steps of a method for enabling public network access to Kubernetes cluster services via a P2P network and gateway according to the present invention. Detailed Implementation

[0078] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0079] like Figure 1As shown, a method for enabling public network access to Kubernetes cluster services through a P2P network and gateway is described. The method is based on a Service Controller component, a gateway system, a P2P virtual network, and a DNS system.

[0080] The Service Controller component is deployed inside the Kubernetes cluster and is used to monitor changes in resources in Kubernetes and dynamically update gateway routing rules.

[0081] The gateway system is used for the management and termination of SSL / TLS certificates, as well as for optimizing service performance through multi-level load balancing strategies.

[0082] The P2P virtual network is used to build a secure communication tunnel based on P2P, supporting end-to-end encrypted communication and dynamic node management;

[0083] The DNS system is used to manage service domain names, providing policy-based intelligent resolution and selection of the nearest access node, and has automatic failover functionality;

[0084] Through the collaborative work of these core components, this invention enables efficient and secure exposure of Kubernetes intranet services to the public network, while simplifying operation and maintenance management processes and improving system scalability and reliability.

[0085] Includes the following sub-steps:

[0086] S1: Deploy the gateway system, configure domain names and wildcard domain certificates;

[0087] Includes the following sub-steps:

[0088] S11: Deploy the gateway system;

[0089] Includes the following sub-steps:

[0090] S111: Assess and prepare the basic environment;

[0091] Before deploying the gateway system, assess and prepare the basic environment, including hardware resource assessment, operating system configuration, and database preparation;

[0092] Specifically, a hardware resource assessment is conducted beforehand, including computing resources such as CPU, RAM, storage, and network bandwidth; to ensure that the hardware resources meet the minimum requirements of the gateway.

[0093] Specifically, select an appropriate CPU configuration based on the expected API interface request traffic and processing complexity, select an appropriate memory capacity based on the expected load, ensure that the storage capacity can meet the daily operation needs, ensure sufficient bandwidth to support traffic demand, and configure a redundant network to cope with traffic surges under high concurrency conditions.

[0094] Choose a stable Linux distribution, such as CentOS, Ubuntu, or Debian, and ensure that the kernel version of the chosen operating system meets the gateway requirements, i.e., it supports Linux kernel 4.x or higher; and configure the network parameters, file descriptor limits, and kernel parameters of this operating system.

[0095] Deploy a highly available PostgreSQL database as the backend storage for the gateway and perform performance optimizations; these optimizations include index optimization, query optimization, and caching strategies.

[0096] By conducting hardware resource assessments, we ensure that the servers have sufficient computing power and storage space to support the stable operation and scalability of the gateway.

[0097] S112: Deploy the gateway;

[0098] The API gateway is deployed using an architecture that separates the control plane and the data plane.

[0099] Specifically, the control plane node of the gateway is deployed, and the configuration management of the API gateway is performed through the control plane node. The configuration includes routing, authentication, traffic control, etc.; and the gateway Admin API is used for configuration management.

[0100] Deploy multiple gateway data plane nodes to process actual API requests. Each data plane node independently handles external API requests, including request forwarding, response return, API request load balancing, authentication, and authorization.

[0101] S12: Configure the domain name;

[0102] Includes the following sub-steps:

[0103] S121: Register the main domain name;

[0104] Choose a suitable domain registrar based on your actual needs and register a main domain that meets your business or personal requirements.

[0105] S122: Configure A records and wildcard DNS records;

[0106] Log in to the control panel of the selected domain registrar, and in the DNS management or domain name resolution settings of the domain management interface, add a new A record to point the registered main domain name to the public IP address of the gateway;

[0107] The A record is a DNS record type used to map a domain name to a corresponding IPv4 address; it includes the main domain name, type, value, TTL, etc.; the main domain name is the registered main domain name, the type is A record, the value is the public IP address of the gateway, and the TTL is usually 300 seconds.

[0108] In the DNS management section of the domain name management interface, add a wildcard DNS record and configure the A record for the wildcard DNS record so that the A record for the wildcard DNS record points to the same public IP address as the main domain name; the wildcard DNS record is a type of DNS record that makes all subdomains under the registered main domain name point to the same IP address, i.e., the public IP address;

[0109] S123: Verify domain name resolution;

[0110] After configuration, use the nslookup or dig tool in the command line terminal to verify that each main domain name and subdomain points to a public IP address;

[0111] S13: Configure wildcard domain certificate;

[0112] Apply for and distribute wildcard domain certificates;

[0113] Use automated tools such as Certbot to apply for wildcard domain certificates. After successfully obtaining the wildcard domain certificate, distribute the wildcard domain certificate to all gateway nodes that need to use it, ensuring that the wildcard domain certificate is consistent across all gateway nodes, so that the gateway can handle HTTPS requests.

[0114] At the same time, automated tools are used to manage wildcard domain certificates to ensure timely updates and security.

[0115] By registering the domain name, configuring the A record, and setting up wildcard DNS resolution, we can finally apply for and configure a wildcard SSL certificate, enabling all subdomains to be securely accessed via HTTPS.

[0116] S2: Deploy a P2P system;

[0117] Includes the following sub-steps:

[0118] S21: Deploy the core components of the P2P server;

[0119] The core components of the P2P server include a P2P management server, a signaling server, and a user authentication management system.

[0120] The P2P management server is used to manage the entire P2P network, including functions such as node registration, connection, and routing; the signaling server is used for signal transmission between nodes; the user authentication management system is used to verify the identity of each node, ensuring that only authenticated nodes can join the P2P network.

[0121] Generate and configure the registration KEY required for P2P node registration. The registration KEY consists of a key pair, which contains a public key and a private key. The private key is kept by the node, and the public key is shared by other nodes.

[0122] Generate key pairs using OpenSSL, GPG, or other encryption tools, configure the generated registration KEY in the P2P management system, and verify the nodes to be added to the P2P network;

[0123] S22: Deploy P2P client nodes;

[0124] On the gateway node, the node is registered and verified using a Docker container and a registration key provided by the P2P server, and the P2P client is deployed.

[0125] In a Kubernetes cluster, multiple P2P client instances are deployed using the StatefulSet controller and the registration key provided by the P2P server.

[0126] S3: Configure routing and forwarding rules for the P2P nodes of the K8S cluster via the P2P server;

[0127] Log in to the P2P server management interface and create routing rules;

[0128] The routing rule includes the target network, next hop, priority, and description. Specifically, in the target network, the IP range of the Pods in the K8S cluster is entered, the P2P node in the K8S cluster is selected as the next hop, the priority of the routing rule is set, and the description information for this routing rule is added.

[0129] After creation, the routing rules are saved to the P2P server. The P2P server then distributes these routing rules to all relevant P2P nodes, enabling the P2P nodes to perform routing forwarding according to these rules.

[0130] The P2P nodes within the K8S cluster periodically synchronize routing rules from the P2P server. When a P2P node receives a new routing rule, it updates its routing table according to the rule.

[0131] On the gateway node, attempt to access the IP addresses of Pods and Services within the Kubernetes cluster. If the routing rules are configured correctly, the gateway node will successfully access the Pods and Services within the Kubernetes cluster, enabling direct communication.

[0132] S4: Real-time monitoring of resource changes in the Kubernetes cluster;

[0133] Includes the following sub-steps:

[0134] S41: Monitoring service resource changes;

[0135] The Service Controller component, deployed in the Kubernetes cluster, monitors changes to service resources in the Kubernetes cluster in real time.

[0136] S42: Initiate the automatic configuration process and collect metadata information;

[0137] When a service is detected to be created, updated, or deleted, the Service Controller component initiates an auto-configuration process and collects the service's metadata information.

[0138] The automatic configuration process includes the automated configuration of network settings, logs, monitoring, authorization, and other aspects of this service;

[0139] The metadata information includes the service's port, protocol, selector, path, load balancing configuration, etc.

[0140] S5: Configure the gateway;

[0141] Includes the following sub-steps:

[0142] S51: Generate gateway routing rules based on service information;

[0143] Based on the service's metadata information, the gateway generates gateway routing rules according to the new service's port, protocol, and path.

[0144] Configure path mapping for the service according to its specific requirements, and configure the corresponding security policies accordingly;

[0145] S52: Automated certificate management and HTTPS configuration;

[0146] Generate SSL / TLS certificates for the service by integrating a certificate management tool or a certificate management tool in Kubernetes; and configure HTTPS routing for the service to achieve encrypted request transmission;

[0147] S53: Implement the load balancing strategy for requests;

[0148] The gateway configures load balancing policies for services, including round-robin, least connections, weighted load balancing, health checks, and failover.

[0149] Enable public network access for Kubernetes cluster services.

[0150] This invention constructs a full-link security protection system from client to server; by implementing transmission encryption and supporting complete certificate chain verification, it prevents data from being eavesdropped or tampered with during transmission; based on P2P technology, it implements point-to-point encrypted communication and uses asymmetric encryption for node identity authentication, ensuring secure data transmission in the virtual network; all encryption certificates are automatically applied for, distributed, and rotated by a unified certificate management center, reducing the operational costs of certificate management; at the access control level, a unified gateway and P2P network policy control center are constructed; all access policies can be updated and distributed to various execution layers in real time, including gateways and P2P nodes.

[0151] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for enabling public network access to Kubernetes cluster services via a P2P network and gateway, characterized in that: Based on Service Controller components, gateway system, P2P virtual network and DNS system; Includes the following steps: S1: Deploy the gateway system, configure domain names and wildcard domain certificates; Includes the following sub-steps: S11: Deploy the gateway system; Before deploying the gateway system, assess and prepare the basic environment, including hardware resource assessment, operating system configuration, and database preparation; After the evaluation was completed, the API gateway was deployed using an architecture that separated the control plane and the data plane. S12: Configure the domain name; Choose a suitable domain registrar based on your actual needs and register a main domain that meets your business or personal requirements. Configure A records and wildcard DNS records. After configuration, verify domain name resolution. S13: Configure wildcard domain certificate; Apply for and distribute wildcard domain certificates; The application for wildcard domain certificates is carried out using an automated tool called Certbot. After successfully obtaining the wildcard domain certificate, it is distributed to all gateway nodes that need to use it, ensuring that the wildcard domain certificate is consistent across all gateway nodes, so that the gateway can handle HTTPS requests. Simultaneously, use automated tools to manage wildcard domain certificates; S2: Deploy a P2P system; Includes the following sub-steps: S21: Deploy the core components of the P2P server; The core components of the P2P server include a P2P management server, a signaling server, and a user authentication management system. The P2P management server is used to manage the entire P2P network, including node registration, connection, and routing functions; the signaling server is used for signal transmission between nodes; the user authentication management system is used to verify the identity of each node, ensuring that only authenticated nodes can join the P2P network. Generate and configure the registration KEY required for P2P node registration. The registration KEY consists of a key pair, which contains a public key and a private key. The private key is kept by the node, and the public key is shared by other nodes. Generate key pairs using OpenSSL, GPG, or other encryption tools, configure the generated registration KEY in the P2P management system, and verify the nodes to be added to the P2P network; S22: Deploy P2P client nodes; On the gateway node, the node is registered and verified using a Docker container and a registration key provided by the P2P server, and the P2P client is deployed. In a Kubernetes cluster, multiple P2P client instances are deployed using the StatefulSet controller and the registration key provided by the P2P server. S3: Configure routing and forwarding rules for the P2P nodes of the K8S cluster via the P2P server; Log in to the P2P server management interface and create routing rules; After creation, configure routing and forwarding rules for the K8S cluster P2P nodes through the P2P server; S4: Real-time monitoring of resource changes in the Kubernetes cluster; Includes the following sub-steps: S41: Monitoring service resource changes; S42: Initiate the automatic configuration process and collect metadata information; S5: Configure the gateway; Includes the following sub-steps: S51: Generate gateway routing rules based on service information; S52: Automated certificate management and HTTPS configuration; S53: Implement load balancing strategies for requests.

2. The method for enabling public network access to Kubernetes cluster services via a P2P network and gateway as described in claim 1, characterized in that: Step S12 includes the following sub-steps: S121: Register the main domain name; Choose a suitable domain registrar based on your actual needs and register a main domain that meets your business or personal requirements. S122: Configure A records and wildcard DNS records; Log in to the control panel of the selected domain registrar, and in the DNS management or domain name resolution settings of the domain management interface, add a new A record to point the registered main domain name to the public IP address of the gateway; The A record is a DNS record type used to map a domain name to a corresponding IPv4 address; the main domain name is the registered main domain name, which is an A record and has the value of the gateway's public IP address. Add a wildcard domain name resolution record in the DNS management section of the domain name management interface, configure the wildcard domain name resolution A record, and make the wildcard domain name resolution A record point to the same public IP address as the main domain name; The wildcard DNS record is a type of DNS record that makes all subdomains under the registered main domain point to the same IP address, i.e., a public IP address. S123: Verify domain name resolution; After configuration, use the nslookup or dig tool in the command line terminal to verify that each main domain name and subdomain points to a public IP address.

3. The method for enabling public network access to Kubernetes cluster services via a P2P network and gateway as described in claim 1, characterized in that: The specific details of step S3 are as follows: Log in to the P2P server management interface and create routing rules; The routing rule includes the target network, next hop, priority, and description. Specifically, in the target network, the IP range of the Pods in the K8S cluster is entered, the P2P node in the K8S cluster is selected as the next hop, the priority of the routing rule is set, and the description information for this routing rule is added. After creation, the routing rules are saved to the P2P server. The P2P server then distributes these routing rules to all relevant P2P nodes, enabling the P2P nodes to perform routing forwarding according to these rules. The P2P nodes within the K8S cluster periodically synchronize routing rules from the P2P server. When a P2P node receives a new routing rule, it updates its routing table according to the rule. On the gateway node, attempt to access the IP addresses of Pods and Services within the Kubernetes cluster. If the routing rules are configured correctly, the gateway node will successfully access the Pods and Services within the Kubernetes cluster, enabling direct communication.

4. The method for enabling public network access to Kubernetes cluster services via a P2P network and gateway as described in claim 1, characterized in that: The specific details of step S4 are as follows: S41: Monitoring service resource changes; The Service Controller component, deployed in the Kubernetes cluster, monitors changes to service resources in the Kubernetes cluster in real time. S42: Initiate the automatic configuration process and collect metadata information; When a service is detected to be created, updated, or deleted, the Service Controller component initiates an auto-configuration process and collects the service's metadata information. The automatic configuration process includes the automated configuration of network settings, logs, monitoring, and authorization for this service.

5. The method for enabling public network access to Kubernetes cluster services via a P2P network and gateway as described in claim 1, characterized in that: The specific details of step S5 are as follows: S51: Generate gateway routing rules based on service information; Based on the service's metadata information, the gateway generates gateway routing rules according to the new service's port, protocol, and path. Configure path mapping for the service according to its specific requirements, and configure the corresponding security policies accordingly; S52: Automated certificate management and HTTPS configuration; Generate SSL / TLS certificates for services by integrating certificate management tools or certificate management tools in Kubernetes; Configure HTTPS routing for the service to enable encrypted request transmission; S53: Implement the load balancing strategy for requests; The gateway configures load balancing policies for services to enable public network access to Kubernetes cluster services; Enable public network access for Kubernetes cluster services.

Images