A service resource access method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a service resource access method and device, electronic equipment and storage medium, when a user creates a service access request is detected through a VIP controller, the configuration information of the service access request is obtained; when it is determined through the VIP controller that the destination label is contained in the configuration information, the service access request is intercepted based on the destination label; the available virtual IP for the VIP controller is obtained; the service resource corresponding to the service access request is determined, and the available virtual IP is distributed to the service resource; the service resource is accessed based on the available virtual IP through the VIP controller, the concept of the VIP controller is introduced, and the access control based on the label is introduced, the port exposed to the outside by the service is decoupled from the port in the Kubernetes. Each service corresponds to a unique VIP controller, avoiding the problem of port conflict, at the same time, the internal service is exposed as a unified external access address, hiding the specific information of the backend service, increasing the difficulty for attackers to find the target, and improving the security.

Description

Technical Field

[0001] This invention relates to the field of service resource access technology, and in particular to a service resource access method, a service resource access device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Kubernetes (K8s), as a powerful container orchestration platform, is widely used for managing and scheduling containerized applications. K8s simplifies the deployment and management of containerized applications through declarative configuration and automation. However, in practical applications, the way K8s exposes its NodePort services has some limitations.

[0003] NodePort is a mechanism for exposing services to external nodes within a cluster. Each NodePort service occupies a unique node port, while the range of Kubernetes node ports is limited. When multiple services need to be exposed, the limited port resources may lead to port conflicts, causing inconvenience for operation and maintenance. Furthermore, NodePort directly exposes services to the node, increasing the risk of service attacks and reducing service security. Summary of the Invention

[0004] The present invention provides a service resource access method, apparatus, electronic device, and computer-readable storage medium to overcome or at least partially solve the above-mentioned problems.

[0005] This invention discloses a service resource access method, which is applied to a Kubernetes cluster. The Kubernetes cluster is equipped with a VIP controller and includes:

[0006] When a user creates a service access request, the configuration information of the service access request is obtained through the VIP controller;

[0007] When the VIP controller determines that the configuration information contains a destination tag, the service access request is intercepted based on the destination tag.

[0008] Obtain an available virtual IP address for the VIP controller;

[0009] Identify the service resource corresponding to the service access request, and distribute the available virtual IP to the service resource;

[0010] The VIP controller accesses the service resources based on the available virtual IP.

[0011] This invention also discloses a service resource access device, which is applied to a Kubernetes cluster. The Kubernetes cluster is equipped with a VIP controller and includes:

[0012] The configuration information acquisition module is used to acquire the configuration information of the service access request when the VIP controller detects that a user has created a service access request.

[0013] The service access request interception module is used to intercept the service access request based on the destination tag when the VIP controller determines that the configuration information contains a destination tag.

[0014] A virtual IP acquisition module is used to acquire available virtual IPs for the VIP controller;

[0015] A virtual IP distribution module is used to determine the service resource corresponding to the service access request and distribute the available virtual IP to the service resource;

[0016] The service resource access module is used to access the service resources based on the available virtual IP through the VIP controller.

[0017] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0018] The memory is used to store computer programs;

[0019] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0020] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0021] The embodiments of the present invention have the following advantages:

[0022] This invention, in its embodiments, involves obtaining configuration information for a service access request when detected by the VIP controller; intercepting the service access request based on a destination tag when the VIP controller determines that the configuration information contains such a tag; obtaining an available virtual IP address for the VIP controller; identifying the service resource corresponding to the service access request and distributing the available virtual IP address to the service resource; and allowing the VIP controller to access the service resource based on the available virtual IP address. This introduces the concept of a VIP controller and tag-based access control, decoupling the externally exposed ports of the service from the internal ports of Kubernetes. Each service corresponds to a unique VIP controller, avoiding port conflicts. Simultaneously, exposing internal services to a unified external access address hides the specific information of the backend services, increasing the difficulty for attackers to discover the target and improving security. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a service resource access method provided by related technologies;

[0024] Figure 2 This is a flowchart illustrating another method for accessing service resources provided by related technologies;

[0025] Figure 3 This is a flowchart of the steps of a service resource access method provided in an embodiment of the present invention;

[0026] Figure 4 This is a flowchart illustrating a service resource access method provided in an embodiment of the present invention;

[0027] Figure 5 This is a schematic diagram of the execution flow of a VIP controller provided in an embodiment of the present invention;

