Service resource access method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a service resource access method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining the configuration information of a service access request when a VIP controller detects that a user creates the service access request; when the VIP controller judges that the configuration information contains a target label, intercepting a service access request based on the target label; obtaining an available virtual IP for the VIP controller; determining a service resource corresponding to the service access request, and distributing an available virtual IP to the service resource; a VIP controller accesses service resources based on an available virtual IP, the concept of the VIP controller and access control based on a label are introduced, and a port exposed to the outside of the service is decoupled from a port in Kubernetes. According to the technical scheme, each service corresponds to a unique VIP controller, the problem of port conflict is avoided, meanwhile, the internal service is exposed as a unified external access address, specific information of the back-end service is hidden, the difficulty for an attacker to find a target is increased, and the safety is improved.

Description

Technical Field

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

[0002] As a powerful container orchestration platform, Kubernetes (K8s) is widely used to manage and schedule containerized applications. K8s simplifies the deployment and management of containerized applications through declarative configuration and automation. However, in actual applications, the NodePort service exposure method of K8s has some limitations.

[0003] NodePort is a mechanism for exposing services to nodes outside the cluster. Each NodePort service occupies a unique node port, and the range of K8s node ports is limited. When multiple services need to be exposed, limited port resources may cause port conflicts, which brings inconvenience to operation and maintenance management. In addition, NodePort directly exposes services to nodes, increasing the risk of service attacks and reducing service security. Summary of the invention

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

[0005] An embodiment of the present invention discloses a service resource access method, which is applied to a Kubernetes cluster, wherein the Kubernetes cluster is provided with a VIP controller, including:

[0006] When the VIP controller detects that a user creates a service access request, obtaining configuration information of the service access request;

[0007] When it is determined by the VIP controller that the configuration information includes a destination tag, intercepting the service access request based on the destination tag;

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

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

[0010] The service resource is accessed through the VIP controller based on the available virtual IP.

[0011] The embodiment of the present invention further discloses a service resource access device, which is applied to a Kubernetes cluster, and the Kubernetes cluster is provided with a VIP controller, including:

[0012] A configuration information acquisition module, used to acquire configuration information of a service access request when a user creates a service access request through the VIP controller;

[0013] A service access request interception module, configured to intercept the service access request based on the destination tag when it is determined by the VIP controller that the configuration information contains a destination tag;

[0014] An available virtual IP acquisition module, used to acquire an available virtual IP for the VIP controller;

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

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

[0017] The embodiment of the present invention further discloses an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

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

[0019] The processor is used to implement the method described in the embodiment of the present invention when executing the program stored in the memory.

[0020] The embodiment of the present invention further discloses a computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, enables the processors to execute the method described in the embodiment of the present invention.

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

[0022] The embodiment of the present invention, when the VIP controller detects that a user creates a service access request, obtains the configuration information of the service access request; when the VIP controller determines that the configuration information contains a destination tag, intercepts the service access request based on the destination tag; obtains an available virtual IP for the VIP controller; determines the service resource corresponding to the service access request, and distributes the available virtual IP to the service resource; accesses the service resource based on the available virtual IP through the VIP controller, introduces the concept of VIP controller and label-based access control, and decouples the port exposed to the outside of the service from the port inside Kubernetes. Each service corresponds to a unique VIP controller, which avoids the problem of port conflicts. 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 targets, and improving security. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] Figure 2 It is a flowchart of another service resource access method provided by the related technology;

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

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

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

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

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

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

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

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

[0033] Fig.11 is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0034] Kubernetes (K8s) is a powerful container orchestration platform. Its core concepts include ApiServer, Service, CRD, etcd, etc. K8s is a portable and scalable open source platform for managing containerized workloads and services, which can promote declarative configuration and automation.

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

[0036] There are many concepts related to kubernetes. The concepts related to the present invention mainly include ApiServer, Service, CRD, etcd, etc. In order to enable those skilled in the art to better understand the embodiments of the present 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 checking various kubernetes resource objects, as well as resource quota checking and authentication functions.

