Cluster network access method and system

Abstract

The application discloses a cluster network access method, which is applied to an operator module in a kubernetes cluster to be taken over, and the method comprises the following steps: listening to a user-input custom resource, and determining whether takeover information required for taking over the kubernetes cluster to be taken over is included in the custom resource; if yes, executing takeover processing logic corresponding to the takeover information defined in the operator module, acquiring configuration information corresponding to the kubernetes cluster to be taken over included in the takeover information, and respectively delivering the acquired configuration information to each kubernetes cluster to be taken over, so as to complete the automatic takeover of each kubernetes cluster to be taken over.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of container orchestration technology, and in particular to a cluster network access method and system. Background Technology

[0002] Container orchestration refers to the automation of container deployment, management, scaling, and networking. It can provide convenience for enterprises that need to deploy and manage multiple containers. Among them, Kubernetes cluster, or k8s cluster for short, is an open-source container orchestration system and a microservices and cloud-native platform. k8s cluster allows users to schedule and run containers across machines on-premises or in the cloud. Summary of the Invention

[0003] To address the aforementioned technical problems, this application provides a method and system for accessing a cluster network, the technical solution of which is as follows:

[0004] According to a first aspect of this application, a cluster network access method is provided, applied to an operator module in a Kubernetes cluster to be taken over, the method comprising:

[0005] Listen for user-inputted custom resources and determine whether the custom resources include the takeover information required to take over the Kubernetes cluster to be taken over;

[0006] If so, execute the takeover processing logic defined in the operator module corresponding to the takeover information, obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information, and send the obtained configuration information to each Kubernetes cluster to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

[0007] Optionally, the takeover information includes network information parameters of the Kubernetes cluster to be taken over;

[0008] The process involves executing the takeover processing logic defined in the operator module corresponding to the takeover information, and obtaining the configuration information corresponding to the Kubernetes cluster to be taken over, contained in the takeover information, including:

[0009] Store the network information parameters of the Kubernetes cluster to be taken over into the database;

[0010] Based on the network information parameters in the database corresponding to the Kubernetes clusters to be taken over, generate routing information corresponding to all Kubernetes clusters to be taken over.

[0011] Optionally, the takeover information may also include the account and password of the control node of the Kubernetes cluster to be taken over, as well as the address of the authentication information.

[0012] The process involves executing the takeover processing logic defined in the operator module corresponding to the takeover information, and obtaining the configuration information corresponding to the Kubernetes cluster to be taken over, contained in the takeover information, including:

[0013] Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over;

[0014] Based on the address of the authentication information corresponding to the Kubernetes cluster to be taken over, obtain the authentication information corresponding to the Kubernetes cluster to be taken over, and store the authentication information in the database;

[0015] Based on the authentication information corresponding to the Kubernetes clusters to be taken over in the database, generate the sum of authentication information for all Kubernetes clusters to be taken over.

[0016] Optionally, before distributing the configuration information to each Kubernetes cluster to be taken over, the method further includes:

[0017] Create a service mesh containing the first root certificate and determine whether the Kubernetes cluster to be taken over has a service mesh instance installed that corresponds to the service mesh that does not contain the first root certificate.

[0018] If so, uninstall the service mesh instance corresponding to the service mesh that does not contain the first root certificate, and reinstall the service mesh instance corresponding to the service mesh that contains the first root certificate in the Kubernetes cluster to be taken over.

[0019] If not, install the service mesh instance corresponding to the service mesh containing the first root certificate on the Kubernetes cluster to be taken over.

[0020] Optionally, the configuration information includes routing information;

[0021] The step of distributing the configuration information to each Kubernetes cluster to be taken over includes:

[0022] Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over;

[0023] The routing information corresponding to all Kubernetes clusters to be taken over will be sent to the logged-in Kubernetes clusters to be taken over.

[0024] Optionally, the configuration information includes authentication information;

[0025] The step of distributing the configuration information to each Kubernetes cluster to be taken over includes:

[0026] Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over;