[0028] Figure 6 This is a schematic diagram of the execution flow of a scanning operation provided in an embodiment of the present invention;

[0029] Figure 7 This is a schematic diagram of a service deletion process provided in an embodiment of the present invention using a VIP controller;

[0030] Figure 8 This is a schematic diagram of another service resource execution status monitoring process provided in this embodiment of the invention;

[0031] Figure 9 This is a structural block diagram of a service resource access device provided in an embodiment of the present invention;

[0032] Figure 10This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention;

[0033] Figure 11 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0034] Kubernetes (K8s) is a powerful container orchestration platform whose core concepts include APIServer, Service, CRD, and etcd. K8s is a portable, scalable, open-source platform for managing containerized workloads and services, which promotes declarative configuration and automation.

[0035] Kubernetes boasts a large and rapidly growing ecosystem, with a wide range of services, support, and tools available.

[0036] There are many concepts related to Kubernetes. The concepts relevant to this invention mainly include APIServer, Service, CRD, etcd, etc. In order to enable those skilled in the art to better understand the embodiments of this invention, some technical terms are explained below.

[0037] ApiServer: ApiServer is the external data window of the entire Kubernetes system, providing HTTP REST interfaces for adding, deleting, modifying, and querying various Kubernetes resource objects, as well as functions such as resource quota checking and authentication.

[0038] Service: A component of Kubernetes, it's an abstraction that helps you expose collections of Pods on the network. Each Service object defines a logical set of endpoints (typically Pods) and the strategies for accessing these Pods.

[0039] CRD stands for CustomResourceDefinitions, which is an extension of the Kubernetes API. When the default API objects provided by Kubernetes cannot meet the user's needs, the user can use CRD to create a custom API object. At the same time, the user needs to write a controller component to handle the corresponding CRD.

[0040] Etcd is a distributed key-value store designed to reliably and quickly store and access critical data. It achieves reliable distributed collaboration through distributed locks, leader election, and write barriers. Etcd clusters are designed for highly available, persistent data storage and retrieval.

[0041] The Ingress Controller is a crucial component in a Kubernetes (K8s) cluster, responsible for routing external HTTP(S) traffic to services within the cluster. Simply put, the Ingress Controller acts as a reverse proxy, forwarding requests to the appropriate Service based on the rules defined in the Ingress resource.

[0042] In a private environment, services in Kubernetes are typically exposed in the following ways:

[0043] 1) Internal access within the clusterIP cluster is not available to the outside of the cluster;

[0044] 2) NodePort;

[0045] 3) Deploy the reverse proxy Ingress controller;

[0046] 4) Loadbalance is not supported in private environments; it requires payment in public cloud environments.

[0047] refer to Figure 1 , Figure 1 This is a flowchart illustrating a service resource access method provided by related technologies. Taking the normal creation of a nodeport access service as an example: When the Kubernetes cluster receives the creation request, after passing through the api-server and service-controller, a port will be created on each cluster node. Any traffic sent to this port will be forwarded to the corresponding application service.

[0048] However, in practical applications, a user often creates multiple services. This means that a user needs to specify a port for each service created, while the Kubernetes nodePort port range is limited to 30000-32767. Using this approach in a production environment not only hinders operation and maintenance management but also easily exposes the specific location of the service, leading to security risks.

[0049] refer to Figure 2 , Figure 2 This is a flowchart illustrating another service resource access method provided by related technologies; another method exposes services externally through an ingress controller: when the Kubernetes cluster receives a service creation request, it uses an independent ingress object to define request forwarding rules, routing the request to one or more services. This decouples services from request rules, allowing for a unified consideration of business exposure from a business perspective, rather than considering it separately for each service.

[0050] However, in practical applications, the ingress controller is not a standard Kubernetes component, making deployment somewhat complex, and the numerous versions make upgrades cumbersome. While ingress offers good support for HTTPS HTTP protocols, it is not friendly to TCP connections, requiring domain name resolution configuration during access, which involves numerous and complex configuration steps.

[0051] Reference Figure 3 The diagram illustrates a flowchart of a service resource access method provided in an embodiment of the present invention, which may specifically include the following steps:

[0052] Step 301: When a user creates a service access request, the configuration information of the service access request is obtained through the VIP controller;

[0053] Step 302: When the VIP controller determines that the configuration information contains a destination tag, the service access request is intercepted based on the destination tag;