[0038] Service: is a component of Kubernetes. It is an abstraction that helps you expose a collection of Pods on the network. Each Service object defines a logical set of endpoints (usually these endpoints are Pods) and a strategy for how to access these Pods.

[0039] CRD: The full name is CustomResourceDefinitions, which is an extension of the Kubernetes API. When the default API objects provided by Kubernetes cannot meet the needs of users, users can use CRD to create custom API objects. At the same time, users need to write a controller component to process the corresponding CRD.

[0040] Etcd: is a distributed key-value pair storage designed to reliably and quickly save and provide access to critical data. Reliable distributed collaboration is achieved through distributed locks, leader elections, and write barriers. etcd clusters are prepared for high availability, persistent data storage and retrieval.

[0041] Ingress Controller is a very important component in the Kubernetes (K8s) cluster. It is responsible for routing external HTTP(S) traffic to services within the cluster. In simple terms, Ingress Controller is a reverse proxy that forwards requests to the corresponding Service according to the rules defined in the Ingress resource.

[0042] Services in K8s are usually exposed in a private environment as follows:

[0043] 1) clusterIP is only accessible within the cluster and cannot be accessed from outside the cluster;

[0044] 2)NodePort;

[0045] 3) Deploy reverse proxy Ingress controller;

[0046] 4) Loadbalance is not supported in private environments, and public cloud environments require a fee.

[0047] refer to Figure 1 , Figure 1 It is a flow chart of a service resource access method provided by related technologies; take the normal creation of a nodeport access service as an example: when the k8s cluster receives a creation request, it will create a port on each cluster node after passing through the api-server and the service-controller, and any traffic sent to the port will be forwarded to the corresponding application service.

[0048] However, in actual applications, a user often creates multiple services. This means that each time a user creates a service, they need to specify a port, and the k8s nodePort port range is limited to 30000-32767. Using this method in a production environment is not only not conducive to operation and maintenance management, but also often easily exposes the specific location of the service, leading to security risks.

[0049] refer to Figure 2 , Figure 2 This is a flowchart of another service resource access method provided by related technologies; another method is to expose services to the outside world through ingress controller: when the k8s cluster receives a service creation request, it uses an independent ingress object to formulate request forwarding rules and route the request to one or more services. In this way, the service and request rules are decoupled, and the exposure of the business can be considered uniformly from the business dimension, instead of considering each service separately.

[0050] However, in actual application, ingress controller is not a standard component of k8s, so it is relatively complex to deploy, and it is troublesome to upgrade due to the large number of versions. Although ingress supports HTTPS and HTTP protocols well, it is not friendly to TCP connections. During the access process, domain name resolution needs to be configured, which requires a lot of configuration and is relatively complex.

[0051] Reference Figure 3 , shows a flow chart of the steps 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 the VIP controller detects that a user creates a service access request, obtain configuration information of the service access request;

[0053] Step 302, when it is determined by the VIP controller that the configuration information includes a destination tag, intercepting the service access request based on the destination tag;

[0054] Step 303, obtaining an available virtual IP for the VIP controller;

[0055] Step 304, determining a service resource corresponding to the service access request, and distributing the available virtual IP to the service resource;

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

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

[0058] How VIP controller works:

[0059] Assigning VIP: When a new Service is created and the Service is marked as requiring the use of a VIP, the VIP controller assigns 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 the interface.

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

[0062] Maintain the mapping between VIP and Service: Continuously monitor the status of Service and dynamically adjust the VIP binding relationship when the Service changes (such as creation, deletion, update).

[0063] Interaction with etcd: VIP controllers usually use etcd to store the mapping between VIP and Service, as well as the available IP pool.

[0064] The role of VIP controller:

[0065] Simplify service exposure: Users do not need to worry about the underlying network configuration. They only need to create a Service and add labels to expose the service outside the cluster.

[0066] Improve service availability: Through the virtual IP, high availability can be achieved. When the backend service fails, it can quickly switch to other instances.

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

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