[0027] The authentication information of all Kubernetes clusters awaiting takeover is summed and sent to the logged-in Kubernetes cluster awaiting takeover.

[0028] According to a second aspect of this application, a cluster network access system is provided, applied to an operator module in a Kubernetes cluster to be taken over, the system comprising:

[0029] The listening unit is used to listen to the user's input of custom resources and determine whether the custom resources include the takeover information required to take over the Kubernetes cluster to be taken over.

[0030] The execution unit is used to execute the takeover processing logic defined in the operator module corresponding to the takeover information, obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information, and send the obtained configuration information to each Kubernetes cluster to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

[0031] By applying the technical solution provided in this application, when taking over a Kubernetes cluster, the operator module in the Kubernetes cluster to be taken over can be triggered to automatically take over all Kubernetes clusters to be taken over by listening to user-inputted custom resources. On the one hand, since no manual takeover is required, the complex and tedious manual configuration required for cluster takeover is avoided. On the other hand, since the automation function of the operator module can be used to complete the cluster takeover execution logic, communication between clusters across networks can be easily realized even in cloud environments that have not purchased the LoadBalancer service provided by cloud vendors.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0034] Figure 1 Here is a flowchart illustrating an exemplary method for accessing a cluster network;

[0035] Figure 2 This is a schematic diagram of the structure of the electronic device containing the cluster network access device in one embodiment of this specification;

[0036] Figure 3 This is a block diagram of a cluster network access device in one embodiment of this specification. Detailed Implementation

[0037] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0038] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0039] To enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the relevant technologies for material procurement involved in the embodiments of this specification will be briefly described below.

[0040] As an open-source system that enables the automatic deployment, scaling, and management of containerized applications, Kubernetes clusters provide a range of functions, including container orchestration, resource scheduling, elastic scaling, deployment management, and service discovery. However, as a microservices and cloud-native platform, Kubernetes clusters inevitably include a major drawback of microservices architecture: more complex network communication, especially the difficulty of communication between clusters across different networks.

[0041] In current technology, the LoadBalancer service provided by cloud vendors can inject sidecar proxies into each cluster according to the requirements of the service mesh instance. The control panel corresponding to the service mesh instance in each cluster can discover the workloads running on other clusters by accessing the remote Kubernetes API server, i.e., the API Server, and can enable Pods running on different clusters to communicate directly by accessing the Gateway, thereby realizing communication between clusters across the network.

[0042] However, the LoadBalancer service provided by cloud vendors is expensive. For cloud environments that have not purchased this service, if they want to achieve communication between clusters across networks, the only option is for operations and maintenance personnel to distribute the configuration to each cluster that needs to communicate. This process is too cumbersome and complicated for operations and maintenance personnel.

[0043] In view of this, this specification aims to propose a technical solution that can automatically take over Kubernetes clusters and enable communication between clusters across networks.

[0044] In implementation, the operator module in the Kubernetes cluster can listen to user-inputted custom resources and determine whether the custom resources include the takeover information required to take over the Kubernetes cluster to be taken over.

[0045] If the aforementioned custom resources include the takeover information required for taking over the Kubernetes cluster to be taken over, the takeover processing logic defined in the aforementioned operator module corresponding to the aforementioned takeover information can be executed. The configuration information corresponding to the aforementioned Kubernetes cluster to be taken over contained in the aforementioned takeover information can be obtained, and the obtained configuration information can be distributed to each of the Kubernetes clusters to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

[0046] In the above technical solutions, when taking over a Kubernetes cluster, the operator module in the Kubernetes cluster to be taken over can be triggered by listening to user-inputted custom resources to automatically take over all Kubernetes clusters to be taken over. On the one hand, since no manual takeover is required, the complex and tedious manual configuration required for cluster takeover is avoided. On the other hand, since the automation function of the operator module can be used to complete the cluster takeover execution logic, communication between clusters across networks can be easily achieved even in cloud environments that have not purchased the LoadBalancer service provided by cloud vendors.