[0054] Step 303: Obtain an available virtual IP address for the VIP controller;

[0055] Step 304: Determine the service resource corresponding to the service access request, and distribute the available virtual IP to the service resource;

[0056] Step 305: Access the service resources through the VIP controller based on the available virtual IP.

[0057] A VIP controller is a controller that manages virtual IPs in a Kubernetes cluster. Its main function is to assign unique virtual IP addresses to Kubernetes services and maintain the mapping relationship between these IP addresses and backend services.

[0058] How the VIP controller works:

[0059] VIP allocation: When a new Service is created and it is marked as requiring the use of a VIP, the VIP controller will allocate an unused VIP to the Service from a predefined IP pool.

[0060] Create a virtual network interface: Create a virtual network interface on the node and bind the assigned VIP to that interface.

[0061] Update Service configuration: Update the Service configuration and add the assigned VIP to the Service spec.

[0062] Maintain the mapping between VIPs and Services: Continuously monitor the status of Services and dynamically adjust the binding relationship of VIPs when Services change (such as creation, deletion, or update).

[0063] Interacting with etcd: VIP controllers typically use etcd to store the mapping between VIPs and services, as well as the available IP pool.

[0064] The function of the VIP controller:

[0065] Simplified service exposure: Users do not need to worry about the underlying network configuration; they can simply create a Service and add a tag to expose the service to the outside of the cluster.

[0066] Improve service availability: High availability can be achieved through virtual IPs, allowing for quick switching to other instances when backend services fail.

[0067] Enhanced service manageability: The VIP controller provides a centralized way to manage service exposures, making it easier for operations and maintenance personnel to manage and monitor them.

[0068] The VIP controller is an important component in the Kubernetes ecosystem. It simplifies service exposure and management by assigning virtual IPs to services. The VIP controller works in conjunction with components such as Service and etcd to achieve load balancing and high availability of services in a Kubernetes cluster.

[0069] The embodiments of the present invention can be applied to Kubernetes clusters, wherein the Kubernetes clusters are equipped with VIP controllers.

[0070] In a specific implementation, when the VIP controller detects a user creating a service access request, it can obtain the configuration information of the service access request to understand the detailed information of the user request, including the target service, access method, etc., thereby providing a basis for subsequent interception and distribution decisions.

[0071] For example, a user can create a service request using the following code, add an internal network load balancing tag to the service, and send it to the k8s api-server.

[0072]

[0073]

[0074] This YAML code defines a Kubernetes Service resource to describe a service named test-service.

[0075] kind: Service: Specifies that the type of this resource is Service, which is a service in Kubernetes.

[0076] apiVersion: v1: Specifies the API version; here, version v1 is used.

[0077] metadata:

[0078] name: The name of the service, which is test-service.

[0079] namespace: The namespace where the service resides; the default value is "default".

[0080] labels:

[0081] innerloadBalance: true: This tag is custom and is used to identify that the service needs to perform private load balancing, which is the target tag in this embodiment of the invention.

[0082] spec:

[0083] type: ClusterIP: Specifies that the Service type is ClusterIP, meaning that the service is only accessible within the cluster and will not be exposed to the outside of the cluster.

[0084] selector:

[0085] app:test-service: Matches Pods with the tag app:test-service, meaning that the Service will proxy traffic to Pods that match this tag.

[0086] ports:

[0087] port: 80: The port of the Service, the port used when accessing the Service from outside.

[0088] targetPort: 80: The port of the Pod, i.e. the port of the Pod to which traffic is ultimately forwarded.

[0089] The creation of this Service resource actually involves the user sending a request to the Kubernetes cluster, informing the cluster:

[0090] Create a new service named test-service to distribute traffic to a group of Pods.

[0091] Specify service type: This service is only accessible within the cluster.

[0092] Special handling is indicated by the innerloadBalance:true tag, which tells the system that this service requires special private load balancing.

[0093] Relationship with the overall plan:

[0094] This step is the starting point of the entire private load balancing solution. When the Kubernetes API Server receives this request, it forwards it to the VIP controller according to configured rules (such as webhooks). The VIP controller recognizes that this Service has the `innerloadBalance: true` tag, thus triggering a series of subsequent operations, including:

[0095] Get available IPs from etcd.

[0096] Create a Service of type LoadBalancer.

[0097] Create a virtual network interface card on the node.

[0098] Update the IP pool in etcd.

