CN112153143A - Kubernetes cluster flow scheduling method and device and electronic equipment - Google Patents

Kubernetes cluster flow scheduling method and device and electronic equipment Download PDF

Info

Publication number
CN112153143A
CN112153143A CN202011017804.4A CN202011017804A CN112153143A CN 112153143 A CN112153143 A CN 112153143A CN 202011017804 A CN202011017804 A CN 202011017804A CN 112153143 A CN112153143 A CN 112153143A
Authority
CN
China
Prior art keywords
pod
endpoint resource
available
standby
access address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202011017804.4A
Other languages
Chinese (zh)
Other versions
CN112153143B (en
Inventor
贾永鹏
马超
揭震
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sina Technology China Co Ltd
Original Assignee
Sina Technology China Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sina Technology China Co Ltd filed Critical Sina Technology China Co Ltd
Priority to CN202011017804.4A priority Critical patent/CN112153143B/en
Publication of CN112153143A publication Critical patent/CN112153143A/en
Application granted granted Critical
Publication of CN112153143B publication Critical patent/CN112153143B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Abstract

The application discloses a Kubernet cluster flow scheduling method and device and electronic equipment, which can realize flow scheduling in a master mode and a standby mode in Service. The method comprises the following steps: acquiring Endpoint resources of the Kubernets cluster, wherein the Endpoint resources comprise an access address of a Pod corresponding to a Service of the Kubernets cluster; determining the Pod type of a Pod in the Endpoint resource based on the access address of the Pod in the Endpoint resource, wherein the Pod type comprises a main Pod and a standby Pod; modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the Pod in the Endpoint resource, wherein the Pod type of the available Pod in the modified Endpoint resource is only a main Pod or a standby Pod; and starting an access address of the Pod in the modified Endpoint resource, and performing flow scheduling on the Pod by the Service based on the started access address.

Description

Kubernetes cluster flow scheduling method and device and electronic equipment
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for traffic scheduling of a Kubernetes cluster, and an electronic device.
Background
The current Kubernetes cluster mainly adopts a polling flow scheduling mode, Service (Service) acquires the load condition of a Pod by polling the Pod of a corresponding back end, and then schedules access flow from the outside of the Kubernetes cluster to the corresponding Pod based on the load condition of the Pod. In this way, if a part of the Pod is hung or restarted, etc., the processing of the access traffic is interrupted.
In view of this, a scheme capable of implementing traffic scheduling in the active/standby mode is needed.
Disclosure of Invention
The embodiment of the application provides a traffic scheduling method and device of a Kubernet cluster and electronic equipment, which can realize traffic scheduling in a master mode and a standby mode in Service.
In order to solve the technical problem, the embodiment of the application adopts the following technical scheme:
in a first aspect, an embodiment of the present application provides a method for traffic scheduling of a kubernets cluster, where the method includes:
acquiring Endpoint resources of the Kubernets cluster, wherein the Endpoint resources comprise an access address of a Pod corresponding to a Service of the Kubernets cluster;
determining the Pod type of a Pod in the Endpoint resource based on the access address of the Pod in the Endpoint resource, wherein the Pod type comprises a main Pod and a standby Pod;
modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the modified Endpoint resource is only a main Pod or a standby Pod;
and starting the access address of the available Pod in the modified Endpoint resource, and performing flow scheduling on the available Pod by the Service based on the started access address.
Optionally, modifying the Endpoint resource based on Pod types of available pods in the Endpoint resource, where the Pod types of the available pods in the modified Endpoint resource are only primary pods or standby pods, and the modifying includes:
modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the Pod in the Endpoint resource, wherein the Pod type of the available Pod in the Endpoint resource after modification is only a main Pod or a standby Pod, and the method comprises the following steps:
under the condition that the Pod types of the available pods in the Endpoint resource simultaneously comprise a main Pod and a standby Pod, removing the access address of the standby Pod in the Endpoint resource by changing an admission controller;
and under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod, reserving the access address of the available Pod in the Endpoint resource.
Optionally, before modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, the method further includes:
detecting whether the Endpoint resource contains an access address of the standby Pod or not;
if the Endpoint resource contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the Endpoint resource, and determining that the access address of the standby Pod in the Endpoint resource passes the normative verification.
Optionally, before modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, the method further includes:
monitoring Service of the Kubernetes cluster;
and verifying the Service based on a pre-configured verification admission control mechanism, and determining that the Service passes the verification.
Optionally, verifying the Service based on a pre-configured verification admission control mechanism, and determining that the Service passes the verification, includes:
detecting whether the label of the Service contains the access address of the standby Pod or not;
if the label contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the label;
and if the access address of the spare Pod in the label passes the normative verification, determining that the Service passes the verification.
Optionally, initiating an access address of an available Pod in the modified Endpoint resource, including:
under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods and the number of the standby pods is multiple, based on the flow size to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, selecting a target Pod for flow scheduling from the multiple available pods contained in the modified Endpoint resource, and starting an access address of the target Pod;
and starting the access addresses of all available Pods in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource after modification is only the main Pod.
In a second aspect, an embodiment of the present application provides a device for scheduling traffic of a kubernets cluster, where the device includes:
an Endpoint resource obtaining unit, configured to obtain an Endpoint resource of the kubernets cluster, where the Endpoint resource includes an access address of a Pod corresponding to a Service of the kubernets cluster;
a determining unit, configured to determine, based on an access address of a Pod in the Endpoint resource, a Pod type of an available Pod that is available for traffic scheduling in the Endpoint resource, where the Pod type includes a primary Pod and a standby Pod;
the modification unit is used for modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the Endpoint resource after modification is only a main Pod or a standby Pod;
and the Service performs flow scheduling on the available Pod based on the started access address.
Optionally, the modifying unit is specifically configured to:
under the condition that the Pod types of the available pods in the Endpoint resource simultaneously comprise a main Pod and a standby Pod, removing the access address of the standby Pod in the Endpoint resource by changing an admission controller;
and under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod, reserving the access address of the available Pod in the Endpoint resource.
Optionally, the apparatus further includes a change admission checking unit;
the change admission checking unit is specifically configured to:
detecting whether the Endpoint resource contains an access address of the standby Pod or not;
and if the Endpoint resource comprises the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the Endpoint resource, and triggering the modification unit under the condition that the access address of the standby Pod in the Endpoint resource is determined to pass the normative verification.
Optionally, the apparatus further comprises:
a Service monitoring unit, configured to monitor a Service of the kubernet cluster;
and the verification admission checking unit is used for checking the Service based on a pre-configured verification admission control mechanism and triggering the modification unit under the condition that the Service passes the checking.
Optionally, the verification admission check unit is specifically configured to:
detecting whether the label of the Service contains the access address of the standby Pod or not;
if the label contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the label;
and if the access address of the spare Pod in the label passes the normative verification, determining that the Service passes the verification.
Optionally, the starting unit is specifically configured to:
under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods and the number of the standby pods is multiple, determining a target Pod for traffic scheduling from the multiple available pods contained in the modified Endpoint resource based on the size of traffic to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting an access address of the target Pod;
and starting the access addresses of all available Pods in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource after modification is only the main Pod.
In a third aspect, an embodiment of the present application provides an electronic device, including:
a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the method for traffic scheduling of a kubernets cluster according to the first aspect.
In a fourth aspect, an embodiment of the present application provides a storage medium, where instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the traffic scheduling method of the kubernets cluster according to the first aspect.
The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects:
by the flow scheduling method of the Kubernets cluster, provided by the embodiment of the application, the Service in the Kubernets cluster and the operation condition of the corresponding Pod can be obtained by acquiring the Endpoint resource of the Kubernets cluster; the method comprises the steps of verifying and modifying the Endpoint resource by using a pre-configured change admission mechanism, enabling the Pod type of an available Pod in the modified Endpoint resource to be only a main Pod or a standby Pod, further starting an access address of the available Pod in the Endpoint resource, enabling only the main Pod or the standby Pod corresponding to Service to operate, further enabling the Service to only schedule external traffic to the corresponding main Pod or the standby Pod, and realizing flexible traffic scheduling by using a main mode and a standby mode in the Service.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a flowchart of a traffic scheduling method of a kubernets cluster according to an embodiment of the present application;
fig. 2 is a schematic diagram of a traffic scheduling process of a kubernets cluster according to an embodiment of the present application;
fig. 3 is a flowchart of another method for traffic scheduling of a kubernets cluster according to the embodiment of the present application;
fig. 4 is a flowchart of another method for traffic scheduling of a kubernets cluster according to the embodiment of the present application;
fig. 5 is a flowchart of another method for traffic scheduling of a kubernets cluster according to the embodiment of the present application;
fig. 6 is a schematic structural diagram of another kubernets cluster traffic scheduling apparatus according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
Example 1
The embodiment of the application provides a traffic scheduling method for a kubernets cluster, which can realize the traffic scheduling switching of a main mode and a standby mode in the Service of the kubernets cluster according to the operation condition of a Pod corresponding to the Service at the rear end, so as to avoid the problem caused by the interruption of traffic processing. The method can be applied to an Application Programming Interface (API) Server (or an API Server) of a Kubernetes cluster. As shown in fig. 1, the method comprises the steps of:
and S12, acquiring the Endpoint resource of the Kubernets cluster.
The Endpoint resource comprises an access address of a Pod corresponding to Service of the Kubernetes cluster.
Specifically, the Endpoint is a resource object in the kubernets cluster, is stored in the ETCD of the kubernets cluster, and is used for recording access addresses of all the Pod corresponding to one Service. An Endpoint Controller component in the Kubernetes cluster can create a corresponding Endpoint for Service, monitor the change of the Service and the corresponding Pod, and update the Endpoint according to the change of the Service and the corresponding Pod, thereby obtaining Endpoint resources.
S14, based on the access address of the Pod in the Endpoint resource, determining the Pod type of the available Pod in the Endpoint resource, which can be used for flow scheduling.
Wherein the Pod types include a primary Pod and a secondary Pod. The Service dispatches the access flow to any one or more Pods for processing, the Pod being processed is used as a main Pod corresponding to the Service, and the other Pods corresponding to the Service are used as standby Pods of the current main Pod.
Specifically, the access address of the standby Pod in the kubernets cluster may be preset, after the Endpoint resource is obtained, the access address of the available Pod for traffic scheduling may be read from the subset of the Endpoint resource, and the access addresses of the available Pod are respectively compared with the preset access address of the standby Pod, so as to determine the Pod type of the available Pod of the Endpoint resource.
And S16, modifying the Endpoint resource based on the pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the Endpoint resource after modification is only a main Pod or a standby Pod.
Specifically, the change admission mechanism may be built in a resource object, which is the mutewebhookconfiguration of the kubernets cluster, and the definition of the change admission mechanism may include, but is not limited to: a namespace in which a muttingadmission Webhook service is located, a Webhook request path, a Base64 encoding of a CA certificate, a change matching rule, etc., wherein the change matching rule is used to indicate kubernets resources that can enter a change Admission Controller (change Admission Controller) of the API Server. For example, the matching rule may be: and enabling the Endpoint resource with the key of 'end-point-extended' and the value of 'end-point-back-ip' label to enter the change admission controller.
As shown in fig. 2, the change Admission controller may verify the Endpoint resource based on the muted webhookconfiguration, and if the Endpoint resource conforms to the change matching rule defined in the muted webhookconfiguration, the change Admission controller may interact with the muted Admission Webhook service based on the Endpoint resource to modify the Endpoint resource, and store the modified Endpoint resource in the ETCD. Wherein, the change Admission controller and the multicast Admission Webhook service interact in a mode of HTTPS (Hyper Text Transfer Protocol Over Secure Socket).
Specifically, the change admission controller may delete or reserve an access address including a Pod in the Endpoint resource according to the Pod type of the available Pod in the Endpoint resource, so that the Pod type of the available Pod in the Endpoint resource is only a primary Pod or a standby Pod, and further, only the primary Pod or the standby Pod can be scheduled by Service.
And under the condition that the Pod type of the available Pod in the Endpoint resource is only the standby Pod, the main Pod is unavailable and only the standby Pod is available in the Pod corresponding to the Service. At this time, the admission controller is not required to be changed to modify the Endpoint resource.
And under the condition that the Pod types of the available pods in the Endpoint resource simultaneously comprise the main pods and the standby pods, both the main pods and the standby pods corresponding to the Service are available. At this time, the change admission controller may delete the access address of the standby Pod in the Endpoint to avoid that the standby Pod is not scheduled to the traffic.
And under the condition that no Pod is available in the Endpoint resource, the main Pod and the standby Pod corresponding to the Service are unavailable, and at the moment, the access controller is changed without modifying the Endpoint resource.
When the Pod type of the available Pod in the Endpoint resource is only the master Pod, that is, the master Pod corresponding to Service is available, the access controller is changed without modifying the Endpoint resource.
And S18, starting the access address of the available Pod in the modified Endpoint resource, and performing traffic scheduling on the available Pod by the Service based on the started access address.
In an optional scheme, under the condition that the Pod type of an available Pod in the modified Endpoint resource is only a main Pod, the access addresses of all available pods in the Endpoint resource can be started, at this time, the access addresses of the available pods in the Endpoint resource can be directly started, the main Pod still processes the traffic allocated by the Service, and the continuity of traffic scheduling is ensured.
And under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods, the access addresses of all the pods can be started, at this time, Service can forward the external access traffic of the kubernets cluster to the standby pods, and the standby pods process the external access traffic, so that the problem of access traffic processing interruption caused by unavailability of the main Pod can be avoided.
Considering that the number of the standby Pod is large and the traffic to be scheduled is small, if all the standby pods are started, a situation that part of the standby pods are in an idle state may occur, and the operation of the standby pods in the idle state may cause resource waste. In order to solve this problem, in a more preferred scheme, when the type of available Pod in the modified Endpoint resource is only spare Pod and the number of spare pods is multiple, a target Pod for traffic scheduling may be determined from the multiple available pods included in the modified Endpoint resource based on the load capacity of each available Pod included in the modified Endpoint resource and the size of traffic to be scheduled, and an access address of the target Pod may be started. The load capacity of the available Pod is used to characterize the amount of traffic that the Pod can carry, which can be determined based on the capacity of the Pod and other performance related parameters.
Of course, in some other preferred schemes, access addresses of the available pods may be sequentially started according to the weight based on the weight corresponding to each available Pod in the Endpoint resource, or access addresses of available pods with weights exceeding the preset weight may be started. The weight corresponding to the available Pod can be set by user according to actual needs.
By the flow scheduling method of the Kubernets cluster, provided by the embodiment of the application, the Service in the Kubernets cluster and the operation condition of the corresponding Pod can be obtained by acquiring the Endpoint resource of the Kubernets cluster; the method comprises the steps of verifying and modifying the Endpoint resource by using a pre-configured change admission mechanism, enabling the Pod type of an available Pod in the modified Endpoint resource to be only a main Pod or a standby Pod, further starting an access address of the available Pod in the Endpoint resource, enabling only the main Pod or the standby Pod corresponding to Service to operate, further enabling the Service to only schedule external traffic to the corresponding main Pod or the standby Pod, and realizing flexible traffic scheduling by using a main mode and a standby mode in the Service.
In order to make those skilled in the art understand the technical solution provided in the embodiment of the present application, a detailed description is given below of a traffic scheduling manner of the kubernets cluster provided in the embodiment of the present application.
In an optional scheme, considering that the access address of the standby Pod is included in the Endpoint resource, it is only possible to implement switching between the primary and standby traffic scheduling modes in Service, and in order to ensure implementation of the primary and standby traffic scheduling modes, it is also necessary to ensure that the access address of the standby Pod is valid. Based on this, before the step S16, the method provided in the embodiment of the present application may further include: and detecting whether the Endpoint resource contains the access address of the standby Pod, if the Endpoint resource contains the access address of the standby Pod, performing normative check on the access address of the standby Pod in the Endpoint resource, and determining that the access address of the standby Pod passes the normative check. After determining that the access address of the backup Pod in the Endpoint resource passes the normative check, the above step S16 is executed.
Specifically, as shown in fig. 3, the change Admission controller may determine whether the obtained Endpoint resource conforms to a matching rule defined in the muteing Webhook configuration resource, and if so, carry the obtained Endpoint resource in the POST request and send the POST request to a URL corresponding to the change Admission Webhook service (muteing Admission Webhook service). After receiving a POST request from a change admission controller, the change admission Webhook service requests JSON data related to an Endpoint resource contained in a BODY BODY, and performs deserialization operation on the JSON data. If the deserialization operation fails, returning a notification message of failed modification to the change admission controller to indicate that the change admission controller does not modify the Endpoint resource if the change admission Webhook service fails; and if the deserialization operation is successful, changing the access Webhook service, acquiring label information of the Endpoint resource, and acquiring an access address (such as an IP address) of the standby Pod based on the label. And then, the change admission Webhook service performs normative verification on the acquired access address of the backup Pod, for example, verifying whether the access address meets the address specification, whether a corresponding separator exists, and the like. If the access address of the standby Pod does not pass the normative verification, and the change admission Webhook service returns a notification message of failed modification to the change admission controller so as to indicate the change admission controller not to modify the Endpoint resource; and if the access address of the backup Pod passes the normative verification and the access Webhook service is changed, further judging whether Subsets of the Endpoint resource contain the access address.
Under the condition that the Subsets do not contain any access address, the Pod corresponding to the Service is determined to be unavailable at the moment, and the change admission Webhook Service can return a notification message of failed modification to the change admission controller so as to indicate the change admission controller not to modify the Endpoint resource.
When only the access address of the slave Pod is included in the Subsets, it may be determined that the master Pod corresponding to Service is unavailable at this time, and only the slave Pod is available, and the change admission Webhook Service may return a notification message that the modification is passed to the change admission controller, so as to instruct the change admission controller to start the access address included in the Subsets. Accordingly, in step S18, the change admission controller may start the access address included in the Subsets to start the standby Pod, so that the Service may schedule the access traffic to the standby Pod for processing, thereby ensuring the continuity of the access traffic processing.
Under the condition that the Subsets contain the access address of the main Pod and the access address of the standby Pod, the main Pod and the standby Pod corresponding to the Service can be determined to be available at the time, and further, the change admission Webhook Service can generate a corresponding modification request based on the access address of the standby Pod and send the modification request to the change admission controller so as to request the change admission controller to modify the Endpoint resource. Accordingly, in step S16, the change admission controller may delete the access address of the standby Pod contained in the Subsets of the Endpoint resource based on the modification request. In step S18, the change admission controller starts the access address of the available Pod in the modified Endpoint resource. Because the available Pod in the modified Endpoint resource is only the master Pod, the Pod corresponding to the Service cannot be started, and the Service still schedules the access traffic to the master Pod for processing, the traffic scheduling mode of the master mode is realized.
It can be understood that in the above scheme, by performing normative verification on the access address of the standby Pod contained in the Endpoint resource, it can be ensured that the subsequently enabled access address is valid, and the stability and security of the traffic scheduling process of the kubernets cluster are ensured; after the access address of the spare Pod passes the normative verification, the access address and the type of the available Pod which is corresponding to the Service and can be used for flow scheduling are determined based on the access address contained in Subsets under the Endpoint resource, the logic is simple to realize, and the convenience of the flow scheduling of the Kubernetes cluster is improved.
Example 2
The embodiment of the present application further provides another method for scheduling traffic of a kubernets cluster, and on the basis of embodiment 1, the embodiment is further improved, where the specific improvements are as follows: before the step S14, the Service of the kubernets cluster may also be verified, and it is determined that the Service passes the verification. As shown in fig. 4, the method for scheduling traffic of a kubernets cluster in this embodiment of the application includes steps S42 to S52, where step S42 is substantially the same as step S12 in embodiment 1, step S48 is substantially the same as step S14 in embodiment 1, step S50 is substantially the same as step S16 in embodiment 1, and step S52 is substantially the same as step S18 in embodiment 1, which is not repeated herein, and differences are mainly described below, and technical details not described in detail in the embodiment may be referred to a method for scheduling traffic of a kubernets cluster provided in embodiment 1, and are not repeated herein.
And S42, acquiring Endpoint resources of the Kubernets cluster.
And S44, monitoring the Service of the Kubernets cluster.
Specifically, the Endpoint Controller component in the kubernets cluster listens for changes to Service.
S46, checking the Service based on the pre-configured verification admission control mechanism.
Specifically, the authentication admission control mechanism may be built in a resource object, validating webhookconfiguration of kubernets cluster, and the definition thereof may include but is not limited to: a namespace in which a validatingadvissionwebhook service (authentication Admission Webhook service) is located, a Webhook request path, Base64 encoding of a CA certificate, a matching rule, etc., wherein the matching rule is used to indicate that kubernets resources of a authentication Admission Controller (Validating Admission Controller) of the API Server can be entered. For example, the matching rule may be: and the Service with the key of 'end-extended' and the value of 'end-point-backup-ip' label enters the verification admission controller.
As shown in fig. 2, the verifying Admission controller may verify the Service based on the Validating Webhook configuration, and if the Service conforms to the matching rule defined in the Validating Webhook configuration, the verifying Admission controller may interact with the Validating Admission Webhook Service (verifying Admission Webhook Service) based on the Service to further verify the Service, and store the Service in the ETCD after the Service passes the verification. The authentication Admission controller and the valid Admission Webhook service interact in an HTTPS mode.
S48, determining the Pod type of the available Pod which can be used for flow scheduling in the Endpoint resource based on the access address of the Pod in the Endpoint resource when the Service passes the verification.
And S50, modifying the Endpoint resource based on the pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the Endpoint resource after modification is only a main Pod or a standby Pod.
And S52, starting the access address of the available Pod in the modified Endpoint resource, and performing traffic scheduling on the available Pod by the Service based on the started access address.
It can be understood that, according to the traffic scheduling scheme of the kubernets cluster provided in this embodiment, by introducing the verification admission control mechanism into the kubernets cluster, before the Endpoint resource is verified and modified based on the change admission control mechanism, the Service of the kubernets cluster is verified, and it is determined that the Service passes the verification, so that the validity of the Service can be ensured, and the stability and the security of the traffic scheduling of the kubernets cluster are further improved.
In an alternative, the step S46 may include: detecting whether the obtained label of the Service in the Service contains the access address of the standby Pod, if so, performing normative verification on the access address of the standby Pod in the label, and if the access address of the standby Pod in the label passes the normative verification, determining that the Service passes the verification.
Specifically, as shown in fig. 5, the verification Admission controller may determine whether the obtained Service originally conforms to the matching rule based on the matching rule defined in the Validating Webhook configuration resource, and if so, carry the obtained Service information in the POST request and send the Service information to a URL corresponding to the Validating Admission Webhook Service (verification Admission Webhook Service). After receiving a POST request from a verification admission controller, the verification admission Webhook Service requests JSON data related to Service contained in a BODY BODY, and performs deserialization operation on the JSON data, namely deserialization operation on Service information. If the deserialization operation fails, if the Webhook service is verified to be admitted, a notification message of verification failure is returned to the verification admission controller; if the deserialization operation is successful, the Webhook Service is verified to be admitted, the name and the label information of Service are obtained, whether a label with a key of 'end-extended' and a value of 'end-backup-ip' exists in the obtained label information is judged, if yes, whether a 'backup IP' label exists is further judged, and if yes, the access address of the corresponding backup Pod is obtained through the label. And then, verifying that the Webhook access service performs normative verification on the acquired access address of the standby Pod, for example, verifying whether the access address meets the address specification, whether a corresponding separator exists, and the like. If the access address does not pass the normative verification, if the Webhook service is verified to be admitted, a notification message of verification failure is returned to the verification admission controller; and if the access address passes through the normative verification, and the verification of the access to the Webhook service returns a notification message of successful verification to the verification access controller.
It can be understood that, in the above scheme, by performing normative verification on the access address of the standby Pod included in the tag of the Service, it can be ensured that the subsequently enabled access address is effective, the stability and the security of the traffic scheduling process of the kubernets cluster are ensured, the implementation logic is simple, and the convenience of the traffic scheduling of the kubernets cluster is improved.
It should be noted that, in the foregoing embodiment of the present application, in order to improve the Security of interaction between an admission controller (including a change admission controller and a verification admission controller) and its corresponding admission Webhook service (including a change admission Webhook service and a verification admission Webhook service), TLS (Transport Layer Security) authentication may also be performed in the process of interaction between the two admission controllers. Specifically, a CA Certificate and a CA private key may be generated, a private key of the Webhook service is generated, a CSR (Certificate Sign Request, Certificate signing Request) and a Base64 code of the CA Certificate are generated for the private key of the Webhook service, and then interaction may be performed between the admission controller and the corresponding admission Webhook service based on the generated data.
It should be noted that the above description describes certain embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Example 3
Referring to fig. 6, an embodiment of the present application further provides a device 600 for scheduling traffic of a kubernets cluster, where the device 600 may be applied to an API Server of the kubernets cluster. As shown in fig. 6, the apparatus 600 may include:
an Endpoint resource obtaining unit 610, configured to obtain an Endpoint resource of the kubernets cluster, where the Endpoint resource includes an access address of a Pod corresponding to a Service of the kubernets cluster.
A determining unit 620, configured to determine, based on an access address of a Pod in the Endpoint resource, a Pod type of an available Pod that is available for traffic scheduling in the Endpoint resource, where the Pod type includes a primary Pod and a standby Pod.
A modifying unit 630, configured to modify the Endpoint resource based on a preconfigured change admission control mechanism and Pod types of available pods in the Endpoint resource, where the Pod types of the available pods in the Endpoint resource after modification are only primary pods or standby pods.
And the starting unit 640 is configured to start an access address of an available Pod in the modified Endpoint resource, and the Service performs traffic scheduling on the available Pod based on the started access address.
Optionally, the modifying unit 630 is specifically configured to:
under the condition that the Pod types of the available pods in the Endpoint resource simultaneously comprise a main Pod and a standby Pod, removing the access address of the standby Pod in the Endpoint resource by changing an admission controller;
and under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod, reserving the access address of the available Pod in the Endpoint resource.
Optionally, the apparatus further includes a change admission checking unit;
the change admission checking unit is specifically configured to:
detecting whether the Endpoint resource contains an access address of the standby Pod or not;
and if the Endpoint resource comprises the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the Endpoint resource, and triggering the modification unit under the condition that the access address of the standby Pod in the Endpoint resource is determined to pass the normative verification.
Optionally, the apparatus 600 may further include:
and the Service monitoring unit is used for monitoring the Service of the Kubernet cluster.
And the verification admission checking unit is used for checking the Service based on a pre-configured verification admission control mechanism and triggering the modification unit under the condition that the Service passes the checking.
Optionally, the verification admission check unit is specifically configured to:
detecting whether the label of the Service contains the access address of the standby Pod or not;
if the label contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the label;
and if the access address of the spare Pod in the label passes the normative verification, determining that the Service passes the verification.
Optionally, the starting unit 640 is specifically configured to:
under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods and the number of the standby pods is multiple, determining a target Pod for traffic scheduling from the multiple available pods contained in the modified Endpoint resource based on the size of traffic to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting an access address of the target Pod;
and starting the access addresses of all available Pods in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource after modification is only the main Pod.
Example 4
Referring to fig. 7, an electronic device is further provided in the embodiments of the present application. Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Referring to fig. 7, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 7, but this does not indicate only one bus or one type of bus.
And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.
The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the traffic scheduling device of the Kubernetes cluster on a logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:
acquiring Endpoint resources of the Kubernets cluster, wherein the Endpoint resources comprise an access address of a Pod corresponding to a Service of the Kubernets cluster;
determining the Pod type of a Pod in the Endpoint resource based on the access address of the Pod in the Endpoint resource, wherein the Pod type comprises a main Pod and a standby Pod;
modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the modified Endpoint resource is only a main Pod or a standby Pod;
and starting the access address of the available Pod in the modified Endpoint resource, and performing flow scheduling on the available Pod by the Service based on the started access address.
The method executed by the traffic scheduling device of the kubernets cluster as disclosed in the embodiment of fig. 1 of the present application may be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also 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, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
The electronic device may also execute the method in fig. 1, and implement the functions of the embodiment of the traffic scheduling device in the kubernets cluster shown in fig. 1, which are not described herein again in this embodiment of the application.
Of course, besides the software implementation, the electronic device of the present application does not exclude other implementations, such as a logic device or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or a logic device.
Embodiments of the present application also provide a computer-readable storage medium storing one or more programs, where the one or more programs include instructions, which when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to perform the method of the embodiment shown in fig. 1, and are specifically configured to:
acquiring Endpoint resources of the Kubernets cluster, wherein the Endpoint resources comprise an access address of a Pod corresponding to a Service of the Kubernets cluster;
determining the Pod type of a Pod in the Endpoint resource based on the access address of the Pod in the Endpoint resource, wherein the Pod type comprises a main Pod and a standby Pod;
modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the modified Endpoint resource is only a main Pod or a standby Pod;
and starting the access address of the available Pod in the modified Endpoint resource, and performing flow scheduling on the available Pod by the Service based on the started access address.
In short, the above description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

Claims (10)

1. A traffic scheduling method of a Kubernetes cluster is characterized by comprising the following steps:
acquiring Endpoint resources of the Kubernets cluster, wherein the Endpoint resources comprise an access address of a Pod corresponding to a Service of the Kubernets cluster;
determining the Pod type of an available Pod which can be used for flow scheduling in the Endpoint resource based on the access address of the Pod in the Endpoint resource, wherein the Pod type comprises a main Pod and a standby Pod;
modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the modified Endpoint resource is only a main Pod or a standby Pod;
and starting the access address of the available Pod in the modified Endpoint resource, and performing flow scheduling on the available Pod by the Service based on the started access address.
2. The method of claim 1, wherein the Endpoint resource is modified based on a pre-configured change admission control mechanism and Pod types of available pods in the Endpoint resource, and the modified Pod types of the available pods in the Endpoint resource are only primary pods or standby pods, including:
under the condition that the Pod types of the available pods in the Endpoint resource simultaneously comprise a main Pod and a standby Pod, removing the access address of the standby Pod in the Endpoint resource by changing an admission controller;
and under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod, reserving the access address of the available Pod in the Endpoint resource.
3. The method of claim 1, wherein before modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, the method further comprises:
detecting whether the Endpoint resource contains an access address of the standby Pod or not;
if the Endpoint resource contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the Endpoint resource, and determining that the access address of the standby Pod in the Endpoint resource passes the normative verification.
4. The method of claim 1, wherein before modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, the method further comprises:
monitoring Service of the Kubernetes cluster;
and verifying the Service based on a pre-configured verification admission control mechanism, and determining that the Service passes the verification.
5. The method of claim 4, wherein verifying the Service based on a pre-configured verification admission control mechanism and determining that the Service passes the verification comprises:
detecting whether the label of the Service contains the access address of the standby Pod or not;
if the label contains the access address of the standby Pod, performing normative verification on the access address of the standby Pod in the label;
and if the access address of the spare Pod in the label passes the normative verification, determining that the Service passes the verification.
6. The method of claim 1, wherein initiating an access address for an available Pod in the modified Endpoint resource comprises:
under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods and the number of the standby pods is multiple, determining a target Pod for traffic scheduling from the multiple available pods contained in the modified Endpoint resource based on the size of traffic to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting an access address of the target Pod;
and starting the access addresses of all available Pods in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource after modification is only the main Pod.
7. A kubernets cluster traffic scheduling apparatus, comprising:
an Endpoint resource obtaining unit, configured to obtain an Endpoint resource of the kubernets cluster, where the Endpoint resource includes an access address of a Pod corresponding to a Service of the kubernets cluster;
a determining unit, configured to determine, based on an access address of a Pod in the Endpoint resource, a Pod type of an available Pod that is available for traffic scheduling in the Endpoint resource, where the Pod type includes a primary Pod and a standby Pod;
the modification unit is used for modifying the Endpoint resource based on a pre-configured access control change mechanism and the Pod type of the available Pod in the Endpoint resource, wherein the Pod type of the available Pod in the Endpoint resource after modification is only a main Pod or a standby Pod;
and the Service performs flow scheduling on the available Pod based on the started access address.
8. The apparatus according to claim 7, wherein the modifying unit is specifically configured to:
removing an access address of a standby Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource simultaneously comprises a main Pod and a standby Pod;
and under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod, reserving the access address of the available Pod in the Endpoint resource.
9. An electronic device, comprising:
a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the Kubernets cluster traffic scheduling method of any of claims 1 to 6.
10. A storage medium having instructions which, when executed by a processor of an electronic device, enable the electronic device to perform the method of traffic scheduling for a kubernets cluster of any one of claims 1 to 6.
CN202011017804.4A 2020-09-24 2020-09-24 Flow scheduling method and device for Kubernetes cluster and electronic equipment Active CN112153143B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011017804.4A CN112153143B (en) 2020-09-24 2020-09-24 Flow scheduling method and device for Kubernetes cluster and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011017804.4A CN112153143B (en) 2020-09-24 2020-09-24 Flow scheduling method and device for Kubernetes cluster and electronic equipment

Publications (2)

Publication Number Publication Date
CN112153143A true CN112153143A (en) 2020-12-29
CN112153143B CN112153143B (en) 2023-04-28

Family

ID=73897895

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011017804.4A Active CN112153143B (en) 2020-09-24 2020-09-24 Flow scheduling method and device for Kubernetes cluster and electronic equipment

Country Status (1)

Country Link
CN (1) CN112153143B (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114448895A (en) * 2022-04-11 2022-05-06 苏州浪潮智能科技有限公司 Application access method, device, equipment and medium
CN115134358A (en) * 2021-03-19 2022-09-30 顺丰科技有限公司 Cross-cluster traffic forwarding method and device, computer equipment and storage medium
CN115277586A (en) * 2022-07-29 2022-11-01 中国电信股份有限公司 Method, system, equipment and storage medium for processing Pod flow
CN115361440A (en) * 2022-08-12 2022-11-18 新浪网技术(中国)有限公司 Updating method and updating device for endpoint resources of multiple Kubernetes clusters and electronic equipment
CN116033010A (en) * 2023-02-16 2023-04-28 北京有竹居网络技术有限公司 Remote access method, device, electronic equipment and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108769100A (en) * 2018-04-03 2018-11-06 郑州云海信息技术有限公司 A kind of implementation method and its device based on kubernetes number of containers elastic telescopics
WO2019179026A1 (en) * 2018-03-21 2019-09-26 平安科技（深圳）有限公司 Electronic device, method for automatically generating cluster access domain name, and storage medium
CN111274591A (en) * 2020-01-19 2020-06-12 北京百度网讯科技有限公司 Method, device, electronic equipment and medium for accessing Kubernetes cluster
CN111614738A (en) * 2020-05-07 2020-09-01 北京金山云网络技术有限公司 Service access method, device, equipment and storage medium based on Kubernetes cluster

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019179026A1 (en) * 2018-03-21 2019-09-26 平安科技（深圳）有限公司 Electronic device, method for automatically generating cluster access domain name, and storage medium
CN108769100A (en) * 2018-04-03 2018-11-06 郑州云海信息技术有限公司 A kind of implementation method and its device based on kubernetes number of containers elastic telescopics
CN111274591A (en) * 2020-01-19 2020-06-12 北京百度网讯科技有限公司 Method, device, electronic equipment and medium for accessing Kubernetes cluster
CN111614738A (en) * 2020-05-07 2020-09-01 北京金山云网络技术有限公司 Service access method, device, equipment and storage medium based on Kubernetes cluster

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115134358A (en) * 2021-03-19 2022-09-30 顺丰科技有限公司 Cross-cluster traffic forwarding method and device, computer equipment and storage medium
CN115134358B (en) * 2021-03-19 2024-04-12 顺丰科技有限公司 Cross-cluster traffic forwarding method and device, computer equipment and storage medium
CN114448895A (en) * 2022-04-11 2022-05-06 苏州浪潮智能科技有限公司 Application access method, device, equipment and medium
CN114448895B (en) * 2022-04-11 2022-06-17 苏州浪潮智能科技有限公司 Application access method, device, equipment and medium
WO2023197874A1 (en) * 2022-04-11 2023-10-19 苏州浪潮智能科技有限公司 Application access method and apparatus, and device and medium
CN115277586A (en) * 2022-07-29 2022-11-01 中国电信股份有限公司 Method, system, equipment and storage medium for processing Pod flow
CN115361440A (en) * 2022-08-12 2022-11-18 新浪网技术(中国)有限公司 Updating method and updating device for endpoint resources of multiple Kubernetes clusters and electronic equipment
CN116033010A (en) * 2023-02-16 2023-04-28 北京有竹居网络技术有限公司 Remote access method, device, electronic equipment and storage medium

Also Published As

Publication number Publication date
CN112153143B (en) 2023-04-28

Similar Documents

Publication Publication Date Title
CN112153143B (en) Flow scheduling method and device for Kubernetes cluster and electronic equipment
CN107391320B (en) Consensus method and device
CN110659988B (en) Parallel processing method and device for block chain consensus and execution and electronic equipment
RU2731331C1 (en) Consensus method and device based on blockchain
CN108648078B (en) Transaction preprocessing method and device and electronic equipment
US10999060B2 (en) Data processing method and apparatus
JP2020508594A (en) Service processing and consensus methods and devices
CN113840012B (en) Block chain-based screen recording evidence obtaining method and system and electronic equipment
CN110708163B (en) Block chain consensus method, device and system and electronic equipment
CN110020859B (en) Parallel execution block chain consensus method and device and electronic equipment
CN109391512B (en) Service publishing method and device and electronic equipment
US20190158626A1 (en) Method, apparatus and computer readable storage medium for processing service
CN111369358B (en) Block chain consensus method and device and electronic equipment
CN110442481B (en) Service processing method, service component container and electronic equipment
CN113205416A (en) Service processing method and system based on block chain prediction machine
CN112433863A (en) Micro-service calling method and device, terminal equipment and storage medium
CN111694639A (en) Method and device for updating address of process container and electronic equipment
CN111651467A (en) Block chain link point interface issuing and calling method and device
CN116933886B (en) Quantum computing execution method, quantum computing execution system, electronic equipment and storage medium
CN112751935A (en) Request processing method and device, electronic equipment and storage medium
CN111159298B (en) Service request processing method and device, electronic equipment and storage medium
CN111400690A (en) Biological verification method and device
CN110609707B (en) Online data processing system generation method, device and equipment
CN114285903B (en) Request processing method, device and system and electronic equipment
CN111258873B (en) Test method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TA01 Transfer of patent application right

Effective date of registration: 20230417

Address after: Room 501-502, 5/F, Sina Headquarters Scientific Research Building, Block N-1 and N-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Applicant after: Sina Technology (China) Co.,Ltd.

Address before: 100193 7th floor, scientific research building, Sina headquarters, plot n-1, n-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Applicant before: Sina.com Technology (China) Co.,Ltd.

TA01 Transfer of patent application right