[0047] Please see Figure 1 , Figure 1 This is a flowchart illustrating an exemplary method for accessing a cluster network. For example... Figure 1 As shown, this method is applied to the operator module in the Kubernetes cluster to be taken over, and the method may include the following steps:

[0048] S102: Listen for user-inputted custom resources and determine whether the custom resources include the takeover information required to take over the Kubernetes cluster to be taken over.

[0049] The Operator module refers to a type of cloud-native extension service based on Kubernetes Custom Resource Objects (CRDs) and controllers. It can be used to extend the functionality of the Kubernetes API, representing instances of complex applications created, configured, and managed by Kubernetes users. This module is built on the basic concepts of Kubernetes resources and controllers, while also covering knowledge of specific domains or applications. It can be used to automate the application lifecycle managed by the aforementioned controllers. Common functions include deploying applications with specified configurations and numbers, initiating upgrades, automatic backups and fault recovery, and executing any other management application tasks that can be presented as code.

[0050] To implement user-defined functions through the operator module, users can define their own execution logic code for managing custom resources within the operator module. They can also define resources corresponding to the custom functions defined in the operator module. Kubernetes clusters support user-defined resources, among which CR (Custom Resource) is a type of custom resource in Kubernetes clusters. In addition, this custom resource needs to be defined in order for the above-mentioned custom resource generation operation to be successfully executed in the Kubernetes cluster. That is to say, the definition information CRD corresponding to the custom resource needs to be added.

[0051] A Custom Resource Definition (CRD) is a native resource type built into Kubernetes clusters. It can be used to register a new resource in a Kubernetes cluster to extend the cluster's capabilities. Specifically, it can be used to describe the specific form of the custom resource. Kubernetes clusters can only successfully execute the generation operation of the custom resource after executing the CRD corresponding to it.

[0052] When a user wants to take over a cluster, they can encapsulate the takeover information corresponding to all the Kubernetes clusters that need to be taken over into a custom resource and upload it to the Kubernetes cluster via command line. Alternatively, the user can submit the takeover information of the cluster to be taken over through the user-facing web interface provided by the Kubernetes cluster, upload the takeover information to the Kubernetes cluster, and the Kubernetes cluster will complete the encapsulation of the takeover information. This specification does not limit the specific implementation of these methods.

[0053] In practical applications, the aforementioned custom resource can be a user-uploaded YAML file. The user can upload the YAML file via command line, and the command line for uploading the YAML file can be `kubectl apply -f yaml filename`. This specification does not limit the specific commands to these commands.

[0054] In this way, users can choose to trigger the takeover logic of the Kubernetes cluster to be taken over either via command line on the server or by entering takeover information in the web interface, making it convenient for users to automate the takeover of the Kubernetes cluster to be taken over according to their own preferences.

[0055] Once the user has uploaded the aforementioned custom resources, the operator module of the Kubernetes cluster can listen to the user's uploaded custom resources and determine whether the custom resources include the takeover information required for taking over the Kubernetes cluster to be taken over.

[0056] In practical applications, the aforementioned custom resources can be uploaded to the Etcd storage system in the Kubernetes cluster. Etcd is a highly available key-value store and a core component of the Kubernetes cluster, primarily used for shared configuration and service discovery. The operator module can monitor data changes in the Etcd storage system and thus determine whether the custom resources uploaded to the Etcd storage system contain the takeover information required to take over the Kubernetes cluster to be taken over by querying the custom resources uploaded to the Etcd storage system.

[0057] S104: If it is determined that the custom resource includes the takeover information required for taking over the Kubernetes cluster to be taken over, execute the takeover processing logic defined in the operator module corresponding to the takeover information, obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information, and send the obtained configuration information to each Kubernetes cluster to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