[0099] By creating a Service with a special tag, a signal is sent to the system indicating the need for private load balancing. This signal triggers a series of subsequent automated operations, ultimately enabling private access to the service.

[0100] As can be seen from the above, when a user creates a service access request, they can set the destination tag innerloadBalance in the configuration information. Therefore, the VIP controller can first determine whether the configuration information contains the destination tag in order to determine whether to perform subsequent load balancing operations.

[0101] In this embodiment of the invention, when the VIP controller determines that the configuration information contains a destination tag, it can intercept the service access request based on the destination tag; thereby filtering the request according to the destination tag in the configuration information, so as to realize access control for different users or applications based on the tag, traffic diversion based on the tag, traffic management, and isolation of different types of services, thereby improving system stability.

[0102] By obtaining the available virtual IP for the VIP controller, an available VIP controller is selected for the current request. The request is then distributed to different backend services through round-robin or other algorithms to improve system availability. When a backend service becomes unavailable, the request can be forwarded to other available backend services.

[0103] By identifying the service resource corresponding to the service access request and distributing the available virtual IP to the service resource, the service resource corresponding to the current request is found, and the VIP controller is assigned to the service, thereby accurately routing the request to the corresponding service. Through the VIP controller, the client can easily discover the service.

[0104] The VIP controller accesses the service resources based on the available virtual IP, and accesses the backend services through the VIP. This allows clients to access the backend services without needing to know the specific address of the backend services, reducing the complexity of client configuration.

[0105] For example, the VIP controller is mainly used to implement the following process.

[0106] 1. Check service configuration:

[0107] After receiving a Service creation request, the VIP controller will first check the configuration information of the Service.

[0108] The key checkpoint should have the `innerloadBalance: true` tag. If it does, it means that the Service needs to perform private load balancing.

[0109] 2. Determine the Service type:

[0110] If the Service is configured with the innerloadBalance: true tag, proceed to the next step.

[0111] If this tag is not present, it means that private load balancing is not required, and the system will return directly without further processing.

[0112] 3. VIP allocation:

[0113] Obtain an available IP address from etcd and use it as the VIP of this Service.

[0114] etcd stores the IP and MAC address information of all nodes in the local area network. The VIP controller selects an unused IP from these IPs as the VIP.

[0115] 4. Create a Service:

[0116] Create a new Service in the Kubernetes cluster.

[0117] The assigned VIP is bound to this Service, so that when external access to this VIP is made, the traffic will be forwarded to the corresponding Pod.

[0118] Set the Service type to LoadBalancer to support load balancing.

[0119] Alternatively, the VIP controller can also be used for:

[0120] 5. Create a virtual network adapter:

[0121] Create a virtual network interface card on the current node.

[0122] Bind the assigned VIP controller to this virtual network adapter.

[0123] The network can be configured by interacting with the kernel through the netlink package.

[0124] 6. Update etcd:

[0125] Update the assigned VIP and its corresponding MAC address information to etcd.

[0126] In this way, the IP pool in etcd remains up-to-date.

[0127] In practical applications, due to the limited node port resources used by the NodePort service exposure method, port conflicts are prone to occur when there are a large number of services, affecting the normal exposure of services. At the same time, NodePort directly exposes services to nodes, increasing the risk of service attacks and reducing service security.

[0128] This invention, through the following embodiments, introduces the concept of a VIP controller and tag-based access control: when a user creates a service access request, the VIP controller obtains the configuration information of the service access request; when the VIP controller determines that the configuration information contains a destination tag, the service access request is intercepted based on the destination tag; an available virtual IP for the VIP controller is obtained; the service resource corresponding to the service access request is determined, and the available virtual IP is distributed to the service resource; the VIP controller accesses the service resource based on the available virtual IP. This brings the following beneficial effects:

[0129] By introducing a VIP controller, the ports exposed by a service to the outside world are decoupled from the ports inside Kubernetes. Each service corresponds to a unique VIP controller, avoiding port conflict issues.

[0130] The VIP controller dynamically allocates VIPs from the available VIP pool, ensuring that each service has a unique external access address.

[0131] By intercepting service access requests based on destination tags, fine-grained access control can be achieved to prevent unauthorized access.

[0132] VIP exposes internal services as a unified external access address, hiding the specific information of the backend services and increasing the difficulty for attackers to discover the target.

[0133] Simplify service exposure: Users only need to care about Service creation and label configuration, without needing to worry about the underlying network configuration and port allocation.