[0069] The embodiment of the present invention can be applied to a Kubernetes cluster, and the Kubernetes cluster is provided with a VIP controller.

[0070] In a specific implementation, when the VIP controller detects that a user has created a service access request, the embodiment of the present invention can obtain the configuration information of the service access request to understand the detailed information of the user's 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 through the following code, add an intranet load balancing label to the service, and send it to the k8s api-server.

[0072]

[0073]

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

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

[0076] apiVersion: v1: specifies the API version. The v1 version is used here.

[0077] metadata:

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

[0079] namespace: The namespace where the service is located. The default value is default.

[0080] labels:

[0081] innerloadBalance: true: This tag is customized and is used to indicate that the service needs to be privately loaded and balanced, which is the destination tag in the embodiment of the present invention.

[0082] spec:

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

[0084] selector:

[0085] app:test-service: matches Pods with the label app:test-service, that is, the Service will proxy traffic to Pods matching this label.

[0086] ports:

[0087] port: 80: Service port, the port used for external access to the Service.

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

[0089] The creation of this Service resource actually means that the user sends a request to the Kubernetes cluster, telling the cluster:

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

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

[0092] Mark special processing: Use the innerloadBalance: true tag to tell the system that this service requires special private load balancing processing.

[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 will forward the request to the VIP controller according to the configured rules (such as Webhook). The VIP controller will recognize that this Service has the innerloadBalance: true label, which triggers a series of subsequent operations, including:

[0095] Get available IP addresses from etcd.

[0096] Create a Service of type LoadBalancer.

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

[0098] Update the IP pool in etcd.

[0099] By creating a Service with a special label, a signal is sent to the system indicating that private load balancing is required. This signal will trigger a series of subsequent automated operations, ultimately achieving private access to the service.

[0100] As can be seen from the above, when creating a service access request, the user 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 to determine whether to perform subsequent load balancing operations.

[0101] According to an embodiment of the present invention, when the VIP controller determines that the configuration information contains a destination tag, the service access request can be intercepted based on the destination tag; the request can be filtered according to the destination tag in the configuration information to implement access control for different users or applications based on the tag, and traffic can be diverted according to the tag to implement traffic management, and different types of services can be isolated to improve system stability.

[0102] By obtaining an available virtual IP for the VIP controller, an available VIP controller is selected for the current request, and the request is distributed to different backend services through polling or other algorithms, thereby improving system availability. When a backend service is unavailable, the request can be forwarded to other available backend services.

[0103] By determining 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, so as to accurately route the request to the corresponding service, and 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 the backend service is accessed through the VIP, so that the client does not need to know the specific address of the backend service, but only needs to access it through the VIP, thereby reducing the configuration complexity of the client.

[0105] Exemplarily, the VIP controller (VIP-controller) is mainly used to implement the following process.

[0106] 1. Check service configuration:

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

[0108] Check whether the key checkpoint contains the innerloadBalance: true tag. If so, it means that the Service needs to be privately loaded and balanced.

[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 request is returned directly without any subsequent operations.

[0112] 3. Assign VIP:

[0113] Get an available IP address from etcd as the VIP of the Service.

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

[0115] 4. Create Service:

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

[0117] Bind the assigned VIP to the Service so that when the VIP is accessed externally, the traffic will be forwarded to the corresponding Pod.

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

[0119] Optionally, the VIP controller can also be used to:

[0120] 5. Create a virtual network card:

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

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

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

[0124] 6. Update etcd:

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

[0126] This way, the IP pool in etcd is kept up to date.

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

[0128] In the embodiment of the present invention, when the VIP controller detects that a user creates a service access request, the configuration information of the service access request is obtained; 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; a service resource corresponding to the service access request is determined, and the available virtual IP is distributed to the service resource; and the service resource is accessed based on the available virtual IP by the VIP controller, the concept of the VIP controller and the tag-based access control are introduced, which brings the following beneficial effects:

[0129] By introducing the VIP controller, the ports exposed by the service are decoupled from the ports inside Kubernetes. Each service corresponds to a unique VIP controller, avoiding the problem of port conflicts.

[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 purpose tags, fine-grained access control can be implemented to prevent illegal 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 find their targets.

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

[0134] Improve service availability: VIP can achieve load balancing and failover to improve service availability.

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

[0136] Improve system security: Improve system security by filtering by tags and hiding internal services.

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

[0138] Based on the above embodiment, a variant embodiment of the above embodiment is proposed. It should be noted that in order to make the description concise, only the differences from the above embodiment are described in the variant embodiment.

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

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

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

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

[0143] Ensure the uniqueness of IP addresses: The strong consistency of etcd ensures that the IP address assigned to each VIP controller is unique to avoid IP conflicts.

[0144] Improve system scalability: When the cluster scales up, you can increase the available IP pool by adding new IP addresses to etcd to achieve elastic expansion of the system.

[0145] Convenient 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] Improve system availability: Through the distributed characteristics of etcd, even if some etcd nodes fail, the allocation of IP addresses can still be guaranteed, thus improving the availability of the system.

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

[0149] Simplify system management: Centralize the management of IP addresses in etcd, simplifying the work of system administrators.

[0150] Improve system security: Through the access control mechanism of etcd, the allocation of IP addresses can be controlled to improve the security of the system.

[0151] Optionally, the Kubernetes cluster is configured with an application programming interface api-server for the service access request, and 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] Calling the application programming interface api-server to receive the available virtual IP;

[0153] Creating the service resource service based on the virtual IP;

[0154] The available virtual IP is configured to the service resource.

[0155] Exemplarily, the process of determining service resources and distributing available virtual IPs may be as follows:

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

[0157] The user or system sends a request to create a Service to the API Server through tools such as kubectl.

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

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

[0160] The API Server queries 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 obtains an unused IP address from the list.

[0163] 3. API Server creates 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, that is, the service resource must be of a type that supports load balancing.

[0166] Use the assigned IP address as the external access IP address of the Service.

[0167] Store the created Service in etcd.

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

[0169] The cloud platform or load balancer will monitor Service changes in etcd.

[0170] When a new LoadBalancer type Service is detected, a load balancer instance is automatically created for the Service.

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

[0172] 5. VIP Controller monitors Service status:

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

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

[0175] If the status of a Service changes to Failed, the VIP Controller may attempt to recreate the Service or perform failover.

[0176] Determining service resources and distributing available virtual IP addresses in the above manner can achieve the following beneficial effects:

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

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

[0179] Reliability: etcd ensures data consistency and improves system reliability.

[0180] Scalability: The IP address pool can be easily expanded to meet growing service needs

[0181] Optionally, it also includes:

[0182] Monitoring the execution status of the service resource through the VIP controller;

[0183] generating service resource update information based on the execution status;

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

[0185] In a specific implementation, the VIP controller VIP Controller of an embodiment of the present invention can continuously monitor the execution status changes of the service resource Service in etcd. Exemplarily, the changes may include the three states of creation, deletion and update. When the status of the Service changes (for example, from Pending to Running), the VIP Controller will perform corresponding processing. If the status of the Service becomes failed, the VIP Controller may try to recreate the Service or perform fault recovery. When the execution status is updated, service resource update information can be generated for the updated content, and the service resource update information and the updated service resource Service are sent to the application programming interface and submitted to the api-server.

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

[0187] Generate an address dynamic mapping protocol acquisition request through the VIP scanning controller;

[0188] Broadcasting an address dynamic mapping protocol acquisition request to the local area network of the Kubernetes cluster to receive an address dynamic mapping protocol response from a device in the local area network; the address dynamic mapping protocol response includes a device IP address and a device MAC address;

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

[0190] Exemplarily, the scanning process may be performed in the following manner.

[0191] 1. Start scanning:

[0192] The VIP scanning controller starts the scanning process according to the preset timing task or trigger condition.

[0193] 2. Send ARP request:

[0194] The scanning controller broadcasts ARP requests to the LAN to obtain the corresponding relationship between the IP addresses and MAC addresses of all devices in the LAN.

[0195] 3. The ARP protocol is a network protocol used in a local area network 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 in the LAN.

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

[0199] 5. Update etcd:

[0200] Write the received IP address and MAC address information into etcd.

[0201] etcd is a distributed key-value storage system used to store and manage key data. Storing IP and MAC address information in etcd makes it easier for the VIP controller to query when allocating VIPs.

[0202] In the embodiment of the present invention, the VIP scanning controller generates an address dynamic mapping protocol acquisition request; the address dynamic mapping protocol acquisition request is broadcasted to the local area network of the Kubernetes cluster to receive an address dynamic mapping protocol response from a device in the local area network; the address dynamic mapping protocol response includes a device IP address and a device MAC address; the device IP address and the device MAC address are written into the distributed key-value storage system etcd, thereby achieving the following beneficial effects:

[0203] Ensure VIP availability: Ensure that the VIP assigned to the service is available in the LAN through regular scanning.

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

[0205] Support dynamic IP environment: Even if the IP address in the LAN changes, the IP pool can be updated in time.

[0206] The scanning process is an important part of the entire private load balancing solution, which provides basic data for VIP allocation. By regularly scanning the LAN, the IP information in etcd is ensured to be up to date, thereby ensuring the accuracy of VIP allocation. When allocating VIPs, available IP addresses will be queried from etcd. If the IP information in etcd is inaccurate, VIP allocation may fail. The scanning process ensures the reliability of the entire solution, allowing private load balancing to run stably.

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

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

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

[0210]

[0211]

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

[0213] S2.VIP-controller verifies and intercepts the service.

[0214] If the label innerLoadBalance: true is contained, the IP address pool in etcd is read first, and after finding an available IP, the result is returned to the api-server to create the corresponding service, define the service type as LoadBalance, and monitor the service status. If there is no label, no operation is performed.

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

[0216] refer to Figure 6 , Figure 6 is a schematic diagram of an 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 scan the IP of the local area network where the node is located at regular intervals, and store the IP and mac of the scan results in etcd. etcd uses kv data storage, and its query speed is generally better than that of relational databases. Its main principle is to obtain the IP and Mac addresses of devices in the local area network by sending arp packets using gopacket.

[0218] S4.VIP-controller completes the loadbalance IP change of the service to VIP, and users can access the service through VIP. VIP-controller monitors the creation, deletion, and update of the service, and finally submits the service to the api-server.

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

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

[0221] The deletion and update processes can be based on Figure 7 and Figure 8The process diagram is shown in FIG.

[0222] For example, based on Figure 7 VIP controller plays a key role in the Service life cycle: listening to Service deletion events. When a Service is deleted, the VIP controller will perform a series of operations to ensure the consistency of the system state.

[0223] Process interpretation:

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

[0225] API Server processes the request: After receiving the deletion request, the API Server broadcasts the deletion event to the entire Kubernetes cluster.

[0226] VIP-controller senses the deletion event: As a component in the cluster, VIP-controller continuously monitors the events of the API Server. When it senses the event that a service is 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 VIP: Similar to virtual network interfaces, VIPs also correspond to services one by one. Therefore, VIP-controller will delete the VIP associated with the service from the system.

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

[0230] The significance of deleting the VIP-controller monitoring service:

[0231] Resource recovery: By deleting the virtual network interface and VIP associated with the Service, system resources are released and resource utilization is improved.

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

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

[0234] Figure 8 This shows a series of operations performed by the VIP controller when updating a Service. Compared with the previous deletion operation, the update operation involves more resource status changes.

[0235] Process interpretation:

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

[0237] API Server processes the request: After receiving the update request, the API Server broadcasts the update event to the entire Kubernetes cluster.

[0238] VIP-controller senses update events: VIP-controller will continue to monitor API Server events. When it senses an event that a Service has been updated, it will trigger subsequent processing.

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

[0240] Delete the original network interface: Similar to VIP, the network interface 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 VIP: Create a new network interface and bind the newly created VIP to this network interface.

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

[0244] Update etcd: Update the data in etcd and update the correspondence between Service and VIP to the latest status.

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

[0246] State synchronization: Ensure that the state of VIP and Service is always consistent to avoid configuration mismatch.

[0247] Dynamic adjustment: Ability to dynamically adjust VIP configuration according to changes in Service configuration to adapt to changes in business needs.

[0248] High availability: Ensure service availability by updating VIP in a timely manner.

[0249] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0250] Reference Fig. 9 , shows 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 the user creates a service access request;