[0058] If it is determined that the aforementioned custom resources include the takeover information required for taking over the Kubernetes clusters to be taken over, the aforementioned operator module can execute the takeover processing logic defined in the aforementioned operator module corresponding to the aforementioned takeover information. It can obtain the configuration information corresponding to the aforementioned Kubernetes clusters to be taken over contained in the aforementioned takeover information, and can distribute the obtained configuration information to each of the Kubernetes clusters to be taken over. After the process of distributing the configuration to all the aforementioned Kubernetes clusters to be taken over is completed and the network connectivity and service connectivity tests are passed, the automated takeover process of each Kubernetes cluster to be taken over is completed.

[0059] In one embodiment, the takeover information may include network information parameters of the Kubernetes cluster to be taken over. The takeover processing logic defined in the execution operator module corresponding to the takeover information is used to obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information. This may involve storing the network information parameters of the Kubernetes cluster to be taken over in a database, and generating routing information corresponding to all Kubernetes clusters to be taken over based on the network information parameters corresponding to the Kubernetes cluster to be taken over in the database.

[0060] In practical applications, the aforementioned network information parameters can be gateway information used for cross-network communication. The gateway information can include the port information exposed by the Kubernetes cluster to be taken over and the IP address of any node in the Kubernetes cluster to be taken over.

[0061] The database used to store the aforementioned network information parameters of the Kubernetes cluster to be taken over can be a relational database, such as Oracle, SQL Server, or MySQL, or a NoSQL database, such as MongoDB, Redis, or HBase. These will not be listed in this specification.

[0062] In one embodiment shown, the takeover information may further include the account and password of the control node of the Kubernetes cluster to be taken over, as well as the address of the authentication information. The takeover processing logic defined in the execution operator module corresponding to the takeover information is used to obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information. Alternatively, based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over, one can log in to the Kubernetes cluster to be taken over. According to the address of the authentication information corresponding to the Kubernetes cluster to be taken over, one can obtain the authentication information corresponding to the Kubernetes cluster to be taken over, and store the authentication information in the database. Based on the authentication information corresponding to the Kubernetes cluster to be taken over in the database, the sum of the authentication information of all Kubernetes clusters to be taken over can be generated.

[0063] In practical applications, the account and password of the aforementioned control node can be the account and password of the Master control node of the Kubernetes cluster to be taken over. With this account and password, one can log in to the Kubernetes cluster to be taken over. A network testing tool can be used to test whether the Kubernetes cluster to be taken over has successfully connected to the server. If the test passes, the login is confirmed to be successful. Then, based on the address of the aforementioned authentication information, the kubeconfig file corresponding to the Kubernetes cluster to be taken over can be obtained from the logged-in Kubernetes cluster. Based on the aforementioned kubeconfig file and the aforementioned Master account and password, authentication information corresponding to the Kubernetes cluster to be taken over can be generated and stored in the database.

[0064] In one embodiment shown, before distributing the configuration information to each Kubernetes cluster to be taken over, a service mesh containing the first root certificate can be created. It can be determined whether the Kubernetes cluster to be taken over has a service mesh instance corresponding to the service mesh without the first root certificate installed. If the Kubernetes cluster to be taken over has a service mesh instance corresponding to the service mesh without the first root certificate installed, the service mesh instance corresponding to the service mesh without the first root certificate can be uninstalled, and the service mesh instance corresponding to the service mesh containing the first root certificate can be reinstalled on the Kubernetes cluster to be taken over. If the Kubernetes cluster to be taken over does not have a service mesh instance corresponding to the service mesh without the first root certificate installed, the service mesh instance corresponding to the service mesh containing the first root certificate can be installed on the Kubernetes cluster to be taken over.

[0065] The service mesh mentioned above can be a mesh, which may include a first root certificate. This first root certificate can be a custom root certificate uploaded by the user to the database, or it can be a root certificate generated by the operator module, specifying information such as certificate organization, region, and validity period. Examples of such root certificates are not listed here. The service mesh instance mentioned above can be Istio. The process of installing Istio involves first configuring a certificate issuance certificate for the Kubernetes cluster to be taken over. This certificate can be a certificate issued under the first root certificate. After signing and validating this certificate, different CNI, network models, and control panel models can be selected for different Kubernetes clusters to be taken over, based on the specific usage needs of different users. After completing the Istio installation, a cross-cluster communication gateway (east-wastgateway) and a remote-secret key for inter-cluster communication can be configured and installed. This key can be used to ensure the security of inter-cluster communication.