[0134] Improve service availability: VIP enables load balancing and failover, thereby improving service availability.

[0135] Enhanced service manageability: The VIP controller provides a centralized way to manage service exposures, making it easier for operations and maintenance personnel to manage and monitor them.

[0136] Enhanced system security: By using tags to filter and hide internal services, the system's security has been improved.

[0137] Flexible expansion: Supports dynamic VIP allocation and updates to adapt to ever-changing service needs.

[0138] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0139] Optionally, the Kubernetes cluster is equipped with a distributed key-value store system, etcd, and the step of obtaining an available virtual IP for the VIP controller includes:

[0140] Obtain an available virtual IP address for the VIP controller from the IP address pool of the distributed key-value storage system etcd.

[0141] In a Kubernetes cluster, etcd is introduced as a distributed key-value store system, and an IP address pool is maintained within it to allocate available virtual IPs to the VIP controller. The main purpose is:

[0142] Centralized management of IP addresses: All available virtual IPs are centrally stored in etcd for convenient unified management and allocation.

[0143] Ensuring IP address uniqueness: etcd's strong consistency ensures that each VIP controller is assigned a unique IP address, avoiding IP conflicts.

[0144] Improve system scalability: When the cluster size increases, the available IP pool can be increased by adding new IP addresses to etcd, thus achieving elastic scaling of the system.

[0145] Facilitates fault recovery: When a node or VIP controller fails, a new IP address can be quickly obtained from etcd for fault recovery.

[0146] Beneficial effects include:

[0147] Improved system availability: Due to the distributed nature of etcd, even if some etcd nodes fail, IP address allocation can still be guaranteed, thus improving system availability.

[0148] Enhance system flexibility: The size of the IP address pool can be dynamically adjusted as needed to meet ever-changing business requirements.

[0149] Simplified system management: Centralizing IP address management in etcd simplifies the work of system administrators.

[0150] Enhance system security: Through etcd's access control mechanism, permission control can be exercised over the allocation of IP addresses, thereby improving system security.

[0151] Optionally, the Kubernetes cluster is configured with an application programming interface (api-server) for the service access request. The step of determining the service resource corresponding to the service access request and distributing the available virtual IP to the service resource includes:

[0152] The API-server is invoked to receive the available virtual IP address;

[0153] The service resource is created based on the virtual IP.

[0154] Configure the available virtual IP to the service resource.

[0155] For example, the process of determining service resources and distributing available virtual IPs can be as follows:

[0156] 1. The API Server receives a Service creation request:

[0157] Users or systems can send requests to the API Server to create a Service using tools such as kubectl.

[0158] The request includes information such as the name, port, selector, and type of the Service (usually LoadBalancer).

[0159] 2. The API Server queries etcd to obtain available IPs:

[0160] The API Server will query the predefined IP address pool in etcd.

[0161] An IP address pool is a key-value pair, where the key is usually a fixed string and the value is a list of IP addresses.

[0162] The API Server retrieves an unused IP address from the list.

[0163] 3. API Server creates a Service:

[0164] The API Server creates a Service resource based on the obtained IP address and other information provided by the user.

[0165] Setting the Service type to LoadBalancer indicates that the Service needs to be exposed outside the cluster, meaning that the service resource is of a type that supports load balancing.

[0166] The assigned IP address will be used as the external access IP for the Service.

[0167] The created Service is stored in etcd.

[0168] 4. The cloud platform or load balancer receives the Service creation notification:

[0169] Cloud platforms or load balancers monitor changes to services in etcd.

[0170] When a new LoadBalancer type Service is detected to be created, a load balancer instance will be automatically created for that Service.

[0171] Configure the load balancer to listen on the IP and port assigned to the Service and forward traffic to the backend Pod.

[0172] 5. The VIP Controller listens to the Service status:

[0173] The VIP Controller continuously monitors the state changes of the Service in etcd.

[0174] When the state of the Service changes (for example, from Pending to Running), the VIP Controller will handle it accordingly.

[0175] If the Service's status becomes failed, the VIP Controller may attempt to recreate the Service or perform fault recovery.

[0176] The above method of determining service resources and distributing available virtual IPs can achieve the following beneficial effects:

[0177] Automation: Most operations are completed automatically by the system, reducing human intervention.

[0178] Flexible: The configuration of the IP address pool and load balancer can be dynamically adjusted as needed.

