CN112153143B - Flow scheduling method and device for Kubernetes cluster and electronic equipment - Google Patents
Flow scheduling method and device for Kubernetes cluster and electronic equipment Download PDFInfo
- Publication number
- CN112153143B CN112153143B CN202011017804.4A CN202011017804A CN112153143B CN 112153143 B CN112153143 B CN 112153143B CN 202011017804 A CN202011017804 A CN 202011017804A CN 112153143 B CN112153143 B CN 112153143B
- Authority
- CN
- China
- Prior art keywords
- pod
- endpoint resource
- available
- access address
- standby
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 230000008859 change Effects 0.000 claims abstract description 66
- 230000007246 mechanism Effects 0.000 claims abstract description 29
- 238000012795 verification Methods 0.000 claims description 62
- 238000012544 monitoring process Methods 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims 1
- 230000004048 modification Effects 0.000 description 13
- 238000012986 modification Methods 0.000 description 13
- 238000012545 processing Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 9
- 238000010606 normalization Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application discloses a flow scheduling method, a flow scheduling device and electronic equipment of a Kubernetes cluster, which can realize flow scheduling in a main mode and a standby mode in Service. The method comprises the following steps: acquiring an Endpoint resource of the Kubernetes cluster, wherein the Endpoint resource comprises an access address of a Pod corresponding to a Service of the Kubernetes cluster; determining the Pod type of the 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 preconfigured change admission control 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 the 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
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for scheduling traffic of Kubernetes clusters, and an electronic device.
Background
The current Kubernetes cluster mainly adopts a polling flow scheduling mode, service obtains the load condition of Pod by polling Pod corresponding to the back end, and then schedules access flow from outside the Kubernetes cluster to corresponding Pod based on the load condition of Pod. In this way, if a part of Pod is hung up or restarted, the processing of the access traffic is interrupted.
In view of this, there is a need for a solution that can implement traffic scheduling in the active-standby mode.
Disclosure of Invention
The embodiment of the application provides a flow scheduling method, a flow scheduling device and electronic equipment of a Kubernetes cluster, which can realize flow scheduling in a main mode and a standby mode in Service.
In order to solve the technical problems, the following technical solutions are adopted in the embodiments of the present application:
in a first aspect, an embodiment of the present application provides a method for traffic scheduling of Kubernetes clusters, where the method includes:
acquiring an Endpoint resource of the Kubernetes cluster, wherein the Endpoint resource comprises an access address of a Pod corresponding to a Service of the Kubernetes cluster;
determining the Pod type of the 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 preconfigured change admission control 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 traffic scheduling on the available Pod by the Service based on the started access address.
Optionally, modifying the Endpoint resource based on the Pod type of the available Pod in the Endpoint resource, where the Pod type of the available Pod in the modified Endpoint resource is only a primary Pod or a backup Pod, including:
modifying the Endpoint resource based on a preconfigured change admission control 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 the method comprises the following steps:
removing the access address of the standby Pod in the Endpoint resource by a change admission controller under the condition that the Pod type of the available Pod in the Endpoint resource comprises the main Pod and the standby Pod at the same time;
and reserving the access address of the available Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod.
Optionally, before modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of a Pod available in the Endpoint resource, the method further comprises:
detecting whether the Endpoint resource contains an access address of a standby Pod;
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 a Pod available 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.
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 tag of the Service contains an access address of a standby Pod;
if the tag contains the access address of the standby Pod, carrying out normative verification on the access address of the standby Pod in the tag;
And if the access address of the standby Pod in the tag passes the normative verification, determining that the Service passes the verification.
Optionally, starting the access address of the available Pod in the modified Endpoint resource includes:
under the condition that the Pod types of the available pods in the modified Endpoint resource are only standby pods and the number of standby pods is a plurality of, selecting a target Pod for flow scheduling from the plurality of available pods contained in the modified Endpoint resource based on the flow size to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting the access address of the target Pod;
and under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the main Pod, starting the access addresses of all the available Pods in the Endpoint resource.
In a second aspect, an embodiment of the present application provides a traffic scheduling device of a Kubernetes cluster, where the device includes:
an Endpoint resource obtaining unit, configured to obtain Endpoint resources of the Kubernetes cluster, where the Endpoint resources include access addresses of Pod corresponding to Service of the Kubernetes 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 in the Endpoint resource that is used for traffic scheduling, where the Pod type includes a primary Pod and a backup Pod;
A modifying unit, configured to modify the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, where the Pod type of the available Pod in the modified Endpoint resource is only a primary Pod or a backup Pod;
and the starting unit is used for starting the access address of the available Pod in the modified Endpoint resource, and the Service performs flow scheduling on the available Pod based on the started access address.
Optionally, the modification unit is specifically configured to:
removing the access address of the standby Pod in the Endpoint resource by a change admission controller under the condition that the Pod type of the available Pod in the Endpoint resource comprises the main Pod and the standby Pod at the same time;
and reserving the access address of the available Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod.
Optionally, the apparatus further comprises a change admission checking unit;
the change admittance verification unit is specifically configured to:
detecting whether the Endpoint resource contains an access address of a standby Pod;
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 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 Service of the Kubernetes cluster;
and the verification admission verification unit is used for verifying the Service based on a pre-configured verification admission control mechanism and triggering the modification unit under the condition that the Service is confirmed to pass the verification.
Optionally, the verification admission verification unit is specifically configured to:
detecting whether the tag of the Service contains an access address of a standby Pod;
if the tag contains the access address of the standby Pod, carrying out normative verification on the access address of the standby Pod in the tag;
and if the access address of the standby Pod in the tag 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 standby pods is a plurality of, determining a target Pod for flow scheduling from a plurality of available pods contained in the modified Endpoint resource based on the flow size to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting the access address of the target Pod;
And under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the main Pod, starting the access addresses of all the available Pods in the Endpoint resource.
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 Kubernetes clusters 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 are executed by a processor of an electronic device, so that the electronic device can perform the traffic scheduling method of the Kubernetes cluster in the first aspect.
The above-mentioned at least one technical scheme that this application embodiment adopted can reach following beneficial effect:
by the flow scheduling method of the Kubernetes cluster, service and corresponding Pod running conditions in the Kubernetes cluster can be obtained by acquiring the Endpoint resources of the Kubernetes cluster; by using a preconfigured change admission mechanism to check and modify an Endpoint resource, the Pod type of an available Pod in the modified Endpoint resource is only a main Pod or a standby Pod, and an access address of the available Pod in the Endpoint resource is further started, so that only the main Pod or the standby Pod corresponding to Service can operate, further, service can only schedule external traffic to the corresponding main Pod or standby Pod, and flexible use of the main and standby modes in Service for traffic scheduling is realized.
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 embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:
fig. 1 is a flowchart of a flow scheduling method of a Kubernetes cluster provided in an embodiment of the present application;
fig. 2 is a schematic diagram of a flow scheduling process of a Kubernetes cluster according to an embodiment of the present application;
fig. 3 is a flowchart of another flow scheduling method of Kubernetes clusters provided in an embodiment of the present application;
fig. 4 is a flowchart of another flow scheduling method of Kubernetes clusters provided in an embodiment of the present application;
fig. 5 is a flowchart of another flow scheduling method of Kubernetes clusters provided in an embodiment of the present application;
fig. 6 is a schematic structural diagram of a flow scheduling device of a Kubernetes cluster according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.
Example 1
The embodiment of the application provides a flow scheduling method of a Kubernetes cluster, which can be used for performing flow scheduling switching of a main mode and a standby mode in Service of the Kubernetes cluster according to the running condition of Pod of a rear end corresponding to Service so as to avoid the problem caused by flow processing interruption. The method can be applied to an API (Application Programming Interface, application program interface) Server (or an API Server) of the Kubernetes cluster. As shown in fig. 1, the method comprises the steps of:
s12, acquiring an Endpoint resource of the Kubernetes cluster.
The Endpoint resource includes an access address of a Pod corresponding to Service of the Kubernetes cluster.
Specifically, an Endpoint is a resource object in the Kubernetes cluster, and is stored in the ETCD of the Kubernetes cluster, so as to record access addresses of all Pod corresponding to a Service. The Endpoint Controller component in the Kubernetes cluster creates a corresponding Endpoint for Service, listens for changes in Service and corresponding Pod, and updates the Endpoint according to the changes in Service and corresponding Pod, thereby obtaining an Endpoint resource.
S14, determining the Pod type of the available Pod in the Endpoint resource for traffic scheduling based on the access address of the Pod in the Endpoint resource.
The Pod type comprises a main Pod and a standby Pod. And the Service dispatches the access flow to any one or more Pods for processing, wherein the one or more Pods in process serve as the main Pod corresponding to the Service, and other Pods corresponding to the Service serve as the standby Pods of the current main Pod.
Specifically, the access address of the standby Pod in the Kubernetes cluster can be preset, after the Endpoint resource is acquired, the access address of the available Pod for traffic scheduling can be read from the subset of the Endpoint resource, and the access address of the available Pod is respectively compared with the access address of the preset standby Pod, so that the Pod type of the available Pod of the Endpoint resource is determined.
S16, modifying the Endpoint resource based on a preconfigured change admission control 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.
In particular, the change admission mechanism may be built into a resource object, such as a MutatingWebhookConfiguration of a Kubernetes cluster, whose definition may include, but is not limited to: a namespace in which a mutandis Webhook service resides, a Webhook request path, base64 encoding of CA certificates, a change matching rule indicating Kubernetes resources of a change admission controller (Mutating Admission Controller) that can enter an API Server, etc. For example, the matching rule may be: endpoint resources with keys of "end-point-extension" and values of "end-point-backup-ip" labels enter the change admission controller.
As shown in FIG. 2, the change admission controller may verify an Endpoint resource based on a mutatingWebHookConfiguration, and if the Endpoint resource meets the change matching rules defined in the mutatingWebHookConfiguration, the change admission controller may interact with Mutating Admission Webhook services based on the Endpoint resource to modify the Endpoint resource, and store the modified Endpoint resource in the ETCD. Wherein the admission controller and Mutating Admission Webhook service interact in the manner of HTTPS (Hyper Text Transfer Protocol Over Secure Socket, hypertext transfer security protocol).
Specifically, the change admission controller may delete or reserve the access address containing the 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 the primary Pod or the backup Pod, and further, only the primary Pod or the backup Pod can be scheduled by Service.
In the case that the Pod type of the available Pod in the Endpoint resource is only the standby Pod, the main Pod is not available and only the standby Pod is available in the Pod corresponding to Service. At this point, the change admission controller does not need to modify the Endpoint resources.
In the case that the Pod type of the available Pod in the Endpoint resource includes both a primary Pod and a backup Pod, both the primary Pod and the backup Pod corresponding to 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 will not be scheduled to traffic.
Under the condition that no Pod is available in the Endpoint resource, the main Pod and the standby Pod corresponding to Service are not available, and at this time, the change admission controller does not need to modify the Endpoint resource.
In the case that the Pod type of the available Pod in the Endpoint resource is only the primary Pod, that is, the primary Pod corresponding to Service is available, the change admission controller does not need to modify the Endpoint resource.
S18, starting access addresses of available Pods in the modified Endpoint resources, and performing traffic scheduling on the available Pods by Service based on the started access addresses.
In an alternative scheme, under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the main Pod, the access addresses of all the 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, and the traffic distributed by the main Pod is still processed by Service, so that the continuity of traffic scheduling is ensured.
Under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the standby Pod, the access addresses of all the pods can be started, at this time, service can forward the external access traffic of the Kubernetes cluster to the standby Pod, and the standby Pod processes the external access traffic, so that the problem of access traffic processing interruption caused by the unavailability of the main Pod can be avoided.
Considering that when the number of standby Pod is large and the traffic to be scheduled is small, if all standby Pod is started, the situation that part of standby Pod is in idle state may occur, and the running of standby Pod in idle state may cause resource waste. To solve this problem, in a more preferred solution, in a case where the types of available pods in the modified Endpoint resource are only standby pods and the number of standby pods is multiple, a target Pod for traffic scheduling may be determined from the multiple available pods contained in the modified Endpoint resource based on the load capability and the traffic size to be scheduled of each available Pod contained in the modified Endpoint resource, and an access address of the target Pod may be started. The load capacity of the Pod is used to characterize the flow that the Pod can carry, and can be determined based on the capacity of the Pod and other performance related parameters.
Of course, in other preferred schemes, the access addresses of the available Pod can be started in turn according to the weight corresponding to each available Pod in the Endpoint resource, or the access addresses of the available Pod with the weight exceeding the preset weight can be started. The weight corresponding to the available Pod can be set in a self-defined manner according to actual needs.
By the flow scheduling method of the Kubernetes cluster, service and corresponding Pod running conditions in the Kubernetes cluster can be obtained by acquiring the Endpoint resources of the Kubernetes cluster; by using a preconfigured change admission mechanism to check and modify an Endpoint resource, the Pod type of an available Pod in the modified Endpoint resource is only a main Pod or a standby Pod, and an access address of the available Pod in the Endpoint resource is further started, so that only the main Pod or the standby Pod corresponding to Service can operate, further, service can only schedule external traffic to the corresponding main Pod or standby Pod, and flexible use of the main and standby modes in Service for traffic scheduling is realized.
In order to enable those skilled in the art to better understand the technical solution provided by the embodiments of the present application, a flow scheduling manner of the Kubernetes cluster provided by the embodiments of the present application is described in detail below.
In an alternative scheme, considering that the access address of the standby Pod is contained in the Endpoint resource, the switching of the primary and standby traffic scheduling modes can be realized in Service, and in order to ensure the realization of the primary and standby traffic scheduling modes, it is also required 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: detecting whether the Endpoint resource contains the access address of the standby Pod, if so, 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 passes the normative verification. After determining that the access address of the standby Pod in the Endpoint resource passes the normalization check, step S16 is executed.
Specifically, as shown in fig. 3, the change admission controller may determine whether the acquired Endpoint resource meets the matching rule based on the matching rule defined in the mutatingwebhook configuration resource, and if yes, carry the acquired Endpoint resource in a POST request and send the POST request to a URL corresponding to the change admission Webhook service (Mutating Admission Webhook service). After receiving the POST request from the change admission controller, the change admission Webhook service requests JSON data related to the Endpoint resources contained in the BODY and performs deserialization operation on the JSON data. If the deserialization operation fails, the change admittance Webhook service returns a notification message of the modification failure to the change admittance controller so as to indicate the change admittance controller not to modify the Endpoint resource; if the deserialization operation is successful, the change admission Webhook service acquires label information of the Endpoint resource, and acquires an access address (such as an IP address) of the standby Pod based on the label. Then, the change admission Webhook service performs normalization verification on the access address of the acquired standby Pod, for example, verifies whether the access address meets the address specification, whether there is a corresponding separator, and the like. If the access address of the standby Pod does not pass the normalization check, the change admittance Webhook service returns a notification message of failure in modification to the change admittance controller so as to indicate that the change admittance controller does not modify the Endpoint resource; if the access address of the standby Pod passes the normalization check, the change admission Webhook service further judges whether the Subsets of the Endpoint resource contain the access address.
Under the condition that the Subsets do not contain any access address, at this time, it can be determined that the Pod corresponding to Service is not available, and the change admission Webhook Service can return a notification message of modification failure to the change admission controller so as to instruct the change admission controller not to modify the Endpoint resource.
In the case that the Subsets only include access addresses of the standby Pod, it may be determined that the primary Pod corresponding to Service is unavailable and only the standby Pod is available at this time, and the change admission Webhook Service may return a notification message for passing the modification to the change admission controller to instruct the change admission controller to start the access address included in the Subsets. Accordingly, in the 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, and further, the continuity of the access traffic processing may be ensured.
In the case that the Subsets include the access address of the primary Pod and the access address of the backup Pod, it may be determined that both the primary Pod and the backup Pod corresponding to Service are available at this time, and further, the change admission Webhook Service may generate a corresponding modification request based on the access address of the backup 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 described above, the change admission controller may delete the access address of the standby Pod included in the Subsets of the Endpoint resource based on the modification request. In step S18 described above, the change admission controller initiates the access address of the available Pod in the modified Endpoint resource. Because the available Pod in the modified Endpoint resource is only the main Pod, the Pod corresponding to Service is not started, and Service still schedules the access traffic to the main Pod for processing, thereby realizing the traffic scheduling mode of the main mode.
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, the access address which is started subsequently can be ensured to be effective, and the stability and the safety of the flow scheduling process of the Kubernetes cluster are ensured; after the access address of the standby Pod passes the normalization verification, the access address and the type of the available Pod which are corresponding to the Service and can be used for flow scheduling are determined based on the access address contained in the Subsets under the Endpoint resource, so that the logic is simple, and the convenience of flow scheduling of the Kubernetes cluster is improved.
Example 2
The embodiment of the application also provides another flow scheduling method of the Kubernetes cluster, and the embodiment is further improved on the basis of the embodiment 1, and the specific improvement is that: before the step S14, service of the Kubernetes cluster may also be checked, and it is determined that Service passes the check. As shown in fig. 4, the traffic scheduling method of the Kubernetes cluster in the embodiment of the present 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, step S52 is substantially the same as step S18 in embodiment 1, and details of the traffic scheduling method of the Kubernetes cluster provided in embodiment 1 will not be described herein again, and the differences will mainly be described below, but technical details not described in detail in the embodiment will be referred to herein again.
S42, acquiring Endpoint resources of the Kubernetes cluster.
S44, monitoring Service of the Kubernetes cluster.
In particular, endpoint Controller components in the Kubernetes cluster would snoop for changes in Service.
S46, checking the Service based on a pre-configured verification admission control mechanism.
Specifically, the authentication admission control mechanism may be built in a resource object, namely ValidatingWebhookConfiguration of Kubernetes cluster, and the defined content may include, but is not limited to: validatingAdmissionWebhook service (authentication admission Webhook service) is located in a namespace, webhook request path, base64 encoding of CA certificates, matching rules indicating Kubernetes resources of an authentication admission controller (Validating Admission Controller) that can enter an API Server, etc. For example, the matching rule may be: service with key "end-extension" and value "end-point-backup-ip" label enters the authentication admission controller.
As shown in fig. 2, the authentication admission controller may verify a Service based on validating Webhook configuration, and if the Service meets a matching rule defined in validating Webhook configuration, the authentication admission controller may interact with Validating Admission Webhook Service (authentication admission Webhook Service) based on the Service to further verify the Service, and store it in ETCD after the Service passes the verification. Wherein the authentication admission controller and Validating Admission Webhook service interact in an HTTPS manner.
S48, under the condition that Service passes verification, determining the Pod type of the available Pod in the Endpoint resource, which can be used for traffic scheduling, based on the access address of the Pod in the Endpoint resource.
S50, modifying the Endpoint resource based on a preconfigured change admission control 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.
S52, starting access addresses of available Pods in the modified Endpoint resources, and performing traffic scheduling on the available Pods by Service based on the started access addresses.
It can be understood that, by introducing the verification admission control mechanism into the Kubernetes cluster according to the flow scheduling scheme of the Kubernetes cluster provided by the embodiment, before verifying and modifying the Endpoint resource based on the change admission control mechanism, service of the Kubernetes cluster is verified, and Service passing verification is determined, so that Service effectiveness can be ensured, and stability and safety of flow scheduling of the Kubernetes cluster are further improved.
In an alternative solution, the step S46 may include: detecting whether a tag of Service in the acquired Service contains an access address of a standby Pod, if the tag contains the access address of the standby Pod, performing normalization check on the access address of the standby Pod in the tag, and if the access address of the standby Pod in the tag passes the normalization check, determining that the Service passes the check.
Specifically, as shown in fig. 5, the authentication admission controller may determine whether the acquired Service originally accords with the matching rule based on the matching rule defined in the validatingwebhook configuration resource, and if so, carry the acquired Service information in the POST request and send the POST request to the URL corresponding to the Validating Admission Webhook Service (authentication admission Webhook Service). After receiving the POST request from the authentication admission controller, the authentication admission Webhook Service requests JSON data related to Service contained in the BODY, and performs deserialization operation on the JSON data, that is, deserialization operation on Service information. If the deserialization operation fails, the verification admission Webhook service returns a notification message of verification failure to the verification admission controller; if the deserialization operation is successful, verifying the admission Webhook Service, acquiring the name and the label information of Service, judging whether the acquired label information has a label with the key of 'end-extension' and the value of 'end-backup-ip', if so, further judging whether a 'backup IP' label exists, and if so, acquiring the access address of the corresponding standby Pod through the label. Then, the verification admission Webhook service performs normalization verification on the access address of the acquired standby Pod, for example, verification on whether the access address meets the address specification, whether the access address has a corresponding separator or not, and the like. If the access address fails the normative check, the verification admission Webhook service returns a notification message of check failure to the verification admission controller; if the access address passes the normative check, the authentication admission Webhook service returns a notification message of successful check to the authentication admission controller.
It can be understood that in the above scheme, by performing normative verification on the access address of the standby Pod contained in the Service tag, the access address which is started subsequently can be ensured to be effective, so that the stability and safety of the flow scheduling process of the Kubernetes cluster are ensured, the implementation logic is simple, and the convenience of flow scheduling of the Kubernetes cluster is improved.
It should be noted that, in the above embodiment of the present application, in order to improve the security of interaction between the admission controller (including the change admission controller and the verification admission controller) and its corresponding admitted Webhook service (including the change admission Webhook service and the verification admission Webhook service), TLS (Transport Layer Security, secure transport layer protocol) authentication may also be performed during the interaction between the two. Specifically, a CA certificate and a CA private key may be generated, a private key of a Webhook service may be generated, a CSR (Certificate Sign Request, certificate signing request) may be generated for the private key of the Webhook service, a Base64 encoding of the CA certificate, etc., so that interaction between the admission controller and its corresponding admitted Webhook service may be performed based on these generated data.
It should be noted that the foregoing describes specific embodiments of the present invention. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can 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 are also possible or may be advantageous.
Example 3
Referring to fig. 6, the embodiment of the present application further provides a flow scheduling apparatus 600 of a Kubernetes cluster, where the apparatus 600 may be applied to an API Server of the Kubernetes cluster. As shown in fig. 6, the apparatus 600 may include:
an Endpoint resource obtaining unit 610, configured to obtain Endpoint resources of the Kubernetes cluster, where the Endpoint resources include access addresses of Pod corresponding to Service of the Kubernetes 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 in the Endpoint resource that is used for traffic scheduling, where the Pod type includes a primary Pod and a backup Pod.
And a modifying unit 630, configured to modify the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, where the Pod type of the available Pod in the modified Endpoint resource is only a primary Pod or a backup Pod.
And a starting unit 640, configured to start an access address of an available Pod in the modified Endpoint resource, where the Service performs traffic scheduling on the available Pod based on the started access address.
Optionally, the modifying unit 630 is specifically configured to:
Removing the access address of the standby Pod in the Endpoint resource by a change admission controller under the condition that the Pod type of the available Pod in the Endpoint resource comprises the main Pod and the standby Pod at the same time;
and reserving the access address of the available Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod.
Optionally, the apparatus further comprises a change admission checking unit;
the change admittance verification unit is specifically configured to:
detecting whether the Endpoint resource contains an access address of a standby Pod;
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 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 Kubernetes cluster.
And the verification admission verification unit is used for verifying the Service based on a pre-configured verification admission control mechanism and triggering the modification unit under the condition that the Service is confirmed to pass the verification.
Optionally, the verification admission verification unit is specifically configured to:
detecting whether the tag of the Service contains an access address of a standby Pod;
if the tag contains the access address of the standby Pod, carrying out normative verification on the access address of the standby Pod in the tag;
and if the access address of the standby Pod in the tag 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 standby pods is a plurality of, determining a target Pod for flow scheduling from a plurality of available pods contained in the modified Endpoint resource based on the flow size to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting the access address of the target Pod;
and under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the main Pod, starting the access addresses of all the available Pods in the Endpoint resource.
Example 4
Referring to fig. 7, an embodiment of the present application further provides an electronic device. Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Referring to fig. 7, at the hardware level, the electronic device includes a processor, and optionally 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 (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, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 7, but not only one bus or type of bus.
And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.
The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs, and the flow scheduling device of the Kubernetes cluster is formed on a logic level. The processor is used for executing the programs stored in the memory and is specifically used for executing the following operations:
acquiring an Endpoint resource of the Kubernetes cluster, wherein the Endpoint resource comprises an access address of a Pod corresponding to a Service of the Kubernetes cluster;
Determining the Pod type of the 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 preconfigured change admission control 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 traffic scheduling on the available Pod by the Service based on the started access address.
The method executed by the flow scheduling device of the Kubernetes cluster disclosed in the embodiment shown in fig. 1 of the present application may be applied to a processor or implemented by the 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 by instructions in the form of software. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The disclosed methods, steps, and logic blocks 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 a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.
The electronic device may further execute the method of fig. 1 and implement the functions of the flow scheduling device of the Kubernetes cluster in the embodiment shown in fig. 1, which is not described herein again.
Of course, other implementations, such as a logic device or a combination of hardware and software, are not excluded from the electronic device of the present application, that is, the execution subject of the following processing flow is not limited to each logic unit, but may be hardware or a logic device.
The present embodiments also provide a computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a portable electronic device comprising a plurality of application programs, enable the portable electronic device to perform the method of the embodiment of fig. 1, and in particular to:
acquiring an Endpoint resource of the Kubernetes cluster, wherein the Endpoint resource comprises an access address of a Pod corresponding to a Service of the Kubernetes cluster;
determining the Pod type of the 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 preconfigured change admission control 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 traffic scheduling on the available Pod by the Service based on the started access address.
In summary, the foregoing 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, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, 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 storage media for a computer 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, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
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 one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
Claims (10)
1. A method for traffic scheduling of Kubernetes clusters, the method comprising:
acquiring an Endpoint resource of the Kubernetes cluster, wherein the Endpoint resource comprises an access address of a Pod corresponding to a Service of the Kubernetes cluster;
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, wherein the Pod type comprises a main Pod and a standby Pod;
modifying the Endpoint resource based on a preconfigured change admission control 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 traffic scheduling on the available Pod by the Service based on the started access address.
2. The method of claim 1, wherein modifying the Endpoint resource based on a preconfigured admission control mechanism and a Pod type of available pods in the Endpoint resource, the Pod type of available pods in the modified Endpoint resource being either primary Pod or backup Pod only, comprising:
removing the access address of the standby Pod in the Endpoint resource by a change admission controller under the condition that the Pod type of the available Pod in the Endpoint resource comprises the main Pod and the standby Pod at the same time;
and reserving the access address of the available Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod.
3. The method of claim 1, wherein prior to modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of a Pod available in the Endpoint resource, the method further comprises:
detecting whether the Endpoint resource contains an access address of a standby Pod;
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 prior to modifying the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of a Pod available 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 authentication admission control mechanism and determining that the Service passes the verification comprises:
detecting whether the tag of the Service contains an access address of a standby Pod;
if the tag contains the access address of the standby Pod, carrying out normative verification on the access address of the standby Pod in the tag;
and if the access address of the standby Pod in the tag passes the normative verification, determining that the Service passes the verification.
6. The method of claim 1, wherein initiating the access address of the 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 standby pods is a plurality of, determining a target Pod for flow scheduling from a plurality of available pods contained in the modified Endpoint resource based on the flow size to be scheduled and the load capacity of each available Pod in the modified Endpoint resource, and starting the access address of the target Pod;
And under the condition that the Pod type of the available Pod in the modified Endpoint resource is only the main Pod, starting the access addresses of all the available Pods in the Endpoint resource.
7. A traffic scheduling device of a Kubernetes cluster, the device comprising:
an Endpoint resource obtaining unit, configured to obtain Endpoint resources of the Kubernetes cluster, where the Endpoint resources include access addresses of Pod corresponding to Service of the Kubernetes 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 in the Endpoint resource that is available for traffic scheduling, where the Pod type includes a primary Pod and a backup Pod;
a modifying unit, configured to modify the Endpoint resource based on a preconfigured change admission control mechanism and a Pod type of an available Pod in the Endpoint resource, where the Pod type of the available Pod in the modified Endpoint resource is only a primary Pod or a backup Pod;
and the starting unit is used for starting the access address of the available Pod in the modified Endpoint resource, 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 the access address of the standby Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource comprises the main Pod and the standby Pod simultaneously;
and reserving the access address of the available Pod in the Endpoint resource under the condition that the Pod type of the available Pod in the Endpoint resource is only a main Pod or a standby Pod.
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 method of traffic scheduling of Kubernetes clusters according to any one of claims 1 to 6.
10. A storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform the method of traffic scheduling of Kubernetes clusters according to any one of claims 1 to 6.
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 CN112153143A (en) | 2020-12-29 |
| CN112153143B true 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) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115134358B (en) * | 2021-03-19 | 2024-04-12 | 顺丰科技有限公司 | Cross-cluster traffic forwarding method and device, computer equipment and storage medium |
| CN114185558A (en) * | 2021-12-16 | 2022-03-15 | 华云数据控股集团有限公司 | Native application master selection method and device based on K8s and storage medium |
| CN114281476A (en) * | 2021-12-21 | 2022-04-05 | 中国—东盟信息港股份有限公司 | Kubernetes cloud native cluster resource deletion protection method, device, equipment and storage medium |
| CN114448895B (en) * | 2022-04-11 | 2022-06-17 | 苏州浪潮智能科技有限公司 | Application access method, device, equipment and medium |
| CN115277586B (en) * | 2022-07-29 | 2024-07-23 | 中国电信股份有限公司 | Pod flow processing method, system, equipment and storage medium |
| CN115361440B (en) * | 2022-08-12 | 2024-06-18 | 新浪技术（中国）有限公司 | Method and device for updating endpoint resources of multiple Kubernetes clusters and electronic equipment |
| CN115714747B (en) * | 2022-12-13 | 2024-07-26 | 重庆紫光华山智安科技有限公司 | Method, device, system and medium for optimizing cluster internal network flow based on Kubernetes |
| CN116033010B (en) * | 2023-02-16 | 2024-10-29 | 北京有竹居网络技术有限公司 | Remote access method, device, electronic equipment and storage medium |
Citations (4)
| 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 |
-
2020
- 2020-09-24 CN CN202011017804.4A patent/CN112153143B/en active Active
Patent Citations (4)
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112153143A (en) | 2020-12-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112153143B (en) | Flow scheduling method and device for Kubernetes cluster and electronic equipment | |
| CN108648078B (en) | Transaction preprocessing method and device and electronic equipment | |
| CN113840012B (en) | Block chain-based screen recording evidence obtaining method and system and electronic equipment | |
| US20200136804A1 (en) | Data processing method and apparatus | |
| CN110020859B (en) | Parallel execution block chain consensus method and device and electronic equipment | |
| CN110708163B (en) | Block chain consensus method, device and system and electronic equipment | |
| CN111369358B (en) | Block chain consensus method and device and electronic equipment | |
| CN110442481B (en) | Service processing method, service component container and electronic equipment | |
| CN111651467B (en) | Block chain node interface issuing and calling method and device | |
| CN113205416A (en) | Service processing method and system based on block chain prediction machine | |
| CN111694639A (en) | Method and device for updating address of process container and electronic equipment | |
| CN112751935B (en) | Request processing method and device, electronic equipment and storage medium | |
| CN112437155B (en) | Service data processing method and device and server device | |
| CN108541000B (en) | Method, medium and device for detecting network connection | |
| CN111159298B (en) | Service request processing method and device, electronic equipment and storage medium | |
| CN111400690B (en) | Biological verification method and device | |
| CN114285903B (en) | Request processing method, device and system and electronic equipment | |
| CN113706146B (en) | Processing method, device and system for executing batch transactions based on blockchain | |
| CN111242778B (en) | Data processing method, device, computer equipment and storage medium | |
| CN111651469B (en) | Method and device for managing blockchain system contracts | |
| CN110535785B (en) | Control method and device for sending frequency and distributed system | |
| CN112637201A (en) | Request processing method, device, equipment and system of web server | |
| CN111209593A (en) | Block chain-based distributed lock processing method, related device and electronic equipment | |
| CN112437192A (en) | Installation method and running method of application software, electronic equipment and computer readable medium | |
| CN111383025B (en) | Method and device for forwarding wind control data and electronic equipment |
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 | ||
| 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. |