[0066] In this way, the communication foundation between the Kubernetes clusters to be taken over can be established.

[0067] In one embodiment shown, the configuration information may include routing information. Distributing the configuration information to each Kubernetes cluster to be taken over may include: logging into the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over; and distributing routing information corresponding to all Kubernetes clusters to be taken over to the logged-in Kubernetes cluster to be taken over.

[0068] In practical applications, the Kubernetes clusters to be taken over can be logged into simultaneously using the account and password of the Master control node corresponding to each Kubernetes cluster to be taken over, and then the routing information corresponding to all Kubernetes clusters to be taken over can be distributed in parallel. Alternatively, the Kubernetes clusters to be taken over can be logged into sequentially using the account and password of the Master control node corresponding to each Kubernetes cluster to be taken over, and then the routing information distribution process can be completed sequentially. Examples of each method will not be provided in this manual.

[0069] In one embodiment shown, the configuration information may further include authentication information. The configuration information is distributed to each Kubernetes cluster to be taken over. It may also include: based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over, the Kubernetes cluster to be taken over can be logged in, and the total authentication information of all Kubernetes clusters to be taken over can be distributed to the logged-in Kubernetes cluster to be taken over.

[0070] In practical applications, the Kubernetes clusters to be taken over can be logged into simultaneously using the account and password of the Master control node corresponding to each Kubernetes cluster to be taken over, and then the authentication information of all Kubernetes clusters to be taken over can be distributed in parallel. Alternatively, the Kubernetes clusters to be taken over can be logged into sequentially using the account and password of the Master control node corresponding to each Kubernetes cluster to be taken over, and then the process of distributing the above authentication information can be completed sequentially. Examples of each method will not be provided in this specification.

[0071] After completing the above installation and configuration process, you can also use network pre-testing tools to test the connectivity of the basic network and services. You can run preset test cases and output the test results in the form of logs. If the expected test results are obtained, it can be proven that the takeover was successful. If the test results are not as expected, the logs can also be used by users as a reference for manual testing. In addition, if the takeover fails, the takeover logic can be re-executed on the Kubernetes cluster to be taken over.

[0072] In practical applications, the aforementioned network pre-testing tools can be replaced by the Fortio tool, which also supports load testing and data analysis functions. This manual does not limit the scope of these tools.

[0073] To facilitate understanding of the process of implementing the above material procurement method, this specification uses a specific example, taking the takeover of clusters A, B, and C as an example, to describe this application.

[0074] Users can upload custom resources that can be recognized by the Kubernetes cluster. These custom resources can be stored in the form of YAML files, which can include the account and password information of the Master of Cluster A, Cluster B and Cluster C, the address of the kubeconfig file and network information parameters. Users can upload the above custom resources to the Etcd storage system of the Kubernetes cluster through the command line "kubectl apply -f yaml filename".

[0075] The Operator module can monitor data changes in the Etcd storage system, query custom resources uploaded to the Etcd storage system, determine if the custom resources contain the takeover information required for taking over clusters A, B, and C, and trigger the takeover processing logic for clusters A, B, and C in the operator module.