[0179] Reliability: etcd ensures data consistency, thus improving system reliability.

[0180] Scalability: The IP address pool can be easily expanded to meet ever-growing service demands.

[0181] Optionally, it also includes:

[0182] The VIP controller monitors the execution status of the service resources.

[0183] Based on the execution status, service resource update information is generated;

[0184] The service resource update information is sent to the application programming interface.

[0185] In a specific implementation, the VIP Controller of this embodiment can continuously monitor changes in the execution status of Service resources in etcd. For example, changes can include three states: creation, deletion, and update. When the Service's status changes (e.g., from Pending to Running), the VIP Controller will perform corresponding processing. If the Service's status becomes Failure, the VIP Controller may attempt to recreate the Service or perform fault recovery. When the execution status is updated, service resource update information can be generated based on the updated content, and the service resource update information and the updated Service resource can be sent to the application programming interface (API) to submit to the api-server.

[0186] Optionally, the VIP controller includes a VIP scanning controller, and further includes:

[0187] The VIP scanning controller generates an address dynamic mapping protocol to obtain requests.

[0188] Broadcast a request for Dynamic Address Mapping Protocol (DAP) to the local area network of the Kubernetes cluster to receive DAP responses from devices within the local area network; the DAP responses include device IP addresses and device MAC addresses.

[0189] The device IP address and device MAC address are written into the distributed key-value storage system etcd.

[0190] For example, the scanning process can be performed as follows.

[0191] 1. Start scanning:

[0192] The VIP scanning controller starts the scanning process according to preset timed tasks or trigger conditions.

[0193] 2. Send an ARP request:

[0194] The scanning controller broadcasts ARP requests to the local area network (LAN) to obtain the IP address and MAC address mappings of all devices within the LAN.

[0195] 3. The ARP protocol is a network protocol used in local area networks to achieve dynamic mapping between IP addresses and physical addresses (MAC addresses).

[0196] 4. Receive ARP response:

[0197] The scanning controller receives ARP responses from devices within the local area network.

[0198] The response contains the device's IP address and MAC address.

[0199] 5. Update etcd:

[0200] The received IP address and MAC address information is written to etcd.

[0201] etcd is a distributed key-value store system used to store and manage critical data. Storing IP and MAC address information in etcd allows the VIP controller to query it when assigning VIPs.

[0202] In this embodiment of the invention, an address dynamic mapping protocol acquisition request is generated through the VIP scanning controller; the request is broadcast to the local area network of the Kubernetes cluster to receive address dynamic mapping protocol responses from devices within the local area network; the address dynamic mapping protocol response includes the device IP address and the device MAC address; the device IP address and the device MAC address are written into the distributed key-value storage system etcd, achieving the following beneficial effects:

[0203] Ensure VIP availability: Regularly scan to ensure that the VIPs assigned to the service are available within the local area network.

[0204] Provides accurate IP information: Provides a reliable data source for VIP allocation.

[0205] Supports dynamic IP environments: The IP pool can be updated promptly even if the IP addresses within the local area network change.

[0206] The scanning process is a crucial step in the entire private load balancing solution, providing the foundational data for VIP allocation. Regularly scanning the local area network ensures that the IP information in etcd is up-to-date, thereby guaranteeing the accuracy of VIP allocation. When allocating a VIP, available IP addresses are queried from etcd. Inaccurate IP information in etcd can lead to VIP allocation failure. The scanning process ensures the reliability of the entire solution, enabling the private load balancing system to operate stably.

[0207] To enable those skilled in the art to better understand the embodiments of the present invention, an example is used below to illustrate the embodiments of the present invention.

[0208] refer to Figure 4 , Figure 4 This is a flowchart illustrating a service resource access method provided in an embodiment of the present invention;

[0209] S1. The user creates a service request, adds an internal network load balancing tag to the service, and sends it to the k8s api-server.

[0210]

[0211]

[0212] refer to Figure 5 , Figure 5 This is a schematic diagram of the execution flow of a VIP controller provided in an embodiment of the present invention;

[0213] S2.VIP-controller performs validation and interception on the service.

[0214] If the tag innerLoadBalance: true is present, the system will first read the IP address pool in etcd, find an available IP, and return the result to the api-server to create the corresponding service. The service type will be defined as LoadBalance, and the service status will be monitored. If the tag is not present, no operation will be performed.