[0252] A service access request interception module 902, configured to intercept the service access request based on the destination tag when the configuration information is determined by the VIP controller to contain the destination tag;

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

[0254] An 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 based on the available virtual IP through the VIP controller.

[0256] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0257] In addition, an embodiment of the present invention further provides an electronic device, such as Fig.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, used for storing computer programs;

[0259] The processor 1001 is configured to implement the service resource access method described in any one of the above embodiments when executing the program stored in the memory 1003:

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

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

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

[0263] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0264] like Fig.11 As shown, in another embodiment provided by the present invention, a computer-readable storage medium 1101 is also provided, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the service resource access method described in the above embodiment.

[0265] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the enlightenment of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.

[0266] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

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

[0268] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

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

[0271] If the functions are implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks, or optical disks.

[0272] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A service resource access method, characterized in that: The method is applied to a Kubernetes cluster, wherein the Kubernetes cluster is provided with a VIP controller, and comprises: When the VIP controller detects that a user creates a service access request, obtaining configuration information of the service access request; When it is determined by the VIP controller that the configuration information includes a destination tag, intercepting the service access request based on the destination tag; Obtain an available virtual IP for the VIP controller; Determine a service resource corresponding to the service access request, and distribute the available virtual IP to the service resource; The service resource is accessed through the VIP controller based on the available virtual IP.

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

