CN113572831A - Communication method between Kubernetes clusters, computer equipment and medium - Google Patents
Communication method between Kubernetes clusters, computer equipment and medium Download PDFInfo
- Publication number
- CN113572831A CN113572831A CN202110825216.1A CN202110825216A CN113572831A CN 113572831 A CN113572831 A CN 113572831A CN 202110825216 A CN202110825216 A CN 202110825216A CN 113572831 A CN113572831 A CN 113572831A
- Authority
- CN
- China
- Prior art keywords
- target
- node
- cluster
- kubernets
- target node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 151
- 238000000034 method Methods 0.000 title claims abstract description 59
- 230000001360 synchronised effect Effects 0.000 claims abstract description 36
- 230000004044 response Effects 0.000 claims abstract description 33
- 238000012545 processing Methods 0.000 claims description 17
- 238000012217 deletion Methods 0.000 claims description 5
- 230000037430 deletion Effects 0.000 claims description 5
- RJKFOVLPORLFTN-LEKSSAKUSA-N Progesterone Chemical compound C1CC2=CC(=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H](C(=O)C)[C@@]1(C)CC2 RJKFOVLPORLFTN-LEKSSAKUSA-N 0.000 claims description 2
- 230000008569 process Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000008531 maintenance mechanism Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 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/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- 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
-
- 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
- H04L67/104—Peer-to-peer [P2P] networks
-
- 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
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- 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
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the invention discloses a communication method, computer equipment and medium among Kubernets clusters, which are applied to a main Kubernets cluster, wherein the method comprises the following steps: in response to an increase instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of a master Kubernets cluster; respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster; and responding to a synchronization instruction of the data to be synchronized in the target reference node, and synchronizing the data to be synchronized from the target reference node to the target node through the target communication channel. The scheme of the embodiment of the invention solves the problems that the two Kubernets can not normally communicate and the communication efficiency is lower when the gateway node fails or fails in the prior art, and realizes the point-to-point communication between the Kubernets.
Description
Technical Field
The embodiment of the invention relates to the technical field of cloud computing, in particular to a communication method between Kubernetes clusters, computer equipment and a medium.
Background
Kubernets is an open source for managing containerized applications on multiple hosts in a cloud platform, and its goal is to make deploying containerized applications simple and efficient, providing application deployment, planning, updating, and maintenance mechanisms.
At present, a plurality of kubernets clusters are usually deployed to carry different services, or disaster recovery of services is performed between the clusters, so that services of different kubernets clusters need to be accessed to each other; in the method in the prior art, traffic communication between two kubernets clusters is realized by forwarding traffic to a gateway node in a centralized manner and then communicating with other clusters through the gateway node.
The method in the prior art cannot realize point-to-point communication between Kubernets, and when a gateway node fails or fails, normal communication between two Kubernets cannot be realized, so that the communication efficiency is low.
Disclosure of Invention
The embodiment of the invention provides a communication method between Kubernets clusters, computer equipment and a medium, so as to realize point-to-point communication between the Kubernets clusters.
In a first aspect, an embodiment of the present invention provides a communication method between kubernets clusters, which is applied to a main kubernets cluster, and includes:
in response to an add instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of the master Kubernets cluster;
respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster;
synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
In a second aspect, an embodiment of the present invention further provides a computer device, including a processor and a memory, where the memory is used to store instructions, and when the instructions are executed, the processor is caused to perform the following operations:
in response to an add instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of the master Kubernets cluster;
respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster;
synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
In a third aspect, an embodiment of the present invention further provides a storage medium containing computer-executable instructions, which when executed by a computer processor, are configured to perform the method for communication between kubernets clusters according to any embodiment of the present invention.
The method comprises the steps that attribute information of a target node is synchronized to a storage area of a main Kubernetes cluster by responding to an increasing instruction of the target node of a target slave Kubernetes cluster; respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster; responding to a synchronization instruction of data to be synchronized in a target reference node, synchronizing the data to be synchronized from the target reference node to the target node through a target communication channel, solving the problems that normal communication cannot be performed between two Kubernets clusters and the communication efficiency is low when a gateway node fails or fails in the prior art, and realizing point-to-point communication between the Kubernets clusters.
Drawings
Fig. 1 is a flowchart of a communication method between kubernets clusters in a first embodiment of the present invention;
fig. 2 is a flowchart of a communication method between kubernets clusters in the second embodiment of the present invention;
fig. 3 is a flowchart of a communication method between kubernets clusters in the third embodiment of the present invention;
fig. 4 is a flowchart of a communication method between kubernets clusters in the fourth embodiment of the present invention;
fig. 5 is a schematic structural diagram of a communication device between kubernets clusters according to a fifth embodiment of the present invention;
fig. 6 is a schematic structural diagram of a computer device in the sixth embodiment of the present invention.
Detailed Description
The embodiments of the present invention will be described in further detail with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad invention. It should be further noted that, for convenience of description, only some structures, not all structures, relating to the embodiments of the present invention are shown in the drawings.
Before discussing exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart may describe the operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figure. The processes may correspond to methods, functions, procedures, subroutines, and the like.
The term "kubernets" as used herein is an open source for managing containerized applications on multiple hosts in a cloud platform, providing a mechanism for application deployment, planning, updating, and maintenance with the goal of making it simple and efficient to deploy containerized applications.
The term "etcd" as used herein is a distributed key-value pair storage system that internally employs the raft protocol as a consistency algorithm for reliably and quickly storing critical data and providing access.
The term "CRD (Custom Resource Definition)" used herein is an extension of kubernets API, which allows users to easily store and retrieve structured data.
The term "kubernets-api" as used herein is a community standard component, and a kubernets cluster object access portal, and various resources inside a cluster can be operated by accessing the api, including kubernets standard objects such as service, endpoint, node, etc., and also kubernets custom objects, i.e., CRD resources.
The term "keepalived" used herein is a lightweight high-availability solution under linux, and the realization of high-availability function through VRRP protocol can ensure that the whole network can operate uninterruptedly when an individual node goes down.
The term "Pod" as used herein is the smallest/simplest basic unit of kubernets cluster creation or deployment, with one Pod representing one process running on the cluster.
As used herein, the term "service" is a logical grouping of a Pod, a policy that allows access to them, and a user accessing the service will load balance the service into the corresponding Pod.
The term "endpoint" used herein corresponds to a set of IP address and port number of a matched point in a service, each service corresponds to an endpoint object with the same name, and when the service is accessed, the load is finally balanced to the content of the endpoint object.
The term "NodePort" as used herein is an exposure of services through IP and static ports (NodePort) on each node; a nodoport service can be accessed from outside the cluster by requesting < NodeIP > < nodoport >.
As used herein, the term "Ingress" is an external portal that implements a service within a cluster, a URL that may be configured to provide external access to the service, load balancing, SSL, providing name-based virtual hosts, and the like.
For ease of understanding, the main inventive concepts of the embodiments of the present invention are briefly described.
In the prior art, service communication between two kubernets clusters is realized by forwarding traffic to a gateway node in a centralized manner and then communicating with other clusters through the gateway node.
The method in the prior art cannot realize point-to-point communication between Kubernets, and when a gateway node fails or fails, normal communication between two Kubernets cannot be realized, so that the communication efficiency is low.
The inventor considers whether the communication between the nodes between the Kubernets clusters can be directly realized or not aiming at the problems that the normal communication between the two Kubernets clusters cannot be realized and the communication efficiency is low when the gateway node fails or fails in the prior art, and the communication between the Kubernets clusters is realized without depending on the gateway node.
Based on the above thought, the inventors have creatively proposed to synchronize the attribute information of a target node into the storage area of the master kubernets cluster by responding to an add instruction of the target node of the target slave kubernets cluster; respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster; synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node. The advantage of this is that the master kubernets cluster synchronizes the attribute information of the nodes added from the kubernets cluster to the storage area, so as to subsequently establish a communication channel between the node of the master kubernets cluster and the nodes of the other kubernets cluster, thereby realizing peer-to-peer communication between a plurality of kubernets clusters, and not influencing the communication condition between the kubernets clusters due to the failure of one node.
Example one
Fig. 1 is a flowchart of a method for communication between kubernets clusters in an embodiment of the present invention, where the embodiment is applicable to a case of performing communication between kubernets clusters, and the method may be executed by a communication device between kubernets clusters, where the device may be implemented in software and/or hardware and integrated in a computer device. Specifically, referring to fig. 1, the method specifically includes the following steps:
It should be noted that the communication method between kubernets clusters related in this embodiment may be applied to a main kubernets cluster; the master kubernets cluster may be any kubernets cluster, and the rest kubernets clusters are named as slave kubernets clusters in this embodiment; illustratively, if three kubernets clusters are included in the system, respectively kubernets cluster A, Kubernetes cluster B and kubernets cluster C, then kubernets cluster B and kubernets cluster C are not clustered from kubernets when kubernets cluster a is the master kubernets cluster.
The target slave kubernets cluster may be any slave kubernets cluster, and this is not limited in this embodiment. The target node may be any node in the target slave kubernets cluster, for example, a newly added computer device, a mobile terminal, or a computer device, which is not limited in this embodiment.
In an optional implementation manner of this embodiment, when the master kubernets cluster monitors that a target is added from the kubernets cluster, the attribute information of the added target node may be copied to a storage area of the master kubernets cluster; the storage area of the main kubernets cluster may be an etcd storage system (which is a distributed key-value pair storage system, and a raft protocol is used as a consistency algorithm inside the storage system to reliably and quickly store key data and provide access), or may be a CRD (i.e., a user-defined resource, which is an extension of a kubernets API and can allow a user to simply store and acquire structured data), which is not limited in this embodiment.
In a specific example of this embodiment, a vector-controller (cluster data controller) deployed in a master node of a master kubernets cluster may monitor a storage area of other slave kubernets cluster in real time, and when it is monitored in the storage area that there is an addition of new attribute information of a node, it may be determined that there is an addition of a target node in the target slave kubernets cluster, and further, the attribute information of the target node stored in the storage area of the target slave kubernets cluster may be synchronized to the storage area of the master kubernets cluster.
Wherein the attribute information of the target node may include at least one of: an IP Address (Internet Protocol Address) of the node, network segment information CIDR of the node, a MAC Address (physical Address) of the node tunnel device, an IP Address of the node tunnel device, and the like, which are not limited in this embodiment.
And step 120, respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main kubernets cluster.
The at least one reference node of the master kubernets cluster may be one or more slave nodes of the master kubernets cluster, which is not limited in this embodiment.
In an optional implementation manner of this embodiment, after the master kubernets cluster synchronizes the attribute information of the target node to the storage area of the master kubernets cluster, a communication channel between the target node and each reference node may be further established according to the attribute information of the newly added target node and the attribute information of at least one reference node of the master kubernets cluster.
For example, after the master kubernets cluster synchronizes the attribute information of the target node to the storage area of the master kubernets cluster, the target reference node in the master kubernets cluster may establish a communication channel between the target reference node and the target node according to the attribute information of the target node in the storage area and the attribute information of the target reference node, so as to provide a basis for data transmission between the subsequent target reference node and the target node. The target reference node may be any reference node, which is not limited in this embodiment.
In a specific example of this embodiment, the vector-agent (node configuration agent) of each slave node deployed in the master kubernets cluster may monitor the storage area of the master kubernets cluster in real time, and when the addition of the attribute information of a new node is monitored in the storage area, a communication channel between the current node and the target node may be established according to the attribute information of the target node and the attribute information of the current node (any reference node), so as to provide a basis for data transmission between the current node and the target node.
The target reference node is any reference node in the master kubernets cluster, which establishes a communication channel with the target reference node, and is not limited in this embodiment.
In an optional implementation manner of this embodiment, after the communication channels between the target node and each reference node are respectively established, if a synchronization instruction of data to be synchronized in the target reference node is received, the data to be synchronized may be synchronized from the target reference node to the target node through the communication channel between the target reference node and the target node, that is, data transmission between the master kubernets cluster and the target slave kubernets cluster is implemented.
In the scheme of this embodiment, attribute information of a target node is synchronized to a storage area of a master kubernets cluster by responding to an addition instruction of the target node of a target slave kubernets cluster; respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster; responding to a synchronization instruction of data to be synchronized in a target reference node, synchronizing the data to be synchronized from the target reference node to the target node through a target communication channel, solving the problems that normal communication cannot be performed between two Kubernets clusters and the communication efficiency is low when a gateway node fails or fails in the prior art, and realizing point-to-point communication between the Kubernets clusters.
Example two
Fig. 2 is a flowchart of a communication method between kubernets clusters in a second embodiment of the present invention, where this embodiment is a further refinement of the foregoing technical solutions, and the technical solution in this embodiment may be combined with various alternatives in one or more of the foregoing embodiments. As shown in fig. 2, the communication method between kubernets clusters may include the following steps:
and step 210, establishing access connection between the master Kubernets cluster and each slave Kubernets cluster, so that the master Kubernets cluster monitors the resource information stored in the storage area of each slave Kubernets cluster.
In an optional implementation manner of this embodiment, before responding to an instruction to add a target node of a target slave kubernets cluster, the master kubernets cluster may further establish an access connection between the master kubernets cluster and each slave kubernets cluster, so that the master kubernets cluster may monitor resource information stored in a storage area by each slave kubernets cluster.
In an optional implementation manner of this embodiment, the establishing an access connection between the master kubernets cluster and each slave kubernets cluster may include: selecting several nodes in the kubernets cluster to start keepalive service (for example, 3 or 5 slave nodes may be selected in the master kubernets cluster, which is not limited in this embodiment), and configuring keepalive to generate a virtual IP address, where the virtual IP address may drift between the selected nodes, so as to ensure high availability of the generated virtual IP address.
Furthermore, the etcd cluster of each Kubernetes cluster uses a nodoport mode to expose services to the outside, because the generated virtual IP address is also on the node, the outside can access the etcd through the virtual IP address and the port number set by the nodoport, and the connection can be established between the clusters (between the master Kubernetes cluster and each slave Kubernetes cluster) by directly using the corresponding virtual IP address and the corresponding port number to access the etcd of the other side.
It should be noted that, in this embodiment, in order to establish an access connection between a master kubernets cluster and each slave kubernets cluster, authentication information of etcds of all clusters needs to be written into a specified directory of each kubernets cluster master node, and after a vector-controller definition template is mounted inside a Pod through the directory of a host, a vector-controller process can perform authentication using corresponding authentication information and etcds of other kubernets clusters.
In an optional implementation manner of this embodiment, the establishing an access connection between the master kubernets cluster and each slave kubernets cluster may further include: the method comprises the steps that a main node in the Kubernetes cluster starts keepalived service, a virtual IP address is generated by configuring keepalived, the virtual IP address can drift among a plurality of main nodes, and high availability of the virtual IP address is guaranteed. The plurality of main nodes expose the Kubernets-api service to the outside through the fixed port numbers, and because the virtual IP addresses are also on the main nodes, the Kubernets-api service of the cluster can be accessed by the outside through the virtual IP addresses and the set port numbers. It will be appreciated that each kubernets cluster (including the master and slave kubernets) may register the same CRD resources that may be used to hold information needed for multi-cluster communication.
It should be noted that, in this embodiment, in order to establish access connection between the master kubernets cluster and each slave kubernets cluster, authentication information of kubernets-api of all clusters needs to be written into a specified directory of each kubernets cluster master node, and after a deploymenent template of a vector-controller is placed inside a Pod by mounting the directory of a host, the vector-controller process can use the corresponding authentication information and kubernets-api of other clusters for authentication, thereby monitoring changes in CRD resources of other clusters.
Wherein the attribute information of the target node may include at least one of: the IP address of the node, the network segment information of the node, the MAC address of the node tunnel device, and the IP address of the node tunnel device, etc. are not limited in this embodiment.
In an optional implementation manner of this embodiment, after the access connection between the master kubernets cluster and each slave kubernets cluster is established, that is, after the master kubernets cluster may monitor resource information stored in the storage area of each slave kubernets cluster, if the master kubernets cluster monitors that a new target node is added in the target slave kubernets cluster, the attribute information of the new target node may be synchronized into the storage area of the master kubernets through the access connection between the master kubernets cluster and the target slave kubernets cluster, so as to provide a basis for subsequently establishing a communication channel between a slave node and a target node in the master kubernets cluster.
In an optional implementation manner of this embodiment, the establishing, according to the attribute information of the target node and the attribute information of at least one reference node of the master kubernets cluster, a communication channel between the target node and each reference node may include one or more of the following: respectively establishing a communication channel between a target node and each reference node according to the IP address of the target node and the IP address of each reference node; respectively establishing communication channels between the target node and the reference nodes according to the network segment information of the target node and the network segment information of the reference nodes; respectively establishing a communication channel between a target node and each reference node according to the MAC address of the node tunnel equipment of the target node and the MAC address of the node tunnel equipment of each reference node; and respectively establishing a communication channel between the target node and each reference node according to the IP address of the node tunnel equipment of the target node and the IP address of the node tunnel equipment of each reference node.
In this embodiment, before responding to the instruction of adding the target node of the target slave kubernets cluster, the master kubernets cluster further includes: the access connection between the main Kubernets cluster and each slave Kubernets cluster is established, so that the main Kubernets cluster monitors the resource information stored in the storage area of each slave Kubernets cluster, a basis is provided for the subsequent establishment of a communication channel of each node in the main Kubernets cluster and each slave Kubernets cluster, and the data transmission between the Kubernets clusters is facilitated.
On the basis of the above technical solution, the communication method between kubernets clusters may further include: in response to a target deletion instruction from a target node of a Kubernetes cluster, deleting attribute information of the target node from a storage area of the main Kubernetes cluster; and releasing the communication channel between the target node and each reference node.
In a specific implementation, if a master Kubernetes cluster monitors that a target deletes a target node from the Kubernetes cluster, the attribute information of the target node can be deleted in a storage area; further, the communication channel between the target node and each reference node in the kubernets cluster can be released.
The advantage of setting up like this lies in, can handle the communication channel that fails in time, saved storage space to the phenomenon that sends data to the node that fails can not appear, promoted the communication efficiency between the Kubernetes cluster.
EXAMPLE III
Fig. 3 is a flowchart of a communication method between kubernets clusters in a third embodiment of the present invention, where this embodiment is a further refinement of the foregoing technical solutions, and the technical solution in this embodiment may be combined with various alternatives in one or more of the foregoing embodiments. As shown in fig. 3, the communication method between kubernets clusters may include the following steps:
and step 310, establishing access connection between the master Kubernets cluster and each slave Kubernets cluster.
The parameter information of the shared service may include a name of the shared service or other information, which is not limited in this embodiment.
In an optional implementation manner of this embodiment, after the communication channels between the target node and each of the reference nodes are respectively established, that is, under the condition that it is ensured that the master kubernets cluster and each of the slave kubernets clusters can perform point-to-point communication, the shared service in the clusters can be further acquired, and parameter information of the shared service is synchronized into the storage area; if the target is added with a new target sharing service from the Kubernets cluster, whether a reference sharing service which is the same as the parameter information of the new target sharing service is stored in the storage area or not can be determined; if so, not processing the target sharing service; if not, a target shared service is created in the master Kubernets cluster.
In an optional implementation manner of this embodiment, when a vector-controller of a main kubernets cluster is started, all shared service (shared service) information of a current cluster may be acquired according to a filter condition (vector.alpha.io/shared-service: "true"), and the information is updated into a storage area; the specific content may be endpoint list information corresponding to the service.
Further, the vector-controller monitors the shared service event of the current cluster according to a filter condition (vector. alpha. io/shared-service: "true"), and writes the information of the service into the storage area of the current cluster when new shared services are added. Meanwhile, when a shared service is deleted from the cluster, information of the service is deleted from the storage area of the current cluster. And meanwhile, the endpoint event is monitored, and when endpoint with the same name as the shared service is changed, the information of the storage area is updated.
Further, the vector-controller monitors information of storage areas of other clusters, and when a new shared service is added to the other clusters, it is first detected whether the current cluster has a shared service with the same name:
when no shared service with the same name exists, the shared service with the same name is created in the current cluster, but the shared service does not contain a podSelector, the shared service is marked as vector.alpha.io/scope: < cluster-name >, and meanwhile, an endpoint with the same name is created, and the content is the content stored in the storage area of other clusters; because the shared service does not contain the podSelector, when the end and the shared service name are the same, the kube-proxy is directly triggered to issue a corresponding load balancing strategy according to the content of the end, and the effect of balancing the load to other cluster points is achieved.
When the shared service with the same name exists, if the shared service contains vector, alpha, io/scope < cluster-name >, the endpoint information with the same name is directly updated, the updated content is the content of the storage area of other clusters, and then the kube-proxy is triggered to re-issue a new IPVS strategy according to the content of the latest endpoint, so that the effect of automatically synchronizing the load balancing objects of other clusters is achieved.
When the shared service with the same name exists, if the shared service does not contain vector.alpha.io/scope: < cluster-name >, a waring log is recorded, and then processing is not carried out, namely the shared service does not support the service with the same name in other clusters.
In the scheme of this embodiment, at least one shared service may also be acquired, and parameter information of each shared service is synchronized to the storage area; in response to an increase instruction of a target shared service of a target slave Kubernets cluster, determining whether a reference shared service which is the same as parameter information of the target shared service is stored in the storage area; if yes, the target sharing service is not processed; otherwise, the target shared service is created in the main Kubernetes cluster, and for shared services among the clusters, service discovery can be intelligently achieved, that is, the service which the cluster needs to be shared can enable other clusters to normally identify the service of the current cluster through an intelligent control mode, no matter which cluster accesses the service, the request is forwarded to the service Pod of the cluster to which the service belongs, and the same result can be returned.
Example four
Fig. 4 is a flowchart of a communication method between kubernets clusters in a fourth embodiment of the present invention, where this embodiment is a further refinement of the foregoing technical solutions, and the technical solution in this embodiment may be combined with various alternatives in one or more of the foregoing embodiments. As shown in fig. 4, the communication method between kubernets clusters may include the following steps:
and step 410, establishing access connection between the master Kubernets cluster and each slave Kubernets cluster.
The target application involved in this embodiment is any Pod in the kubernets cluster, the Pod is the minimum or simplest basic unit created or deployed by the kubernets, and one Pod represents a process running on the kubernets cluster.
In an optional implementation manner of this embodiment, after the communication channels between the target node and each of the reference nodes are respectively established, that is, under the condition that it is ensured that the master kubernets cluster and each of the slave kubernets clusters can perform peer-to-peer communication, if an access instruction to a target high available service in the master kubernets cluster is received, it may be further determined whether a target application corresponding to the target high available service exists in the master kubernets cluster; if the main Kubernetes cluster has a target application corresponding to the target high-availability service, the target high-availability service can be forwarded to the target application for processing; if the target application corresponding to the target high available service does not exist in the main Kubernets cluster, the target application corresponding to the target high available service can be detected in other slave Kubernets clusters, and the target high available service is forwarded to the target application of the target slave Kubernets cluster for processing.
In an optional implementation manner of this embodiment, when the vector-controller starts, according to the filter condition vector.alpha.io/ha-service: "true", information of all high available services (ha-services) of the current cluster is obtained, and a resource change of the high available services is continuously monitored.
Further, a corresponding mirror-service is created in the current cluster for each high-availability service, wherein the mirror-service contains the same label, namespace, podSelector, port information, the name of which is the original service plus the "-mirror" suffix, and additionally marked as mirror-service: "true"; if an endpoint event with the same name as the mirrorservice is listened to, the listened content is updated into the storage area.
Further, updating the content of the current high-availability service, deleting the point selector, deleting the endpoint and endpointslice objects with the same name, creating the endpoint with the same name as the high-availability service, and setting the content of the endpoint according to the ha mode.
If no label of vector.alpha.io/ha-mode exists in the high-availability service or the label is vector.alpha.io/ha-mode: "ab", checking whether an endpoint list exists in the content in the storage area of the current cluster or not; if so, updating the content of the endpoint to the content of the current cluster storage area; and if not, acquiring the contents of the storage areas of other clusters and updating endpoint.
If the high available service flag is vector.alpha.io/ha-mode: "aa", the contents of the storage regions of all clusters are retrieved and endpoint is updated.
In the scheme of this embodiment, it may also be determined, in response to an access instruction of a target high available service in a master kubernets cluster, whether there is a target application corresponding to the target high available service in the master kubernets cluster; if so, forwarding the target high available service to the target application for processing; otherwise, a target application corresponding to the target high-availability service is detected in each Kubernetes cluster, the target high-availability service is forwarded to the target application for processing, load balancing across clusters can be achieved for the high-availability service, each service has a high-availability redundancy function among multiple clusters, and a primary/standby or multi-active high-availability mode can be selected according to the requirement of the service on time delay.
In the prior art, in order to include services inside the kubernets cluster for external or other cluster access, the following two ways are generally adopted: one is an overlay virtual network based on a tunnel technology, such as a flannel, an antrea, and the like, and there are various tunnel technologies that can be used in the virtual network, such as a vxlan tunnel, an ipsec tunnel, and the like, when a Pod accesses a Pod of another node, a message of a source Pod reaches a destination Pod through a tunnel between a source physical node and a destination physical node; and the other is an underlay network based on a physical network card, such as MacVlan, SRIOV and the like, when the Pod accesses the Pod of other nodes, the message of the source Pod is directly sent to the network card of the destination physical node from the network card of the source physical node.
The Kubernetes Pod externally-exposed communication is generally carried out in two modes, the first mode is NodePort, NodePort exposes the internal service externally in a four-layer mode, when in use, NodePort sets a designated port number for the internal service, the external part accesses the internal service by accessing the physical IP of a certain node of the Kubernetes cluster and the port number, and the NodePort automatically forwards a request to the internal service Pod in the accessing process; the second is Ingress, which exposes the internal seven-layer service to the outside in a http/https mode, sets a designated URL for the internal seven-layer service when in use, accesses the internal seven-layer service by accessing the physical IP of any Ingress node and the URL outside, forwards a request to the internal service Pod in a Nginx proxy mode inside the Ingress, and realizes four-layer load balancing in a latest version by a certain configuration, and can access the corresponding service by using the physical IP of the Ingress node and the designated Port.
In the prior art, both native cross-cluster communication modes of a community are centralized, that is, internal services are exposed through a certain node, so that a single-point fault problem exists in the condition, when the accessed node fails and is unavailable, the communication capacity of services is seriously influenced, and the two modes also have a single-point performance bottleneck, when a plurality of high-load applications are intensively communicated through a certain node, bandwidth contention exists, and normal communication among the services cannot be guaranteed when a plurality of large-scale clusters are communicated with each other; meanwhile, when the communication between the clusters is performed through the two manners, the source IP address changes due to the existence of one-layer forwarding, and the real source IP address cannot be acquired inside the destination Pod, which finally causes that part of applications cannot work normally. And part of cross-cluster applications have a point-to-point communication requirement, and the IP of Pod cannot be directly exposed to the outside in the community native mode, so that the requirement cannot be well met, and a user needs to spend a certain cost to modify the application to adapt to the community native external exposure mode.
The Kubernets cluster communication method provided by the embodiment of the invention is a fully distributed cross-cluster network communication mode, through which the Pod between clusters can directly perform point-to-point communication without forwarding of an intermediate fixed node, the cross-cluster service communication performance is improved, and on the basis, domain names between clusters can be mutually identified (service discovery) according to certain setting, so that the applications between clusters can directly access each other, the cross-cluster application communication mode is completely consistent with the cluster internal application communication mode, the two problems of single-point failure and single-node performance bottleneck can be thoroughly solved, and the use habit of a user on cluster application can not be changed. Meanwhile, each application can be highly available in a cluster range, and a master-standby or multi-active high-availability mode can be realized for different applications, so that the disaster tolerance capability of the applications is greatly improved.
EXAMPLE five
Fig. 5 is a schematic structural diagram of a communication device between kubernets clusters according to a fifth embodiment of the present invention, where the device may execute the communication method between kubernets clusters according to the foregoing embodiments. Referring to fig. 5, the apparatus includes: an attribute information synchronization module 510, a communication channel establishment module 520, and a data synchronization module 530.
An attribute information synchronization module 510, configured to synchronize, in response to an add instruction of a target node of a target slave kubernets cluster, attribute information of the target node into a storage area of the master kubernets cluster;
a communication channel establishing module 520, configured to respectively establish a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the master kubernets cluster;
a data synchronization module 530, configured to synchronize data to be synchronized from a target reference node to a target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
In the scheme of this embodiment, an attribute information synchronization module is used to respond to an instruction of adding a target node of a target slave kubernets cluster, and synchronize the attribute information of the target node into a storage area of the master kubernets cluster; respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster through a communication channel establishing module; the data synchronization module responds to a synchronization instruction of data to be synchronized in a target reference node, and the data to be synchronized is synchronized to the target node from the target reference node through a target communication channel, so that the problems that in the prior art, when a gateway node fails or fails, normal communication cannot be performed between two Kubernets, and the communication efficiency is low are solved, and point-to-point communication between the Kubernets is realized.
In an optional implementation manner of this embodiment, the apparatus for communication between kubernets clusters further includes: access connection establishment module for
And establishing access connection between the master Kubernets cluster and each slave Kubernets cluster, so that the master Kubernets cluster monitors the resource information stored in the storage area of each slave Kubernets cluster.
In an optional implementation manner of this embodiment, the attribute information synchronization module 510 is specifically configured to
When the main Kubernetes cluster monitors that a target node is added to the target from the Kubernetes cluster through the access connection, synchronizing the attribute information of the target node stored in the storage area of the target slave Kubernetes cluster to the storage area of the main Kubernetes cluster through the access connection;
wherein the attribute information of the target node includes at least one of: the network segment information of the node, the physical address MAC of the node tunnel equipment and the IP address of the node tunnel equipment.
In an optional implementation manner of this embodiment, the communication channel establishing module 520 is specifically configured to
Respectively establishing a communication channel between a target node and each reference node according to the IP address of the target node and the IP address of each reference node;
respectively establishing communication channels between the target node and the reference nodes according to the network segment information of the target node and the network segment information of the reference nodes;
respectively establishing a communication channel between a target node and each reference node according to the MAC address of the node tunnel equipment of the target node and the MAC address of the node tunnel equipment of each reference node;
and respectively establishing a communication channel between the target node and each reference node according to the IP address of the node tunnel equipment of the target node and the IP address of the node tunnel equipment of each reference node.
In an optional implementation manner of this embodiment, the apparatus for communication between kubernets clusters further includes: communication channel deletion module for
In response to a target deletion instruction from a target node of a Kubernetes cluster, deleting attribute information of the target node from a storage area of the main Kubernetes cluster;
and releasing the communication channel between the target node and each reference node.
In an optional implementation manner of this embodiment, the apparatus for communication between kubernets clusters further includes: shared service processing module for
Acquiring at least one sharing service, and synchronizing the parameter information of each sharing service into a storage area;
in response to an increase instruction of a target shared service of a target slave Kubernets cluster, determining whether a reference shared service which is the same as parameter information of the target shared service is stored in the storage area;
if yes, the target sharing service is not processed;
otherwise, the target shared service is created in the master Kubernets cluster.
In an optional implementation manner of this embodiment, the apparatus for communication between kubernets clusters further includes: highly available service processing module for
In response to an access instruction of a target high available service in the main Kubernets cluster, determining whether a target application corresponding to the target high available service exists in the main Kubernets cluster;
if so, forwarding the target high available service to the target application for processing;
otherwise, detecting a target application corresponding to the target high-availability service in each Kubernetes cluster, and forwarding the target high-availability service to the target application for processing.
The communication device between Kubernets clusters provided by the embodiment of the invention can execute the communication method between Kubernets clusters provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method.
EXAMPLE six
Fig. 6 is a schematic structural diagram of a computer apparatus according to a sixth embodiment of the present invention, as shown in fig. 6, the computer apparatus includes a processor 60, a memory 61, an input device 62, and an output device 63; the number of processors 60 in the computer device may be one or more, and one processor 60 is taken as an example in fig. 6; the processor 60, the memory 61, the input device 62 and the output device 63 in the computer apparatus may be connected by a bus or other means, and the connection by the bus is exemplified in fig. 6.
The memory 61 is used as a computer-readable storage medium for storing software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the kubernets inter-cluster communication method in the embodiment of the present invention (for example, the attribute information synchronization module 510, the communication channel establishment module 520, and the data synchronization module 530 in the kubernets inter-cluster communication device). The processor 60 executes various functional applications of the computer device and data processing by running software programs, instructions and modules stored in the memory 61, that is, implements the above-described communication method between kubernets clusters.
The memory 61 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the terminal, and the like. Further, the memory 61 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, the memory 61 may further include memory located remotely from the processor 60, which may be connected to a computer device over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The input device 62 may be used to receive input numeric or character information and to generate key signal inputs relating to user settings and function controls of the computer apparatus. The output device 63 may include a display device such as a display screen.
EXAMPLE seven
An embodiment of the present invention further provides a storage medium containing computer-executable instructions, where the computer-executable instructions are executed by a computer processor to perform a method for communication between kubernets clusters, where the method includes:
in response to an add instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of the master Kubernets cluster;
respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster;
synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
Of course, the storage medium provided by the embodiment of the present invention contains computer-executable instructions, and the computer-executable instructions are not limited to the operations of the method described above, and may also perform related operations in the method for communication between kubernets clusters provided by any embodiment of the present invention.
From the above description of the embodiments, it is obvious for those skilled in the art that the present invention can be implemented by software and necessary general hardware, and certainly, can also be implemented by hardware, but the former is a better embodiment in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a floppy disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a FLASH Memory (FLASH), a hard disk or an optical disk of a computer, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute the methods according to the embodiments of the present invention.
It should be noted that, in the embodiment of the communication apparatus between kubernets clusters, the included units and modules are merely divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be implemented; in addition, specific names of the functional units are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present invention.
It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.
Claims (15)
1. A communication method between Kubernets clusters is applied to a main Kubernets cluster, and is characterized by comprising the following steps:
in response to an add instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of the master Kubernets cluster;
respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster;
synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
2. The method of claim 1, further comprising, prior to responding to an add instruction by the target from a target node of a Kubernetes cluster:
and establishing access connection between the master Kubernets cluster and each slave Kubernets cluster, so that the master Kubernets cluster monitors the resource information stored in the storage area of each slave Kubernets cluster.
3. The method of claim 2, wherein said synchronizing attribute information of a target node of a target slave kubernets cluster into a storage area of the master kubernets cluster in response to an add instruction of the target node comprises:
when the main Kubernetes cluster monitors that a target node is added to the target from the Kubernetes cluster through the access connection, synchronizing the attribute information of the target node stored in the storage area of the target slave Kubernetes cluster to the storage area of the main Kubernetes cluster through the access connection;
wherein the attribute information of the target node includes at least one of: the network segment information CIDR of the node, the physical address MAC of the node tunnel equipment and the IP address of the node tunnel equipment.
4. The method according to claim 3, wherein the establishing a communication channel between the target node and each of the reference nodes according to the attribute information of the target node and the attribute information of at least one of the reference nodes of the master Kubernets cluster respectively comprises one of:
respectively establishing a communication channel between a target node and each reference node according to the IP address of the target node and the IP address of each reference node;
respectively establishing communication channels between the target node and the reference nodes according to the network segment information of the target node and the network segment information of the reference nodes;
respectively establishing a communication channel between a target node and each reference node according to the MAC address of the node tunnel equipment of the target node and the MAC address of the node tunnel equipment of each reference node;
and respectively establishing a communication channel between the target node and each reference node according to the IP address of the node tunnel equipment of the target node and the IP address of the node tunnel equipment of each reference node.
5. The method of claim 1, further comprising:
in response to a target deletion instruction from a target node of a Kubernetes cluster, deleting attribute information of the target node from a storage area of the main Kubernetes cluster;
and releasing the communication channel between the target node and each reference node.
6. The method of claim 1, further comprising:
acquiring at least one sharing service, and synchronizing the parameter information of each sharing service into a storage area;
in response to an increase instruction of a target shared service of a target slave Kubernets cluster, determining whether a reference shared service which is the same as parameter information of the target shared service is stored in the storage area;
if yes, the target sharing service is not processed;
otherwise, the target shared service is created in the master Kubernets cluster.
7. The method of claim 1, further comprising:
in response to an access instruction of a target high available service in the main Kubernets cluster, determining whether a target application corresponding to the target high available service exists in the main Kubernets cluster;
if so, forwarding the target high available service to the target application for processing;
otherwise, detecting a target application corresponding to the target high-availability service in each Kubernetes cluster, and forwarding the target high-availability service to the target application for processing.
8. A computer device comprising a processor and a memory, the memory storing instructions that, when executed, cause the processor to:
in response to an add instruction of a target node of a target slave Kubernets cluster, synchronizing attribute information of the target node into a storage area of the master Kubernets cluster;
respectively establishing a communication channel between the target node and each reference node according to the attribute information of the target node and the attribute information of at least one reference node of the main Kubernetes cluster;
synchronizing data to be synchronized from a target reference node to the target node through a target communication channel in response to a synchronization instruction of the data to be synchronized in the target reference node.
9. The computer device of claim 8, wherein the processor is further configured to:
and establishing access connection between the master Kubernets cluster and each slave Kubernets cluster, so that the master Kubernets cluster monitors the resource information stored in the storage area of each slave Kubernets cluster.
10. The computer device of claim 9, wherein the processor is configured to synchronize the attribute information of the target node to the storage area of the master kubernets cluster in response to an add instruction of the target node from a kubernets cluster by:
when the main Kubernetes cluster monitors that a target node is added to the target from the Kubernetes cluster through the access connection, synchronizing the attribute information of the target node stored in the storage area of the target slave Kubernetes cluster to the storage area of the main Kubernetes cluster through the access connection;
wherein the attribute information of the target node includes at least one of: the network segment information of the node, the physical address MAC of the node tunnel equipment and the IP address of the node tunnel equipment.
11. The computer device of claim 10, wherein the processor is configured to establish a communication channel between the target node and each of the reference nodes according to the attribute information of the target node and the attribute information of at least one of the reference nodes of the master kubernets cluster by one of:
respectively establishing a communication channel between a target node and each reference node according to the IP address of the target node and the IP address of each reference node;
respectively establishing communication channels between the target node and the reference nodes according to the network segment information of the target node and the network segment information of the reference nodes;
respectively establishing a communication channel between a target node and each reference node according to the MAC address of the node tunnel equipment of the target node and the MAC address of the node tunnel equipment of each reference node;
and respectively establishing a communication channel between the target node and each reference node according to the IP address of the node tunnel equipment of the target node and the IP address of the node tunnel equipment of each reference node.
12. The computer device of claim 8, wherein the processor is further configured to:
in response to a target deletion instruction from a target node of a Kubernetes cluster, deleting attribute information of the target node from a storage area of the main Kubernetes cluster;
and releasing the communication channel between the target node and each reference node.
13. The computer device of claim 8, wherein the processor is further configured to:
acquiring at least one sharing service, and synchronizing the parameter information of each sharing service into a storage area;
in response to an increase instruction of a target shared service of a target slave Kubernets cluster, determining whether a reference shared service which is the same as parameter information of the target shared service is stored in the storage area;
if yes, the target sharing service is not processed;
otherwise, the target shared service is created in the master Kubernets cluster.
14. The computer device of claim 8, wherein the processor is further configured to:
in response to an access instruction of a target high available service in the main Kubernets cluster, determining whether a target application corresponding to the target high available service exists in the main Kubernets cluster;
if so, forwarding the target high available service to the target application for processing;
otherwise, detecting a target application corresponding to the target high-availability service in each Kubernetes cluster, and forwarding the target high-availability service to the target application for processing.
15. A storage medium containing computer-executable instructions for performing the method of communication between kubernets clusters as claimed in any one of claims 1-7 when executed by a computer processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110825216.1A CN113572831B (en) | 2021-07-21 | 2021-07-21 | Communication method, computer equipment and medium between Kubernetes clusters |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110825216.1A CN113572831B (en) | 2021-07-21 | 2021-07-21 | Communication method, computer equipment and medium between Kubernetes clusters |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113572831A true CN113572831A (en) | 2021-10-29 |
| CN113572831B CN113572831B (en) | 2024-03-15 |
Family
ID=78165950
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110825216.1A Active CN113572831B (en) | 2021-07-21 | 2021-07-21 | Communication method, computer equipment and medium between Kubernetes clusters |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113572831B (en) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114827017A (en) * | 2022-03-31 | 2022-07-29 | 北京声智科技有限公司 | Kafka cluster communication method and device, electronic equipment and storage medium |
| CN114938394A (en) * | 2022-04-13 | 2022-08-23 | 京东科技信息技术有限公司 | Cross-cluster network control method, device, equipment and storage medium |
| CN115086330A (en) * | 2022-06-14 | 2022-09-20 | 亚信科技（中国）有限公司 | Cross-cluster load balancing system |
| CN115150410A (en) * | 2022-07-19 | 2022-10-04 | 京东科技信息技术有限公司 | Multi-cluster access method and system |
| CN115473766A (en) * | 2022-08-22 | 2022-12-13 | 苏州思萃工业互联网技术研究所有限公司 | Method and system for realizing vip based on distributed gateway |
| CN115878378A (en) * | 2022-11-23 | 2023-03-31 | 北京凌云雀科技有限公司 | Cloud-native-based two-place three-center database disaster tolerance system deployment method and device |
| CN116614348A (en) * | 2023-07-19 | 2023-08-18 | 联想凌拓科技有限公司 | System for remote copy service and method of operating the same |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110765203A (en) * | 2019-09-29 | 2020-02-07 | 烽火通信科技股份有限公司 | Method and system for realizing MySQL master-slave synchronization and performance acquisition of container |
| CN110808857A (en) * | 2019-10-31 | 2020-02-18 | 深圳前海环融联易信息科技服务有限公司 | Network intercommunication method, device, equipment and storage medium for realizing Kubernetes cluster |
| CN111885123A (en) * | 2020-07-06 | 2020-11-03 | 苏州浪潮智能科技有限公司 | Construction method and device of cross-K8 s target service access channel |
| CN112003728A (en) * | 2020-07-24 | 2020-11-27 | 苏州浪潮智能科技有限公司 | Kubernetes cluster-based application master and standby implementation method and device |
| CN112214330A (en) * | 2020-11-04 | 2021-01-12 | 腾讯科技（深圳）有限公司 | Method and device for deploying master nodes in cluster and computer-readable storage medium |
| CN112434008A (en) * | 2020-11-18 | 2021-03-02 | 星环信息科技(上海)股份有限公司 | Distributed database upgrading method, device and medium |
| WO2021051880A1 (en) * | 2019-09-18 | 2021-03-25 | 平安科技（深圳）有限公司 | Resource data acquisition method and apparatus, computer device and storage medium |
| CN112751913A (en) * | 2020-12-22 | 2021-05-04 | 联奕科技股份有限公司 | Network communication method and system across Kubernetes cluster |
| CN112866408A (en) * | 2021-02-09 | 2021-05-28 | 山东英信计算机技术有限公司 | Service switching method, device, equipment and storage medium in cluster |
| CN113031874A (en) * | 2021-03-26 | 2021-06-25 | 网易（杭州）网络有限公司 | Cache processing method, device, equipment and storage medium based on Kubernetes cluster |
-
2021
- 2021-07-21 CN CN202110825216.1A patent/CN113572831B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021051880A1 (en) * | 2019-09-18 | 2021-03-25 | 平安科技（深圳）有限公司 | Resource data acquisition method and apparatus, computer device and storage medium |
| CN110765203A (en) * | 2019-09-29 | 2020-02-07 | 烽火通信科技股份有限公司 | Method and system for realizing MySQL master-slave synchronization and performance acquisition of container |
| CN110808857A (en) * | 2019-10-31 | 2020-02-18 | 深圳前海环融联易信息科技服务有限公司 | Network intercommunication method, device, equipment and storage medium for realizing Kubernetes cluster |
| CN111885123A (en) * | 2020-07-06 | 2020-11-03 | 苏州浪潮智能科技有限公司 | Construction method and device of cross-K8 s target service access channel |
| CN112003728A (en) * | 2020-07-24 | 2020-11-27 | 苏州浪潮智能科技有限公司 | Kubernetes cluster-based application master and standby implementation method and device |
| CN112214330A (en) * | 2020-11-04 | 2021-01-12 | 腾讯科技（深圳）有限公司 | Method and device for deploying master nodes in cluster and computer-readable storage medium |
| CN112434008A (en) * | 2020-11-18 | 2021-03-02 | 星环信息科技(上海)股份有限公司 | Distributed database upgrading method, device and medium |
| CN112751913A (en) * | 2020-12-22 | 2021-05-04 | 联奕科技股份有限公司 | Network communication method and system across Kubernetes cluster |
| CN112866408A (en) * | 2021-02-09 | 2021-05-28 | 山东英信计算机技术有限公司 | Service switching method, device, equipment and storage medium in cluster |
| CN113031874A (en) * | 2021-03-26 | 2021-06-25 | 网易（杭州）网络有限公司 | Cache processing method, device, equipment and storage medium based on Kubernetes cluster |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114827017A (en) * | 2022-03-31 | 2022-07-29 | 北京声智科技有限公司 | Kafka cluster communication method and device, electronic equipment and storage medium |
| CN114827017B (en) * | 2022-03-31 | 2024-01-30 | 北京声智科技有限公司 | Communication method and device of Kafka cluster, electronic equipment and storage medium |
| CN114938394A (en) * | 2022-04-13 | 2022-08-23 | 京东科技信息技术有限公司 | Cross-cluster network control method, device, equipment and storage medium |
| CN114938394B (en) * | 2022-04-13 | 2024-05-17 | 京东科技信息技术有限公司 | Cross-cluster network control method, device, equipment and storage medium |
| CN115086330A (en) * | 2022-06-14 | 2022-09-20 | 亚信科技（中国）有限公司 | Cross-cluster load balancing system |
| CN115086330B (en) * | 2022-06-14 | 2024-03-01 | 亚信科技（中国）有限公司 | Cross-cluster load balancing system |
| CN115150410A (en) * | 2022-07-19 | 2022-10-04 | 京东科技信息技术有限公司 | Multi-cluster access method and system |
| CN115473766A (en) * | 2022-08-22 | 2022-12-13 | 苏州思萃工业互联网技术研究所有限公司 | Method and system for realizing vip based on distributed gateway |
| CN115473766B (en) * | 2022-08-22 | 2024-01-26 | 苏州思萃工业互联网技术研究所有限公司 | Vip implementation method and system based on distributed gateway |
| CN115878378A (en) * | 2022-11-23 | 2023-03-31 | 北京凌云雀科技有限公司 | Cloud-native-based two-place three-center database disaster tolerance system deployment method and device |
| CN115878378B (en) * | 2022-11-23 | 2023-09-05 | 北京凌云雀科技有限公司 | Cloud-protogenesis-based two-place three-center database disaster recovery system deployment method and device |
| CN116614348A (en) * | 2023-07-19 | 2023-08-18 | 联想凌拓科技有限公司 | System for remote copy service and method of operating the same |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113572831B (en) | 2024-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113572831B (en) | Communication method, computer equipment and medium between Kubernetes clusters | |
| CN107947961B (en) | SDN-based Kubernetes network management system and method | |
| JP6498230B2 (en) | Flexible HDD / SSD storage support system and method | |
| US20190196921A1 (en) | High availability and failovers | |
| WO2017162173A1 (en) | Method and device for establishing connection of cloud server cluster | |
| CN110290174B (en) | Control method and control node of main master cluster | |
| US9992058B2 (en) | Redundant storage solution | |
| US10320905B2 (en) | Highly available network filer super cluster | |
| EP3788772B1 (en) | On-node dhcp implementation for virtual machines | |
| US11403319B2 (en) | High-availability network device database synchronization | |
| CN109462511B (en) | Network establishing method and device | |
| CN114500169B (en) | Method for establishing VXLAN tunnel, method and device for forwarding message | |
| WO2017114363A1 (en) | Packet processing method, bng and bng cluster system | |
| WO2020057445A1 (en) | Communication system, method, and device | |
| CN113364741A (en) | Application access method and proxy server | |
| US20200204481A1 (en) | Fast redirect of traffic when pods fail | |
| CN115086312A (en) | Method and system for realizing kubernets service cross-cluster communication | |
| CN115225634B (en) | Data forwarding method, device and computer program product under virtual network | |
| CN113904973B (en) | Route updating method, medium, device and computing equipment | |
| US11870646B2 (en) | Fabric availability and synchronization | |
| CN114422280B (en) | Network deployment method, device, node and storage medium | |
| CN116743845B (en) | Edge service discovery method, device, node equipment and readable storage medium | |
| CN117040933B (en) | Cross-regional network drainage processing method, security processing method, device and equipment | |
| CN113014426B (en) | Method and device for establishing communication between cloud server and client server | |
| CN116366370B (en) | Asymmetric communication method, system, storage medium and communication 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 |