CN117596248A - Method and device for switching traffic across available areas, electronic equipment, chip and medium - Google Patents

Method and device for switching traffic across available areas, electronic equipment, chip and medium Download PDF

Info

Publication number
CN117596248A
CN117596248A CN202311605451.3A CN202311605451A CN117596248A CN 117596248 A CN117596248 A CN 117596248A CN 202311605451 A CN202311605451 A CN 202311605451A CN 117596248 A CN117596248 A CN 117596248A
Authority
CN
China
Prior art keywords
available
available area
ingress
node
area
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.)
Pending
Application number
CN202311605451.3A
Other languages
Chinese (zh)
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.)
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software Technology 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 China Mobile Communications Group Co Ltd, China Mobile Suzhou Software Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202311605451.3A priority Critical patent/CN117596248A/en
Publication of CN117596248A publication Critical patent/CN117596248A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The disclosure provides a method, a device, electronic equipment, a chip and a medium for switching flow across available areas, and relates to the technical field of cloud computing. The flow switching method across the available area comprises the following steps: monitoring the K8s object, and binding the K8s object to load balancers of different available areas; monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, and determining whether the first available area is available; and if the first available area is not available, forwarding the traffic of the first available area to the second available area. By the technical scheme provided by the disclosure, the problem that K8s spans multiple available areas, the corresponding service cannot be dynamically selected according to the strategy by the ingress nginx is solved, manual operation is reduced, and the flow forwarding times are reduced.

Description