3. The method according to claim 1, characterized in that The Kubernetes cluster is configured with an application programming interface for the service access request, and the steps of determining a service resource corresponding to the service access request and distributing the available virtual IP to the service resource include: Calling the application programming interface to receive the available virtual IP; Creating the service resource based on the virtual IP; The available virtual IP is configured to the service resource.

4. The method according to claim 2, characterized in that: The VIP controller includes a VIP scanning controller, and further includes: Generate an address dynamic mapping protocol acquisition request through the VIP scanning controller; Broadcasting an address dynamic mapping protocol acquisition request to the local area network of the Kubernetes cluster to receive an address dynamic mapping protocol response from a device in the local area network; the address dynamic mapping protocol response includes a device IP address and a device MAC address; The device IP address and device MAC address are written into the distributed key-value storage system etcd.

5. The method according to claim 3, characterized in that: Also includes: Create a virtual network card, and bind the VIP controller to the virtual network card.

6. The method according to claim 5, characterized in that Also includes: Monitoring the execution status of the service resource through the VIP controller; generating service resource update information based on the execution status; The service resource update information is sent to the application programming interface.

7. The method according to claim 1 or 6, characterized in that: Also includes: Set the service resource to a resource type that supports load balancing.

8. A service resource access device, characterized in that: The device is applied to a Kubernetes cluster, and the Kubernetes cluster is provided with a VIP controller, including: A configuration information acquisition module, used to acquire configuration information of a service access request when a user creates a service access request through the VIP controller; A service access request interception module, configured to intercept the service access request based on the destination tag when it is determined by the VIP controller that the configuration information contains a destination tag; An available virtual IP acquisition module, used to acquire an available virtual IP for the VIP controller; An available virtual IP distribution module, used to determine the service resource corresponding to the service access request and distribute the available virtual IP to the service resource; A service resource access module is used to access the service resource based on the available virtual IP through the VIP controller.

9. 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; The processor is used to implement the method according to any one of claims 1 to 7 when executing the program stored in the memory.

10. A computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 7.

Images