[0215] Besides creating and listening to services, the VIP-controller also has an important function of creating a virtual network interface card (NIC) on the node and binding it to the VIP. Network operations are mainly implemented through the netlink package. Netlink is a special type of inter-process communication (IPC) used to enable communication between user processes and kernel processes, and it is also the most commonly used interface for communication between network applications and the kernel.

[0216] refer to Figure 6 , Figure 6 This is a schematic diagram of the execution flow of a scanning operation provided in an embodiment of the present invention;

[0217] The main function of S3.VIP-Scanner-controller is to periodically scan the IP addresses of the local area network where the node resides and store the scan results (IP and MAC addresses) in etcd. etcd uses key-value data storage, and its query speed is generally better than that of relational databases. Its main principle is to use gopacket to send ARP packets to obtain the IP and MAC addresses of devices on the local area network.

[0218] S4. The VIP-controller performs load balancing on the service by changing the IP address to the VIP, allowing users to access the service through the VIP. The VIP-controller monitors the service's creation, deletion, and update states, and finally submits the service to the API server.

[0219] refer to Figure 7 and Figure 8 , Figure 7 This is a schematic diagram of a service deletion process provided in an embodiment of the present invention using a VIP controller; Figure 8 This is a schematic diagram of another service resource execution status monitoring process provided in this embodiment of the invention;

[0220] The creation process can be as follows Figure 5 As shown, this is based on step S2.

[0221] The deletion and update process can be based on Figure 7 and Figure 8The process is illustrated in the diagram.

[0222] For example, based on Figure 7 The VIP controller plays a crucial role in the Service lifecycle: listening for Service deletion events. When a Service is deleted, the VIP controller performs a series of operations to ensure the consistency of the system state.

[0223] Process Explanation:

[0224] Deleting a Service: When a user or the system decides to delete a Service, a deletion request is sent to the API Server.

[0225] API Server Request Processing: After receiving a deletion request, the API Server will broadcast this deletion event to the entire Kubernetes cluster.

[0226] VIP-controller detects deletion events: As a component in the cluster, VIP-controller continuously listens for events from the API Server. When it detects that a Service has been deleted, it triggers the subsequent processing flow.

[0227] Deleting a virtual network interface: Since there is a one-to-one correspondence between a Service and a virtual network interface, when a Service is deleted, the VIP-controller will find the corresponding virtual network interface and delete it.

[0228] Deleting a VIP: Similar to virtual network interfaces, VIPs are also one-to-one with services. Therefore, the VIP controller will delete the VIP associated with that service from the system.

[0229] Update etcd: The VIP-controller will update the data in etcd and remove the deleted Service and its corresponding VIP information from etcd.

[0230] The significance of VIP-controller monitoring Service deletion:

[0231] Resource recycling: By deleting the virtual network interfaces and VIPs associated with the Service, system resources are released, improving resource utilization.

[0232] State consistency: Ensure that the state of the system is consistent with the actual situation to avoid the emergence of "zombie" resources.

[0233] Preventing conflicts: Prevent subsequent requests from mistakenly hitting services that have been deleted, thus ensuring system stability.

[0234] Figure 8 This demonstrates a series of operations performed by the VIP controller during a Service update. Compared to the previous delete operation, the update operation involves more resource state changes.

[0235] Process Explanation:

[0236] Service Update: When a user or system modifies a Service, an update request is sent to the API Server.

[0237] API Server Request Processing: After receiving an update request, the API Server will broadcast this update event to the entire Kubernetes cluster.

[0238] VIP-controller detects update events: The VIP-controller continuously listens for events from the API Server. When it detects an update event for a certain Service, it triggers the subsequent processing flow.

[0239] Delete the existing VIP: To ensure consistency of state, the VIP-controller will first delete the VIP corresponding to the old Service configuration.

[0240] Delete existing network interfaces: Similar to VIPs, network interfaces corresponding to the old Service configuration will also be deleted.

[0241] Create a new VIP: Create a new VIP based on the updated Service configuration.

[0242] Create a new network interface and bind a VIP: Create a new network interface and bind the newly created VIP to this network interface.

[0243] Update the VIP of the Service: Update the VIP field in the Service's Spec to the newly created VIP.

[0244] Update etcd: Update the data in etcd to update the mapping between Services and VIPs to the latest state.

[0245] The significance of VIP-controller listening for Service updates:

[0246] State synchronization: Ensure that the states of VIP and Service are always consistent to avoid configuration mismatches.