[0076] The Operator module can store network configuration parameters from the takeover information of clusters A, B, and C to a MySQL database. Based on these network configuration parameters, it can generate routing information corresponding to clusters A, B, and C. It can log in to cluster A using the Master's username and password from the takeover information, retrieve the kubeconfig file of cluster A from its address, and generate authentication information for cluster A based on the Master's username and password and the kubeconfig file. This authentication information can be stored in the MySQL database. Furthermore, it can simultaneously retrieve the authentication information for clusters B and C. The methods for retrieving authentication information for clusters B and C are also described. Similar to obtaining authentication information for cluster A, after storing the authentication information of clusters A, B, and C in a MySQL database, a service mesh (mesh1) can be created, and a root certificate 'a' can be selected for mesh1. It can then be determined whether the service mesh instance 'istio' corresponding to the service mesh that does not contain root certificate 'a' is installed in clusters A, B, and C. If the aforementioned clusters do not have the service mesh instance 'istio' corresponding to the service mesh that does not contain root certificate 'a' installed, then the service mesh instance 'istio' corresponding to mesh1 that contains root certificate 'a' can be directly installed. If the aforementioned clusters have the service mesh instance 'istio' corresponding to the service mesh that does not contain root certificate 'a' installed, then that service mesh instance 'istio' can be uninstalled, and the service mesh instance 'istio' corresponding to mesh1 that contains root certificate 'a' can be reinstalled.

[0077] The above-described process for installing Istio takes installing Istio on cluster A as an example. First, a certificate can be issued for cluster A. This certificate can be a certificate issued under the root certificate 'a' mentioned above. After the certificate is signed and approved, the corresponding CNI, network model, and control panel model can be selected for cluster A according to the user's specific usage requirements. Then, Istio can be installed. After the installation is complete, the east-wast gateway for cross-cluster communication and the remote-secret for inter-cluster communication can be configured and installed.

[0078] After completing the above istio installation, the Operator module can log in to cluster A using the account and password of the Master of cluster A, and can send the sum of routing information and authentication information corresponding to cluster A, cluster B and cluster C to cluster A. At the same time, it can also send the sum of the above routing information and authentication information to cluster B and cluster C in the same way.

[0079] After completing the above configuration distribution process, network pre-testing tools can be used to test the network connectivity and service connectivity between clusters A, B, and C. Three preset test cases can be run, and the test results can be output in the form of logs. If the expected test results are obtained, it can be proven that the takeover was successful. If the test results are not as expected, manual troubleshooting can be performed, and it can be determined that the takeover of clusters A, B, and C has failed. The takeover logic can then be re-executed for clusters A, B, and C.

[0080] Corresponding to the embodiments of the above-described cluster network access method, this specification also provides an embodiment of a cluster network access system.

[0081] Please see Figure 2 , Figure 2 This is a schematic diagram of the electronic device housing the cluster network access system in one embodiment of this specification. At the hardware level, the device includes a processor 202, an internal bus 204, a network interface 206, memory 208, and non-volatile memory 210, and may also include other hardware required for various services. One or more embodiments of this specification can be implemented in software, for example, the processor 202 can read the corresponding computer program from the non-volatile memory 210 into memory 208 and then run it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0082] Please see Figure 3 , Figure 3 This is a block diagram of a trunking network access system according to one embodiment of this specification. This trunking network access device can be applied to, for example... Figure 2 The illustrated electronic device is used to implement the technical solution described in this specification. The cluster network access system is applied to the operator module in the Kubernetes cluster to be taken over, and the system may include:

[0083] The listening unit is used to listen to the user's input of custom resources and determine whether the custom resources include the takeover information required to take over the Kubernetes cluster to be taken over.

[0084] The execution unit is used to execute the takeover processing logic defined in the operator module corresponding to the takeover information, obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information, and send the obtained configuration information to each Kubernetes cluster to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

[0085] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0086] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0087] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0088] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0089] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0090] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0091] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0092] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0093] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A cluster network access method, applied to an operator module in a Kubernetes cluster to be taken over, the method comprising: Listen for user-inputted custom resources and determine whether the custom resources include takeover information required for taking over the Kubernetes cluster to be taken over; the takeover information includes network information parameters of the Kubernetes cluster to be taken over. If so, execute the takeover processing logic defined in the operator module corresponding to the takeover information, and obtain the configuration information contained in the takeover information corresponding to the Kubernetes cluster to be taken over; the execution of the takeover processing logic defined in the operator module corresponding to the takeover information and obtaining the configuration information contained in the takeover information corresponding to the Kubernetes cluster to be taken over includes: storing the network information parameters of the Kubernetes cluster to be taken over to the database, and generating routing information corresponding to all Kubernetes clusters to be taken over based on the network information parameters in the database corresponding to the Kubernetes cluster to be taken over; Before distributing the configuration information to each Kubernetes cluster to be taken over, a service mesh containing the first root certificate is created, and it is determined whether the Kubernetes cluster to be taken over has a service mesh instance corresponding to the service mesh without the first root certificate installed. If so, the service mesh instance corresponding to the service mesh without the first root certificate is uninstalled, and the service mesh instance corresponding to the service mesh containing the first root certificate is reinstalled on the Kubernetes cluster to be taken over. If not, the service mesh instance corresponding to the service mesh containing the first root certificate is installed on the Kubernetes cluster to be taken over. The obtained configuration information is distributed to each Kubernetes cluster to be taken over, so as to complete the automated takeover of each Kubernetes cluster to be taken over.