Method and device for switching traffic across available areas, electronic equipment, chip and medium
Technical Field
The disclosure relates to the field of cloud computing, and in particular relates to a method, a device, electronic equipment, a chip and a medium for switching traffic across available areas.
Background
At present, K8s has become a fact standard in the field of Cloud protogenesis, many companies also migrate their own services to a K8s cluster, services (services) in K8s provide 4-layer access capability, which is mainly three types, namely, cluster internet protocol (ClusterIP), node port (NodePort) and load balancing (LoadBalance) types, wherein the services of the ClusterIP type can only be accessed inside the cluster, the services of the NodePort type can be accessed by a host and an exposed port, the services of the LoadBalance type need to subscribe to LoadBalance instances on public clouds, and a load balancing service corresponding to the services one by one is created for the services by a Cloud Provider (Cloud Provider). This approach is both wasteful of resource costs and high since one load balancer is required for each LoadBalance type service.
Disclosure of Invention
The invention provides a method, a device, electronic equipment, a chip and a medium for switching flow across available areas, which are used for solving the problem that K8s cannot dynamically select corresponding services according to strategies when crossing multiple available areas, automatically finding nodes, services, ingress objects and endpoint objects in a K8s cluster by using LoadBalance on public cloud as a Controller (Controller) of Ingress in K8s, updating a server into LoadBalance according to different priority groups according to set scheduling values of different available areas, enabling flow forwarding in the LoadBalance to be consistent with expected flow of Ingress finally, automatically completing access from an external network to the K8s across available areas cluster, monitoring health check information reported in the LoadBalance, automatically switching routes when judging that a certain available area is unavailable through an index distribution algorithm, and automatically switching the flow to another available area after the available area is restored. When the K8s cluster expands or contracts, nodes of expansion and contraction are automatically found, server groups in LoadBase are synchronized in real time, manual operation is reduced, and the flow forwarding times are reduced.
An embodiment of a first aspect of the present disclosure provides a method for traffic switching across available areas, where the method includes:
Monitoring the K8s object, and binding the K8s object to load balancers of different available areas;
monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, and determining whether the first available area is available;
and if the first available area is not available, forwarding the traffic of the first available area to the second available area.
In one embodiment of the present disclosure, a load balancer binding a K8s object to different available regions includes:
determining whether the K8s object is an ingress object;
if the K8s object is an ingress object, acquiring all request paths and a back-end server in an ingress rule of the ingress object;
grouping the request path and the back-end server, obtaining a node (node) of an ingress object, a service and an endpoint, and determining a first available region where the node is located;
and calling an interface of the load equalizer, creating a listener, and adding a 7-layer forwarding strategy into the listener according to the packet.
In one embodiment of the present disclosure, monitoring a health status of a backend server in a first available region to which a node of a K8s object belongs, and determining whether the first available region is available includes:
determining, by the listener, a health status of each backend server in the first available region;
And when the health states of more than half of the nodes in the first available area are invalid, determining that the first available area is not available.
In one embodiment of the present disclosure, forwarding traffic of the first available region to the second available region if the first available region is unavailable comprises:
dynamically modifying a 7-layer forwarding strategy in the load balancer;
deleting the first route of the server group in the first available area, and adding the first route in the server group route in the second available area;
and directing the path of the first route to the node corresponding to the server group in the second available area.
In one embodiment of the present disclosure, determining the health status of each back-end server in the first availability zone includes:
using an exponential distribution algorithm, taking the exponential distribution algorithm as an algorithm sample in a preset finite sequence according to a sampling success time interval, and carrying out probability calculation through N data samples to obtain the failure probability of the node in the first available region;
and when the failure probability is greater than or equal to a preset configurable value, determining that the node fails.
In one embodiment of the present disclosure, the method further comprises:
and after the health states of more than half of the nodes in the first available area recover the available states, recovering the first route in the server group in the first available area, and deleting the second route in the server group in the second available area.
In one embodiment of the present disclosure, the method further comprises:
when the node corresponding to the ingress object changes, acquiring path grouping and available area information in the changed ingress object;
and updating 7-layer forwarding strategies in different available areas in the load balancer so that a server group corresponding to the 7-layer forwarding strategies in each available area in the load balancer is consistent with the available area where the paths and nodes defined in the ingress object are located.
In one embodiment of the present disclosure, the method further comprises:
when the ingress object is deleted, an interface in the load balancer is called, and a listener, a 7-layer forwarding policy and a server group of the ingress object existing in the load balancer are deleted.
An embodiment of a second aspect of the present disclosure proposes a traffic switching device across an available area, the device comprising:
the binding module is used for monitoring the K8s object and binding the K8s object to load balancers of different available areas;
the determining module is used for monitoring the health state of a back-end server in a first available area to which the node of the K8s object belongs and determining whether the first available area is available;
and the forwarding module is used for forwarding the traffic of the first available area to the second available area if the first available area is unavailable.
An embodiment of a third aspect of the present disclosure proposes an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of the embodiments of the first aspect of the present disclosure.
An embodiment of a fourth aspect of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of the embodiment of the first aspect of the present disclosure.
A fifth aspect embodiment of the present disclosure proposes a chip comprising at least one processor and a communication interface; the communication interface is for receiving signals input to or output from the chip, and the processor communicates with the communication interface and implements the method of any of the embodiments of the first aspect of the disclosure by logic circuitry or executing code instructions.
In summary, according to the method for switching traffic across available areas provided by the present disclosure, a K8s object is monitored, and the K8s object is bound to a load balancer of different available areas, so that high availability is provided for service operation; monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, determining whether the first available area is available, realizing health monitoring of the available area, and providing a premise for flow switching; if the first available area is not available, forwarding the traffic of the first available area to the second available area ensures continuous operation and high availability of the service. Manual operation is reduced, and the number of times of traffic forwarding is reduced.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.
FIG. 1 is a schematic diagram of an external network accessing K8s through LoadBasance in the related art;
fig. 2 is a flowchart of a method for traffic switching across available areas according to an embodiment of the present disclosure;
FIG. 3 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure;
FIG. 4 is a flowchart of monitoring the health of a backend server in a first available region to which a node of a K8s object belongs and determining whether the first available region is available in accordance with an embodiment of the present disclosure;
FIG. 5 is a flow chart of forwarding traffic of a first available region to a second available region if the first available region is unavailable according to an embodiment of the present disclosure;
FIG. 6 is a flow chart of one embodiment of the present disclosure for determining the health status of each back-end server in a first availability zone;
FIG. 7 is a flow chart of forwarding traffic of a first available region to a second available region if the first available region is unavailable according to an embodiment of the present disclosure;
FIG. 8 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure;
FIG. 9 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure;
fig. 10 is a schematic diagram of LoadBalance7 layer forwarding according to an embodiment of the disclosure;
FIG. 11 is a schematic diagram of adding policies to LoadBasance by availability zones according to one embodiment of the disclosure Ingress Controller;
FIG. 12 is a schematic diagram of an IngressController and LoadBasance call relationship according to an embodiment of the disclosure;
fig. 13 is a schematic structural diagram of a flow switching device across available areas according to an embodiment of the present disclosure;
FIG. 14 is a block diagram of an electronic device for implementing a method of traffic handoff across available areas of the present disclosure, according to an example embodiment;
fig. 15 is a schematic structural diagram of a chip of an embodiment of the present disclosure.
Detailed Description
Embodiments of the present disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals identify the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and intended for the purpose of explaining the present disclosure and are not to be construed as limiting the present disclosure.
Kubernetes, abbreviated as K8s or "kube", is an open-source Linux container automation operation and maintenance platform. The system is a portable and extensible platform for managing containerized workload and services, and facilitates declarative configuration and automation. The K8s combines the containers that make up the application into a logical unit for ease of management and service discovery. Furthermore, the goal of K8s is to make deploying a containerized application simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance.
Fig. 1 is a schematic diagram of an external network accessing K8s through LoadBalance in the related art. When an ingress is created, as shown in fig. 1, an ingress class is added as an nginx, and the ingress of the ingress class is monitored as an ingress of the nginx, and is converted into a configuration of the nginx, so that the configuration is enabled. When a client accesses a Pod application, traffic is forwarded to a service of a LoadBalance corresponding to a cluster ingress nginx through a LoadBalance load balancer, the service of the ingress nginx forwards the traffic to a corresponding ingress nginx Pod, ingress nginx Pod to start an nginx service, and different paths are forwarded to different services according to a 7-layer http protocol, wherein Pod is a minimum deployable computing unit in K8s and is a minimum resource object model which can be created and managed.
The flow can be seen from the following steps: the ingress nginx needs to be reloaded after the configuration file is dynamically modified, so that the service is temporarily unavailable; when the ingress nginx receives external traffic, the traffic is forwarded to ingress nginx service to ingress nginx Pod via LoadBalance, and then forwarded by the nginx in ingress nginx Pod, and the traffic is forwarded to the Pod that actually provides service, which causes the traffic to be forwarded through multiple layers, thereby increasing network load and delay. When K8s spans multiple available areas, the ingress rginx cannot dynamically select the corresponding service according to the policy.
The services in K8s provide 4-layer access capability, which mainly comprises three types, clusterIP, nodePort and LoadBalance types, wherein the services of the ClusterIP type can only be accessed inside a cluster, the services of the NodePort type can be accessed by a host and an exposed port, the services of the LoadBalance type need to subscribe LoadBalance instances on public clouds, and a load balance service corresponding to the services one by one is created for the services through a cloudprovider. This approach is both wasteful of resource costs and high since one load balancer is required for each LoadBalance type service.
The method aims at solving the problem that K8s spans multiple available areas, the ingress nginx cannot dynamically select corresponding services according to strategies, and in the related art, a public cloud mode is generally used as an agent, and a listner and a module are required to be manually added. The method dynamically adds the K8s node to different server groups in the loadbalance according to the available area where the K8s node is located, and can dynamically switch available area flow direction according to the available state of the node, so that high availability of multi-available area K8s application is realized.
The method provided by the disclosure is applied to the traffic switching task crossing the available area, has rich scenes in application, can be used in the fields of cloud computing, cloud containers and the like, and is particularly suitable for the following scenes: content distribution, backup, storage, etc. as a way to provide Software as a service (SaaS); the financial industry forms financial products, information and services into a cloud network through a cloud computing model forming principle, so that the capability of a financial institution for discovering and solving problems is improved; the manufacturing industry can acquire manufacturing resources and services at any time according to needs through a network and a terminal, and then various activities of the manufacturing whole life cycle are completed; the education industry, including all hardware computing resources necessary for education informatization, provides a good platform for education institutions and the like after virtualization; based on new technologies such as cloud computing and big data, the medical technology is combined to construct a specific medical service platform in the medical and health field; in the game industry, in a game mode based on cloud computing, all games are run at a server side, and rendered game pictures are transmitted to a user through a network. The application scenario is not limited in the embodiments of the present disclosure.
The following describes in detail the method for switching traffic across available areas provided in the present application with reference to the accompanying drawings.
Fig. 2 is a flowchart of a method for traffic switching across available areas according to an embodiment of the present disclosure. As shown in the embodiment of fig. 2, the method for switching traffic across the available area includes:
step 201, listening for the K8s object and binding the K8s object to the load balancer of different available areas.
In this embodiment, the K8s object, i.e., the container orchestration system (Kubernetes) object, is a persistent entity in Kubernetes, which comprehensively represents the actual situation of the cluster. They are designed to represent complex and diverse containerized ecologies, enabling efficient representation and management of system states by abstracting a series of resource entities into objects identifiable by K8 s. In particular operations, these objects are typically described in yaml files that contain information about which containerized applications are running (and the nodes at which they reside), the resources that the applications can use, and policies that are apparent when the applications are running, such as restart policies. Briefly, an "object" is an instance of a "resource" that is a persisted entity. The availability zone refers to a set of availability zones. These regions are part of a logical grouping, typically defined by the primary cloud provider as a set of regions with the same functionality. Within a particular area, each available region provides the same application programming interface (Application Programming Interface, API) and services. Kubernetes clusters can be run across multiple such available areas in design to improve the reliability and fault tolerance of the system. A load balancer on a cloud is a network device or service that is primarily used to distribute inbound network traffic to multiple backend servers. Such devices may be in hardware or in software. The load balancer is one of the basic components in cloud computing, and runs based on specific algorithms, such as polling, minimum connection number, minimum response time, etc., by which it is determined how to distribute requests to various servers, as an entry for network traffic, user requests or traffic can be distributed uniformly to backend servers through the load balancer according to some load balancing algorithm. In addition, to ensure high availability and performance optimization of the system, the load balancer also periodically checks the health of the backend servers, discovers failed or unavailable servers in time, and transfers traffic to the available servers. This ensures that the system can continue to operate even if one of the servers fails, while the resources of each server are fully utilized. After creating the ingress object, the gateway controller of the ingress listens for the K8s object and binds the K8s object to the LoadBalance of different available areas.
Step 202, monitor the health status of the backend server in the first available region to which the node of the K8s object belongs, and determine whether the first available region is available.
In this embodiment, the first available area refers to a service cluster where a node where a K8s object is created is located, and is used as a main processing area of external traffic. The method comprises the steps that an ingrescontroller of an ingress object monitors the health state of a back-end server in a first available area where a node of a K8s object is located, and whether the first available area is available is determined according to the health state of the back-end server.
If the first available area is not available, the traffic of the first available area is forwarded to the second available area 203.
In this embodiment, the second available area refers to a spare traffic available area. And when the health state of the first available area is not available, forwarding the external traffic of the first available area to the second available area for further processing.
In summary, according to the method for switching traffic across available areas provided by the present disclosure, a K8s object is monitored, and the K8s object is bound to a load balancer of different available areas, so that high availability is provided for service operation; monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, determining whether the first available area is available, realizing health monitoring of the available area, and providing a premise for flow switching; if the first available area is not available, forwarding the traffic of the first available area to the second available area ensures continuous operation and high availability of the service. Manual operation is reduced, and the number of times of traffic forwarding is reduced.
FIG. 3 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure. Fig. 3 is a further illustration of step 201 of fig. 2, based on the embodiment shown in fig. 3, comprising the steps of:
step 301, it is determined whether the K8s object is an ingress object.
In this embodiment, the ingress object refers to an API object in K8s, and is generally configured with yaml. The role is to define the rules for request forwarding as a configuration template or configuration file. It is checked whether the K8s object is an ingress object.
Step 302, if the K8s object is an ingress object, acquiring all request paths and back-end servers in an ingress rule of the ingress object.
In this embodiment, the ingress rule refers to a service where an external request is routed to the inside of the cluster. If the K8s object is an ingress object, all request paths and back-end servers in the ingress rule of the ingress object are acquired.
Step 303, grouping the request path and the backend server, obtaining the node, the service and the endpoint of the ingress object, and determining the first available region where the node is located.
In this embodiment, node nodes of the ingress object refer to working hosts in the K8s cluster, which are opposite to the master, and may be physical hosts, or may be a virtual host, and service for starting and managing pid is run on each node and can be managed by the master. The service of ingress objects is an abstraction that is used to logically represent a set of Pods and to disclose access portals, and the service can use a tag selector to select Pods with similar functionality and treat them as a single entity to more conveniently manage and discover those Pods. The main role of service is to provide stable ingress address and load balancing capability. The endpoint end of the ingres refers to a service, and includes a set of backend Pod, when an external flow request reaches the ingres, the rules configured by the ingres will forward the request to the corresponding service and Pod, in this scenario, the service acts as the endpoint end of the ingres and is responsible for processing the request sent from the ingres. And grouping the obtained request path of the ingress object and the back-end server, and obtaining the node, the service and the endpoint of the ingress object, thereby determining a first available area of the node.
Step 304, call the interface of the load equalizer, create the listener, and add the 7-layer forwarding policy to the listener according to the packet.
In this embodiment, the 7-layer forwarding policy, also called seven-layer load balancing, is a network traffic management technology, and mainly works in the application layer of the OSI model, that is, the HTTP protocol layer. When processing a network request, the seven-layer load balancer not only analyzes the IP address and the port number from the client, but also further checks the URI, the host name, the resource type and other data in the complete HTTP message. Based on this information, the seven-layer load balancer can forward the request to the backend server using the appropriate policies. In contrast to four-tier load balancing, four-tier load balancing is only directed to network packets sent and received by upstream services, and does not examine what the specific content within the packets is. And seven layers of load balancing can process the information of the upper layers of application layers, thereby providing richer and flexible flow management functions. For example, seven-layer load balancing may forward requests from different domain names and URLs to different servers for processing, one seven-layer listener may configure multiple domain names, and one domain name may configure multiple forwarding paths. And calling an interface of the load balancer, creating a monitor to monitor the load balancer, and adding a 7-layer forwarding strategy to the monitor according to the request path and the packet of the back-end server. The mapping relationship between the customizable ingress and the load balancer is as follows:
Definition of ingress Loadbalance definition
ingress Listener
path L7Policy
backend Pool
Pod member
Pod readness health monitor
In the above table, path of the ingress object is a path, band is a back-end server, pod is an entity execution unit of the ingress, pod ready is a way of measuring whether Pod is ready to receive traffic, listener is a monitor of load balancing loadbearer, L7Policy is a 7-layer forwarding Policy, pool is a back-end server group, member is an application service in Pool, and Health monitor is Health status monitoring of the back-end server.
In this embodiment, by confirming that the K8s object is an ingress object, the K8s object is bound to load balancers of different available areas, so that the cluster has high availability, and when one available area fails, traffic can be automatically routed to another normal available area, thereby ensuring continuous operation and high availability of services; the flexibility is also provided, and the flow can be flexibly routed to different back-end services or servers according to the requirements and the scenes of the application by configuring different strategies; in addition, cluster management is simplified, using ingress and load balancer, traffic routing rules across the available areas are centrally managed and configured without requiring separate processing for each backend service.
Fig. 4 is a flowchart of monitoring health of a backend server in a first available region to which a node of a K8s object belongs and determining whether the first available region is available according to an embodiment of the present disclosure. Fig. 4 is a further illustration of step 202 of fig. 3 and 2, based on the embodiment shown in fig. 4, comprising the steps of:
in step 401, the health status of each backend server in the first available zone is determined by the listener.
In this embodiment, the health status of each backend server in the first available region is obtained by the listener of the load balancer.
In step 402, when the health status of more than half of the nodes in the first available region is invalid, it is determined that the first available region is not available.
In this embodiment, when more than half of the health states in the back-end server, i.e., the nodes, of the first available area are failure states, it is determined that the first available area is not available.
In this embodiment, the number of failed nodes of the back end server of the first available area is obtained by the listener, so that the first available area is determined to be in an unavailable state, and the state of the first available area is provided for traffic forwarding.
Fig. 5 is a flow chart of forwarding traffic of a first available region to a second available region if the first available region is unavailable according to an embodiment of the present disclosure. Fig. 5 is a specific illustration of step 401 of fig. 4, based on the embodiment shown in fig. 5, comprising the steps of:
Step 501 dynamically modifies the layer 7 forwarding policy in the load balancer.
In this embodiment, when an ingress is created, an ingress class is added as an nginx, and the ingress of the ingress class is monitored as an ingnx, and is forwarded as a configuration parameter of the nginx, so that the configuration parameter is effective. When the client accesses the Pod application, the traffic is forwarded to the service of the loadport corresponding to the cluster ingress nginx through the loadport firstly, the service of the ingress ginx forwards the traffic to the corresponding ingress nginx Pod, ingress nginx Pod to start an ginx service, and different paths are forwarded to different services according to the 7-layer http protocol. Thereby completing the dynamic modification of the 7-layer forwarding policy in the load balancer.
Step 502, deleting the first route of the server group in the first available area, and adding the first route to the server group route in the second available area.
In this embodiment, the first route refers to a node route address indicating path information of the server group in the first available area. When the first available area is in a failure unavailable state, then the first route of the server group in the first available area is deleted and added to the route of the server group in the second available area.
In step 503, the path of the first route is directed to the node corresponding to the server group in the second available area.
In this embodiment, the path of the first route is configured to point to the node corresponding to the server group in the second available area, so that when the first available area is unavailable, the traffic is forwarded to the second available area, and continuous operation and high availability of the service are ensured.
Fig. 6 is a flowchart of determining a health status of each back-end server in a first availability zone, according to an embodiment of the present disclosure. Fig. 6 is a specific illustration of step 401 of fig. 4, based on the embodiment shown in fig. 5, comprising the steps of:
and 601, adopting an exponential distribution algorithm, taking a sampling success time interval as an algorithm sample in a preset finite sequence, and carrying out probability calculation through N data samples to obtain the failure probability of the node in the first available region.
In this embodiment, in order to determine the health status of each back-end server in the first available area, the probability density function is used to estimate the node failure probability, and preferably, an exponential distribution is used as the estimating function of the node failure distribution, where the probability density used by the exponential distribution is as follows:
the distribution function is:
Where x represents the interval between the current time and the last sampling success time, λ takes a value of 1 per sample average, the final actual failure probability distribution function is 1-F (x; λ), the obtained result obtained by taking the logarithm by taking the formula is xλ/ln (10), and the calculated result is taken as the misjudgment probability of node failure, that is, the failure probability of the node in the first available region is smaller as the value is larger.
In step 602, when the failure probability is greater than or equal to a preset configurable value, determining that the node fails.
In this embodiment, when the failure probability is greater than or equal to a preset configurable threshold, it is determined that the node fails. Whereby the health status of each back-end server in the first available area is estimated by an exponential distribution. The state reference information of the available area is provided for traffic forwarding.
Fig. 7 is a flowchart of forwarding traffic of a first available region to a second available region if the first available region is unavailable according to an embodiment of the present disclosure. Fig. 7 is a further illustration of fig. 5, based on the embodiment shown in fig. 7, comprising the steps of:
in step 701, after the health status of the nodes in the first available area exceeds half of the nodes, the first route is restored in the server group in the first available area, and the second route in the server group in the second available area is deleted.
In this embodiment, the second route refers to a node route address indicating path information of the server group in the second available area. And after more than half of the health states in the nodes in the first available area are restored from the unavailable state to the available state, restoring the deleted first route in the server group in the first available area, and deleting the second route in the server group in the second available area.
In this embodiment, after the first available area recovers the value available state, the first route of the first available area is started immediately, and the second route of the second available area is deleted and adjusted to the original traffic processing state. The method and the system realize the automatic routing of the traffic to the server group of the optimal available area for processing, and ensure the high availability of the service.
FIG. 8 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure. Fig. 8 is a further detailed illustration of fig. 3, based on the embodiment shown in fig. 8, comprising the steps of:
step 801, when a node corresponding to the ingress object changes, obtaining a path group and available area information in the changed ingress object.
In this embodiment, when a node corresponding to an ingress object changes, path packets and available area information in the changed ingress object need to be acquired, so that accuracy of routing information is ensured.
Step 802, updating 7-layer forwarding policies in different available areas in the load balancer, so that a server group corresponding to the 7-layer forwarding policies in each available area in the load balancer is consistent with an available area where a path and a node defined in the ingress object are located.
In this embodiment, when a node corresponding to an ingress object changes, 7-layer forwarding policies in different available areas in the load balancer are updated, so that a server group corresponding to the 7-layer forwarding policies in each available area in the load balancer is consistent with a path defined in the ingress object and an available area where the node is located. Thereby improving network performance, i.e. selecting the same available area as the backend server, reducing network latency and improving access speed, improving system reliability,
FIG. 9 is a flow chart of a load balancer binding K8s objects to different availability zones according to an embodiment of the present disclosure. Fig. 9 is a further detailed illustration of fig. 3, based on the embodiment shown in fig. 9, comprising the steps of:
step 901, when the ingress object is deleted, calling an interface in the load balancer, and deleting a listener, a 7-layer forwarding policy and a server group of the ingress object existing in the load balancer.
In this embodiment, when an ingress object is deleted from the K8s cluster, if there are also a listener, a seven-layer forwarding policy, and a server group associated with the ingress object, some problems may arise. For example, a subsequently created new ingress object may not work properly because the old listener, forwarding policy, and server group still occupy resources on the load balancer. At this point, by invoking the load balancer interface, the elimination of these no longer needed listeners, seven-layer forwarding policies, and server groups will help avoid the problems described above. Thus, the normal operation of the load balancer can be ensured, and the efficiency of processing new requests can be improved.
Fig. 10 is a schematic diagram of LoadBalance7 layer traffic forwarding according to an embodiment of the disclosure. As shown in fig. 10, in this embodiment, a loadport configures a plurality of listeners to monitor different ports, and performs 7-layer forwarding through L7Policy, after the traffic reaches the loadport, the listeners are responsible for forwarding the traffic to the members servers of different server groups pool in a load balancing manner through the L7Policy rule, the members are members of the server groups, and the members servers are responsible for responding to corresponding http requests as application real deployment servers.
Ingress is used as a traffic forwarding api object in K8s, mainly defines how the request traffic is forwarded to a corresponding service, and Ingress is used as an interface, has no effect after definition, and is Ingress Controller when the Ingress function is truly realized, and Ingress Nginx is a Ingress Controller realization mode. The yaml definition of Ingress is as follows:
the host, the path and the band are defined in the entry object rule, and when the host+path is accessed, the service is proxied into the service corresponding to the band by the Ingress. In the K8s, the service agents a group of Pod access modes, when the service is accessed, the actual K8s forwards the traffic to the Pod application, and when the service exposure mode is NodePort, the K8s traffic is forwarded to the real service through the node and the port where the Pod is located, so that the node classification can be respectively hung in the server groups of different LoadBasand by utilizing the available areas where the node is located, and the high-availability load balancing switching of the multiple available areas is completed.
Fig. 11 is a schematic diagram of adding policies to LoadBalance by availability zone Ingress Controller according to an embodiment of the present disclosure. As shown in fig. 11, in the present embodiment,
step 1, firstly, setting an available area (Availability Zone, AZ) 1 as a default available area as a main processing area of external traffic, AZ2 as a standby traffic available area, ingress LoadBalance monitoring a K8s event, and judging whether the event is any event in Node, ingress, service, endpoint.
Step 2, if the event is an entry event, acquiring all the request paths and back-end services in the entry rule, and grouping the paths and server groups in the entry rule into { "/url1": "service1", "/url2" accordingto the request path, which is described by taking/url 1 and/url 2 as examples herein: "service 2"; the node information corresponding to the Pod pointed by the Ingress back-end service is obtained, and the available area label where the node is located takes the available area 1az1 and the available area 2 corresponding to the path/url 1, namely az2 as examples, the node nodeport where the back-end service is located is further grouped according to the available area label, in this example, the available area of 192.168.10.1 and 192.168.10.2 nodes is az1, the available area of 192.168.20.1 nodes is az2, and the available area can be divided into { "/url1": { "az1": "192.168.10.1:32020": "192.168.10.2:32020" ] "and" az 2":" 192.20.1:32020 "}, according to the available area label of the node.
Step 3, calling an elastic load balancing LoadBalance related interface, creating a listener monitor, obtaining host+path corresponding to Ingress as a name, adding a corresponding L7Policy to the monitor according to a node nodeport packet, adding forwarding paths/url 1 and/az 1/url1 to an az1 available area in the embodiment shown in fig. 10, creating a back-end server group pool1 for the available area 1, adding member192.168.10.1:32020 and 192.168.10.2:32020 to the server group, and forwarding the paths/url 1 and/az 1/url1 to the back-end server group pool; adding forwarding path/url 2 to az2 available area, creating a back-end server group pool2 for the available area 2, and adding members 192.168.20.1:32020 to the server group.
Step 4, when the node corresponding to the ingress changes, the IngressController firstly acquires the path grouping in the changed ingress and the available area information according to the node; calling a LoadBalance interface to acquire the original available area node information, comparing the two information, updating L7policy in different available areas in the LoadBalance, and finally enabling a server group corresponding to the L7policy in each available area in the LoadBalance to be consistent with a path defined in Ingress and the available area where the node is located.
And 5, when the Ingress is deleted, the IngressController calls an interface in the loadBasand, acquires a listener, L7policy and a server group pool existing in the loadBasand by the ingres, and deletes the information one by one, so that the configuration in the loadBasand is consistent with the definition of the Ingress finally.
After the IngressController adds the K8s node and the application server information sub-available area as the members to the loadBase, the loadBase carries out health monitoring and activity detection on the members in the back-end server group according to the health checking strategy defined in the Ingress, and sends the health monitoring information to the AMQP message queue, the IngressController also monitors the health checking state reported by the loadBase, and when a certain available area is in an unavailable state, the available area is switched in real time, and the user does not have the perception of completing flow switching, so that the high availability target is achieved.
Fig. 12 is a schematic diagram of an importesscontrol and LoadBalance call relationship according to an embodiment of the disclosure. In step 5 of the embodiment shown in fig. 11, when a half node of a certain available area is in an unavailable state, the available area is switched in real time, and the user does not have to perceive to complete traffic switching, so as to achieve a high availability target, wherein in the embodiment, as shown in fig. 12, a heartbeat detection or a http detection is adopted by a Healthmonitor in loadBase to monitor the survival state of a server application (in a node port mode), and the link state is reported to an AMQP message queue, and meanwhile, an ingress controller monitors the AMQP message queue, acquires the link state from the loadBase to a node Pod of K8s, and determines whether to dynamically switch the request path of the traffic according to whether the available area node survives an algorithm. Because the server detection is processed in the form of a heartbeat packet, the TCP protocol is connection-oriented, and when the opposite terminal does not respond, whether the application is reachable or not can be judged only according to the set timeout time, and abnormality cannot be known quickly.
Because in probability theory and statistics, the exponential distribution is a continuous probability distribution, and can be used for representing the time interval of occurrence of independent random events, an exponential distribution algorithm is adopted in the algorithm for detecting whether the node survives, the algorithm takes the time interval of successful sampling as an algorithm sample in a section of finite sequence, probability calculation is carried out through the latest N data samples, and the probability of node failure is obtained:
the probability density function used for the exponential distribution is as follows:
the distribution function is:
where x represents the interval between the current time and the last sampling success time, lambda takes a value of 1 per sample average, the final actual failure probability distribution function is 1-F (x; lambda), and the result obtained by taking the logarithm of the formula is xlambda/ln (10).
And taking the calculation result as the false positive probability of node failure, wherein the larger the value is, the smaller the false positive probability is.
In the method, an algorithm based on an exponential distribution function is adopted to judge whether a node fails to rapidly switch over a failed available area, the application unavailable time is reduced, a threshold value of the misjudgment probability is set to be a configurable value, when the calculation result of the misjudgment probability is larger than the configurable value, the node is judged to fail, and an IngressController records that the node is in a failure state. The key algorithm is realized as follows:
The IngressController creates a queue with a length of N (N takes a value of 10 and can be dynamically adjusted), monitors successfully acquired node state data in an AMQP (advanced message service protocol) and stores the successfully acquired node state data in the queue, when new data comes in, old data can be deleted in the queue, therefore, the long queue in the queue is always of a fixed length N, whether the node unavailability probability reaches a threshold value or not is circularly judged according to a configured monitoring time interval, the node unavailability is judged when the node unavailability reaches the threshold value, when more than half of nodes in an AZ1 availability area fail, the IngressController dynamically modifies L7 poll in a LoadBase, removes routes/url 1 and/AZ 1/url1 of the AZ1 server group, and adds/url 1 in the AZ2 server group route, and points the/url 1 route to a nodeport corresponding to the AZ2 server group, so that the flow is dynamically switched to the AZ2 availability area under the condition that a user does not feel. After the nodes in the available area 1 exceed half of the available states, the IngressController recovers/url and/AZ 1/url in the AZ1 server group, removes/url in the AZ2 server group route, and completes seamless switching of the AZ1 available area.
According to the flow switching method across the available areas, provided by the embodiment of the disclosure, the K8s object is monitored, the K8s object is bound to load balancers of different available areas, and high availability is provided for service operation; monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, determining whether the first available area is available, realizing health monitoring of the available area, and providing a premise for flow switching; if the first available area is not available, forwarding the traffic of the first available area to the second available area ensures continuous operation and high availability of the service. Manual operation is reduced, and the number of times of traffic forwarding is reduced.
Corresponding to the methods provided by the above several embodiments, the present disclosure further provides a flow switching device across the available area, and since the device provided by the embodiments of the present disclosure corresponds to the method provided by the above several embodiments, implementation manners of the method are also applicable to the device provided by the embodiment, and will not be described in detail in the present embodiment.
Fig. 13 is a schematic structural diagram of a flow switching device 1300 across available areas according to an embodiment of the present disclosure. As shown in fig. 13, the flow switching device across the available area includes:
a binding module 1310, configured to monitor the K8s object and bind the K8s object to load balancers of different available areas;
a determining module 1320, configured to monitor a health status of a backend server in a first available area to which a node of the K8s object belongs, and determine whether the first available area is available;
and a forwarding module 1330, configured to forward the traffic in the first available area to the second available area if the first available area is unavailable.
In some embodiments, binding module 1310 binds K8s objects to load balancers of different availability zones in the following manner:
determining whether the K8s object is an ingress object;
if the K8s object is an ingress object, acquiring all request paths and a back-end server in an ingress rule of the ingress object;
Grouping the request path and the back-end server, obtaining node, service and endpoint of the ingress object, and determining a first available area where the node is located;
and calling an interface of the load equalizer, creating a listener, and adding a 7-layer forwarding strategy into the listener according to the packet.
In some embodiments, binding module 1310 listens for the health of the backend servers in the first available region to which the node of the K8s object belongs, and determines whether the first available region is available, as follows:
determining, by the listener, a health status of each backend server in the first available region;
and when the health states of more than half of the nodes in the first available area are invalid, determining that the first available area is not available.
In some embodiments, binding module 1310 forwards traffic for a first available region to a second available region if the first available region is unavailable by:
dynamically modifying a 7-layer forwarding strategy in the load balancer;
deleting the first route of the server group in the first available area, and adding the first route in the server group route in the second available area;
and directing the path of the first route to the node corresponding to the server group in the second available area.
In some embodiments, binding module 1310 determines the health status of each back-end server in the first available region as follows:
using an exponential distribution algorithm, taking a sampling success time interval as an algorithm sample in a preset finite sequence, and carrying out probability calculation through N data samples to obtain the failure probability of the node in the first available region;
and when the failure probability is greater than or equal to a preset configurable value, determining that the node fails.
In some embodiments, binding module 1310 is also to:
and after the health states of more than half of the nodes in the first available area recover the available states, recovering the first route in the server group in the first available area, and deleting the second route in the server group in the second available area.
In some embodiments, binding module 1310 is also to:
when the node corresponding to the ingress object changes, acquiring path grouping and available area information in the changed ingress object;
and updating 7-layer forwarding strategies in different available areas in the load balancer so that a server group corresponding to the 7-layer forwarding strategies in each available area in the load balancer is consistent with the available area where the paths and nodes defined in the ingress object are located.
In some embodiments, binding module 1310 is also to:
when the ingress object is deleted, an interface in the load balancer is called, and a listener, a 7-layer forwarding policy and a server group of the ingress object existing in the load balancer are deleted.
In summary, through the flow switching device crossing the available areas, monitoring the K8s object, and binding the K8s object to the load equalizer of different available areas; monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, and determining whether the first available area is available; and if the first available area is not available, forwarding the traffic of the first available area to the second available area. The device solves the problem that K8s spans multiple available areas, the ingress nginx can not dynamically select corresponding services according to the strategy, manual operation is reduced, and the flow forwarding times are reduced.
In the embodiments provided in the present application, the method and the apparatus provided in the embodiments of the present application are described. In order to implement the functions in the methods provided in the embodiments of the present application, the electronic device may include a hardware structure, a software module, and implement the functions in the form of a hardware structure, a software module, or a hardware structure plus a software module. Some of the functions described above may be implemented in a hardware structure, a software module, or a combination of a hardware structure and a software module.
Fig. 14 is a block diagram of an electronic device 1400 for implementing the above-described method of traffic handoff across available regions, according to an example embodiment.
For example, electronic device 1400 may be a mobile phone, computer, messaging device, game console, tablet device, medical device, exercise device, personal digital assistant, or the like.
Referring to fig. 14, an electronic device 1400 may include one or more of the following components: processing component 1402, memory 1404, power component 1406, multimedia component 1408, audio component 1410, input/output (I/O) interface 1412, sensor component 1414, and communication component 1416.
The processing component 1402 generally controls overall operation of the electronic device 1400, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 1402 may include one or more processors 1420 to execute instructions to perform all or part of the steps of the methods described above. Further, the processing component 1402 can include one or more modules that facilitate interaction between the processing component 1402 and other components. For example, the processing component 1402 can include a multimedia module to facilitate interaction between the multimedia component 1408 and the processing component 1402.
The memory 1404 is configured to store various types of data to support operations at the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 1400, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 1404 may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.
The power supply component 1406 provides power to the various components of the electronic device 1400. Power components 1406 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for electronic device 1400.
The multimedia component 1408 includes a screen between the electronic device 1400 and the user that provides an output interface. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or sliding action, but also the duration and pressure associated with the touch or sliding operation. In some embodiments, the multimedia component 1408 includes a front camera and/or a rear camera. When the electronic device 1400 is in an operational mode, such as a shooting mode or a video mode, the front camera and/or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
The audio component 1410 is configured to output and/or input audio signals. For example, the audio component 1410 includes a Microphone (MIC) configured to receive external audio signals when the electronic device 1400 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may be further stored in the memory 1404 or transmitted via the communication component 1416. In some embodiments, audio component 1410 also includes a speaker for outputting audio signals.
The I/O interface 1412 provides an interface between the processing component 1402 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to: homepage button, volume button, start button, and lock button.
The sensor assembly 1414 includes one or more sensors for providing status assessment of various aspects of the electronic device 1400. For example, the sensor assembly 1414 may detect an on/off state of the electronic device 1400, a relative positioning of the components, such as a display and keypad of the electronic device 1400, the sensor assembly 1414 may also detect a change in position of the electronic device 1400 or a component of the electronic device 1400, the presence or absence of a user's contact with the electronic device 1400, an orientation or acceleration/deceleration of the electronic device 1400, and a change in temperature of the electronic device 1400. The sensor assembly 1414 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. The sensor assembly 1414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1414 may also include an acceleration sensor, a gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
The communication component 1416 is configured to facilitate communication between the electronic device 1400 and other devices, either wired or wireless. The electronic device 1400 may access a wireless network based on a communication standard, such as WiFi,2G or 3G,4G LTE, 5G NR (New Radio), or a combination thereof. In one exemplary embodiment, the communication component 1416 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 1416 further includes a Near Field Communication (NFC) module to facilitate short range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.
In an exemplary embodiment, the electronic device 1400 may be implemented by one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.
In an exemplary embodiment, a non-transitory computer-readable storage medium is also provided, such as a memory 1404 including instructions executable by the processor 1420 of the electronic device 1400 to perform the above-described method. For example, the non-transitory computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.
Embodiments of the present disclosure also provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of traffic switching across available areas described in the above embodiments of the present disclosure.
Embodiments of the present disclosure also provide a computer program product comprising a computer program which, when executed by a processor, performs the method of traffic switching across available areas described in the above embodiments of the present disclosure.
Fig. 15 is a schematic structural diagram of a chip 1500 for implementing the above-described flow switching method across the available areas according to an exemplary embodiment.
Referring to fig. 15, a chip 1500 includes at least one communication interface 1501 and a processor 1502; the communication interface 1501 is configured to receive a signal input to the chip 1500 or a signal output from the chip 1500, and the processor 1502 communicates with the communication interface 1501 and implements the traffic switching method across the available area described in the above embodiments through logic circuits or execution of code instructions.
It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.
In the description of the present specification, reference is made to the description of the terms "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples," etc., meaning that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present disclosure. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and further implementations are included within the scope of the preferred embodiment of the present disclosure in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present disclosure.
Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, system that includes a processing module, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (control method) with one or more wires, a portable computer cartridge (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium may even be paper or other suitable medium upon which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
It should be understood that portions of embodiments of the present disclosure may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.
Those of ordinary skill in the art will appreciate that all or a portion of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, where the program when executed includes one or a combination of the steps of the method embodiments.
Furthermore, functional units in various embodiments of the present disclosure may be integrated into one processing module, or each unit may exist alone physically, or two or more units may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules may also be stored in a computer readable storage medium if implemented as software functional modules and sold or used as a stand-alone product. The above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, or the like.
While embodiments of the present disclosure have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the present disclosure, and that variations, modifications, alternatives, and variations of the above embodiments may be made by those of ordinary skill in the art within the scope of the present disclosure.

Claims (12)

1. A method for traffic handoff across an available region, the method comprising:
monitoring a K8s object, and binding the K8s object to load balancers of different available areas;
monitoring the health state of a back-end server in a first available area to which a node of the K8s object belongs, and determining whether the first available area is available;
and if the first available area is not available, forwarding the traffic of the first available area to a second available area.
2. The method of claim 1, wherein the load balancer binding the K8s object to different availability zones comprises:
determining whether the K8s object is an ingress object;
if the K8s object is an ingress object, acquiring all request paths and a back-end server in an ingress rule of the ingress object;
grouping the request path and the back-end server, acquiring a node, a service device and an endpoint of the ingress object, and determining a first available region where the node is located;
And calling an interface of a load equalizer, creating a listener, and adding a 7-layer forwarding strategy into the listener according to the packet.
3. The method of claim 2, wherein listening for the health of a backend server in a first available region to which a node of the K8s object belongs and determining whether the first available region is available comprises:
determining, by the listener, a health status of each backend server in the first available region;
and when the health states of more than half of the nodes in the first available area are invalid, determining that the first available area is not available.
4. The method of claim 3, wherein forwarding traffic for the first available region to a second available region if the first available region is unavailable comprises:
dynamically modifying a 7-layer forwarding policy in the load balancer;
deleting a first route of a server group in the first available area, and adding the first route to a server group route in the second available area;
and directing the path of the first route to a node corresponding to the server group in the second available area.
5. The method of claim 3, wherein the determining a health status of each back-end server in the first availability zone comprises:
Using an exponential distribution algorithm, taking a sampling success time interval as an algorithm sample in a preset finite sequence, and carrying out probability calculation through N data samples to obtain the failure probability of the node in the first available region;
and when the failure probability is greater than or equal to a preset configurable value, determining that the node fails.
6. The method according to claim 4, wherein the method further comprises:
and after the health states of more than half of the nodes in the first available area recover the available states, recovering the first route in the server group in the first available area, and deleting the second route in the server group in the second available area.
7. The method according to claim 2, wherein the method further comprises:
when the node corresponding to the ingress object changes, acquiring path grouping and available area information in the changed ingress object;
and updating 7-layer forwarding strategies in different available areas in the load balancer so that a server group corresponding to the 7-layer forwarding strategies in each available area in the load balancer is consistent with the available area where the paths and nodes defined in the ingress object are located.
8. The method according to claim 2, wherein the method further comprises:
and when the ingress object is deleted, calling an interface in the load balancer, and deleting a listener, a 7-layer forwarding strategy and a server group which exist in the load balancer by the ingress object.
9. A traffic switching device across an available area, the device comprising:
the binding module is used for monitoring the K8s object and binding the K8s object to load balancers of different available areas;
the determining module is used for monitoring the health state of a back-end server in a first available area to which the node of the K8s object belongs and determining whether the first available area is available;
and the forwarding module is used for forwarding the traffic of the first available area to a second available area if the first available area is unavailable.
10. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.
11. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-8.
12. A chip comprising at least one processor and a communication interface; the communication interface is configured to receive signals input to or output from the chip, and the processor is in communication with the communication interface and implements the method according to any one of claims 1-8 by logic circuitry or executing code instructions.
CN202311605451.3A 2023-11-28 2023-11-28 Method and device for switching traffic across available areas, electronic equipment, chip and medium Pending CN117596248A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311605451.3A CN117596248A (en) 2023-11-28 2023-11-28 Method and device for switching traffic across available areas, electronic equipment, chip and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311605451.3A CN117596248A (en) 2023-11-28 2023-11-28 Method and device for switching traffic across available areas, electronic equipment, chip and medium

Publications (1)

Publication Number Publication Date
CN117596248A true CN117596248A (en) 2024-02-23

Family

ID=89911260

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311605451.3A Pending CN117596248A (en) 2023-11-28 2023-11-28 Method and device for switching traffic across available areas, electronic equipment, chip and medium

Country Status (1)

Country Link
CN (1) CN117596248A (en)

Similar Documents

Publication Publication Date Title
CN113261247B (en) Method and client device for maintaining continuous network service
US20220094761A1 (en) Server Invocation Method and Proxy Server
KR20210064294A (en) Communication access method and apparatus, computer device, and storage medium
US10318550B2 (en) Systems and methods for autonomous resource discovery, management, and stitching
US10530669B2 (en) Network service aware routers, and applications thereof
US9331915B1 (en) Dynamic network traffic mirroring
CN111683139B (en) Method and device for balancing load
US20170293500A1 (en) Method for optimal vm selection for multi data center virtual network function deployment
CN113572831A (en) Communication method between Kubernetes clusters, computer equipment and medium
US20190349436A1 (en) Methods, apparatus and systems for resuming transmission link
CN113268308B (en) Information processing method, device and storage medium
US20080183878A1 (en) System And Method For Dynamic Patching Of Network Applications
US8964596B1 (en) Network service aware routers, and applications thereof
CN117596248A (en) Method and device for switching traffic across available areas, electronic equipment, chip and medium
CN113596119B (en) Edge capability distribution method, system, device and computer readable storage medium
US9019964B2 (en) Methods and systems for routing application traffic
US11379279B2 (en) Netlink asynchronous notifications for native and third party application in distributed network systems
WO2024102158A1 (en) Data flow management system
CN115996187A (en) Routing information processing method and device, routing information interaction system and routing equipment
CN116248683A (en) Cloud load balancing system and cloud load balancing method
JP6246677B2 (en) COMMUNICATION SYSTEM, CONTROL DEVICE, AND PROCESSING DEVICE SWITCHING METHOD
WO2022245479A1 (en) Broker cell for distributed message system
CN116450199A (en) Node release method, device and storage medium
CN117076152A (en) Event processing method, device, electronic equipment, chip and medium
CN113452539A (en) Source station switching method and device, electronic equipment and storage medium

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