[0247] Dynamic adjustment: It can dynamically adjust the VIP configuration based on changes in Service configuration to adapt to changes in business needs.

[0248] High availability: Service availability is ensured by timely VIP updates.

[0249] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0250] Reference Figure 9 The diagram illustrates a structural block diagram of a service resource access device provided in an embodiment of the present invention, which may specifically include the following modules:

[0251] The configuration information acquisition module 901 is used to acquire the configuration information of the service access request when the VIP controller detects that a user has created a service access request.

[0252] The service access request interception module 902 is used to intercept the service access request based on the destination tag when the configuration information is determined by the VIP controller.

[0253] Available virtual IP acquisition module 903 is used to acquire available virtual IPs for the VIP controller;

[0254] Available virtual IP distribution module 904 is used to determine the service resource corresponding to the service access request and distribute the available virtual IP to the service resource;

[0255] The service resource access module 905 is used to access the service resource through the VIP controller based on the available virtual IP.

[0256] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0257] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 10 As shown, it includes a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004, wherein the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004.

[0258] Memory 1003 is used to store computer programs;

[0259] When the processor 1001 executes the program stored in the memory 1003, it implements any of the service resource access methods described in the above embodiments:

[0260] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0261] The communication interface is used for communication between the aforementioned terminal and other devices.

[0262] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0263] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0264] like Figure 11 As shown, in another embodiment of the present invention, a computer-readable storage medium 1101 is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the service resource access method described in the above embodiments.

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

[0266] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0267] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0268] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0269] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0270] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0271] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for accessing service resources, characterized in that, The method is applied to a Kubernetes cluster, which has a VIP controller and includes: When a user creates a service access request, the configuration information of the service access request is obtained through the VIP controller; When the VIP controller determines that the configuration information contains a destination tag, the service access request is intercepted based on the destination tag. Obtain an available virtual IP address for the VIP controller; Identify the service resource corresponding to the service access request, and distribute the available virtual IP to the service resource; The VIP controller accesses the service resources based on the available virtual IP. The Kubernetes cluster is configured with an application programming interface for the service access request. The steps of determining the service resource corresponding to the service access request and distributing the available virtual IP to the service resource include: The available virtual IP is received by calling the application programming interface. The service resource is created based on the virtual IP; Configure the available virtual IP to the service resource; Create a virtual network interface card (NIC) and bind the VIP controller to the virtual NIC.

2. The method according to claim 1, characterized in that, The Kubernetes cluster is configured with a distributed key-value store system, etcd. The step of obtaining an available virtual IP for the VIP controller includes: Obtain an available virtual IP address for the VIP controller from the IP address pool of the distributed key-value storage system etcd.

3. The method according to claim 2, characterized in that, The VIP controller includes a VIP scanning controller, and also includes: The VIP scanning controller generates an address dynamic mapping protocol to obtain requests. Broadcast a request for Dynamic Address Mapping Protocol (DAP) to the local area network of the Kubernetes cluster to receive DAP responses from devices within the local area network; the DAP responses include device IP addresses and device MAC addresses. The device IP address and device MAC address are written into the distributed key-value storage system etcd.

4. The method according to claim 1, characterized in that, Also includes: The VIP controller monitors the execution status of the service resources. Based on the execution status, service resource update information is generated; The service resource update information is sent to the application programming interface.

5. The method according to claim 1, characterized in that, Also includes: Configure the service resources to support load balancing.

6. A service resource access device, characterized in that, The device is applied to a Kubernetes cluster, which is equipped with a VIP controller, including: The configuration information acquisition module is used to acquire the configuration information of the service access request when the VIP controller detects that a user has created a service access request. The service access request interception module is used to intercept the service access request based on the destination tag when the VIP controller determines that the configuration information contains a destination tag. A virtual IP acquisition module is used to acquire available virtual IPs for the VIP controller; A virtual IP distribution module is used to determine the service resource corresponding to the service access request and distribute the available virtual IP to the service resource; The service resource access module is used to access the service resources based on the available virtual IP through the VIP controller; The Kubernetes cluster is configured with an application programming interface for the service access request, and the available virtual IP distribution module is also used to call the application programming interface to receive the available virtual IP. The service resource is created based on the virtual IP; Configure the available virtual IP to the service resource; Create a virtual network interface card (NIC) and bind the VIP controller to the virtual NIC.

7. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-5.

8. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-5.

Images