2. The method according to claim 1, wherein the takeover information further includes the account and password of the control node of the Kubernetes cluster to be taken over, as well as the address of the authentication information; The process involves executing the takeover processing logic defined in the operator module corresponding to the takeover information, and obtaining the configuration information corresponding to the Kubernetes cluster to be taken over, contained in the takeover information, including: Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over; Based on the address of the authentication information corresponding to the Kubernetes cluster to be taken over, obtain the authentication information corresponding to the Kubernetes cluster to be taken over, and store the authentication information in the database; Based on the authentication information corresponding to the Kubernetes clusters to be taken over in the database, generate the sum of authentication information for all Kubernetes clusters to be taken over.

3. The method according to claim 1, wherein the configuration information includes routing information; The step of distributing the configuration information to each Kubernetes cluster to be taken over includes: Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over; The routing information corresponding to all Kubernetes clusters to be taken over will be sent to the logged-in Kubernetes clusters to be taken over.

4. The method according to claim 2, wherein the configuration information includes authentication information; The step of distributing the configuration information to each Kubernetes cluster to be taken over includes: Log in to the Kubernetes cluster to be taken over based on the account and password of the control node corresponding to the Kubernetes cluster to be taken over; The authentication information of all Kubernetes clusters awaiting takeover is summed and sent to the logged-in Kubernetes clusters awaiting takeover.

5. A cluster network access system, applied to an operator module in a Kubernetes cluster to be taken over, the system comprising: The listening unit is used to listen to user-inputted custom resources and determine whether the custom resources include takeover information required for taking over the Kubernetes cluster to be taken over; the takeover information includes network information parameters of the Kubernetes cluster to be taken over. An execution unit is configured to, when it is determined that the custom resource includes takeover information required for taking over the Kubernetes cluster to be taken over, execute the takeover processing logic defined in the operator module corresponding to the takeover information, and obtain the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information; the execution of the takeover processing logic defined in the operator module corresponding to the takeover information and obtaining the configuration information corresponding to the Kubernetes cluster to be taken over contained in the takeover information includes: storing the network information parameters of the Kubernetes cluster to be taken over to a database, and generating routing information corresponding to all Kubernetes clusters to be taken over based on the network information parameters corresponding to the Kubernetes cluster to be taken over in the database; The execution unit is further configured to, before distributing the configuration information to each Kubernetes cluster to be taken over, create a service mesh containing a first root certificate, and determine whether the Kubernetes cluster to be taken over has a service mesh instance corresponding to the service mesh without a first root certificate installed; if so, uninstall the service mesh instance corresponding to the service mesh without a first root certificate, and reinstall the service mesh instance corresponding to the service mesh containing the first root certificate on the Kubernetes cluster to be taken over; if not, install the service mesh instance corresponding to the service mesh containing the first root certificate on the Kubernetes cluster to be taken over; and distribute the obtained configuration information to each Kubernetes cluster to be taken over to complete the automated takeover of each Kubernetes cluster to be taken over.

6. An electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 4 by invoking the machine-readable instructions.

7. A machine-readable storage medium storing machine-readable instructions that, when invoked and executed by a processor, implement the method of any one of claims 1 to 4.

Images